Incoming details.
==== Summary ==== In the "Dirty COW" vulnerability patch (CVE-2016-5195), can_follow_write_pmd() was changed to take into account the new FOLL_COW flag (8310d48b125d "mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp"). We noticed a problematic use of pmd_mkdirty() in the touch_pmd() function. touch_pmd() can be reached by get_user_pages(). In such case, the pmd will become dirty. This scenario breaks the new can_follow_write_pmd()'s logic - pmd can become dirty without going through a COW cycle - which makes writing on read-only transparent huge pages possible. This bug is not as severe as the original "Dirty cow" because an ext4 file (or any other regular file) cannot be mapped using THP. Nevertheless, it does allow us to overwrite read-only huge pages. For example, the zero huge page and sealed shmem files can be overwritten (since their mapping can be populated using THP). Note that after the first write page-fault to the zero page, it will be replaced with a new fresh (and zeroed) thp. Using this primitive, we successfully crashed several processes. A likely consequence of overwriting the huge zero page is having improper initial values inside large BSS sections. Common vulnerable pattern would be using the zero value as an indicator that a global variable hasn't been initialized yet. Potentially, privileged processes using the mentioned pattern are exploitable. ===== POC ===== The POC overwrites the zero-page of the system. POC source on GitHub: https://github.com/bindecy/HugeDirtyCowPOC ===== Affected Versions ===== The POC was tested on Ubuntu 17.04 with kernel 4.10 and Fedora 27 with kernel 4.13. Every kernel version with THP support and the Dirty COW patch should be vulnerable (2.6.38 - 4.14). RHEL claimed by the vendor as not affected. Fixed on Nov 27, 2017: https://github.com/torvalds/linux/commit/a8f97366452ed491d13cf1e44241bc0b5740b1f0 ===== Timeline ===== 22.11.17 — Initial report to security@kernel.org and linux-distros@vs.openwall.org 22.11.17 — CVE-2017–1000405 was assigned 27.11.17 — Patch was committed to mainline kernel 29.11.17 — Public announcement ===== Credit ===== Eylon Ben Yaakov and Daniel Shapiro from Bindecy
thanks
patch still need upstream review. waiting for upstream.
Alice, patch is already commited to 4.14.4[1]. Is it time to backport/fix our stable? https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.4
BTW, could anyone please explain why we are at 4.12.x while EOL branch is 4.13.x?
Stable for gentoo-sources doesn't mean the same like stable for packages. If you care about security you should keyword the LTS kernel you are interested in and don't wait for stabilization.
(In reply to Thomas Deutschmann from comment #6) > If you care about security you should keyword the LTS kernel you are > interested in and don't wait for stabilization. Sorry, but do you think that by default users are don't care about security? I just trying to understand the process. I'm a Gentoo user since 2004, and still cannot figure out how does it works. I understand, that kernel team have to choose between security, stability and maintainability. And that kernel is most critical parts of the system. But still, kernel stabilization process in Gentoo is not transparent at all.
> Sorry, but do you think that by default users are don't care about security? No, but I have the feeling that most Gentoo users have wrong expectations regarding stable kernels in Gentoo. > But still, kernel stabilization process in Gentoo is not transparent at all. That's what I tried to tell you: gentoo-sources don't get the same treatment like vulnerable packages. This isn't something new. This was always the case: Especially since upstream is releasing new kernels every ~10 days in average with the note "All users of the X kernel series must upgrade". We would really like to stabilize new kernels in time but we don't have the man power to do that. And please notice that there's a major difference between stabilizing a normal package vs. stabilizing a new kernel: - In most cases a minor package bump is just fixing bugs. - Due to the UNIX philosophy "Write programs that do one thing and do it well" which is still honored by most programs you can better check for regressions. - As long as you don't lose access to your system you are able to downgrade most of the time in case you need to due to a regression/new problem. But the kernel is different: - There are so many drivers/components in the kernel which you cannot test anymore. Remember the broken crypto in user space (bug 575024) or broken megaraid driver (bug 599464)? Doesn't affect everyone but when you are affected you will have problems. - If a kernel crashes or doesn't boot there's no easy fix. In most cases, the user has to manually fix the problem (=needs to get physical access to the broken Gentoo box). So face it: You cannot get a known working stable kernel on most platforms/setups together with latest security fixes. However, if you would give people the choice between kernel with latest fixes vs known working kernel, the majority would pick the well tested kernel (this is ridiculous in so many ways because when we stabilize a new kernel we will pick the latest one but...). tl;dr One could say we only have stable gentoo-sources at all to _not_ break the depgraph, to have a minimum version we need to support and to allow stable users to set up a new Gentoo system without the need to keyword something.
Mike Limansky we are currently moving away from 4.12 we are just waiting that 4.14 stabilize https://archives.gentoo.org/gentoo-kernel/message/b32bf0b9c65614c8979923ebac77c34b
Thomas thank you for clarification. Sorry if I was rude. I just wanna say that kernel team might be more open to community. If we had something like stabilization candidates, people would be able to test it earlier. Alice thank you for good news!
Fix in 4.9.67, 4.14.4, 4.15
