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.
- CVSS v3 base score: 5.5 (Medium severity)
Proof of Concept (PoC)
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.
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
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.
zrammodule is not (yet) very widely used, i.e. not loaded by default on many distributions.
- 2015-05: zram
hot_addfeature is proposed. (LKML)
hot_addsupport 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
NOTEis added in a source comment about the unusual “read-to-create” behavior. (git)
- 2017-06: a project-wide rework unwittingly breaks
zrambuild is fixed. This results in undoing the previous permission fix. (git)
- 2020-06: permissions bits on
hot_addare 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)