A flaw was discovered in processing setsockopt for 32 bit processes on 64 bit systems. This flaw will allow attackers to alter arbitary kernel memory when unloading a kernel module. This action is usually restricted to root-priveledged users but can also be leveraged if the kernel is compiled with CONFIG_USER_NS and CONFIG_NET_NS and the user is granted elevated priveledges. This flaw was introduced in commit 52e804c6dfaa, Upstream fixes http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ce683e5f9d04 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e94e0cfb088 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bdf533de6968 Discussion on oss-sec: http://www.openwall.com/lists/oss-security/2016/06/24/5
Public via: http://seclists.org/oss-sec/2016/q2/599
Statement: This issue affects the Linux kernels as shipped with Red Hat Enterprise Linux 7, MRG-2 and realtime and will be addressed in a future update.
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1350769]
kernel-4.6.3-300.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
kernel-4.4.14-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: MRG for RHEL-6 v.2 Via RHSA-2016:1883 https://rhn.redhat.com/errata/RHSA-2016-1883.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:1847 https://rhn.redhat.com/errata/RHSA-2016-1847.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:1875 https://rhn.redhat.com/errata/RHSA-2016-1875.html
Is the fix for RHEL6 still in the pipeline? Am I right in understanding that network namespaces need to be enabled before the vulnerability is exploitable?
*** Bug 1383265 has been marked as a duplicate of this bug. ***
The fix for EL6 is not in the pipeline, it was my misunderstanding of the code that marked it vulnerable and I have corrected that understanding in the statement. Sorry for any confusion Charlie Brady.