CVE-2026-43655-AppleM2ScalerCSCDriver-UAF

Divulgazione pubblica per CVE-2026-43655 AppleM2ScalerCSCDriver use-after-free

La connessione vittima invia operazioni asincrone e poi viene chiusa. Le connessioni sostitutive vengono aperte successivamente e impostano il proprio marker a 0xBEEF0002. Quando viene eseguito il successivo ciclo di scheduling dello scaler, il fault osserva il marker sostitutivo (x9 = 0x00000000BEEF0002), non il marker della vittima. Ciò dimostra che lo scheduler ha letto da uno slot di operazione che era stato liberato e poi riallocato a una connessione diversa.

Configurazione interessata

• Sistema operativo interessato osservato: iOS 26.4
• Risolto in: iOS 26.5 / iPadOS 26.5 / macOS Tahoe 26.5
• Kext: com.apple.driver.AppleM2ScalerCSCDriver
• Percorso user-client: IOSurfaceAcceleratorClient
• Autorizzazioni app utilizzate dalla PoC: solo get-task-allow
• Nessun jailbreak, nessuna autorizzazione di piattaforma, nessuna autorizzazione privata Apple speciale

Causa principale

AppleM2ScalerCSCDriver mantiene lo stato dello scheduler condiviso tra i client dello scaler. Il disallineamento del ciclo di vita rilevante è:

1. Un client invia operazioni asincrone dello scaler.
2. Tali operazioni vengono inserite nello stato di proprietà dello scheduler.
3. La connessione del client viene chiusa con IOServiceClose.
4. Lo storage delle operazioni per-client viene liberato.
5. Lo stato condiviso dello scheduler non viene completamente ripulito dalle voci appartenenti al client chiuso.
6. Un successivo passaggio dello scheduler elabora puntatori di operazioni obsoleti.

Il percorso di teardown non rimuove le voci dello scheduler in sospeso del client in chiusura dall'heap condiviso dello scheduler. Lo scheduler successivamente legge e scrive campi attraverso quei puntatori obsoleti.

Campi importanti osservati durante l'analisi:

Il comportamento dell'allocatore di operazioni rende osservabile il bug: gli slot di operazioni liberati possono essere riutilizzati da operazioni successive di connessioni diverse. Chiudendo una connessione vittima e aprendo immediatamente nuove connessioni spray, la PoC può causare voci dello scheduler obsolete che puntano a memoria ora di proprietà delle connessioni spray.

Perché x9 = 0xBEEF0002 dimostra UAF

La PoC utilizza una distinzione vittima/spray:

1. La connessione vittima imposta il marker 0xDEAD0001.
2. La vittima invia 50 operazioni asincrone dello scaler.
3. La connessione vittima viene chiusa, liberando gli oggetti delle operazioni della vittima.
4. Le connessioni spray impostano il marker 0xBEEF0002.
5. Le operazioni spray riutilizzano gli slot del pool di operazioni liberato.
6. Lo scheduler elabora successivamente le voci dello scheduler obsoleto della vittima.

Se lo scheduler stesse ancora leggendo oggetti live di proprietà della vittima, il valore osservato sarebbe 0xDEAD0001. Invece, il fault riprodotto osserva 0xBEEF0002, il valore scritto dalle connessioni spray sostitutive. Questa è la prova chiave che lo scheduler sta dereferenziando un puntatore obsoleto in memoria del kernel liberata e riutilizzata.

Questo mostra anche l'impatto cross-connessione: la voce dello scheduler è stata creata da una connessione, ma la memoria che ha successivamente toccato era stata riciclata per un'altra connessione. Nelle esecuzioni riprodotte, l'attività finale dello scheduler potrebbe essere guidata dall'attività normale di SpringBoard/compositor/UI piuttosto che dal processo originale della PoC.

Impatto

• Lettura del kernel dalla memoria di operazioni liberata/riutilizzata.
• Scritture del kernel a offset fissi nella memoria di operazioni liberata/riutilizzata durante gli aggiornamenti di contabilità/stato dello scheduler.
• Effetto cross-connessione perché l'heap dello scheduler è condiviso tra gli utenti dello scaler.
• Comportamento di attivazione cross-process perché qualsiasi processo successivo che guidi lo scheduling dello scaler può causare l'elaborazione della voce obsoleta.
• Lo stato obsoleto dello scheduler può sopravvivere alla finestra di esecuzione immediata dell'app PoC originale e attivarsi in un successivo ciclo dello scheduler.

L'avviso pubblico di Apple descrive l'impatto come: “Un'app potrebbe causare una terminazione inaspettata del sistema o leggere la memoria del kernel.”

Sequenza di riproduzione su dispositivo fisico

Dettaglio importante per la riproduzione: dopo aver toccato TEARDOWN UAF, il dispositivo non va necessariamente in panico immediatamente. La PoC prepara prima lo stato obsoleto dello scheduler. Il bug si attiva al successivo ciclo di scheduling dello scaler, che in pratica si verifica quando l'attività di SpringBoard/compositor guida lo scaler. Nella mia riproduzione su dispositivo fisico, ho attivato quel ciclo dello scheduler toccando/interagendo con la Dynamic Island dopo che la PoC ha finito di preparare lo stato obsoleto dello scheduler.

Passaggi:

1. Riavviare il dispositivo interessato prima di eseguire la PoC.
2. Installare e avviare ScalerTeardownUAF.ipa.
3. Toccare TEARDOWN UAF.
4. La PoC apre una connessione vittima AppleM2ScalerCSCDriver.
5. La PoC crea oggetti IOSurface di origine/destinazione.
6. La PoC invia un'operazione sincrona di base dello scaler.
7. La PoC imposta i dati di credito/marker del selettore 10 a 0xDEAD0001 sulla connessione vittima.
8. La PoC invia 50 operazioni asincrone sulla connessione vittima.
9. La PoC chiude la connessione vittima con IOServiceClose, liberando gli oggetti delle operazioni di proprietà della vittima mentre rimangono voci dello scheduler obsolete.
10. La PoC apre 50 connessioni spray.
11. Ogni connessione spray imposta i dati di credito/marker del selettore 10 a 0xBEEF0002.
12. La PoC invia ulteriori operazioni asincrone sulle connessioni spray per riutilizzare gli slot di operazioni liberati e mantenere attiva la pressione dello scheduler.
13. Quando l'app richiede l'attivazione, toccare/interagire con la Dynamic Island per causare attività di SpringBoard/compositor e guidare lo scheduler dello scaler.
14. Il dispositivo va in panico/riavvia quando viene elaborata la voce obsoleta dello scheduler.
15. Dopo il riavvio, verificare che lo stato del registro di panico contenga x9 = 0x00000000BEEF0002.

Condizione di prova attesa:

• x9 = 0x00000000BEEF0002 significa che lo scheduler ha letto il marker spray dalla memoria che apparteneva originariamente all'operazione vittima liberata.
• 0xBEEF0002 non è il marker della vittima; è il marker della connessione sostitutiva.
• Pertanto la lettura osservata dello scheduler è avvenuta dopo la liberazione e il riutilizzo.

Comportamento della PoC

Il codice sorgente incluso esegue la seguente sequenza:

Il file sorgente rilevante è ScalerTeardownUAF.m.

Build

File del repository

Cronologia

• Crash iniziale trovato durante il test del comportamento di AppleM2ScalerCSCDriver.
• UAF provato con distinzione dei marker vittima/spray: vittima 0xDEAD0001, spray 0xBEEF0002.
• Riproduzione su dispositivo fisico confermata attivando il successivo ciclo di scheduling dello scaler tramite l'attività del compositor di Dynamic Island / SpringBoard.
• Apple ha risolto il problema nella linea di rilascio 26.5 e ha assegnato CVE-2026-43655.