This is a note to let you know that I've just added the patch titled
net: deal with integer overflows in kmalloc_reserve()
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
net-deal-with-integer-overflows-in-kmalloc_reserve.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <
sta...@vger.kernel.org> know about it.
From
stable...@vger.kernel.org Fri Sep 15 20:23:47 2023
From: Ajay Kaher <
aka...@vmware.com>
Date: Fri, 15 Sep 2023 23:51:05 +0530
Subject: net: deal with integer overflows in kmalloc_reserve()
To:
sta...@vger.kernel.org
Cc:
da...@davemloft.net,
edum...@google.com,
ku...@kernel.org,
pab...@redhat.com,
alexand...@fb.com,
soh...@google.com,
net...@vger.kernel.org,
na...@vmware.com,
amak...@vmware.com,
vsirn...@vmware.com,
er.aja...@gmail.com,
aka...@vmware.com, Kees Cook <
kees...@chromium.org>, Vlastimil Babka <
vba...@suse.cz>
Message-ID: <
1694802065-1821-5-g...@vmware.com>
From: Eric Dumazet <
edum...@google.com>
commit 915d975b2ffa58a14bfcf16fafe00c41315949ff upstream.
Blamed commit changed:
ptr = kmalloc(size);
if (ptr)
size = ksize(ptr);
to:
size = kmalloc_size_roundup(size);
ptr = kmalloc(size);
This allowed various crash as reported by syzbot [1]
and Kyle Zeng.
Problem is that if @size is bigger than 0x80000001,
kmalloc_size_roundup(size) returns 2^32.
kmalloc_reserve() uses a 32bit variable (obj_size),
so 2^32 is truncated to 0.
kmalloc(0) returns ZERO_SIZE_PTR which is not handled by
skb allocations.
Following trace can be triggered if a netdev->mtu is set
close to 0x7fffffff
We might in the future limit netdev->mtu to more sensible
limit (like KMALLOC_MAX_SIZE).
This patch is based on a syzbot report, and also a report
and tentative fix from Kyle Zeng.
[1]
BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline]
BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527
Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554
CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023
Call trace:
dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106
print_report+0xe4/0x4b4 mm/kasan/report.c:398
kasan_report+0x150/0x1ac mm/kasan/report.c:495
kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189
memset+0x40/0x70 mm/kasan/shadow.c:44
__build_skb_around net/core/skbuff.c:294 [inline]
__alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527
alloc_skb include/linux/skbuff.h:1316 [inline]
igmpv3_newpack+0x104/0x1088 net/ipv4/igmp.c:359
add_grec+0x81c/0x1124 net/ipv4/igmp.c:534
igmpv3_send_cr net/ipv4/igmp.c:667 [inline]
igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810
call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474
expire_timers kernel/time/timer.c:1519 [inline]
__run_timers+0x54c/0x710 kernel/time/timer.c:1790
run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803
_stext+0x380/0xfbc
____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79
call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891
do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:84
invoke_softirq kernel/softirq.c:437 [inline]
__irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683
irq_exit_rcu+0x14/0x78 kernel/softirq.c:695
el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry-common.c:717
__el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724
el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729
el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S:584
Fixes: 12d6c1d3a2ad ("skbuff: Proactively round up to kmalloc bucket size")
Reported-by: syzbot <
syzk...@googlegroups.com>
Reported-by: Kyle Zeng <
zengy...@gmail.com>
Signed-off-by: Eric Dumazet <
edum...@google.com>
Cc: Kees Cook <
kees...@chromium.org>
Cc: Vlastimil Babka <
vba...@suse.cz>
Signed-off-by: David S. Miller <
da...@davemloft.net>
[Ajay: Regenerated the patch for v6.1.y]
Signed-off-by: Ajay Kaher <
aka...@vmware.com>
Signed-off-by: Greg Kroah-Hartman <
gre...@linuxfoundation.org>
---
net/core/skbuff.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -428,11 +428,17 @@ static void *kmalloc_reserve(unsigned in
bool *pfmemalloc)
{
bool ret_pfmemalloc = false;
- unsigned int obj_size;
+ size_t obj_size;
void *obj;
obj_size = SKB_HEAD_ALIGN(*size);
- *size = obj_size = kmalloc_size_roundup(obj_size);
+
+ obj_size = kmalloc_size_roundup(obj_size);
+ /* The following cast might truncate high-order bits of obj_size, this
+ * is harmless because kmalloc(obj_size >= 2^32) will fail anyway.
+ */
+ *size = (unsigned int)obj_size;
+
/*
* Try a regular allocation, when that fails and we're not entitled
* to the reserves, fail.
Patches currently in stable-queue which might be from
stable...@vger.kernel.org are
queue-6.1/net-add-skb_head_align-helper.patch
queue-6.1/io_uring-don-t-set-affinity-on-a-dying-sqpoll-thread.patch
queue-6.1/net-remove-osize-variable-in-__alloc_skb.patch
queue-6.1/io_uring-always-lock-in-io_apoll_task_func.patch
queue-6.1/net-factorize-code-in-kmalloc_reserve.patch
queue-6.1/io_uring-revert-io_uring-fix-multishot-accept-ordering.patch
queue-6.1/io_uring-net-don-t-overflow-multishot-accept.patch
queue-6.1/io_uring-sqpoll-fix-io-wq-affinity-when-ioring_setup_sqpoll-is-used.patch
queue-6.1/io_uring-break-out-of-iowq-iopoll-on-teardown.patch
queue-6.1/net-deal-with-integer-overflows-in-kmalloc_reserve.patch