Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 26
Не беря даже в расчёт то, что для условного 2022-го нет пятилетних багов и расчёт процентов и прочего поэтому сразу 'едет'
Баг мог не исправляться годами не потому, что он неизвестен, а потому, что он неважен. Ок, допустим у вас неверный подсчёт ссылок и память утекает. Вопрос скорости утекания. Если для зависания системы надо подождать 10 лет - да проще 1 раз в год сервер перезагрузить, чем баг исправлять, вот он и висит незакрытым.
Старые баги - не только утечки, а вполне себе потенциальные уязвимости. Да и как было продемонстрировано, утечки могут быть потенциальным DDoS, то есть достаточно просто триггерить нужную цепочку фаервола и сервер упадет по OutOfMemory, и никакой OOM не спасет, т.к. это память ядра.
Баг мог не исправляться годами не потому что он неизвестен, а потому что никто не знал как его заабузить или скомбинировать с чем-то еще и заабузить - вот это правильнее.
сервер упадет по OutOfMemory, и никакой OOM не спасет, т.к. это память ядра.
и это, кстате, хорошее замечание. как будто автор вообще не предтставляет предметную область. о чем еще немного намекает "баг в ethtool" - это usermod бинарник и даже не идет в базовой поставке почти всех дистрибутивов.
нехорошо эта вся статья пахнет, как реклама очередной сгенеренной ЫЫ тулы. да, и самое главное - нагенерить ИИ-говном багов сейчас может любая собака, а вот патчи отправить, да чтобы их еще приняли, почему-то почти никто
Интересная штука с 2.1 года среднего времени жизни. Но я бы разделил баги на две категории: те, что проявляются в популярных сценариях (networking, FS), и те, что живут в редких подсистемах типа SCTP или CAN. Первые находят быстро (кто-то наткнулся в проде), вторые могут лежать годами, потому что код просто не выполняется.
VulnBERT с 92% полнотой звучит круто, но как вы фильтруете ложноположительные результаты? 1.2% FPR на весь кодбейс ядра — это тысячи false positives, если прогонять на каждом коммите.
Прикольно, но практически как-то использовать такой датасет я бы не стал по следующим причинам:
определение идентификатора CVE по сообщению коммита практически бесполезное занятие, так как зачастую там такой информации нет. Так что не удивлюсь, если в результате оказалось, что идентификатор выставлен у 1-2 записей;
датасет составлен из предположения, что выставленные тэги Fixes правильные и не меняются со временем.
А это не так. Зачастую тэг Fixes указывает чуть ли не на релиз ядра 2.6.12-rc6 (когда начали юзать git) и реальный коммит, который вводит уязвимость он не покажет. А покажут базы данных уязвимостей типа nvd, linuxkernelcves, cip-kernel-sec и т.д. Так как в них отражаются результаты анализа от экспертов, включая и рельные хэши коммитов, которые вносят уязвимость.
Меня сразу смутило название: физик.... А с каких пор физики занимаются подобными делами?
По поводу багов: ну есть где то баг, который никогда не увидят 99% пользователей? Ну и фиг с ним.
Помню, читал, когда то давно, mindcraft, который спонсировался microsoft уже тестировал web сервера windows nt и gnu/linux, типа он в 5 раз быстрее оказался. (Типа оказался), хотя независимые тестировщики указали что gnu/linux работает ни чуть ни хуже, а где то даже и лучше.
Вот эта статья что то подобное мне напоминает.
Меня слово “физик” вообще не смутило. У нас пол IT из физиков и математиков. Люди, которые умеют работать со статистикой и большими массивами данных, вполне логично лезут в такие исследования
Ха, мне в институте не хватало понимания по статистике (90-е), так я в дополнение к лекциям читал дедовский справочник по биометрике года 48-го. Сколько нужно шмелей для опыления какого количества гектаров клевера (пчелы не годятся: хоботки которткие), учитывая что длина хоботков у шмелей распределена нормально и т.д. Удои у коров там и еще куча всего. Да, вуз не технический, но и не гуманитарный. ) Сигмы, критерии Стьюдента, вот это всё...
Что смущает то?
Да, физики могут в программирование. Потому что в конце 90х и начале нулевых не было особо специальностей "крутой программист", и, естественно в программисты шли технари. Например с физико-технических факультетов.
ЗЫ: а вот обратное для современных выпускников ит-специалностей не верно.
Это распространённый демагогический приём, "отсылка к ложному авторитету" — типа, не простой безвестный Васёк что-то там посчитал, а аж целый Физик(!) — и пофиг, что заслуги автора в области физики никак не указывают на его(её) компетентность в предмете статьи.
Этот же приём часто используют в рекламе, привлекая к съёмкам артистов, спортсменов и прочих "медийных" личностей. Забавно, что на какую-то часть популяции хомосапиенсов это даже действует: люди с двухзначным IQ склонны считать, что "успешный человек успешен во всём", и действительно считают мнение о, например, стиральном порошке, объявленное каким-нить спортсменом или певичкой, более ценным, чем мнение условного соседа.
При составлении заголовка и мысли не было употреблять отсыл к ложному авторитету. Были мысли а) подчеркнуть научный подход: статья совсем не похожа на типичное исследование ИБ, где уязвимость выворачивается наизнанку, это куда более статистика, наблюдения, с которыми работают именно учёные; и была мысль б) получить оригинальный заголовок, при оригинальности соответствующий действительности.
Апелляции к авторитету, то есть утверждения, что раз исследование проделал физик, то оно безупречно, здесь нет. Более того, был некий риск реакции «Где физика и где ИБ?» — а это противоположно созданию ложного авторитета. Наконец, научная работа по физике у автора есть, а вот коммитов в ядро, как верно заметили, нет… Значит, автор действительно больше физик, чем CS/CTF.
Интересно, этот физик использовала Slackware? ;-)
Во-первых, эта статься уже была пару недель назад.
Во-вторых,
size_t total = n_elements * element_size; // может переполниться
buf = kmalloc(total, GFP_KERNEL);
memcpy(buf, src, n_elements * element_size); // копирует больше, чем выделяет
Почему копирует больше, чем выделяет? memcpy точно также принимает size_t, там точно также все переполнится и то же самое значение получится. Даже если memcpy будет заинлайнена, беззнаковое переполнение не является UB и компилятору нет никакой причины использовать тут более широкий тип, в который все влезет. При инлайне поведение должно сохранятся.
Кстати, SourceCraft тоже как попугай повторил про ошибку здесь, независимым экспертом он тут быть не может. А жаль.
а как она багует, очень интересно
извините а при каких условиях переполнится size_t?
тоесть надо перед умножением проверить количество элементов получается
наверно и размер элемента можно проверить и их произведение получается
там еще вход в интервалы же получается ваще жесть )
будет ли такая безопасность, которая всё проверит и выкинет ошибку, влиять на скорость интересно, закрыть все баги, всё проверять и скорость упадёт поидее, тоесть просадка по кешу и угадайке ) тоже жесть
Добрый день. Статья была на Хабре? Только что пересмотрел заголовки 140 переводов с 6 января и ничего подобного не нашёл. Возможно, что-то упустил мой RSS-клиент, крутится не круглые сутки. Но он зафиксировал даже дубль от BotHub. По второму вопросу можно написать автору: jenny@pebblebed.com. Контакты в конце, предпочитаю оставлять.
P.S. Нашёл урезанный обзор на Comss.
Статья была опубликована 13 января 2026г @PatientZero "Баги в ядре Linux в среднем прячутся по 2 года. Некоторые скрываются до 20 лет" https://habr.com/ru/articles/983558/
Я думал весь Linux-way это превозмогание багов с помощью костылей. Справедливости ради, Linux самая лучшая ОС для этого.
Самый стабильный интерфейс в линуксе - это баги, которые живут по 20 лет
nf_conntrack_get(&ct->ct_general); // инкремент
Меня удивило, что функция, меняющая что-то, имеет get в названии.
И я правильно понял, что ни одного нового бага эта физичка (будем уважительны к феминитивам) не нашла?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Физик проанализировала более 100 000 «исправленных» багов ядра Linux