Ошибки в ядре Linux замечают в среднем через 2 года

Энтузиасты опубликовали результаты исследования времени обнаружения и устранения ошибок в коде ядра Linux. Данные были получены в результате анализа 125 тысяч ошибок, помеченных в Git-репозитории тегом Fixes:, ссылающимся на коммит, в котором возникла ошибка.

Среднее время обнаружения ошибок в ядре составило 2,1 года. Если рассматривать только ошибки, исправленные в 2025 году, данный показатель составил 2,8 года.

Из-за неравномерности распределения медианное время существования ошибки в коде ядра составило 8 месяцев для выборки с 2005 года и 1 год для ошибок, исправленных в 2025 году. Наиболее долго сохранявшейся в коде ошибкой стало переполнение буфера в ethtool, устранённое спустя 20,7 года.

Динамика обнаружения ошибок заметно отличается от среднего значения для некоторых подсистем, например, в драйвере шины CAN и стеке SCTP выявление проблем в среднем занимает около 4 лет, в IPv4-стеке - 3,6 года, USB и TTY - 3,5, Netfilter и сетевом стеке - 2,9, VM - 1,8, GPU - 1,4, BPF - 1,1 года.

Время обнаружения коррелирует с типами ошибок:

В полученной статистике также прослеживается влияние внедрения новых инструментов для автоматизированного поиска ошибок, статического анализа и тестирования кода, таких как Syzkaller, KASAN, KMSAN и KCSAN. Например, в 2010 году не было зафиксировано исправлений ошибок, найденных в течение года. В то время, как в 2014 году в течение года выявлялось 31% ошибок, 2018 году - 54%, а в 2022 году - 69% ошибок.

@Lord_of_Rings
09.01.2026 23:51 UTC
Первоисточник

Комментарии

@achekalin
09.01.2026 19:17 UTC
+5

Это прямо рассказ из серии "я научится считать в экселе", со стороны тех энтузиастов. Берёшь список фиксов, анализируешь - и получаешь. Сил много, выхлоп важен не то чтобы в мировом масштабе.

@a_cid
09.01.2026 19:30 UTC
0

На то они и энтузиасты) Понимая что не масштаб не мировой, все равно сделали и поделились. Кому-то будет интересно в любом случае это увидеть.

@WondeRu
09.01.2026 23:15 UTC
+2

Когда коту делать нечего, он… пишет статьи

@nervnomancer
09.01.2026 19:37 UTC
+2

Кто б такую статистику для божественного вантуза сделал )


Из соседней новости про лохматую пропиетарщину UNIXv4:

Один из исследователей безопасности обратил внимание на утилиту "su", поставлявшуюся в UNIXv4. Данная утилита включала менее 50 строк кода, устанавливалась с флагом setuid-root и позволяла запустить /bin/sh с правами root при вводе правильного пароля. Код содержал уязвимость, приводящую к переполнению буфера из-за копирования вводимого пользователем пароля в фиксированный 100-символьный массив без проверки размера вводимых данных.

Выявленную проблему прокомментировал 93-летний Дуглас Макилрой (Douglas McIlroy), входивший в команду изначальных разработчиков Unix в Bell Labs, предложивший концепцию неименованных каналов и создавший такие утилиты, как echo, spell, diff, sort, join и tr. По словам Дугласа, до появления червя Морриса в 1988 году мало кто обращал внимание на переполнения буферов.

@Gizensha
09.01.2026 19:51 UTC
-6

Но ИИшные багрепорты мы будет и дальше отметать с негодованием. Не смеет железка Человеку указывать на ошибки!

@Junecat
09.01.2026 23:32 UTC
+8

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

19.01.2026 08:24 UTC
-1

Ну раз не потратил время на написание нормального кода, потратит на исправление багов. Это очень лицемерное отношение "как вы посмели выкатить мне багрепорт", и я его постоянно вижу среди ленивых разрабов, ведь проще курощать пользователей, чем продумывать архитектуру.

Вон тот клоун, разраб курла, смеялся над вайбкодингом, а как иишка нашла больше дыр, чем кода в его проекте, так закрыл багбаунти. А когда ему указали на это на гитхабе, он ничтоже сумняшеся ответил "а где вы видите неисправленные баги", при этом удалив ссылку на known bugs, а на дальнейшие аргументы про это забанил доступ к репозиторию. Все луддиты такие.