A race condition was found in the way Linux kernel's memory subsystem handled breakage of the read only private mappings COW situation on write access. An unprivileged local user could use this flaw to gain write access to otherwise read only memory mappings and thus increase their privileges on the system. Red Hat is aware of this issue and if you have questions about the affectedness of your system please contact Red Hat Support. For additional information see https://access.redhat.com/security/vulnerabilities/2706661
Please note that this mitigation disables ptrace functionality which debuggers and programs that inspect other processes (virus scanners) use and thus these programs won't be operational. Also this mitigation works against the In The Wild (ITW) exploit we are aware of but most likely does not mitigate the issue as a whole. To mitigate the issue: 1) On the host, save the following in a file with the ".stp" extension: probe kernel.function("mem_write").call ? { $count = 0 } probe syscall.ptrace { // includes compat ptrace as well $request = 0xfff } probe begin { printk(0, "CVE-2016-5195 mitigation loaded") } probe end { printk(0, "CVE-2016-5195 mitigation unloaded") } 2) Install the "systemtap" package and any required dependencies. Refer to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux "SystemTap Beginners Guide" document, available from docs.redhat.com, for information on installing the required -debuginfo and matching kernel-devel packages 3) Run the "stap -g [filename-from-step-1].stp" command as root. If the host is rebooted, the changes will be lost and the script must be run again. Alternatively, build the systemtap script on a development system with "stap -g -p 4 [filename-from-step-1].stp", distribute the resulting kernel module to all affected systems, and run "staprun -L <module>" on those. When using this approach only systemtap-runtime package is required on the affected systems. Please notice that the kernel version must be the same across all systems.
Acknowledgements: Name: Phil Oester
[Edited 2016-10-26] At the time of public disclosure, the in the wild exploit that we were aware of did not work on Red Hat Enterprise Linux 5 and 6 out of the box because on one side of the race it writes to /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6. Since public disclosure several Proof of Concepts (POC) have been published, that use ptrace method, which do work on Red Hat Enterprise Linux 5 & 6. It should be noted that the mitigation (System Tap Script listed in comment #13) has been effective in blocking all currently known POC that have been published.
Upstream patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1387080]
Mitigation: Please see bug 1384344 comment #13 (https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13) for details on how to mitigate this issue.
(In reply to Petr Matousek from comment #16) > The in the wild exploit we are aware of doesn't work on Red Hat Enterprise > Linux 5 and 6 out of the box because on one side of the race it writes to > /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise > Linux 5 and 6. But it does work on RHEL 7?
While trying to install the systemtap mitigation, I got the following error until I installed the -debuginfo RPM for the kernels I was using. > semantic error: while resolving probe point: identifier 'syscall' at > /tmp/dirtycow.stp:5:7 > source: probe syscall.ptrace { // includes compat ptrace as well > ^ > > semantic error: no match I had to install kernel-devel-$(uname -r) systemtap kernel-debuginfo-$(uname -r) before I could get stap to build the module for me. The instructions in comment #13 do mention the -debuginfo package, but I had confused -devel and -debuginfo and was getting that error until I had both.
(In reply to Drew Sears from comment #21) > (In reply to Petr Matousek from comment #16) > > The in the wild exploit we are aware of doesn't work on Red Hat Enterprise > > Linux 5 and 6 out of the box because on one side of the race it writes to > > /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise > > Linux 5 and 6. > > But it does work on RHEL 7? I just tested this, and the exploit works on 7.
I wasn't able to get this to work on RHEL 6.8 or 7.2: [erc@lhqseltstut02 root]$ ls -l foo -rw-r--r--. 1 root root 0 Oct 21 09:32 foo [erc@lhqseltstut02 root]$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo) [erc@lhqseltstut02 root]$ ./dirtyc0w foo m00000000000000000 mmap ffffffff madvise -100000000 procselfmem -100000000 [erc@lhqseltstut02 root]$ ls -l foo -rw-r--r--. 1 root root 0 Oct 21 09:32 foo Michael, how did you get it to work on RHEL7? What version are you running?
Getting the same result on Fedora 22: edwin.carp@7G32G72 ~$ ./dirtyc0w foo m00000000000000000 mmap ffffffff madvise -100000000 procselfmem -100000000 edwin.carp@7G32G72 ~$ ls -l foo -rw-r--r--. 1 root root 0 Oct 21 10:36 foo edwin.carp@7G32G72 ~$ cat foo edwin.carp@7G32G72 ~$ cat /etc/redhat-release Fedora release 22 (Twenty Two)
(In reply to Petr Matousek from comment #13) > Please note that this mitigation disables ptrace functionality which > debuggers and programs that inspect other processes (virus scanners) > use and thus these programs won't be operational. > > [skipping systemtap-based mitigation] I was able to reproduce the bug with centos/7 (the latest official Vagrant image of CentOS Linux 7), and I can also confirm that the SystemTap mitigation prevents the original exploit from working. There are two other POCs now linked from the dirtyc0w GitHub repo, but I didn't test if the SystemTap mitigation also stops them. As alternatives, I also tried to completely disable ptrace via "sesetbool -P deny_ptrace 1", as well as confining the test user as user_u. Neither of these stopped the exploit from working.
(In reply to Joel Smith from comment #23) > I had to install > > kernel-devel-$(uname -r) > systemtap > kernel-debuginfo-$(uname -r) > > before I could get stap to build the module for me. The instructions in > comment #13 do mention the -debuginfo package, but I had confused -devel and > -debuginfo and was getting that error until I had both. On CentOS 7.2, I had to get kernel-debuginfo and kernel-debuginfo-common from http://debuginfo.centos.org rather then the usual repos. Fairly large packages. The stap script appears to block the POC exploit. But when I killed the script with ctrl-C, and re-tried the POC, the VM my system was running on died. Prior to running stap, the POC appeared to work "normally" - obtained root and exited.
(In reply to Petr Matousek from comment #13) > 1) On the host, save the following in a file with the ".stp" extension: > > probe kernel.function("mem_write").call ? { > $count = 0 > } > > probe syscall.ptrace { // includes compat ptrace as well > $request = 0xfff > } > > probe begin { > printk(0, "CVE-2016-5195 mitigation loaded") > } > > > probe end { > printk(0, "CVE-2016-5195 mitigation unloaded") > } I think the script wants probe kernel.function("mem_write").return ? { $return = %{ -EIO %} } part added, for simply overwriting $count with 0 causes legitimate /proc/self/mem writers (if any) to loop forever inside the kernel unless SIGKILL is delivered; running $ for i in `seq 1 1024`; do echo > /proc/self/mem & done triggers resource consumption. (In reply to advax from comment #31) > (In reply to Joel Smith from comment #23) > > > I had to install > > > > kernel-devel-$(uname -r) > > systemtap > > kernel-debuginfo-$(uname -r) > > > > before I could get stap to build the module for me. The instructions in > > comment #13 do mention the -debuginfo package, but I had confused -devel and > > -debuginfo and was getting that error until I had both. > > On CentOS 7.2, I had to get kernel-debuginfo and kernel-debuginfo-common > from http://debuginfo.centos.org rather then the usual repos. Fairly large > packages. You can do # yum install systemtap yum-utils # debuginfo-install kernel-$(uname -r) to download and install.
Statement: This issue affects the Linux kernel packages as shipped with Red Hat Enterprise Linux 5, 6, 7 and MRG 2.x. This issue has been rated as having Important security impact. Updates for each affected version are in progress and will be released as soon as possible. Shipping versions of Fedora are affected and Fedora is aware of this flaw. For additional information about this flaw, please see https://access.redhat.com/security/vulnerabilities/2706661
(In reply to Tetsuo Handa from comment #32) > I think the script wants > > probe kernel.function("mem_write").return ? { > $return = %{ -EIO %} > } > > part added, for simply overwriting $count with 0 causes > legitimate /proc/self/mem writers (if any) to loop forever > inside the kernel unless SIGKILL is delivered; running > > $ for i in `seq 1 1024`; do echo > /proc/self/mem & done > > triggers resource consumption. I found that it is not looping forever inside the kernel, but for some reason can't be terminated by entering Ctrl-C from keyboard. When the script is running, I can terminate if /bin/echo but I can't terminate if shell's built-in echo. So, this seems to be a different problem. [kumaneko@localhost ~]$ /bin/echo > /proc/self/mem ^C [kumaneko@localhost ~]$ echo > /proc/self/mem ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C
Another exploit that doesn't rely on /proc/self/mem but on ptrace (should work on RHEL5/6) : https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c
(In reply to Tetsuo Handa from comment #32) > You can do > > # yum install systemtap yum-utils > # debuginfo-install kernel-$(uname -r) > > to download and install. On 7.2 this gives me debuginfo-install kernel-$(uname -r) Loaded plugins: product-id, rhnplugin This system is receiving updates from RHN Classic or Red Hat Satellite. enabling epel-debuginfo Could not find debuginfo for main pkg: kernel-3.10.0-327.36.2.el7.x86_64 No debuginfo packages available to install As a more general comment, it's absolutely insane that RedHat are basically silent on this matter, there is no visible timeline or information beyond references to the mitigation above which notes > Also this mitigation works against the In The Wild (ITW) exploit we are aware of but > most likely does not mitigate the issue as a whole. The other large distributions have been patched for days! What is the hold up?
(In reply to Ian Allison from comment #36) > (In reply to Tetsuo Handa from comment #32) > > You can do > > > > # yum install systemtap yum-utils > > # debuginfo-install kernel-$(uname -r) > > > > to download and install. > > On 7.2 this gives me > > debuginfo-install kernel-$(uname -r) > Loaded plugins: product-id, rhnplugin > This system is receiving updates from RHN Classic or Red Hat Satellite. > enabling epel-debuginfo > Could not find debuginfo for main pkg: kernel-3.10.0-327.36.2.el7.x86_64 > No debuginfo packages available to install On my RHEL 7.2 system, it works just fine. kernel-debuginfo and kernel-debuginfo-common-x86_64 come from the rhel-7-server-debug-rpms repo, and yum-plugin-auto-update-debug-info from the rhel-7-server-optional-rpms repo.
Hi Akemi, (In reply to Akemi Yagi from comment #37) > kernel-debuginfo and kernel-debuginfo-common-x86_64 come from the > rhel-7-server-debug-rpms repo, and yum-plugin-auto-update-debug-info from > the rhel-7-server-optional-rpms repo. It looks like my organization doesn't have the debuginfo channels on our satellite server. I guess I'll just have to wait. Thank you anyway! -Ian.
If it helps anybody, I made an Ansible role based off the work from https://gryzli.info/2016/10/21/protect-cve-2016-5195-dirtycow-centos-7rhel7cpanelcloudlinux/. The Ansible role is located at https://github.com/pgporada/ansible-role-cve. It's idempotent fwiw. I've run it across my fleet of servers running Cent7 with the latest kernel and haven't noticed any ill effects.
I am using kernel-ml 4.6.4-1 from elrepo, Centos 7.2.1511 When running debuginfo-install kernel-ml-$(uname -r) I get Could not find debuginfo for main pkg: kernel-ml-4.6.4-1.el7.elrepo.x86_64 There does not seem to be debuginfo packages for ml kernels from elrepo. When running stap I get: [root@CentOS-71-64-minimal dirtycow]# stap -g cow.stp semantic error: while resolving probe point: identifier 'syscall' at cow.stp:5:7 source: probe syscall.ptrace { // includes compat ptrace as well ^ semantic error: no match Pass 2: analysis failed. [man error::pass2] Any way to get around this?
(In reply to Ed Carp from comment #26) > I wasn't able to get this to work on RHEL 6.8 or 7.2: > > [erc@lhqseltstut02 root]$ ls -l foo > -rw-r--r--. 1 root root 0 Oct 21 09:32 foo [...] > [erc@lhqseltstut02 root]$ ./dirtyc0w foo m00000000000000000 > mmap ffffffff > [...] The file should have a > 0 size, otherwise mmap fails (-1).
(In reply to Michael Carlson from comment #24) > (In reply to Drew Sears from comment #21) > > (In reply to Petr Matousek from comment #16) > > > The in the wild exploit we are aware of doesn't work on Red Hat Enterprise > > > Linux 5 and 6 out of the box because on one side of the race it writes to > > > /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise > > > Linux 5 and 6. > > > > But it does work on RHEL 7? > > I just tested this, and the exploit works on 7. Does someone know why /proc/self/mem was made writable in RHEL7? Is this required by a RHEL package or some proprietary product? (or was this patch lost during the v7 cycle?)
(In reply to Karapuzo from comment #40) > I am using kernel-ml 4.6.4-1 from elrepo, Centos 7.2.1511 > > When running debuginfo-install kernel-ml-$(uname -r) I get > > Could not find debuginfo for main pkg: kernel-ml-4.6.4-1.el7.elrepo.x86_64 > > There does not seem to be debuginfo packages for ml kernels from elrepo. > Any way to get around this? Yes, just update your kernel-ml to the latest version (v4.8.4). It contains the upstream (kernel.org) patch that fixes the bug.
Hopefully RH has a patch today... One vulnerable WordPress install that allows a remote file upload and any server is rooted... All other vendors have patches available it seems...
(In reply to Laurentiu Pancescu from comment #30) > (In reply to Petr Matousek from comment #13) > > Please note that this mitigation disables ptrace functionality which > > debuggers and programs that inspect other processes (virus scanners) > > use and thus these programs won't be operational. > > > > [skipping systemtap-based mitigation] > > I was able to reproduce the bug with centos/7 (the latest official Vagrant > image of CentOS Linux 7), and I can also confirm that the SystemTap > mitigation prevents the original exploit from working. There are two other > POCs now linked from the dirtyc0w GitHub repo, but I didn't test if the > SystemTap mitigation also stops them. > > As alternatives, I also tried to completely disable ptrace via "sesetbool -P > deny_ptrace 1", as well as confining the test user as user_u. Neither of > these stopped the exploit from working. Your alternative way only work on CentOS 7 when i run this command (sesetbool -P deny_ptrace 1") on centos 5 or 6 i see this error : Boolean deny_ptrace is not defined do you have alternative way for centos 5 and 6 thanks
(In reply to Rahimian from comment #46) > (In reply to Laurentiu Pancescu from comment #30) > > Neither of these stopped the exploit from working. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Your alternative way only work on CentOS 7 No, it doesn't work in the sense of being a workaround for this bug, and I never claimed it would be an alternative solution (see above). > when i run this command (sesetbool -P deny_ptrace 1") on centos 5 or 6 i see > this error : > Boolean deny_ptrace is not defined > > do you have alternative way for centos 5 and 6 > thanks Disabling ptrace didn't prevent privilege escalation to root using this particular kernel bug in my own tests, therefore it is _NOT_ an alternative workaround. Petr's SystemTap workaround from comment #13 is the only reliable solution I'm aware of, until an updated kernel will be made available. Full disclosure: I am _not_ a kernel or SELinux expert and I don't work for RedHat.
(In reply to Mathieu Parent from comment #42) > (In reply to Michael Carlson from comment #24) > > (In reply to Drew Sears from comment #21) > > > (In reply to Petr Matousek from comment #16) > > > > The in the wild exploit we are aware of doesn't work on Red Hat Enterprise > > > > Linux 5 and 6 out of the box because on one side of the race it writes to > > > > /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise > > > > Linux 5 and 6. > > > > > > But it does work on RHEL 7? > > > > I just tested this, and the exploit works on 7. > > Does someone know why /proc/self/mem was made writable in RHEL7? Is this > required by a RHEL package or some proprietary product? (or was this patch > lost during the v7 cycle?) It wasn't due to any sort of proprietary product or RHEL package. Back in 2011, there was a commit to allow mem_write to be allowed again. Prior to that commit, there was a define of mem_write NULL. There was an initial security reason why it was blocked, but that was fixed. For more information on the commits I'm referring to, go here http://lists.openwall.net/linux-kernel/2011/03/03/54
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html
(In reply to Petr Matousek from comment #13) > Please note that this mitigation disables ptrace functionality which > debuggers and programs that inspect other processes (virus scanners) > use and thus these programs won't be operational. > > Also this mitigation works against the In The Wild (ITW) exploit we are > aware of but most likely does not mitigate the issue as a whole. > > To mitigate the issue: > > > 1) On the host, save the following in a file with the ".stp" extension: > > probe kernel.function("mem_write").call ? { > $count = 0 > } > > probe syscall.ptrace { // includes compat ptrace as well > $request = 0xfff > } > > probe begin { > printk(0, "CVE-2016-5195 mitigation loaded") > } > > > probe end { > printk(0, "CVE-2016-5195 mitigation unloaded") > } > > > 2) Install the "systemtap" package and any required dependencies. Refer > to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux > "SystemTap Beginners Guide" document, available from docs.redhat.com, > for information on installing the required -debuginfo and matching > kernel-devel packages > > 3) Run the "stap -g [filename-from-step-1].stp" command as root. > > If the host is rebooted, the changes will be lost and the script must be > run again. > > > Alternatively, build the systemtap script on a development system with > "stap -g -p 4 [filename-from-step-1].stp", distribute the resulting > kernel module to all affected systems, and run "staprun -L <module>" on > those. > When using this approach only systemtap-runtime package is required on > the affected systems. Please notice that the kernel version must be the same > across all systems. Hi when i run stap -g update.stp i see this error : semantic error: while resolving probe point: identifier 'syscall' at update.stp:5:7 source: probe syscall.ptrace { // includes compat ptrace as well ^ semantic error: no match Pass 2: analysis failed. [man error::pass2] how can i fix this error
(In reply to errata-xmlrpc from comment #49) > This issue has been addressed in the following products: > > Red Hat Enterprise Linux 7 > > Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html i updated my server kernel to 3.10.0-327.36.2.el7 but vulnerability until remained ./rh-cve-2016-5195_1.sh Your kernel is 3.10.0-327.36.2.el7.x86_64 which IS vulnerable. Red Hat recommends that you update your kernel. Alternatively, you can apply partial mitigation described at https://access.redhat.com/security/vulnerabilities/2706661 .
(In reply to Rahimian from comment #53) > (In reply to errata-xmlrpc from comment #49) > > This issue has been addressed in the following products: > > > > Red Hat Enterprise Linux 7 > > > > Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html > > i updated my server kernel to 3.10.0-327.36.2.el7 > > but vulnerability until remained > > ./rh-cve-2016-5195_1.sh > Your kernel is 3.10.0-327.36.2.el7.x86_64 which IS vulnerable. > Red Hat recommends that you update your kernel. Alternatively, you can apply > partial > mitigation described at > https://access.redhat.com/security/vulnerabilities/2706661 . You need to update to 3.10.0-327.36.3.el7.x86_64, which just came out today.
(In reply to Rahimian from comment #52) > (In reply to Petr Matousek from comment #13) > > Please note that this mitigation disables ptrace functionality which > > debuggers and programs that inspect other processes (virus scanners) > > use and thus these programs won't be operational. > > > > Also this mitigation works against the In The Wild (ITW) exploit we are > > aware of but most likely does not mitigate the issue as a whole. > > > > To mitigate the issue: > > > > > > 1) On the host, save the following in a file with the ".stp" extension: > > > > probe kernel.function("mem_write").call ? { > > $count = 0 > > } > > > > probe syscall.ptrace { // includes compat ptrace as well > > $request = 0xfff > > } > > > > probe begin { > > printk(0, "CVE-2016-5195 mitigation loaded") > > } > > > > > > probe end { > > printk(0, "CVE-2016-5195 mitigation unloaded") > > } > > > > > > 2) Install the "systemtap" package and any required dependencies. Refer > > to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux > > "SystemTap Beginners Guide" document, available from docs.redhat.com, > > for information on installing the required -debuginfo and matching > > kernel-devel packages > > > > 3) Run the "stap -g [filename-from-step-1].stp" command as root. > > > > If the host is rebooted, the changes will be lost and the script must be > > run again. > > > > > > Alternatively, build the systemtap script on a development system with > > "stap -g -p 4 [filename-from-step-1].stp", distribute the resulting > > kernel module to all affected systems, and run "staprun -L <module>" on > > those. > > When using this approach only systemtap-runtime package is required on > > the affected systems. Please notice that the kernel version must be the same > > across all systems. > > Hi > when i run stap -g update.stp i see this error : > > semantic error: while resolving probe point: identifier 'syscall' at > update.stp:5:7 > source: probe syscall.ptrace { // includes compat ptrace as well > ^ > > semantic error: no match > > Pass 2: analysis failed. [man error::pass2] > > how can i fix this error That issue usually occurs when you don't have the debuginfo RPM. Try this.. yum install --enablerepo='base-debuginfo' -y kernel-devel-$(uname -r) systemtap kernel-debuginfo-$(uname -r) kernel-devel-$(uname -r)
Just for the record: despite on-line noise to the contrary, unprivileged containers are not vulnerable to vDSO-based attacks. These require ptrace the cap for which is blocked in the OCI defaults.
It also works on Fedora 25 x64.
(In reply to sde from comment #35) > Another exploit that doesn't rely on /proc/self/mem but on ptrace (should > work on RHEL5/6) : > https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c Given this exploit works on at least RHEL 6 with 2.6.32-642.6.1.el6.x86_64, could somebody please comment when RHEL 6 (and 5) will receive updates? Additionally cross-filed case 01727522 on the Red Hat customer portal now.
(In reply to Robert Scheck from comment #60) > (In reply to sde from comment #35) > > Another exploit that doesn't rely on /proc/self/mem but on ptrace (should > > work on RHEL5/6) : > > https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c > Has anybody actually confirmed by personal experience that this or other exploits actually works on RHEL 5 or RHEL 6? It would be "nice" to have working examples to check if the mitigation is working on these systems.
(In reply to Christian Anthon from comment #61) > (In reply to Robert Scheck from comment #60) > > (In reply to sde from comment #35) > > > Another exploit that doesn't rely on /proc/self/mem but on ptrace (should > > > work on RHEL5/6) : > > > https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c > > > > Has anybody actually confirmed by personal experience that this or other > exploits actually works on RHEL 5 or RHEL 6? It would be "nice" to have > working examples to check if the mitigation is working on these systems. Yes, works on RHEL 5/6 that are not patched. Once patched, the vulnerability does not work.
(In reply to errata-xmlrpc from comment #49) > This issue has been addressed in the following products: > > Red Hat Enterprise Linux 7 > > Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html What plans for releasing fixed EL6 kernel?
(In reply to nucleo from comment #63) > (In reply to errata-xmlrpc from comment #49) > > This issue has been addressed in the following products: > > > > Red Hat Enterprise Linux 7 > > > > Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html > > What plans for releasing fixed EL6 kernel? Already available as 2.6.32-642.6.2.el6. See "Resolve" tab at https://access.redhat.com/security/vulnerabilities/2706661 .
(In reply to Tetsuo Handa from comment #64) > (In reply to nucleo from comment #63) > > (In reply to errata-xmlrpc from comment #49) > > > This issue has been addressed in the following products: > > > > > > Red Hat Enterprise Linux 7 > > > > > > Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html > > > > What plans for releasing fixed EL6 kernel? > > Already available as 2.6.32-642.6.2.el6. See "Resolve" tab at > https://access.redhat.com/security/vulnerabilities/2706661 . Although they say it is available, it doesn't appear to actually be available yet. Everything I tried still shows 2.6.32-642.6.1 as the latest kernel.
(In reply to Andrew Thomas from comment #65) > (In reply to Tetsuo Handa from comment #64) > > (In reply to nucleo from comment #63) > > > (In reply to errata-xmlrpc from comment #49) > > > > This issue has been addressed in the following products: > > > > > > > > Red Hat Enterprise Linux 7 > > > > > > > > Via RHSA-2016:2098 https://rhn.redhat.com/errata/RHSA-2016-2098.html > > > > > > What plans for releasing fixed EL6 kernel? > > > > Already available as 2.6.32-642.6.2.el6. See "Resolve" tab at > > https://access.redhat.com/security/vulnerabilities/2706661 . > > Although they say it is available, it doesn't appear to actually be > available yet. Everything I tried still shows 2.6.32-642.6.1 as the latest > kernel. Its available. If you're using RHEL6 you should be able to `yum update` at this point and it should update. Maybe you're using CentOS 6? If so, you're going to have to wait until they push and update to their repos. RHEL provides public SRPMs for all of their packages, and its definately in their SRPM Repo ( http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6.32-642.6.2.el6.src.rpm ) If you are running RHEL6, maybe try to clear your yum cache by running `yum clean all`
I am sorry, but speaking up as a paying RHEL customer, I still can not see the mentioned update 2.6.32-642.6.2.el6 on any of my systems, while each of the systems is directly connected to RHSM. It feels like the Red Hat CDN is not yet in sync or so. Interestingly the e-mail for RHSA-2016-2105 did not arrive here yet, too.
> > > > Although they say it is available, it doesn't appear to actually be > > available yet. Everything I tried still shows 2.6.32-642.6.1 as the latest > > kernel. > > Its available. If you're using RHEL6 you should be able to `yum update` at > this point and it should update. Maybe you're using CentOS 6? If so, > you're going to have to wait until they push and update to their repos. > > RHEL provides public SRPMs for all of their packages, and its definately in > their SRPM Repo ( > http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6. > 32-642.6.2.el6.src.rpm ) > > If you are running RHEL6, maybe try to clear your yum cache by running `yum > clean all` I am running RHEL6. Earlier today I used yum to update to kernel-2.6.32-642.6.1.el6.x86_64. I have been using "yum clean all" and yum update, but it says there are no updates available. I went to the Customer Portal Downloads area. It also shows that 2.6.32-642.6.1 is the latest, and 2.6.32-642.6.2 is not there.
(In reply to Andrew Thomas from comment #68) > > > > > > Although they say it is available, it doesn't appear to actually be > > > available yet. Everything I tried still shows 2.6.32-642.6.1 as the latest > > > kernel. > > > > Its available. If you're using RHEL6 you should be able to `yum update` at > > this point and it should update. Maybe you're using CentOS 6? If so, > > you're going to have to wait until they push and update to their repos. > > > > RHEL provides public SRPMs for all of their packages, and its definately in > > their SRPM Repo ( > > http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6. > > 32-642.6.2.el6.src.rpm ) > > > > If you are running RHEL6, maybe try to clear your yum cache by running `yum > > clean all` > > I am running RHEL6. Earlier today I used yum to update to > kernel-2.6.32-642.6.1.el6.x86_64. I have been using "yum clean all" and yum > update, but it says there are no updates available. > > I went to the Customer Portal Downloads area. It also shows that > 2.6.32-642.6.1 is the latest, and 2.6.32-642.6.2 is not there. Hi Andrew and David - please be aware that bugzilla is not a support tool. Additionally a LOT of people are cc'd on this bugzilla. The RHEL 6.8.z Errata is in progress - which explains why some are seeing it and others are not. When the push process is completed and sanity checked we then mark it formally as live. If you have specific issues that need investigating, please open a support case with Red Hat Support within the Customer Portal http://access.redhat.com/ - While right now, I assume it is because the bits are in-progress, there are multiple reasons (for fully live Errata/RPMs) for failure, and experienced members of our staff can help to diagnose the cause and appropriately report internally (if needed) to that team, or to assist specific customers with potentially local issues in the customers environment. Regards, Cliff
am i the only getting gpg error in both existing kernel 2.6.32-431.el6.x86_64 and 2.6.32.621 Src rpm kernel-2.6.32-642.6.2.el6.src.rpm + cp /root/rpmbuild/SOURCES/extrakeys.pub . + cat ### ### Now generating a PGP key pair to be used for signing modules. ### ### If this takes a long time, you might wish to run rngd in the background to ### keep the supply of entropy topped up. It needs to be run as root, and ### should use a hardware random number generator if one is available, eg: ### ### rngd -r /dev/hwrandom ### ### If one isn't available, the pseudo-random number generator can be used: ### ### rngd -r /dev/urandom ### + gpg --homedir . --batch --gen-key /root/rpmbuild/SOURCES/genkey gpg: WARNING: unsafe permissions on homedir `.' gpg: keyring `./secring.gpg' created gpg: keyring `./pubring.gpg' created gpg: WARNING: some OpenPGP programs can't handle a DSA key with this digest size ?
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.7 Extended Update Support Via RHSA-2016:2106 https://rhn.redhat.com/errata/RHSA-2016-2106.html
This issue has been addressed in the following products: MRG for RHEL-6 v.2 Via RHSA-2016:2107 https://rhn.redhat.com/errata/RHSA-2016-2107.html
tks guys
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2016:2105 https://rhn.redhat.com/errata/RHSA-2016-2105.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:2110 https://rhn.redhat.com/errata/RHSA-2016-2110.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.1 Extended Update Support Via RHSA-2016:2118 https://rhn.redhat.com/errata/RHSA-2016-2118.html
Thanks for the kernel updates for RHEL6 and RHEL7. When can we expect a fix for Red Hat Enterprise Linux RHEL5? We have dozens of live production systems on RHEL5 and need this fix asap. Hopefully it is being worked on with the same urgency? Thanks!
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.5 Advanced Update Support Red Hat Enterprise Linux 6.5 Telco Extended Update Support Via RHSA-2016:2120 https://rhn.redhat.com/errata/RHSA-2016-2120.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 5 Via RHSA-2016:2124 https://rhn.redhat.com/errata/RHSA-2016-2124.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 5.6 Long Life Via RHSA-2016:2127 https://rhn.redhat.com/errata/RHSA-2016-2127.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 5.9 Long Life Via RHSA-2016:2126 https://rhn.redhat.com/errata/RHSA-2016-2126.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.6 Extended Update Support Via RHSA-2016:2128 https://rhn.redhat.com/errata/RHSA-2016-2128.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.4 Advanced Update Support Via RHSA-2016:2133 https://rhn.redhat.com/errata/RHSA-2016-2133.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.2 Advanced Update Support Via RHSA-2016:2132 https://rhn.redhat.com/errata/RHSA-2016-2132.html
The bug is still not solved. With the following kernel release it's still possible to get root privileges from a normal linux user. [xxx@xxx xxx]# uname -a Linux xxx 2.6.32-642.11.1.el6.x86_64 #1 SMP Tue Nov 15 09:40:59 PST 2016 x86_64 x86_64 x86_64 GNU/Linux) Best Regards Stefano
(In reply to stefano gristina from comment #94) > The bug is still not solved. > > With the following kernel release it's still possible to get root privileges > from a normal linux user. > > [xxx@xxx xxx]# uname -a > Linux xxx 2.6.32-642.11.1.el6.x86_64 #1 SMP Tue Nov 15 09:40:59 PST 2016 > x86_64 x86_64 x86_64 GNU/Linux) > > Best Regards > > Stefano Hi Stefano, Can you please contact secalert with any details. To my knowledge this is not the case and maybe user error. But let us communicate with you in private to investigate the details. If you wish to use GPG - our details can be found here: https://access.redhat.com/security/team/contact/ Regards, Cliff
Done. Best Regards Stefano
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2017:0372 https://rhn.redhat.com/errata/RHSA-2017-0372.html
This comment was flagged a spam, view the edit history to see the original text if required.