CVE-2025-38617

Published Aug 22, 2025

Last updated a month 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: usb: misc: usbio: fix disconnect UAF in client teardown usbio_disconnect() walks usbio->cli_list in reverse and uninitializes each auxiliary device. auxiliary_device_uninit() drops the device reference, and for an unbound child that can run usbio_auxdev_release() and free the containing struct usbio_client. list_for_each_entry_reverse() advances after the loop body by reading client->link.prev. If the current client is freed by auxiliary_device_uninit(), the iterator dereferences freed memory. Use list_for_each_entry_safe_reverse() so the previous client is cached before the body can drop the final reference. This preserves reverse teardown order while keeping the next iterator cursor independent of the current client's lifetime. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in usbio_disconnect+0x12e/0x150 Call Trace: <TASK> dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? usbio_disconnect+0x12e/0x150 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? usbio_disconnect+0x12e/0x150 kasan_report+0xe0/0x110 ? usbio_disconnect+0x12e/0x150 usbio_disconnect+0x12e/0x150 usb_unbind_interface+0xf3/0x400 really_probe+0x316/0x660 __driver_probe_device+0x106/0x240 driver_probe_device+0x4a/0x110 __device_attach_driver+0xf1/0x1a0 ? __pfx___device_attach_driver+0x10/0x10 bus_for_each_drv+0xf9/0x160 ? __pfx_bus_for_each_drv+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x130 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __device_attach+0x133/0x2a0 ? __pfx___device_attach+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_unlock+0x9a/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 device_initial_probe+0x55/0x70 bus_probe_device+0x4a/0xd0 device_add+0x9b9/0xc10 ? __pfx_device_add+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xea/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 ? usb_enable_lpm+0x3c/0x260 usb_set_configuration+0xb64/0xf20 usb_generic_driver_probe+0x5f/0x90 usb_probe_device+0x71/0x1b0 really_probe+0x46b/0x660 __driver_probe_device+0x106/0x240 driver_probe_device+0x4a/0x110 __device_attach_driver+0xf1/0x1a0 ? __pfx___device_attach_driver+0x10/0x10 bus_for_each_drv+0xf9/0x160 ? __pfx_bus_for_each_drv+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x130 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __device_attach+0x133/0x2a0 ? __pfx___device_attach+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_unlock+0x9a/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 device_initial_probe+0x55/0x70 bus_probe_device+0x4a/0xd0 device_add+0x9b9/0xc10 ? __pfx_device_add+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? add_device_randomness+0xb7/0xf0 usb_new_device+0x492/0x870 hub_event+0x1b10/0x29c0 ? __pfx_hub_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x187/0x300 ? process_one_work+0x475/0xb90 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_hub_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>CVE-2026-64453
  2. In the Linux kernel, the following vulnerability has been resolved: tracing: Fix NULL pointer dereference in func_set_flag() func_set_flag() dereferences tr->current_trace_flags before verifying that the current tracer is actually the function tracer. When the active tracer has been switched away from "function" (e.g., to "wakeup_rt"), tr->current_trace_flags can be NULL, leading to a NULL pointer dereference and kernel crash. The call chain that triggers this is: trace_options_write() -> __set_tracer_option() -> trace->set_flag() /* func_set_flag */ In func_set_flag(), the first operation is: if (!!set == !!(tr->current_trace_flags->val & bit)) This dereferences tr->current_trace_flags unconditionally. The safety check that guards against a non-function tracer: if (tr->current_trace != &function_trace) return 0; is placed *after* the dereference, which is too late. This was observed with the following crash dump: BUG: unable to handle page fault at 0000000000000000 RIP: func_set_flag+0xd Call Trace: __set_tracer_option+0x27 trace_options_write+0x75 vfs_write+0x12a ksys_write+0x66 do_syscall_64+0x5b RIP: ffffffff914c973d RSP: ff67ec88b01dfdf0 RFLAGS: 00010202 RAX: 0000000000000000 RBX: ff3a826e80354580 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff93918080 The disassembly confirms the fault: func_set_flag+0: mov 0x1f08(%rdi), %rax ; RAX = tr->current_trace_flags = NULL func_set_flag+13: mov (%rax), %eax ; page fault: dereference NULL At the time of the crash: tr->current_trace_flags = 0x0 (NULL) tr->current_trace = wakeup_rt_tracer (not function_trace) The scenario is that a process opens a function tracer option file (such as "func_stack_trace"), then the current tracer is switched to another tracer (e.g., "wakeup_rt"), which sets current_trace_flags to NULL. When the process subsequently writes to the option file, func_set_flag() is invoked and crashes on the NULL dereference. Fix this by moving the current_trace check before the current_trace_flags dereference, so that func_set_flag() returns early when the function tracer is not active.CVE-2026-64451
  3. In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it ("if (glen > dlen) break;"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: this_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: "if (glen > dlen) break;" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means "legacy peer without Selective ACK", a distinct legitimate state.CVE-2026-64450