Samsung, Xiaomi и другие: найден способ получить root

31 августа 2026 года Лукас Маар, исследователь компании Calif, которая занимается наступательной кибербезопасностью, опубликовал первую часть серии постов под общим названием OEMpocalypse, про универсальную стратегию, которая поднимает права обычного Android-приложения без единого запрошенного разрешения до root. На Android такое приложение живёт в изолированном домене untrusted_app, и просто так до ядра не дотянуться: доступ одновременно ограничивают избирательное управление доступом Unix (DAC), мандатная политика SELinux поверх него и фильтр системных вызовов seccomp. Автор делит весь резерв багов, доступных из этого домена, на три группы: ядро Linux с надстройкой Android Common Kernel (ACK) над ним; драйверы чипсета (GPU, DSP/NPU); и, наконец, код, который каждый производитель, Samsung, Xiaomi, Oppo/OnePlus/Realme, добавляет сам поверх Android (в тексте упомянуты фирменные надстройки One UI, HyperOS и ColorOS). Первые две группы годами проверяют внешние исследователи: в первой известен, например, баг IonStack, доведённый до root на устройствах сразу нескольких производителей; во второй такие баги ловили и в реальных атаках, в частности, в Qualcomm-модуле adsprpc, а в исследовательской литературе их разбирали Сет Дженкинс из Project Zero и Мань Юэ Мо из GitHub Security Lab. Третья группа изучена заметно меньше и обычно закрыта более строгим доменом SELinux, именно на ней и построена стратегия автора.

Схема состоит максимум из двух шагов. Если политика SELinux конкретного производителя не пускает untrusted_app напрямую к нужному драйверу, шаг 1, логическая уязвимость в одном из собственных IPC-сервисов производителя (Binder-вызовы, интенты, контент-провайдеры, локальные сокеты): отсутствующая проверка вызывающего или лишний экспортированный компонент переводят выполнение в более привилегированный процесс. Шаг 2, use-after-free страницы физической памяти (UAF) в фирменном драйвере ядра: драйвер освобождает страницу, но ссылка на неё где-то остаётся, и освобождённую физическую страницу можно подставить под что угодно, вплоть до структур ядра, дающих произвольное чтение и запись. По словам автора, ценность именно такого примитива в том, что он живёт на уровне страницы, а не слэба: его не задевают слэб-защиты вроде CONFIG_SLAB_BUCKETS, CONFIG_RANDOM_KMALLOC_CACHES и CONFIG_SLAB_FREELIST_HARDENED, обычно не нужна утечка адреса для обхода KASLR, а поток управления он не трогает, значит, не мешает и CFI. Сегодня разные производители ставят на новые устройства ядра от версии 5.15 до 6.12, и это обычно источник нестабильности для эксплойтов, но, по словам автора, именно в его цепочках код освобождения и повторного использования страниц не менялся во всём этом диапазоне.

Ключевая ставка в том, что код производителя привязан не к чипсету, а к его собственной программной надстройке: один и тот же баг встречается на всех моделях линейки независимо от того, стоит внутри Snapdragon, Exynos или Dimensity, Samsung, например, продаёт флагманы и на Exynos, и на Snapdragon, а уязвимый компонент общий для обоих. Для сравнения вариантов автор всю серию использует три критерия: надёжность, «почти 100% успеха» независимо от включённых защит и настроек (это заявленная цель, а не измеренный результат), портируемость, минимум правок под конкретное ядро, производителя, чипсет или модель, и универсальность, максимальный охват одним эксплойтом. Стратегию он реализовал трижды, по разу для Samsung, Xiaomi и семейства Oppo/OnePlus/Realme, получив цепочки, которые покрывают все флагманы Samsung (как минимум линейку Galaxy S23, S26 и актуальные модели Z), большую часть смартфонов Xiaomi среднего и топового класса и свежие флагманы Oppo, OnePlus и Realme. Плата за это, отказ от охвата сразу нескольких производителей одним эксплойтом: цепочка для Samsung не трогает Xiaomi, и каждая из трёх собрана заново, а держится минимум на двух независимых уязвимостях одновременно, если производитель закроет любую одну, всей цепочке нужна замена.

Каждая цепочка показана на видео на стоковом подписанном устройстве с заблокированным загрузчиком: приложение без единого запрошенного разрешения запускает эксплойт и открывает root-шелл, а строки Verified boot: green, Bootloader lock: 1 и VBMeta state: locked на экране подтверждают, что прошивка не тронута. В таблице тестовых устройств шесть штук, но в записях видны только пять: цепочка Samsung, на Galaxy S26 Ultra (ядро 6.12.30) и Galaxy S26 (ядро 6.12.38), обе на прошивке июля 2026 года; цепочка Xiaomi, на Xiaomi 17 (ядро 6.12.23); цепочка Oppo/OnePlus, на Oppo Find X9 Ultra и OnePlus Ace 6 Ultra (оба на ядре 6.12.58, тоже прошивка июля 2026 года). Шестое устройство, Galaxy S23 (ядро 5.15.148, прошивка марта 2025 года), в записи не попало: его использовали только как уже рутованный стенд для разработки цепочки Samsung, а готовый результат затем перенесли на заблокированные S26 и S26 Ultra вслепую.

Автор подчёркивает, что ни один из использованных багов не был тонким: каждый, ошибка в жизненном цикле страницы памяти, которую, по его оценке, поймал бы прицельный ревью драйвера, а сами драйверы не выглядели написанными с расчётом на недобросовестного вызывающего. Отсюда его защитный вывод: раз такой баг почти не задевают существующие средства защиты ядра, они рассчитаны на другой класс уязвимостей, повреждение памяти уровня слэба и перехват потока управления, единственная реальная защита, не допускать саму ошибку и держать подобные драйверы за выделенным доменом SELinux, к которому имеет доступ только доверенный компонент. Но и этот барьер работает ровно настолько, насколько защищён собственный IPC-код производителя перед этим доменом, а именно его и обходят описанные здесь цепочки. Технические детали трёх конкретных уязвимостей, какие именно IPC-сервисы и драйверы задействованы, автор оставил для следующих частей серии (2, Samsung, 3, Xiaomi, 4, Oppo/OnePlus/Realme); в этом посте нет ни номеров CVE, ни данных о том, уведомлены ли производители или выпущены ли патчи.

Ключевые факты

Стратегия в два шага: если политика SELinux производителя закрывает нужный драйвер, сначала, обход песочницы через баг в собственном IPC-сервисе производителя, затем, use-after-free страницы физической памяти (UAF) в фирменном драйвере ядра.
Стратегия реализована трижды: по разу для Samsung, Xiaomi и семейства Oppo/OnePlus/Realme; каждая двухшаговая цепочка держится минимум на двух независимых уязвимостях одновременно.
Покрытие: все флагманы Samsung (как минимум линейка Galaxy S23, S26 и модели Z), большая часть смартфонов Xiaomi среднего и топового класса, свежие флагманы Oppo, OnePlus и Realme.
Продемонстрировано на стоковых подписанных устройствах с заблокированным загрузчиком: приложение без единого разрешения получает root-шелл, что подтверждают строки Verified boot: green и Bootloader lock: 1 на видео.
Технические детали каждой из трёх цепочек автор оставил для следующих частей серии (2, Samsung, 3, Xiaomi, 4, Oppo/OnePlus/Realme); в этом посте нет ни CVE, ни данных об уведомлении производителей или патчах.

Почему это важно

Демонстрации сняты не на разлоченных для разработки телефонах, а на стоковых подписанных устройствах с заблокированным загрузчиком, то есть ровно на том, что обычно считают надёжной защитой. При этом уязвимость искали не в общем ядре Linux и не в драйверах чипсета (GPU, DSP/NPU), эти слои давно и системно проверяют внешние исследователи, а в коде, который каждый производитель (Samsung, Xiaomi, Oppo/OnePlus/Realme) добавляет сам поверх Android и который, по наблюдению автора, получает заметно меньше внешнего аудита. Одна и та же двухшаговая схема, use-after-free страницы памяти в фирменном драйвере ядра, при необходимости дополненный обходом песочницы через баг в собственном IPC-сервисе производителя, сработала сразу для трёх крупных экосистем, а не для одного случайного устройства.

Кому это важно

В первую очередь, командам безопасности самих производителей (Samsung, Xiaomi, Oppo, OnePlus, Realme): материал прямо указывает, где ревьюить в первую очередь, собственные IPC-сервисы и фирменные драйверы ядра, а не то, что и так изучено сообществом. Дальше, исследователям Android-эксплуатации: автор явно противопоставляет свою стратегию двум хорошо изученным направлениям (общий код Linux/Android Common Kernel и чипсетные GPU/DSP-драйверы) и открывает третье. Также, командам, отвечающим за парки корпоративных Android-устройств: раз обычное приложение без единого разрешения способно дойти до root, предустановленный код производителя, самостоятельный источник риска независимо от того, какие разрешения выданы пользовательским приложениям. Рядовому владельцу телефона касается меньше: рабочего эксплойта в открытом доступе нет, и в посте нет данных об использовании этих багов в реальных атаках.

Как это применить

Готового инструмента или кода эксплойта в посте нет, только видеозаписи демонстраций и описание стратегии на уровне идеи. Для тех, кто занимается ревью кода производителя, из статьи следуют две конкретные точки проверки: собственные IPC-точки входа (Binder-вызовы, интенты, контент-провайдеры, локальные сокеты), на отсутствующую проверку вызывающего или лишний экспортированный компонент; и драйверы ядра, которые привязывают физические страницы памяти к пользовательскому процессу или к устройству, на то, снимается ли эта привязка до того, как страница освобождается. Технические детали трёх конкретных цепочек (Samsung, Xiaomi, Oppo/OnePlus/Realme) автор оставил для частей 2, 4 этой же серии, здесь их пока нет.

Можно ли доверять

Пост подписан именем автора (Лукас Маар) и опубликован на сайте исследований компании Calif, которая занимается наступательной кибербезопасностью; в тексте, точная таблица протестированных устройств с чипсетом, версией Android, версией ядра и датой прошивки для каждого, а на видео прямо на экране показаны строки Verified boot: green, Bootloader lock: 1 и VBMeta state: locked, по ним можно проверить, что устройство действительно не разблокировано, а не просто поверить автору на слово. Автор явно опирается на известную предыдущую работу, баг IonStack, публикации Сета Дженкинса из Project Zero и Мань Юэ Мо из GitHub Security Lab, и вписывает свой результат в этот контекст, а не выдаёт его как нечто из ниоткуда. При этом независимого подтверждения нет: реакции производителей, номеров CVE и данных об уведомлении или патчах в посте нет вовсе, а сами уязвимости трёх цепочек раскрываются только в обещанных частях 2, 4, сейчас их достоверность подтверждают только слово автора и записанные демонстрации.

Риски и подводные камни

Главное ограничение называет сам автор: стратегия отказалась от охвата сразу нескольких производителей одним эксплойтом, цепочка для Samsung не трогает Xiaomi, и каждую из трёх пришлось строить заново. Каждая двухшаговая цепочка держится минимум на двух независимых уязвимостях сразу: стоит производителю закрыть любую одну, и всей цепочке нужна замена, а поддержание такого набора в рабочем состоянии, по словам автора, постоянная работа. Отдельный риск, со стороны самой публикации: даже без кода эксплойта уже названная и обоснованная стратегия (искать баги именно в коде производителя, а не в давно перепаханном общем ядре) может ускорить независимое обнаружение похожих проблем третьими лицами быстрее, чем производители успеют проверить остальные свои драйверы. Наконец, охват не безграничен: речь о конкретных линейках, флагманах Samsung (как минимум Galaxy S23, S26 и модели Z), Xiaomi среднего и топового уровня, свежих флагманах Oppo, OnePlus и Realme, а не обо всех Android-устройствах разом.

«Один эксплойт, чтобы править всеми»

— Лукас Маар, автор поста