Cloudanix VulnDB

CVE-2026-98384

None

CVSS

—

EPSS

0.2%

Published

Oct 9, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel can let certain network inspection programs read memory they should not, which might crash the system or leak data.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds kernel memory read when bpf_sock_destroy() is invoked on timewait or request sockets supplied by the TCP iterator, because sk_protocol is read from an offset valid only for full struct sock objects.

Why it matters to the business

Kernel crashes or memory disclosure on systems running unpatched Linux kernels that use BPF iterators over TCP sockets, potentially causing service outages or information exposure.

How an attack unfolds

An attacker loads a BPF program using bpf_iter_tcp that reaches bpf_sock_destroy() on a TIME_WAIT or NEW_SYN_RECV socket; the iterator supplies an incompatible sock object, the read of sk_protocol overruns the allocation, and KASAN or a subsequent fault is triggered.

How to fix it

Apply the upstream fix that gates the sk_protocol access behind a check for full sockets only; rebuild and boot the corrected kernel. No specific fixed versions are listed in the advisory.

How to confirm the fix worked

Verify the patch is present by inspecting the bpf_sock_destroy source for the added full-sock check; run the reproducer test_progs against the updated kernel and confirm absence of the KASAN slab-out-of-bounds report.

Typical attack path

  1. Compile and load a BPF iterator program targeting tcp6 or tcp sockets
  2. Trigger iteration over sockets that include TIME_WAIT or request states
  3. bpf_iter_tcp_seq_show calls bpf_sock_destroy on the incompatible object
  4. Out-of-bounds read of sk_protocol occurs inside bpf_sock_destroy
  5. Kernel fault or KASAN report is raised

How to detect it

Search kernel logs and KASAN reports for the strings bpf_sock_destroy and slab-out-of-bounds; examine BPF program load events and tcp iterator usage around the time of any crash.

  • bpf_sock_destroy+0xc7/0xe0
  • BUG: KASAN: slab-out-of-bounds in bpf_sock_destroy
  • bpf_prog_c3dd61f9d9cd9f37_iter_tcp6_timewait
  • bpf_iter_tcp_seq_show+0x26b/0x4b0

What your security team should do

  • Prioritize kernel update on any system exposing BPF iterators to untrusted programs
  • Audit custom BPF code that iterates TCP sockets for similar assumptions about socket types
  • Monitor for KASAN or BUG reports containing bpf_sock_destroy after deployment

The 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.

Affected packages

Ecosystem Package Introduced Fixed