CVE-2025-38165 in Linux
Summary
by MITRE • 07/03/2025
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix panic when calling skb_linearize
The panic can be reproduced by executing the command: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000
Then a kernel panic was captured: ''' [ 657.460555] kernel BUG at net/core/skbuff.c:2178!
[ 657.462680] Tainted: [W]=WARN
[ 657.463287] Workqueue: events sk_psock_backlog
... [ 657.469610] <TASK>
[ 657.469738] ? die+0x36/0x90
[ 657.469916] ? do_trap+0x1d0/0x270
[ 657.470118] ? pskb_expand_head+0x612/0xf40
[ 657.470376] ? pskb_expand_head+0x612/0xf40
[ 657.470620] ? do_error_trap+0xa3/0x170
[ 657.470846] ? pskb_expand_head+0x612/0xf40
[ 657.471092] ? handle_invalid_op+0x2c/0x40
[ 657.471335] ? pskb_expand_head+0x612/0xf40
[ 657.471579] ? exc_invalid_op+0x2d/0x40
[ 657.471805] ? asm_exc_invalid_op+0x1a/0x20
[ 657.472052] ? pskb_expand_head+0xd1/0xf40
[ 657.472292] ? pskb_expand_head+0x612/0xf40
[ 657.472540] ? lock_acquire+0x18f/0x4e0
[ 657.472766] ? find_held_lock+0x2d/0x110
[ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10
[ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470
[ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10
[ 657.473826] __pskb_pull_tail+0xfd/0x1d20
[ 657.474062] ? __kasan_slab_alloc+0x4e/0x90
[ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510
[ 657.475392] ? __kasan_kmalloc+0xaa/0xb0
[ 657.476010] sk_psock_backlog+0x5cf/0xd70
[ 657.476637] process_one_work+0x858/0x1a20
'''
The panic originates from the assertion BUG_ON(skb_shared(skb)) in skb_linearize(). A previous commit(see Fixes tag) introduced skb_get() to avoid race conditions between skb operations in the backlog and skb release in the recvmsg path. However, this caused the panic to always occur when skb_linearize is executed.
The "--rx-strp 100000" parameter forces the RX path to use the strparser module which aggregates data until it reaches 100KB before calling sockmap logic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.
To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.
''' sk_psock_backlog: sk_psock_handle_skb skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue' sk_psock_skb_ingress____________ ↓ | | → sk_psock_skb_ingress_self | sk_psock_skb_ingress_enqueue sk_psock_verdict_apply_________________↑ skb_linearize '''
Note that for verdict_apply path, the skb_get operation is unnecessary so we add 'take_ref' param to control it's behavior.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 04/18/2026
The vulnerability identified as CVE-2025-38165 resides within the Linux kernel's implementation of Berkeley Packet Filter (BPF) and sockmap functionality, specifically concerning the handling of socket buffer (skb) linearization operations. This flaw manifests as a kernel panic triggered during the execution of a benchmark command designed to stress the sockmap subsystem. The panic occurs when the system attempts to process incoming network packets through the ingress path, particularly when utilizing the strparser module to aggregate data streams. The specific command that reproduces the issue is ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000, which configures the system to process packets with a 100KB payload threshold that exceeds the maximum number of fragments allowed, thereby forcing the kernel to invoke the skb_linearize function.
The technical root cause of this vulnerability lies in an assertion failure within the skb_linearize function located at net/core/skbuff.c:2178, specifically the BUG_ON(skb_shared(skb)) check that triggers when a shared skb is encountered. The issue was introduced by a previous commit that added skb_get() calls to prevent race conditions between backlog processing and skb release operations in the recvmsg path. However, this change inadvertently created a scenario where the skb_get() operation was performed at an inappropriate point in the execution flow, leading to shared skb references that cannot be safely linearized. The kernel stack trace clearly indicates the sequence of function calls leading to the panic, beginning with sk_psock_backlog, proceeding through sk_psock_skb_ingress_enqueue, and ultimately failing in __pskb_pull_tail due to the shared skb state.
This vulnerability directly maps to CWE-121, which describes heap-based buffer overflow conditions, and relates to the broader category of kernel memory management flaws. The operational impact of this vulnerability is significant as it can lead to complete system crashes and denial of service conditions, particularly in environments where BPF and sockmap are heavily utilized for network packet processing and filtering. The attack scenario involves an adversary who can execute the specific benchmark command or manipulate network traffic patterns to trigger the problematic code path. According to ATT&CK framework, this vulnerability could be leveraged through T1499.004 (Endpoint Denial of Service) and potentially T1059.007 (Command and Scripting Interpreter: PowerShell) if an attacker can influence system command execution. The fix implemented addresses this by relocating the skb_get() operation from the sk_psock_backlog function to the sk_psock_skb_ingress_enqueue function, ensuring that the reference counting occurs at the appropriate point in the processing pipeline. Additionally, a new 'take_ref' parameter was introduced to control the behavior of the skb_get() operation in the verdict_apply path where such operations are unnecessary, thereby preventing the panic while maintaining proper reference counting for the affected code paths.