AI-сканери наближають Linux до 2000 CVE за реліз і перевантажують супровідників
Різке зростання кількості виправлень не означає автоматичного погіршення безпеки: моделі знаходять справжні дефекти, але створюють багато шуму й малокорисних латок.

Кількість ідентифікаторів CVE, які супроводжують виправлення в кожному новому релізі ядра Linux, наближається до двох тисяч. За графіком Грега Кроа-Гартмана, більшу частину гілки Linux 6.x показник тримався біля 500, перевищив тисячу у Linux 7.0 та півтори тисячі у 7.2. Якщо тенденція збережеться, реліз 7.3 може перейти межу 2000. Проте ця статистика не доводить, що ядро раптом стало вчетверо менш безпечним.
Головна зміна — спосіб пошуку. Автоматизовані дослідники та системи на основі великих мовних моделей тепер масово переглядають понад 40 млн рядків коду, накопичених приблизно за 35 років. Вони знаходять невідповідності, підозрілі перевірки меж, рідкісні помилки керування пам’яттю та проблеми у старих драйверах, до яких люди могли не повертатися роками. Частина звітів є реальною й приводить до корисних виправлень.
Tom’s Hardware наводить приклад дефектів, виявлених AI-підсиленим статичним аналізом і підтверджених командою Intel Product Security. Це важливе нагадування: інструмент не слід відкидати лише через походження звіту. Якщо є відтворюваний сценарій, зрозумілий шлях виконання, коректна латка та перевірка фахівцем, автоматизація розширює охоплення аудиту й може знайти помилку до того, як нею скористається нападник.
Проблема полягає у співвідношенні сигналу й шуму. Моделі надсилають припущення про недосяжні гілки, формальні неточності та малопріоритетні проблеми в обладнанні, якого майже ніде не залишилося. Деякі пропоновані латки змінюють коментарі або стиль без практичної користі, інші містять галюцинації й можуть самі додати регресію. Кожен такий матеріал однаково потребує часу людини: прочитати пояснення, перевірити контекст, зібрати конфігурацію, запустити тести й відповісти автору.
Супровідник мережевої підсистеми Якуб Кіцинський оцінив, що від третини до половини з 648 латок у net-next для циклу 7.3 стосувалися малопріоритетного очищення, уточнень або змін, підштовхнутих AI. Він прямо описав команду як повністю перевантажену. Навіть правильна дрібна правка має альтернативну вартість: у той самий час досвідчений рецензент не аналізує складну вразливість, регресію продуктивності чи новий драйвер.
Сам номер CVE також не є одиницею небезпеки. Один запис може описувати помилку в рідкісному ISA-адаптері, що потребує локального доступу й спеціальної конфігурації, а інший — віддалено досяжний дефект у широко ввімкненому мережевому коді. Для оцінки ризику адміністратору потрібні експлуатованість, привілеї, доступність компонента, конфігурація ядра та наявність виправлення. Порівнювати системи лише за кількістю CVE некоректно.
Однією з відповідей спільноти стає видалення застарілого коду. Обговорюється вилучення близько 28 тисяч рядків мережевих драйверів для ISA й PCMCIA; у Linux 7.3 уже прибирають старі драйвери SGI та IBM, а файлову систему FreeVxFS вилучили раніше. Менша кодова база скорочує площу атаки й обсяг рецензування. Водночас видалення потребує обережності, бо старі компоненти можуть залишатися потрібними промисловим або музейним системам.
Ефективна політика для AI-звітів має вимагати мінімальну відтворюваність: точну версію, конфігурацію, тест, журнал збою та пояснення досяжності. Автоматично згенерований патч не повинен отримувати привілей лише тому, що виглядає переконливо. Корисними можуть бути квоти, репутація авторів, окремі черги для механічних прибирань і обов’язкове маркування використання моделей. Мета — не заборонити інструмент, а зробити вартість подання ближчою до вартості перевірки.
Для користувачів висновок залишається звичним: встановлювати підтримувані ядра та оновлення дистрибутива, не вмикати непотрібні модулі й оцінювати конкретні бюлетені. Стрибок статистики радше відображає інтенсивніший пошук і ширшу практику призначення CVE, ніж раптовий крах якості Linux. Справжній виклик — забезпечити, щоб людська увага встигала перевіряти машинний потік і не пропускала найважливіші дефекти.
Матеріал підготовлений редакцією HARDW на основі публікації Tom’s Hardware.
Відкрити оригінал на Tom’s Hardware ↗




