Bugzilla – Bug 980265
VUL-0: CVE-2016-4794: kernel: Use after free in array_map_alloc
Last modified: 2020-06-11 12:18:16 UTC
rh#1335889 Use after free vulnerability was found in percpu using previously allocated memory in bpf. First __alloc_percpu_gfp() is called, then the memory is freed with free_percpu() which triggers async pcpu_balance_work and then pcpu_extend_area_map is hitting use-after-free. CVE request (contains reproducer): http://seclists.org/oss-sec/2016/q2/332 References: https://bugzilla.redhat.com/show_bug.cgi?id=1335889 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4794 http://seclists.org/oss-sec/2016/q2/336 http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-4794.html
bugbot adjusting priority
There are two patches by Tejun to be sent to mainline soon. Both are marked for stable backports for kernels 3.18+. SLE12/SP1 are based on 3.12 and don't have backported the 3.18 commits that introduced the bug. I have verified the code just to be sure and the races indeed don't seem to exist: - upstream tentative "percpu: fix synchronization between chunk->map_extend_work and chunk destruction" fixes commit 9c824b6a172c ("percpu: make sure chunk->map array has available space") The problem here is race between asynchronous pcpu_extend_area_map() and asynchronous pcpu_balance_work(). Our kernels don't have asynchronous pcpu_extend_area_map() so we are fine. - upstream tentative patch "percpu: fix synchronization between synchronous map extension and chunk destruction" fixes commit 1a4d76076cda ("percpu: implement asynchronous chunk population") This time it's problem with synchronous pcpu_extend_area_map() and asynchronous removal of the same chunk via pcpu_balance_work(). Our kernels don't have pcpu_balance_work(), but we do have pcpu_reclaim() which is similar and asynchronous. While the function pcpu_extend_area_map() is not fully under pcpu_lock spinlock (same with the upstream kernel), the race is still prevented by pcpu_alloc_mutex being held in both operations. This was broken in 3.18 and the upstream fix restores the same protection. So the conclusion is that the vulnerable kernels are: * SLE12-SP2 is not yet released. I can backport the fixes there once they hit mainline, but they will also come through longterm stable tree. * SLE12-SP1-ARM (and openSUSE-42.1) same story. No need for a live patch then.
thanks for the research! keeping open until sle12-sp2 and opensuse is fixed
This needs to be fixed before sles12 sp2 shipping if possible.
Patches backported and merged to SLE12-SP2 and openSUSE-42.1 branches. SLE12-SP1-ARM should automerge AFAIK.
openSUSE-SU-2016:1798-1: An update that solves four vulnerabilities and has 5 fixes is now available. Category: security (important) Bug References: 970114,970275,978469,980265,983977,984755,986362,986530,986572 CVE References: CVE-2016-4470,CVE-2016-4794,CVE-2016-4997,CVE-2016-5829 Sources used: openSUSE Leap 42.1 (src): kernel-debug-4.1.27-24.1, kernel-default-4.1.27-24.1, kernel-docs-4.1.27-24.2, kernel-ec2-4.1.27-24.1, kernel-obs-build-4.1.27-24.2, kernel-obs-qa-4.1.27-24.1, kernel-obs-qa-xen-4.1.27-24.1, kernel-pae-4.1.27-24.1, kernel-pv-4.1.27-24.1, kernel-source-4.1.27-24.1, kernel-syms-4.1.27-24.1, kernel-vanilla-4.1.27-24.1, kernel-xen-4.1.27-24.1
released, and fixed in GA