A vulnerability in the Linux kernel's keyrings garbage collector allowing any local user account to trigger a kernel panic. Problem arrises when using request_key() or keyctl request2. This code sequence tries to invoke an upcall to instantiate a keyring if one doesn't already exist by that name within the user's keyring set. However, if the upcall fails, the code sets keyring->type_data.reject_error to -ENOKEY or some other error code. When the key is garbage collected, the key destroy function is called unconditionally and keyring_destroy() uses list_empty() on keyring->type_data.link - which is in a union with reject_error. Subsequently, the kernel tries to unlink the keyring from the keyring names list, which leads to an oops.
Upstream patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ce1fad2740c648a4340f6f6c391a8a83769d2e8c
CVE request: http://seclists.org/oss-sec/2015/q4/111
Statement: This issue affects the Linux kernels as shipped with Red Hat Enterprise Linux 6 , 7 and Red Hat MRG 2. Future updates for the respective releases may address this flaw.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2015:2636 https://rhn.redhat.com/errata/RHSA-2015-2636.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:0212 https://rhn.redhat.com/errata/RHSA-2016-0212.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:0185 https://rhn.redhat.com/errata/RHSA-2016-0185.html
This issue has been addressed in the following products: MRG for RHEL-6 v.2 Via RHSA-2016:0224 https://rhn.redhat.com/errata/RHSA-2016-0224.html