cinder27/docs/IOS27.2-KERNEL-DIFF.md

# iOS 27.2 kernel differential — 27.0.1 vs 27.2 (iPhone19,7)

Scope: the iOS 27.2 security update (24B119) against 27.0.1 (24A446) for iPhone 18
Pro Max (`iPhone19,7`). The question: what does the update actually change in the
kernel, which of the 162 advisory CVEs can be tied to a fix site, and does anything
in the diff look like a PPL / SPTM / MIE bypass.

## How the images were obtained

Both restore images are the production IPSWs from Apple's CDN:

| Build | Version | Size | Kernelcache member |
|---|---|---|---|
| 24A446 | 27.0.1 | 12,728,434,807 B | `kernelcache.release.v6x-pandia` |
| 24B119 | 27.2 | 13,722,855,612 B | `kernelcache.release.v6x-pandia` |

The kernelcache was pulled straight out of the ZIP with HTTP Range requests, so the
analysis did not wait for the full 26 GB. The container is IM4P; the payload is LZFSE.

| Build | Kernelcache (decoded) | SHA-256 (first 16) |
|---|---|---|
| 27.0.1 | 78,315,520 B | `dec73956a9a443c5` |
| 27.2 | 79,167,488 B | `9a6efbc4be67319a` |

Both are `MH_FILESET` images with a `__DATA_SPTM` segment, carrying 303 (27.0.1) and
305 (27.2) fileset entries. Two kexts are new: `com.apple.driver.ApplePencilDriver`,
`com.apple.iokit.AppleSecurityResearch`; none were removed.

## Reading the diff

Raw text-segment hashes are useless here: the fileset is relinked, so branch
displacements and absolute literal pools move in almost every kext even when the
code is unchanged. The diff therefore keys on:

1. `__TEXT_EXEC` size change (layout-independent),
2. `__cstring` / `__oslogstring` set difference (new checks usually add a message),
3. `llvm-objdump` instruction diff for the kexts that survive both filters.

93 of 303 common kexts changed text size. The largest are the ones the advisory
points at:

| Delta | Kext | Advisory component |
|---|---|---|
| +115,472 | `com.apple.driver.ASIOKit` | IOKit / audio |
| +39,624 | `com.apple.driver.AppleH16ANEInterface` | Apple Neural Engine |
| +29,376 | `com.apple.kernel` | Kernel |
| +16,080 | `com.apple.driver.AppleAVE2` | AVEVideoEncoder |
| +9,572 | `com.apple.driver.FairPlayIOKit` | Security |
| +9,316 | `com.apple.driver.AppleDisplayCrossbar` | IOMobileFrameBuffer |
| +8,304 | `com.apple.AGXG19P` | GPU |
| +4,712 | `com.apple.driver.AppleMobileDispH19P-DCP` | IOMobileFrameBuffer |
| +4,480 | `com.apple.driver.RTBuddy` | Kernel / RTKit |
| +4,152 | `com.apple.driver.AppleSARService` | Kernel |

## Fix sites that are confirmed by strings

### CVE-2026-112705 — AppleAVE2 temporal layers

27.2 adds the upper bound that 27.0.1 lacks:

```
number of temporal layers (prop) is out of range %d %d %d
0 <= pInfo->uPropCfg.sHEVC.iNumberOfTemporalLayers
    && pInfo->uPropCfg.sHEVC.iNumberOfTemporalLayers <= 7
0 < pInfo->sSessionCfg.sEnc.sAlgCfg.sGOP.iNumOfTemporalLayer
    && (... <= 7)
AVE_HEVC_CheckVPSExtBounds
HEVC VPS vps_max_layers_minus1 is out of range
HEVC VPS layer_id_in_nuh is out of range
HEVC VPS layer-set total is out of range
```

The property is now clamped to **0…7**. The trigger in the 27.0.1 dossier
(`NumberOfTemporalLayers = 16463`, first frame → AppleAVE2 +0xDA78) is exactly the
value this assertion rejects. A `--sweep` mode was added to both POCs: it sets
0…12 and submits no frame. On macOS 27.0 it accepts 1…12 (and 16463); on 27.2 the
>7 rungs must return an error.

### CVE-2026-113910 — decmpfs chunked zlib

27.2 adds the produced-vs-expected check in
`AppleFSCompression/Common/ChunkCompression.cpp`:

```
%s:%d: chunk %u produced %lld of %lld expected bytes
```

That is the exact under-production condition the leak harness drives. The C POC's
`--loop` / `--keep` collector now sits on a documented fix site.

### CVE-2026-112507 — ipc_port request table

27.2 adds the checks the 27.0.1 code was missing:

```
ipr != ((void*)0)
table != ((void*)0)
ipc_misc.c
```

This is a **NULL-check fix**, not a reclaimable-object fix. It matches the device
result already recorded: `mach_port_request_notification` returns -300
(MIG_TYPE_ERROR) for every type/right combination, 0 of 12,288 registrations armed,
so the request-table path is never entered from an unentitled app.

### Other kernel changes

The core kernel gains 62 meaningful strings (build paths and UUIDs excluded). The
security-relevant ones:

- `VM entry %p lock shared lock overflow` — a new vm_map lock-overflow panic,
  consistent with the COW / vm_map CVEs (112474 / 112576).
- `Page modified after framebank withdraw %p` — page-lifecycle check.
- `size <= sdl->sdl_alen` — sockaddr_dl bounds check in the network stack.
- `speculative_pages_freed` / `_demoted` / `_requeued_inactive` — pageout counters.
- `FilterDropBadDirection`, `nx_netif_filter_pkt_to_mbuf`, `pktap != NULL`,
  `ret == TB_ERROR_SUCCESS` — network filter validation.
- `ipr != NULL`, `table != NULL`, `ipc_misc.c` — the 112507 fix.
- New entitlements: `com.apple.private.verified-jit-mode`,
  `com.apple.private.vfs.unmunged-access-time`, `com.apple.security.cs.debugger`.

These line up with the 15 Kernel entries in the advisory (UAF, OOB read/write, race,
type confusion, COW integrity, kernel-layout disclosure). The advisory does not
assign individual functions, so the mapping above is evidence-based, not a
per-CVE signature.

## PPL / SPTM / MIE

This is the part the request specifically asked to dig into.

- `__DATA_SPTM` is **byte-identical** in both builds: 311,296 bytes, SHA-256
  `f4bc1e5e95f61af5…`. No SPTM code or data changed.
- The PPL token strings (`UAT_PPL_IOCTL_*`, `PPL map operation failed`,
  `PPL state object`) are unchanged; no new PPL checks or messages.
- No MIE / Memory Integrity / mtag / page-protection strings were added or removed.
- The only SPTM-related additions are boot-time memory-size validation:
  `memsize=%u MB leaves no memory for XNU/SPTM to manage`, `Mismatch of
  ARM_LARGE_MEMORY in SPTM/XNU`, and iBoot DRAM-size checks. These are
  configuration checks, not a permission bypass.
- The 27.2 advisory contains no component named PPL, SPTM, MIE, or Page Protection,
  and no CVE description mentions them.

**Verdict: no PPL, SPTM, or MIE bypass is fixed in iOS 27.2, and the firmware diff
shows no change in the SPTM/PPL/MIE code paths.** A bypass PoC for any of the three
would have to come from a different bug, not from this update. The kernel CVEs with
"write kernel memory" impacts are ordinary kernel memory-safety bugs; none of them
is a page-table / monitor bypass on its own, and exploiting one would still have to
defeat SPTM/PPL/MIE at runtime.

## What can be turned into a PoC

| CVE | Primitive | PoC status |
|---|---|---|
| 2026-112705 | fixed-offset constant fill in AppleAVE2 | existing Swift/C POC + new `--sweep`; kernel panic on 27.0.1, property refused on 27.2 |
| 2026-113910 | kernel heap disclosure through decmpfs | existing C collector (`--loop`, `--keep`, pointer classes); read-only |
| 2026-112507 | request-table NULL check / race | existing harness; unreachable from an unentitled app (-300) |
| 2026-112696 | ANE validation, +39 KB | no trigger in the diff; ANE kext strings show resource/scheduler validation, not a user-reachable entry |
| 2026-65385 | IOHIDEvent fixed-offset write | IOHIDFamily grew only 236 B (+ `TCCService`); the advisory's IOKit fix is likely in the userland IOKit.framework (DSC), not this kext |
| other Kernel CVEs | UAF/OOB/race | fix sites visible as strings, but no trigger or reclaim strategy; writing a PoC would be guesswork |

The WebKit, ImageIO, CoreMedia and other userland components live in the dyld shared
cache inside the root filesystem image, which is not part of the ZIP's plain files;
those were not diffed here.

## Reproduce

```bash
python3 tools/ipsw/remote_ipsw.py extract <ipsw-url> kernelcache work/kernel/27.2.im4p
python3 tools/ipsw/ipswlib.py kernel ...            # decode + list
python3 tools/ipsw/extract_kext.py work/kernel/27.2.kernel \
        work/kernel/27.2-entries.json com.apple.driver.AppleAVE2 out.macho
python3 tools/ipsw/disasm_diff.py a.macho b.macho
```

The tools are read-only: no device is touched, and no firmware is modified.