CVE-2025-38617

Published Aug 22, 2025

Last updated 10 days ago

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-38617 describes a race condition vulnerability found within the Linux kernel's networking subsystem. Specifically, the flaw occurs in the `net/packet` module during the interaction between the `packet_set_ring()` and `packet_notifier()` functions. The vulnerability arises when `packet_set_ring()` releases the `po->bind_lock`, which can allow a separate thread to execute `packet_notifier()` and process an `NETDEV_UP` event. This race condition is analogous to a previously addressed issue. The resolution involves temporarily setting `po->num` to zero, ensuring the socket remains unhooked until the lock is reacquired.

Description
In the Linux kernel, the following vulnerability has been resolved: net/packet: fix a race in packet_set_ring() and packet_notifier() When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event. This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()"). There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken. The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history.
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD status
Modified
Products
linux_kernel, debian_linux

Risk scores

CVSS 3.1

Type
Primary
Base score
4.7
Impact score
3.6
Exploitability score
1
Vector string
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Severity
MEDIUM

Weaknesses

nvd@nist.gov
CWE-362

Social media

Hype score
Not currently trending
  1. Exploiting a use-after-free vulnerability in the Linux kernel’s packet socket subsystem, caused by a race condition between packet_set_ring() and packet_notifier() (CVE-2025-38617) https://t.co/F86BqcWmYk #infosec https://t.co/i8re1JTtT2

    @0xor0ne

    12 Apr 2026

    5999 Impressions

    24 Retweets

    119 Likes

    61 Bookmarks

    1 Reply

    0 Quotes

  2. A Race Within A Race: Exploiting CVE-2025-38617 in Linux Packet Sockets https://t.co/r5rJhupZPm

    @Komodosec

    6 Apr 2026

    160 Impressions

    1 Retweet

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. A Race Within A Race: Exploiting CVE-2025-38617 in Linux Packet Sockets.. A step-by-step guide to exploiting a 20-year-old bug in the Linux kernel..  https://t.co/2ZIj4pf629

    @Tinolle1955

    26 Mar 2026

    721 Impressions

    1 Retweet

    11 Likes

    7 Bookmarks

    0 Replies

    0 Quotes

  4. A Race Within a Race: Exploiting CVE-2025-38617 in Linux Packet Sockets https://t.co/Guhe2dTHrm

    @angsuman

    21 Mar 2026

    103 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. Exploitation of CVE-2025-38617 in Linux Packet Sockets The article examines the exploitation of a race condition vulnerability in the Linux kernel’s packet socket subsystem (CVE-2025-38617 -> (https://t.co/WsSNB0cYmd)). The flaw allows an attacker to achieve local privilege

    @ptdbugs

    17 Mar 2026

    136 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. A Race Within A Race: Exploiting CVE-2025-38617 in Linux Packet Sockets Excellent article by Quang Le about exploiting CVE-2025-38617 — a race condition that leads to a use-after-free in the packet sockets implementation. https://t.co/aSys46Iit8 https://t.co/uRXwbhCRDf

    @linkersec

    17 Mar 2026

    4361 Impressions

    12 Retweets

    87 Likes

    44 Bookmarks

    2 Replies

    0 Quotes

  7. CVE-2025-38617 es una vulnerabilidad use-after-free en el subsistema de packet sockets del kernel Linux, causada por una race condition. El bug existía desde Linux 2.6.12 (2005) y fue corregido en la versión 6.16. 20 años en producción. Sin que nadie lo viera ¿Cuántos + ha

    @Zymeralabs

    12 Mar 2026

    108 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. Top 5 Trending CVEs: 1 - CVE-2025-54236 2 - CVE-2025-38617 3 - CVE-2026-21513 4 - CVE-2026-3102 5 - CVE-2017-7921 #cve #cvetrends #cveshield #cybersecurity https://t.co/4Fua3CAN6W

    @CVEShield

    10 Mar 2026

    173 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  9. Analysis and exploitation of CVE-2025-38617, a race condition based use-after-free vulnerability in the Linux kernel’s packet socket subsystem (@calif_io) https://t.co/F86BqcWmYk #Linux #infosec https://t.co/Q6oWLni1KA

    @0xor0ne

    9 Mar 2026

    4873 Impressions

    20 Retweets

    101 Likes

    46 Bookmarks

    1 Reply

    0 Quotes

  10. Exploiting CVE-2025-38617 in Linux Packet Sockets https://t.co/SJxKtKR784

    @Dinosn

    7 Mar 2026

    1730 Impressions

    3 Retweets

    17 Likes

    9 Bookmarks

    1 Reply

    0 Quotes

  11. A Race Within A Race: Exploiting CVE-2025-38617 in Linux Packet Sockets https://t.co/SJxKtKR784

    @Dinosn

    7 Mar 2026

    1665 Impressions

    3 Retweets

    19 Likes

    7 Bookmarks

    0 Replies

    0 Quotes

  12. CVE-2025-38617 vulnerability allows attackers to exploit Linux packet sockets, potentially leading to privilege escalation. https://t.co/jELT5q6mWD

    @Crash0verr1d3

    7 Mar 2026

    70 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  13. A Race Within A Race: Exploiting CVE-2025-38617 in Linux Packet Sockets https://t.co/cohac2JCu3

    @_r_netsec

    6 Mar 2026

    786 Impressions

    1 Retweet

    7 Likes

    3 Bookmarks

    0 Replies

    0 Quotes

  14. Top 5 Trending CVEs: 1 - CVE-2024-23222 2 - CVE-2026-22719 3 - CVE-2026-25611 4 - CVE-2025-38617 5 - CVE-2026-21902 #cve #cvetrends #cveshield #cybersecurity https://t.co/4Fua3CAN6W

    @CVEShield

    5 Mar 2026

    232 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  15. #exploit #Kernel_Security A Race Within A Race: Exploiting CVE-2025-38617 in Linux Packet Sockets https://t.co/oavL2He7Ll // A step-by-step guide to exploiting a 20-year-old bug in the Linux kernel to achieve full privilege escalation and container escape, plus a cool bug-hunting

    @ksg93rd

    4 Mar 2026

    531 Impressions

    2 Retweets

    10 Likes

    2 Bookmarks

    0 Replies

    0 Quotes

  16. 20年以上潜伏していたLinuxカーネルの欠陥が、ついに特権昇格とコンテナ脱出を可能にする深刻な脆弱性として明らかになった。単純な競合条件が高度な防御機構を突破する実証も示された。 CVE-2025-38617は、Li

    @yousukezan

    3 Mar 2026

    32362 Impressions

    196 Retweets

    465 Likes

    208 Bookmarks

    3 Replies

    3 Quotes

  17. A Race Within A Race: Exploiting CVE-2025-38617 in Linux Packet Sockets. A step-by-step guide to exploiting a 20-year-old bug in the Linux kernel to achieve full privilege escalation and container escape, plus a cool bug-hunting heuristic. https://t.co/IxURrHpBT0

    @calif_io

    3 Mar 2026

    7382 Impressions

    37 Retweets

    114 Likes

    71 Bookmarks

    3 Replies

    0 Quotes

  18. CVE-2025-38617 In the Linux kernel, the following vulnerability has been resolved: net/packet: fix a race in packet_set_ring() and packet_notifier() When packet_set_ring() release… https://t.co/aKmKSqg5Ei

    @CVEnew

    22 Aug 2025

    261 Impressions

    0 Retweets

    0 Likes

    0 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