lkml.org 
[lkml]   [2023]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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!

\
 
 \ /
  Last update: 2023-07-04 07:45    [W:0.036 / U:3.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site