В ядре 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 высокий приоритет для Ubuntu, указав причину как «trivial local privilege escalation». На странице Ubuntu Security для затронутых ядер на момент обновления 13 мая значился статус «Needs evaluation», а в примечании отдельно сказано, что проблема также находится в ESP-модуле ядра и может временно смягчаться тем же способом, что и Dirty Frag.
Debian Security Tracker на момент проверки помечал уязвимыми ядра в ветках bullseye, bookworm, trixie, forky и sid; для пакета linux в unstable фиксированная версия ещё не была указана.
Временная мера защиты остаётся такой же, как для Dirty Frag: отключить загрузку модулей 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-фермы и любые машины, где непривилегированные или частично доверенные пользователи могут выполнять локальный код.
>>> Источник
