CVE-2026-74696: tcp: fix TFO max_qlen accounting across reuseport migration
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix TFO maxqlen accounting across reuseport migration
A listener's TCPFASTOPEN maxqlen stops being accurate and lets through far more pending Fast Open requests than it was configured for.
This only shows up with SOREUSEPORT listener migration, where closing a listener hands its still-pending TFO children over to a surviving one.
fastopenq.qlen is charged in tcpfastopencreatechild() when the child is created and uncharged in reqskfastopenremove() when the handshake completes. The uncharge follows rsklistener of the request the child points at, and inetreqskclone() has repointed the child at a new request owned by the new listener, so the ++ and the -- land on two different sockets. The new listener's qlen drifts negative and its limit no longer binds.
Charge the new listener during migration, like reqskqueuemigrated() already does for queue->young and queue->qlen.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
The issue requires TCP Fast Open listeners using SO_REUSEPORT listener migration. It occurs when a listener closes and its pending Fast Open children are migrated to a surviving listener.
What is the practical impact of successful exploitation?
The surviving listener's TCP_FASTOPEN max_qlen accounting can drift negative after migration. As a result, it can accept substantially more pending Fast Open requests than its configured limit.
What conditions are needed to trigger the accounting failure?
Pending TCP Fast Open child requests must exist when a SO_REUSEPORT listener is closed and migrated. The mismatch occurs because the request is repointed to the new listener before the original charge is later removed.
Is a listener without TCP Fast Open or SO_REUSEPORT migration affected?
The described condition is specific to TCP Fast Open queue accounting during SO_REUSEPORT listener migration. The provided information does not indicate impact for listeners that do not use those features.