--- /dev/null
+From c3b704d4a4a265660e665df51b129e8425216ed1 Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Tue, 5 Sep 2023 04:23:38 +0000
+Subject: igmp: limit igmpv3_newpack() packet size to IP_MAX_MTU
+
+From: Eric Dumazet <edumazet@google.com>
+
+commit c3b704d4a4a265660e665df51b129e8425216ed1 upstream.
+
+This is a follow up of commit 915d975b2ffa ("net: deal with integer
+overflows in kmalloc_reserve()") based on David Laight feedback.
+
+Back in 2010, I failed to realize malicious users could set dev->mtu
+to arbitrary values. This mtu has been since limited to 0x7fffffff but
+regardless of how big dev->mtu is, it makes no sense for igmpv3_newpack()
+to allocate more than IP_MAX_MTU and risk various skb fields overflows.
+
+Fixes: 57e1ab6eaddc ("igmp: refine skb allocations")
+Link: https://lore.kernel.org/netdev/d273628df80f45428e739274ab9ecb72@AcuMS.aculab.com/
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reported-by: David Laight <David.Laight@ACULAB.COM>
+Cc: Kyle Zeng <zengyhkyle@gmail.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/igmp.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/ipv4/igmp.c
++++ b/net/ipv4/igmp.c
+@@ -353,8 +353,9 @@ static struct sk_buff *igmpv3_newpack(st
+ struct flowi4 fl4;
+ int hlen = LL_RESERVED_SPACE(dev);
+ int tlen = dev->needed_tailroom;
+- unsigned int size = mtu;
++ unsigned int size;
+
++ size = min(mtu, IP_MAX_MTU);
+ while (1) {
+ skb = alloc_skb(size + hlen + tlen,
+ GFP_ATOMIC | __GFP_NOWARN);
--- /dev/null
+From 915d975b2ffa58a14bfcf16fafe00c41315949ff Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Thu, 31 Aug 2023 18:37:50 +0000
+Subject: net: deal with integer overflows in kmalloc_reserve()
+
+From: Eric Dumazet <edumazet@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 <syzkaller@googlegroups.com>
+Reported-by: Kyle Zeng <zengyhkyle@gmail.com>
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/skbuff.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/net/core/skbuff.c
++++ b/net/core/skbuff.c
+@@ -550,7 +550,7 @@ 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);
+@@ -567,7 +567,13 @@ static void *kmalloc_reserve(unsigned in
+ obj = kmem_cache_alloc_node(skb_small_head_cache, flags, node);
+ goto out;
+ }
+- *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.
--- /dev/null
+From 050d91c03b28ca479df13dfb02bcd2c60dd6a878 Mon Sep 17 00:00:00 2001
+From: Kyle Zeng <zengyhkyle@gmail.com>
+Date: Tue, 5 Sep 2023 15:04:09 -0700
+Subject: netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c
+
+From: Kyle Zeng <zengyhkyle@gmail.com>
+
+commit 050d91c03b28ca479df13dfb02bcd2c60dd6a878 upstream.
+
+The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can
+lead to the use of wrong `CIDR_POS(c)` for calculating array offsets,
+which can lead to integer underflow. As a result, it leads to slab
+out-of-bound access.
+This patch adds back the IP_SET_HASH_WITH_NET0 macro to
+ip_set_hash_netportnet to address the issue.
+
+Fixes: 886503f34d63 ("netfilter: ipset: actually allow allowable CIDR 0 in hash:net,port,net")
+Suggested-by: Jozsef Kadlecsik <kadlec@netfilter.org>
+Signed-off-by: Kyle Zeng <zengyhkyle@gmail.com>
+Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org>
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/netfilter/ipset/ip_set_hash_netportnet.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/netfilter/ipset/ip_set_hash_netportnet.c
++++ b/net/netfilter/ipset/ip_set_hash_netportnet.c
+@@ -36,6 +36,7 @@ MODULE_ALIAS("ip_set_hash:net,port,net")
+ #define IP_SET_HASH_WITH_PROTO
+ #define IP_SET_HASH_WITH_NETS
+ #define IPSET_NET_COUNT 2
++#define IP_SET_HASH_WITH_NET0
+
+ /* IPv4 variant */
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
