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

Hi,

It's been almost two months since I sent this report, and I haven't
heard back. I'd really appreciate any feedback when you get a chance.

I've rechecked both mainline master and stable 6.12.95 -- the
vulnerability remains unfixed in both trees:

1. mm/shmem.c: shmem_mfill_atomic_pte() (6.12) / shmem_mfill_filemap_add()
   (7.x) still adds pages to the page cache without calling file_modified()
   or __remove_privs(). Writing to a SUID binary on tmpfs via UFFDIO_COPY
   preserves the setuid bit.

2. mm/userfaultfd.c: I noticed commit 85668fda932a added retry state
   tracking on master, but MFILL_RETRY_STATE_VMA_FLAGS still does not
   include VMA_WRITE_BIT -- the mprotect TOCTOU remains exploitable.

This is a deterministic local privilege escalation (no race timing
needed for the killpriv bypass), affects every kernel since 4.11
(8+ years), and works on any system with userfaultfd + tmpfs (the
default on virtually all distributions).

I have a full working PoC that gets uid=0 from uid=1000 reliably.
Happy to provide any additional information if needed.

Thanks,
Vladimir


---------- Forwarded message ---------
From: vova tokarev <[email protected]>
Date: Tue, Jun 16, 2026 at 12:37 PM
Subject: BadBunny: UFFDIO_COPY shmem killpriv bypass leading to local
privilege escalation
To: <[email protected]>


Hi,

I found a local privilege escalation (BadBunny) in the userfaultfd +
shmem subsystems that affects all Linux kernels from 4.11 to 7.1
(every major distribution: Ubuntu, Debian, Fedora, RHEL, SUSE, Arch,
Android, ChromeOS, and any system with CONFIG_USERFAULTFD=y and a
tmpfs/shmem mount).

Two bugs are chained:

1. TOCTOU in UFFDIO_COPY retry path (mm/userfaultfd.c):
   mfill_retry_state_changed() does not re-validate VM_WRITE after
   dropping and re-acquiring the mmap lock in mfill_copy_folio_retry().
   A concurrent mprotect(PROT_READ) installs a writable PTE into a
   now-read-only VMA.

2. Missing killpriv in shmem UFFDIO_COPY (mm/shmem.c):
   shmem_mfill_filemap_add() adds pages to the shmem page cache
   without calling file_modified()/killpriv. This preserves SUID/SGID
   bits when file content is replaced via UFFDIO_COPY, unlike normal
   write() which strips them.

NOTE: The killpriv bypass (Bug 2) does not require
unprivileged userfaultfd and works even with vm.unprivileged_userfaultfd=0,
since UFFDIO_COPY on shmem is available to any process that can open
a tmpfs file O_RDWR and call userfaultfd with UFFD_USER_MODE_ONLY.

An unprivileged user can replace the content of a SUID-root binary on
tmpfs via UFFDIO_COPY while preserving its setuid permission, then
execute it to obtain root.

The attack is deterministic (no timing dependency for the killpriv
bypass), requires no heap spraying, and bypasses all modern kernel
mitigations (KASLR, SMEP, SMAP, CFI, PAC, heap hardening).

Affected versions: Linux 4.11+ (since shmem UFFDIO_COPY support,
    commit 4c27fe4c4c84 "userfaultfd: shmem: add shmem_mcopy_atomic_pte")
Confirmed on: 7.1.0 (aarch64)
Affected distros: All major distributions (Ubuntu, Debian, Fedora,
    RHEL, SUSE, Arch, Android, ChromeOS) that have CONFIG_USERFAULTFD=y
    and tmpfs mounted (virtually all Linux systems)

Attached files:
  - bad_bunny.c                           Full LPE exploit (uid=1000 to
uid=0) Build: gcc -static -O2 -pthread
  - suidhelper.c                            Standalone SUID payload binary
Build: gcc -static -O2
  - uffdio_copy_lpe_report.md     Detailed writeup with root cause,
reproduction steps, and suggested fix
  - badbunny_demo.mp4             PoC demo clip

The PoC (bad_bunny.c) sets up a SUID target on tmpfs, drops to
uid=1000, uses UFFDIO_COPY to replace the binary content with
suidhelper (which does setuid(0) + execve("/bin/sh")), and executes
it to get uid=0 euid=0 gid=0 egid=0. No physical hardware needed.

Suggested fix: Add file_modified() call in shmem_mfill_filemap_add()
to strip SUID/SGID on content modification, matching the normal write
path behavior.

Thank you,
Vladimir Tokarev