{ "schema_version": "1.6.1", "id": "RPI-CVE-2023-53752", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2023-53752" ], "published": "2025-12-08T01:19:54Z", "summary": "net: deal with integer overflows in kmalloc_reserve()", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: deal with integer overflows in kmalloc_reserve()\n\nBlamed commit changed:\n ptr = kmalloc(size);\n if (ptr)\n size = ksize(ptr);\n\n size = kmalloc_size_roundup(size);\n ptr = kmalloc(size);\n\nThis allowed various crash as reported by syzbot [1]\nand Kyle Zeng.\n\nProblem is that if @size is bigger than 0x80000001,\nkmalloc_size_roundup(size) returns 2^32.\n\nkmalloc_reserve() uses a 32bit variable (obj_size),\nso 2^32 is truncated to 0.\n\nkmalloc(0) returns ZERO_SIZE_PTR which is not handled by\nskb allocations.\n\nFollowing trace can be triggered if a netdev->mtu is set\nclose to 0x7fffffff\n\nWe might in the future limit netdev->mtu to more sensible\nlimit (like KMALLOC_MAX_SIZE).\n\nThis patch is based on a syzbot report, and also a report\nand tentative fix from Kyle Zeng.\n\n[1]\nBUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline]\nBUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527\nWrite of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554\n\nCPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023\nCall trace:\ndump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279\nshow_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106\nprint_report+0xe4/0x4b4 mm/kasan/report.c:398\nkasan_report+0x150/0x1ac mm/kasan/report.c:495\nkasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189\nmemset+0x40/0x70 mm/kasan/shadow.c:44\n__build_skb_around net/core/skbuff.c:294 [inline]\n__alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527\nalloc_skb include/linux/skbuff.h:1316 [inline]\nigmpv3_newpack+0x104/0x1088 net/ipv4/igmp.c:359\nadd_grec+0x81c/0x1124 net/ipv4/igmp.c:534\nigmpv3_send_cr net/ipv4/igmp.c:667 [inline]\nigmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810\ncall_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474\nexpire_timers kernel/time/timer.c:1519 [inline]\n__run_timers+0x54c/0x710 kernel/time/timer.c:1790\nrun_timer_softirq+0x28/0x4c kernel/time/timer.c:1803\n_stext+0x380/0xfbc\n____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79\ncall_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891\ndo_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:84\ninvoke_softirq kernel/softirq.c:437 [inline]\n__irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683\nirq_exit_rcu+0x14/0x78 kernel/softirq.c:695\nel0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry-common.c:717\n__el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724\nel0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729\nel0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S:584", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt2", "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi2-rpi-v6", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7l", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v8", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt2": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.54" }, "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.54", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2023-53752" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/31cf7853a940181593e4472fc56f46574123f9f6" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e4ffc47a1c3e5d11a853aa178c9a5136e79412e9" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/bf7da02d2b8faf324206e1cbe64a4813ff903cc1" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/915d975b2ffa58a14bfcf16fafe00c41315949ff" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:24:39Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - Triggering the overflow requires a locally-configured netdev MTU near 0x7fffffff (set via rtnetlink/ioctl) plus a local socket joining a multicast group; no remote peer can induce a >2GB skb allocation. The vulnerable code is thus reached only through local syscalls.\nAC:L - The overflow is fully deterministic \u2014 kmalloc(0) always returns ZERO_SIZE_PTR with no memory pressure or timing dependency, so every IGMP/MLD report on the oversized-MTU device corrupts memory. No race, memory-layout guess, or condition outside attacker control is involved.\nPR:L - Setting a huge MTU needs CAP_NET_ADMIN, but an unprivileged user obtains it over their own netns via `unshare -Urn`, and the always-present `lo` device has no max_mtu cap \u2014 verified working on a current kernel. Joining the multicast group that arms the IGMP timer needs no privileges at all.\nUI:N - The attacker performs every step themselves \u2014 namespace creation, MTU configuration, and the multicast join that arms the IGMP timer. No victim action is required.\nS:U - The corruption occurs within the kernel's own memory-management and skb handling, the same security authority as the vulnerable component. No VM, IOMMU, or hypervisor boundary is crossed.\nC:H - The skb is built with head=ZERO_SIZE_PTR and a ~4GB end offset, so skb_shared_info and packet data land at low, user-mappable addresses; on systems without SMAP/PAN (ARM/embedded/older x86, as in the arm64 syzbot report where the access actually reached user memory) the attacker can pre-map that page and have the kernel populate attacker-readable memory, and the resulting control over shinfo->frags gives an arbitrary kernel read primitive.\nI:H - This is an unbounded wild-write: the kernel memsets and then writes packet contents through a bogus head pointer at attacker-influenced offsets, and if skb_shared_info is placed in attacker-mapped memory the kernel dereferences attacker-controlled nr_frags/frags[]/frag_list/destructor_arg, yielding an arbitrary write and control-flow hijack primitive.\nA:H - In the common case the wild write hits an unmapped or SMAP-protected address from softirq (timer) context, producing an immediate kernel oops/panic as shown in the syzbot KASAN report. The crash is reliably reproducible by any local unprivileged user." } } }