I understand that /dev/kmem and /dev/mem provide access to the memory (i.e. raw RAM) of the system. I am also aware, that /dev/kmem can be completely disabled in kernel and that access can be restricted for /dev/mem.

It seems to me, having raw access to memory can be useful for developers and hackers, but why should I need access to memory through /dev/mem. AFAIK it cannot be disabled in kernel (unlike /dev/kmem). Having access to raw memory that can be potentially abused/exploited seems to me to be just asking for trouble.

Is there some practical use for it? Do any user programs require it to work properly?

  • 1
    lwn.net/Articles/147901 suggests that X server could use /dev/mem. Not sure that's still relevant. – Mat Apr 26 '14 at 9:00
  • This LJ article suggests the same thing: linuxjournal.com/magazine/anthony-lineberry-devmem-rootkits – slm Apr 26 '14 at 9:18
  • Did you disable loadable modules, too? Because that's even more dangerous than /dev/mem. Load a module, run code in kernel mode. And on top of that, hardening against attackers with root access is only worthwhile if there are things that root cannot do, which tends not to be the case in typical installations. – Gilles 'SO- stop being evil' Apr 26 '14 at 23:13
  • @Gilles - I am using cryptographically signed modules. Only modules signed with my private key can be loaded. – user1968963 Apr 27 '14 at 10:10
  • Additional to STRICT_DEVMEM described in man mem, write access to /dev/mem is disabled by kernel lockdown patches used to support "secure boot" (lockdown can be enabled without secure boot). phoronix.com/… – sourcejedi Jul 25 '17 at 21:09

There's a slide deck from Scale 7x 2009 titled: Undermining the Linux Kernel: Malicious Code Injection via /dev/mem that contained these 2 bullets.

Who needs this?

  • X Server (Video Memory & Control Registers)
  • DOSEmu

From everything I've found from search thus far it would appear that these 2 bullets are the front-runners for legitimate uses.


  • what if I don't run X server on my server, and thus do not need /dev/mem. Is there a way to disable /dev/mem in the kernel completely? I could only find "Filter access to /dev/mem" (CONFIG_STRICT_DEVMEM). – user1968963 Apr 26 '14 at 9:44
  • 1
    A modern X server, under Linux, is able to live without /dev/mem, as graphic cards have their own device node. That's the case with i915 for example. – jørgensen Jun 12 '14 at 15:38

It's worth noting that even if you disabled /dev/mem and /dev/kmem that memory can still be dumped; take a look at man proc to reveal /proc/kcore; it is the systems physical memory. A really good forensics toolkit rekall has a tool that does this already; it dumps the memory (and /boot files) so that they can be analyzed.

As a matter of fact, Ubuntu by default disables /dev/kmem:

There is no modern use of /dev/kmem any more beyond attackers using it to load kernel rootkits. CONFIG_DEVKMEM is set to "n". While the /dev/kmem device node still exists in Ubuntu 8.04 LTS through Ubuntu 9.04, it is not actually attached to anything in the kernel.

Ubuntu doesn't disable /dev/mem because its needed by applications.

Some applications (Xorg) need direct access to the physical memory from user-space. The special file /dev/mem exists to provide this access. In the past, it was possible to view and change kernel memory from this file if an attacker had root access. The CONFIG_STRICT_DEVMEM kernel option was introduced to block non-device memory access (originally named CONFIG_NONPROMISC_DEVMEM).

How to disable /proc/kcore?

Do not enable CONFIG_PROC_KCORE when building the kernel.

How do you disable /dev/mem?

Well, looking over man mem gives us some details about how its created:

mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

You should be able to just rm -rf /dev/mem; you can disable during kernel build phase by not enabling CONFIG_STRICT_DEVMEM.

How to disable /dev/kmem?

Ensure that CONFIG_DEVKMEM is not enabled upon kernel build.

How to prevent cold-boot attacks?

What if I was able to disable /proc/kcore, /dev/mem, /dev/kmem and then used an encrypted swap partition or didn't use swap at all? Well, your memory could just be freezed and accessed that way. How do you prevent this attack? You encrypt your RAM; how do you encrypt your RAM? You can't. See TRESOR for details.

  • I have disabled /dev/kmem in my kernel, and I don't see any /proc/kcore on my system. But I do have /dev/mem, and I would like to disable it. – Martin Vegter Jul 26 '17 at 14:40
  • There's typos in this answer. /proc/mem should be /dev/mem, similarly for /proc/kmem. – rlf Jul 31 '17 at 14:06
  • @bbb31 nice one. I thought there may have been a possibility that there was something I was missing. If that had been the case then I wanted to give you a chance to clarify. – rlf Jul 31 '17 at 16:36
  • "How do you prevent this attack? You encrypt your RAM; how do you encrypt your RAM? You can't." Note: In the future, you should be able to do it (at least on some types of hardware) - it's coming soon! lwn.net/Articles/776688 – 比尔盖子 May 4 '20 at 11:49

As you know, /dev/mem provides access to the physical memory of a running system. /dev/kmem provides access to kernel virtual memory. Both of these character devices can be persistently disabled through kernel configuration options (the code is the most authoritative source of information so it is used for reference). Unsetting the first two options below will disable the corresponding devices.

Depending on your distribution, your current kernel configuration can be seen using something like zless /proc/config.gz or less /boot/config-$(uname -r).

I think the initial intent of /dev/mem was to support interaction with memory-mapped peripherals. The obvious negative security implications of having these virtual devices available (e.g. an attacker being able to on the fly patch the memory of another process or even the kernel) have been known about for at least a decade. Restricting access to /dev/mem has been supported in the mainline kernel since early 2008, /dev/kmem has also been optional since around then too.

A decade ago it seems that X was reliant on /dev/mem, I don't think this is still true. To test the claims about X needing /dev/mem I deleted the virtual device from my laptop yesterday and it has been functioning seemingly perfect since. In 2017 there seems to be no practical use for these devices outside of research and doing development.

From a security perspective it is a good idea to remove these devices. It is still worth noting that a remote attacker, with elevated privileges, can read memory outside of its address space. Memory of other user space applications can be accessed using /proc/<pid>/mem. Kernel memory can be accessed using /proc/kcore.


I didn't include /dev/mem on my system from the start. I use Gentoo Linux, so this may come as no surprise, since with this Linux distribution you practically build every package yourself, including the Linux kernel.

I never noticed any problems due to the lack of /dev/mem, even when using X.org X11. Just today I noticed that an emerge of the package x11-drivers/xf86-video-vesa prints a message stating that it requires /dev/mem, like this:

* This driver requires /dev/mem support in your kernel
*   Device Drivers --->
*     Character devices  --->
*       [*] /dev/mem virtual device support

Since I didn't install the VESA driver for the XServer intentionally, or even if so only as a fallback I actually never ever had to use and therefore didn't notice it – until now.

But this proves the point that a) X11 doesn't need /dev/mem anymore, and b) that some X11 video drivers may still do anyway.

Newer video drivers for specific hardware will most likely work without it. Just like modern X.org-X11 (on Gentoo, x11-base/xorg-server) doesn't even have to be suid root anymore, that's what progress looks like...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.