CVE-2026-99138

What it actually does

Use-after-free when do_tcp_getsockopt reads icsk->icsk_ca_ops and calls its get_info pointer without RCU protection, allowing concurrent free of BPF struct_ops memory.

Why it matters to the business

Attackers can crash the kernel or achieve code execution on affected systems, leading to denial of service or full host compromise; the issue is only one day old with no public exploit yet.

How an attack unfolds

An attacker invokes getsockopt(TCP_CC_INFO) on a TCP socket while a BPF-based congestion-control struct_ops is being unregistered; the kernel dereferences a stale pointer into already-freed memory, triggering the use-after-free.

How to fix it

Apply the upstream fix that wraps the ca_ops load and get_info call inside rcu_read_lock/rcu_read_unlock and uses READ_ONCE; rebuild and reboot to a patched kernel.

How to confirm the fix worked

Confirm the presence of rcu_read_lock around the icsk_ca_ops access and the READ_ONCE load in net/ipv4/tcp.c:do_tcp_getsockopt; re-run KASAN or syzkaller tests that previously triggered the UAF.

Typical attack path

1. Load or register a BPF struct_ops TCP congestion-control program
2. Trigger concurrent removal or replacement of that program
3. Call getsockopt with TCP_CC_INFO option on an affected socket
4. Kernel reads stale icsk_ca_ops pointer and calls get_info through freed memory

How to detect it

Search kernel logs and KASAN reports for slab-use-after-free mentioning do_tcp_getsockopt; inspect audit logs for unusual getsockopt calls on TCP sockets around the time of any crash.

• BUG: KASAN: slab-use-after-free in do_tcp_getsockopt
• Read of size 8 at addr .* by task .* in net/ipv4/tcp.c:4564

What your security team should do

• Prioritize kernel updates on all Linux hosts within the next 7 days
• Restrict unprivileged use of getsockopt(TCP_CC_INFO) via seccomp or LSM where possible
• Monitor for KASAN reports containing do_tcp_getsockopt+0x2037
• Test the patch in staging before broad rollout