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

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

Is there a patch available for CVE-2026-23354?

Yes, a patch is available for CVE-2026-23354. Update the affected software to the latest version immediately.

Linux CVE-2026-23354

EUVD-2026-15329 HIGH

Improper Validation of Array Index (CWE-129)

2026-03-25 Linux

GHSA-4jgp-jccm-6ppx

Linux Information Disclosure Red Hat

7.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.8 HIGH

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

SUSE

5.2 MEDIUM

qualitative

Red Hat

3.3 MEDIUM

qualitative

Primary rating from NVD.

CVSS VectorNVD

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

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Re-analysis Queued

Apr 24, 2026 - 19:22 vuln.today

cvss_changed

CVSS changed

Apr 24, 2026 - 19:22 NVD

7.8 (HIGH)

Patch released

Mar 31, 2026 - 21:13 nvd

Patch available

EUVD ID Assigned

Mar 25, 2026 - 10:45 euvd

EUVD-2026-15329

Analysis Generated

Mar 25, 2026 - 10:45 vuln.today

CVE Published

Mar 25, 2026 - 10:27 nvd

N/A

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

x86/fred: Correct speculative safety in fred_extint()

array_index_nospec() is no use if the result gets spilled to the stack, as it makes the believed safe-under-speculation value subject to memory predictions.

For all practical purposes, this means array_index_nospec() must be used in the expression that accesses the array.

As the code currently stands, it's the wrong side of irqentry_enter(), and 'index' is put into %ebp across the function call.

Remove the index variable and reposition array_index_nospec(), so it's calculated immediately before the array access.

AnalysisAI

This vulnerability is a speculative execution safety flaw in the Linux kernel's x86 FRED (Flexible Return and Event Delivery) interrupt handling code where array_index_nospec() is incorrectly positioned, allowing speculative memory predictions to leak sensitive information through side-channel attacks. The vulnerability affects all Linux kernel versions with FRED support (primarily x86-64 systems with newer Intel/AMD processors). An attacker with local access could potentially infer sensitive kernel memory values through timing or covert channel attacks exploiting the unsafe speculation window.

Technical ContextAI

The vulnerability exists in the x86/fred subsystem's fred_extint() function, which handles external interrupts using FRED (Flexible Return and Event Delivery), a newer x86 interrupt delivery mechanism introduced in recent Intel and AMD processors. The root cause is improper application of array_index_nospec(), a kernel defense mechanism designed to prevent array indexing side-channel attacks (CWE-1041: Use of Incompletely Controlled Index or Strength Constraint). The bug occurs because array_index_nospec() sanitizes an index value, but the sanitized value is then spilled to the stack across an irqentry_enter() function call, placing it in %ebp register. This defeats the speculative safety guarantee because the value becomes subject to memory prediction attacks before being used to access the array. The fix requires moving the array_index_nospec() call immediately before the array access to ensure the sanitized value is used directly without intermediate spills to memory.

RemediationAI

Update the Linux kernel to the latest stable version that includes the fred_extint() speculative safety fix, available in the stable kernel commits referenced above. Users should check their kernel version with 'uname -r' and verify whether FRED is enabled (check dmesg for FRED initialization messages). For systems with FRED-capable processors, apply kernel updates via your distribution's package manager (e.g., 'apt upgrade linux-image' on Debian, 'yum update kernel' on Red Hat, or 'pacman -Syu' on Arch). Until patches can be applied, limit interrupt-intensive workloads and enforce strong access controls to prevent local privilege escalation, though these are not reliable mitigations. For systems where FRED is not used, ensure FRED is disabled in BIOS/UEFI to avoid the code path entirely, though modern kernels with this patch should be preferred regardless.

Same weakness CWE-129 – Improper Validation of Array Index

View all

CVE-2016-9053 CRITICAL POC

9.8

CVE-2020-27485 CRITICAL POC

9.9

CVE-2020-27483 CRITICAL POC

9.9

CVE-2024-24563 CRITICAL POC

9.8

CVE-2017-8797 HIGH

7.5

CVE-2018-11489 HIGH POC

8.8

CVE-2026-56770 HIGH POC

8.7

CVE-2017-7228 HIGH POC

8.2

Same technique Information Disclosure

View all

CVE-2013-2251 CRITICAL POC

9.8

CVE-2017-5638 CRITICAL POC

9.8

CVE-2025-24813 CRITICAL POC

9.8

CVE-2015-1701 HIGH POC

7.8

CVE-2017-0147 HIGH POC

7.5

CVE-2014-6324 HIGH POC

8.8

CVE-2023-7028 CRITICAL POC

10.0

CVE-2017-0213 HIGH POC

7.3

Vendor StatusVendor

Debian

linux

Release	Status	Fixed Version	Urgency
bullseye	not-affected	-	-
bullseye (security)	fixed	5.10.251-1	-
bookworm	not-affected	-	-
bookworm (security)	fixed	6.1.164-1	-
trixie	vulnerable	6.12.73-1	-
trixie (security)	vulnerable	6.12.74-2	-
forky, sid	fixed	6.19.8-1	-
(unstable)	fixed	6.19.8-1	-

SUSE

Severity: Medium

Product	Status
SUSE Linux Enterprise Desktop 15 SP7	Fixed
SUSE Linux Enterprise Desktop 15 SP7	Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7	Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7	Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7	Fixed

CVE-2026-23354 vulnerability details – vuln.today

Back

Linux CVE-2026-23354

Severity by source

CVSS VectorNVD

Lifecycle Timeline

DescriptionCVE.org

AnalysisAI

Technical ContextAI

RemediationAI

Same weakness CWE-129 – Improper Validation of Array Index

Same technique Information Disclosure

Vendor StatusVendor

Debian

SUSE

Share

External POC / Exploit Code