DDR5 Memory Explained: On-Die ECC, PMIC, Refresh and Rowhammer

DDR5 is the fifth generation of DDR SDRAM, published by JEDEC as JESD79-5 in July 2020. It splits each DIMM into two independent subchannels, doubles burst length to 16, runs at 1.1 V from a power chip on the module, and adds on-die ECC. Against Rowhammer it adds Refresh Management and, since April 2024, Per Row Activation Counting.

None of those features makes DDR5 immune. On-die ECC exists mainly to keep denser chips reliable, not to stop attacks, and it is not the same thing as the ECC on a server module. Research published in 2024 and 2025 flipped bits on real DDR5 modules, and one 2025 study flipped bits on every module it tested from one manufacturer. This guide goes one level deeper than our memory evolution overview: what changed electrically, what each reliability feature really does, what the research showed, and the exact commands to check your own machines.

Key takeaways

• A DDR5 DIMM carries two independent subchannels of 32 data bits each. On modules with side-band ECC each subchannel is 40 bits wide (32 data plus 8 check bits), which is the figure JEDEC used when it announced the standard on 14 July 2020.
• Burst length 16 on a 32-bit subchannel moves exactly 64 bytes, one CPU cache line, using half the DIMM. That is why one DDR5 DIMM behaves like two narrower channels.
• On-die ECC is single error correction over 128 data bits plus 8 parity bits, done inside each DRAM chip. It never protects the bus between the DRAM and the CPU, and it does not report what it fixed to the operating system in the way side-band ECC does.
• The power management IC (PMIC) moved from the motherboard onto the module. Texas Instruments' application brief says the input to the DIMM is 5 V or 12 V depending on the variant, and the PMIC makes the 1.1 V and 1.8 V rails locally.
• Refresh Management (RFM) gives the DRAM extra time to refresh rows near heavily used ones. Per Row Activation Counting (PRAC), added in JESD79-5C on 17 April 2024, counts activations per row in the chip and asks the memory controller to back off when a count gets too high.
• ZenHammer (USENIX Security 2024) flipped bits on 1 of 10 DDR5 devices. Phoenix (disclosed 15 September 2025, CVE-2025-6202) flipped bits on all 15 SK hynix DDR5 DIMMs the ETH Zurich team tested. Tripling the refresh rate stopped Phoenix on the test systems at an 8.4% cost on SPEC CPU2017.
• For fleets: buy side-band ECC where data matters, confirm errors are actually reported, apply firmware updates that change refresh or mitigation settings, and keep overclocking profiles off servers.

A dated DDR5 timeline

Every date below comes from a JEDEC announcement, a research group's own page or the NVD record. Where we could only reach a JEDEC press release through a republished copy, the Sources section says so.

What changed electrically from DDR4 to DDR5

DDR5 is not a faster DDR4. JEDEC's 2020 announcement framed the goal as scaling performance "without degrading channel efficiency at higher speeds." To get there the standard changed the shape of the module, the length of each transfer, the internal organisation of each chip, the voltages and the way signals are received.

DDR4 vs DDR5 at a glance

The values below come from the JEDEC announcements and Micron's two DDR5 white papers. Ranges reflect what the standard defines, not what any one product ships.

Two subchannels per DIMM

On DDR4 a DIMM presents one 64-bit data channel to the memory controller. On DDR5 the same physical slot carries two fully independent subchannels, each with its own command and address signals and 32 data bits. Micron's white paper puts the effect plainly: it essentially turns "an 8-channel system as we know it today into a 16-channel system."

The reason is concurrency. Two requests that land on different subchannels can proceed at once. Server workloads with many threads issuing small random reads benefit most.

When a module has side-band ECC, each subchannel grows to 40 bits: 32 data bits plus 8 check bits. That is why the JEDEC press release describes the DDR5 DIMM as having "two 40-bit fully independent sub-channels." Client modules without ECC carry only the 32 data bits per subchannel.

Burst length 16 and the 64-byte cache line

Most CPUs move memory in 64-byte cache lines. The burst length is how many transfers one read or write command produces. The arithmetic shows why DDR5 chose 16:

• DDR4: 64 bits per transfer x 8 transfers = 512 bits = 64 bytes, using the whole DIMM.
• DDR5: 32 bits per transfer x 16 transfers = 512 bits = 64 bytes, using one subchannel, half the DIMM.

So a DDR5 DIMM can serve two different cache lines at the same time, one per subchannel. Micron also notes that the longer default burst "reduces the number of IOs required to access the same 64B cache line data payload."

Worked example 1: peak bandwidth per DIMM

Peak bandwidth is width x transfer rate. Using the launch speeds JEDEC named:

• DDR4-3200: 64 bits x 3,200 million transfers per second = 204,800 million bits per second = 25.6 GB/s per DIMM.
• DDR5-4800: 2 subchannels x 32 bits x 4,800 million transfers per second = 307,200 million bits per second = 38.4 GB/s per DIMM.

That is a 1.5x jump at launch, which matches JEDEC's description of 4.8 Gbps as "50% higher than DDR4's end of life speed of 3.2 Gbps." At DDR5-6400 the same formula gives 51.2 GB/s, double DDR4-3200. Micron's paper estimates the effective gain at DDR5-4800 as about 1.87x once the efficiency features are counted, because peak numbers ignore the stalls that bank groups and same-bank refresh remove. ECC bits are not counted: they carry check data, not your data.

Bank groups, banks and same-bank refresh

Inside each DRAM chip, memory is divided into banks, and banks are grouped. Moving between two banks in different groups is fast (the "short" timings such as tCCD_S); moving between banks in the same group is slower (tCCD_L, which Micron says can be nearly double). DDR5 doubles the number of bank groups and keeps the number of banks per group, so a 16 Gb x8 chip goes from 16 to 32 banks. More groups means the controller hits the short timings more often.

Refresh also changed. Every DRAM cell leaks and must be rewritten periodically. DDR4 used an all-bank refresh, which idles every bank while it runs. DDR5 keeps that command (REFab) and adds same-bank refresh (REFsb), which refreshes the same bank number in every bank group while the other banks stay available. Micron gives the numbers for a 16 Gb DDR5 device: in normal mode a refresh is due every 3.9 µs on average and lasts 295 ns; same-bank refresh runs in fine granularity mode at 1.95 µs per bank and lasts only 130 ns.

Lower voltage and new rails

JEDEC moved VDD from 1.2 V to 1.1 V. Micron's table also shows VPP, the wordline pump supply, dropping from 2.5 V to 1.8 V.

A rough rule of thumb for switching power is that it scales with the square of voltage. With everything else held equal, (1.1 / 1.2) squared is about 0.84, so roughly 16% less switching energy per operation from the voltage change alone. Real savings depend on speed, temperature and workload, so treat that as an intuition, not a datasheet value.

Signal integrity at higher speeds

At several gigatransfers per second, each bit smears into the next. DDR5 adds a multi-tap decision feedback equaliser in the DRAM's data receivers, a duty cycle adjuster and new training modes. That is why a DDR5 system can spend noticeable time training memory on first boot, and why changing modules or profiles triggers retraining.

What on-die ECC corrects, and why it is not side-band ECC

This is the most misunderstood DDR5 feature. Marketing pages sometimes write "DDR5 has ECC built in" as if every DDR5 stick were now server-grade. It is not.

What on-die ECC does

According to Micron, DDR5 on-die ECC is single error correction (SEC) that pairs 128 data bits with 8 parity bits to form a 136-bit codeword. The chip stores the codeword on a write. On a read it computes a syndrome over the 136 bits and fixes any single flipped bit before the data leaves the chip.

JEDEC's 2020 announcement lists on-die ECC among the features that "enable manufacturing on advanced process nodes." That phrase is the honest purpose. As cells shrink, more of them are weak from the factory or drift over time. On-die ECC lets the manufacturer ship those chips without the system seeing the errors.

DDR5 also adds error check and scrub (ECS). The chip reads its own data, corrects single-bit errors and writes the fixed data back. In automatic mode it schedules this so that a full pass of the array completes within a recommended 24 hours. At the end of a pass it can report a count of corrected errors once that count passes a threshold, and the row with the most errors.

What on-die ECC does not do

• It does not protect the wires. Errors that happen between the DRAM chip and the memory controller, on the module traces, connector or motherboard, are invisible to it. DDR5's read and write CRC can detect some bus errors; side-band ECC corrects them.
• It does not detect two-bit errors reliably. Eight parity bits over 128 data bits are enough to correct one error but not to guarantee detection of two. Micron explains that DDR5 designs arrange the code so that a double-bit error "aliases" into a different quadrant of the word, so that it still shows up as a multi-bit fault to system-level ECC if the system has it. Without system ECC, that miscorrection simply reaches the CPU as wrong data.
• It does not tell the operating system what it fixed, read by read. The ECS counters are coarse and need firmware support to be read out at all. Linux EDAC counters, which most fleet monitoring relies on, come from the memory controller's side-band ECC, not from inside the chip.
• It does not stop Rowhammer. ETH Zurich's Phoenix page says on-die ECC does not stop the attack because flips can accumulate before they are corrected, which happens only when data is rewritten or after a scrub period such as 24 hours. More flips per word than the code can handle get through.

Worked example 2: overhead of the two kinds of ECC

On-die ECC adds 8 parity bits per 128 data bits: 8 / 128 = 6.25% extra storage inside every chip. You pay for it in every DDR5 module, ECC or not, and you cannot turn it off.

Side-band ECC adds 8 check bits per 32 data bits on each subchannel: 8 / 32 = 25%. On a module built from x8 chips, each 32-bit subchannel needs four data chips plus one ECC chip, so a rank has 10 chips instead of 8. That is the extra cost of an ECC UDIMM or RDIMM, and it buys correction across the bus plus error reporting to the OS. DDR4 ECC modules added 8 bits per 64 (12.5%), so DDR5 side-band ECC costs more per bit than DDR4 did, the price of having two independent subchannels.

Comparison: three levels of memory error protection

The right-hand column is deliberately generic. CPU and server vendors brand their chip-fail correction differently and document it in their own platform guides; read those for your hardware rather than assuming.

Why the power management IC moved onto the DIMM

On DDR4 the motherboard regulated memory voltages and fed every slot from the same rails. DDR5 moved that job onto each module. JEDEC's announcement describes "voltage regulator on DIMM design" that "enables pay as you go scalability, better voltage tolerance for improved DRAM yields and the potential to further reduce power consumption."

In practice that means three things.

1. Pay as you go. A board with two populated slots does not have to carry regulators sized for eight. Each module brings the power circuitry it needs.
2. Tighter regulation. The PMIC sits a few millimetres from the DRAM chips. Shorter distances mean less voltage droop under load, which matters at 1.1 V where small dips are a large fraction of the margin.
3. Telemetry and control. Texas Instruments' application brief (February 2026) says the PMIC "requires an I2C and I3C bus interface for configuration, fault conditions, and telemetry of voltage, current, power, and temperature."

What the PMIC produces

TI's brief lists the DDR5 on-DIMM rails:

Server versus client modules

TI says the input to the DIMM "can be 5V or 12V, depending on the DIMM variant." Vendor datasheets show the split. Renesas describes its P8911 as a client PMIC for UDIMMs and SODIMMs with a 4.25 V to 5.5 V input, three step-down regulators and two LDOs, aimed at notebook, desktop and embedded platforms. Its P8900 is listed separately as a PMIC "for DDR5 RDIMMs and LRDIMMs." Client PMICs are specified for a nominal 5 V input, which leaves the 12 V input for other variants; vendor material points to server-class RDIMMs and LRDIMMs, but confirm the input for your exact module in its datasheet. Either way, server and client modules use different PMIC parts, which is one more reason an RDIMM and a UDIMM are not interchangeable even before you count the registering clock driver.

The client part also lists "Secure Mode and Programmable mode," programmable output voltages and sequencing, error injection and persistent error log registers. That matters for two reasons. Overclocking profiles can raise module voltages through the PMIC, so a profile is no longer just a timing table. And a module that logs its own power faults gives a technician something to read when a machine fails to train memory.

Rowhammer in one page

Rowhammer is a read disturbance effect. Activating one DRAM row many times in a short period can flip bits in physically nearby rows that were never written. It was first described in published research in 2014 and has been shown on DDR3, DDR4, LPDDR4 and now DDR5. Our history of Rowhammer and cold boot attacks covers the earlier generations; here we only need the defender's view.

Three facts drive every DDR5 defence:

1. A row needs a minimum number of activations before neighbours flip. Research calls this the Rowhammer threshold. It has fallen with each process shrink, because smaller cells hold less charge and sit closer together.
2. Refresh resets the clock. Rewriting a victim row restores its charge. Anything that refreshes victims before the threshold is reached prevents the flip.
3. The DRAM cannot see the whole picture alone, and the controller cannot see inside the DRAM. Defences have to split the work between the chip and the memory controller.

DDR4-era chips relied on Target Row Refresh (TRR), an undocumented in-DRAM tracker that refreshes the neighbours of a few busy rows. DDR5 chips still use vendor TRR designs, and Phoenix was a TRR bypass. What DDR5 adds is a standard way for the chip and the controller to cooperate.

Refresh Management and Per Row Activation Counting

Worked example 4: the refresh budget

DDR5 halved the refresh window. The Chronus paper, citing the JEDEC standard, gives tREFW as 32 ms for DDR5, against 64 ms for DDR4. Every row must be refreshed within that window.

• Refresh commands per window: 32 ms / 3.9 µs = about 8,205, which is why DRAM datasheets speak of 8K refresh commands per window.
• Time spent refreshing in normal all-bank mode for a 16 Gb chip: 295 ns / 3,900 ns = about 7.6% of the time a rank is unavailable.
• Now triple the refresh rate, as the Phoenix researchers recommend as a stopgap: tREFI becomes about 1.3 µs, and 295 ns / 1,300 ns = about 22.7% of the time a rank is busy refreshing.

That 22.7% is not a 22.7% slowdown. The Phoenix team measured 8.4% on SPEC CPU2017, because programs do not spend every cycle waiting for memory and controllers overlap refresh with other work. But the arithmetic shows why the industry wanted something smarter than "refresh everything more often."

Worked example 5: how many activations fit in a window

Suppose, for illustration, a bank can accept one row activation every 50 ns. In a 32 ms window that is 32,000,000 ns / 50 ns = 640,000 activations to a single bank. If the Rowhammer threshold for a chip is in the low thousands, an attacker has room to hammer hundreds of rows past the threshold between scheduled refreshes. The real activation interval depends on the part and speed grade, so use your datasheet's tRC for real planning. The shape of the problem is the point: scheduled refresh alone gives an attacker hundreds of thresholds' worth of time.

Refresh Management (RFM)

RFM is a DRAM command. The Chronus paper describes it as a command that gives the DRAM chip a time window (the paper cites about 195 ns) to perform preventive refreshes of rows it considers at risk. The memory controller decides when to send it. In the simplest form, periodic RFM, the controller counts activations to a bank or region and issues RFM whenever the count passes a threshold.

JESD79-5A, published 26 October 2021, added Adaptive RFM, letting the threshold change with conditions. RFM's limitation is that the controller only knows how many activations a bank received, not which rows inside the DRAM are actually at risk. It is a coarse tool.

Per Row Activation Counting (PRAC)

JEDEC's 17 April 2024 announcement of JESD79-5C describes PRAC this way: it "precisely counts DRAM activations on a wordline granularity. When PRAC-enabled DRAM detects an excessive number of activations, it alerts the system to pause traffic and to designate time for mitigative measures."

The mechanism, as the Chronus and PRACLeak papers describe it:

1. Every row has an activation counter stored in the DRAM itself.
2. When a row's count reaches a back-off threshold, the DRAM asserts an alert signal to the controller (the Alert Back-Off, or ABO, protocol).
3. Within a defined window after the alert (Chronus cites about 180 ns as an example), the controller must issue RFM commands.
4. During those RFM windows the DRAM refreshes the potential victims of the most activated rows and resets their counters.
5. After a recovery period, a delay applies before the DRAM can raise the alert again.

PRAC moves the counting to where the information is. The DRAM knows exactly which rows were hammered. The controller only has to respond to the alert.

JESD79-5C also deprecated Partial Array Self Refresh "to address security concerns." JEDEC did not spell out the concern in the release; the effect is that a power-saving mode that skipped refreshing parts of the array is no longer recommended.

What PRAC costs, and its known weaknesses

PRAC is the first standard, chip-level Rowhammer mitigation with precise counts, and it is being studied hard.

• Latency. Incrementing a counter on every activation lengthens some DRAM timing parameters. Chronus (HPCA 2025) found PRAC's overhead on benign applications "non-negligible for modern DRAM chips" in simulation and larger for future chips with lower thresholds.
• Wave attack. Chronus also found that PRAC performs a fixed number of preventive refreshes per back-off. An adversarial pattern that brings many rows near the threshold together, called a wave attack, forces PRAC to be configured with much lower thresholds to stay safe. Chronus proposes separating counters from data and refreshing as many rows as needed per back-off.
• Timing side channel. PRACLeak (ISCA 2025) showed that the alert and RFM pauses create measurable latency differences that can leak information, and demonstrated leaking secret keys from vulnerable AES implementations in that setting. Its proposed fix, Timing-Safe PRAC, issues RFMs on a fixed schedule independent of activity, at a 3.4% overhead at a threshold of 1,024.
• Real hardware looks better than simulation. A July 2025 paper measured PRAC timing on real CPUs and found average and maximum overheads of 1.06% and 3.28% on SPEC CPU2017, up to 9.15 times lower than simulator reports, with a closed page policy hiding most of the extra precharge time.

The lesson for defenders is that PRAC is a real step forward and also a new mechanism with its own side effects. Treat it as one layer, not the end of the problem.

Comparison: DDR5 Rowhammer mitigations

What published research showed about DDR5's real resistance

Comparison of public DDR5 Rowhammer results

ZenHammer: the first public DDR5 flips

ETH Zurich's ZenHammer work focused on AMD Zen systems. The main result was that DDR4 on Zen 2 and Zen 3 was as exposed as on Intel systems once the address mapping was understood. On Zen 4 with DDR5, the team triggered flips on one of ten devices, about 42,000 of them. The authors called it the first public report of DDR5 bit flips on commodity systems and were careful to say that nine devices showed none and more research was needed. AMD was notified on 26 February 2024 and the results were made public on 25 March 2024.

Phoenix: every module from one maker

Phoenix went further. The team reverse engineered the in-DRAM TRR used in SK hynix DDR5 and found it left gaps that long hammering patterns could use, provided the attacker kept the pattern synchronised with refresh commands. They built a self-correcting synchronisation method to do that. All 15 DIMMs tested were vulnerable. The researchers limited the study to the largest DRAM maker because reverse engineering each vendor's mitigation is expensive, so the absence of other vendors in the results is not evidence that they are safe.

The research page reports a privilege escalation proof of concept that succeeded in as little as 109 seconds in the fastest case. We describe it only at that level. The NVD record for CVE-2025-6202, published 15 September 2025, describes local triggering of bit flips on SK hynix DDR5 on x86 and lists DIMMs produced from January 2021 until December 2024, with a CVSS 3.1 base score of 7.1.

The defensive lessons on the Phoenix page:

• Tripling the refresh rate (tREFI of about 1.3 µs) stopped Phoenix on the test systems at an 8.4% SPEC CPU2017 cost.
• On-die ECC did not stop it.
• The researchers were told on 12 September 2025 of a BIOS update for AMD client machines but said they could not verify that it fixes Phoenix. Check your own board vendor's notes rather than assuming.

What it means

DDR5's margin against Rowhammer depends on each vendor's undisclosed TRR. PRAC is the industry's answer, and early real-hardware numbers suggest its cost is modest. Until PRAC-capable modules and controllers are the norm in your fleet, the dependable levers are side-band ECC with monitoring, firmware updates that change refresh behaviour, and keeping untrusted code off machines that hold high-value data where you can.

The SPD hub, XMP and EXPO

What the SPD hub is

Every DIMM carries Serial Presence Detect (SPD) data: a small table that tells the firmware the module's size, organisation, speeds and timings. On DDR5 that table lives in an SPD hub. The Linux kernel's spd5118 driver documentation describes it as an SPD5118 device compliant with JEDEC JESD300, with a built-in temperature sensor that "some systems use" to throttle the memory controller. The driver finds these devices at I2C addresses 0x50 to 0x57, exposes temperature readings and alarm thresholds through hwmon, and exposes the SPD contents through an eeprom file on the device.

The hub also sits on the module's sideband bus with the PMIC and any extra temperature sensors. TI's table shows the PMIC feeding the hub its own 1.8 V and 1.0 V supplies. JEDEC said in 2020 that DDR5 uses the MIPI I3C Basic specification for this system management bus, which is faster than the SMBus style bus on DDR4.

What XMP and EXPO change

JEDEC defines standard speed bins and timings, and every DDR5 module boots at a JEDEC profile first. XMP and EXPO are extra profiles stored in the SPD data that tell the firmware to run the module faster, with tighter timings and, often, higher voltages.

• Intel XMP 3.0 for DDR5 supports up to five profiles: three set by the module vendor and two rewritable ones, and Intel says it adds support for on-module voltage control. Intel's page states that the first boot uses default JEDEC settings and that profiles apply only after you enable them in firmware.
• AMD EXPO stores overclocking profiles for DDR5 on Socket AM5 systems. AMD's memory compatibility list shows which kits support EXPO and which are compatible with XMP.

Both vendors are blunt about the trade-off. Intel says altering frequency or voltage outside its specifications "may void the processor warranty," and names enabling XMP as an example. AMD says operating memory outside its published specifications "will void any applicable AMD product warranty, even when enabled via AMD hardware and/or software," and lists data loss and corruption among the risks.

Why stability matters for security

A memory profile that is slightly unstable does not usually crash at once. It produces occasional wrong bits. On a non-ECC desktop nothing reports them. The symptoms look like software bugs: a corrupted archive, a compiler that fails once in a hundred runs, a database page that fails its checksum. On a build machine that produces software you ship, silent corruption is an integrity problem. On-die ECC does not help, because many profile-induced errors happen on the bus, outside the cell array.

Our rule of thumb: run JEDEC profiles on servers, CI runners and machines that sign or build releases. If a workstation runs XMP or EXPO, validate it with a long memory test after every firmware update or module change.

How to read DDR5 details on Linux and Windows

The commands below only read information. None of them change memory settings, and none of them write to the SPD. Several need root because SMBIOS tables and I2C devices are restricted.

Step 1: list modules from SMBIOS (Linux)

# Memory devices (SMBIOS type 17) and memory arrays (type 16)
sudo dmidecode --type memory

# Only the fields most people need
sudo dmidecode -t 17 | grep -E 'Locator|Size|Type:|Speed|Manufacturer|Part Number|Rank|Total Width|Data Width|Configured Voltage'

Look for Type: DDR5, Configured Memory Speed, and the two widths. If Total Width is larger than Data Width (for example 80 bits against 64), the module has side-band ECC; if they match, it does not. The dmidecode manual warns that SMBIOS information is supplied by firmware and is "possibly unreliable," and that it can describe what a board supports rather than what is installed. Treat it as a strong hint, then confirm with EDAC.

Step 2: read the SPD hub and module temperature (Linux)

# Load the DDR5 SPD hub driver (mainline Linux)
sudo modprobe spd5118

# Temperature readings appear through hwmon
sensors | grep -A3 spd5118

# Raw SPD contents for the module at I2C address 0x50 on bus N
ls /sys/bus/i2c/drivers/spd5118/
sudo hexdump -C /sys/bus/i2c/devices/N-0050/eeprom | head

Many boards block access to the memory SMBus from the OS, in which case the driver binds to nothing and you should rely on SMBIOS instead. decode-dimms from i2c-tools can turn SPD bytes into readable text, but the Debian manual page for it describes DDR4 support through the ee1004 driver and does not mention DDR5. Check that your i2c-tools version decodes DDR5 SPD before trusting its output.

Step 3: confirm ECC is real and counting (Linux)

# Is an EDAC driver loaded for this memory controller?
ls /sys/devices/system/edac/mc/
cat /sys/devices/system/edac/mc/mc0/mc_name

# Per-DIMM labels, type and error counts
grep . /sys/devices/system/edac/mc/mc*/dimm*/dimm_label
grep . /sys/devices/system/edac/mc/mc*/dimm*/dimm_mem_type
grep . /sys/devices/system/edac/mc/mc*/dimm*/dimm_ce_count
grep . /sys/devices/system/edac/mc/mc*/dimm*/dimm_ue_count

# Controller totals, and errors the driver could not attribute to a DIMM
cat /sys/devices/system/edac/mc/mc*/ce_count /sys/devices/system/edac/mc/mc*/ce_noinfo_count

The kernel's RAS guide calls the per-DIMM corrected error count "very important to examine" because corrected errors give early warning that a module is starting to fail. If /sys/devices/system/edac/mc/ is empty on a machine you believe has ECC modules, either the platform does not support ECC with those modules, ECC is disabled in firmware, or no EDAC driver exists for the controller. All three mean you have no visibility.

The EDAC core can also log each corrected error to the kernel log. The edac_mc_log_ce parameter controls that; with panic_on_ue set, an uncorrected error halts the system instead of letting it continue with bad data, which the kernel guide notes means the uncorrected counter will never increment.

Step 4: keep a history with rasdaemon (Linux)

# Debian and Ubuntu
sudo apt install rasdaemon
# Fedora and RHEL family
sudo dnf install rasdaemon

sudo systemctl enable --now rasdaemon

# Summaries from the recorded database
sudo ras-mc-ctl --summary
sudo ras-mc-ctl --errors

rasdaemon listens to kernel RAS trace events, including EDAC memory errors, and can record them to a SQLite database by default when run with recording enabled. That gives you history across reboots, which raw sysfs counters do not.

Step 5: list modules on Windows

Get-CimInstance Win32_PhysicalMemory |
  Select-Object DeviceLocator, Manufacturer, PartNumber, Capacity,
                SMBIOSMemoryType, ConfiguredClockSpeed, ConfiguredVoltage,
                DataWidth, TotalWidth |
  Format-Table -AutoSize

Notes from Microsoft's class documentation:

• MemoryType is a CIM value whose documented list stops at DDR4. Use SMBIOSMemoryType, the raw SMBIOS value, and look it up in the DMTF SMBIOS specification's memory type table.
• ConfiguredVoltage is in millivolts, so a JEDEC DDR5 module reports about 1100. A higher figure usually means an XMP or EXPO profile is active.
• TotalWidth includes error correction bits; when there are none it should equal DataWidth. That is the quickest ECC check on Windows.
• ConfiguredClockSpeed, ConfiguredVoltage and SMBIOSMemoryType need Windows 10 or Windows Server 2016 or later.

Microsoft documents the clock field in megahertz. Compare the figure with the module's rated transfer rate on its label rather than assuming the unit firmware used.

Step 6: watch for memory errors on Windows

Corrected and uncorrected hardware errors on Windows are reported through the Windows Hardware Error Architecture and appear in the System event log from the WHEA-Logger source. A simple fleet query:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'Microsoft-Windows-WHEA-Logger' } -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

A steady trickle of corrected memory errors from one slot is the same signal as a rising dimm_ce_count on Linux: plan to replace that module.

MRDIMM, CAMM2 and what comes after DDR5

MRDIMM for servers

JEDEC's 22 July 2024 announcement described the DDR5 Multiplexed Rank DIMM as a way to exceed RDIMM data rates by combining signals from more than one rank over the same channel. Planned features included platform compatibility with RDIMM, reuse of standard DDR5 parts (DRAM, form factor, pinout, SPD, PMIC and temperature sensors), the same reliability, availability and serviceability features as RDIMM, and a target of doubling bandwidth to 12.8 Gbps. JEDEC also described a taller MRDIMM form factor to fit twice the number of DRAM packages without 3D stacking.

From a security and operations view, MRDIMM inherits everything in this guide: on-die ECC, side-band ECC, the PMIC and the SPD hub. Your monitoring does not change; the number of modules per failure domain might.

CAMM2 for laptops and compact desktops

JESD318, published 5 December 2023, defines Compression Attached Memory Modules for both DDR5 and LPDDR5/5X in one document. JEDEC says DDR5 CAMM2s are intended for performance notebooks and mainstream desktops, and LPDDR5/5X CAMM2s for a broader range of notebooks and some server segments. The two share a connector design but have different pinouts, and mounting differences stop you fitting the wrong kind. The standard also allows stacking two single-channel modules at different heights (2.85 mm and 7.5 mm).

For fleet owners the useful change is that CAMM2 brings replaceable memory back to thin laptops that would otherwise solder LPDDR to the board. A replaceable module is a repairable failure.

After DDR5

In the same July 2024 release JEDEC said its JC-45 committee was developing a CAMM for LPDDR6 targeting more than 14.4 GT/s, with a 24-bit subchannel and a 48-bit channel. We could not confirm a published JEDEC DDR6 standard on JEDEC's public pages while writing this. Treat DDR6 speeds and dates you see online as forecasts until JEDEC announces publication. PRAC is the part most likely to carry forward: JEDEC's JC-42 chair said in April 2024 that "work is underway to incorporate this feature into other DRAM product families."

What a buyer or fleet owner should check

Decision table: which DDR5 for which machine

Checklist

1. Confirm side-band ECC end to end. The module, the CPU and the motherboard all have to support it, and firmware must enable it. Check Total Width against Data Width, then confirm EDAC or WHEA reporting works.
2. Collect corrected error counts centrally. A single corrected error is normal over a long life. A rising count on one DIMM is a replacement ticket.
3. Track firmware. Refresh rate options, Rowhammer mitigations and memory training fixes ship in BIOS and UEFI updates. NIST SP 800-193 frames platform firmware around protection, detection and recovery; memory configuration lives inside that firmware, so it belongs in the same update process. Our motherboard evolution guide covers how BIOS, UEFI and the BMC fit together.
4. Record module part numbers and manufacture dates. CVE-2025-6202 is scoped by manufacturer and production date range. You can only answer "are we affected" if you know which modules you have.
5. Keep overclocking profiles off servers and build hosts. Check ConfiguredVoltage or Configured Voltage for values above 1.1 V.
6. Watch module temperature where you can read it. A slot that runs much hotter than its neighbours is an airflow problem that can become an error problem.
7. Ask your hardware vendor about PRAC and refresh settings. PRAC needs both DRAM and controller support. Ask whether your platform supports it and what refresh options firmware exposes.
8. Mix modules carefully. Two different kits can train at the slower one's timings or fail to train at all, especially with XMP or EXPO. Buy matched kits for production.

If you are building or speccing a machine, our guide on how a desktop PC is made walks through component choices.

Where Safeguard fits, honestly

Safeguard does not inspect memory modules, read SPD data, scan firmware or manage devices, and none of the checks above run inside it. The fit is narrower and indirect: the tools you use to watch memory health are software. rasdaemon, i2c-tools, dmidecode, lm-sensors, the exporters that ship counters to your monitoring system, and the container images those agents run in are open source components with their own dependencies and vulnerabilities. Safeguard can scan the repositories and images where you build and package that tooling, show which projects carry a given component version, and open fix pull requests when a patched version exists. That keeps the software side of your hardware monitoring current; the DRAM, its firmware and its mitigations still come from your hardware and platform vendors.

Common mistakes

• Treating on-die ECC as ECC. "DDR5 has ECC" does not mean a non-ECC DDR5 stick protects the bus or reports errors. Only side-band ECC does that.
• Buying ECC modules for a platform that ignores them. Some client boards accept ECC UDIMMs but run them without ECC. Verify with EDAC or WHEA, not the module label.
• Assuming no EDAC errors means healthy memory. An empty /sys/devices/system/edac/mc/ means no visibility, not no errors.
• Running XMP or EXPO on build and signing hosts. Profile instability produces silent bit errors that look like flaky software.
• Believing DDR5 ended Rowhammer. Phoenix flipped bits on every module it tested from one maker. Mitigations reduce risk; they did not remove it.
• Waiting for PRAC before doing anything. Firmware updates, refresh settings and ECC monitoring are available today.
• Mixing RDIMM and UDIMM, or different kits. They are electrically different, with different PMIC input voltages, and mixed kits can fail training.
• Not recording part numbers. Without them you cannot match a CVE scoped by vendor and production date.

FAQ

Is DDR5 on-die ECC the same as ECC memory?

No. On-die ECC corrects single-bit errors inside each DRAM chip before data leaves it. ECC memory, meaning side-band ECC, adds extra check bits on the bus and lets the memory controller correct errors anywhere between the cells and the CPU, and report them to the operating system. Every DDR5 chip has on-die ECC; only ECC modules have side-band ECC.

Does DDR5 stop Rowhammer?

No. DDR5 adds standard tools, RFM and since April 2024 PRAC, that make Rowhammer harder. Published research flipped bits on DDR5: 1 of 10 devices in ZenHammer (2024) and all 15 tested SK hynix DIMMs in Phoenix (2025).

What is PRAC in DDR5?

Per Row Activation Counting, added in JEDEC JESD79-5C on 17 April 2024. The DRAM counts activations for each row and signals the memory controller when a row gets close to a dangerous count, and the controller then gives the DRAM time to refresh nearby rows.

What is the difference between RFM and PRAC?

RFM is a command that gives the DRAM time to refresh rows at risk; the controller decides when to send it, usually after counting activations to a bank. PRAC adds exact per-row counters inside the DRAM and an alert that tells the controller when to send RFM. PRAC uses RFM as its response.

Why does DDR5 have a PMIC on the module?

JEDEC moved voltage regulation onto the DIMM so each module brings its own regulator, sits closer to the chips at 1.1 V, and reports voltage, current, power and temperature over its management bus. TI says the module input is 5 V or 12 V depending on the variant, and client PMICs are specified for about 5 V.

Is it safe to enable XMP or EXPO?

It is a supported feature, but both Intel and AMD say running memory outside their specifications can void warranties, and AMD lists data corruption among the risks. For gaming PCs it is common. For servers, CI runners and build or signing machines, stay on JEDEC profiles.

How do I check if my DDR5 has ECC on Linux?

Run sudo dmidecode -t 17 and compare Total Width with Data Width; a larger total means extra ECC bits. Then check that /sys/devices/system/edac/mc/ lists a memory controller with per-DIMM dimm_ce_count files. Both must be true for working ECC.

Are DDR5 modules affected by CVE-2025-6202?

The NVD record covers SK hynix DDR5 on x86, for DIMMs produced from January 2021 until December 2024. Check your module part numbers and manufacture dates, apply firmware updates from your system vendor, and consider higher refresh settings where firmware offers them.

What comes after DDR5?

For servers, MRDIMM extends DDR5 bandwidth. For laptops, CAMM2 brings replaceable DDR5 and LPDDR5/5X modules, and JEDEC is developing an LPDDR6 CAMM. We could not confirm a published JEDEC DDR6 standard at the time of writing.

Fix it without waiting for upstream

Memory hardware is not a software dependency, but the machines it sits in run plenty of open source: Linux EDAC drivers, rasdaemon, i2c-tools, dmidecode, firmware update tooling and the monitoring agents that collect error counts, all of which get rebuilt and reinstalled when you replace a server or reimage a workstation. Keeping those components patched is the part of this topic where software supply chain hygiene applies directly, and the honest limit is that DRAM, its TRR logic and platform firmware fixes still come from your hardware vendors. Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos touches memory hardware. They show how Safeguard keeps the open source software around your fleet tooling current, which is the honest overlap with this topic. To try the CLI, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Point the same flow at the repository where you keep your memory health tooling, such as rasdaemon configuration, exporters and the scripts that collect EDAC and WHEA counts, to see which of their dependencies carry known vulnerabilities.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. Asked to fix the lodash CVE in a repo, it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. The same approve-each-step pattern applies when you bump a vulnerable library inside a monitoring agent or dashboard.

Click through it at your own pace, or open it full screen.

The third demo shows the desktop app sending work to a computer running the CLI, with each command approved before it runs. That suits a lab or build host where you want a person to approve every change, the same caution this guide recommends for memory settings on those machines.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• JEDEC: JEDEC Publishes New DDR5 Standard (JESD79-5), 14 July 2020, as republished by Design & Reuse
• JEDEC: JEDEC Publishes Update to DDR5 SDRAM Standard (JESD79-5A), 26 October 2021, as republished by Design & Reuse
• JEDEC: JEDEC Updates JESD79-5C DDR5 SDRAM Standard, 17 April 2024, as republished by Design & Reuse
• JEDEC: JEDEC Publishes New CAMM2 Memory Module Standard (JESD318), 5 December 2023, as republished by Design & Reuse
• JEDEC: JEDEC Unveils Plans for DDR5 MRDIMM and LPDDR6 CAMM Standards, 22 July 2024, as republished by Design & Reuse
• Micron: Introducing Micron DDR5 SDRAM, More Than a Generational Update (white paper)
• Micron: DDR5 SDRAM New Features (white paper)
• Texas Instruments: Suggested DC/DC Converters and PMIC for Powering DDR5, LPDDR5, and LPDDR5X Memory (SBAA792)
• Renesas: P8911 DDR5 Client PMIC for UDIMMs and SODIMMs
• Renesas: P8900 PMIC for DDR5 RDIMMs and LRDIMMs
• ETH Zurich COMSEC: Phoenix, Rowhammer on DDR5
• ETH Zurich COMSEC: ZenHammer
• NVD: CVE-2025-6202
• Canpolat et al.: Chronus, Understanding and Securing the Cutting-Edge Industry Solutions to DRAM Read Disturbance (HPCA 2025)
• When Mitigations Backfire: Timing Channel Attacks and Defense for PRAC-Based RowHammer Mitigations (ISCA 2025)
• Per-Row Activation Counting on Real Hardware: Demystifying Performance Overheads
• Linux kernel: EDAC driver API
• Linux kernel: Reliability, Availability and Serviceability (RAS) admin guide
• Linux kernel: spd5118 hwmon driver
• Debian manual page: dmidecode(8)
• Debian manual page: decode-dimms(1)
• rasdaemon project
• Microsoft Learn: Win32_PhysicalMemory class
• Intel: Extreme Memory Profile (XMP)
• AMD: EXPO Technology
• NIST SP 800-193: Platform Firmware Resiliency Guidelines

Last reviewed: 23 October 2026. JEDEC revises DDR5 regularly and memory mitigations ship through firmware; check the linked standards, research pages and your platform vendor's notes for the latest status.