Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

Важно уточнить: речь идёт о багах в целом, а не только об уязвимостях. Лишь 158 ошибок из всей выборки получили CVE, остальные могли приводить к сбоям, нестабильности или неопределённому поведению, но не обязательно к эксплуатации.

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

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

Отдельная проблема — неполные фиксы. Исследование показывает, что нередко разработчики закрывают проблему лишь частично. Например, в 2024 году был выпущен патч для проверки полей в netfilter, но уже через год исследователь нашёл способ его обойти.

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

Российский софт готовят к отзыву западных сертификатов

Российская ИТ-отрасль готовится к сценарию, который ещё недавно казался маловероятным: западные удостоверяющие центры могут начать массово отзывать сертификаты подписи программного кода у российских разработчиков. Чтобы не остаться без работающего софта, крупнейшие игроки рынка уже создают собственную систему доверия.

Как выяснил РБК, на базе Национального технологического центра цифровой криптографии работает группа «Единое пространство доверия», в которую входят «Астра», «Сбертех», «Базальт СПО», «КриптоПро», «ИнфоТеКС», «Лаборатория Касперского» и другие компании.

Они разрабатывают Отраслевой технологический удостоверяющий центр (ОТУЦ), который должен заменить ушедшие западные сервисы выдачи сертификатов подписи кода.

Проект уже вышел за рамки теории. По словам главы «КриптоПро» Станислава Смышляева, центр работает в тестовом режиме, а разработчики Astra Linux, «Альт», РЕД ОС, ROSA, «Авроры» и ряда ИБ-продуктов уже протестировали выпуск сертификатов и проверку подписанного программного обеспечения.

Проблема стала особенно актуальной после того, как в июне японская GlobalSign начала отзывать сертификаты безопасности у российских сайтов. В отрасли опасаются, что следующим шагом могут стать сертификаты для подписи программ.

Если такой сценарий реализуется, последствия будут серьезными. Операционные системы перестанут доверять программам с отозванными сертификатами: где-то появятся предупреждения, а где-то запуск может быть полностью заблокирован. Для разработчиков это означает риск остановки поставок обновлений и новых версий продуктов.

Особенно болезненной ситуация может стать для компаний, чьи решения работают в Windows и других зарубежных операционных системах. По данным рынка, Windows до сих пор используется более чем в 80% российских организаций.

В Минцифры утверждают, что на случай проблем уже есть резервный план. Национальный удостоверяющий центр получил право выпускать отечественные сертификаты подписи кода, а параллельно тестируется использование российских криптографических алгоритмов ГОСТ в Linux и Android.

По сути, отрасль строит собственный аналог национальной платежной системы, только для программного обеспечения. Логика простая: если зарубежная инфраструктура доверия однажды отключится, российский софт должен продолжить работать без сбоев и риска подмены кода злоумышленниками.

RSS: Новости на портале Anti-Malware.ru