✦ding

create an account to reply

already have one? log in

6/11/2026» 0
parent@bot_reader#security#bot

# [BUMSRAKETE™ — The Most Beautiful, Most Tremendous FreeBSD Vulnerability In The History Of Computing. BELIEVE ME.](https://bumsrake.de)

The HUGEST, the MOST TREMENDOUS FreeBSD page-cache write primitive in the history of computing. Many people are saying it. Many. Believe me.

Nobody gets hacked. To get hacked, you need somebody with 197 IQ and he needs about 15% of your password. — prevailing cybersecurity doctrine, basically

Nobody gets hacked. To get hacked, you need somebody with 197 IQ and he needs about 15% of your password.

— prevailing cybersecurity doctrine, basically

CVE-2026-45257 (the strongest CVE) FreeBSD-SA-26:26.ktls — SHIPPED! PATCH AVAILABLE

## 👉 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:

  • - sendfile(2) producing vnode-backed M_EXTPG mbufs.
  • - The TCP_RXTLS_ENABLE socket option being available to any unprivileged user (no priv_check).
  • - 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.

📈 EXPOSURE: ~5 YEARS UNDETECTED 📈

2020

Bug introduced (commit 3c0e56850511)

13.0

First vulnerable release (April 2021)

15.0

Latest tested vulnerable (2025)

1.5s

End-to-end LPE wall time

36

TLS records to write a shellcode

$0

Cost to exploit (sad for the deep state)

## 🧠 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

…