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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

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.
>
> 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.
>
> Given that the fallocate killpriv fixes went through the security fix
> process (CVE + stable backport), should this follow the same path?
> Happy to send the patch either way.
>
> Thanks,
> Vladimir

Please don't send what sounds exactly like an undisclosed AI-generated
'summary' type email.

https://docs.kernel.org/process/coding-assistants.html
https://docs.kernel.org/process/generated-content.html

I really wonder if this summary email trend (never ever saw it before LLMs
came into being) is just there to workslop people into providing the next
LLM prompt...

Please don't send top-posted email quoting everything below it - at least
put in the bare minimum effort required to see how kernel discussions have
functioned for the past 3+ decades.

Especially if you are looking to assign some silly name to an alleged
vulnerability.

I _hate_ how this stuff has impacted the mailing list.

--
Cheers, Lorenzo