18 мая The Register обратил внимание на сообщение Торвальдса в еженедельном статусе Linux 7.1-rc4. Релиз-кандидат сам по себе вышел обычным: исправления драйверов, ноутбучные quirks, HID++ для новых Bluetooth-клавиатур Logitech, правки AMD Dynamic EPP, KVM и свежие фиксы. Но в письме Торвальдс отдельно выделил новую документацию по секьюрити-багам и ответственному применению ИИ-инструментов.
Проблема в том, что несколько исследователей запускают похожие ИИ-инструменты, получают один и тот же класс находок, затем отправляют почти одинаковые отчёты в приватную секьюрити-рассылку. Мейнтейнеры тратят время не на исправления, а на маршрутизацию писем, проверку дублей и объяснение, что баг уже обсуждался или был закрыт неделями раньше.
Торвальдс сформулировал позицию так: ИИ-инструменты полезны, если помогают, а не создают лишнюю работу. Его главный совет для исследователей — прочитать документацию, подготовить патч и добавить реальную ценность поверх того, что нашла модель. Простая отправка «вот подозрительный фрагмент, разберитесь сами» теперь воспринимается как спам, а не помощь проекту.
Linux kernel — не багбаунти-платформа, где достаточно загрузить скриншот и ждать выплаты. Для ядра важны воспроизводимость, понятный импакт, корректный патч, публичная история обсуждения и минимизация ложных тревог. ИИ-отчет без проверки может выглядеть убедительно, но внутри часто оказывается старый баг, невозможный сценарий, дубликат, проблема в мертвом коде или теоретическая конструкция без реального пути эксплуатации.
Новая документация просит отправителей писать короткие plain-text-отчеты без Markdown, ставить ключевые факты в начало, описывать проверенный эффект и не раздувать возможные последствия. Если отчет утверждает, что баг дает повышение привилегий, нужно показать, какую конкретно возможность получает непривилегированный пользователь. Теоретическое «может привести к компрометации» без воспроизведения больше не считается нормальной заявкой на срочную обработку службой безопасности.
Отдельное требование касается ИИ-сгенерированных эксплойтов. Их нужно тестировать перед отправкой и подтверждать воспроизводимость. Эксплойт-код не стоит публиковать сразу в открытой переписке; можно указать, что рабочий эксплойт существует, и передать его приватно мейнтейнеру по запросу.
Отдельный документ AI Coding Assistants теперь описывает, как использовать ИИ-инструменты при подготовке патчей. Там закреплено: ИИ-помощники должны следовать обычному процессу разработки ядра, а человек несет ответственность за код, лицензирование и Signed-off-by.
В документации более четко описана модель того, какие нарушения действительно могут считаться уязвимостями. В перечень входят нарушение изоляции пользователей, разделения памяти процессов, ограничений ptrace, IPC и сетевой изоляции, а также обходы механизмов Linux capabilities: например, CAP_SYS_ADMIN, CAP_NET_ADMIN и CAP_SYS_PTRACE.
Документ также фиксирует, что не всякая ошибка автоматически становится security-багом. Проблемы в устаревших ветках ядра, небезопасных build options, странных sysctl-настройках, dev-only-функциях вроде LOCKDEP, KASAN и FAULT_INJECTION, экспериментальном коде или staging-драйверах обычно не требуют закрытой срочной обработки.
Поток AI- и fuzzing-находок уже влияет не только на почту, но и на состав ядра. В апреле из Linux начали убирать старые сетевые драйверы эпохи ISA и PCMCIA, ISDN-код и другие участки, где почти нет живых пользователей, но есть новые отчёты от fuzzers и ИИ-инструментов. Phoronix писал, что один merge убрал более 138 тыс. строк кода, включая ISDN, legacy ATM, часть ham radio support и старые драйверы сетевых адаптеров.
Это важная перемена для Linux. Ведь долгие годы ядро славилось сохранением поддержки старого железа. Теперь ИИ-генерация отчётов меняет экономику сопровождения: старый код остается в дереве только до тех пор, пока его наличие не создает лишнюю работу людям.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
