Gaining full control relies on having minimal access to start with. For the average Raspberry used by the average user behind a home router (which includes some intrusion detection) that’s an exceedingly unlikely scenario. Almost a likely as your phone getting hacked with the “Dirty COW” exploit.

The machines that are most at risk have open ports (done with port forwarding), or OpenVPN tunnels. Even then there are no hackers exploiting this on ARM processors at the current time.

I think the world of Linux users is making a mountain out of this worm cast (it’s not even mole hill sized) for a bug that’s been in the kernel for twenty years. It’s also present in your Android tablet and Android phone and your phone makers aren’t waving their flags over this thing.

I get this:
pi@raspberrypi ~ $ sudo apt-get install raspberrypi-kernel
Reading package lists… Done
Building dependency tree
Reading state information… Done
E: Unable to locate package raspberrypi-kernel

I made the update and upgrade before.

Once I read the link a Google+, I came here and did the command and … then I remember that my distro was Ubuntu Mate on my raspi3 :)
ooops

Dirty COW bug fix discussed in the forum here:
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=163434&p=1058266&hilit=dirty+cow#p1058266

and here:
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=163538&p=1058409&hilit=dirty+cow#p1058409

According to Dougie Lawson:
“If you run sudo apt-get update && sudo apt-get -y dist-upgrade you’ll get the 4.4.26+ kernel (which includes the Dirty COW fix).”

Seems to be missing on Wheezy.

So what is the solution for Wheezy?

why i never see “/var/run/reboot-required” and “/var/run/reboot-required.pkgs”, when i use apt-get update/upgrade, on raspbian, to see if a reboot is required.
after a new kernel it must be there for sure, but i can not see.

Hi, I found that for Wheezy, the command “rpi-update” is used to update the kernel. I ran it and rebooted and I am no longer vulnerable. Hope that helps!

Also, if your username is pi and your password is raspberry, then Dirty Cow is not your top concern.

Reduced snark helpful comment:
Use the ‘passwd’ command to change your password to something strong.
If you are not using the ‘pi’ account, either change its password as well, or delete the account entirely with userdel or deluser.

And Leon, runner4567 is not a strong password. (I only promised reduced snark, not snark-free.)

Linus published a patch two years ago to fix it. He knows that this has been in the Kernel for 11 years, but it would mean having to rewrite the whole Kernel ans end up with alot of bugs to fix.

The fix was released last week a day after the Microsoft Fanboys tried to make it sound like Windows is failsafe.

” Last week a very serious vulnerability in the Linux kernel, the so called Dirty COW, was reported. Our dedicated Linux kernel team immediately addressed the issues and were able to patch it in less than 24 hours on the majority of our servers. What is more, we managed to do this without server reboot and we avoided the downtime that normally results from such kernel update activities.”

This is the code and email how he patched it.

commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream.

This is an ancient bug that was actually attempted to be fixed once
(badly) by me 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”).

In the meantime, the s390 situation has long been fixed, and we can now
fix it by checking the pte_dirty() bit properly (and do it better). The
s390 dirty bit was implemented in abf09bed3cce (“s390/mm: implement
software dirty bits”) which made it into v3.9. Earlier kernels will
have to look at the page state itself.

Also, the VM has become more scalable, and what used a purely
theoretical race back then has become easier to trigger.

To fix it, we introduce a new internal FOLL_COW flag to mark the “yes,
we already did a COW” rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.

Reported-and-tested-by: Phil “not Paul” Oester
Acked-by: Hugh Dickins
Reviewed-by: Michal Hocko
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Willy Tarreau
Cc: Nick Piggin
Cc: Greg Thelen
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds
[wt: s/gup.c/memory.c; s/follow_page_pte/follow_page_mask;
s/faultin_page/__get_user_page]
Signed-off-by: Willy Tarreau
—
include/linux/mm.h | 1 +
mm/memory.c | 14 ++++++++++++–
2 files changed, 13 insertions(+), 2 deletions(-)

diff –git a/include/linux/mm.h b/include/linux/mm.h
index 53b0d70..55590f4 100644
— a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1715,6 +1715,7 @@ static inline struct page *follow_page(struct vm_area_struct *vma,
#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 –git a/mm/memory.c b/mm/memory.c
index 10cdade..2ca2ee1 100644
— a/mm/memory.c
+++ b/mm/memory.c
@@ -1462,6 +1462,16 @@ int zap_vma_ptes(struct vm_area_struct *vma, unsigned long address,
}
EXPORT_SYMBOL_GPL(zap_vma_ptes);

+/*
+ * 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));
+}
+
/**
* follow_page_mask – look up a page descriptor from a user-virtual address
* @vma: vm_area_struct mapping @address
@@ -1569,7 +1579,7 @@ split_fallthrough:
}
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))
goto unlock;

page = vm_normal_page(vma, address, pte);
@@ -1877,7 +1887,7 @@ long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
*/
if ((ret & VM_FAULT_WRITE) &&
!(vma->vm_flags & VM_WRITE))
– foll_flags &= ~FOLL_WRITE;
+ foll_flags |= FOLL_COW;

cond_resched();
}
—
2.8.0.rc2.1.gbe9624a

And this is why unattended upgrades should be on by default.

What if next time it isn’t so obscure ?

Just one word of warning to anyone that has used berryboot to load Raspbian. If you try to apply this fix the pi won’t boot and your SD card will be unreadable and unformattable on your PC. I managed to re-format the card on my camera (really!) which then allowed to go through the whole new install process and of couorse lost all the content on my pi system.