CVE-2024-44948

What it actually does

Missing capability check in mtrr_save_state() before accessing fixed MTRR MSRs on x86 CPUs without the fixed MTRR capability bit causes an RDMSR that triggers a handled #GP fault and a subsequent WARN_ON().

Why it matters to the business

On affected older or non-standard x86 hardware, kernel operations may generate spurious warnings and log noise, potentially complicating troubleshooting or monitoring without causing functional failure or data exposure.

How an attack unfolds

An attacker with local access on an unsupported CPU triggers mtrr_save_state() during normal kernel operation; the absent capability check leads to an RDMSR that faults, producing a warning but no further attacker-controlled effect because the fault is handled gracefully.

How to fix it

Update the Linux kernel to a version containing commit 34f36e6ee5bd7eff8b2adcd9fcaef369f752d82e or later; for affected downstream projects such as constellation/v2 upgrade to version 2.5.2 or newer.

How to confirm the fix worked

Boot the patched kernel on hardware lacking the fixed MTRR capability bit and confirm absence of the WARN_ON() message during MTRR state save operations; inspect kernel source for the added capability check before MSR access.

Typical attack path

1. Obtain local code execution on target system
2. Trigger code paths that invoke mtrr_save_state()
3. Observe resulting kernel warning on CPUs lacking fixed MTRR support

How to detect it

Search kernel logs and dmesg output for MTRR-related warnings or stack traces indicating RDMSR faults during state save operations; correlate with hardware capability queries if available.

What your security team should do

• Prioritize kernel updates on systems using older x86 CPUs that may lack fixed MTRR support
• Monitor kernel logs for unexpected WARN_ON() entries related to MTRR during boot or suspend/resume
• Review hardware compatibility lists for any remaining systems that could trigger the path