Hacker News Digest

Анонимный пользователь отправил ссылку на статью в Hacker News, где подробно разбираются две уязвимости в драйверах NVIDIA. Вместо того чтобы просто пересказывать статью, я напишу краткий и точный пересказ в двух абзацах, как ты и просил.

В драйверах NVIDIA для Linux обнаружены две уязвимости: одна приводит к разыменованию нулевого указателя, другая — к использованию памяти после освобождения. Обе позволяют локальному непривилегированному пользователю выполнить код на уровне ядра. Уязвимости были исправлены NVIDIA в октябре 2025 года.

Исследователи из Quarkslab детально изучили вторую уязвимость (CVE-2025-23280), которая затрагивает функцию threadStateInit в модуле nvidia.ko. Уязвимость позволяет перезаписать структуры в ядерной памяти, что в конечном итоге приводит к выполнению произвольного кода. Для эксплуатации уязвимости использовались специально созданные вызовы ioctl, которые манипулируют кеш-памятью и таблицами страниц, что позволяет обходить защиту KASLR и получать примитивы чтения/записи. В процессе эксплуатации также использовались возможности Linux по управлению памятью, такие как vmalloc и fork, для повышения надежности атаки.

• NVIDIA просит отложить публикацию уязвимостей до января 2026 года, что выходит за рамки стандартного 90-дневного цикла раскрытия.
• Quarkslab отвергла просьбу, указав, что уязвимости были раскрыты в июне и что отсутствие фиксов в драйвере для Jetson Thor нарушает соглашение о ответственном раскрытии.
• Обсуждение выявило, что драйверы NVIDIA остаются уязвимыми, а их закрытый характер мешает сообществу оценить и предложить патчи.
• Участники подчеркнули, что открытые модули ядра были бы защищены от таких багов, если бы драйвер был открыт.
• В итоге, дискуссия подчеркнула, что ответственное раскрытие и открытый код могли бы предотвратить подобные ситуации в будущем.

• CVE-2025-53136 – утечка адреса ядра Windows 24H2+ через NtQuerySystemInformation(SystemTokenInformation).
• Появилась после неудачного патча CVE-2024-43511: в RtlSidHashInitialize() ядро кладёт указатель на TOKEN→UserAndGroups в пользовательский буфер, и за короткий промежуток его можно считать.
• Уязвимость доступна из Low IL / AppContainer; при победе в гонке выдаёт надёжный KASLR bypass.
• Эксплойт: два потока – один циклично вызывает syscall, второй читает буфер; адрес токена утечёт почти всегда.
• Цепляется с write-what-where → LPE.

• KASLR на x86 считается «мертв» даже с KPTI: EntryBleed и prefetch-эксплойты работают на новых Intel/AMD.
• Утечка через SystemTokenInformation (Win11 24H2) даёт адрес ядра, но раньше KASLR и так легко обходился.
• Баг оказался в NtQueryInformationToken, а не в новом enum; статья уже исправлена.
• Патч KB5063878 (август 2024) закрыл уязвимость; совпадение с «фиаско Phison SSD» – случайность.
• Эксплойт полезен как звено в цепочке, но KASLR всё равно воспринимается лишь «speed bump».

GrapheneOS получает предварительный доступ к бюллетеням безопасности Android и уже готовит обновления.

• Google на 3–4 месяца блокирует публикацию исходников патчей безопасности, чтобы OEM-ы успели обновить свои устройства, но при этом злоумышленники получают «белый свет» на использование уязвимостей.
• GrapheneOS видит патчи, но не может включать их в открытые сборки, пока не истечёт эмбарго, что ставит пользователей в уязвимое положение.
• Предложенный выход — выпускать временно бинарные обновления (opt-in), чтобы сообщество могло запрашивать GPL-исходники и реверс-инжирить исправления.
• Участники считают, что OEM-ы легко могли бы тестировать патчи в CI за дни, но экономия и нежелание тратиться на безопасность тормозят процесс.
• Некоторые подозревают, что затягивание обновлений выгодно не только OEM, но и госструктурам, которым даётся «окно» для эксплойтов.

Коллега нашёл в ARM-дизассемблере кучу «лишних» инструкций d4d4 (bmi #-0x58), которые никогда не выполняются.

Минимальный пример:

00020100 <one>:
   20100: 4770  bx lr
   20102: d4d4  bmi …

bx lr возвращает из функции, так что d4d4 недостижима.
Мысль: выравнивание? Thumb-команды 16-битные, но компилятор не выравнивает функции на 32 бита.

Добавляем вторую функцию — d4d4 исчезает.
Третья — d4d4 снова появляется, но только после последней функции.

Смотрим объектный файл: компилятор d4d4 не вставляет. Значит, линковщик lld добивает секцию до 32-битной границы именно этой командой.
Меняем порядок файлов — «лишняя» инструкция перемещается в начало следующего модуля, подтверждая гипотезу.

GNU ld вместо d4d4 ставит нули.

• Коммит 2017 года в OpenBSD закладывал «trapsleds» — заполнение «дырок» в исполняемых секциях инструкциями-ловушками (trap), чтобы сорвать NOP-sled-эксплойты.
• На ARM32/Thumb ожидалось 0xD4 (BRK) или 0xBE (BKPT), но в режиме Thumb та же последовательность байтов декодируется как условный переход назад, превращая «ловушку» в потенциальный ROP-гаджет.
• Это делает защиту нерабочей на Cortex-M (только Thumb), что участники признают ошибкой/«сломанной» митигацией.
• Некоторые считают, что описание механизма в коммит-сообщении достаточно, другие требуют комментариев в коде, чтобы избежать подобных недоразумений.