CVE-2026-43655-AppleM2ScalerCSCDriver-UAF

Публичное раскрытие для CVE-2026-43655 AppleM2ScalerCSCDriver use-after-free

Соединение-жертва отправляет асинхронные операции, а затем закрывается. После этого открываются соединения-замены и устанавливают свой маркер в 0xBEEF0002. Когда запускается следующий цикл планирования скалера, сбой наблюдает маркер замены (x9 = 0x00000000BEEF0002), а не маркер жертвы. Это доказывает, что планировщик прочитал из слота операции, который был освобождён, а затем перераспределён другому соединению.

Затрагиваемая конфигурация

• Наблюдаемая уязвимая ОС: iOS 26.4
• Исправлено в: iOS 26.5 / iPadOS 26.5 / macOS Tahoe 26.5
• Kext: com.apple.driver.AppleM2ScalerCSCDriver
• Путь пользовательского клиента: IOSurfaceAcceleratorClient
• Привилегии приложения, используемые PoC: только get-task-allow
• Без джейлбрейка, без платформенной привилегии, без специальной приватной привилегии Apple

Первопричина

AppleM2ScalerCSCDriver хранит состояние планировщика, общее для всех клиентов скалера. Соответствующее несоответствие времени жизни:

1. Клиент отправляет асинхронные операции скалера.
2. Эти операции вставляются в состояние, принадлежащее планировщику.
3. Соединение клиента закрывается с помощью IOServiceClose.
4. Хранилище операций, специфичное для клиента, освобождается.
5. Общее состояние планировщика не полностью очищается от записей, принадлежащих закрытому клиенту.
6. Последующий проход планировщика обрабатывает устаревшие указатели на операции.

Путь разрушения не удаляет ожидающие записи планировщика закрывающегося клиента из общей кучи планировщика. Планировщик впоследствии читает и записывает поля через эти устаревшие указатели.

Важные поля, наблюдаемые во время анализа:

Поведение аллокатора операций делает ошибку наблюдаемой: освобождённые слоты операций могут быть повторно использованы последующими операциями из других соединений. Закрывая соединение-жертву и сразу же распыляя новые соединения, PoC может заставить устаревшие записи планировщика указывать на память, теперь принадлежащую соединениям-заменам.

Почему x9 = 0xBEEF0002 доказывает UAF

PoC использует различие жертва/замена:

1. Соединение-жертва устанавливает маркер 0xDEAD0001.
2. Жертва отправляет 50 асинхронных операций скалера.
3. Соединение-жертва закрывается, освобождая объекты операций жертвы.
4. Соединения-замены устанавливают маркер 0xBEEF0002.
5. Операции замены повторно используют освобождённые слоты пула операций.
6. Планировщик позже обрабатывает устаревшие записи планировщика жертвы.

Если бы планировщик всё ещё читал живые объекты, принадлежащие жертве, наблюдаемое значение было бы 0xDEAD0001. Вместо этого воспроизведённый сбой наблюдает 0xBEEF0002 — значение, записанное соединениями-заменами (спрей). Это ключевое доказательство того, что планировщик разыменовывает устаревший указатель на освобождённую и повторно использованную память ядра.

Это также показывает влияние на несколько соединений: запись планировщика была создана одним соединением, но память, к которой она позже обратилась, была переработана для другого соединения. В воспроизведённых запусках конечная активность планировщика могла быть вызвана обычной активностью SpringBoard/композитора/интерфейса, а не исходным процессом PoC.

Воздействие

• Чтение ядра из освобождённой/повторно использованной памяти операций.
• Запись ядра по фиксированным смещениям в освобождённую/повторно использованную память операций во время учёта/обновления состояния планировщика.
• Межсоединённый эффект, поскольку куча планировщика является общей для пользователей скалера.
• Межпроцессное поведение триггера, поскольку любой последующий процесс, который управляет планированием скалера, может вызвать обработку устаревшей записи.
• Устаревшее состояние планировщика может пережить непосредственное окно выполнения исходного приложения PoC и сработать в следующем цикле планировщика.

Публичное уведомление Apple описывает воздействие как: «Приложение может вызвать неожиданное завершение системы или прочитать память ядра».

Последовательность воспроизведения на физическом устройстве

Важная деталь воспроизведения: после нажатия TEARDOWN UAF устройство не обязательно паникует немедленно. PoC сначала подготавливает устаревшее состояние планировщика. Ошибка срабатывает в следующем цикле планирования скалера, который на практике происходит, когда активность SpringBoard/композитора управляет скалером. В моём воспроизведении на физическом устройстве я вызвал этот цикл планировщика, нажав/взаимодействовав с Dynamic Island после того, как PoC завершил подготовку устаревшего состояния планировщика.

Шаги:

1. Перезагрузите уязвимое устройство перед запуском PoC.
2. Установите и запустите ScalerTeardownUAF.ipa.
3. Нажмите TEARDOWN UAF.
4. PoC открывает соединение-жертву AppleM2ScalerCSCDriver.
5. PoC создаёт объекты IOSurface источника и назначения.
6. PoC отправляет синхронную базовую операцию скалера.
7. PoC устанавливает данные кредита/маркера селектора 10 в 0xDEAD0001 на соединении-жертве.
8. PoC отправляет 50 асинхронных операций на соединении-жертве.
9. PoC закрывает соединение-жертву с помощью IOServiceClose, освобождая объекты операций, принадлежащие жертве, при этом устаревшие записи планировщика остаются.
10. PoC открывает 50 соединений-замен.
11. Каждое соединение-замена устанавливает данные кредита/маркера селектора 10 в 0xBEEF0002.
12. PoC отправляет дополнительные асинхронные операции на соединениях-заменах, чтобы повторно использовать освобождённые слоты операций и поддерживать нагрузку на планировщик.
13. Когда приложение запрашивает триггер, нажмите/взаимодействуйте с Dynamic Island, чтобы вызвать активность SpringBoard/композитора и запустить планировщик скалера.
14. Устройство паникует/перезагружается при обработке устаревшей записи планировщика.
15. После перезагрузки проверьте, что состояние регистра паники содержит x9 = 0x00000000BEEF0002.

Ожидаемое условие доказательства:

• x9 = 0x00000000BEEF0002 означает, что планировщик прочитал маркер замены из памяти, которая изначально принадлежала освобождённой операции жертвы.
• 0xBEEF0002 — это не маркер жертвы; это маркер соединения-замены.
• Следовательно, наблюдаемое чтение планировщика произошло после освобождения и повторного использования.

Поведение PoC

Включённый исходный код выполняет следующую последовательность:

Соответствующий исходный файл: ScalerTeardownUAF.m.

Сборка

Файлы репозитория

Хронология

• Первоначальный сбой обнаружен при тестировании поведения AppleM2ScalerCSCDriver.
• UAF подтверждён различением маркеров жертвы и замены: жертва 0xDEAD0001, замена 0xBEEF0002.
• Воспроизведение на физическом устройстве подтверждено запуском следующего цикла планирования скалера через активность Dynamic Island / SpringBoard композитора.
• Apple исправила проблему в линейке выпусков 26.5 и присвоила CVE-2026-43655.