A Linux kernel vulnerability has been revealed, known as Fragnesia and identifier CVE-2026-46300. The problem relates to the same class of page cache attacks as the recently discussed Copy Fail and Dirty Frag, but it is not a re-publication of an old error: it refers to a distinct defect in the code of XFRM ESP-in-TCP.
. The vulnerability was discovered by researcher William Bowling from the team V12 Security. According to the published description, Fragnesia allows an unprivileged local user to modify the contents of read-only files in the page cache memory and, as a result, execute code with root privileges. Unlike many old LPE exploits, the attack does not require a race condition and is described by researchers as deterministic.
Technically, the problem is related to the fact that when network buffers are merged, the kernel may lose track of whether a data fragment is 'shared' and associated with an external memory page, including the page cache. The proposed patch describes this as an error in skb_try_coalesce(): when transferring paged fragments from one sk_buff to another, the SKBFL_SHARED_FRAG flag was not preserved. As a result, later ESP code might mistakenly consider the buffer safe for modification.
The practical effect is that data previously placed in the TCP queue from a file, after switching the socket to the espintcp mode, could be processed by the kernel as ESP ciphertext. When decrypted with AES-GCM, bytes were modified directly in the page cache page associated with the file. This does not change the file on disk, but alters its representation in memory until the page is evicted from the cache.
In the published attack demonstration, the target was /usr/bin/su: the exploit modified the initial bytes of the binary file in the page cache and then executed the modified in-memory copy, obtaining a shell with root privileges. The original file on disk remained unchanged, making the issue particularly unpleasant for diagnostics: traces of exploitation may disappear after clearing the page cache or rebooting.
A Fragnesia kevesebb mint egy héttel a Dirty Frag után jelent meg. A V12 hangsúlyozza, hogy ez egy külön hiba ugyanazon támadási felületen — ESP/XFRM — nem egy már javított sérülékenység átnevezése. A Phoronix azt is megjegyzi, hogy a publikálás időpontjában elérhető volt egy proof-of-concept, a javítás pedig egy kis patch volt a net/core/skbuff.c fájlhoz, amely még nem került az alapértelmezett kernelvekbe.
A Canonical CVE-2026-46300 magas prioritást adott az Ubuntu számára, megjelölve az okot mint "triviális helyi jogosultság-emelkedés". Az Ubuntu Security oldalán a frissítés időpontjában a sérintett kernelvek státusza "Értékelés szükséges" volt, és a megjegyzésben külön említik, hogy a probléma szintén található az ESP modulban és átmenetileg azonos módon lehet mérsékelni, mint a Dirty Frag esetében.
Debian Security Tracker a vizsgálat időpontjában jelölte meg sérülékenynek a bullseye, bookworm, trixie, forky és sid ágtartományok kerneljeit; a linux csomag instabil változatához még nem volt megadva a kijavított verzió.
A védelmi időszakos intézkedés ugyanaz marad, mint a Dirty Frag esetében: a modulok betöltésének letiltása esp4, esp6 és rxrpc, ha a rendszernek nincs szüksége rájuk. Ez megszakíthatja az IPsec alagutakat azon csomópontokon, ahol kernel ESP, strongSwan, Libreswan vagy hasonló konfigurációk használatosak, ezért VPN-hidakon ezt az intézkedést csak a következmények felmérése után érdemes alkalmazni.
Példa a vezetők számára az átmeneti mérséklésre:
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
Ha gyanítják, hogy a rendszer már támadás alatt állt, a modulok blokkolása nem elegendő: mivel a nyilvános demonstráció az executable fájlt pontosan a page cache-ben módosítja, a rendszergazdák javasolják a lapkészlet törlését vagy a rendszer újraindítását a védelmi intézkedések alkalmazása után. A CloudLinux egyértelműen kijelenti, hogy a kihasználás után a /usr/bin/su módosítva maradhat a memóriában, amíg a megfelelő lapokat ki nem szorítják.
A temporális szabály eltávolításához a javított kernel telepítése után eltávolíthatja a létrehozott fájlt:
sudo rm /etc/modprobe.d/dirtyfrag.conf
A fő ajánlás továbbra is az alapértelmezett: telepítse a disztribúciójától származó javított kernelt, és indítsa újra a rendszert. A frissítés előtt a legnagyobb kockázatot a többfelhasználós szerverek, CI-futtatók, megosztott tárhely, konténeres build-farmok és bármely gép jelenti, ahol nem privilégizált vagy részben megbízható felhasználók futtathatnak helyi kódot.
Forrás: linux.org.ru
