CVE-2025-37752

Published May 1, 2025

Last updated 4 days ago

CVSS high 7.8
Linux Kernel

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-37752 is an array-out-of-bounds vulnerability found in the Linux kernel's network packet scheduler, specifically within the Stochastic Fairness Queueing (SFQ) queuing discipline. The vulnerability stems from insufficient validation of the SFQ limit parameter. An invalid SFQ limit, combined with interactions between SFQ and the TBF Qdisc, can lead to writing a 0x0000 value approximately 256KB out of bounds at a misaligned offset. The vulnerability occurs because the limit validation is performed directly on user-provided data without considering how other parameter changes might affect the limit value. This can lead to scenarios where the limit is indirectly updated through configurations. When exploited, this can trigger an array-index-out-of-bounds condition in `net/sched/sch_sfq.c`.

Description
In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: move the limit validation It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed. Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations: tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1 This fixes the following syzkaller reported crash: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [inline] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD status
Modified
Products
linux_kernel, debian_linux

Risk scores

CVSS 3.1

Type
Primary
Base score
7.8
Impact score
5.9
Exploitability score
1.8
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity
HIGH

Weaknesses

nvd@nist.gov
CWE-129

Social media

Hype score
Not currently trending
  1. Exploiting an array Out-Of-Bounds vulnerability in the Linux network packet scheduler (CVE-2025-37752) https://t.co/5uObf9u1ei

    @Aadriksh

    11 Sept 2025

    9602 Impressions

    25 Retweets

    322 Likes

    171 Bookmarks

    3 Replies

    0 Quotes

  2. Exploiting an array-Out-Of-Bounds vulnerability in the Linux network packet scheduler (CVE-2025-37752) https://t.co/UdEJrQyekL #infosec #Linux https://t.co/snHo6lHNwo

    @0xor0ne

    8 Sept 2025

    12336 Impressions

    48 Retweets

    318 Likes

    124 Bookmarks

    2 Replies

    0 Quotes

  3. 🚨 Critical kernel patches released for #Ubuntu 16.04/14.04 LTS (USN-7727-1). Impacts AWS, KVM, &amp; generic systems. CVEs include CVE-2024-50051, CVE-2025-37752. Read more: 👉 https://t.co/ZKeMWeLAIf #Security https://t.co/Zw16SoURGi

    @Cezar_H_Linux

    29 Aug 2025

    18 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. 🔒 URGENT: #openSUSE kernel patches for 3 critical CVEs (CVE-2025-37797, CVE-2025-37752, CVE-2025-21702) are live! DoS risks threaten unpatched systems—especially networks using HFSC/SFQ scheduling. 👉 https://t.co/JkPnR7DScY https://t.co/dKVwjDqDG6

    @Cezar_H_Linux

    5 Aug 2025

    38 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. 🚨 Critical #LinuxKernel Patches! SUSE Live Patch 38 (SLE 15 SP4 / openSUSE Leap 15.4) fixes 4 HIGH-sev vulns: ✅ CVE-2025-37797 (HFSC UAF). ✅ CVE-2024-53125 (BPF flaw). ✅ CVE-2025-21702 (pfifo). ✅ CVE-2025-37752 (SFQ). Read more:👉 https://t.co/9xiz3h2QSu https://t.c

    @Cezar_H_Linux

    4 Aug 2025

    46 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. Exploiting CVE-2025-37752: array-Out-Of-Bounds vulnerability in the Linux network packet scheduler https://t.co/UdEJrQyekL #infosec #Linux https://t.co/d445rudk3F

    @0xor0ne

    31 Jul 2025

    8108 Impressions

    38 Retweets

    211 Likes

    61 Bookmarks

    2 Replies

    0 Quotes

  7. Array-Out-Of-Bounds exploitation in the Linux network packet scheduler (CVE-2025-37752) https://t.co/UdEJrQyekL #infosec #Linux https://t.co/QEiHDYTDIV

    @0xor0ne

    6 Jul 2025

    7009 Impressions

    26 Retweets

    175 Likes

    75 Bookmarks

    0 Replies

    1 Quote

  8. Exploiting an array-Out-Of-Bounds vulnerability in the Linux network packet scheduler (CVE-2025-37752) https://t.co/UdEJrQyekL #infosec #Linux https://t.co/DyklTHr1sk

    @0xor0ne

    6 Jun 2025

    11096 Impressions

    46 Retweets

    297 Likes

    113 Bookmarks

    2 Replies

    0 Quotes

  9. Top 5 Trending CVEs: 1 - CVE-2025-3935 2 - CVE-2024-29269 3 - CVE-2024-29847 4 - CVE-2025-30397 5 - CVE-2025-37752 #cve #cvetrends #cveshield #cybersecurity https://t.co/4Fua3CAN6W

    @CVEShield

    1 Jun 2025

    18 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  10. Khai thác lỗ hổng Array-Out-Of-Bounds trong trình lập lịch gói mạng Linux (CVE-2025-37752) https://t.co/1IYK9PRSAB

    @tuong_nguyen8

    1 Jun 2025

    6 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. Exploiting an Array-Out-Of-Bounds vulnerability in the Linux network packet scheduler (CVE-2025-37752) https://t.co/UdEJrQyekL #infosec #Linux https://t.co/uqatAFi7FD

    @0xor0ne

    31 May 2025

    8613 Impressions

    40 Retweets

    210 Likes

    82 Bookmarks

    1 Reply

    0 Quotes

  12. [CVE-2025-37752] Two Bytes Of Madness: Pwning The Linux Kernel With A 0x0000 Written 262636 Bytes Out-Of-Bounds Great article by D3vil about exploiting a type confusion in the network scheduler subsystem and pwning all kernelCTF instances. https://t.co/lpZyXYFM3w https://t.co/U

    @linkersec

    13 May 2025

    5569 Impressions

    32 Retweets

    141 Likes

    67 Bookmarks

    1 Reply

    2 Quotes

  13. CVE-2025-37752 : Two Bytes Of Madness: Pwning The Linux Kernel With A 0x0000 Written 262636 Bytes Out-Of-Bounds https://t.co/ruMufIUtxj

    @freedomhack101

    13 May 2025

    64 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  14. [CVE-2025-37752] Two Bytes Of Madness: Pwning The Linux Kernel With A 0x0000 Written 262636 Bytes Out-Of-Bounds https://t.co/0MknQ7evhq

    @akaclandestine

    12 May 2025

    3548 Impressions

    16 Retweets

    74 Likes

    28 Bookmarks

    1 Reply

    1 Quote

  15. Top 5 Trending CVEs: 1 - CVE-2025-37752 2 - CVE-2025-0995 3 - CVE-2025-1550 4 - CVE-2025-24203 5 - CVE-2025-32819 #cve #cvetrends #cveshield #cybersecurity https://t.co/4Fua3CAN6W

    @CVEShield

    12 May 2025

    13 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  16. [CVE-2025-37752] Two Bytes Of Madness: Pwning The Linux Kernel With A 0x0000 Written 262636 Bytes Out-Of-Bound by @cor_ctf D3vil https://t.co/m2O4XYyJpD https://t.co/cVdDtUTima

    @alexjplaskett

    11 May 2025

    4495 Impressions

    24 Retweets

    83 Likes

    43 Bookmarks

    0 Replies

    0 Quotes

  17. We are back😎 Say hello to our kernelCTF submission for CVE-2025-37752🩸 Who would have thought you could pwn a kernel with just a 0x0000 written 262636 bytes out of bounds? Read the full writeup at: https://t.co/GkpCjamlaZ 👀

    @cor_ctf

    6 May 2025

    4944 Impressions

    43 Retweets

    138 Likes

    53 Bookmarks

    0 Replies

    0 Quotes

Configurations

  1. In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK> Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.CVE-2026-63807
  2. In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: <TASK> __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf </TASK> Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on "normal" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.CVE-2026-63806
  3. In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.CVE-2026-63803