Вразливість CVE-2026-98432 у мережевому стеку IPv4 TCP ядра Linux дає змогу віддаленому неавтентифікованому зловмиснику досягти виконання довільного коду через умову гонки під час обробки TCP-з’єднань. Проблема стосується всіх версій ядра, починаючи з 4.4, і будь-якої системи з відкритим TCP-портом, що приймає IPv4-з’єднання. Red Hat та Canonical класифікують вразливість як критичну з оцінкою CVSS 9.8. Патчі вже доступні для RHEL, Amazon Linux і частково для Ubuntu; адміністраторам необхідно оновити ядро та перезавантажити системи.
Технічна суть вразливості
Проблема належить до класу use-after-free і виникає у функції tcp_v4_syn_recv_sock(). Під час приймання вхідного IPv4 TCP-з’єднання ядро передає IP-опції з запитного сокета дочірньому без копіювання. Якщо клієнт повторно надсилає SYN-пакет, поки інший процесор ще читає ці опції, ядро звертається до вже звільненої пам’яті у функції ip_options_build(). Дочірні TCP-сокети не мають прапорця SOCK_RCU_FREE, а деструктор inet_sock_destruct() звільняє inet_opt звичайним kfree() замість kfree_rcu().
Зловмисник ініціює гонку, надсилаючи TCP-запити на встановлення з’єднання з IPv4-опціями Record Route або Timestamp на будь-який слухаючий TCP-порт. Автентифікація не потрібна. Аналогічна проблема існує під час міграції запитних сокетів (net.ipv4.tcp_migrate_req=1). Згідно з даними Canonical, IPv6 не є вразливим до основної проблеми, оскільки шлях обробки IPv6 дублює опції.
Виправлення полягає у заміні kfree() на kfree_rcu() в inet_sock_destruct() і tcp_v4_reqsk_destructor(), що забезпечує звільнення пам’яті лише після завершення RCU grace period.
Розбіжності в оцінках серйозності
Показово, що вендори розходяться в оцінці критичності. Fortinet, Red Hat і Ubuntu присвоюють CVSSv3 9.8 і статус Critical, вказуючи на можливість віддаленого виконання коду. Amazon Linux, навпаки, оцінює вразливість у 8.1 (Important), акцентуючи увагу на відмові в обслуговуванні та можливому пошкодженні пам’яті як основних наслідках. Ця розбіжність відображає різницю в оцінці практичної експлуатованості: гонка потребує точного таймінгу, і не кожен вендор вважає надійне досягнення RCE гарантованим.
Статус експлуатації
За даними Fortinet, вразливість не зафіксована в активній експлуатації. Canonical повідомляє, що, окрім внутрішнього дослідження Anthropic, інших експлойтів не відомо. На GitHub опубліковано код, який демонструє гонку та виявляє звернення до звільненої пам’яті в SYN-ACK, але без реалізації виконання коду. Ми уже писали про те, що внутрішня дослідницька модель Anthropic створила робочий експлойт для цієї вразливості, який дає змогу отримати root-доступ до серверів зі слухачем MPTCP без автентифікації. Код експлойта опублікований не був.
Уражені системи та доступні патчі
Вразливість зачіпає широкий спектр Linux-дистрибутивів:
- Red Hat Enterprise Linux 8, 9, 10 та Red Hat OpenShift Container Platform — патчі випущено 1 листопада (RHSA-2026:93414, RHSA-2026:93412, RHSA-2026:93413). Red Hat також зазначає, що продукти на базі ядра RHEL, зокрема Red Hat OpenStack Platform і Red Hat Virtualization, можуть бути уражені.
- Ubuntu 22.04, 24.04, 26.04 LTS — виправлення доступні в каналі -proposed (версії ядра 5.15.0-203.213, 6.8.0-149.149, 7.0.0-43.43 відповідно). Пакети з -proposed не встановлюються автоматично. Ubuntu 26.10 виправлено в основному каналі. Для Ubuntu 20.04 і старших патчів поки немає.
- Amazon Linux 2 і Amazon Linux 2023 — виправлення випущено між 24 і 30 жовтня.
- Fortinet — перевіряє вплив на понад 50 продуктів, зокрема FortiOS, FortiGate Cloud, FortiProxy, FortiManager, FortiAnalyzer, FortiWeb, FortiSIEM та інші. Статус розслідування — у процесі.
Рекомендації щодо захисту
Оновлення ядра з подальшим перезавантаженням — єдине повноцінне рішення, як підкреслюють і Red Hat, і Canonical. До встановлення патча доступні тимчасові заходи, що знижують, але не усувають ризик:
Фільтрація IPv4 TCP-пакетів з IP-опціями. Red Hat опублікував правило nftables:
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop
}
}Це правило блокує відомий вектор атаки, але має обмеження: воно діє лише на хості, де завантажене, і не фільтрує трафік між контейнерами на тому ж хості. Крім того, правило може порушити роботу застосунків, що використовують IPv4-опції.
Вимкнення MPTCP не є достатнім заходом. Red Hat прямо зазначає, що MPTCP не є передумовою вразливості — системи з вимкненим MPTCP залишаються вразливими. Canonical підтверджує: «Команда безпеки Ubuntu вважає, що оновлення безпеки — єдиний адекватний захід захисту».
Для перевірки поточної версії ядра використовуйте uname -r і порівняйте результат з версіями виправлених пакетів для вашого дистрибутива.
З огляду на наявність публічного PoC-коду, що демонструє гонку, критичну оцінку від більшості вендорів і широту уражених систем — від серверів до контейнерних платформ — оновлення ядра слід розглядати як пріоритетне завдання. Адміністраторам RHEL рекомендується встановити випущені патчі негайно; адміністраторам Ubuntu, які не можуть чекати виходу пакетів з -proposed в основний канал, — оцінити можливість раннього оновлення через -proposed з урахуванням ризиків тестового каналу.
