Skip to main content

Linux Kernel EUVDEUVD-2026-25454

| CVE-2026-31561 MEDIUM
2026-04-24 Linux GHSA-pgvp-p3vq-7q7h
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.7 MEDIUM

AC:H raised from NVD's AC:L to reflect the narrow boot-timing window required; no confidentiality or integrity impact beyond system crash.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

6
Analysis Generated
Jul 24, 2026 - 03:12 vuln.today
CVSS changed
Apr 27, 2026 - 20:37 NVD
5.5 (MEDIUM)
Patch released
Apr 27, 2026 - 20:30 nvd
Patch available
Patch available
Apr 24, 2026 - 16:16 EUVD
EUVD ID Assigned
Apr 24, 2026 - 15:00 euvd
EUVD-2026-25454
CVE Published
Apr 24, 2026 - 14:35 nvd
MEDIUM 5.5

DescriptionCVE.org

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

x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits mask

Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so that whenever something else modifies CR4, that bit remains set. Which in itself is a perfectly fine idea.

However, there's an issue when during boot FRED is initialized: first on the BSP and later on the APs. Thus, there's a window in time when exceptions cannot be handled.

This becomes particularly nasty when running as SEV-{ES,SNP} or TDX guests which, when they manage to trigger exceptions during that short window described above, triple fault due to FRED MSRs not being set up yet.

See Link tag below for a much more detailed explanation of the situation.

So, as a result, the commit in that Link URL tried to address this shortcoming by temporarily disabling CR4 pinning when an AP is not online yet.

However, that is a problem in itself because in this case, an attack on the kernel needs to only modify the online bit - a single bit in RW memory - and then disable CR4 pinning and then disable SM*P, leading to more and worse things to happen to the system.

So, instead, remove the FRED bit from the CR4 pinning mask, thus obviating the need to temporarily disable CR4 pinning.

If someone manages to disable FRED when poking at CR4, then idt_invalidate() would make sure the system would crash'n'burn on the first exception triggered, which is a much better outcome security-wise.

AnalysisAI

The Linux kernel's x86 FRED (Flexible Return and Event Delivery) initialization path crashes AMD SEV-ES, SEV-SNP, and Intel TDX confidential VM guests via triple fault when any exception is triggered during the brief AP initialization window before FRED MSRs are configured. A prior attempted mitigation introduced a secondary risk: temporarily disabling CR4 pinning for offline CPUs created a path where a local attacker could flip a single RW-memory bit (the CPU online flag) to suppress CR4 security controls and disable SMEP/SMAP protections. No public exploit has been identified at time of analysis; EPSS is 0.02% (5th percentile), consistent with the narrow real-world exploitability of this flaw.

Technical ContextAI

FRED (Flexible Return and Event Delivery) is an Intel CPU architecture feature that replaces legacy IDT-based exception dispatch with a more efficient MSR-controlled mechanism, enabled via a dedicated bit in the CR4 control register. The Linux kernel's CR4 pinning subsystem protects security-critical CR4 bits - including SMEP (Supervisor Mode Execution Prevention) and SMAP (Supervisor Mode Access Prevention) - from being cleared by privileged kernel exploits. The defect originates from a commit that added the FRED CR4 bit to the pinned bits mask before FRED MSRs are configured on Application Processors (APs) during SMP bring-up, creating a window where the pinning asserts a bit the system cannot yet back with proper handler state. Confidential VM platforms (AMD SEV-ES, SEV-SNP, Intel TDX) intercept exceptions differently from standard VMs, and any exception during this unconfigured FRED window triggers an unrecoverable triple fault. The CPE (cpe:2.3:a:linux:linux:*) identifies the Linux kernel broadly; in practice, only x86 builds with FRED hardware support deployed as confidential VM guests are affected by the primary fault path.

RemediationAI

Upgrade the Linux kernel to a patched version: 6.12.80, 6.18.21, 6.19.11, or 7.0. Stable-branch fix commits are published at https://git.kernel.org/stable/c/d7853d9fe94abf43b46c57b0b7f8418198b7615a, https://git.kernel.org/stable/c/a6e14114684d2324e5401617d6d01acb4a4e0e22, https://git.kernel.org/stable/c/00d956dafa76f86a73424fe5cce3d604a8be2e4b, and https://git.kernel.org/stable/c/411df123c017169922cc767affce76282b8e6c85. Distribution patches from Red Hat and SUSE should be monitored through their respective security channels. For environments that cannot patch immediately and are running SEV-ES, SEV-SNP, or TDX confidential workloads, consider temporarily disabling FRED at kernel build time or via boot parameters if the platform allows it - note this reverts exception handling to legacy IDT dispatch and may affect performance and security posture of FRED-dependent paths. Standard bare-metal and non-confidential VM deployments are not affected by the primary fault and do not require emergency response.

Vendor StatusVendor

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

Share

EUVD-2026-25454 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy