CVE-2026-43655-AppleM2ScalerCSCDriver-UAF

Divulgación pública para CVE-2026-43655 AppleM2ScalerCSCDriver use-after-free

La conexión víctima envía operaciones asíncronas y luego se cierra. Las conexiones de reemplazo se abren después y establecen su propio marcador en 0xBEEF0002. Cuando se ejecuta el siguiente ciclo de planificación del escalador, la falla observa el marcador de reemplazo (x9 = 0x00000000BEEF0002), no el marcador de la víctima. Esto demuestra que el planificador leyó desde una ranura de operación que había sido liberada y luego reasignada a una conexión diferente.

Configuración afectada

• SO afectado observado: iOS 26.4
• Corregido en: iOS 26.5 / iPadOS 26.5 / macOS Tahoe 26.5
• Kext: com.apple.driver.AppleM2ScalerCSCDriver
• Ruta de cliente de usuario: IOSurfaceAcceleratorClient
• Permisos de aplicación utilizados por la PoC: solo get-task-allow
• Sin jailbreak, sin permiso de plataforma, sin permiso privado especial de Apple

Causa raíz

AppleM2ScalerCSCDriver mantiene el estado del planificador compartido entre los clientes del escalador. El desajuste de ciclo de vida relevante es:

1. Un cliente envía operaciones asíncronas del escalador.
2. Esas operaciones se insertan en el estado propiedad del planificador.
3. La conexión del cliente se cierra con IOServiceClose.
4. Se libera el almacenamiento de operaciones por cliente.
5. El estado compartido del planificador no se purga completamente de las entradas pertenecientes al cliente cerrado.
6. Una pasada posterior del planificador procesa punteros de operaciones obsoletos.

La ruta de destrucción no elimina las entradas pendientes del planificador del cliente que se cierra del montón compartido del planificador. El planificador posteriormente lee y escribe campos a través de esos punteros obsoletos.

Campos importantes observados durante el análisis:

El comportamiento del asignador de operaciones hace que el error sea observable: las ranuras de operación liberadas pueden ser reutilizadas por operaciones posteriores de diferentes conexiones. Al cerrar una conexión víctima y rociar inmediatamente nuevas conexiones, la PoC puede hacer que las entradas obsoletas del planificador apunten a memoria ahora propiedad de las conexiones de rocío.

Por qué x9 = 0xBEEF0002 demuestra UAF

La PoC utiliza una distinción víctima/rocío:

1. La conexión víctima establece el marcador 0xDEAD0001.
2. La víctima envía 50 operaciones asíncronas del escalador.
3. La conexión víctima se cierra, liberando los objetos de operación de la víctima.
4. Las conexiones de rocío establecen el marcador 0xBEEF0002.
5. Las operaciones de rocío reutilizan las ranuras del grupo de operaciones liberadas.
6. El planificador posteriormente procesa las entradas obsoletas de la víctima.

Si el planificador aún estuviera leyendo objetos vivos propiedad de la víctima, el valor observado sería 0xDEAD0001. En cambio, la falla reproducida observa 0xBEEF0002, el valor escrito por las conexiones de rocío de reemplazo. Esa es la prueba clave de que el planificador está desreferenciando un puntero obsoleto hacia memoria del núcleo liberada y reutilizada.

Esto también muestra el impacto entre conexiones: la entrada del planificador fue creada por una conexión, pero la memoria que luego tocó había sido reciclada para otra conexión. En ejecuciones reproducidas, la actividad final del planificador pudo ser impulsada por la actividad normal de SpringBoard/compositor/UI en lugar del proceso original de la PoC.

Impacto

• Lectura del núcleo desde memoria de operación liberada/reutilizada.
• Escrituras del núcleo en desplazamientos fijos en memoria de operación liberada/reutilizada durante actualizaciones de contabilidad/estado del planificador.
• Efecto entre conexiones porque el montón del planificador está compartido entre usuarios del escalador.
• Comportamiento de activación entre procesos porque cualquier proceso posterior que impulse la planificación del escalador puede hacer que se procese la entrada obsoleta.
• El estado obsoleto del planificador puede sobrevivir a la ventana de ejecución inmediata de la aplicación PoC original y activarse en un ciclo de planificación posterior.

El aviso público de Apple describe el impacto como: “Una aplicación puede causar una terminación inesperada del sistema o leer memoria del núcleo.”

Secuencia de reproducción en dispositivo físico

Detalle importante de reproducción: después de tocar TEARDOWN UAF, el dispositivo no necesariamente entra en pánico inmediatamente. La PoC primero prepara el estado obsoleto del planificador. El error se activa en el siguiente ciclo de planificación del escalador, que en la práctica ocurre cuando la actividad de SpringBoard/compositor impulsa el escalador. En mi reproducción en dispositivo físico, activé ese ciclo de planificación tocando/interactuando con la Dynamic Island después de que la PoC terminara de preparar el estado obsoleto del planificador.

Pasos:

1. Reinicie el dispositivo afectado antes de ejecutar la PoC.
2. Instale e inicie ScalerTeardownUAF.ipa.
3. Toque TEARDOWN UAF.
4. La PoC abre una conexión víctima de AppleM2ScalerCSCDriver.
5. La PoC crea objetos IOSurface de origen/destino.
6. La PoC envía una operación de escalador de línea base síncrona.
7. La PoC establece los datos de crédito/marcador del selector 10 en 0xDEAD0001 en la conexión víctima.
8. La PoC envía 50 operaciones asíncronas en la conexión víctima.
9. La PoC cierra la conexión víctima con IOServiceClose, liberando los objetos de operación propiedad de la víctima mientras las entradas obsoletas del planificador permanecen.
10. La PoC abre 50 conexiones de rocío.
11. Cada conexión de rocío establece los datos de crédito/marcador del selector 10 en 0xBEEF0002.
12. La PoC envía operaciones asíncronas adicionales en las conexiones de rocío para reutilizar las ranuras de operación liberadas y mantener la presión del planificador activa.
13. Cuando la aplicación solicita el disparador, toque/interactúe con la Dynamic Island para causar actividad de SpringBoard/compositor e impulsar el planificador del escalador.
14. El dispositivo entra en pánico/reinicia cuando se procesa la entrada obsoleta del planificador.
15. Después del reinicio, verifique que el estado del registro de pánico contenga x9 = 0x00000000BEEF0002.

Condición de prueba esperada:

• x9 = 0x00000000BEEF0002 significa que el planificador leyó el marcador de rocío de la memoria que originalmente pertenecía a la operación víctima liberada.
• 0xBEEF0002 no es el marcador de la víctima; es el marcador de la conexión de reemplazo.
• Por lo tanto, la lectura observada del planificador ocurrió después de la liberación y reutilización.

Comportamiento de la PoC

El código fuente incluido realiza la siguiente secuencia:

El archivo fuente relevante es ScalerTeardownUAF.m.

Compilación

Archivos del repositorio

Cronología

• Fallo inicial encontrado mientras se probaba el comportamiento de AppleM2ScalerCSCDriver.
• UAF demostrado con distinción de marcador víctima/rocío: víctima 0xDEAD0001, rocío 0xBEEF0002.
• Reproducción en dispositivo físico confirmada al disparar el siguiente ciclo de planificación del escalador a través de la actividad de Dynamic Island / compositor de SpringBoard.
• Apple corrigió el problema en la línea de versiones 26.5 y asignó CVE-2026-43655.