В ядрото на Linux е разкрита нова уязвимост за локално повишаване на права, наречена Fragnesia и идентификатор CVE-2026-46300. Проблемата е свързана със същия клас атаки на page cache, каквито наскоро бяха обсъждани - Copy Fail и Dirty Frag, но не е повторна публикация на стара грешка: става дума за отделен дефект в кода XFRM ESP-in-TCP.
Уязвимостта беше открита от изследователя Уилям Боулънг от екипа на 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, посочвайки причината като „тривиално локално ескалиране на права“. На страницата за Ubuntu Security за засегнатите ядра към момента на обновлението на 13 май беше посочен статус „Нужна оценка“, а в бележките е казано, че проблемът също е в 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/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /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 ранери, споделен хостинг, контейнерни build-ферми и всякакви машини, където неподадените или частично доверени потребители могат да изпълняват локален код.
Източник: linux.org.ru
