CVE-2026-98384
bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destroy()
No known exploitation. EPSS puts it in the 4th percentile. Fixed versions are out.
What to do
Find your product and version, then upgrade to the build on the right.
- LinuxAffected: ≥ 4ddbcb886268af8d12a23e6640b39d1d9c652b1b, < 5b4eb82475ae17d55974235c09e97044829426a8Upgrade to: 5b4eb82475ae17d55974235c09e97044829426a8Affected: ≥ 4ddbcb886268af8d12a23e6640b39d1d9c652b1b, < a9651704c6fd64590b5ad4fbe7c3768accf95993Upgrade to: a9651704c6fd64590b5ad4fbe7c3768accf95993Affected: ≥ 4ddbcb886268af8d12a23e6640b39d1d9c652b1b, < 91a482a81eabddebf5430cbbdf12027e1a91b767Upgrade to: 91a482a81eabddebf5430cbbdf12027e1a91b767Affected: ≥ 4ddbcb886268af8d12a23e6640b39d1d9c652b1b, < 2534a5e5d360c2b10203cfa80f4ab9d021e48f2fUpgrade to: 2534a5e5d360c2b10203cfa80f4ab9d021e48f2f + 1 more branchStated by: CVE record
Versions as the sources state them. Full version matrix after sign-in
What it is
From the CVE record
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destroy() sk_protocol lives in struct sock, not in struct sock_common. A timewait or request sock handed to bpf_sock_destroy() by the tcp iterator is neither, so reading sk->sk_protocol runs past the object: ================================================================== BUG: KASAN: slab-out-of-bounds in bpf_sock_destroy+0xc7/0xe0 Read of size 2 at addr ffff8881047d11b4 by task test_progs/428 Tainted: [W]=WARN Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 print_report+0xd1/0x630 kasan_report+0xf3/0x130 __asan_report_load2_noabort+0x14/0x30 bpf_sock_destroy+0xc7/0xe0 bpf_prog_c3dd61f9d9cd9f37_iter_tcp6_timewait+0x9f/0xb7 bpf_iter_run_prog+0x538/0xde0 bpf_iter_tcp_seq_show+0x26b/0x4b0 bpf_seq_read+0x424/0x1210 vfs_read+0x197/0xe40 ksys_read+0x119/0x240 __x64_sys_read+0x72/0xc0 x64_sys_call+0x647/0x27e0 do_syscall_64+0xe5/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Only check sk_protocol on full socks. tcp_abort() already knows how to deal with TIME_WAIT and NEW_SYN_RECV socks. Also fix the comment, it never matched the code.
In plain language
No plain-language summary for this CVE yet.
Exploitation
Where each signal puts this CVE on the scale from published to confirmed exploited.
- CISA KEV
Not in the catalog. CISA has not confirmed exploitation.
- Public exploits
No public exploit or proof of concept found in the sources we track.
- EPSS
0.2% chance of exploitation activity in the next 30 days, which ranks it in the 4th percentile of scored CVEs.
Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.
Lifecycle
2 events over 0 days, from the signal feeds we watch.
- Publishedrecord updated
Affected products
Sources
References in the record
- git.kernel.org/stable/c/01b245ba016d44861690594e10f67e026ce8552f
- git.kernel.org/stable/c/2534a5e5d360c2b10203cfa80f4ab9d021e48f2f
- git.kernel.org/stable/c/5b4eb82475ae17d55974235c09e97044829426a8
And 2 more references. See all after sign-in
In the news
Watch the software you run.
My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.
We'll flag the next CVE, public exploit or patch for Linux, not every advisory.
A free account adds
- The full version matrix and every affected product
- Exploit links, proofs of concept and Metasploit modules
- Email alerts for the products you watch
- The same data over REST API, MCP and CLI