Если у вас self-hosted сервер на Ubuntu или RHEL, свежая CVE в ядре Linux - резкое напоминание об очень конкретной ловушке: новый номер версии ядра - это не то же самое, что пропатченный сервер. CVE-2026-98432 - удалённый use-after-free без аутентификации в IPv4 TCP-стеке Linux, рейтинг 9.8 (Critical) от собственной CVE-команды ядра и cve.org.[1] Upstream починил её в стабильных ядрах от 5.10.272 до 7.3.[1][5] Но по состоянию на 1 ноября 2026 Ubuntu и Red Hat Enterprise Linux не выпустили пропатченное ядро - Ubuntu помечает свои поддерживаемые релизы как «Vulnerable / work in progress», а Red Hat всё ещё ускоряет выпуск фикса.[2][3][4] На таких системах uname -r спокойно выведет вполне современное ядро, которое при этом уязвимо. В этой статье - что это за баг, почему версия на экране враньё и какие шаги сделать до (и после) выхода kernel-патча.

Баг: чтение освобождённых опций во время IPv4 TCP-handshake

CVE-2026-98432 - гонка в том, как ядро передаёт состояние соединения во время TCP-handshake.[1] В tcp_v4_syn_recv_sock() ядро передаёт владение ireq->ireq_opt (IP-опции входящего запроса соединения) дочернему сокету без копирования.[1] Параллельно на другом CPU повторно отправленный SYN для того же request-сокета может обработаться, и tcp_check_req() может послать SYNACK, который снова читает ireq->ireq_opt.[1] С коммита 079096f103fa («tcp/dccp: install syn_recv requests into ehash table») request-сокеты обрабатываются без удержания listener-лока - и ничто не мешает дочернему сокету быть освобождённым, пока SYNACK ещё строится.[1] У TCP-дочерних сокетов нет SOCK_RCU_FREE, а inet_sock_destruct() освобождает inet_opt обычным kfree() - поэтому конкурентный путь читает уже освобождённую память: классический use-after-free в ip_options_build().[1]

Есть и второй триггер - через миграцию request-сокета (net.ipv4.tcp_migrate_req=1 или программа BPF_SK_REUSEPORT_SELECT_OR_MIGRATE), где клонированный request-сокет и его клон делят один ireq_opt, и клон может быть освобождён, пока другой CPU ещё держит ссылку на старый.[1] Фикс меняет обычные kfree() в inet_sock_destruct() и tcp_v4_reqsk_destructor() на kfree_rcu(), чтобы память освобождалась только после grace-периода RCU - к этому моменту все читатели уже закончили.[1][5] IPv6 не затронут первой проблемой (v6-путь дублирует опции), хотя отдельная проблема миграции закрывается отдельным патчем.[1]

Уязвимый код есть в ядре с Linux 4.4.[1] Главное - он достижим обычным, неаутентифицированным IPv4 TCP-трафиком: Red Hat отмечает, что атакующему не нужны привилегии и пользовательское взаимодействие, достаточно быть в сети, поэтому в корпоративных конфигурациях, где TCP-сервисы по умолчанию принимают входящие соединения, рейтинг Critical.[3][4]

Почему uname -r вам врёт

Вот что чаще всего подводит владельцев VPS. Upstream-ядро починило это в 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 и 7.3 - версии, которые cve.org перечисляет как «unaffected» для каждой стабильной ветки.[1][5] Но практически никто не грузит голый upstream-kernel. Вы грузите ядро своего дистрибутива, и у него своя строка версии и свой статус патчинга, которые к номерам upstream-релизов отношения не имеют.[2][3] uname -r показывает работающее ядро; он не показывает, закрыта ли CVE вашим вендором. А в этом случае, по состоянию на 1 ноября 2026, два крупнейших дома self-managed серверов сидят ровно в окне уязвимости:

  • Ubuntu 26.10, 26.04 LTS, 24.04 LTS и 22.04 LTS: «Vulnerable - work in progress». Трекер безопасности Ubuntu показывает фикс как introduced коммитом 079096f и resolved e3f33b0, но ни пропатченного ядра, ни Ubuntu Security Notice для ни одного поддерживаемого релиза нет; 20.04 и 18.04 тоже остаются «Vulnerable».[2] Обратите внимание: Ubuntu оценивает это как 8.3 (High) по CVSS v4.0, а команда ядра и cve.org - как 9.8 (Critical) по v3.1. Тот же баг, разные правила скоринга - ещё один слой путаницы, который лучше просто игнорировать.[1][2]
  • Red Hat Enterprise Linux 8, 9 и 10: affected, фикс не выпущен. Бюллетень Red Hat RHSB-2026-016 (от 30 октября) оценивает это как Critical, прямо относит RHEL 8/9/10 и OpenShift к затронутым и пишет, что Red Hat «ускоряет выпуск фиксов».[3][4] Митигация ниже - задокументированная промежуточная мера самого Red Hat.
  • Debian 12 и 13: заплатены. Debian выпустил исправленные ядра - 6.1.190-1 для bookworm, 6.12.113-1 для trixie и 6.12.113-1~deb12u1 для опт-ин ядра 6.12 в bookworm (авизы DLA-4841-1, DLA-4850-1, DSA-6568-1).[6]
  • SUSE: неоднородно. Собственный скоринг SUSE по CVSS v4.0 - 9.2 (вектор с Attack Requirements = Present; строже, чем 8.3 у Ubuntu). Статусы по продуктам разные: исправленные ядра уже в статусе Released для SUSE Linux Enterprise Micro 5.3–5.5, SLE High Availability Extension 16.0 и HPC 15 SP5-LTSS, а у SLED/SLES 15 SP7 пакет kernel-source всё ещё In progress, сами kernel-default - Affected.[7]

Поэтому ответ на вопрос «какое ядро меня защищает» - это не номер версии, который можно загуглить, а статус, который ваш дистрибутив публикует именно для этой CVE, и он меняется ежедневно.[2][3][7]

Что делать прямо сейчас, до выхода kernel-патча

Пока дистрибутив не выпустил исправленное ядро, экспозицию можно уменьшить (не устранить) фильтрацией опасного трафика. Для RHEL (и в целом для любого хоста на nftables) бюллетень безопасности Red Hat документирует nftables-таблицу, которая отбрасывает входящие IPv4 TCP-пакеты с IP-опциями - именно тот путь обработки опций, которого касается use-after-free.[4] Обычный трафик приложений в целом не затрагивается: стандартные TCP-опции живут в TCP-заголовке и остаются разрешёнными, но Red Hat явно предупреждает проверить правило на своём трафике и протестировать его не в production.[4]

Сохраните это в файл cve-2026-98432.nft:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Затем загрузите его командами check-and-load из бюллетеня:

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Чтобы потом убрать его (например, после загрузки пропатченного ядра):[4]

sudo nft delete table inet cve_2026_98432

Ещё два промежуточных шага стоит сделать на любом хосте, который не нужно намеренно раскрывать:

  • Выключите MPTCP там, где его не используете. Сообщество безопасности активно обсуждает эту CVE с конца октября, и есть сообщения о рабочей цепочке удалённого root-эксплойта против хостов, раскрывающих multipath-TCP listener.[8] Это сигнал сообщества, а не часть официальной митигации Red Hat или CNA ядра, так что относитесь к шагу как к дополнительному укреплению: если workload’ов на MPTCP у вас нет, отключение пути net.mptcp.enabled убирает широко обсуждаемую поверхность триггера. (Ни запись в CVE, ни бюллетень Red Hat не документируют MPTCP в официальных митигациях, так что фильтр не заменяет фикс ядра.)[1][4]
  • Помните: ваши контейнеры делят ядро хоста. Фикс в ядре, а не в runtime или базовом образе. Если приложение живёт в Docker, обновление образа ничего не меняет, пока не пропатчено и (см. ниже) не перезагружено ядро хоста. Прокси и оркестраторы тут тоже не помогут - это уровень ядра, а не уровень приложений.

Апдейт ядра не закончен, пока не сделан перезапуск

Этому нужен отдельный раздел, потому что это самая частая причина, по которой «пропатченный» VPS на самом деле не пропатчен. Апдейт ядра на Ubuntu или RHEL устанавливает новый kernel-образ, но не подменяет его в текущей работающей системе - старое уязвимое ядро продолжает работать до перезагрузки (или покупки live-patching, что отдельная история). Последовательность, которая реально закрывает дыру:

  1. Сверьте работающее ядро со статусом CVE у вашего дистрибутива, а не со списком upstream-версий: uname -r, затем сравните со столбцом fixed-версии в своём трекере.[2][3][6]
  2. Примените apt upgrade (Ubuntu/Debian) или апдейт RHEL, как только выйдет авиз.[2][3]
  3. Перезагрузитесь и проверьте, что новое ядро реально работает (снова uname -r).
  4. Если ставили nftables-фильтр - его можно снять, когда работающее ядро совпадёт с fixed-версией.

Пока не сделан шаг 3, CVE не закрыта, как бы ни выглядел вывод пакетного менеджера.

Больший урок для self-hosting

Каждый self-hosted VPS на Ubuntu или RHEL, который принимает входящие IPv4 TCP-соединения, прямо сейчас сидит в радиусе поражения этой CVE - то самое ядро, на котором у вас работают публичный сайт, API, сокет БД или SSH, и есть путь атаки.[3][4] Долгосрочный вывод - тот, ради которого этот баг и создан: статус патчинга ядра - это свойство трекера вашего дистрибутива, а не строки upstream-версии на экране. Когда видите CVE с удалённым, неаутентифицированным рейтингом «Critical», рефлекс «проверю свою версию» неверный - спасающий рефлекс такой: «проверю статус этого CVE у своего дистрибутива, затем удостоверюсь, что работающее ядро реально изменилось». Вместе с промежуточным nftables-фильтром, отключением ненужного MPTCP и явным шагом перезагрузки это превращает страшный авиз в короткий проверяемый чек-лист на сервере, который под вашим контролем.

Источники

  1. CVE.org - запись CVE-2026-98432 (опубликована 15.10.2026; описание IPv4 use-after-free и фикса kfree_rcu; CVSS 3.1 base 9.8, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H; затронуто с 4.4 / коммита 079096f103fa; «unaffected» с 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3; ссылки на stable-коммиты). https://www.cve.org/CVERecord?id=CVE-2026-98432 - checked 2026-11-01
  2. Ubuntu - security tracker CVE-2026-98432 (статусы релизов: 26.10/26.04 LTS/24.04 LTS/22.04 LTS «Vulnerable work in progress», 20.04/18.04 «Vulnerable»; patch details introduced 079096f, fixed e3f33b0; CVSS v4.0 base 8.3 High). https://ubuntu.com/security/CVE-2026-98432 - checked 2026-11-01
  3. Red Hat Customer Portal - CVE-2026-98432 (Critical; CVSS 3.1 base 9.8; неаутентифицированный удалённый атакующий, без привилегий и пользовательского взаимодействия; затронуты RHEL 8/9/10; указание на митигацию). https://access.redhat.com/security/cve/CVE-2026-98432 - checked 2026-11-01
  4. Red Hat Security Bulletin - RHSB-2026-016 «Use-after-free - kernel IPv4 (CVE-2026-98432)» (опубликован 30.10.2026; рейтинг Critical; затронутые продукты RHEL 8/9/10, OpenShift и слои на ядре RHEL; ускорение выпуска фиксов; nftables-таблица inet cve_2026_98432 с hdrlength > 5 drop и команды sudo nft --check/--file/list/delete table). https://access.redhat.com/security/vulnerabilities/RHSB-2026-016 - checked 2026-11-01
  5. Ядро Linux - основной фикс-коммит e3f33b0a1d89 «ipv4: free inet_opt and ireq_opt after an RCU grace period» (resolved в 7.3-rc7; меняет kfree() на kfree_rcu() в inet_sock_destruct() и tcp_v4_reqsk_destructor(); ID коммита перекрёстно подтверждён трекерами cve.org, Ubuntu и Debian). https://git.kernel.org/linus/e3f33b0a1d89d738e2b913dab519226eaf76e15b - checked 2026-11-01
  6. Debian Security Tracker - CVE-2026-98432 (bookworm linux 6.1.190-1 fixed через DLA-4841-1; bookworm linux-6.12 6.12.113-1~deb12u1 через DLA-4850-1; trixie linux 6.12.113-1 fixed через DSA-6568-1). https://security-tracker.debian.org/tracker/CVE-2026-98432 - checked 2026-11-01
  7. SUSE - CVE-2026-98432 (собственная оценка по CVSS v4.0: base 9.2, вектор CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H; статусы по продуктам: исправленное ядро Released для SLE Micro 5.3–5.5, SLE HA Extension 16.0, HPC 15 SP5-LTSS; SLED/SLES 15 SP7 - kernel-source In progress, kernel-default Affected). https://suse.com/security/cve/CVE-2026-98432 - checked 2026-11-01
  8. Hacker News - тред о CVE-2026-98432 (501 балл на 01.11.2026; сигнал сообщества - обсуждение и сообщения об исследовании remote-root эксплойта через MPTCP; НЕ источник факта). https://news.ycombinator.com/item?id=50319143 - checked 2026-11-01