CVE-2025-6202: SK Hynix DDR5 Rowhammer Vulnerability

CVE-2025-6202 Overview

CVE-2025-6202 is a hardware vulnerability affecting SK Hynix DDR5 memory modules on x86 platforms. A local attacker can trigger Rowhammer-induced bit flips that compromise hardware integrity and the broader security of the system. The flaw affects DDR5 DIMMs produced between January 2021 and December 2024, covering a large portion of the in-market DDR5 inventory. The vulnerability was disclosed in coordination with researchers from ETH Zurich's ComSec group as part of the Phoenix research project, with supporting analysis from Google. It is tracked under [CWE-404] (Improper Resource Shutdown or Release) and carries a CVSS 4.0 base score of 7.1.

Critical Impact

A local attacker with limited privileges can induce bit flips in adjacent DRAM rows, bypassing in-DRAM Target Row Refresh (TRR) mitigations to corrupt memory used by privileged processes, the kernel, or cryptographic material.

Affected Products

• SK Hynix DDR5 DIMMs manufactured between 2021-01 and 2024-12
• x86 host systems populated with affected DDR5 modules
• Workloads relying on DDR5 memory integrity for security boundaries (virtualization, sandboxing, cryptography)

Discovery Timeline

• 2025-09-15 - CVE-2025-6202 published to NVD with details from the ETH Zurich Phoenix research
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-6202

Vulnerability Analysis

Rowhammer is a DRAM disturbance effect. Repeated activation of one DRAM row (the aggressor) leaks charge from neighboring rows (victims), flipping bits without direct access to those addresses. DDR5 introduced refresh management and on-die in-DRAM TRR mechanisms intended to neutralize this class of attack.

The Phoenix research demonstrates that SK Hynix DDR5 modules produced from 2021 through 2024 contain TRR sampling weaknesses. Researchers built self-correcting refresh-synchronized hammering patterns that evade in-DRAM mitigations and produce reproducible bit flips on default-configured systems. Once a bit flip lands in security-relevant memory, a local attacker can corrupt page table entries, escalate privileges, or compromise cryptographic keys.

Root Cause

The root cause is insufficient coverage of aggressor row tracking in SK Hynix DDR5 TRR logic. The sampler does not reliably detect adversarial access patterns synchronized to the refresh interval, leaving victim rows exposed to charge leakage. Because the defect resides in the DRAM device itself, it cannot be eliminated through operating system patches.

Attack Vector

Exploitation requires local code execution at low privilege. The attacker allocates memory, identifies physically contiguous rows through side channels such as timing or huge-page mappings, and issues hammering loops aligned with the DRAM refresh window. After bit flips are induced in target rows, the attacker pivots to privilege escalation, sandbox escape, or key recovery depending on which structure was corrupted. No network access or user interaction is required.

No public exploit code is currently available for CVE-2025-6202. Technical details and proof-of-concept methodology are described in the ETH Zurich ComSec Phoenix project and the Google Security Blog Rowhammer research update.

Detection Methods for CVE-2025-6202

Indicators of Compromise

• Unexpected machine check exceptions (MCEs) or correctable ECC events reported by the memory controller and platform firmware
• Unexplained kernel panics, segmentation faults, or page table integrity failures originating from unprivileged processes
• Sustained processes generating high volumes of CLFLUSH, non-temporal stores, or tight memory access loops to specific physical address ranges

Detection Strategies

• Enable and monitor DRAM error telemetry through rasdaemon, mcelog, or vendor BMC interfaces and alert on rising correctable error rates
• Hunt for processes exhibiting Rowhammer-like access patterns: repeated cache-flush instructions combined with high memory bandwidth on small address windows
• Correlate hardware error logs with process execution telemetry to attribute anomalous DRAM behavior to a specific workload or user

Monitoring Recommendations

• Aggregate platform RAS (Reliability, Availability, Serviceability) logs centrally and baseline normal correctable-error rates per DIMM
• Track use of huge pages and pagemap access by unprivileged users, which is commonly required to locate physically contiguous victim rows
• Review virtualization hosts and multi-tenant systems where a single bit flip across tenant boundaries can break isolation

How to Mitigate CVE-2025-6202

Immediate Actions Required

• Inventory DDR5 DIMMs by manufacturer, part number, and production date and identify SK Hynix modules within the 2021-01 to 2024-12 window
• Enable ECC and, where supported by the platform, on-die ECC plus link ECC reporting so that bit flips surface as observable events
• Increase DRAM refresh rate (lower tREFI) on supported platforms and motherboards to reduce the hammering window available to attackers
• Restrict local code execution on shared and multi-tenant systems and remove unnecessary local accounts

Patch Information

CVE-2025-6202 is a hardware defect in DDR5 DIMMs. No software patch fully remediates the issue. Mitigation depends on platform firmware updates, memory controller configuration changes, and DIMM replacement guidance from system OEMs and SK Hynix. Apply BIOS and microcode updates from your hardware vendor as they become available, and consult the OEM for DIMM replacement programs covering affected production batches.

Workarounds

• Disable transparent huge pages and restrict access to /proc/self/pagemap for unprivileged users to raise the cost of locating victim rows
• Apply kernel hardening such as Linux CONFIG_KSM review, guard pages around sensitive kernel allocations, and isolation of security-critical structures
• Segregate untrusted workloads onto hardware populated with unaffected DIMMs and avoid co-residency with sensitive tenants
• Where feasible, replace affected SK Hynix DDR5 modules with DIMMs confirmed by the vendor to include corrected TRR implementations

# Example: raise DRAM refresh frequency awareness and monitor ECC events on Linux
sudo dmidecode -t memory | grep -E 'Manufacturer|Part Number|Week|Year|Size'
sudo systemctl enable --now rasdaemon
sudo ras-mc-ctl --error-count
sudo ras-mc-ctl --summary