Фирма Binarly, специализирующаяся на безопасности прошивок, нашла шесть новых дыр в U-Boot — том самом загрузчике, который включает железо в домашних роутерах, умных камерах и управляющих чипах серверов в дата-центрах. Четыре бага просто вешают устройство. Два позволяют запустить чужой код через специально собранную вредоносную образ-картинку — причём до того, как загрузчик вообще успевает проверить подлинность программного обеспечения. Именно в этой детали и зарыта главная проблема: все шесть уязвимостей срабатывают на этапе чтения образа, а проверка подписи происходит уже потом. Загрузчик стартует раньше операционной системы, так что дыра здесь способна подорвать доверие ко всему, что грузится следом.
U-Boot упаковывает ядро, дерево устройств, ramdisk и прочие компоненты загрузки в контейнер под названием FIT — Flattened Image Tree. Перед передачей управления загрузчик сверяет цифровую подпись этого пакета. Именно в механизме проверки Binarly и искала слабые места — и нашла их с избытком.
Уязвимый код тянется из U-Boot версии 2013.07 и присутствует в более чем 50 стабильных релизах подряд. Он же перекочевал во множество прошивок производителей, построенных поверх U-Boot — а таких прошивок в мире огромное количество, от бытовой техники до серверного оборудования.
Уязвимостям присвоили идентификаторы от BRLY-2026-037 до BRLY-2026-042. CVE-номера пока не выданы. Две ошибки относятся к категории «выполнение произвольного кода», четыре — к категории «просто крах системы».
Самые серьёзные баги, BRLY-2026-037 и BRLY-2026-038, оба берут начало в одном непроверенном значении. U-Boot вызывает функцию fdt_get_name — это функция поиска из библиотеки разбора дерева устройств. На испорченном образе она возвращает либо нулевой указатель, либо отрицательную длину. И то, и другое U-Boot использует без всякой проверки. В одном из вариантов отрицательная длина попадает в арифметику указателей, которая идёт назад по памяти, пока не перезапишет сохранённый адрес возврата. При подходящей раскладке памяти любая из этих двух ошибок способна передать управление коду атакующего.
Оставшиеся четыре бага работают проще, но не менее неприятно. BRLY-2026-039 читает за пределами образа, доверяя размеру, который контролирует атакующий. BRLY-2026-041 делает то же самое, но через смещение. BRLY-2026-040 разыменовывает нулевой указатель, который возвращает устаревший формат образа без проверки. А BRLY-2026-042 исчерпывает стек через глубоко вложенный образ — ранний этап валидации начинает рекурсивно вызывать сам себя, пока стек не закончится.
Для каждой из шести проблем Binarly опубликовала proof-of-concept образ и шаги воспроизведения, продемонстрировав их на стандартных сборках U-Boot. Пока о реальных атаках с использованием этих багов не сообщалось.
Приоритет очевиден: две ошибки с повреждением памяти важнее остальных. Крах устройства — штука неприятная, но обратимая. Выполнение кода на этапе загрузки — совсем другая история, она способна подорвать всю цепочку доверия целиком. В худшем случае восстановление устройства требует физического доступа и перепрошивки чипа памяти чистым образом. А код, выполняющийся ниже операционной системы, зачастую остаётся невидимым для обычных средств защиты.
Есть и практический вопрос: как вредоносный образ вообще попадёт в путь загрузки? Обычно для этого нужен физический доступ или уже имеющаяся привилегированная точка опоры в системе. Но тут стоит сделать оговорку — такая точка опоры не всегда локальная. Тот же исследователь из Binarly ранее показывал на примере контроллеров управления серверами Supermicro, что злоумышленник с удалённым доступом к интерфейсу управления способен злоупотребить штатным процессом обновления устройства и залить вредоносный образ вообще без физического контакта с железом.
Патчи для всех шести проблем U-Boot принял в июне 2026 года. Но релиз v2026.07 был заморожен ещё в апреле и вышел без этих исправлений. Следующая версия, v2026.10, ожидается не раньше октября. Для конечных пользователей это означает, что большинство устройств работает на прошивках вендоров, построенных поверх U-Boot, — а значит, исправление придёт только вместе с обновлением от производителя конкретного продукта. И когда оно придёт — вопрос отдельный.
История с проверкой подписи в U-Boot не первая. Месяцами ранее ту же логику зацепила уязвимость CVE-2026-33243, которую U-Boot закрыл ещё в апреле. Тот же баг затронул родственный загрузчик barebox, использующий тот же инструментарий для работы с образами. Суть проблемы была в том, что свойство, предназначенное лишь для перечисления того, что покрывает подпись, само оказалось неподписанным — это позволяло подменить части образа, не тронутые проверкой.
Функция fdt_get_name, лежащая в основе двух худших новых уязвимостей, происходит из библиотеки libfdt — общей библиотеки для работы с плоским деревом устройств, которую используют U-Boot, ядро Linux, barebox и другие проекты. Та же ошибка с непроверенным возвращаемым значением потенциально может всплыть везде, где применяется эта библиотека.
Схожая история уже разворачивалась в 2023 году под названием LogoFAIL — набор багов разбора изображений в прошивках персональных компьютеров, позволявших коду атакующего запускаться во время загрузки, ещё до того, как Secure Boot успевал хоть что-то проверить. Тогда проблема затронула практически все крупные бренды ПК. А ещё раньше, в 2020-м, была BootHole — уязвимость загрузчика, сломавшая Secure Boot сразу во всей экосистеме. Оба случая показали одно и то же: написать патч — это лёгкая часть работы. Медленная часть — доставить его на миллионы устройств, где крутятся собственные копии U-Boot от разных вендоров.
Повторяющаяся закономерность во всех этих историях проста: всё внимание достаётся цифровой подписи, а баги раз за разом обнаруживаются в той «сантехнике», которая работает до неё. Разбор образов на этапе загрузки остаётся устойчивой уязвимой поверхностью сразу для нескольких экосистем — U-Boot, barebox, прошивок ПК и общих библиотек вроде libfdt. А задача патчинга низкоуровневых прошивок в раздробленной среде производителей так и остаётся практическим пробелом в безопасности, который никуда не девается.
Изображение носит иллюстративный характер
U-Boot упаковывает ядро, дерево устройств, ramdisk и прочие компоненты загрузки в контейнер под названием FIT — Flattened Image Tree. Перед передачей управления загрузчик сверяет цифровую подпись этого пакета. Именно в механизме проверки Binarly и искала слабые места — и нашла их с избытком.
Уязвимый код тянется из U-Boot версии 2013.07 и присутствует в более чем 50 стабильных релизах подряд. Он же перекочевал во множество прошивок производителей, построенных поверх U-Boot — а таких прошивок в мире огромное количество, от бытовой техники до серверного оборудования.
Уязвимостям присвоили идентификаторы от BRLY-2026-037 до BRLY-2026-042. CVE-номера пока не выданы. Две ошибки относятся к категории «выполнение произвольного кода», четыре — к категории «просто крах системы».
Самые серьёзные баги, BRLY-2026-037 и BRLY-2026-038, оба берут начало в одном непроверенном значении. U-Boot вызывает функцию fdt_get_name — это функция поиска из библиотеки разбора дерева устройств. На испорченном образе она возвращает либо нулевой указатель, либо отрицательную длину. И то, и другое U-Boot использует без всякой проверки. В одном из вариантов отрицательная длина попадает в арифметику указателей, которая идёт назад по памяти, пока не перезапишет сохранённый адрес возврата. При подходящей раскладке памяти любая из этих двух ошибок способна передать управление коду атакующего.
Оставшиеся четыре бага работают проще, но не менее неприятно. BRLY-2026-039 читает за пределами образа, доверяя размеру, который контролирует атакующий. BRLY-2026-041 делает то же самое, но через смещение. BRLY-2026-040 разыменовывает нулевой указатель, который возвращает устаревший формат образа без проверки. А BRLY-2026-042 исчерпывает стек через глубоко вложенный образ — ранний этап валидации начинает рекурсивно вызывать сам себя, пока стек не закончится.
Для каждой из шести проблем Binarly опубликовала proof-of-concept образ и шаги воспроизведения, продемонстрировав их на стандартных сборках U-Boot. Пока о реальных атаках с использованием этих багов не сообщалось.
Приоритет очевиден: две ошибки с повреждением памяти важнее остальных. Крах устройства — штука неприятная, но обратимая. Выполнение кода на этапе загрузки — совсем другая история, она способна подорвать всю цепочку доверия целиком. В худшем случае восстановление устройства требует физического доступа и перепрошивки чипа памяти чистым образом. А код, выполняющийся ниже операционной системы, зачастую остаётся невидимым для обычных средств защиты.
Есть и практический вопрос: как вредоносный образ вообще попадёт в путь загрузки? Обычно для этого нужен физический доступ или уже имеющаяся привилегированная точка опоры в системе. Но тут стоит сделать оговорку — такая точка опоры не всегда локальная. Тот же исследователь из Binarly ранее показывал на примере контроллеров управления серверами Supermicro, что злоумышленник с удалённым доступом к интерфейсу управления способен злоупотребить штатным процессом обновления устройства и залить вредоносный образ вообще без физического контакта с железом.
Патчи для всех шести проблем U-Boot принял в июне 2026 года. Но релиз v2026.07 был заморожен ещё в апреле и вышел без этих исправлений. Следующая версия, v2026.10, ожидается не раньше октября. Для конечных пользователей это означает, что большинство устройств работает на прошивках вендоров, построенных поверх U-Boot, — а значит, исправление придёт только вместе с обновлением от производителя конкретного продукта. И когда оно придёт — вопрос отдельный.
История с проверкой подписи в U-Boot не первая. Месяцами ранее ту же логику зацепила уязвимость CVE-2026-33243, которую U-Boot закрыл ещё в апреле. Тот же баг затронул родственный загрузчик barebox, использующий тот же инструментарий для работы с образами. Суть проблемы была в том, что свойство, предназначенное лишь для перечисления того, что покрывает подпись, само оказалось неподписанным — это позволяло подменить части образа, не тронутые проверкой.
Функция fdt_get_name, лежащая в основе двух худших новых уязвимостей, происходит из библиотеки libfdt — общей библиотеки для работы с плоским деревом устройств, которую используют U-Boot, ядро Linux, barebox и другие проекты. Та же ошибка с непроверенным возвращаемым значением потенциально может всплыть везде, где применяется эта библиотека.
Схожая история уже разворачивалась в 2023 году под названием LogoFAIL — набор багов разбора изображений в прошивках персональных компьютеров, позволявших коду атакующего запускаться во время загрузки, ещё до того, как Secure Boot успевал хоть что-то проверить. Тогда проблема затронула практически все крупные бренды ПК. А ещё раньше, в 2020-м, была BootHole — уязвимость загрузчика, сломавшая Secure Boot сразу во всей экосистеме. Оба случая показали одно и то же: написать патч — это лёгкая часть работы. Медленная часть — доставить его на миллионы устройств, где крутятся собственные копии U-Boot от разных вендоров.
Повторяющаяся закономерность во всех этих историях проста: всё внимание достаётся цифровой подписи, а баги раз за разом обнаруживаются в той «сантехнике», которая работает до неё. Разбор образов на этапе загрузки остаётся устойчивой уязвимой поверхностью сразу для нескольких экосистем — U-Boot, barebox, прошивок ПК и общих библиотек вроде libfdt. А задача патчинга низкоуровневых прошивок в раздробленной среде производителей так и остаётся практическим пробелом в безопасности, который никуда не девается.
