What is the CVSS score of CVE-2026-89783?

CVE-2026-89783 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

Which versions of Linux Kernel are affected by CVE-2026-89783?

Linux kernel-based systems, especially those running IPv6 IPsec, are affected by a memory-safety flaw that can cause a denial-of-service only when the non-default kernel.panic_on_warn sysctl is…. A patch is available.

How to fix or mitigate CVE-2026-89783?

Within 24 hours, inventory Linux kernel systems and determine whether IPv6 IPsec is enabled and whether kernel.panic_on_warn=1 (the non-default setting that makes this flaw fatal); apply the vendor-released patch per the vendor advisory for CVE-2026-89783 as soon as the distribution-specific fixed kernel package is available (Patch available per vendor advisory), noting that no exact fixed version was provided in the input. Within 7 days, prioritize patching for any Linux kernel host with panic_on_warn=1 or with untrusted IPv6 IPsec exposure, stage the vendor kernel update through change control, and if patching must be delayed, keep panic_on_warn=0 and disable IPv6 IPsec where it is not required while monitoring UBSAN_BOUNDS warnings. Within 30 days, complete kernel patching across all affected Linux assets, verify through vendor advisories that the corrected xfrm6_input_addr depth guard is included, and add configuration checks to flag panic_on_warn=1 and confirm IPv6 IPsec exposure is either patched or removed.

Linux Kernel CVE-2026-89783

EUVD-2026-80304 CRITICAL

2026-09-16 Linux

GHSA-w5hj-mmmx-p42j

Buffer Overflow Linux

9.8

CVSS 3.1 · Vendor: Linux

Severity by source

Vendor (Linux) PRIMARY

9.8 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

5.9 MEDIUM

Reaching the write needs a full nested secpath plus Mobile IPv6 header (AC:H); write stays within allocation so C:N/I:N; impact is a panic under panic_on_warn, hence A:H.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Sep 16, 2026 - 15:23 vuln.today

CVSS changed

Sep 16, 2026 - 15:22 NVD

9.8 (CRITICAL)

Patch available

Sep 16, 2026 - 10:02 EUVD

CVE Published

Sep 16, 2026 - 08:48 cve.org

CRITICAL 9.8

CVE Published

Sep 16, 2026 - 08:48 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

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]'

Articles & Coverage 1

News Critical Stack Buffer Overflow in Linux Kernel IPv6 IPsec - CVE-2026-89783 Sep 16, 2026

AnalysisAI

IPv6 IPsec receive processing in the Linux kernel writes one element past the end of the six-slot xfrm_state pointer array in xfrm6_input_addr(), because the depth guard tests '1 + sp->len == XFRM_MAX_DEPTH' instead of '>=', so a secpath already stacked to XFRM_MAX_DEPTH by xfrm_input() and preserved across xfrm_trans_reinject() bypasses the check and stores into sp->xvec[sp->len++]. The attacker must control an inner packet carrying a Mobile IPv6 destination-options Home Address option or a type-2 routing header, and because the write stays inside the larger sec_path allocation it is invisible to KASAN - it is only flagged by UBSAN_BOUNDS and only fatal when the non-default panic_on_warn sysctl is enabled, otherwise it is a logged warning with no functional effect. …

Unlock full vulnerability intelligence

Risk assessment & exploitation conditions
Attack chain visualization
Remediation with exact patch versions
Threat intelligence from 22 sources
Personal watchlist & email alerts

Continue with Google Continue with GitHub

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Access

technique details hidden

Delivery

technique details hidden

Exploit

technique details hidden

Execution

technique details hidden

Impact

technique details hidden

Access

technique details hidden

Delivery

technique details hidden

Exploit

technique details hidden

Execution

technique details hidden

Impact

technique details hidden

Vulnerability AssessmentAI

Exploitation	Requires the host to use the IPv6 IPsec (xfrm) transport-mode receive path with a secpath stacked to XFRM_MAX_DEPTH (6 nested SA transforms), reached via xfrm_trans_reinject(), and an inner packet carrying either a destination-options Home Address (HAO) option or a type-2 routing header (Mobile IPv6 constructs). … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment	The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H = 9.8) is the generic maximal score auto-assigned to Linux kernel CVEs and is not credible for this specific bug. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario	Full exploit scenario with step-by-step reproduction available after sign-in.
Remediation	Vendor-released patch: upgrade to the fixed kernel for your branch - 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, or 7.2.6 (with 7.3-rc1 as the mainline fix) - or cherry-pick the corresponding stable commit (5f35a29a5eed3d80befd32050843ac88dea3d61a, 91fc387f63c00ddfb5221127a17bac97549a8343, 8fe2c53fb81f5ad5be43af2ad09583f7c78b4b77, 48996649222e95008cdb98cd58579e3fc8e5ee06, bdcda866c89f9a8b1acdabf02d26cde9fbe501d8, 68e8737fe8e72f085c608cff322b3d2de8340af1, 0f679e0523ddfff3fb554336ceb874b0e51e9cd3, 5d9e3bf34fec9a5d237e4b7cef4a707bc2e091bc), which replaces the erroneous '1 + sp->len == XFRM_MAX_DEPTH' test with 'sp->len >= XFRM_MAX_DEPTH'. … Detailed patch versions, workarounds, and compensating controls in full report.

Recommended ActionAI

Within 24 hours, inventory Linux kernel systems and determine whether IPv6 IPsec is enabled and whether kernel.panic_on_warn=1 (the non-default setting that makes this flaw fatal); apply the vendor-released patch per the vendor advisory for CVE-2026-89783 as soon as the distribution-specific fixed kernel package is available (Patch available per vendor advisory), noting that no exact fixed version was provided in the input. …

Threat intelligence, references, and detailed analysis are available after sign-in.