CRITICAL Introduced in 2.6.25
xfrm6 SecPath OOB
CVE-2026-89783
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
KernelScan AI9.8CRITICAL
01Description
In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use "sp->len >= XFRM_MAX_DEPTH", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'
02KernelScan AI Analysis
Risk summary
A remote attacker can send a crafted IPv6 packet to a host with IPsec configured, triggering an out-of-bounds write in the XFRM secpath handling code. The write corrupts adjacent fields in the sec_path structure, potentially leading to kernel memory corruption, privilege escalation, or a system crash. Any device terminating IPv6 IPsec tunnels and processing Mobile IPv6 extension headers is at risk.
Vulnerability analysis
An off-by-one error in the IPv6 IPsec input path allows a write one element past the end of the array that tracks security associations when the array is already full. This occurs when a packet that has passed through the maximum number of nested IPsec transformations is processed again by IPv6 input and contains certain Mobile IPv6 extension headers; the bounds check fails to catch the already-full array, and the code writes past the array boundary. The fix corrects the bounds check to reject any array that is at or beyond maximum depth, matching the check used elsewhere in the IPsec input path. The vulnerable code is reachable from the network by any remote attacker sending IPv6 packets to a host that has IPsec configured with sufficient nested security associations to fill the tracking array; no local access or privileges are required on the attacker's side.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.15 | 2.6.25 | 5.15.221 | 68e8737fe8e7 |
| 6.6 | 2.6.25 | 6.6.157 | bdcda866c89f |
| 6.12 | 2.6.25 | 6.12.110 | 48996649222e |
| 6.18 | 2.6.25 | 6.18.52 | 0f679e0523dd |
| 7.2 | 2.6.25 | 7.2.6 | 5f35a29a5eed |
| mainline | 2.6.25 | 7.3-rc1 | 5d9e3bf34fec |
| 6.1 | 2.6.25 | 6.1.188 | 8fe2c53fb81f |
| 5.10 | 2.6.25 | 5.10.270 | 91fc387f63c0 |