CVE-2026-43805: IODMACommand-Zustandswettlaufanalyse und PoC

Dies ist eine Analyse, die eine fehlende Zustandssperre in IODMACommand::PerformOperation_Impl von Apples IOKit durch einen Kernel-Binärvergleich von macOS 26.5/26.6 aufgedeckt hat. In verwundbaren Builds kann CompleteDMA denselben Zustand freigeben, während PerformOperation den Bereitschaftszustand und den Speicherdeskriptor verwendet. Der Patch in 26.6 wendet das fDextLock, das beide Pfade bereits gemeinsam nutzten, auch auf PerformOperation_Impl an.

Verifizierungsstatus

Der Binärvergleich, die Aufrufziele, die Zuordnung zum öffentlichen XNU-Quellcode und das deterministische Wettlaufmodell wurden verifiziert. Der native DriverKit-Trigger im Repository wurde in einer Linux/WSL-Umgebung erstellt und konnte noch nicht mit Xcode gebaut und im A/B-Vergleich auf verwundbarem/gepatchtem macOS ausgeführt werden. Daher behauptet dieses Repository derzeit nicht, einen tatsächlichen Kernel-Panic oder einen kontrollierbaren Kernel-Write beobachtet zu haben.

Schwachstelleninformationen

Apple hat dieses Problem als Race Condition in IOKit eingestuft und erklärt, dass eine lokale App einen unerwarteten Systemabsturz oder Kernel-Speicherschreibvorgänge verursachen kann. Der Melder ist Jaeyoung Lee. Apple macOS Tahoe 26.6 Sicherheitshinweis, Apple iOS/iPadOS 26.6 Sicherheitshinweis

Produkt	Erste korrigierte Version	In der Analyse verwendetes verwundbares/korrigiertes Paar
iOS / iPadOS	26.6	iPhone 11: 26.5.2 (23F84) → 26.6 (23G71)
macOS Tahoe	26.6	KDK 26.5 (25F71) → KDK 26.6 (25G70)
macOS Sequoia	15.7.8	Nur korrigierte Version im Hinweis bestätigt
macOS Sonoma	14.8.8	Nur korrigierte Version im Hinweis bestätigt
watchOS	26.6	Nur korrigierte Version im Hinweis bestätigt

Die korrigierten Versionen für Sequoia und Sonoma können im Apple 15.7.8 Hinweis bzw. Apple 14.8.8 Hinweis eingesehen werden, watchOS im Apple 26.6 Hinweis.

Am 2026-09-27 wurde mit Kombinationen aus CVE-ID und PoC, exploit, GitHub, IOKit und dem Namen des Melders gesucht, aber es konnten kein öffentlicher Reproduktionscode oder keine Ursachenanalyse gefunden werden. Dieser Satz ist eine Beobachtung zum Zeitpunkt der Suche und bedeutet nicht, dass ein öffentlicher PoC niemals existiert.

Analysemethode

Da der XNU-Quellcode, der der korrigierten Version entspricht, nicht veröffentlicht wurde, wurde anstelle eines Quellcode-Commit-Diffs der KDK-Kernel verglichen. Die verwundbare Seite entspricht genau dem von Apple veröffentlichten xnu-12377.121.6, aber zum Analysezeitpunkt gab es kein Tag xnu-12377.161.13 für die korrigierte Seite. KDK ist ein von Apple bereitgestelltes Kernel-Symbol- und Debug-Artefakt, und Apple empfiehlt ebenfalls die Verwendung eines zur Version passenden KDK. Apple KDK Anleitung

Die für den Vergleich verwendeten Dateien sind nicht im Repository enthalten.

Kategorie	Datei	SHA-256
Verwundbares KDK DMG	Kernel_Debug_Kit_26.5_build_25F71.dmg	90ed319cd1ba6e23d1eefcee89fa1b10743f4cf60b85208ae52aa9f45543c7aa
Korrigiertes KDK DMG	Kernel_Debug_Kit_26.6_build_25G70.dmg	edaa0b3d431b43ba7dda2f0e82314b19d5476ba4089a7d8c1de18c49b3ad168b
Verwundbarer x86_64 Kernel	XNU 12377.121.6~2	f4dcaa7e59ae59f3d945c2332862772596b71e9823cc202983ba4f9d897b5bec
Korrigierter x86_64 Kernel	XNU 12377.161.13~4	754db65cb15599183ccebfaa2e4909f673de5d7da42ba4293256cb1184587efd
Verwundbarer iOS kernelcache	XNU 12377.122.8~1	7bd856548a2d170a5f8c962e9a5740290e5a4ba9a6ac39c96c927d4dd400d890
Korrigierter iOS kernelcache	XNU 12377.162.13~2	680fa3925641e2b81541c8455fc6d8d432acad9f059ac44bb48324791049c9d6

tools/diff_macho_symbols.py liest Mach-O-Symbole und Ausführungsabschnitte, stellt C++-Namen wieder her und normalisiert Verzweigungs-/Aufrufziele sowie RIP-relative Adressen, um Anweisungen pro Funktion zu vergleichen. Von den 19 geänderten Funktionen mit IOKit-Namen entsprach die Änderung des Kontrollflusses von IODMACommand::PerformOperation_Impl – abgesehen von Änderungen der Zeilennummern für Diagnosezwecke – der im Hinweis genannten „improved state handling".

IODMACommand::PerformOperation_Impl(...)
  vulnerable: 0xffffff8000a39080, 512 bytes
  fixed:      0xffffff8000a3b860, 544 bytes
  normalized similarity: 0.621429

Im korrigierten Kernel kommt folgender Aufruf neu hinzu.

mov  rax, [r14 + 0x70]     ; IODMACommand::reserved
mov  rdi, [rax + 0xc0]     ; IODMACommandInternal::fDextLock
call IOLockLock
    ; fActive 확인 및 readBytes/writeBytes 작업
mov  rax, [r14 + 0x70]
mov  rdi, [rax + 0xc0]
call IOLockUnlock

Betrachtet man den verwundbaren öffentlichen Quellcode, so erfassen PrepareForDMA_Impl und CompleteDMA_Impl bereits fDextLock. Im Gegensatz dazu prüft PerformOperation_Impl fActive und verwendet dann fMemory, readBytes, writeBytes ohne dieselbe Sperre.

Root Cause

sequenceDiagram
    participant A as Worker A: PerformOperation
    participant C as IODMACommand state
    participant B as Worker B: CompleteDMA
    A->>C: fActive == true 확인
    A->>A: 임시 버퍼 할당/준비
    B->>C: fDextLock 획득
    B->>C: complete(), fActive 감소
    B->>C: clearMemoryDescriptor(), fMemory 해제
    B-->>C: fDextLock 해제
    A->>C: readBytes/writeBytes에서 fMemory 사용
    Note over A,C: 상태 검사와 사용 사이 TOCTOU

Wenn CompleteDMA_Impl zwischen der Prüfung und der Verwendung in PerformOperation_Impl ausgeführt wird, ist der ursprünglich bestätigte Bereitschaftszustand nicht mehr gültig. fMemory ist ein OSSharedPtr<IOMemoryDescriptor>, aber dieser Pfad erwirbt weder eine separate Referenz noch eine Sperre, um den gesamten Vorgang zu schützen. Infolgedessen kann ein freigegebener oder ersetzter DMA-Speicherzustand weiterhin verwendet werden.

Nach dem Patch serialisieren die drei DMA-RPCs die Zustandsübergänge mit derselben Sperre.

flowchart LR
    P[PrepareForDMA] -->|fDextLock| S[(fActive / fMemory)]
    O[PerformOperation] -->|fDextLock 추가| S
    C[CompleteDMA] -->|fDextLock| S

Der Apple-Hinweis nennt als mögliche Auswirkung einen Kernel-Memory-Write, aber allein durch den Binärvergleich wird keine stabile Kontrolle über Schreibadresse und -wert nachgewiesen. Was hier bestätigt werden kann, ist der Lebensdauer-/Bereitschaftszustandswettlauf und die Sperre, die ihn verhindert.

PoC 1: Deterministisches Wettlaufmodell

poc/model/race_model.cpp reproduziert das problematische Interleaving, ohne Kernel-APIs aufzurufen. Im verwundbaren Pfad wird erzwungen, dass der Lifecycle-Thread den Speicher unmittelbar nach der Zustandsprüfung freigibt, und im korrigierten Pfad wird überprüft, ob dieselbe Sperre die Freigabe verzögert.

make model

Verifizierte Ausgabe:

vulnerable path: stale memory access = observed
fixed path:      stale memory access = not observed

Dieses Modell ist ein ergänzender PoC zur Verifizierung des Patch-Prinzips und nicht das tatsächliche Absturzergebnis der Apple-Kernel-Schwachstelle.