OpenWrt Forum Archive

Topic: [PATCH] Backport of patch for CVE-2016-5195 for Chaos Calmer

The content of this topic has been archived on 12 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

The title says it all. Here is a backport of commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 that patches CVE-2016-5195.

This is a serious privilege escalation bug, although it does require local access in order to exploit.

Still cannot submit any tickets to trac, so posting here for those who are running CC and feel an urgent need to patch this bug

git apply <patch-name>
diff --git a/target/linux/generic/patches-3.18/099-CVE-2016-5195.patch b/target/linux/generic/patches-3.18/099-CVE-2016-5195.patch
new file mode 100644
index 0000000..2febc79
--- /dev/null
+++ b/target/linux/generic/patches-3.18/099-CVE-2016-5195.patch
@@ -0,0 +1,47 @@
+--- a/include/linux/mm.h
++++ b/include/linux/mm.h
+@@ -2029,6 +2029,7 @@ static inline struct page *follow_page(s
+ #define FOLL_NUMA    0x200    /* force NUMA hinting page fault */
+ #define FOLL_MIGRATION    0x400    /* wait for page to replace migration entry */
+ #define FOLL_TRIED    0x800    /* a retry, previous pass started an IO */
++#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/gup.c
++++ b/mm/gup.c
+@@ -32,6 +32,16 @@ static struct page *no_page_table(struct
+     return NULL;
+ }
+ 
++/*
++ * FOLL_FORCE can write to even unwritable pte's, but only
++ * after we've gone through a COW cycle and they are dirty.
++ */
++static inline bool can_follow_write_pte(pte_t pte, unsigned int flags)
++{
++    return pte_write(pte) ||
++        ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte));
++}
++
+ static struct page *follow_page_pte(struct vm_area_struct *vma,
+         unsigned long address, pmd_t *pmd, unsigned int flags)
+ {
+@@ -66,7 +76,7 @@ retry:
+     }
+     if ((flags & FOLL_NUMA) && pte_numa(pte))
+         goto no_page;
+-    if ((flags & FOLL_WRITE) && !pte_write(pte)) {
++    if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags)) {
+         pte_unmap_unlock(ptep, ptl);
+         return NULL;
+     }
+@@ -315,7 +325,7 @@ static int faultin_page(struct task_stru
+      * reCOWed by userspace write).
+      */
+     if ((ret & VM_FAULT_WRITE) && !(vma->vm_flags & VM_WRITE))
+-        *flags &= ~FOLL_WRITE;
++        *flags |= FOLL_COW;
+     return 0;
+ }
+ 
-- 
1.8.3.1

excuse a naive question, but how to I apply this patch? SSH to the router and what do I do then?
Thanks in advance

This patch requires you to build your own image from source code. In the root of the source tree

git apply <patch name>
make V=s

You'll then need to use sysupgrade to upgrade the new image

Bumping kernel versions in OpenWrt is highly non-trivial

(Last edited by dl12345 on 24 Oct 2016, 08:38)

But not that difficult either, me thinks you are able to pull it off and make a pull request for CC wink

There are 265 patches in target/linux/generic/patches-3.18 (including this CVE patch) all of which would need to be integrated and verified with a new kernel version. Unless there's a really good reason to bump the kernel version, it's best to leave it untouched

I'm also in the camp of this are far to many patches for generic

Once the 3.18 branch gets updated and released, we'll bump the 3.18 kernels to .44 unless regressions appear - there isn't much reason to add another generic patch to backport this fix. I'm building .43 now on a few targets to see what the .36->.43 upgrade blows up so far.

-w-

There was another local user high sev vuln and a couple non-local high sev DDoS vulns published last week on linux kernel: 

CVE-2015-3288
CVE-2016-7039
CVE-2016-8666

Stupid question, but isn't openwrt running all daemons as root anyway? So if somebody breaks in through sec issue in daemon, he already got root privileges. No need to escalate.

finch wrote:

Stupid question, but isn't openwrt running all daemons as root anyway?

No. Look at your /etc/passwd.

FYI, @wigyori has now updated the 15.05 repo to kernel 3.18.44 which contains this fix

The discussion might have continued from here.