UBUNTU-CVE-2026-99139: Use After Free
In the Linux kernel, the following vulnerability has been resolved: tcp: fix use-after-free in dotcpgetsockopt(TCPCONGESTION) dotcpgetsockopt() reads icsk->icskcaops->name without holding rcureadlock(). Since commit 0baf26b0fcd7 ("bpf: tcp: Support tcpcongestionops in bpf"), icskcaops can point to dynamically allocated BPF structops memory that may be freed concurrently via setsockopt(TCPCONGESTION), leading to a use-after-free. BUG: KASAN: slab-use-after-free in copytouser+0x37/0x60 Read of size 16 at addr ffff888013505260 by task exploit/149 copytouser+0x37/0x60 dotcpgetsockopt+0x158a/0x2460 (net/ipv4/tcp.c:4585) tcpgetsockopt+0x91/0xf0 sysgetsockopt+0xf7/0x170 Fix this by holding rcureadlock() around the caops->name access, using READONCE() to load icskcaops, and copying the name to a stack buffer before releasing the lock. Also annotate the relevant icskcaops stores with WRITEONCE() to fix the accompanying KCSAN data-race issue.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In do_tcp_getsockopt(TCP_CONGESTION), hold rcu_read_lock() around the ca_ops->name access, use READ_ONCE() to load icsk_ca_ops, and copy the name to a stack buffer before releasing the lock.
- Compensating control
Annotate the relevant icsk_ca_ops stores with WRITE_ONCE() to address the accompanying KCSAN data race.
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
The vulnerable path is reached when TCP_CONGESTION is queried through getsockopt while the socket's congestion-control operations can be changed concurrently through setsockopt(TCP_CONGESTION). The race specifically involves dynamically allocated BPF struct_ops-backed TCP congestion-control operations being freed during the query.
Are systems using only built-in TCP congestion-control algorithms exposed to the described race?
The description identifies dynamically allocated BPF struct_ops memory as the object that can be freed concurrently. It does not state that built-in, non-BPF congestion-control algorithms are affected by this use-after-free scenario.
How can administrators recognize the issue on an affected system?
A successful trigger may produce a KASAN slab-use-after-free report in _copy_to_user, with do_tcp_getsockopt and tcp_getsockopt in the call trace. The reported access is a read of the congestion-control name while servicing TCP_CONGESTION.
What does the fix change?
The fix protects access to the congestion-control operation name with rcu_read_lock, reads the icsk_ca_ops pointer with READ_ONCE, and copies the name into a stack buffer before dropping the lock. It also adds WRITE_ONCE annotations to relevant pointer stores to address an associated KCSAN data-race report.