Linux kernel built with the hardware breakpoint(CONFIG_HAVE_HW_BREAKPOINT) support is vulnerable to a breakpoint address corruption issue. It could occur while modifying a h/w breakpoint via 'modify_user_hw_breakpoint' routine. An unprivileged user/process could use this flaw to crash the system kernel resulting in DoS OR to potentially escalate privileges on a the system. Upstream patches: ----------------- -> https://git.kernel.org/linus/f67b15037a7a50c57f72e69a6d59941ad90a0f0f -> https://git.kernel.org/linus/18ff57b220610a699947f20b156a8245ca7eee98 -> https://git.kernel.org/linus/705feaf321c37e4dca3637fd5cb3b275f17a06c9 Reference: ---------- -> http://www.openwall.com/lists/oss-security/2018/05/01/3
Acknowledgments: Name: Andy Lutomirski
Mitigation: To mitigate this issue: 1) Save the following script in a 'CVE-2018-1000199.stp' file. --- probe kernel.function("ptrace_set_debugreg") { if ($n < 4) $n = 4; /* set invalid debug register #, returns -EIO */ } probe begin { printk(0, "CVE-2018-1000199 mitigation loaded") } probe end { printk(0, "CVE-2018-1000199 mitigation unloaded") } --- 2) Install systemtap package and its dependencies # yum install -y systemtap systemtap-runtime # yum install -y kernel-devel kernel-debuginfo kernel-debuginfo-common 3) Build the mitigation kernel module as root. # stap -r `uname -r` -m cve_2018_1000199.ko -g CVE-2018-1000199.stp -p4 4) Load the mitigation module as root # staprun -L cve_2018_1000199.ko
Statement: This issue does not affect the versions of Linux kernel as shipped with Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6. This issue affects the version of the kernel package as shipped with Red Hat Enterprise Linux 7 and Red Hat Enterprise MRG 2. Future kernel updates for Red Hat Enterprise Linux 7 and Red Hat Enterprise MRG 2 may address this issue.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:1318 https://access.redhat.com/errata/RHSA-2018:1318
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.4 Extended Update Support Via RHSA-2018:1345 https://access.redhat.com/errata/RHSA-2018:1345
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.2 Advanced Update Support Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions Red Hat Enterprise Linux 7.2 Telco Extended Update Support Via RHSA-2018:1347 https://access.redhat.com/errata/RHSA-2018:1347
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.3 Extended Update Support Via RHSA-2018:1348 https://access.redhat.com/errata/RHSA-2018:1348
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:1355 https://access.redhat.com/errata/RHSA-2018:1355
This issue has been addressed in the following products: Red Hat Enterprise MRG 2 Via RHSA-2018:1354 https://access.redhat.com/errata/RHSA-2018:1354
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:1374 https://access.redhat.com/errata/RHSA-2018:1374
How can you validate that the patch made it on? I see the script and the articles, but can you validate with a version of the kernel? if I run uname -r and it comes back with 3.10.0-862.2.3.e17.x86_64 does that mean the system is not vulnerable anymore?
(In reply to Gadget from comment #18) > if I run uname -r and it comes back with > > 3.10.0-862.2.3.e17.x86_64 > does that mean the system is not vulnerable anymore? Yes, it does include the fix. Please note, Bugzilla is not for support queries. Please use proper support channel for future questions: -> https://access.redhat.com/ Thank you.