CVE-2026-99139
NoneCVSS
—
EPSS
0.2%
Published
Oct 28, 2026
CISA due date
—
Cloudanix analysis
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
- Load a BPF program implementing tcp_congestion_ops
- Attach it to a TCP socket via setsockopt(TCP_CONGESTION)
- Race concurrent getsockopt(TCP_CONGESTION) calls that read the name field without RCU protection
- Trigger deallocation of the BPF struct_ops object while the read is still in progress
- 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 |
|---|