Re: CVE-2022-2590: Linux kernel: Modifying shmem/tmpfs files without write permissions

[David Hildenbrand <david () redhat com>]

On 08.08.22 21:51, Demi Marie Obenour wrote:
> On Mon, Aug 08, 2022 at 09:18:27AM +0200, David Hildenbrand wrote:
> > Hi,
> >
> > I found a security issue (CVE-2022-2590) in the Linux kernel similar to
> > Dirty COW (CVE-2016-5195), however, restricted to shared memory (shmem /
> > tmpfs). I notified distributions one week ago and the embargo ended today.
> >
> > An unprivileged user can modify file content of a shmem (tmpfs) file,
> > even if that user does not have write permissions to the file. The file
> > could be an executable.

Hi,

> Is Android affected by this, or do other protections (such as SELinux)
> prevent an exploit from succeeding? 

Android: short, don't know. They are affected if
* they are based on >= v5.16 OR they backported the patch
* and they have CONFIG_USERFAULTFD=y (I assume so)

My gut feeling is that we found this issue early enough before it got
part of many distros, including Android.

Regarding other protections: not aware of any.

> Also, is read access to the file
> necessary? 

We have to be able to mmap the file. Just like for the original dirty
COW (IIRC) we need read access.

> Are sealed memfds impacted?

Yes. I just extended my reproducer to modify content of a memfd that is
sealed with F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_WRITE | F_SEAL_SEAL.

> > The introducing upstream commit ID is:
> >   9ae0f87d009c ("mm/shmem: unconditionally set pte dirty in
> >   mfill_atomic_install_pte")
> >
> > Linux >= v5.16 is affected on x86-64 and aarch64 if the kernel is
> > compiled with CONFIG_USERFAULTFD=y. For Linux < v5.19 it's sufficient to
> > revert the problematic commit, which is possible with minor contextual
> > conflicts. For Linux >= v5.19 I'll send a proposal fix today.
> >
> > I have a working reproducer that I will post as reply to this mail in
> > one week (August 15).
>
> Can you try to make sure that a patch has made it into Greg’s stable
> trees by then?  Also, would it be possible to include a regression test?

That's the plan, hopefully there is feedback on the upstream patch
soonish, because backports usually rely on the fix being upstream. Greg
(cc) is aware of the issue.

Regarding regression test: I noticed that LTP has a Dirty COW regression
test [1]. Most probably LTP is the right place for that.

[1]
https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/security/dirtyc0w

-- 
Thanks,

David / dhildenb