Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 4 Jul 2023 07:43:47 +0200 | From | Steffen Klassert <> | Subject | Re: [PATCH v3] net: xfrm: Fix xfrm_address_filter OOB read |
| |
On Tue, Jun 27, 2023 at 11:31:38AM +0800, Lin Ma wrote: > We found below OOB crash: > > [ 44.211730] ================================================================== > [ 44.212045] BUG: KASAN: slab-out-of-bounds in memcmp+0x8b/0xb0 > [ 44.212045] Read of size 8 at addr ffff88800870f320 by task poc.xfrm/97 > [ 44.212045] > [ 44.212045] CPU: 0 PID: 97 Comm: poc.xfrm Not tainted 6.4.0-rc7-00072-gdad9774deaf1-dirty #4 > [ 44.212045] Call Trace: > [ 44.212045] <TASK> > [ 44.212045] dump_stack_lvl+0x37/0x50 > [ 44.212045] print_report+0xcc/0x620 > [ 44.212045] ? __virt_addr_valid+0xf3/0x170 > [ 44.212045] ? memcmp+0x8b/0xb0 > [ 44.212045] kasan_report+0xb2/0xe0 > [ 44.212045] ? memcmp+0x8b/0xb0 > [ 44.212045] kasan_check_range+0x39/0x1c0 > [ 44.212045] memcmp+0x8b/0xb0 > [ 44.212045] xfrm_state_walk+0x21c/0x420
...
> > By investigating the code, we find the root cause of this OOB is the lack > of checks in xfrm_dump_sa(). The buggy code allows a malicious user to pass > arbitrary value of filter->splen/dplen. Hence, with crafted xfrm states, > the attacker can achieve 8 bytes heap OOB read, which causes info leak. > > if (attrs[XFRMA_ADDRESS_FILTER]) { > filter = kmemdup(nla_data(attrs[XFRMA_ADDRESS_FILTER]), > sizeof(*filter), GFP_KERNEL); > if (filter == NULL) > return -ENOMEM; > // NO MORE CHECKS HERE !!! > } > > This patch fixes the OOB by adding necessary boundary checks, just like > the code in pfkey_dump() function. > > Fixes: d3623099d350 ("ipsec: add support of limited SA dump") > Signed-off-by: Lin Ma <linma@zju.edu.cn>
Applied, thanks a lot!
| ![\](/images/icornerr.gif) |