CVE-2025-68188

What it actually does

Use-after-free in tcp_fastopen_active_disable_ofo_check() when accessing dst_dev()->flags without RCU protection, enabling potential kernel memory corruption or crashes.

Why it matters to the business

Unpatched Linux systems face risk of kernel-level crashes or privilege escalation that can disrupt network services, reduce system availability, and expose sensitive workloads across large numbers of servers and containers.

How an attack unfolds

An attacker crafts TCP Fast Open traffic that triggers the vulnerable code path in the kernel's TCP stack; without RCU protection the stale dst_dev pointer can be dereferenced after free, leading to memory corruption that may be leveraged for denial of service or local privilege escalation.

How to fix it

Upgrade the Linux kernel to a version containing commit bc2b881a0896c111c1041d8bb1f92a3b3873ace5 or later; for git-sync-fips update to 4.4.0-r2 or newer; apply vendor kernel packages as soon as available and reboot affected systems.

How to confirm the fix worked

Confirm the running kernel contains commit bc2b881a0896c111c1041d8bb1f92a3b3873ace5 by checking /proc/version or uname output against the fixed commit; run regression tests exercising TCP Fast Open code paths.

Typical attack path

1. Establish a TCP connection using Fast Open to reach the vulnerable function
2. Trigger conditions that cause dst_dev() to return a pointer that is later freed
3. Reuse the freed memory to corrupt kernel structures
4. Escalate privileges or cause kernel panic

How to detect it

Review kernel logs for oops or panic messages referencing tcp_fastopen_active_disable_ofo_check or dst_dev; correlate with network traffic containing TCP Fast Open options; no public exploit artifacts are known.

What your security team should do

• Immediately inventory all Linux kernel versions and prioritize patching of internet-facing or high-value systems
• Apply the fixed commit or equivalent vendor update within standard change windows
• Monitor EPSS trend and any new exploit reports given the 315-day publication window