Peter Kjellström
2016-Oct-25 13:39 UTC
[CentOS] CVE-2016-5195 DirtyCOW : Critical Linux Kernel Flaw
On Tue, 25 Oct 2016 10:06:12 +0200 Christian Anthon <anthon at rth.dk> wrote:> What is the best approach on centos 6 to mitigate the problem is > officially patched? As far as I can tell Centos 6 is vulnerable to > attacks using ptrace.I can confirm that c6 is vulnerable, we're running a patched kernel (local build) using a rhel6 adaptation of the upstream fix. Ask off-list if you want an src.rpm /Peter K
Christian Anthon
2016-Oct-25 13:50 UTC
[CentOS] CVE-2016-5195 DirtyCOW : Critical Linux Kernel Flaw
On 25-10-2016 15:39, Peter Kjellstr?m wrote:> I can confirm that c6 is vulnerable, we're running a patched kernel > (local build) using a rhel6 adaptation of the upstream fix. > > Ask off-list if you want an src.rpmThanks, the srpm would be very helpful, I'll reply off-list. Cheers, Christian.
Leon Fauster
2016-Oct-25 17:26 UTC
[CentOS] CVE-2016-5195 DirtyCOW : Critical Linux Kernel Flaw
Am 25.10.2016 um 15:39 schrieb Peter Kjellstr?m <cap at nsc.liu.se>:> On Tue, 25 Oct 2016 10:06:12 +0200 > Christian Anthon <anthon at rth.dk> wrote: > >> What is the best approach on centos 6 to mitigate the problem is >> officially patched? As far as I can tell Centos 6 is vulnerable to >> attacks using ptrace. > > I can confirm that c6 is vulnerable, we're running a patched kernel > (local build) using a rhel6 adaptation of the upstream fix. > > Ask off-list if you want an src.rpmHi Peter, can you confirm that its this? http://pastebin.centos.org/56391/ -- LF
m.roth at 5-cent.us
2016-Oct-25 18:18 UTC
[CentOS] CVE-2016-5195 DirtyCOW : Critical Linux Kernel Flaw
My manager just told me that upstream has released a patched kernel for 7: CentOS package kernel-3.10.0-327.36.3.el7.x86_64.rpm see http://rhn.redhat.com/errata/RHSA-2016-2098.html I'm hoping Johnny can get us that, hopefully before the end of the week. mark
Phelps, Matthew
2016-Oct-25 18:58 UTC
[CentOS] CVE-2016-5195 DirtyCOW : Critical Linux Kernel Flaw
On Tue, Oct 25, 2016 at 2:18 PM, <m.roth at 5-cent.us> wrote:> My manager just told me that upstream has released a patched kernel for 7: > > CentOS package kernel-3.10.0-327.36.3.el7.x86_64.rpm > see http://rhn.redhat.com/errata/RHSA-2016-2098.html > > I'm hoping Johnny can get us that, hopefully before the end of the week. > > mark > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >That came out this morning: Johnny Hughes <johnny at centos.org> 7:17 AM (7 hours ago) to centos-announce CentOS Errata and Security Advisory 2016:2098 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-2098.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: afb7e2a7c3a38185b99f092b70ec274888a5beb136a7e5077559cbd29b3f55d7 kernel-3.10.0-327.36.3.el7.x86_64.rpm 1b33324ee4de14c03dde2eefb91bdee83082dd4ced6c0b94f5ab3253690bce38 kernel-abi-whitelists-3.10.0-327.36.3.el7.noarch.rpm 000ccd89b45a28645202add878b5e37d9a482df68fd5cf12914611098724eea7 kernel-debug-3.10.0-327.36.3.el7.x86_64.rpm 430e59db8a03d01f25ff602e766b96b06157fb881db68ca0cb81f229ec2609d6 kernel-debug-devel-3.10.0-327.36.3.el7.x86_64.rpm 5522697d3b016509dd3744e714d61e5d177921d2a045588730c1cd41713ba2c1 kernel-devel-3.10.0-327.36.3.el7.x86_64.rpm b3fb9f23b5a2427d90e286350b1e7ded8ce6c3c2c5f7e191ee15bb8a70c981aa kernel-doc-3.10.0-327.36.3.el7.noarch.rpm ad0006f10828ff8890c5599982c57a5ed75a9fdc9aab90e0c8cba6422eb766ea kernel-headers-3.10.0-327.36.3.el7.x86_64.rpm 3639553b0daacf8b577a5576d732eadae1aeef30cf61ca15dd755e439b5a8578 kernel-tools-3.10.0-327.36.3.el7.x86_64.rpm b66a1c39f21081605dc3f19afc73236b5cb23a1de8d1bd1b14718165663de7ac kernel-tools-libs-3.10.0-327.36.3.el7.x86_64.rpm 97f1708f020dc0c19c9abead5cabdf813aa56ffdf6f8956811669019d74980d8 kernel-tools-libs-devel-3.10.0-327.36.3.el7.x86_64.rpm 6101abe377f9c3f96f9a0b32840ccde2d60835af96ffbb1c787841e0a98bb755 perf-3.10.0-327.36.3.el7.x86_64.rpm cd55f641ed83faeb33d35a7915c78f85f58a237612ffebdfd5f41e652472ce7b python-perf-3.10.0-327.36.3.el7.x86_64.rpm Source: fc7d9058db4d12308f80993c446175e0fd45e413ffafa7b9b2b0c38a432a4a3c kernel-3.10.0-327.36.3.el7.src.rpm -- Matt Phelps System Administrator, Computation Facility Harvard - Smithsonian Center for Astrophysics mphelps at cfa.harvard.edu, http://www.cfa.harvard.edu
Akemi Yagi
2016-Oct-26 00:21 UTC
[CentOS] CVE-2016-5195 DirtyCOW : Critical Linux Kernel Flaw
On Tue, Oct 25, 2016 at 10:26 AM, Leon Fauster <leonfauster at googlemail.com> wrote:> Am 25.10.2016 um 15:39 schrieb Peter Kjellstr?m <cap at nsc.liu.se>: >> On Tue, 25 Oct 2016 10:06:12 +0200 >> Christian Anthon <anthon at rth.dk> wrote: >> >>> What is the best approach on centos 6 to mitigate the problem is >>> officially patched? As far as I can tell Centos 6 is vulnerable to >>> attacks using ptrace. >> >> I can confirm that c6 is vulnerable, we're running a patched kernel >> (local build) using a rhel6 adaptation of the upstream fix. >> >> Ask off-list if you want an src.rpm > > > Hi Peter, can you confirm that its this? > > http://pastebin.centos.org/56391/That is for the EL-7.2 kernel. Peter was offering a patch for CentOS 6. RH released the patched kernel for EL-6.8 today. I have attached the diff file between 2.6.32-642.6.1.el6 and 2.6.32-642.6.2.el6. It is more complex because the 6 kernel is older, so required more mods, I suppose. Maybe that was the reason why the EL-6 update took longer than EL-7. Akemi -------------- next part -------------- diff -uNpr linux-2.6.32-642.6.1.el6/include/linux/mm.h linux-2.6.32-642.6.2.el6/include/linux/mm.h --- linux-2.6.32-642.6.1.el6/include/linux/mm.h 2016-08-25 08:07:47.000000000 -0700 +++ linux-2.6.32-642.6.2.el6/include/linux/mm.h 2016-10-24 06:19:16.000000000 -0700 @@ -1420,6 +1420,7 @@ struct page *follow_page(struct vm_area_ #define FOLL_HWPOISON 0x100 /* check page is hwpoisoned */ #define FOLL_NUMA 0x200 /* force NUMA hinting page fault */ #define FOLL_MIGRATION 0x400 /* wait for page to replace migration entry */ +#define FOLL_COW 0x4000 /* internal GUP flag */ typedef int (*pte_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr, void *data); diff -uNpr linux-2.6.32-642.6.1.el6/mm/memory.c linux-2.6.32-642.6.2.el6/mm/memory.c --- linux-2.6.32-642.6.1.el6/mm/memory.c 2016-08-25 08:06:57.000000000 -0700 +++ linux-2.6.32-642.6.2.el6/mm/memory.c 2016-10-24 06:19:16.000000000 -0700 @@ -1177,6 +1177,24 @@ int zap_vma_ptes(struct vm_area_struct * } EXPORT_SYMBOL_GPL(zap_vma_ptes); +static inline bool can_follow_write_pte(pte_t pte, struct page *page, + unsigned int flags) +{ + if (pte_write(pte)) + return true; + + /* + * Make sure that we are really following CoWed page. We do not really + * have to care about exclusiveness of the page because we only want + * to ensure that once COWed page hasn't disappeared in the meantime + * or it hasn't been merged to a KSM page. + */ + if ((flags & FOLL_FORCE) && (flags & FOLL_COW)) + return page && PageAnon(page) && !PageKsm(page); + + return false; +} + /* * Do a quick page-table lookup for a single page. */ @@ -1266,10 +1284,11 @@ split_fallthrough: migration_entry_wait(mm, pmd, address); goto split_fallthrough; } - if ((flags & FOLL_WRITE) && !pte_write(pte)) - goto unlock; - page = vm_normal_page(vma, address, pte); + if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, page, flags)) { + pte_unmap_unlock(ptep, ptl); + return NULL; + } if (unlikely(!page)) { if ((flags & FOLL_DUMP) || !is_zero_pfn(pte_pfn(pte))) @@ -1290,7 +1309,6 @@ split_fallthrough: */ mark_page_accessed(page); } -unlock: pte_unmap_unlock(ptep, ptl); out: return page; @@ -1489,17 +1507,13 @@ int __get_user_pages(struct task_struct * The VM_FAULT_WRITE bit tells us that * do_wp_page has broken COW when necessary, * even if maybe_mkwrite decided not to set - * pte_write. We can thus safely do subsequent - * page lookups as if they were reads. But only - * do so when looping for pte_write is futile: - * in some cases userspace may also be wanting - * to write to the gotten user page, which a - * read fault here might prevent (a readonly - * page might get reCOWed by userspace write). + * pte_write. We cannot simply drop FOLL_WRITE + * here because the COWed page might be gone by + * the time we do the subsequent page lookups. */ if ((ret & VM_FAULT_WRITE) && !(vma->vm_flags & VM_WRITE)) - foll_flags &= ~FOLL_WRITE; + foll_flags |= FOLL_COW; cond_resched(); }