{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2023-53752","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2025-12-08T01:18:04.279Z","datePublished":"2025-12-08T01:19:12.407Z","dateUpdated":"2026-08-05T09:15:48.993Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-05T09:15:48.993Z"},"descriptions":[{"lang":"en","value":"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"}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"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 — 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 — 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 — 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."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["net/core/skbuff.c"],"versions":[{"version":"0dbc898f5917c5a3bec6be19d9f5469cbc351a7d","lessThan":"31cf7853a940181593e4472fc56f46574123f9f6","status":"affected","versionType":"git"},{"version":"12d6c1d3a2ad0c199ec57c201cdc71e8e157a232","lessThan":"e4ffc47a1c3e5d11a853aa178c9a5136e79412e9","status":"affected","versionType":"git"},{"version":"12d6c1d3a2ad0c199ec57c201cdc71e8e157a232","lessThan":"bf7da02d2b8faf324206e1cbe64a4813ff903cc1","status":"affected","versionType":"git"},{"version":"12d6c1d3a2ad0c199ec57c201cdc71e8e157a232","lessThan":"915d975b2ffa58a14bfcf16fafe00c41315949ff","status":"affected","versionType":"git"},{"version":"6.1.31","lessThan":"6.1.54","status":"affected","versionType":"semver"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["net/core/skbuff.c"],"versions":[{"version":"6.2","status":"affected"},{"version":"0","lessThan":"6.2","status":"unaffected","versionType":"semver"},{"version":"6.1.54","lessThanOrEqual":"6.1.*","status":"unaffected","versionType":"semver"},{"version":"6.4.16","lessThanOrEqual":"6.4.*","status":"unaffected","versionType":"semver"},{"version":"6.5.3","lessThanOrEqual":"6.5.*","status":"unaffected","versionType":"semver"},{"version":"6.6","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.1.31","versionEndExcluding":"6.1.54"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.2","versionEndExcluding":"6.4.16"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.2","versionEndExcluding":"6.5.3"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.2","versionEndExcluding":"6.6"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/31cf7853a940181593e4472fc56f46574123f9f6"},{"url":"https://git.kernel.org/stable/c/e4ffc47a1c3e5d11a853aa178c9a5136e79412e9"},{"url":"https://git.kernel.org/stable/c/bf7da02d2b8faf324206e1cbe64a4813ff903cc1"},{"url":"https://git.kernel.org/stable/c/915d975b2ffa58a14bfcf16fafe00c41315949ff"}],"title":"net: deal with integer overflows in kmalloc_reserve()","x_generator":{"engine":"bippy-1.2.0"}}}}