CVE-2026-43655-AppleM2ScalerCSCDriver-UAF

Divulgation publique pour CVE-2026-43655 AppleM2ScalerCSCDriver utilisation après libération

La connexion victime soumet des opérations asynchrones puis est fermée. Des connexions de remplacement sont ouvertes ensuite et définissent leur propre marqueur à 0xBEEF0002. Lors du cycle de planification suivant, le défaut observe le marqueur de remplacement (x9 = 0x00000000BEEF0002), et non le marqueur victime. Cela prouve que le planificateur a lu dans un emplacement d’opération qui avait été libéré puis réalloué à une autre connexion.

Configuration affectée

• Système d’exploitation affecté observé : iOS 26.4
• Corrigé dans : iOS 26.5 / iPadOS 26.5 / macOS Tahoe 26.5
• Kext : com.apple.driver.AppleM2ScalerCSCDriver
• Chemin client utilisateur : IOSurfaceAcceleratorClient
• Autorisations d’application utilisées par la PoC : get-task-allow uniquement
• Pas de jailbreak, pas d’autorisation de plateforme, pas d’autorisation privée Apple spéciale

Cause racine

AppleM2ScalerCSCDriver conserve un état de planificateur partagé entre les clients du scaler. La discordance de durée de vie pertinente est :

1. Un client soumet des opérations asynchrones de mise à l’échelle.
2. Ces opérations sont insérées dans l’état appartenant au planificateur.
3. La connexion client est fermée avec IOServiceClose.
4. Le stockage d’opération propre au client est libéré.
5. L’état partagé du planificateur n’est pas complètement purgé des entrées appartenant au client fermé.
6. Un passage ultérieur du planificateur traite des pointeurs d’opération obsolètes.

Le chemin de démontage ne supprime pas les entrées du planificateur en attente du client en cours de fermeture du tas partagé du planificateur. Le planificateur lit et écrit ensuite des champs à travers ces pointeurs obsolètes.

Champs importants observés durant l’analyse :

Le comportement de l’allocateur d’opérations rend le bug observable : les emplacements d’opération libérés peuvent être réutilisés par des opérations ultérieures provenant de connexions différentes. En fermant une connexion victime et en ouvrant immédiatement de nouvelles connexions de remplacement (spray), la PoC peut faire en sorte que des entrées obsolètes du planificateur pointent vers de la mémoire désormais possédée par les connexions de remplacement.

Pourquoi x9 = 0xBEEF0002 prouve l’UAF

La PoC utilise une distinction victime/remplacement :

1. La connexion victime définit le marqueur 0xDEAD0001.
2. La victime soumet 50 opérations asynchrones de mise à l’échelle.
3. La connexion victime est fermée, libérant les objets d’opération de la victime.
4. Les connexions de remplacement définissent le marqueur 0xBEEF0002.
5. Les opérations de remplacement réutilisent les emplacements du pool d’opérations libérées.
6. Le planificateur traite ensuite les entrées obsolètes de la victime.

Si le planificateur lisait encore des objets vivants appartenant à la victime, la valeur observée serait 0xDEAD0001. Au lieu de cela, le défaut reproduit observe 0xBEEF0002, la valeur écrite par les connexions de remplacement. C’est la preuve clé que le planificateur déréférence un pointeur obsolète vers une mémoire du noyau libérée et réutilisée.

Cela montre également un impact entre connexions : l’entrée du planificateur a été créée par une connexion, mais la mémoire qu’elle a ensuite touchée a été recyclée pour une autre connexion. Lors des exécutions reproduites, l’activité finale du planificateur pouvait être déclenchée par l’activité normale de SpringBoard/compositeur/UI plutôt que par le processus PoC d’origine.

Impact

• Lecture noyau depuis une mémoire d’opération libérée/réutilisée.
• Écritures noyau vers des offsets fixes dans la mémoire d’opération libérée/réutilisée durant les mises à jour de comptabilité/état du planificateur.
• Effet entre connexions car le tas du planificateur est partagé entre les utilisateurs du scaler.
• Comportement de déclenchement inter-processus car tout processus ultérieur qui pilote la planification du scaler peut provoquer le traitement de l’entrée obsolète.
• L’état obsolète du planificateur peut survivre à la fenêtre d’exécution immédiate de l’application PoC d’origine et se déclencher lors d’un cycle ultérieur du planificateur.

L’avis public d’Apple décrit l’impact comme : « Une application pourrait être capable de provoquer une terminaison inattendue du système ou de lire la mémoire du noyau. »

Séquence de reproduction sur appareil physique

Détail important de la reproduction : après avoir tapé TEARDOWN UAF, l’appareil ne plante pas nécessairement immédiatement. La PoC prépare d’abord l’état obsolète du planificateur. Le bug se déclenche lors du cycle de planification suivant, ce qui en pratique se produit lorsque l’activité de SpringBoard/compositeur pilote le scaler. Dans ma reproduction sur appareil physique, j’ai déclenché ce cycle de planification en tapant/interagissant avec la Dynamic Island après que la PoC a fini de préparer l’état obsolète du planificateur.

Étapes :

1. Redémarrez l’appareil affecté avant d’exécuter la PoC.
2. Installez et lancez ScalerTeardownUAF.ipa.
3. Tapez TEARDOWN UAF.
4. La PoC ouvre une connexion victime AppleM2ScalerCSCDriver.
5. La PoC crée des objets IOSurface source/destination.
6. La PoC soumet une opération de mise à l’échelle de base synchrone.
7. La PoC définit les données de crédit/marqueur du sélecteur 10 à 0xDEAD0001 sur la connexion victime.
8. La PoC soumet 50 opérations asynchrones sur la connexion victime.
9. La PoC ferme la connexion victime avec IOServiceClose, libérant les objets d’opération appartenant à la victime tandis que les entrées obsolètes du planificateur subsistent.
10. La PoC ouvre 50 connexions de remplacement.
11. Chaque connexion de remplacement définit les données de crédit/marqueur du sélecteur 10 à 0xBEEF0002.
12. La PoC soumet des opérations asynchrones supplémentaires sur les connexions de remplacement pour réutiliser les emplacements d’opération libérés et maintenir une pression sur le planificateur.
13. Lorsque l’application invite au déclenchement, tapez/interagissez avec la Dynamic Island pour provoquer une activité de SpringBoard/compositeur et piloter le planificateur du scaler.
14. L’appareil plante/redémarre lorsque l’entrée obsolète du planificateur est traitée.
15. Après le redémarrage, vérifiez que l’état des registres de panique contient x9 = 0x00000000BEEF0002.

Condition de preuve attendue :

• x9 = 0x00000000BEEF0002 signifie que le planificateur a lu le marqueur de remplacement dans une mémoire qui appartenait à l’origine à l’opération victime libérée.
• 0xBEEF0002 n’est pas le marqueur victime ; c’est le marqueur de la connexion de remplacement.
• Par conséquent, la lecture observée par le planificateur a eu lieu après la libération et la réutilisation.

Comportement de la PoC

Le code source inclus effectue la séquence suivante :

Le fichier source pertinent est ScalerTeardownUAF.m.

Construction

Fichiers du dépôt

Chronologie

• Crash initial découvert en testant le comportement de AppleM2ScalerCSCDriver.
• UAF prouvé avec la distinction de marqueurs victime/remplacement : victime 0xDEAD0001, remplacement 0xBEEF0002.
• Reproduction sur appareil physique confirmée en déclenchant le cycle de planification suivant via l’activité du compositeur Dynamic Island / SpringBoard.
• Apple a corrigé le problème dans la version 26.5 et a attribué le CVE-2026-43655.