{"api_version":"1","generated_at":"2026-10-23T10:58:22+00:00","cve":"CVE-2026-98229","urls":{"html":"https://cve.report/CVE-2026-98229","api":"https://cve.report/api/cve/CVE-2026-98229.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-98229","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-98229"},"summary":{"title":"xfrm: save input state data before secpath resets","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: save input state data before secpath resets\n\nxfrm_input() stores the current xfrm_state in the skb secpath while it\ncontinues receive-side processing. Some input paths can reset that secpath\nbefore xfrm_input() has finished dereferencing the state.\n\nReceive callback users such as VTI and XFRM interfaces can reset the\nsecpath. The VTI receive path does so before checking whether the packet\ncrosses network namespaces, while the XFRM interface path does so only for\ncross-network-namespace packets. The XFRM_MAX_DEPTH error path can also\nreset the secpath before the final drop callback reports the current\nstate's protocol.\n\nIf secpath_reset() drops the last state reference while the state is\nconcurrently deleted, xfrm_input() can still dereference the freed state\nwhen selecting transport_finish() or reporting the drop callback protocol.\n\nSave the state protocol on the stack while the state is still valid,\nand use the already saved address family for transport_finish(). A larval\nXFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This\npreserves the existing drop-path fallback while avoiding the post-reset\nstate dereferences without adding an extra state reference to every\nreceived packet.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-10-06 09:18:10","updated_at":"2026-10-19 10:18:23"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/3cf5cdecd99c9c186a5ea518d93bbf3045b6e3aa","name":"https://git.kernel.org/stable/c/3cf5cdecd99c9c186a5ea518d93bbf3045b6e3aa","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/35de97850987b3d022ed17df5b2577242e746daf","name":"https://git.kernel.org/stable/c/35de97850987b3d022ed17df5b2577242e746daf","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/148db154066b066616b82c12d373e786eba1f96a","name":"https://git.kernel.org/stable/c/148db154066b066616b82c12d373e786eba1f96a","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/537a5ae18b2be70f8eb0aca843682e81a69aab91","name":"https://git.kernel.org/stable/c/537a5ae18b2be70f8eb0aca843682e81a69aab91","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-98229","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98229","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected df3893c176e9b0bb39b28ab5ec8113fa20ad1ee0 35de97850987b3d022ed17df5b2577242e746daf git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected df3893c176e9b0bb39b28ab5ec8113fa20ad1ee0 148db154066b066616b82c12d373e786eba1f96a git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected df3893c176e9b0bb39b28ab5ec8113fa20ad1ee0 537a5ae18b2be70f8eb0aca843682e81a69aab91 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected df3893c176e9b0bb39b28ab5ec8113fa20ad1ee0 3cf5cdecd99c9c186a5ea518d93bbf3045b6e3aa git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 3.15","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 3.15 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.112 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.54 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.8 7.2.* 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":"98229","cve":"CVE-2026-98229","epss":"0.002090000","percentile":"0.100660000","score_date":"2026-10-06","updated_at":"2026-10-07 00:14:55"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["net/xfrm/xfrm_input.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"35de97850987b3d022ed17df5b2577242e746daf","status":"affected","version":"df3893c176e9b0bb39b28ab5ec8113fa20ad1ee0","versionType":"git"},{"lessThan":"148db154066b066616b82c12d373e786eba1f96a","status":"affected","version":"df3893c176e9b0bb39b28ab5ec8113fa20ad1ee0","versionType":"git"},{"lessThan":"537a5ae18b2be70f8eb0aca843682e81a69aab91","status":"affected","version":"df3893c176e9b0bb39b28ab5ec8113fa20ad1ee0","versionType":"git"},{"lessThan":"3cf5cdecd99c9c186a5ea518d93bbf3045b6e3aa","status":"affected","version":"df3893c176e9b0bb39b28ab5ec8113fa20ad1ee0","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["net/xfrm/xfrm_input.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"3.15"},{"lessThan":"3.15","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.112","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.54","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.8","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.112","versionStartIncluding":"3.15","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.54","versionStartIncluding":"3.15","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.8","versionStartIncluding":"3.15","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3","versionStartIncluding":"3.15","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: save input state data before secpath resets\n\nxfrm_input() stores the current xfrm_state in the skb secpath while it\ncontinues receive-side processing. Some input paths can reset that secpath\nbefore xfrm_input() has finished dereferencing the state.\n\nReceive callback users such as VTI and XFRM interfaces can reset the\nsecpath. The VTI receive path does so before checking whether the packet\ncrosses network namespaces, while the XFRM interface path does so only for\ncross-network-namespace packets. The XFRM_MAX_DEPTH error path can also\nreset the secpath before the final drop callback reports the current\nstate's protocol.\n\nIf secpath_reset() drops the last state reference while the state is\nconcurrently deleted, xfrm_input() can still dereference the freed state\nwhen selecting transport_finish() or reporting the drop callback protocol.\n\nSave the state protocol on the stack while the state is still valid,\nand use the already saved address family for transport_finish(). A larval\nXFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This\npreserves the existing drop-path fallback while avoiding the post-reset\nstate dereferences without adding an extra state reference to every\nreceived packet."}],"metrics":[{"cvssV3_1":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"scenarios":[{"lang":"en","value":"AV:L - Freeing the state requires deleting the SA while xfrm_input() is still using it; the packet bytes themselves are not malformed. The attacker who can both inject ESP into a VTI/xfrmi device and send XFRM_MSG_DELSA is a local user acting through netlink in their own netns. A remote IPsec peer cannot delete the SA at will.\nAC:L - placeholder\nPR:L - placeholder\nUI:N - placeholder\nS:U - placeholder\nC:H - placeholder\nI:H - placeholder\nA:H - placeholder"}]}],"providerMetadata":{"dateUpdated":"2026-10-19T09:16:01.147Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/35de97850987b3d022ed17df5b2577242e746daf"},{"url":"https://git.kernel.org/stable/c/148db154066b066616b82c12d373e786eba1f96a"},{"url":"https://git.kernel.org/stable/c/537a5ae18b2be70f8eb0aca843682e81a69aab91"},{"url":"https://git.kernel.org/stable/c/3cf5cdecd99c9c186a5ea518d93bbf3045b6e3aa"}],"title":"xfrm: save input state data before secpath resets","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-98229","datePublished":"2026-10-06T08:45:03.904Z","dateReserved":"2026-09-25T10:25:14.328Z","dateUpdated":"2026-10-19T09:16:01.147Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-06 09:18:10","lastModifiedDate":"2026-10-19 10:18:23","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.9}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"98229","Ordinal":"1","Title":"xfrm: save input state data before secpath resets","CVE":"CVE-2026-98229","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"98229","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: save input state data before secpath resets\n\nxfrm_input() stores the current xfrm_state in the skb secpath while it\ncontinues receive-side processing. Some input paths can reset that secpath\nbefore xfrm_input() has finished dereferencing the state.\n\nReceive callback users such as VTI and XFRM interfaces can reset the\nsecpath. The VTI receive path does so before checking whether the packet\ncrosses network namespaces, while the XFRM interface path does so only for\ncross-network-namespace packets. The XFRM_MAX_DEPTH error path can also\nreset the secpath before the final drop callback reports the current\nstate's protocol.\n\nIf secpath_reset() drops the last state reference while the state is\nconcurrently deleted, xfrm_input() can still dereference the freed state\nwhen selecting transport_finish() or reporting the drop callback protocol.\n\nSave the state protocol on the stack while the state is still valid,\nand use the already saved address family for transport_finish(). A larval\nXFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This\npreserves the existing drop-path fallback while avoiding the post-reset\nstate dereferences without adding an extra state reference to every\nreceived packet.","Type":"Description","Title":"xfrm: save input state data before secpath resets"}]}}}