Cloudanix VulnDB

CVE-2026-99139

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in how the Linux kernel manages network connection settings could let a local attacker crash the computer or potentially take control.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free when do_tcp_getsockopt reads icsk->icsk_ca_ops->name without RCU protection, allowing concurrent free of dynamically allocated BPF struct_ops memory via setsockopt(TCP_CONGESTION).

Why it matters to the business

Kernel memory corruption on systems using BPF-based TCP congestion control can lead to crashes, denial of service, or potential privilege escalation; the issue is public with no known exploitation yet, requiring prompt patching of all affected Linux kernels.

How an attack unfolds

An attacker with local access creates a TCP socket, attaches a BPF TCP congestion control program, then triggers concurrent getsockopt(TCP_CONGESTION) and setsockopt(TCP_CONGESTION) calls so that the name pointer is dereferenced after the underlying BPF memory has been freed.

How to fix it

Upgrade to a Linux kernel containing the fix that adds rcu_read_lock around the ca_ops access, uses READ_ONCE/WRITE_ONCE annotations, and copies the name under the lock before release.

How to confirm the fix worked

Confirm the kernel source contains the RCU locking, READ_ONCE load of icsk_ca_ops, and stack buffer copy in do_tcp_getsockopt; test by exercising concurrent TCP_CONGESTION getsockopt/setsockopt with BPF congestion control programs under KASAN or KCSAN.

Typical attack path

  1. Load a BPF program implementing tcp_congestion_ops
  2. Attach it to a TCP socket via setsockopt(TCP_CONGESTION)
  3. Race concurrent getsockopt(TCP_CONGESTION) calls that read the name field without RCU protection
  4. Trigger deallocation of the BPF struct_ops object while the read is still in progress
  5. Exploit the resulting use-after-free for memory corruption or crash

How to detect it

Look for KASAN reports citing slab-use-after-free during _copy_to_user inside do_tcp_getsockopt or tcp_getsockopt; examine audit logs for frequent TCP_CONGESTION socket option changes from untrusted processes.

What your security team should do

  • Prioritize kernel updates on all systems that load custom BPF TCP congestion control programs
  • Monitor for public exploit code given the one-day publication window
  • Apply the fix before any production use of dynamic TCP congestion ops via BPF

The record

In the Linux kernel, the following vulnerability has been resolved: tcp: fix use-after-free in do_tcp_getsockopt(TCP_CONGESTION) do_tcp_getsockopt() reads icsk->icsk_ca_ops->name without holding rcu_read_lock(). Since commit 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf"), icsk_ca_ops can point to dynamically allocated BPF struct_ops memory that may be freed concurrently via setsockopt(TCP_CONGESTION), leading to a use-after-free. BUG: KASAN: slab-use-after-free in _copy_to_user+0x37/0x60 Read of size 16 at addr ffff888013505260 by task exploit/149 _copy_to_user+0x37/0x60 do_tcp_getsockopt+0x158a/0x2460 (net/ipv4/tcp.c:4585) tcp_getsockopt+0x91/0xf0 __sys_getsockopt+0xf7/0x170 Fix this by holding rcu_read_lock() around the ca_ops->name access, using READ_ONCE() to load icsk_ca_ops, and copying the name to a stack buffer before releasing the lock. Also annotate the relevant icsk_ca_ops stores with WRITE_ONCE() to fix the accompanying KCSAN data-race issue.

Affected packages

Ecosystem Package Introduced Fixed