CVE-2026-99283

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets<br /> <br /> Commit be0502a3f2e9 ("netfilter: conntrack: tcp: only close if RST<br /> matches exact sequence") keeps an established conntrack entry in<br /> ESTABLISHED when an in-window RST does not match the expected sequence<br /> number exactly, so the endpoint can validate the RST with a challenge<br /> ACK.<br /> <br /> The timeout selection nevertheless uses the CLOSE timeout for every RST<br /> packet. The bug is that timeout selection is based on the packet type,<br /> not on the state transition result: even when RST validation keeps<br /> new_state in ESTABLISHED, the timeout is still forced to<br /> TCP_CONNTRACK_CLOSE.<br /> <br /> Linux TCP independently rate limits challenge ACKs per socket. A second<br /> non-exact RST can therefore arrive after the first challenge ACK has<br /> restored the timeout but before the rate limit expires. The second RST<br /> lowers the timeout to 10 seconds again while the endpoint suppresses the<br /> second challenge ACK, allowing the conntrack entry to expire while both<br /> TCP endpoints remain established.<br /> <br /> Using the ESTABLISHED timeout for such RSTs would avoid this short<br /> expiration window, but it could also retain stale entries for the<br /> five-day default because conntrack cannot reliably match the endpoint&amp;#39;s<br /> exact TCP state.<br /> <br /> Use the UNACK timeout for RST packets that leave the conntrack entry in<br /> TCP_CONNTRACK_ESTABLISHED. Exact-match RSTs and accepted RST packet<br /> trains still fall through to timeouts[new_state], which preserves the<br /> CLOSE timeout when conntrack accepts the RST as closing the flow.<br /> <br /> This avoids the aggressive 10-second expiration window for non-exact<br /> RSTs while preserving the short timeout for RSTs that conntrack accepts<br /> as closing the flow.