CVE-2026-89783: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full
In the Linux kernel, the following vulnerability has been resolved:
xfrm6: fix out-of-bounds write in xfrm6inputaddr() when secpath is full
The depth check in xfrm6inputaddr() is off by one:
if (1 + sp->len == XFRMMAXDEPTH) goto drop; ... sp->xvec[sp->len++] = x;
xfrminput() can leave sp->len == XFRMMAXDEPTH, and the transport-mode receive path re-enters IPv6 input via xfrmtransreinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6inputaddr() is called with sp->len == XFRMMAXDEPTH; 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 secpath allocation (invisible to KASAN); UBSANBOUNDS flags it and panics under paniconwarn.
Use "sp->len >= XFRMMAXDEPTH", matching xfrminput(). This also restores one chain level the old check rejected at sp->len == 5.
UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6input.c:309:10 index 6 is out of range for type 'xfrmstate [6]'
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (net/ipv6/xfrm6_input.c, xfrm6_input_addr)to a version that resolves this vulnerability.Patch xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full
Event History
Frequently Asked Questions
What conditions are required to reach the out-of-bounds write?
The secpath must already be at XFRM_MAX_DEPTH when IPv6 input is re-entered through the transport-mode receive path via xfrm_trans_reinject(). The inner packet must then carry either a destination-options Home Address Option (HAO) or a type-2 routing header, causing xfrm6_input_addr() to run.
How can administrators detect that the vulnerable path has been triggered?
A kernel built with UBSAN bounds checking can report an array-index-out-of-bounds event in net/ipv6/xfrm6_input.c at xfrm6_input_addr(), with index 6 reported as outside the xfrm_state *[6] array. Systems configured with panic_on_warn may panic when UBSAN reports the condition.
Is the write necessarily detected by KASAN?
No. The write is one slot beyond the xvec array but remains within the surrounding sec_path allocation, so it is described as invisible to KASAN.