← Все новости

В ядре Linux — TCP use-after-free с оценкой 9.8: Ubuntu и RHEL остались без патчаLinux kernel TCP use-after-free rated 9.8: Ubuntu and RHEL still have no fix

CVE-2026-98432 — use-after-free в обработке TCP-соединений IPv4: удалённый неаутентифицированный пир может испортить память ядра или добиться выполнения кода. Исправление вышло 11–15 октября, но в ядрах Ubuntu и RHEL на 31 октября его не было.CVE-2026-98432 is a use-after-free in IPv4 TCP connection handling that lets an unauthenticated remote peer corrupt kernel memory or achieve code execution. The upstream fix landed on 11–15 October, yet Ubuntu and RHEL kernels still lacked it on 31 October.

Когда Linux принимает TCP-соединение, ядро сначала держит незавершённое рукопожатие в «request socket», а после его завершения создаёт полноценный сокет. Если в заголовке IPv4 были опции, ядро сохраняло их, чтобы повторить в ответе. Ошибка в том, что эти опции передавались новому соединению без копирования и тут же освобождались, хотя другая CPU ещё могла читать их, собирая ответ на повторный запрос. Это use-after-free в коде, который выполняется до того, как соединение увидит приложение: ни логина, ни взаимодействия с пользователем не требуется.

Исправление Эрика Дюмазе меняет два вызова kfree() на kfree_rcu(), то есть освобождает память только после того, как все читатели закончили с ней работу. Ошибка живёт в ядрах начиная с 4.4, исправленные версии — 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 и 7.3.

Почему это громко

Уязвимость нашёл Xinyang Ge из Anthropic, а рабочий proof-of-concept, по словам компании, написал Claude — эксплойт запускал команды от root на серверах с multipath TCP listener. Go-программы с версии 1.24 открывают такие сокеты по умолчанию, так что окружение, нужное для атаки, встречается чаще, чем казалось. Оценка по CVSS — 9.8, Red Hat 30 октября подняла важность до критической.

Где патч есть, а где нет

На 31 октября исправленные ядра выпустили Debian, Amazon Linux, SUSE и Oracle UEK; в AlmaLinux они лежали в тестовом репозитории. Ubuntu во всех релизах числилась уязвимой, у Red Hat — RHEL 8, 9, 10 и OpenShift без исправления.

Что делать

Пока патча нет, помогает правило nftables, отбрасывающее входящие TCP-пакеты, у которых длина заголовка IPv4 больше 20 байт. Это снижает риск, но не заменяет обновление. Проверить, есть ли на хосте MPTCP-сокеты, можно командой ss -Mlnp.

When Linux accepts a TCP connection, the kernel first tracks the half-open handshake in a request socket and creates a full socket once the handshake completes. If the peer’s IPv4 header carried options, the kernel kept them in order to echo them back. The bug: those options were handed to the new connection without being copied and freed immediately, while another CPU could still be reading them to build a reply. That is a use-after-free in code that runs before any application sees the connection — no login, no user interaction.

Eric Dumazet’s fix replaces two plain kfree() calls with kfree_rcu(), which frees memory only after every reader is done with it. The flaw goes back to Linux 4.4; fixed releases are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3.

Why it matters

Xinyang Ge of Anthropic reported the flaw, and the company says Claude wrote a working proof-of-concept that ran commands as root on servers with a multipath TCP listener. Go programs enable MPTCP by default for listen sockets since Go 1.24, so the setup the exploit needs is more common than it first looked. The kernel CNA scores it 9.8, and Red Hat raised its own rating to Critical on 30 October.

Where the fix exists

As of 31 October, fixed kernels had shipped from Debian, Amazon Linux, SUSE and Oracle’s UEK; AlmaLinux had builds in its testing repository. Ubuntu listed its kernel as vulnerable on every release, and Red Hat still listed RHEL 8, 9, 10 and OpenShift as affected without a fix.

What to do

Until your distribution ships a kernel, an nftables rule that drops inbound TCP packets whose IPv4 header is longer than 20 bytes reduces exposure. It is not a substitute for patching. To see whether a host has MPTCP sockets at all, run ss -Mlnp.

Источники