It was reported that possible use-after-free vulnerability in keyring facility, possibly leading to local privilege escalation, was found. Function join_session_keyring in security/keys/process_keys.c holds a reference to the requested keyring, but if that keyring is the same as the one being currently used by the process, the kernel wouldn't decrease keyring->usage before returning to userspace. The usage field can be possibly overflowed causing use-after-free on the keyring object. Introduced by: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3a50597de8635cd05133bd12c95681c82fe7b878 References: http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/ Red Hat KCS article: https://access.redhat.com/articles/2131021 Upstream patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23567fd052a9abb6d67fe8e7a9ccdd9800a540f2
Acknowledgements: Name: the Perception Point research team
Statement: This issue does not affect the Linux kernels as shipped with Red Hat Enterprise Linux 5 and 6. Refer to https://access.redhat.com/node/2131021 for further information.
Created attachment 1116284 [details] prototype systemtap band-aid mk. e Further investigation with larger versions of the systemtap band-aid script suggest that the larger exploit manages somehow to increment the key refcount by 2 (!!) per iteration - one of which the stap band-aid does successfully roll back. The smaller exploit increments it by 1 per iteration, so after the band-aid application, the visible /proc/keys refcount stays static.
From lwn: https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=jessie-security&id=0ac8c3e88cf1ea329ede357f2a01a9b1a8734e24
Further experiments with the systemtap band-aid from comment #13 indicate: - fedora22 4.2.6-200.fc22.x86_64: stap band-aid works for both exploits (refcounts on /proc/keys fluctuates up & down during big exploit, within reasonable O(10000) ranges, then keyring is gc'd at exploit interrupt) - git linux + patch, no stap band-aid: identical behaviour - rhel7 3.10.0-327.4.4.el7.x86_64: stap band-aid works for both exploits, identical behaviour I can't explain my previous observations in comment #11; am suspecting that the rhel7 VM being tested was already subtly corrupted during prior testing. The new results are post-reboot. So, this appears to provide protection: # debuginfo-install kernel (or equivalent) # stap -vgt -Gfix_p=1 -Gtrace_p=0 cve20160728e.stp
Created attachment 1116563 [details] Proposed patch
External References: https://access.redhat.com/node/2131021
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:0065 https://rhn.redhat.com/errata/RHSA-2016-0065.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:0064 https://rhn.redhat.com/errata/RHSA-2016-0064.html
This issue has been addressed in the following products: MRG for RHEL-6 v.2 Via RHSA-2016:0068 https://rhn.redhat.com/errata/RHSA-2016-0068.html
kernel-4.3.3-303.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
kernel-4.3.4-200.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.1 EUS - Server and Compute Node Only Via RHSA-2016:0103 https://rhn.redhat.com/errata/RHSA-2016-0103.html