CVE-2026-99283 · Other
NO FIX YET
The Linux kernel's netfilter connection tracker sets a 10-second close timeout for some reset packets that the endpoints still consider established, so the tracking entry can expire while both ends of the TCP connection remain open. The sources describe this as a stateful firewall or NAT dropping a live connection's state, not as code execution or data theft.
first public Nov 7, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Systems running the Linux kernel with netfilter connection tracking, such as firewalls, NAT gateways and hosts with stateful iptables or nftables rules, may drop established TCP connections early after receiving a non-exact RST. The sources do not say which kernel versions are affected or which configurations are required, so teams should check their kernel series against the upstream fix commit.
Not affected if no-conntrack, stateless-firewall
Who cares firewall, linux-kernel, nat, netfilter
uname -r and compare it against the fixed kernel release in the kernel stable branch for your series; the sources do not name a fixed version.lsmod | grep nf_conntrack or by reviewing iptables/nftables rules that use state or NAT.Unknown from the sources.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets
Commit be0502a3f2e9 ("netfilter: conntrack: tcp: only close if RST matches exact sequence") keeps an established conntrack entry in ESTABLISHED when an in-window RST does not match the expected sequence number exactly, so the endpoint can validate the RST with a challenge ACK.
The timeout selection nevertheless uses the CLOSE timeout for every RST packet. The bug is that timeout selection is based on the packet type, not on the state transition result: even when RST validation keeps new_state in ESTABLISHED, the timeout is still forced to TCP_CONNTRACK_CLOSE.
Linux TCP independently rate limits challenge ACKs per socket. A second non-exact RST can therefore arrive after the first challenge ACK has restored the timeout but before the rate limit expires. The second RST lowers the timeout to 10 seconds again while the endpoint suppresses the second challenge ACK, allowing the conntrack entry to expire while both TCP endpoints remain established.
Using the ESTABLISHED timeout for such RSTs would avoid this short expiration window, but it could also retain stale entries for the five-day default because conntrack cannot reliably match the endpoint's exact TCP state.
Use the UNACK timeout for RST packets that leave the conntrack entry in TCP_CONNTRACK_ESTABLISHED. Exact-match RSTs and accepted RST packet trains still fall through to timeouts[new_state], which preserves the CLOSE timeout when conntrack accepts the RST as closing the flow.
This avoids the aggressive 10-second expiration window for non-exact RSTs while preserving the short timeout for RSTs that conntrack accepts as closing the flow.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.