CVE-2026-43655: use-after-free dello scheduler condiviso di AppleM2ScalerCSCDriver

Divulgazione tecnica pubblica per CVE-2026-43655, un use-after-free di AppleM2ScalerCSCDriver / IOSurfaceAccelerator raggiungibile dal sandbox predefinito delle app iOS senza autorizzazioni speciali.

Apple ha risolto questo problema in iOS 26.5 / iPadOS 26.5 / macOS Tahoe 26.5. Questo repository contiene il codice sorgente della proof-of-concept in Objective-C, le autorizzazioni minime, un IPA compilato e la documentazione tecnica necessaria per comprendere e riprodurre il problema su un dispositivo interessato.

Riepilogo

Il bug è un errore di teardown/ciclo di vita nello scheduler dello scaler. Un processo utente può inviare operazioni asincrone dello scaler, chiudere la connessione IOSurfaceAcceleratorClient che possiede tali operazioni e lasciare voci obsolete in una struttura dello scheduler globale del driver. Un successivo passaggio dello scheduler può quindi elaborare voci che puntano ancora a storage di operazioni già liberato e riutilizzato.

La PoC dimostra il bug del ciclo di vita con due valori di marker distinti:

• marker della connessione vittima: 0xDEAD0001
• marker della connessione spray/sostitutiva: 0xBEEF0002

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:

Offset	Comportamento dello scheduler
operation + 0xc94	letto come valore di credito/marker utilizzato dal percorso di risoluzione del credito
operation + 0xc1c	scritto dal percorso di contabilità crediti dello scheduler
operation + 0x1fe4	scritto dal percorso di aggiornamento stato/flag dello scheduler

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: