Description
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]'
Published: 2026-09-16
Score: 9.8 Critical
EPSS: < 1% Very Low
KEV: No
Impact: Kernel Buffer Overflow
Action: Update Kernel
AI Analysis

Impact

The vulnerability is an off‑by‑one depth check in the IPv6 IPsec processing path, which allows an array to be written past its bounds. The write occurs when a full security path is re‑entered with a packet that includes destination options or a type‑2 routing header, causing the kernel to pause and panic. This can lead to a kernel crash and, potentially, arbitrary code execution if the corrupted data can be leveraged.

Affected Systems

All Linux kernel releases that contain the vulnerable xfrm6_input_addr implementation before the fix commit are affected. The patch is present in recent kernel versions that include commit hash 0f679e0523ddfff3fb554336ceb874b0e51e9cd3. Administrators should review their kernel version labels to ensure they are on the post‑fix revision.

Risk and Exploitability

The CVSS score is not provided and EPSS is unavailable, but the flaw can be triggered by an externally supplied IPv6 packet with specific extension headers, so a remote network attacker can exploit it. The vulnerability is not listed in CISA KEV, yet the possibility of a kernel panic leads to denial of service, and the out‑of‑bounds write could in theory facilitate privilege escalation or arbitrary code execution. Immediate patching is recommended.

Generated by OpenCVE AI on September 16, 2026 at 14:24 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a Linux kernel version that includes the commit correcting the off‑by‑one depth check (see commit 0f679e0523ddfff3fb554336ceb874b0e51e9cd3).
  • Until a kernel update is available, block or filter IPv6 packets that carry destination options HAO or type‑2 routing headers using firewall rules to prevent the vulnerable code path from executing.
  • Monitor system logs for UBSAN "array-index-out-of-bounds" messages or kernel panic traces to detect any successful exploitation attempts.

Generated by OpenCVE AI on September 16, 2026 at 14:24 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 16 Sep 2026 14:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-787
Metrics cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}


Wed, 16 Sep 2026 09:00:00 +0000

Type Values Removed Values Added
Description 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]'
Title xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-16T14:38:34.989Z

Reserved: 2026-09-11T19:38:34.765Z

Link: CVE-2026-89783

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T09:17:08.930

Modified: 2026-09-16T15:18:08.720

Link: CVE-2026-89783

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-16T15:15:14Z

Weaknesses