Root без пароля: как PinTheft превращает io_uring в инструмент захвата ядра.
Сервер закрыт по всем фронтам. Nginx за Cloudflare, fail2ban банит ботов, root-логин по SSH отключён, все порты кроме 22, 80 и 443 заблокированы nftables. Потом кто-то получает непривилегированный shell — через уязвимый плагин, слабый пароль, что угодно. Запускает скрипт. Через несколько секунд — root.
Добро пожаловать в PinTheft.
ЧТО СЛУЧИЛОСЬ
21 мая 2026 года SecurityLab опубликовал детали уязвимости в ядре Linux под названием PinTheft. Обнаружила её команда V12 — в подсистеме RDS (Reliable Datagram Sockets), отвечающей за передачу надёжных датаграмм, преимущественно во внутрикластерном взаимодействии.
PoC-эксплойт уже лежит на GitHub. CVE-идентификатор не присвоен. Патч опубликован командой ядра ещё 5 мая — значит окно между патчем и публичным эксплойтом составило две недели. Если вы не обновили ядро за это время — вы в группе риска.
КАК ЭТО РАБОТАЕТ
В механизме zerocopy подсистемы RDS обнаружена ошибка double-free: одна и та же страница памяти освобождается дважды. Zerocopy — это способ передачи данных между ядром и приложением без физического копирования: вместо копирования передаются ссылки на страницы памяти. Быстро, эффективно — и здесь именно это становится проблемой. Сама по себе ошибка неприятна, но не катастрофа. Катастрофа начинается с io_uring.
io_uring — асинхронный интерфейс ввода-вывода в ядре Linux, появившийся в версии 5.1. Он позволяет приложениям отправлять очереди операций ядру с минимальными накладными расходами. Именно эта механика используется для атаки: атакующий формирует серию io_uring-запросов, которые попадают в момент двойного освобождения и начинают перехватывать ссылки на страницы памяти ядра — это и есть pin stealing. Постепенно накапливая контроль над страницами, атакующий получает возможность выполнить произвольный код с правами kernel. Результат — root без пароля.
Требования для успешной атаки:
— модуль rds загружен
— io_uring включён
— в системе есть любой SUID-бинарник (sudo, pkexec — достаточно)
— архитектура x86_64
— локальный доступ к системе
КТО УЯЗВИМ
Из популярных дистрибутивов rds загружается по умолчанию только в Arch Linux — поэтому основной удар придётся туда. Но это не означает, что Debian, Ubuntu и RHEL в безопасности: если rds загружен (например, потому что какое-то приложение запросило соответствующий socket), система уязвима.
Проверяется одной командой:
lsmod | grep rds
Если есть вывод — rds загружен. При наличии остальных условий система под угрозой.
НАСКОЛЬКО ЭТО СЕРЬЁЗНО
Для типичного VPS или выделенного сервера — средняя. Вот почему.
Смягчающие факторы:
— требует локального доступа, удалённо не эксплуатируется
— на Ubuntu/Debian/RHEL rds не загружен по умолчанию
— нужна конкретная комбинация условий одновременно
Что делает её серьёзной:
— PoC публичный, порог входа нулевой
— если у атакующего уже есть непривилегированный shell (через дырявый WordPress, например) — это прямой путь к root
— нет CVE, значит автоматические сканеры её не видят
Где реально опасно:
— shared hosting с несколькими пользователями на одной машине
— VPS с панелями типа cPanel/Plesk где у клиентов есть shell
— CI/CD системы где запускается код из репозиториев
— серверы разработки с несколькими SSH-пользователями
Где риск минимален:
— одиночный VPS с одним администратором без посторонних пользователей: чтобы использовать PinTheft, атакующий сначала должен попасть на сервер — а это уже отдельная задача
Коротко: сама по себе не катастрофа, но в связке с любой уязвимостью веб-приложения становится финальным аккордом атаки.
ЧТО ДЕЛАТЬ ПРЯМО СЕЙЧАС
Шаг 1. Выгрузить rds и заблокировать навсегда:
sudo modprobe -r rds
echo "install rds /bin/false" | sudo tee /etc/modprobe.d/disable-rds.conf
echo "blacklist rds" | sudo tee -a /etc/modprobe.d/disable-rds.conf
# Debian/Ubuntu — пересобрать initramfs, иначе блокировка не выживет после перезагрузки
sudo update-initramfs -u
# RHEL/Fedora
sudo dracut -f
Почему два правила, а не одно: blacklist запрещает автоматическую загрузку модуля, но его всё равно можно загрузить вручную через modprobe rds или как зависимость другого модуля. install rds /bin/false перехватывает любую попытку загрузки — включая косвенные — и вместо модуля запускает /bin/false, которая мгновенно завершается с ошибкой. Вместе они закрывают оба пути.
Почему нужен initramfs rebuild: правила modprobe.d читаются при загрузке системы из образа initramfs. Если его не пересобрать — новые правила в образ не попадут, и после перезагрузки система будет работать со старым initramfs без блокировки.
Шаг 2. Ограничить io_uring (осторожно — может сломать PostgreSQL 16+ и некоторые container runtimes):
Сначала проверить текущее состояние:
cat /proc/sys/kernel/io_uring_disabled
# 0 = включён для всех
# 1 = отключён для непривилегированных пользователей
# 2 = полностью отключён
Для mitigation нужно минимум =1. Значение =2 полностью убирает вектор, но ломает всё что использует io_uring — включая PostgreSQL 16+. Если не уверены — ставьте =1, он перекрывает вектор атаки (атака требует непривилегированного пользователя) с меньшим риском для сервисов:
sudo sysctl -w kernel.io_uring_disabled=1
echo "kernel.io_uring_disabled=1" | sudo tee /etc/sysctl.d/99-io-uring.conf
Шаг 3. Обновить ядро и перезагрузиться:
# Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic
# RHEL/Fedora
sudo dnf update kernel
После перезагрузки — убедиться что rds больше не загружается:
lsmod | grep rds
# Пустой вывод — хорошо
КОНТЕКСТ: ВОЛНА 2026
PinTheft — не изолированная история. В 2026 году исследователи последовательно публикуют уязвимости в подсистемах zerocopy и io_uring ядра Linux: DirtyDecrypt, DirtyCBC, Dirty Frag, Fragnesia, Copy Fail. Это говорит о том, что данная область ядра системно изучается.
Следите за [email protected] и security advisories своего дистрибутива. Многие из этих уязвимостей появляются там раньше, чем получают CVE-идентификатор — как это произошло с PinTheft.
