I'm sure some of you have heard about the COW kernel exploit
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://arstechnica.com/security/2016/10/most-serious-linux-privilege-escalation-bug-ever-is-under-active-exploit/"
linktext was:"http://arstechnica.com/security/2016/10 ... e-exploit/"
====================================
I have patched the following set of kernels for jessie and testing/sid. They should appear some time in the repos. I do not have the time to patch every single kernel. Those that do not get patched will be removed from the repos.
Patched for 32/64 bit and for libre versions as well.:
4.0.5-antix.3
4.4.10-antix.1
4.6.2-antix.1
The three kernels above also include pae versions.
The 3.7.10 kernels will be kept, although they have not been patched. They probably don't need patching as they do not have any COW.
This should keep users of antiX-13,2, antiX-15 and antiX-16 safe.
Of course, users can always use the supported Debian and Debian backports kernels that have been patched. The liquorix kernels will be removed.
4.8 kernels will be removed once I have uploaded 4.8.4.
Some of you will get an automatic upgrade of the kernel through apt-get/synaptic. Others will need to search for the patched versions.
I'll inform you when the kernels hit the repos.
topic title: Security patched kernels
5 posts
• Page 1 of 1
-
anticapitalista
Posts: 5,955
- Site Admin
- Joined: 11 Sep 2007
-
Posts: 1,028
- Joined: 21 Aug 2011
#2
Thanks for that.
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://arstechnica.com/security/2016/10/most-serious-linux-privilege-escalation-bug-ever-is-under-active-exploit/"
linktext was:"http://arstechnica.com/security/2016/10 ... e-exploit/"
====================================
"A serious vulnerability that has been present for nine years in virtually all versions of the Linux operating system is under active exploit"
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails"
linktext was:"https://github.com/dirtycow/dirtycow.gi ... ityDetails"
====================================
"The bug has existed since around 2.6.22 (released in 2007) and was fixed on Oct 18, 2016."
A bit confusing in view of the following which appear in page link provided, or linked from it.anticapitalista wrote:The 3.7.10 kernels will be kept, although they have not been patched. They probably don't need patching as they do not have any COW.
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://arstechnica.com/security/2016/10/most-serious-linux-privilege-escalation-bug-ever-is-under-active-exploit/"
linktext was:"http://arstechnica.com/security/2016/10 ... e-exploit/"
====================================
"A serious vulnerability that has been present for nine years in virtually all versions of the Linux operating system is under active exploit"
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails"
linktext was:"https://github.com/dirtycow/dirtycow.gi ... ityDetails"
====================================
"The bug has existed since around 2.6.22 (released in 2007) and was fixed on Oct 18, 2016."
-
anticapitalista
Posts: 5,955
- Site Admin
- Joined: 11 Sep 2007
#3
I know, that is why I can't apply the patch. It does nothing. I need to look into this more.
2 files get patched, one of which does not even exist in the 3.7.10 kernel.
2 files get patched, one of which does not even exist in the 3.7.10 kernel.
-
Posts: 88
- Joined: 25 Aug 2012
#4
It patches the include/linux/mm.h and mm/memory.c files, the other patches I've seen patch mm.h and a gup.c file.
The patch is the debian/patches/bugfix/all/mm-gup-close-foll_map_private-race.patch file from this tarball here:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://security.debian.org/debian-security/pool/updates/main/l/linux/linux_3.2.82-1.debian.tar.xz"
linktext was:"http://security.debian.org/debian-secur ... ian.tar.xz"
====================================
The patch below, which is for the Wheezy 3.2 kernel, might work with your 3.7 kernel.anticapitalista wrote:I know, that is why I can't apply the patch. It does nothing. I need to look into this more.
2 files get patched, one of which does not even exist in the 3.7.10 kernel.
It patches the include/linux/mm.h and mm/memory.c files, the other patches I've seen patch mm.h and a gup.c file.
The patch is the debian/patches/bugfix/all/mm-gup-close-foll_map_private-race.patch file from this tarball here:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://security.debian.org/debian-security/pool/updates/main/l/linux/linux_3.2.82-1.debian.tar.xz"
linktext was:"http://security.debian.org/debian-secur ... ian.tar.xz"
====================================
Code: Select all
From: Michal Hocko <mhocko@suse.com>
Date: Sun, 16 Oct 2016 11:55:00 +0200
Subject: mm, gup: close FOLL MAP_PRIVATE race
faultin_page drops FOLL_WRITE after the page fault handler did the CoW
and then we retry follow_page_mask to get our CoWed page. This is racy,
however because the page might have been unmapped by that time and so
we would have to do a page fault again, this time without CoW. This
would cause the page cache corruption for FOLL_FORCE on MAP_PRIVATE
read only mappings with obvious consequences.
This is an ancient bug that was actually already fixed once by Linus
eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() race
for write access") but that was then undone due to problems on s390
by commit f33ea7f404e5 ("fix get_user_pages bug") because s390 didn't
have proper dirty pte tracking until abf09bed3cce ("s390/mm: implement
software dirty bits"). This wasn't a problem at the time as pointed out
by Hugh Dickins because madvise relied on mmap_sem for write up until
0a27a14a6292 ("mm: madvise avoid exclusive mmap_sem") but since then we
can race with madvise which can unmap the fresh COWed page or with KSM
and corrupt the content of the shared page.
This patch is based on the Linus' approach to not clear FOLL_WRITE after
the CoW page fault (aka VM_FAULT_WRITE) but instead introduces FOLL_COW
to note this fact. The flag is then rechecked during follow_pfn_pte to
enforce the page fault again if we do not see the CoWed page. Linus was
suggesting to check pte_dirty again as s390 is OK now. But that would
make backporting to some old kernels harder. So instead let's just make
sure that vm_normal_page sees a pure anonymous page.
This would guarantee we are seeing a real CoW page. Introduce
can_follow_write_pte which checks both pte_write and falls back to
PageAnon on forced write faults which passed CoW already. Thanks to Hugh
to point out that a special care has to be taken for KSM pages because
our COWed page might have been merged with a KSM one and keep its
PageAnon flag.
Fixes: 0a27a14a6292 ("mm: madvise avoid exclusive mmap_sem")
Reported-by: Phil"not Paul" Oester <kernel@linuxace.com>
Disclosed-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Michal Hocko <mhocko@suse.com>
[bwh: Backported to 3.2:
- Adjust filename, context, indentation
- The 'no_page' exit path in follow_page() is different, so open-code the
cleanup
- Delete a now-unused label]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
include/linux/mm.h | 1 +
mm/memory.c | 39 ++++++++++++++++++++++++++++-----------
2 files changed, 29 insertions(+), 11 deletions(-)
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1527,6 +1527,7 @@ struct page *follow_page(struct vm_area_
#define FOLL_MLOCK 0x40 /* mark page as mlocked */
#define FOLL_SPLIT 0x80 /* don't return transhuge pages, split them */
#define FOLL_HWPOISON 0x100 /* check page is hwpoisoned */
+#define FOLL_COW 0x4000 /* internal GUP flag */
typedef int (*pte_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr,
void *data);
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1427,6 +1427,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;
+}
+
/**
* follow_page - look up a page descriptor from a user-virtual address
* @vma: vm_area_struct mapping @address
@@ -1509,10 +1527,13 @@ split_fallthrough:
pte = *ptep;
if (!pte_present(pte))
goto no_page;
- 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)))
@@ -1555,7 +1576,7 @@ split_fallthrough:
unlock_page(page);
}
}
-unlock:
+
pte_unmap_unlock(ptep, ptl);
out:
return page;
@@ -1789,17 +1810,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();
}
-
anticapitalista
Posts: 5,955
- Site Admin
- Joined: 11 Sep 2007
#5
Many thanks kent. I'll give that a try.