{"api_version":"1","generated_at":"2026-11-12T01:43:17+00:00","cve":"CVE-2026-99283","urls":{"html":"https://cve.report/CVE-2026-99283","api":"https://cve.report/api/cve/CVE-2026-99283.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-99283","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-99283"},"summary":{"title":"netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets\n\nCommit be0502a3f2e9 (\"netfilter: conntrack: tcp: only close if RST\nmatches exact sequence\") keeps an established conntrack entry in\nESTABLISHED when an in-window RST does not match the expected sequence\nnumber exactly, so the endpoint can validate the RST with a challenge\nACK.\n\nThe timeout selection nevertheless uses the CLOSE timeout for every RST\npacket.  The bug is that timeout selection is based on the packet type,\nnot on the state transition result: even when RST validation keeps\nnew_state in ESTABLISHED, the timeout is still forced to\nTCP_CONNTRACK_CLOSE.\n\nLinux TCP independently rate limits challenge ACKs per socket.  A second\nnon-exact RST can therefore arrive after the first challenge ACK has\nrestored the timeout but before the rate limit expires.  The second RST\nlowers the timeout to 10 seconds again while the endpoint suppresses the\nsecond challenge ACK, allowing the conntrack entry to expire while both\nTCP endpoints remain established.\n\nUsing the ESTABLISHED timeout for such RSTs would avoid this short\nexpiration window, but it could also retain stale entries for the\nfive-day default because conntrack cannot reliably match the endpoint's\nexact TCP state.\n\nUse the UNACK timeout for RST packets that leave the conntrack entry in\nTCP_CONNTRACK_ESTABLISHED.  Exact-match RSTs and accepted RST packet\ntrains still fall through to timeouts[new_state], which preserves the\nCLOSE timeout when conntrack accepts the RST as closing the flow.\n\nThis avoids the aggressive 10-second expiration window for non-exact\nRSTs while preserving the short timeout for RSTs that conntrack accepts\nas closing the flow.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-11-07 21:17:00","updated_at":"2026-11-10 19:22:31"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/bf80e6802273a900311b44e47c9b1a59c6d2473c","name":"https://git.kernel.org/stable/c/bf80e6802273a900311b44e47c9b1a59c6d2473c","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/4d39a039d0b7737f8475c2431f18572b3b186a3b","name":"https://git.kernel.org/stable/c/4d39a039d0b7737f8475c2431f18572b3b186a3b","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/0c6d33329960b2d884a399196c8403643d8a9de6","name":"https://git.kernel.org/stable/c/0c6d33329960b2d884a399196c8403643d8a9de6","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-99283","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99283","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 4d39a039d0b7737f8475c2431f18572b3b186a3b git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 0c6d33329960b2d884a399196c8403643d8a9de6 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 bf80e6802273a900311b44e47c9b1a59c6d2473c git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.12.117 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.18.61 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.117 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.61 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"99283","cve":"CVE-2026-99283","epss":"0.001940000","percentile":"0.091390000","score_date":"2026-11-10","updated_at":"2026-11-11 00:08:19"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["net/netfilter/nf_conntrack_proto_tcp.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"4d39a039d0b7737f8475c2431f18572b3b186a3b","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"0c6d33329960b2d884a399196c8403643d8a9de6","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"bf80e6802273a900311b44e47c9b1a59c6d2473c","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"6.12.117","status":"affected","version":"0","versionType":"semver"},{"lessThan":"6.18.61","status":"affected","version":"0","versionType":"semver"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["net/netfilter/nf_conntrack_proto_tcp.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.117","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.61","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.117","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.61","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets\n\nCommit be0502a3f2e9 (\"netfilter: conntrack: tcp: only close if RST\nmatches exact sequence\") keeps an established conntrack entry in\nESTABLISHED when an in-window RST does not match the expected sequence\nnumber exactly, so the endpoint can validate the RST with a challenge\nACK.\n\nThe timeout selection nevertheless uses the CLOSE timeout for every RST\npacket.  The bug is that timeout selection is based on the packet type,\nnot on the state transition result: even when RST validation keeps\nnew_state in ESTABLISHED, the timeout is still forced to\nTCP_CONNTRACK_CLOSE.\n\nLinux TCP independently rate limits challenge ACKs per socket.  A second\nnon-exact RST can therefore arrive after the first challenge ACK has\nrestored the timeout but before the rate limit expires.  The second RST\nlowers the timeout to 10 seconds again while the endpoint suppresses the\nsecond challenge ACK, allowing the conntrack entry to expire while both\nTCP endpoints remain established.\n\nUsing the ESTABLISHED timeout for such RSTs would avoid this short\nexpiration window, but it could also retain stale entries for the\nfive-day default because conntrack cannot reliably match the endpoint's\nexact TCP state.\n\nUse the UNACK timeout for RST packets that leave the conntrack entry in\nTCP_CONNTRACK_ESTABLISHED.  Exact-match RSTs and accepted RST packet\ntrains still fall through to timeouts[new_state], which preserves the\nCLOSE timeout when conntrack accepts the RST as closing the flow.\n\nThis avoids the aggressive 10-second expiration window for non-exact\nRSTs while preserving the short timeout for RSTs that conntrack accepts\nas closing the flow."}],"providerMetadata":{"dateUpdated":"2026-11-10T18:15:30.084Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/4d39a039d0b7737f8475c2431f18572b3b186a3b"},{"url":"https://git.kernel.org/stable/c/0c6d33329960b2d884a399196c8403643d8a9de6"},{"url":"https://git.kernel.org/stable/c/bf80e6802273a900311b44e47c9b1a59c6d2473c"}],"title":"netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-99283","datePublished":"2026-11-07T20:14:11.433Z","dateReserved":"2026-09-25T10:25:14.405Z","dateUpdated":"2026-11-10T18:15:30.084Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-11-07 21:17:00","lastModifiedDate":"2026-11-10 19:22:31","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"99283","Ordinal":"1","Title":"netfilter: conntrack: tcp: use UNACK timeout for non-closing RST","CVE":"CVE-2026-99283","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"99283","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets\n\nCommit be0502a3f2e9 (\"netfilter: conntrack: tcp: only close if RST\nmatches exact sequence\") keeps an established conntrack entry in\nESTABLISHED when an in-window RST does not match the expected sequence\nnumber exactly, so the endpoint can validate the RST with a challenge\nACK.\n\nThe timeout selection nevertheless uses the CLOSE timeout for every RST\npacket.  The bug is that timeout selection is based on the packet type,\nnot on the state transition result: even when RST validation keeps\nnew_state in ESTABLISHED, the timeout is still forced to\nTCP_CONNTRACK_CLOSE.\n\nLinux TCP independently rate limits challenge ACKs per socket.  A second\nnon-exact RST can therefore arrive after the first challenge ACK has\nrestored the timeout but before the rate limit expires.  The second RST\nlowers the timeout to 10 seconds again while the endpoint suppresses the\nsecond challenge ACK, allowing the conntrack entry to expire while both\nTCP endpoints remain established.\n\nUsing the ESTABLISHED timeout for such RSTs would avoid this short\nexpiration window, but it could also retain stale entries for the\nfive-day default because conntrack cannot reliably match the endpoint's\nexact TCP state.\n\nUse the UNACK timeout for RST packets that leave the conntrack entry in\nTCP_CONNTRACK_ESTABLISHED.  Exact-match RSTs and accepted RST packet\ntrains still fall through to timeouts[new_state], which preserves the\nCLOSE timeout when conntrack accepts the RST as closing the flow.\n\nThis avoids the aggressive 10-second expiration window for non-exact\nRSTs while preserving the short timeout for RSTs that conntrack accepts\nas closing the flow.","Type":"Description","Title":"netfilter: conntrack: tcp: use UNACK timeout for non-closing RST"}]}}}