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

On Mon, Aug 10, 2026 at 05:05:44AM +0100, Matthew Wilcox wrote:
> 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

Let's not drag Bad Bunny's good name into kernel development. ;)