Dirty Frag (CVE-2026-43284) — Vulnerabilitate critică în kernel-ul Linux care permite escaladare la root

Pe 7 mai 2026, cercetătorul de securitate Hyunwoo Kim (cunoscut și ca @v4bel) a publicat detalii despre o vulnerabilitate critică în kernel-ul Linux, denumită Dirty Frag. Bug-ul a primit ulterior, pe 8 mai, identificatorul CVE-2026-43284 (pentru componenta IPsec ESP), urmat de CVE-2026-43500 (pentru componenta RxRPC).

Spre deosebire de practica standard de „responsible disclosure”, informațiile au fost publicate înainte ca distribuțiile Linux să pregătească patch-uri, deoarece embargo-ul a fost spart de o terță parte care a publicat prematur un exploit pe 7 mai. Un proof-of-concept funcțional este disponibil public pe GitHub, iar **orice utilizator local neprivilegiat poate obține drepturi root cu o singură comandă**.

În acest articol explicăm ce este Dirty Frag, cum funcționează, cine este afectat, ce mitigări sunt disponibile și ce facem noi pentru a proteja infrastructura clienților noștri.

Ce este Dirty Frag

Dirty Frag se înscrie în aceeași clasă de vulnerabilități ca **Dirty Pipe** (descoperită în 2022) și **Copy Fail** (CVE-2026-31431, descoperită cu o săptămână înainte). Toate trei exploatează modul în care kernel-ul Linux gestionează *page cache* — copia în memorie pe care kernel-ul o menține pentru fișierele de pe disc, în scop de performanță.

Tehnic, Dirty Frag înlănțuie două vulnerabilități separate, ambele descoperite de Kim:

1. **xfrm-ESP Page-Cache Write** — în path-ul de decriptare al modulelor `esp4` și `esp6` (IPsec)
2. **RxRPC Page-Cache Write** — în path-ul de verificare al pachetelor în modulul `rxrpc`

Mecanismul de exploatare

Atacul funcționează astfel: când apelul de sistem `splice()` plasează o referință la o pagină read-only de page cache (de exemplu o pagină din `/etc/passwd` sau din `/usr/bin/su`) în slot-ul `frag` al unui `sk_buff` (socket buffer), codul kernel din partea de recepție efectuează operațiuni criptografice „in-place” direct peste acea pagină. Rezultatul: page cache-ul fișierelor protejate este modificat în RAM, iar orice citire ulterioară a fișierului — inclusiv din partea altor utilizatori sau procese — vede copia modificată.

Cu alte cuvinte, un atacator local poate suprascrie binare setuid (cum este `/usr/bin/su`) sau fișiere de configurație critice (cum este `/etc/passwd`) pentru a obține un shell root.

De ce este Dirty Frag deosebit de periculos

– **Bug logic determinist** — spre deosebire de race condition-urile clasice, Dirty Frag nu necesită noroc de timing; kernel-ul nu intră în panic în caz de eșec, iar rata de succes este foarte mare, chiar de la prima încercare.
– **Mitigarea Copy Fail nu te protejează** — chiar dacă ați aplicat anterior blacklist-ul pe modulul `algif_aead` (mitigarea recomandată pentru Copy Fail), sistemul rămâne vulnerabil la Dirty Frag.
– **Exploit public disponibil** — codul a fost publicat pe GitHub (`V4bel/dirtyfrag`) și replicat și sub numele „Copy Fail 2: Electric Boogaloo”.
– **Acoperire largă** — combinarea celor două bug-uri permite escaladare la root pe Ubuntu, RHEL, AlmaLinux, Rocky Linux, CentOS Stream, CloudLinux, Fedora și openSUSE Tumbleweed. Calea ESP necesită posibilitatea de a crea user namespaces neprivilegiate (uneori blocată pe Ubuntu prin AppArmor), iar calea RxRPC nu are nevoie de namespaces, dar modulul `rxrpc.ko` nu este încărcat implicit pe majoritatea distribuțiilor — cu excepția Ubuntu, unde se încarcă din start. Lanțul celor două căi acoperă reciproc punctele oarbe.

Sisteme afectate

Cum verificați dacă sunteți expuși

# Verificați dacă modulele vulnerabile sunt încărcate în prezent
lsmod | grep -E 'esp4|esp6|rxrpc'

# Verificați versiunea kernel-ului
uname -r

# Pentru sisteme RHEL/AlmaLinux/Rocky — verificați dacă pachetul kernel-modules-partner este instalat
rpm -q kernel-modules-partner 2>/dev/null
```

Mitigare imediată (până la un patch oficial)

Singura mitigare disponibilă în acest moment, înainte ca distribuțiile să publice kernel-uri patch-uite stabile, este blocarea încărcării modulelor vulnerabile și descărcarea lor din kernel:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
```

Această comandă:
1. Creează un fișier `modprobe.d` care redirecționează încărcarea celor trei module către `/bin/false` (împiedică reîncărcarea ulterioară).
2. Descarcă modulele dacă sunt încărcate.
3. Curăță page cache-ul, eliminând posibile pagini corupte deja prezente în memorie.

Atenție la impactul funcțional

– **Servere web obișnuite (WordPress, hosting, aplicații PHP/Node.js):** mitigarea **nu are impact funcțional**. Aceste sisteme nu folosesc IPsec ESP sau RxRPC.
– **Servere care găzduiesc tunele VPN IPsec cu ESP:** mitigarea **va opri tunelele**. Trebuie evaluată o alternativă (de exemplu, comutarea temporară pe WireGuard sau OpenVPN, dacă este posibil).
– **Servere care folosesc AFS sau RxRPC:** rar întâlnit în hosting; verificați înainte de aplicare.

Statusul patch-urilor (in 8 mai 2026)

– **Mainline** — patch-ul ESP a fost integrat în branch-ul netdev pe 7 mai și ulterior în mainline pe 8 mai. Patch-ul RxRPC încă nu este merged upstream.
– **AlmaLinux 8 / 9 / 10** — kernel-uri patch-uite disponibile în repo-ul *testing*. Pentru AlmaLinux 10, versiunea testing este `kernel-6.12.0-124.55.3.el10_1`. Vor fi promovate în production în zilele următoare.
– **CloudLinux** — KernelCare livepatch în pregătire. Va fi distribuit automat tuturor abonaților prin fluxul standard `kcarectl –update`.
– **RHEL** — Red Hat lucrează la backport-uri; urmăriți Red Hat Customer Portal pentru advisory-uri oficiale.
– **Ubuntu** — patch-uri în pregătire, status verificabil pe `ubuntu.com/security/notices`.
– **Rocky Linux** — va urma probabil ritmul AlmaLinux.

Ce facem la HostX

1. **Hipervizoare KVM și infrastructură de management** — am aplicat mitigarea preventivă (`modprobe.d` blacklist + `rmmod`) pe toate hipervizoarele KVM RHEL/AlmaLinux care rulează VM-urile clienților, încă din momentul publicării vulnerabilității.
2. **Monitorizare continuă** — urmărim repo-urile *testing* AlmaLinux și CloudLinux și vom promova kernel-urile patch-uite imediat ce sunt declarate stabile.
3. **VM-uri clienți cu KernelCare** — livepatch-ul va fi aplicat automat, fără reboot, în momentul în care CloudLinux îl publică. Niciun downtime.
4. **VM-uri clienți fără livepatch** — vom programa reboot-urile în ferestre de mentenanță anunțate cu cel puțin 48 de ore înainte. Pentru clienții cu cerințe stricte de disponibilitate, recomandăm activarea KernelCare ca soluție permanentă.
5. **Audit post-mitigare** — verificăm că niciun proces critic (în special VM-urile cu IPsec) nu a fost afectat de blocarea modulelor.

Recomandări pentru clienții self-managed

Dacă administrați propriul VPS sau server dedicat, fără ca echipa noastră să intervină:

1. **Aplicați mitigarea de mai sus imediat** dacă nu folosiți IPsec ESP (cazul majoritar pentru hosting și aplicații web).
2. **Limitați accesul SSH** la persoane de încredere și la IP-uri cunoscute — Dirty Frag necesită acces local, deci controlul accesului este crucial. Dezactivați autentificarea cu parolă, folosiți chei SSH.
3. **Verificați actualizările distribuției zilnic** în următoarele zile. Pentru distribuțiile EL (RHEL, AlmaLinux, Rocky):

dnf check-update kernel
dnf update kernel
reboot
```
4. **Monitorizați logurile** pentru activitate suspectă (mai ales `/var/log/audit/audit.log` și `dmesg`).
5. **Considerați KernelCare** dacă reboot-urile sunt costisitoare operațional — livepatch-ul aplică fix-ul fără oprirea serviciilor.

Lecții pentru ecosistemul Linux

Dirty Frag este al treilea bug major din clasa „page cache write” în doar câțiva ani: Dirty Pipe (2022), Copy Fail (aprilie 2026) și acum Dirty Frag (mai 2026). Fiecare exploatează același pattern fundamental — operațiuni in-place ale kernel-ului peste pagini al căror conținut nu îi aparține privat. Probabil vor mai apărea variante similare; expunerea va depinde de cât de rapid distribuțiile și administratorii reacționează.

Pentru un furnizor de hosting și servicii managed, concluzia este clară: **orice utilizator cu shell pe un server poate deveni root până la patch**. Reacția rapidă, mitigarea preventivă și planul de patch-uire ordonat sunt esențiale pentru protejarea clienților.

Resurse oficiale

– Disclosure complet și PoC: https://github.com/V4bel/dirtyfrag
– Advisory AlmaLinux: https://almalinux.org/blog/2026-05-07-dirty-frag/
– Advisory CloudLinux: https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update
– Mailing list `oss-security` (anunțul original Hyunwoo Kim)

–

**Pentru întrebări sau asistență legată de propria infrastructură, contactați-ne din zona Clienți. Echipa noastră este disponibilă 24/7 pentru incidente de securitate.**

Acces Clienti