Bugzilla – Bug 1176392
VUL-0: CVE-2020-25220: kernel-source: Use After Free vulnerability in cgroup BPF component
Last modified: 2020-10-01 06:15:19 UTC
It was found that the Linux kernel's use after free issue could happen during the usage of cgroupv2 (usually when reboot and more likely if virtual machine or docker being used). After recent commit 090e28b ("netprio_cgroup: Fix unlimited memory leak of v2 cgroups") was merged, the problem could be reproduced much simpler starting with 5.7.x kernels. The problem introduced with 4.5 kernel, but there is no known way to trigger it, so it was not known until 5.7 kernel. It could be possible to reproduce the bug by the user without privileges and without reboot if user has an ability to create/close cgroupv2 or this user create a process which is attached to already existing cgroupv2 BPF (but still the user will have to wait till root manually closes cgroupv2 or system is being rebooted). This commit fixes the problem: https://github.com/torvalds/linux/commit/94886c86e833dbc8995202b6c6aaff592b7abd24 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.194 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.140 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.233 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y&id=82fd2138a5ffd7e0d4320cdb669e115ee976a26e https://www.spinics.net/lists/stable/msg405099.html
Quick look -- it appears it's a mistake in the stable backports (stable-4.9, stable-4.14 and stable-4.19) I checked our backports into 4.12-based kernels (bug 1175213) and the fix is correct there, so no need for the fixup. I'll blacklist the CVE. (If I were to judge, the mistaken backport would not make the original use-after-free possible but it would cause a a possible memory leak.)
No of 4.12-based branches is affected by this CVE (there is correct refcounting in cgroup_sk_clone), so there is nothing to do [1]. Assigning back to the security team. [1] I'm not blacklisting CVE as no branch needs it and I'm not blacklisting the stable commit hash 1bfba2f4270c64c912756fc76621bbce959ddf2e neither since it won't show up in git-fixes.
marked all as not affected