Meltdown: the processor flaw that opened protected memory
A design flaw in most Intel processors let any program read the operating system's protected memory. Why it scores only 5.6, and how the fix works.

What to do now
- Install your operating system’s updates: Windows, Linux, macOS and iOS received the fix around January 2018.
- If an old computer’s system no longer gets updates, run only programs you trust: any program can read the system’s memory.
- If you rent servers or run containers, ask your provider whether the host has the fix: containers and some virtual machines could read the host’s memory.
- Year
- 2018
- CVSS 3.0 score
- 5.6 medium
- kilobytes per second: how fast an ordinary program read kernel memory, depending on the machine
- 3.2–503
- days the flaw was kept secret while fixes were prepared
- 216
- Reach met
Potentially every Intel processor with out-of-order execution since 1995 is affected, except Itanium and Atom before 2013 (researchers' site). The paper shows the attack on Intel generations since 2010 (USENIX paper).
- Mass exploitation not met
No attacks in the wild are known, and the flaw is not on CISA's list of exploited vulnerabilities (Apple; NVD, October 2026).
- Damage not met
No damage has been documented.
- Extraordinary response met
Windows, Linux and macOS isolated kernel memory with updates around the disclosure, prepared during 216 days of secrecy (Microsoft; Apple; Google Project Zero).
| Affected | Most Intel processors and a few ARM-based designs |
|---|---|
| CVE | CVE-2017-5754 |
| CVSS vector | CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N |
| Weakness (CWE) | CWE-200 |
| Fixed in | Operating-system updates around the disclosure: KPTI in Linux, Windows KB4056892 (January 3, 2018), macOS 10.13.2 and iOS 11.2; newer processors fix it in hardware |
| Found by | Google Project Zero, Graz University of Technology and Cyberus Technology, independently of each other |
- 1Reported to the vendor
- 2Made public+216 days
- 3Windows update with the fix; Apple had already shipped its own+216 days
- 4The researchers present the full paper at USENIX Security 2018+440 days
On January 3, 2018, researchers made public a flaw that was not in software, but in processors themselves. On most Intel processors, any program could read the memory of the kernel, the core of the operating system. On many systems, it could read all of the computer’s memory. The fix had to come from the operating systems. Windows, Linux, and macOS changed how they handle memory around the same time.
How it worked
Modern processors do not wait for every check before they work. To save time, they run instructions ahead and out of order, and throw the results away if a check fails later.
On Intel processors, a program’s attempt to read kernel memory ran for a moment before the permission check stopped it. The forbidden value was then thrown away, but the program had already used it to touch one particular entry of a large table. That entry stayed in the cache, a small, fast memory inside the processor. The program then timed how fast each entry of the table loaded, using a method called Flush+Reload. This way, it learned the secret value. By repeating these steps, it could read all kernel memory, byte by byte, without any software bug and without special rights.
- Programasks for a byte of kernel memory
- Processorruns ahead before the permission check
- Cachekeeps a trace of the secret byte
- Timingreveals the byte, then the next
Which processors are affected
The researchers’ site says that potentially every Intel processor with out-of-order execution since 1995 is affected, except Itanium and Atom before 2013. Their paper shows the attack on Intel generations since 2010. Of ARM’s own processor designs, only the Cortex-A75 is affected. Samsung’s Exynos M1 also leaked data in tests. AMD stated that its processors are not affected, the paper says.
Because the flaw is in the hardware, the operating system does not matter. On shared servers, programs in containers, which share one operating system, could read the memory of the host. So could some kinds of virtual machines.
The attack is fast. The researchers read kernel and physical memory at 3.2 to 503 kilobytes per second, depending on the machine. Data that was already in the processor’s fastest cache, called L1, came out even faster, with an error rate as low as 0.003 %.
| Core i7-8700K, data in the L1 cache | 582 KB/s | |
|---|---|---|
| Core i7-6700K, data in the L1 cache | 569 KB/s | |
| Xeon E5-1630, data in the L1 cache | 491 KB/s | |
| Core i7-6700K, data only in the L3 cache | 12.4 KB/s | |
| Data in no cache, with optimizations | 3.2 KB/s |
Source: Meltdown paper, USENIX Security 2018. L1 and L3 are levels of the processor’s cache. Without the optimizations, data in no cache came out at less than 10 bytes per second on most systems.
Why a full memory read scores only 5.6
The NVD, the US National Vulnerability Database, rates Meltdown 5.6 out of 10 on version 3.0 of the CVSS scale: medium. That is not because the damage is small, but because of how the attack works. The attacker must already run a program on the computer, with ordinary user rights. The scale calls this a local attack. The attack is rated hard to carry out. And it can only read data, not change or delete it. Intel’s own advisory gives the same score. Shellshock, which works over the internet, scores 9.8.
The fix and the response
Google Project Zero reported the flaw to Intel, AMD, and ARM on June 1, 2017. Graz University of Technology and Cyberus Technology found it independently. For 216 days, the flaw was kept secret while operating-system makers prepared fixes.
The fix is called kernel page-table isolation (KPTI) and builds on a research design called KAISER. Page tables tell the processor which memory a program can see. KPTI removes the kernel’s memory from these tables while ordinary programs run. On January 3, 2018, Microsoft released the fix for Windows, for example in update KB4056892. Apple had already shipped fixes in iOS 11.2, macOS 10.13.2, and tvOS 11.2. Linux added KPTI. Newer processors fix the flaw in hardware.
The protection costs time on every switch between a program and the kernel. How much depends on the system and on which fixes a figure covers:
| Source | What it found | Fixes covered |
|---|---|---|
| Microsoft | Minimal impact | Meltdown and the first Spectre variant |
| Apple | No measurable reduction in macOS and iOS benchmarks | Meltdown |
| Red Hat | 8–19 % slower for the most affected workloads, 4–8 % after a later optimization called retpoline | Meltdown and both Spectre variants together |
Spectre is the name of the two other flaws in Google Project Zero’s report. Most of the slowdown on Windows came from the fix for the second Spectre variant, Microsoft says. Red Hat’s worst case applies to workloads with many switches into the kernel, such as databases that handle many small transactions. It does not show the cost of the Meltdown fix alone.
Read next: NotPetyaPrevious: SpectreOverview: Vulnerabilities