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

[Pedro Falcato <pfalcato@suse.de>]

On Tue, Aug 11, 2026 at 02:16:31PM +0300, vova tokarev wrote:
> Matthew, Christian, Pedro,
> 
> Lol - fair point, I'll keep the reggaeton references out of future
> commit messages.
> 
> Agreed on severity - but this is a
> killpriv invariant violation, and the kernel has treated those as
> security fixes worth backporting before.
> 
> 1. The fallocate killpriv fixes (XFS fbe7e5200365, ext4, f2fs) are
>    exact precedent: same reasoning ("can change the file contents [...]
>    should drop file privileges like suid just like we do for a regular
>    write()"), same one-line fix, and they went through the security fix
>    process with CVE assignment and stable backports.
> 
> 2. CVE-2023-0386 (overlayfs SUID preservation) -- same bug class,
>    CVSS 7.8, CISA KEV.

I don't see how this is related. It looks like an entirely different bug.

> 
> 3. If permissions alone protected SUID, write() wouldn't strip it.
>    killpriv exists for POSIX ACLs granting write to non-owners,
>    group-writable SUID, container shared mounts, and chaining with
>    other write-access bugs.
> 
> 4. This path is reachable unprivileged even with
>    vm.unprivileged_userfaultfd=0 (UFFD_USER_MODE_ONLY bypasses it).
> 
> 5. Pedro's point that MAP_SHARED faults also skip killpriv isn't a
>    counterargument -- it's another instance of the same class. We can
>    fix them independently.

Again, I don't think this is a real issue. I'm happy to be proven wrong
though. Otherwise, I don't see why we should care about this, especially
in MM. All of these helpers (file_modified(), etc) require the inode lock
which, if taken with the mmap_lock/vma lock held, will result in lock
inversion; so you need to implement awkward retry loops everywhere (pin file,
release the VMA lock/mmap lock, grab inode lock, call file_modified(),
unlock inode, retry). And I don't think you can ever specify sane semantics
for mmap (but, again, who the heck cares).

I'm sure this was all a great idea in the UNIX of old in the 1980s and 90s,
I don't think this is particularly important these days. I can theorize some
particularly weird scenarios (what if file is group-writable, but setuid (so
the owner "blessed" it); group writes, setuid should no longer bless it), but
we're much closer to a world where suid is no longer a thing, than a world
where suid (and the UNIX model for users, groups) is this important.


-- 
Pedro