CVE-2026-74624: netfilter: nf_conntrack: defer invalid log until after unlock
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfconntrack: defer invalid log until after unlock
TCP and SCTP conntrack paths can emit invalid-packet logs while ct->lock is still held.
When invalid logging is routed to nfnetlinklog and conntrack export is enabled, the log path can re-enter conntrack netlink glue and dump the same conntrack again. Protocol attribute dumping may take ct->lock, so logging while holding that lock can deadlock.
Defer the TCP invalid logs by storing only the minimal log context while ct->lock is held and emitting the log after unlocking. Also make the TCP timeout-lowering invalid path return whether a log is needed, then emit that log after unlocking.
Do the same for the SCTP invalid state-transition log that can be reached while ct->lock is held.
Add a lockdep assertion to nfctl4protologinvalid() so future callers that log invalid conntracks while holding ct->lock are caught outside TCP and SCTP as well.
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 - Configuration
Implement the resolved behavior: ensure nf_conntrack defers invalid-packet logging until after unlocking ct->lock, so TCP and SCTP conntrack paths do not emit nfnetlink_log/conntrack export logs while ct->lock is held (e.g., by using a timeout-lowering invalid-path check that returns whether a log is needed, and then emitting the log only after ct->lock is released).
Linux kernel conntrack (nf_conntrack) invalid log emission timing = defer invalid-packet logging until after ct->lock is released - Configuration
Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers follow the rule that invalid logging must not occur while ct->lock is held.
Linux kernel conntrack lockdep assertion in nf_ct_l4proto_log_invalid() = add lockdep assertion
Event History
Frequently Asked Questions
Which systems are exposed to the deadlock condition?
Systems using Linux kernel conntrack for TCP or SCTP are exposed when invalid-packet logging is routed to nfnetlink_log and conntrack export is enabled. The problematic paths occur when invalid TCP or SCTP traffic causes logging while the conntrack lock is held.
What must occur for an attacker or traffic source to trigger the issue?
A source must send traffic that reaches an invalid TCP or SCTP conntrack path and causes an invalid-packet log. The deadlock scenario additionally depends on invalid logging using nfnetlink_log together with conntrack export, allowing the logging path to re-enter conntrack netlink handling.
What can be done if the kernel update cannot be applied immediately?
Avoid the triggering logging configuration: do not route invalid conntrack logs to nfnetlink_log while conntrack export is enabled. Reducing or disabling invalid-packet logging for the affected TCP and SCTP conntrack paths also prevents the described log re-entry condition.
How can administrators determine whether their configuration is at risk?
Review conntrack logging configuration to determine whether invalid-packet logs are sent through nfnetlink_log, and check whether conntrack export is enabled. Systems with both settings enabled should also determine whether TCP or SCTP invalid-packet logging is active.