🚨 18 ЛЕТ. Баг сидел в ядре Linux дольше, чем некоторые из вас в IT работают 💀🐧 — 16 августа 2026 г. в 11:21:01.811
🚨 18 ЛЕТ. Баг сидел в ядре Linux дольше, чем некоторые из вас в IT работают 💀🐧 Народ, это тот самый случай, когда "старый код" не значит "проверенный код". Ребята из Tencent Zhuque Lab откопали в сетевом стеке Linux use-after-free, который живёт там с декабря 2007 года, с коммита в ядро 2.6.25. Назвали красиво - SCTPhantom, CVE-2026-64564, CVSS 8.5. И да, из этого призрака достали root. Разбираю технику 👇 Баг сидит в обработке SCTP (Stream Control Transmission Protocol) - протокола, который редко на слуху, но живёт в куче Linux-систем по умолчанию. Конкретно - в механизме Dynamic Address Reconfiguration (ASCONF), который позволяет на лету менять IP-адреса активного SCTP-соединения. Суть косяка: ядро проверяет DEL-IP операцию по одному адресу из пакета, а реально действует по другому transport, который выбрало из другого адреса в том же сообщении. Это классическая рассинхронизация "что проверили" vs "что использовали". Специально собранная ASCONF-последовательность убивает transport-объект, а указатель на него остаётся висеть - и потом используется повторно (use-after-free) Условия для эксплуатации: - нужен локальный доступ (это НЕ remote-баг) - SCTP должен быть достижим на целевой системе Дальше исследователи превратили memory-corruption в стабильную эскалацию привилегий до root. И вот тут разрыв шаблона: они пошли дальше и протестировали побег из контейнера. Результат - 6 из 8 попыток пробили границу контейнера и получили root на хосте, причём в контейнере со стандартным seccomp-профилем, БЕЗ CAP_NET_ADMIN и CAP_SYS_ADMIN. Проверяли на Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9-семействе и OpenCloudOS - то есть это не экзотика, это твой типичный прод-сервер. Как закрывать дыру - Патчи уже выехали: стабильные ядра 7.1.6, 6.18.42, 6.12.101, 6.6.148 (релиз 3 августа 2026), фикс также в mainline 7.2-rc5 - Если апгрейд ядра не срочный - минимизируй достижимость SCTP: блокируй протокол на файрволе, если он тебе не нужен по бизнес-логике - В контейнерных средах - лишний повод пересмотреть seccomp-профили и не полагаться на дефолтные ограничения как на непробиваемую стену - Если у тебя shared-хостинг или multi-tenant контейнерная инфра - патч приоритетный, а не "накатим в следующем цикле" Мораль 18 лет код жил в проде миллионов систем, и никто не смотрел на него достаточно пристально, пока исследователи не выцепили несостыковку в паре строк проверки адреса. Зашей это себе в напоминалку: "старый и стабильный" ≠ "аудированный". Иногда самый жирный 0day - это баг, который был у всех на виду с нулевых 😎🔐

