Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2024-21944

CVE-2024-21944: DIMM SPD Privilege Escalation Vulnerability

CVE-2024-21944 is a privilege escalation flaw in DIMM serial presence detect metadata that allows attackers to overwrite guest memory. This post covers technical details, affected systems, and mitigation strategies.

Published:

CVE-2024-21944 Overview

CVE-2024-21944 is an improper input validation vulnerability ([CWE-20]) affecting AMD processor platforms that parse Dual In-line Memory Module (DIMM) Serial Presence Detect (SPD) metadata. The flaw allows an attacker with physical access, ring0 privileges on a system populated with a non-compliant DIMM, or control over the Root of Trust for BIOS update to overwrite guest memory. Successful exploitation results in loss of guest data integrity within virtualized workloads. AMD documented the issue in AMD Security Bulletin SB-3015.

Critical Impact

An attacker meeting the access prerequisites can corrupt guest virtual machine memory, breaking integrity guarantees expected from confidential computing and standard virtualization boundaries.

Affected Products

  • AMD processor platforms parsing DIMM SPD metadata (see AMD SB-3015 for the specific processor families and firmware versions)
  • Systems exposing virtualization or confidential computing features that rely on host-validated memory configuration
  • Server platforms where the BIOS Root of Trust update path is reachable by privileged software

Discovery Timeline

  • 2026-06-10 - CVE-2024-21944 published to the National Vulnerability Database
  • 2026-06-10 - Last updated in NVD database

Technical Details for CVE-2024-21944

Vulnerability Analysis

The vulnerability resides in how platform firmware consumes Serial Presence Detect data from installed DIMMs. SPD is a small EEPROM on each memory module that reports timing, capacity, and configuration parameters used by the memory controller during initialization. The firmware fails to validate this metadata before acting on it. A maliciously crafted SPD payload, or one supplied through a compromised BIOS update path, can steer memory controller configuration into a state where host firmware writes to memory regions assigned to a guest virtual machine. The result is corruption of guest physical memory without the guest's cooperation or detection.

Root Cause

The defect is a classic input validation failure categorized as [CWE-20]. Firmware trusts SPD content as authoritative because the EEPROM is physically attached to the module. No cryptographic verification or bounds checking constrains the values used during DRAM training and address decoding. When the supplied parameters fall outside expected ranges, downstream memory mapping logic produces overlapping or incorrect regions, allowing writes to cross isolation boundaries.

Attack Vector

Three exploitation paths exist. An attacker with physical access can install a non-compliant DIMM whose SPD EEPROM has been reprogrammed with malicious values. A ring0 attacker on a host already populated with a non-compliant DIMM can trigger configuration paths that consume the bad metadata. An attacker who controls the Root of Trust for BIOS update can deliver firmware that parses SPD without proper validation. All three paths are local and require high privilege or hardware access, which is reflected in the local attack vector and high privileges required for exploitation. The vulnerability does not directly expose confidentiality or availability, but integrity loss within guest virtual machines is significant for multi-tenant and confidential computing deployments.

No public proof-of-concept code is available. Refer to AMD Security Bulletin SB-3015 for vendor technical details.

Detection Methods for CVE-2024-21944

Indicators of Compromise

  • Unexpected guest virtual machine crashes, kernel panics, or filesystem corruption that correlate with host reboots or DIMM hot-events
  • Memory training logs in BIOS or BMC showing SPD values outside JEDEC-specified ranges
  • Unsigned or unexpected BIOS update events recorded by the platform Root of Trust

Detection Strategies

  • Inventory installed DIMMs and compare reported SPD fields against vendor part-number databases to identify non-compliant modules
  • Monitor platform attestation reports from AMD Secure Processor or equivalent measured boot facilities for unexpected firmware measurements
  • Correlate host hardware change events with subsequent guest integrity failures in hypervisor logs

Monitoring Recommendations

  • Forward BMC, IPMI, and hypervisor event logs to a centralized log store for long-retention review of firmware update and memory configuration events
  • Alert on any BIOS or microcode update that does not match an approved change ticket
  • Track ring0 driver loads on hypervisor hosts and review any new kernel modules touching memory controller MSRs

How to Mitigate CVE-2024-21944

Immediate Actions Required

  • Apply the AGESA and BIOS updates referenced in AMD Security Bulletin SB-3015 once your server OEM publishes a compatible package
  • Restrict physical access to servers hosting multi-tenant or confidential computing workloads
  • Audit and enforce signed BIOS update policies so only vendor-approved firmware reaches the Root of Trust

Patch Information

AMD has published mitigations in Security Bulletin SB-3015. Server OEMs integrate the fixed AGESA into platform BIOS releases. Administrators should consult their server vendor (for example Dell, HPE, Lenovo, Supermicro) for the specific BIOS version that incorporates the AMD fix and follow the vendor's documented update procedure.

Workarounds

  • Procure DIMMs only from validated channels and verify part numbers against the OEM qualified vendor list before installation
  • Disable or tightly restrict ring0 access paths by hardening hypervisor host operating systems and removing unsigned kernel drivers
  • Enable platform attestation and refuse to schedule sensitive guests on hosts whose measurements do not match a known-good baseline
bash
# Verify installed BIOS version on a Linux host before and after applying the OEM update
sudo dmidecode -s bios-version
sudo dmidecode -s bios-release-date

# Enumerate DIMM SPD metadata for inventory and comparison against vendor specifications
sudo dmidecode -t memory | grep -E 'Manufacturer|Part Number|Serial Number|Size|Speed'

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.