CVE-2026-23354

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Mar 25, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in how the Linux kernel handles certain low-level CPU operations on x86 systems could let a logged-in user peek at protected memory they should not see.

Chainable

Exploitation: Local Privilege
Attacker needs: Low Privilege
Complexity: Low
Impact: Data Exposure
Component: OS kernel
Class: Improper Input Validation
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

Improper placement of array_index_nospec() allows the index value to be spilled to the stack before the array access in fred_extint(), enabling speculative execution to use memory predictions instead of the sanitized value and potentially leak kernel data across privilege boundaries.

Why it matters to the business

Local attackers can potentially read sensitive kernel memory or escalate privileges on affected Linux systems, risking data exposure or full host compromise in shared or multi-tenant environments; stable low exploit probability reduces immediate widespread risk but kernel prevalence heightens long-term exposure for servers and cloud workloads.

How an attack unfolds

An attacker with local access crafts input that triggers fred_extint(), relies on speculative execution to bypass the misplaced nospec barrier via stack predictions, and observes side-channel effects to infer kernel memory contents.

How to fix it

Update to a Linux kernel containing the corrected fred_extint() implementation that places array_index_nospec() directly in the array access expression; rebuild and reboot all affected systems; monitor vendor advisories for backported fixes since no fixed versions are listed.

How to confirm the fix worked

Inspect kernel source for removal of the separate index variable and direct embedding of array_index_nospec() immediately before the array dereference in fred_extint(); verify the patch commit is present after upgrade and confirm via kernel build logs or binary diffing.

Typical attack path

Obtain local unprivileged access on a vulnerable Linux host
Trigger the fred_extint() path with attacker-controlled index values
Prime CPU speculation and observe cache or timing side channels
Extract leaked kernel memory contents to escalate privileges or steal secrets

How to detect it

Review kernel logs and audit records for repeated entries into fred_extint() under unexpected contexts; correlate with process execution of untrusted local binaries and watch for anomalous cache or timing measurements indicative of side-channel probing.

What your security team should do

Prioritize kernel updates on all x86 Linux systems within change windows
Harden local access controls and monitor for unusual speculative side-channel activity
Track EPSS trend stability and re-evaluate if exploit maturity increases

The record

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.

Affected packages

Ecosystem	Package	Introduced	Fixed