GHSA-W959-55FC-RV4X
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2025-12-18 21:31In 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] [ 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] ? __pfxlockrelease.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.
{
"affected": [],
"aliases": [
"CVE-2025-38165"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T09:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix panic when calling skb_linearize\n\nThe panic can be reproduced by executing the command:\n./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000\n\nThen a kernel panic was captured:\n\u0027\u0027\u0027\n[ 657.460555] kernel BUG at net/core/skbuff.c:2178!\n[ 657.462680] Tainted: [W]=WARN\n[ 657.463287] Workqueue: events sk_psock_backlog\n...\n[ 657.469610] \u003cTASK\u003e\n[ 657.469738] ? die+0x36/0x90\n[ 657.469916] ? do_trap+0x1d0/0x270\n[ 657.470118] ? pskb_expand_head+0x612/0xf40\n[ 657.470376] ? pskb_expand_head+0x612/0xf40\n[ 657.470620] ? do_error_trap+0xa3/0x170\n[ 657.470846] ? pskb_expand_head+0x612/0xf40\n[ 657.471092] ? handle_invalid_op+0x2c/0x40\n[ 657.471335] ? pskb_expand_head+0x612/0xf40\n[ 657.471579] ? exc_invalid_op+0x2d/0x40\n[ 657.471805] ? asm_exc_invalid_op+0x1a/0x20\n[ 657.472052] ? pskb_expand_head+0xd1/0xf40\n[ 657.472292] ? pskb_expand_head+0x612/0xf40\n[ 657.472540] ? lock_acquire+0x18f/0x4e0\n[ 657.472766] ? find_held_lock+0x2d/0x110\n[ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10\n[ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470\n[ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10\n[ 657.473826] __pskb_pull_tail+0xfd/0x1d20\n[ 657.474062] ? __kasan_slab_alloc+0x4e/0x90\n[ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510\n[ 657.475392] ? __kasan_kmalloc+0xaa/0xb0\n[ 657.476010] sk_psock_backlog+0x5cf/0xd70\n[ 657.476637] process_one_work+0x858/0x1a20\n\u0027\u0027\u0027\n\nThe panic originates from the assertion BUG_ON(skb_shared(skb)) in\nskb_linearize(). A previous commit(see Fixes tag) introduced skb_get()\nto avoid race conditions between skb operations in the backlog and skb\nrelease in the recvmsg path. However, this caused the panic to always\noccur when skb_linearize is executed.\n\nThe \"--rx-strp 100000\" parameter forces the RX path to use the strparser\nmodule which aggregates data until it reaches 100KB before calling sockmap\nlogic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.\n\nTo fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.\n\n\u0027\u0027\u0027\nsk_psock_backlog:\n sk_psock_handle_skb\n skb_get(skb) \u003c== we move it into \u0027sk_psock_skb_ingress_enqueue\u0027\n sk_psock_skb_ingress____________\n \u2193\n |\n | \u2192 sk_psock_skb_ingress_self\n | sk_psock_skb_ingress_enqueue\nsk_psock_verdict_apply_________________\u2191 skb_linearize\n\u0027\u0027\u0027\n\nNote that for verdict_apply path, the skb_get operation is unnecessary so\nwe add \u0027take_ref\u0027 param to control it\u0027s behavior.",
"id": "GHSA-w959-55fc-rv4x",
"modified": "2025-12-18T21:31:33Z",
"published": "2025-07-03T09:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38165"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d25fa2d7f127348c818e1dab9e58534f7ac56cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4dba44333a11522df54b49aa1f2edfaf6ce35fc7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ca2e29f6834c64c0e5a9ccf1278c21fb49b827e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9718ba6490732dbe70190d42c21deb1440834402"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db1d15a26f21f97459508c42ae87cabe8d3afc3b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e9c1299d813fc04668042690f2c3cc76d013959a"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.