CentOS - Oct 2016 - 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

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.rpm
Thanks,

the srpm would be very helpful, I'll reply off-list.

Cheers, Christian.

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/ 

--
LF

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

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

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();
 			}