cinder27/docs/KERNEL-RW-ASSESSMENT.md

Kernel read/write feasibility — high and critical dossiers

Scope: the kernel-reachable entries rated High or Critical in the Cinder27 dossiers. Question: can any of them be turned into arbitrary kernel read/write that does not panic the device?

Short answer: no, not from the material as it stands. One entry gives a real kernel heap leak (read), one gives a bounded read model, one gives a race receipt on a UAF-shaped bug. The write entries either write a constant at a fixed offset or never reach the kernel interface at all. This document records what each primitive actually provides, what an arbitrary-R/W chain still needs, and what was added to the POCs.

Guardrails

• The host Mac was panicked once by the CVE-2026-112705 encode path. That path is never executed on the host again; its C twin refuses to submit a frame without --force-host.
• No blind kernel writes are attempted from any POC. A wrong guess in the kernel heap is a panic, not a data point.
• The simulator has no AppleAVE2 hardware encoder and no ANE kernel interface, so the write primitives cannot be exercised there either. Their app modules are split into a safe probe and a deliberate fire module.

Primitive inventory

CVE	Entry	Primitive as shipped	Read	Write	Kernel R/W verdict
2026-112705	AppleAVE2 NumberOfTemporalLayers	fixed-offset constant fill in the driver	no	fixed value, fixed offset	DoS only. No address control, no value control. The original write-up says explicitly: no arbitrary read/write capability.
2026-65385	IOKit IOHIDEventAppendEvent	fixed-offset write into a short heap allocation	no	bounded, offset fixed	Not reachable as a primitive here. The POC stops at symbol resolution; the vendor-defined constructor is missing on the host. No leak, no reclaim, no gadget.
2026-112696	AppleH16ANEInterface	kernel interface reachability	no	none observed	No primitive. The ANE kernel symbols are absent for a third-party process; the module is an honest negative.
2026-112507	XNU ipc_port.c request-table race	stale index → UAF-shaped race	no	none direct	Not reachable from the app. Device receipt: 12,288 notification registrations, 0 armed, 12,288 refused with -300 (MIG_TYPE_ERROR). No request-table entry exists, so there is no stale index to consume.
2026-113910	decmpfs chunked zlib	under-produced chunks expose uninitialised kernel heap through a file read	yes (bounded)	no	Leak only. Useful as a KASLR step; cannot write.
2026-112554	GPT partition-name scan	72-B scan over a 28-B field	yes (bounded, model)	no	Leak only. The C twin models the width; the real read runs in the storage kext.

What arbitrary kernel R/W actually requires

Every iOS kernel R/W chain needs five independent capabilities. A bug that supplies one of them is a chain step, not a chain.

1. KASLR defeat — a kernel text or heap pointer with a known relationship to the unslid base. 113910 and 112554 can supply candidates; neither guarantees a text pointer, and a heap pointer alone does not give the slide.
2. Heap grooming — deterministic placement of a victim object next to the corrupted allocation, in the same zone, at the same size class.
3. Controlled reclaim / corruption — for a UAF: free the object, reallocate the slot with attacker-influenced contents, and keep a stale reference alive. For an OOB write: a value and an offset that land on a field worth corrupting.
4. A read/write gadget — an object whose corrupted field yields a load or store of an attacker-chosen address (e.g. a length+pointer pair, a page-table entry, a thread's pcb pointer).
5. PAC / PPL bypass — kernel code pointers are PAC-signed; page tables are protected by PPL on modern devices. A data-only path can sometimes avoid both, but it still needs 1–4.

None of the six entries supplies 2–5. 112507 is the only one that could plausibly reach step 3, and reaching it requires a device, kernel symbols, and a reclaim strategy that the repository does not have.

Per-entry notes

CVE-2026-112705 — fixed constant, fixed offset

The driver indexes a layer table with the declared count and writes a constant at a fixed offset past it. There is no attacker-chosen value and no attacker-chosen address. The only observable is a kernel data abort. Calling this "R/W" would require a second bug that turns the corrupted field into a pointer; nothing in the dossier provides one. The correct classification is a reliable kernel DoS.

CVE-2026-112507 — reachability closed on the device (2026-10-31)

The staged lifecycle harness was run on the target device (iPhone19,7, iOS 27.0.1) with an ad-hoc signed build, and the race module was re-run with an armed counter:

• mach_port_request_notification(DEAD_NAME) → -300 (MIG_TYPE_ERROR), prev = 0.
• Send to the dead name → MACH_SEND_INVALID_DEST; receive → MACH_RCV_TIMED_OUT.
• kern.ipc: 12,288 registration attempts, 0 armed, 12,288 refused.
• On macOS 27 the same call was swept over 13 combinations of notification type (SEND_POSSIBLE / PORT_DESTROYED / NO_SENDERS / DEAD_NAME) and right layout (receive-only, send+receive, send-only; notify port receive or send). Every combination returned -300.

The kernel refuses to arm a request-table entry for this process. With no entry, the stale-index consumers in ipc_port.c have nothing to consume: the race cannot be driven from an unentitled third-party app, and the "survived" line from the old harness was measuring port churn, not the bug. The published fix shape (NULL checks on ipr / table) is consistent with a denial or null-dereference path, not with a reclaimable object.

Verdict: closed for this app. The remaining hypothetical is a platform process that is allowed to register notifications; that is outside Cinder27's reach.

CVE-2026-112507 — the race itself

The ring allocates receive rights, arms two notification kinds per port, tears down half the ring, then sends to the survivors. The request-table index consumers are the target of the race. A weaponised version would need:

• a win condition that is observable without panicking (a receipt, not a crash);
• a same-zone reclaim object with controllable contents (Mach ports themselves are one candidate, but the request-table entry's layout is not attacker-shaped);
• a stale consumer that dereferences the reclaimed slot after the free;
• a leak to place the reclaim object and to find the kernel base.

The POC records -300 and invalid destination receipts and reports that the interleaving survived. That is the honest limit of a userspace race harness: it can show the window exists, not that the window is controllable.

CVE-2026-113910 — the leak that was worth improving

This is the only entry where more code produces more signal. The C twin now:

• sweeps 8 chunk configurations (including produce=0, which promises 64 KiB per chunk and writes none of it);
• repeats the sweep --loop N times;
• classifies every 8-byte-aligned value as kernel-text (0xfffffff0…), kernel-data (0xffffffe0…), kernel-other, or user;
• writes the raw readback to --keep out.bin for offline analysis;
• never dereferences a candidate.

On the macOS host decmpfs does not engage for a file that already has data (the documented oracle), so the run reports zero candidates and 3.2 MB of plain 0x41 readback. On an iOS device where the chunked xattr is honoured, the same sweep is the KASLR step. It still does not write.

CVE-2026-112554 — a read-width model, not a kernel reader

The C twin builds the overlong-name GPT and walks the name field the way 27.0 does. It proves the scan width (72 B against a 28-B field) but the bytes come from the image, not from the kernel heap. Treat it as a seed/oracle model. The real read would have to run through the storage kext on a mounted image; that is not attempted on the host.

What was deliberately not done

• No attempt to fire 112705 or 65385 on the host: both can panic the kernel, and a panic is not evidence of control.
• No blind write into a guessed kernel address: with KASLR and PAC in play, a wrong guess is indistinguishable from a bug that does not work.
• No claim that 112507 is exploitable: a race receipt is not a UAF primitive until the free/reclaim/stale-dereference sequence is observed.

Bottom line

Arbitrary kernel R/W without a panic is not achievable from these six entries as shipped, and the one entry that had a theoretical UAF path (112507) is now closed by device evidence: notification registration is refused, so the request table is never armed. The maximum safe capability the lab demonstrates is:

• a repeatable kernel heap leak with pointer classification (113910);
• a read-width model for the GPT scan (112554);
• a race-window harness with receipts (112507);
• honest negatives for the write entries that never reach a controllable primitive.

The next real step is not more code in this repository; it is a device session with kernel symbols, a reclaim strategy for 112507, and a stop condition for every write.