Re: Linux kernel: heap out of bounds write in nf_dup_netdev.c since 5.4

[Salvatore Bonaccorso <carnil () debian org>]

Hi,

On Mon, Feb 21, 2022 at 08:38:23PM +0000, Nick Gregory wrote:
> There is a heap out of bounds write in the function nft_fwd_dup_netdev_offload (nf_dup_netdev.c). This was introduced 
> in 5.4-rc1 by 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=be2861dc36d77ff3778979b9c3c79ada4affa131,
>  and is fixed by 
> https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git/commit/?id=b1a5983f56e371046dcf164f90bfaf704d2b89f6. 
> I have created a sample LPE targeting Ubuntu 21.10 with KASLR disabled.
>
> In nft_fwd_dup_netdev_offload, ctx->num_actions++ is used to offset into the flow->rule->action.entries array 
> (nf_dup_netdev.c:67) when setting up dup or fwd flow rules on a chain with hardware offload enabled. However there is 
> a mismatch between the number of times the increment is called vs. the number of allocated entries. The allocated 
> array size is based on the number of nftables expressions that have expr.offload_flags&NFT_OFFLOAD_F_ACTION 
> (nf_tables_offload.c:97), but only the immediate expression type has this (not dup or fwd). It's possible to manually 
> create a rule with dup/fwd expressions that don't have a corresponding/preceding immediate, leading to an undersized 
> entries array, and an arbitrary number of out of bounds array writes. Despite being in code dealing with hardware 
> offload, this is reachable when targeting network devices that don't have offload functionality (e.g. lo) as the bug 
> is triggered before the rule creation fails. Additionally, while nftables requires CAP_NET_ADMIN, we can unshare into 
> a new network namespace to get this as a (normally) unprivileged user. The reproducer code below demonstrates all of 
> this, and will likely immediately panic the system.
>
> This can be turned into kernel ROP/local privilege escalation without too much difficulty, as one of the values that 
> is written out of bounds is conveniently a pointer to a net_device structure. There are many opportunities for one of 
> the OOB writes to land in another heap allocated structure which then misuses it (type confusion, freeing it, etc.). 
> Additionally, an OOB write could be landed in a buffer returned to userland, leaking the address of the net_device 
> allocation out.

This isse seems to have CVE-2022-25636 assigned.

Regards,
Salvatore