CVE-2026-89783: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-89783 Overview

CVE-2026-89783 is an out-of-bounds write vulnerability in the Linux kernel's IPv6 IPsec (xfrm6) input handling code. The flaw resides in the xfrm6_input_addr() function within net/ipv6/xfrm6_input.c, where an off-by-one depth check allows a write one slot past the end of the fixed-size xvec[] array in the sec_path structure. When the transport-mode receive path re-enters IPv6 input through xfrm_trans_reinject() with a full secpath, processing an inner packet carrying a Home Address Option (HAO) or type-2 routing header triggers the boundary violation.

Critical Impact
A remote attacker can trigger an out-of-bounds write in kernel memory by sending crafted IPv6 IPsec traffic, leading to kernel panic under panic_on_warn and potential memory corruption on unpatched systems.

Affected Products

Linux kernel IPv6 IPsec (xfrm6) subsystem
Multiple stable kernel branches referenced in upstream fix commits
Systems processing IPv6 traffic with IPsec transport mode enabled

Discovery Timeline

2026-09-16 - CVE-2026-89783 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89783

Vulnerability Analysis

The vulnerability is an out-of-bounds write [CWE-787] caused by an off-by-one boundary check in xfrm6_input_addr(). The Linux kernel maintains a sec_path structure with a fixed-size array xvec[XFRM_MAX_DEPTH] that tracks IPsec transformations applied to a packet. The pre-patch depth check reads if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; which fails to reject cases where sp->len is already equal to XFRM_MAX_DEPTH.

The general xfrm_input() path can leave sp->len == XFRM_MAX_DEPTH. When transport-mode processing calls xfrm_trans_reinject(), the preserved secpath is carried into subsequent IPv6 input handling. If the inner packet contains a destination-options HAO or a type-2 routing header, xfrm6_input_addr() executes with a fully populated secpath and writes to sp->xvec[sp->len++], storing a pointer one element beyond the 6-slot array.

The corruption remains inside the containing sec_path allocation, which is why KASAN does not flag it. UBSAN_BOUNDS detects the out-of-range index and emits 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]', which panics kernels running with panic_on_warn.

Root Cause

The root cause is an incorrect boundary predicate. The check 1 + sp->len == XFRM_MAX_DEPTH uses strict equality and does not account for a secpath already at maximum depth entering the function. The fix changes the comparison to sp->len >= XFRM_MAX_DEPTH, matching the guard used in xfrm_input() and restoring one legitimate chain level that the previous check rejected at sp->len == 5.

Attack Vector

The vulnerability is reachable over the network without authentication. An attacker sends IPv6 packets that traverse the IPsec transport-mode receive path in a configuration where the secpath fills to XFRM_MAX_DEPTH, then delivers an inner packet with a destination-options HAO or type-2 routing header to invoke xfrm6_input_addr() with the overfull secpath. The immediate observable outcome is an out-of-bounds pointer write inside the sec_path allocation and a UBSAN report; on kernels configured with panic_on_warn, this results in denial of service through kernel panic.

No verified public proof-of-concept code is available for this CVE. See the upstream fix commits linked under Detection and Mitigation for the exact code changes.

Detection Methods for CVE-2026-89783

Indicators of Compromise

Kernel log messages containing UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c
Kernel panic events referencing xfrm6_input_addr in the call stack
Unexpected reboots on IPsec gateways or hosts terminating IPv6 IPsec transport-mode sessions

Detection Strategies

Correlate kernel dmesg and /var/log/kern.log entries for UBSAN reports pointing to net/ipv6/xfrm6_input.c:309
Inspect IPv6 traffic for uncommon combinations of IPsec transport mode with Mobile IPv6 Home Address Options or type-2 routing headers targeting IPsec endpoints
Track kernel version and patch level across Linux fleets to identify hosts running vulnerable xfrm6 code

Monitoring Recommendations

Forward kernel logs to a centralized logging platform and alert on UBSAN or oops entries referencing xfrm6
Monitor host availability metrics for IPsec-terminating systems to detect panic-induced restarts
Enable audit collection for network stack crashes and correlate with peer IPv6 traffic sources

How to Mitigate CVE-2026-89783

Immediate Actions Required

Apply the upstream stable kernel updates that replace the off-by-one check with sp->len >= XFRM_MAX_DEPTH
Prioritize patching Linux hosts that terminate IPv6 IPsec transport-mode traffic or act as Mobile IPv6 endpoints
Review panic_on_warn policy on production kernels, as this setting converts the UBSAN report into an immediate panic

Patch Information

The fix is distributed across multiple stable branches through the following upstream commits: Kernel Git Commit 0f679e0523d, Kernel Git Commit 48996649222e, Kernel Git Commit 5d9e3bf34fe, Kernel Git Commit 5f35a29a5ee, Kernel Git Commit 68e8737fe8e, Kernel Git Commit 8fe2c53fb81, Kernel Git Commit 91fc387f63c, and Kernel Git Commit bdcda866c89f. Apply the update from your Linux distribution's security channel that corresponds to your running kernel branch.

Workarounds

Disable IPv6 IPsec transport mode where it is not required for operational use
Restrict inbound IPv6 traffic containing Mobile IPv6 destination-options HAO or type-2 routing headers at network perimeter devices
Temporarily set kernel.panic_on_warn=0 to prevent panic while a patch rollout is in progress, understanding this does not eliminate the underlying memory corruption

bash

# Verify current panic_on_warn setting and running kernel version
sysctl kernel.panic_on_warn
uname -r

# Check for UBSAN reports referencing xfrm6 in kernel logs
dmesg | grep -i 'xfrm6_input\|UBSAN'