Cloudanix VulnDB

CVE-2025-38047

None

CVSS

—

EPSS

0.2%

Published

Jun 18, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel problem can make some computers freeze when waking from hibernation on certain newer processors.

Exploitation
Other
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The flaw leaves FRED MSRs populated with restore-kernel values after the hibernation image is restored; the image kernel does not recompute and reload the MSRs that depend on kernel text/data locations, resulting in a system hang on S4 resume when FRED is enabled.

Why it matters to the business

Systems using hibernation (S4) may become unresponsive on resume, producing unexpected downtime; the issue affects a narrow configuration and carries low exploitation probability, but organizations running large Linux fleets should still treat kernel updates as routine maintenance.

How an attack unfolds

An attacker with local access or the ability to force hibernation/resume cycles could trigger the hang for denial-of-service; listed threat actors reference unrelated privilege-escalation and information-leak campaigns and do not indicate active exploitation of this resume-path issue.

How to fix it

Update the Linux kernel to commit c42f740a07eea4807e98d2d8febc549c957a7b49 or later; for armagetron on Mageia 5 apply package 0.2.8.3.3-1.mga5 or newer. Reboot after the update and verify FRED-enabled systems resume from S4 without hanging.

How to confirm the fix worked

Confirm the running kernel contains commit c42f740a07eea4807e98d2d8febc549c957a7b49, then perform controlled S4 suspend/resume cycles on FRED-enabled hardware while monitoring for hangs.

Typical attack path

  1. Obtain ability to initiate S4 hibernation on a FRED-enabled x86 system
  2. Trigger or wait for the hibernation cycle to complete
  3. Force resume so the restore kernel loads the image kernel
  4. Observe hang caused by mismatched FRED MSR state

How to detect it

Review system logs and dmesg around resume events for FRED-related MSR warnings or kernel hangs; correlate with hibernation timestamps. No widespread exploitation indicators are known.

What your security team should do

  • Apply the referenced kernel commit or distribution package update at the next maintenance window
  • Prioritize systems that regularly use hibernation or S4 power states
  • Document the change and re-test resume functionality in staging before broad rollout

The record

In the Linux kernel, the following vulnerability has been resolved: x86/fred: Fix system hang during S4 resume with FRED enabled Upon a wakeup from S4, the restore kernel starts and initializes the FRED MSRs as needed from its perspective. It then loads a hibernation image, including the image kernel, and attempts to load image pages directly into their original page frames used before hibernation unless those frames are currently in use. Once all pages are moved to their original locations, it jumps to a "trampoline" page in the image kernel. At this point, the image kernel takes control, but the FRED MSRs still contain values set by the restore kernel, which may differ from those set by the image kernel before hibernation. Therefore, the image kernel must ensure the FRED MSRs have the same values as before hibernation. Since these values depend only on the location of the kernel text and data, they can be recomputed from scratch.

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 linux 0 No fix
Debian:12 linux 0 No fix
Debian:13 linux 0 6.12.32-1
Linux Kernel 6.9.0 6.12.31
SUSE:Linux Enterprise Live Patching 15 SP7 kernel-livepatch-SLE15-SP7-RT_Update_3 0 1-150700.1.5.1
SUSE:Real Time Module 15 SP7 kernel-rt 0 6.4.0-150700.7.13.1
SUSE:Real Time Module 15 SP7 kernel-source-rt 0 6.4.0-150700.7.13.1
SUSE:Real Time Module 15 SP7 kernel-syms-rt 0 6.4.0-150700.7.13.1

Related vulnerabilities