Bug 1176392 - (CVE-2020-25220) VUL-0: CVE-2020-25220: kernel-source: Use After Free vulnerability in cgroup BPF component
VUL-0: CVE-2020-25220: kernel-source: Use After Free vulnerability in cgroup ...
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
Depends on:
  Show dependency treegraph
Reported: 2020-09-10 09:03 UTC by Marcus Meissner
Modified: 2020-10-01 06:15 UTC (History)
2 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2020-09-10 09:03:00 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:

Comment 3 Michal Koutný 2020-09-24 16:39:45 UTC
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.)
Comment 4 Michal Koutný 2020-09-29 17:02:09 UTC
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.
Comment 5 Marcus Meissner 2020-10-01 06:15:19 UTC
marked all as not affected