В ядре Linux раскрыта очередная уязвимость локального повышения привилегий, получившая название Fragnesia и идентификатор CVE-2026-46300. Проблема относится к тому же классу атак на page cache, что и недавно обсуждавшиеся Copy Fail и Dirty Frag, но не является повторной публикацией старой ошибки: речь идёт об отдельном дефекте в коде XFRM ESP-in-TCP.

Уязвимость обнаружил исследователь William Bowling из команды V12 Security. По данным опубликованного описания, Fragnesia позволяет непривилегированному локальному пользователю изменять содержимое файлов, доступных только для чтения, в памяти page cache и за счёт этого выполнять код с правами root. В отличие от многих старых LPE-эксплойтов, атака не требует гонки и описывается исследователями как детерминированная.

Технически проблема связана с тем, что при объединении сетевых буферов ядро могло потерять признак того, что фрагмент данных является «общим» и связан с внешней страницей памяти, в том числе с page cache. В предложенном патче это описано как ошибка в skb_try_coalesce(): при переносе paged fragments из одного sk_buff в другой не сохранялся флаг SKBFL_SHARED_FRAG. В результате более поздний код ESP мог ошибочно считать буфер безопасным для изменения.

Практический эффект заключается в том, что данные, ранее помещённые в TCP-очередь из файла, после переключения сокета в режим espintcp могли обрабатываться ядром как ESP-шифротекст. При расшифровке AES-GCM байты изменялись непосредственно в странице page cache, связанной с файлом. Это не меняет файл на диске, но меняет его представление в памяти до вытеснения страницы из кэша.

В опубликованной демонстрации атаки в качестве цели использовался /usr/bin/su: эксплойт модифицировал первые байты бинарного файла в page cache и затем запускал изменённую в памяти копию, получая shell с правами root. Исходный файл на диске при этом оставался неизменным, что делает проблему особенно неприятной для диагностики: следы эксплуатации могут исчезнуть после очистки page cache или перезагрузки.

Fragnesia появилась менее чем через неделю после Dirty Frag. В V12 подчёркивают, что это отдельная ошибка в той же поверхности атаки — ESP/XFRM, — а не переименование уже исправленной уязвимости. Phoronix также отмечает, что на момент публикации был доступен proof-of-concept, а исправление представляло собой небольшой патч к net/core/skbuff.c, ещё не сразу попавший в основные ветки ядра.

Canonical присвоила [ CVE-2026-46300 ]( https://ubuntu.com/security/CVE-2026-46300 ) высокий приоритет для Ubuntu, указав причину как «trivial local privilege escalation». На странице Ubuntu Security для затронутых ядер на момент обновления 13 мая значился статус «Needs evaluation», а в примечании отдельно сказано, что проблема также находится в ESP-модуле ядра и может временно смягчаться тем же способом, что и Dirty Frag.

[ Debian Security Tracker ]( https://security-tracker.debian.org/tracker/CVE-2026-46300 ) на момент проверки помечал уязвимыми ядра в ветках bullseye, bookworm, trixie, forky и sid; для пакета linux в unstable фиксированная версия ещё не была указана.

Временная мера защиты остаётся такой же, как для Dirty Frag: [ отключить загрузку модулей ]( https://blog.cloudlinux.com/fragnesia-mitigation-and-kernel-update ) esp4, esp6 и rxrpc, если они не нужны системе. Это может нарушить работу IPsec-туннелей на узлах, где используются kernel ESP, strongSwan, Libreswan или похожие конфигурации, поэтому на VPN-шлюзах такую меру нужно применять только после оценки последствий.

Пример временного смягчения для администраторов:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

Если есть подозрение, что система уже могла быть атакована, одной блокировки модулей недостаточно: поскольку публичная демонстрация меняет исполняемый файл именно в page cache, администраторы рекомендуют очистить кэш страниц или перезагрузить систему после применения мер защиты. CloudLinux прямо указывает, что после эксплуатации /usr/bin/su может оставаться изменённым в памяти до вытеснения соответствующих страниц.

Для удаления временного правила после установки исправленного ядра можно убрать созданный файл:

sudo rm /etc/modprobe.d/dirtyfrag.conf

Главная рекомендация остаётся стандартной: установить исправленное ядро от своего дистрибутива и перезагрузить систему. До обновления наибольший риск несут многопользовательские серверы, CI-раннеры, shared hosting, контейнерные build-фермы и любые машины, где непривилегированные или частично доверенные пользователи могут выполнять локальный код.

https://www.linux.org.ru/news/security/18292778