The current Meltdown Intel processor vulnerability is currently remedied by having the page table isolation enabled. There is a question how to turn this off: How to disable Page Table Isolation to regain performance lost due to Intel CPU security hole patch?

My question is opposite: is there a way to check on a running system whether the PTI mechanism is effective on the system and thus the system is protected? I'm specifically looking for cat /proc/something or cat /sys/something, not checking for kernel version or config parameter or the like.

7 Answers 7

  • Grepping CONFIG_PAGE_TABLE_ISOLATION in kernel config as Raniz's suggested does not help on desktop Ubuntu, but may help on cloud instances:

    grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \
    echo "patched :)" || echo "unpatched :("

  • You can check with /proc/cpuinfo as JonasCz suggested:

    grep -q "cpu_insecure\|cpu_meltdown\|kaiser" /proc/cpuinfo && echo "patched :)" \
    || echo "unpatched :("

  • Or from dmesg (thanks to Jason Creighton):

    dmesg | grep -q "Kernel/User page tables isolation: enabled" \
    && echo "patched :)" || echo "unpatched :("

  • You can compile test program from Raphael Carvalho for Meltdown detection:

    sudo apt-get install git build-essential
    cd /tmp
    git clone https://github.com/raphaelsc/Am-I-affected-by-Meltdown.git
    cd Am-I-affected-by-Meltdown
    sudo sh -c "echo 0  > /proc/sys/kernel/kptr_restrict"

on patched system it should end with output

so far so good (i.e. meltdown safe) ...

System not affected (take it with a grain of salt though as false negative
may be reported for specific environments; Please consider running it once again).

On patched system it should show the following:

Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

Do not install 4.4.0-108-generic on Xenial! It breaks boot/reboot/shutdown/suspend functionality!

Install 4.4.0-109-generic (see USN-3522-3 for details)!

As Robie Basak already wrote, there is a page about Spectre and Meltdown vulnerabilities status in Ubuntu.

Also there are:

  • 3
    Updates for Ubuntu are scheduled for Januari 9. They may land earlier but I wouldn't count on it. insights.ubuntu.com/2018/01/04/…
    – Raniz
    Commented Jan 5, 2018 at 6:48
  • 4
    The "dmesg | grep isolation" type answers are preferable to this, IMO. Some distributions (at least Debian stretch, maybe others) ported PTI to their older kernel, but not the cpu_insecure flag in /proc/cpuinfo. On those systems, looking in the dmesg log is the only way to check, AFAICT.
    – Jason C
    Commented Jan 6, 2018 at 18:03
  • 3
    I think the dmesg | grep isolation && echo "patched :)" || echo "unpatched :(" command as listed is unnecessarily dangerous: it doesn't show what line was actually matched, and would also happily print "patched :)" if a random other instance of "isolation" was matched... Commented Jan 6, 2018 at 20:24
  • 2
    I would recommend against the second suggestion (grepping /proc/cpuinfo for cpu_insecure). If you put that into a script and you have a CPU in the future where the problem is fixed in its microarchitecture, /proc/cpuinfo will no longer say cpu_insecure and your script will believe the kernel is unpatched even though it is patched. I would also recommend against the third suggestion, as it's too likely that there might be the word isolation in the dmesg output at some point without it referring to kernel page table isolation. Commented Jan 7, 2018 at 4:28
  • 4
    Upon further investigation, all three of these suggestions are broken. Grepping for isolation will match both Kernel/User page tables isolation: enabled and Kernel/User page tables isolation: disabled on command line.
    – Mark
    Commented Jan 7, 2018 at 7:31

Run the following command :

dmesg | grep 'page tables isolation'

If it displays enabled, then PTI is enabled. If nothing is displayed or you see 'disabled' in the terminal, then PTI is disabled. Ubuntu has not published the patch yet, so it won't display any message.

  • ... or later kernel messages have pushed the bootup messages out of the kernel log buffer. If your kernel prints notices for low-severity stuff like weird network packets, it's common for the boot-time messages to not be part of the dmesg output. See /var/log/kern.log* if it goes back far enough to have the boot messages. Ubuntu used to record boot-time dmesg output to /var/log/dmesg, but doesn't seem to do that anymore. Commented Jan 10, 2018 at 14:23
  • On 14.04, I got dmesg: invalid option -- 'w'. -H is also invalid. Removing the flags worked fine for me, as in this answer
    – wjandrea
    Commented Jan 11, 2018 at 20:14
  • /var/log/kern.log on 14.04
    – eckes
    Commented Jan 11, 2018 at 22:43

You can check with cat /proc/cpuinfo, if it reports cpu_insecure under "bugs", then PTI is enabled.

If it's blank (or just does not list cpu_insecure), then most likely you are running a kernel which has not yet been patched (Ubuntu's hasn't), or you have an AMD processor (for which this will forseeably not be enabled, since they're not vulnerable).

Currently all CPUs are treated as vulnerable in the latest 4.15 kernel.

  • 4.15 is not released yet to the public
    – Aadhil
    Commented Jan 4, 2018 at 8:25
  • It is, if you download the latest release candidate from kernel.org and compile it yourself. @Mohammedaadhil Commented Jan 4, 2018 at 8:28
  • 1
    A release candidate isn't a release.
    – Ruslan
    Commented Jan 4, 2018 at 15:36
  • The article you linked has been updated
    – nixpower
    Commented Jan 4, 2018 at 19:38
  • 2
    Kernel 4.14.11 will set cpu_insecure for any x86 CPU; 4.14.12 and newer will only set it for Intel CPUs (including ones too old or too primitive to be vulnerable. Both will set it even if KPTI is disabled.
    – Mark
    Commented Jan 7, 2018 at 5:38

You can run the command below to see all available mitigations (not only for PTI but also for other vulnerabilities) :

$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion
Mitigation: Clear CPU buffers; SMT vulnerable
Mitigation: PTI
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
  • Awesome answer - short and to the point. Thank you. Commented Sep 4, 2019 at 13:05

I found this great sh script to test Meltdown/spectre vulnerabilities on your system:


The script check your system to known Meltdown and spectre patchs on your system to tell you if these vulnerabilities are now mitigated by your OS


You can check /proc/config.gz for CONFIG_PAGE_TABLE_ISOLATION=y which means that the kernel was compiled with KPTI.

This is on my patched Arch Linux system running 4.14.11-1:

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz 
  • 3
    Unfortunately, the config of the currently running kernel in /proc/ is not enabled by default in Ubuntu kernels. The (much less elegant) workaround is grepping /boot/config-$( uname -r ) instead. Commented Jan 7, 2018 at 4:35
  • 5
    That only tells you if the kernel was compiled with KPTI, not if KPTI is active (it can be turned off at boot time, and possibly at runtime).
    – Mark
    Commented Jan 7, 2018 at 5:31
  • If you've explicitly disabled KPTI via kernel command line parameters you shouldn't need to check if it's active or not.
    – Raniz
    Commented Jan 16, 2018 at 7:53

On my AWS Ubuntu 14.04.5 LTS EC2 instance, I ran

grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)

It should say:


For update I did:

sudo apt-get update && sudo apt-get install linux-image-generic

I think also this is OK:

sudo apt-get update
sudo apt-get dist-upgrade

To check kernel version:

uname -r

Needs to be 3.13.0-139-generic or newer.

  • This method is already mentioned in the top answer
    – wjandrea
    Commented Jan 12, 2018 at 21:00

You must log in to answer this question.

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