Re: Fwd: BadBunny: UFFDIO_COPY shmem killpriv bypass leading to local privilege escalation

[Matthew Wilcox <willy@infradead.org>]

On Sat, Aug 08, 2026 at 01:17:09PM +0100, Pedro Falcato wrote:
> I'm adding a bunch of fs people that might have opinions about this. Please
> see the rest of the thread below.
> 
> On Sat, Aug 08, 2026 at 12:13:06PM +0300, vova tokarev wrote:
> > Pedro,
> > 
> > Thanks for the review. Let me address both points.
> > 
> > On the page fault comparison:
> > 
> > UFFDIO_COPY is not comparable to a page fault. Page faults serve
> > existing page cache content (read-like). UFFDIO_COPY adds new,
> 
> A page fault can also write to the page cache. On MAP_SHARED mappings.
> 
> > 
> > user-controlled content to the shmem page cache (write-like).
> > 
> > The correct comparison is to write(), which calls file_modified()
> > 
> > -> __remove_privs() to strip SUID/SGID.
> > 
> > 
> > This is exactly the reasoning used when fallocate() was fixed
> > 
> > across XFS (commit fbe7e5200365), ext4, and f2fs to call
> > 
> > file_modified(). The XFS commit message says:
> > 
> > "as various fallocate modes can change the file contents [...]
> > 
> > we should drop file privileges like suid just like we do for a
> > 
> > regular write()"
> 
> I can't speak for fallocate, or other system calls. As far as I'm aware,
> this is a best-effort kind of thing. As I said, writing to a MAP_SHARED
> mapping does not clear the setuid bit. It's a super trivial thing to do,
> too. But it's not a problem because setuid executables are not world-writable.

I mean, you're right.  But maybe we should make a bit more of an effort?
I wouldn't like to see this used as part of a chain of exploits, and I
can just about see a path where a confused actor manages to create an
04777 executable.

All the tmpfs on my system are mounted nosuid, and many of them noexec too:

willy@deadly:~$ mount |grep tmp |wc -l
8
willy@deadly:~$ mount |grep tmp |grep nosuid |wc -l
8
willy@deadly:~$ mount |grep tmp |grep noexec |wc -l
4

This certainly isn't a hair-on-fire situation, it's just a place we
could do slightly better.  Not so much BadBunny as MildlyMisbehavingMicrobe