CVE-2026-97631: pre-boot RCE в PXE-драйвере EDK II через ICMP

Проект TianoCore раскрыл подробности уязвимости CVE-2026-97631 в PXE-драйвере EDK II, которая позволяет выполнить код до загрузки операционной системы. Атака идёт по сети, без учётной записи и действий пользователя: достаточно прислать машине, загружающейся по сети, специально сформированное ICMP-сообщение об ошибке. При знании сборки прошивки этот сценарий доводится до исполнения кода в DXE. Ошибку нашли Алекс Матросов из Anthropic и Дэн Холмс-Митра из Google, исправление уже вошло в основную ветку EDK II, но стабильного выпуска с патчем на момент публикации бюллетеня не было. Оценка - 9,5 балла по CVSS 4.0, уровень критический.

Что известно об ошибке в PXE-драйвере EDK II

Суть ошибки

EDK II - открытая эталонная реализация UEFI, которую ведёт проект TianoCore. Драйвер NetworkPkg/UefiPxeBcDxe отвечает за загрузку по сети: по PXE машина получает образ по IPv4 или IPv6 до того, как у неё появится операционная система.

Во время сетевой загрузки драйвер держит открытым запрос на приём ICMP-сообщений об ошибках. Каждое принятое сообщение он копирует в поле Mode.IcmpError фиксированного размера, 504 байта, в своей приватной структуре контекста. ICMP-сообщения об ошибках - служебные пакеты сетевого уровня; они сообщают, например, что адресат или порт недоступны.

Границы в цикле копирования посчитаны неверно сразу в двух обработчиках: PxeBcIcmpErrorDpcHandle для IPv4 и PxeBcIcmp6ErrorDpcHandle для IPv6. Если сообщение длиннее 504 байт, байты всё равно копируются в поле. Указатель назначения при этом сдвигается на суммарную длину, а не на длину текущего фрагмента. Поэтому слишком большое сообщение записывает подконтрольные атакующему байты за пределы поля.

Ничто на более раннем этапе приёма не ограничивает длину сообщения, поэтому слишком большое сообщение доходит до уязвимого копирования без дополнительных проверок. Ошибка попадает сразу под три категории: CWE-120, копирование без проверки размера входа; CWE-131, неверный расчёт размера буфера; CWE-787, запись за границами буфера.

Условия атаки

Эксплуатация не требует учётной записи и участия пользователя. Нужно, чтобы машина в момент атаки загружалась по сети через PXE по IPv4 или IPv6. Атакующий отправляет одноадресное ICMP-сообщение об ошибке на IP-адрес клиента. Источником может быть любой узел на любом сетевом расстоянии, если пакет доходит до загружающейся машины.

Окно атаки равно времени сетевой загрузки: пока идёт PXE-загрузка, драйвер принимает такие сообщения. Отдельной аутентификации для ICMP-ошибок нет, и это нормально для сетевого стека. Практическое следствие простое: чем больше посторонних узлов видят PXE-клиента, тем шире возможность для атаки. В выделенном сегменте провижининга рисков меньше, чем в общей сети, где сетевая загрузка соседствует с рабочими станциями.

Что даёт эксплуатация

Первый сценарий - отказ в обслуживании. Бюллетень описывает предсказуемое повреждение приватных данных драйвера и исключение CPU внутри DXE-ядра при следующей ICMP-ошибке. Загрузка зависает, и машина не получает операционную систему. Для инфраструктуры это отказ в провижининге и восстановлении.

Второй сценарий - выполнение кода. Если атакующий знает сборку целевой прошивки, он может подделать событие в том же пакете. Функция CoreSignalEvent() передаст подставленные атакующим байты на исполнение в фазу DXE. DXE - этап инициализации драйверов UEFI, который работает в ring 0 и до появления любых средств защиты операционной системы.

Ключевая особенность - момент исполнения. Код работает до загрузки ОС, до того, как Secure Boot и measured boot проверят или измерят компоненты операционной системы. Средства контроля, которые живут уже внутри ОС, такой сценарий не увидят: к моменту их запуска код уже выполнился в прошивке.

Варианты различаются по требованиям к атакующему. Отказ в обслуживании детерминирован и не требует знания конкретной прошивки. Для выполнения кода нужно знать сборку и правильно подделать событие, поэтому это более сложный и адресный сценарий.

Затронутые версии

Затронут пакет NetworkPkg в EDK II. Бюллетень указывает затронутую версию как EDK II master на 14 сентября 2026 года, а запись CVE называет диапазон от версии 0 до edk2-stable202608 включительно. Оценка бюллетеня - критическая, 9,5 балла по CVSS 4.0, вектор CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H.

Компонент AT:P в векторе означает, что для атаки нужны определённые условия: целевая машина должна загружаться по сети, и атакующий должен попасть в это окно. Остальные компоненты оценивают атаку как сетевую, с низкой сложностью и без прав и участия пользователя.

На момент публикации бюллетеня стабильных выпусков с исправлением не было: в разделе patched versions указано «not patched currently». Исправление объединили в основную ветку 15 октября 2026 года через pull request 13302. Патч добавляет проверки границ, исправляет расчёт смещения в буфере и обрезает слишком большие ICMP-сообщения, когда буфер заполнен. В трекере Debian перечислены три коммита с исправлением: 14cdbb86, 560ed9b5 и fa789071. Там же запись для trixie помечена как no-dsa (minor issue), то есть отдельного DSA по этой записи нет.

Что делать

Обновите прошивку или сборку EDK II до версии, в которой есть исправление. Ориентир - коммиты из pull request 13302, вошедшие в основную ветку 15 октября 2026 года. Для готовых серверов и ноутбуков ждите обновление BIOS или UEFI от производителя: вендоры собирают прошивки на своей базе, и сроки у них разные.

Если сетевая загрузка не нужна, отключите PXE в настройках UEFI. Это убирает окно, в котором ошибка срабатывает, и не требует ждать обновления. Машины, которым PXE действительно нужен, держите в отдельном сегменте с ограниченным числом узлов, способных отправлять им ICMP-сообщения.

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

На момент подготовки материала стабильного выпуска EDK II с патчем ещё не было. Поэтому сроки появления исправления в готовых прошивках зависят от производителей, и проверять их нужно отдельно.