CVE-2015-3332

What it actually does

A backported TCP Fast Open implementation in affected Linux kernels fails to properly maintain an internal count value, allowing a local process to trigger a kernel panic and crash the system when the Fast Open feature is exercised.

Why it matters to the business

Unexpected system crashes on servers or workstations disrupt operations, cause data loss for in-memory workloads, and require manual reboots or recovery procedures until kernels are updated.

How an attack unfolds

An attacker with local shell access on a vulnerable kernel enables or triggers TCP Fast Open (for example by visiting chrome://flags/#enable-tcp-fast-open in a Chromium-based browser) and sends crafted network traffic that exercises the faulty count logic, resulting in an immediate kernel panic.

How to fix it

Upgrade to a kernel version that contains the corrected TCP Fast Open count handling (3.18 or later mainline, or the corresponding stable/longterm backport that addresses the count maintenance issue). Reboot after installing the new kernel package.

How to confirm the fix worked

Verify the running kernel version is 3.18 or newer; confirm that sysctl net.ipv4.tcp_fastopen and net.ipv6.tcp_fastopen settings can be enabled without causing an immediate oops or panic under load.

Typical attack path

1. Obtain local user access on a host running an affected 3.10.x-3.16.x kernel build
2. Enable TCP Fast Open via sysctl or application settings
3. Trigger the feature with network activity that hits the mishandled count path
4. Observe kernel panic and system reboot or hang

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for oops or panic messages referencing tcp_fastopen, tcp_fast_open, or the count variable handling around the time of unexpected reboots; correlate with any local user sessions that enabled the feature.

• kernel: TCP Fast Open
• BUG: unable to handle kernel NULL pointer dereference.*tcp_fastopen
• general protection fault.*tcp_fast_open
• sysctl net.ipv4.tcp_fastopen

What your security team should do

• Identify all hosts still running 3.10.x through 3.16.x kernels and schedule immediate upgrades
• Disable TCP Fast Open (net.ipv4.tcp_fastopen=0) on unpatched systems until kernels are updated
• Monitor kernel logs for tcp_fastopen-related panics as an early indicator of exposure