CVE-2026-43655: Use-after-free im gemeinsamen Scheduler von AppleM2ScalerCSCDriver

Öffentliche technische Offenlegung für CVE-2026-43655, ein Use-after-Free im AppleM2ScalerCSCDriver / IOSurfaceAccelerator, der aus der standardmäßigen iOS-App-Sandbox ohne besondere Berechtigungen erreichbar ist.

Apple hat dieses Problem in iOS 26.5 / iPadOS 26.5 / macOS Tahoe 26.5 behoben. Dieses Repository enthält den Objective-C-Proof-of-Concept-Quellcode, minimale Berechtigungen, ein gebautes IPA und die technische Beschreibung, die zum Verständnis und zur Reproduktion des Problems auf einem betroffenen Gerät erforderlich sind.

Zusammenfassung

Der Fehler ist ein Lebensdauerfehler beim Abbau im Scaler-Scheduler. Ein Benutzerprozess kann asynchrone Scaler-Operationen einreichen, die IOSurfaceAcceleratorClient-Verbindung schließen, die diese Operationen besitzt, und veraltete Einträge in einer treiberglobalen Scheduler-Struktur hinterlassen. Ein späterer Scheduler-Durchlauf kann dann Einträge verarbeiten, die immer noch auf bereits freigegebenen und wiederverwendeten Operationsspeicher verweisen.

Der PoC demonstriert den Lebensdauerfehler mit zwei verschiedenen Markierungswerten:

• Verbindungsmarkierung des Opfers: 0xDEAD0001
• Spray-/Ersatzverbindungsmarkierung: 0xBEEF0002

Die Opferverbindung reicht asynchrone Operationen ein und wird dann geschlossen. Ersatzverbindungen werden danach geöffnet und setzen ihre eigene Markierung auf 0xBEEF0002. Wenn der nächste Scaler-Scheduling-Zyklus läuft, beobachtet der Fehler die Ersatzmarkierung (x9 = 0x00000000BEEF0002), nicht die Opfermarkierung. Das beweist, dass der Scheduler aus einem Operationsslot gelesen hat, der freigegeben und dann einer anderen Verbindung zugewiesen wurde.

Betroffene Konfiguration

• Beobachtetes betroffenes Betriebssystem: iOS 26.4
• Behoben in: iOS 26.5 / iPadOS 26.5 / macOS Tahoe 26.5
• Kext: com.apple.driver.AppleM2ScalerCSCDriver
• User-Client-Pfad: IOSurfaceAcceleratorClient
• Im PoC verwendete App-Berechtigungen: nur get-task-allow
• Kein Jailbreak, keine Plattformberechtigung, keine spezielle private Apple-Berechtigung

Grundursache

AppleM2ScalerCSCDriver hält den Scheduler-Zustand gemeinsam für alle Scaler-Clients. Die relevante Lebensdauerinkonsistenz ist:

1. Ein Client reicht asynchrone Scaler-Operationen ein.
2. Diese Operationen werden in den scheduler-eigenen Zustand eingefügt.
3. Die Client-Verbindung wird mit IOServiceClose geschlossen.
4. Der pro-Client-Operationsspeicher wird freigegeben.
5. Der gemeinsame Scheduler-Zustand wird nicht vollständig von Einträgen des geschlossenen Clients bereinigt.
6. Ein späterer Scheduler-Durchlauf verarbeitet veraltete Operationszeiger.

Der Abbau-Pfad entfernt die ausstehenden Scheduler-Einträge des schließenden Clients nicht aus dem gemeinsamen Scheduler-Heap. Der Scheduler liest und schreibt später Felder durch diese veralteten Zeiger.

Wichtige während der Analyse beobachtete Felder:

Das Verhalten des Operations-Allokators macht den Fehler beobachtbar: Freigegebene Operationsslots können von späteren Operationen anderer Verbindungen wiederverwendet werden. Durch Schließen einer Opferverbindung und sofortiges Sprayen neuer Verbindungen kann der PoC veraltete Scheduler-Einträge dazu bringen, auf Speicher zu zeigen, der jetzt den Spray-Verbindungen gehört.

Warum x9 = 0xBEEF0002 den Use-After-Free beweist

Der PoC verwendet eine Unterscheidung zwischen Opfer und Spray:

1. Opferverbindung setzt Markierung 0xDEAD0001.
2. Opfer reicht 50 asynchrone Scaler-Operationen ein.
3. Opferverbindung wird geschlossen, wodurch die Opfer-Operationsobjekte freigegeben werden.
4. Spray-Verbindungen setzen Markierung 0xBEEF0002.
5. Spray-Operationen nutzen den freigegebenen Operationspool erneut.
6. Der Scheduler verarbeitet später die veralteten Opfer-Scheduler-Einträge.

Wenn der Scheduler immer noch live vom Opfer besessene Objekte lesen würde, wäre der beobachtete Wert 0xDEAD0001. Stattdessen beobachtet der reproduzierte Fehler 0xBEEF0002, den von den ersetzenden Spray-Verbindungen geschriebenen Wert. Das ist der Hauptbeweis, dass der Scheduler einen veralteten Zeiger auf freigegebenen und wiederverwendeten Kernel-Speicher dereferenziert.

Dies zeigt auch eine verbindungsübergreifende Auswirkung: Der Scheduler-Eintrag wurde von einer Verbindung erstellt, aber der Speicher, den er später berührte, wurde für eine andere Verbindung recycelt. In reproduzierten Läufen konnte die endgültige Scheduler-Aktivität durch normale SpringBoard-/Compositor-/UI-Aktivität und nicht durch den ursprünglichen PoC-Prozess ausgelöst werden.

Auswirkungen

• Kernel liest aus freigegebenem/wiederverwendetem Operationsspeicher.
• Kernel schreibt in feste Offsets in freigegebenem/wiederverwendetem Operationsspeicher während Scheduler-Accounting-/Zustandsaktualisierungen.
• Verbindungsübergreifender Effekt, da der Scheduler-Heap von allen Scaler-Benutzern gemeinsam genutzt wird.
• Prozessübergreifendes Trigger-Verhalten, da jeder spätere Prozess, der das Scaler-Scheduling antreibt, die Verarbeitung des veralteten Eintrags verursachen kann.
• Veralteter Scheduler-Zustand kann das unmittelbare Ausführungsfenster der ursprünglichen PoC-App überdauern und bei einem späteren Scheduler-Zyklus auslösen.

Die öffentliche Apple-Beratung beschreibt die Auswirkungen als: “Eine App kann möglicherweise einen unerwarteten Systemabbruch verursachen oder Kernel-Speicher lesen.”

Physische Geräte-Reproduktionssequenz

Wichtiges Reproduktionsdetail: Nach dem Tippen auf TEARDOWN UAF stürzt das Gerät nicht unbedingt sofort ab. Der PoC erstellt zuerst einen veralteten Scheduler-Zustand. Der Fehler tritt beim nächsten Scaler-Scheduling-Zyklus auf, der in der Praxis auftritt, wenn SpringBoard-/Compositor-Aktivität den Scaler antreibt. Bei meiner physischen Geräte-Reproduktion habe ich diesen Scheduler-Zyklus durch Tippen/Interagieren mit der Dynamic Island ausgelöst, nachdem der PoC den veralteten Scheduler-Zustand erstellt hatte.

Schritte:

1. Starten Sie das betroffene Gerät neu, bevor Sie den PoC ausführen.
2. Installieren und starten Sie ScalerTeardownUAF.ipa.
3. Tippen Sie auf TEARDOWN UAF.
4. Der PoC öffnet eine Opfer-Verbindung zu AppleM2ScalerCSCDriver.
5. Der PoC erstellt Quell-/Ziel-IOSurface-Objekte.
6. Der PoC reicht eine synchrone Basislinien-Scaler-Operation ein.
7. Der PoC setzt Selektor-10-Credit-/Markierungsdaten auf 0xDEAD0001 auf der Opfer-Verbindung.
8. Der PoC reicht 50 asynchrone Operationen auf der Opfer-Verbindung ein.
9. Der PoC schließt die Opfer-Verbindung mit IOServiceClose, wodurch die vom Opfer besessenen Operationsobjekte freigegeben werden, während veraltete Scheduler-Einträge bestehen bleiben.
10. Der PoC öffnet 50 Spray-Verbindungen.
11. Jede Spray-Verbindung setzt Selektor-10-Credit-/Markierungsdaten auf 0xBEEF0002.
12. Der PoC reicht zusätzliche asynchrone Operationen auf den Spray-Verbindungen ein, um freigegebene Operationsslots wiederzuverwenden und den Scheduler-Druck aufrechtzuerhalten.
13. Wenn die App zur Auslösung auffordert, tippen/interagieren Sie mit der Dynamic Island, um SpringBoard-/Compositor-Aktivität zu verursachen und den Scaler-Scheduler anzutreiben.
14. Das Gerät stürzt ab/startet neu, wenn der veraltete Scheduler-Eintrag verarbeitet wird.
15. Überprüfen Sie nach dem Neustart, ob der Panic-Register-Zustand x9 = 0x00000000BEEF0002 enthält.

Erwartete Beweisbedingung:

• x9 = 0x00000000BEEF0002 bedeutet, dass der Scheduler die Spray-Markierung aus Speicher gelesen hat, der ursprünglich zur freigegebenen Opfer-Operation gehörte.
• 0xBEEF0002 ist nicht die Opfermarkierung; es ist die Ersatzverbindungsmarkierung.
• Daher fand der beobachtete Scheduler-Lesevorgang nach Freigabe und Wiederverwendung statt.

PoC-Verhalten

Der enthaltene Quellcode führt die folgende Sequenz aus:

Öffne Opfer-Verbindung
Erstelle IOSurface-Quell-/Ziel-Paar
Reiche synchrone Basislinien-Scaler-Anfrage ein
Setze Opfer-Markierung = 0xDEAD0001 über Selektor 10
Reiche 50 asynchrone Scaler-Operationen ein
Schließe Opfer-Verbindung
Öffne 50 Spray-Verbindungen
Setze Spray-Markierung = 0xBEEF0002 über Selektor 10
Reiche wiederholte asynchrone Scaler-Operationen auf Spray-Verbindungen ein
Warte auf SpringBoard-/Compositor-Scheduler-Trigger

Die relevante Quelldatei ist ScalerTeardownUAF.m.

Build

xcrun -sdk iphoneos clang -framework Foundation -framework UIKit -framework IOKit \
  -framework IOSurface -isysroot $(xcrun --sdk iphoneos --show-sdk-path) \
  -arch arm64 -arch arm64e -miphoneos-version-min=16.0 -fobjc-arc \
  -o iPhoneProbe.app/iPhoneProbe ScalerTeardownUAF.m
ldid -S entitlements.plist iPhoneProbe.app/iPhoneProbe
mkdir -p /tmp/pkg/Payload
cp -r iPhoneProbe.app /tmp/pkg/Payload/
cd /tmp/pkg && zip -qr ScalerTeardownUAF.ipa Payload

Repository-Dateien

Zeitplan

• Erster Absturz beim Testen des AppleM2ScalerCSCDriver-Verhaltens gefunden.
• UAF mit Unterscheidung zwischen Opfer-/Spray-Markierung bewiesen: Opfer 0xDEAD0001, Spray 0xBEEF0002.
• Reproduktion auf physischem Gerät bestätigt durch Auslösen des nächsten Scaler-Scheduling-Zyklus durch Dynamic Island / SpringBoard-Compositor-Aktivität.
• Apple hat das Problem in der 26.5-Release-Reihe behoben und CVE-2026-43655 zugewiesen.