Cloudanix VulnDB

CVE-2026-98229

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel's network security code can let a local user crash the system or gain higher privileges when handling encrypted network traffic.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in xfrm_input() allows dereference of a freed xfrm_state after secpath_reset() drops the final reference during concurrent deletion on VTI/XFRM interface receive paths or XFRM_MAX_DEPTH error handling.

Why it matters to the business

Linux systems processing IPsec traffic face elevated risk of kernel crashes or local privilege escalation, potentially disrupting network services and requiring urgent patching on affected kernels.

How an attack unfolds

An attacker with local access crafts IPsec packets that trigger receive-side processing in xfrm_input(); concurrent state deletion and secpath reset on VTI or XFRM paths allow use of the now-freed state object when selecting transport_finish or reporting drop protocol.

How to fix it

Upgrade to a Linux kernel containing the fix that saves input state protocol and address family on the stack before any secpath_reset; rebuild and reboot with the patched kernel image.

How to confirm the fix worked

Confirm the kernel source contains the stack-saved state protocol logic and absence of post-reset dereferences in xfrm_input; test by exercising VTI and XFRM interface paths with concurrent state deletion.

Typical attack path

  1. Obtain local access or execute code on a Linux host with IPsec/XFRM enabled
  2. Send or inject packets that exercise VTI/XFRM receive paths or hit XFRM_MAX_DEPTH limits
  3. Trigger concurrent xfrm_state deletion while xfrm_input holds a reference that gets reset
  4. Dereference the freed state to cause crash or achieve memory corruption for escalation

How to detect it

Review kernel logs for oops/panic traces referencing xfrm_input, secpath, or xfrm_state after IPsec packet processing; inspect for concurrent state deletion events on VTI or XFRM devices.

What your security team should do

  • Prioritize kernel updates on all systems using IPsec, VTI, or XFRM interfaces
  • Monitor for local privilege-escalation attempts on hosts with network namespaces or IPsec
  • Apply defense-in-depth by restricting local access and reviewing IPsec configurations

The record

In the Linux kernel, the following vulnerability has been resolved: xfrm: save input state data before secpath resets xfrm_input() stores the current xfrm_state in the skb secpath while it continues receive-side processing. Some input paths can reset that secpath before xfrm_input() has finished dereferencing the state. Receive callback users such as VTI and XFRM interfaces can reset the secpath. The VTI receive path does so before checking whether the packet crosses network namespaces, while the XFRM interface path does so only for cross-network-namespace packets. The XFRM_MAX_DEPTH error path can also reset the secpath before the final drop callback reports the current state's protocol. If secpath_reset() drops the last state reference while the state is concurrently deleted, xfrm_input() can still dereference the freed state when selecting transport_finish() or reporting the drop callback protocol. Save the state protocol on the stack while the state is still valid, and use the already saved address family for transport_finish(). A larval XFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This preserves the existing drop-path fallback while avoiding the post-reset state dereferences without adding an extra state reference to every received packet.

Affected packages

Ecosystem Package Introduced Fixed