[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Linux kernel: heap out of bounds write in nf_dup_netdev.c since 5.4
From:       Salvatore Bonaccorso <carnil () debian ! org>
Date:       2022-02-22 6:35:10
Message-ID: YhSEHmSudhT0ig/f () eldamar ! lan
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]