On a Debian Stretch and testing/Buster system with a current kernel and installed microcode I still see meltdown and spectre listed as bugs in /proc/cpuinfo.

However, running the spectre-meltdown-checker shows not vulnerable.

So I'm wondering what /proc/cpuinfo does show. Are these just the vulnerabilities for this cpu and will those always be listed despite having a patched system?


2 Answers 2


The intent of the “bugs” field in /proc/cpuinfo is described in the commit message which introduced it:

x86/cpufeature: Add bug flags to /proc/cpuinfo

Dump the flags which denote we have detected and/or have applied bug workarounds to the CPU we're executing on, in a similar manner to the feature flags.

The advantage is that those are not accumulating over time like the CPU features.

Previously, hardware bugs that the kernel detected were listed as separate features (e.g. the infamous F00F bug, which has its own f00f_bug entry in /proc/cpuinfo on 32-bit x86 systems). The “bugs” entry was introduced to hold these in a single feature going forwards, in the same style as x86 CPU flags.

As far as what the entries mean in practice, as you can see in the message, all that’s guaranteed is that the kernel detected a hardware bug. You’ll need to look elsewhere (boot messages, or specific /proc entries or /sys entries such as the files in /sys/devices/system/cpu/vulnerabilities/) to determine whether the issues are dealt with.

The usefulness of the “bugs” entries is limited in two ways. The first is that true negatives can’t be distinguished from unknowns: if the field doesn’t specify “cpu_meltdown”, you can’t know (just from the field) whether that means that the kernel doesn’t know about Meltdown, or that your CPU isn’t affected by Meltdown. The second is that the detection can be too simplistic; it errs on the side of caution, so it might report that your CPU is vulnerable when it isn’t. Because the “detection” is table-driven, its accuracy depends on which version of the kernel you’re running.

In the case of Meltdown and Spectre bugs, the detection process which feeds the values in /proc/cpuinfo works as follows, on x86:

  • 4
    In the case of spectre and meltdown they're not even detected but just assumed. I have an in-order x86 that's not affected by either, but the kernel just reports that it is anyway because of a hardcoded rule that basically says "any Intel cpu older than X without a microcode patch applied is vulnerable to meltdown". Jul 16, 2018 at 0:30
  • 2
    @R.. is your CPU included in the in-order tables in the kernel? (Look for “cpu_no_speculation” here to see the latest tables.) That is indeed one of the problems with the “bugs” entry wrt. Meltdown, Spectre and co., its accuracy really depends on how recent your kernel is since their “detection” is table-driven. Jul 16, 2018 at 8:45
  • 1
    No, it's a Centerton Bonnell and it's missing from there. I'll see about submitting a patch. Jul 16, 2018 at 15:18
  • Does anyone know if this is still correct when microcode updates have been applied during boot but after loading the kernel?
    – Bachsau
    Aug 4, 2019 at 12:48

The Meltdown/Spectre vulnerabilities are on the CPU chipset design/architecture, and short of buying new future hardware, the patches are a nice illusion of security over the long term. New methods of exploiting the flaws might surface over time that are able to bypass the current patches.

In short, the current software patches/microcode mitigate the problems against known methods of Spectre/Meltdown family of exploits, but do not solve the underlying CPU design problems that allow them in the first place. The affected (several generations) of CPUs have not stopped being vulnerable in the long run (and most probably never will).

However, as @Gilles correctly states, having that warning does not mean the current known exploits Spectre/Meltdown methods will work; they won't work if the patches are installed.

In the case mentioned in the question, the kernel is only checking for the CPU models known to be affected by Spectre/Meltdown (all x86 CPUs for now if we are talking only about x86), and hence the cpu-insecure still being listed in the bug section/line in /proc/cpuinfo.

Go check your /proc/cpuinfo. It will contain cpu_insecure if your kernel has the KPTI patch

I've found that the KPTI patch has this piece of code:

   /* Assume for now that ALL x86 CPUs are insecure */

And after the kernel update, you get:

bugs      : cpu_insecure

PS. There was already a round of updates for a new method for exploiting the Spectre/Meltdown "bugs". It probably won't be the last time.

  • 2
    e.g. If you can hold off buying hw for a while, wait for a new generation of CPUs. My crystal ball tell me we will have a lot of 2nd hand servers selling for peanuts in the medium term. Jul 15, 2018 at 13:32
  • CPU bugs are listed in /proc/cpuinfo even if they are fully mitigated by a software patch. Their presence does not mean that your system is vulnerable to that particular bug. Jul 15, 2018 at 17:15
  • @Gilles granted, you wont be able to apply known exploits. However we had already already a round of exploits going around the 1st generation of patches, and I would venture to say there a lot of commercial interests out there silencing the critics of this being a fundamental design flaw that will force a major CPU redesign. Jul 15, 2018 at 17:25
  • 1
    That's true of Spectre/Meltdown-type exploits, they're fundamental design issues that will keep on giving. But you wrote that this is true of the bugs line shows, and this is just wrong. Most CPU design bugs have a full software workaround that only costs a little performance. If the kernel applies the workaround, then the bug is harmless. Jul 15, 2018 at 17:53
  • 1
    @Rui oh I think I didn’t express myself clearly enough — I meant that the article didn’t answer the question that its own title asked, not that it didn’t answer this question ;-). (As in, the article’s title is “How the industry-breaking Spectre bug stayed secret for seven months”, but the article doesn’t explain how IMO.) Jul 16, 2018 at 11:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .