Acces Clienti

Acces Clienti

pedit COW (CVE-2026-46331): escaladare de privilegii în kernelul Linux — mitigare și actualizare de kernel

26 iun. 2026 | Securitate cibernetica

CVE-2026-46331, poreclit pedit COW, este o vulnerabilitate de escaladare locală de privilegii (LPE) în kernelul Linux. Orice utilizator local neprivilegiat de pe un server afectat poate obține root printr-o singură comandă. Un proof-of-concept funcțional (packet_edit_meme) este deja public din 17 iunie 2026. Dacă administrezi servere CloudLinux 7h, 8, 9, 10 sau CloudLinux for Ubuntu 22.04, trebuie să acționezi acum: aplică una dintre mitigările de mai jos și programează actualizarea de kernel (sau folosește un livepatch KernelCare, fără reboot).

Despre ce este vorba

Pe 17 iunie 2026, cercetătorul Massimiliano Oldani a publicat un PoC funcțional pentru o vulnerabilitate de escaladare de privilegii în kernelul Linux, urmărită acum ca CVE-2026-46331 și poreclită pedit COW. Problema se află în subsistemul de traffic control (tc) al kernelului, mai exact în acțiunea act_pedit din net/sched.

Impactul este direct și sever: un cont neprivilegiat de shell — exact genul de acces pe care îl are un client pe un server de shared hosting — poate escalada la root fără interacțiune suplimentară. Pentru un provider de hosting care rulează mai mulți clienți pe același kernel, aceasta este o vulnerabilitate cu prioritate maximă.

Cum funcționează, pe scurt

Acțiunea act_pedit editează antetele pachetelor „pe loc”. Pentru asta calculează, o singură dată, înainte de editare, intervalul pentru mecanismul copy-on-write (COW) — adică pagina de memorie pe care intenționează să o modifice. Problema este că acest calcul omite offset-ul suplimentar pe care cheile tipate îl adaugă la momentul execuției. Rezultatul: kernelul ajunge să scrie într-o pagină pe care nu a făcut-o niciodată privată.

Acest „COW parțial” permite scrierea în memoria partajată din page cache care susține un fișier real de pe disc — o zonă pe care kernelul o considera protejată la modificare. Controlând offset-ul, un proces neprivilegiat transformă acest defect într-o scriere în copia din page cache a unui fișier pe care în mod normal l-ar putea doar citi.

Capacitatea CAP_NET_ADMIN, necesară pentru a configura acțiunea, nu presupune privilegii reale: se obține în interiorul unui user namespace + network namespace neprivilegiat, disponibil implicit utilizatorilor obișnuiți pe familia EL (RHEL/AlmaLinux/CloudLinux).

PoC-ul public țintește direct binarul setuid-root /bin/su: suprascrie punctul de intrare ELF din cache cu un shellcode echivalent cu setgid(0); setuid(0); execve("/bin/sh"), astfel încât următoarea invocare a su rulează ca root.

Atenție: NU este același bug ca Dirty Frag sau Fragnesia

Acesta este un punct important. pedit COW este un bug nou și diferit, aflat în altă parte a kernelului — acțiunea act_pedit din net/sched — și nu în calea XFRM/ESP din spatele vulnerabilităților Dirty Frag și Fragnesia.

Concret: blacklist-ul de module pe care l-ai aplicat pentru Dirty Frag / Fragnesia NU acoperă această vulnerabilitate. Mitigarea de mai jos vizează un modul diferit (act_pedit). Dacă ai presupus că serverele sunt deja protejate pentru că ai tratat vulnerabilitățile anterioare, presupunerea este greșită.

Versiuni CloudLinux afectate

VersiuneAfectatăSe remediază prin
CloudLinux 7 (CL7)Nu—
CloudLinux 7h (CL7h)Dakernel CloudLinux
CloudLinux 8 (CL8)Dakernel CloudLinux
CloudLinux 9 (CL9)Dakernel AlmaLinux
CloudLinux 10 (CL10)Dakernel AlmaLinux
CloudLinux for Ubuntu 22.04 LTSDaactualizare kernel Ubuntu + livepatch KernelCare

Un livepatch KernelCare, care aplică remedierea fără reboot, va fi disponibil ca alternativă pe toate versiunile afectate (vezi Stream 3 mai jos).

Aplică mitigarea acum

Până la instalarea unui kernel corectat sau a unui livepatch KernelCare, aplică una dintre cele două mitigări de mai jos. Fiecare dintre ele închide vectorul de atac — alege-o pe cea care se potrivește sarcinilor tale de lucru.

Opțiunea A — Blochează modulul act_pedit

Dacă nu folosești reguli tc de tip pedit (un server tipic de web hosting nu le folosește), împiedică încărcarea modulului și descarcă-l dacă este deja prezent:

bash
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf
lsmod | grep -w act_pedit && sudo rmmod act_pedit

Pentru a reveni după instalarea unui kernel corectat:

bash
sudo rm /etc/modprobe.d/disable-act_pedit.conf

Compatibilitate: cu această regulă activă, orice configurație de traffic control care folosește acțiunea pedit va eșua la încărcare. Nu o aplica pe servere care depind de reguli tc … action pedit.

Notă practică (verifică înainte să te bazezi pe Opțiunea A). Pe kernelurile din familia EL, mitigarea prin modprobe.d funcționează doar dacă act_pedit este compilat ca modul încărcabil, nu integrat static în kernel (built-in). Dacă modulul este built-in, trucul cu modprobe.d/rmmod nu are niciun efect — exact capcana întâlnită la mitigarea „Copy Fail”. Verifică pe kernelul tău concret înainte:

bash
modinfo act_pedit >/dev/null 2>&1 && echo "modul incarcabil (Optiunea A e valida)" || echo "posibil built-in — foloseste Optiunea B sau aplica direct kernelul corectat"

Dacă rezultatul indică built-in, treci la Opțiunea B sau aplică direct kernelul corectat.

Opțiunea B — Restricționează user namespace-urile neprivilegiate

Aceasta elimină calea de obținere a CAP_NET_ADMIN pe care se bazează exploit-ul, fără a atinge subsistemul tc.

Pe familia EL (CL7h, CL8, CL9, CL10):

bash
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

Pe CloudLinux for Ubuntu 22.04:

bash
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

Compatibilitate: user namespace-urile neprivilegiate sunt necesare pentru runtime-uri de containere rootless și pentru unele sandbox-uri CI. Restricționarea lor este acceptabilă pe servere hardened sau de hosting, dar perturbatoare pe servere de dezvoltare sau de containere. Nu aplica această opțiune acolo unde rulează astfel de sarcini de lucru.

Restaurează binarele din page cache după mitigare

Exploit-ul modifică un binar legitim de sistem (PoC-ul public suprascrie /bin/su) în page cache ca parte a obținerii root, deci aplicarea mitigării nu este suficientă pe sistemele care ar fi putut fi vizate înainte de aplicarea mitigării. După mitigare, golește page cache-ul pentru a forța reîncărcarea de pe disc:

bash
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

Aceasta este conținere, nu remediere. Golirea cache-ului elimină o copie compromisă, dar dacă un atacator a ajuns deja la root, evicțiunea nu înlătură persistența pe care a instalat-o ulterior. Dacă suspectezi că un server a fost compromis, tratează-l ca fiind compromis și reconstruiește-l.

Instrucțiuni de actualizare

Există trei fluxuri de release, plus o cale separată pentru CloudLinux for Ubuntu 22.04. Folosește-l pe cel care se aplică versiunii tale de CloudLinux.

Stream 1 — kernel CloudLinux (CL7h, CL8)

Kernelurile CloudLinux corectate pentru CL7h și CL8 sunt lansate pe canalul beta și se propagă către stable. Versiuni țintă:

  • CL7h: kernel-4.18.0-553.137.1.lve.el7h sau mai nou
  • CL8: kernel-4.18.0-553.137.1.lve.el8 sau mai nou

Ambele sunt reconstrucții CloudLinux ale corecției din upstream.

Actualizare CL8 de pe canalul beta (cloudlinux-updates-testing):

bash
yum --enablerepo=cloudlinux-updates-testing update 'kernel*'
reboot
uname -r

Actualizare CL7h de pe canalul beta (cl7h_beta):

bash
yum --enablerepo=cl7h_beta update 'kernel*'
reboot
uname -r

Actualizare de pe canalul stable. Odată ce kernelul ajunge pe stable pentru serverul tău, un update simplu aduce versiunea corectată:

bash
yum update 'kernel*'
reboot
uname -r

Stream 2 — kernel AlmaLinux (CL9, CL10)

Kernelurile AlmaLinux corectate pentru CL9 și CL10 sunt disponibile în depozitele de producție (stable). Versiuni țintă:

  • CL9 / AlmaLinux 9: kernel-5.14.0-687.17.1.el9_8 sau mai nou
  • CL10 / AlmaLinux 10: kernel-6.12.0-211.26.1.el10_2 sau mai nou

CloudLinux 9 și 10 folosesc direct kernelul AlmaLinux, iar corecția este deja în producție, deci un update simplu îl aduce:

bash
dnf update 'kernel*'
reboot
uname -r

Stream 3 — livepatch KernelCare (toate versiunile afectate)

Livepatch-urile KernelCare pentru CVE-2026-46331 sunt în build și testare activă. KernelCare le publică mai întâi pe feed-ul de testing și le promovează pe feed-ul principal după validare.

Din feed-ul de testing, odată disponibil:

bash
kcarectl --update --prefix test

Odată promovat pe feed-ul principal, sistemele cu abonament KernelCare primesc corecția automat prin fluxul standard de livepatch:

bash
kcarectl --update

CloudLinux for Ubuntu 22.04 LTS

CloudLinux for Ubuntu 22.04 rulează kernelul standard Ubuntu; nu există un kernel construit de CloudLinux pentru această platformă, iar corecția de producție vine de la Canonical prin apt. Urmărește statusul pe pagina Ubuntu CVE.

Cum verifici că ești corectat

După update + reboot:

bash
uname -r

Compară rezultatul cu versiunea țintă pentru fluxul tău CloudLinux de mai sus.

Pentru KernelCare:

bash
kcarectl --info | grep kpatch-build-time

Un timp de build ulterior datei de publicare a livepatch-ului include corecția pedit COW. Alternativ, după finalizarea metadatelor patch-ului:

bash
kcarectl --patch-info | grep CVE-2026-46331

Recomandarea noastră

Pentru o flotă de servere, coordonarea unui reboot de urgență pe zeci de mașini este partea dificilă, nu comanda de update în sine. Dacă rebooturile simultane sunt greu de programat fără fereastră de mentenanță, KernelCare aplică remedierea pe kernelul aflat în execuție, fără reboot — serverele abonate primesc livepatch-ul automat imediat ce este publicat.

Indiferent de calea aleasă, ordinea corectă de acțiune este:

  1. Aplică acum una dintre mitigări (Opțiunea A sau B), după ce verifici că se potrivește sarcinilor tale de lucru.
  2. Golește page cache-ul dacă serverul ar fi putut fi expus înainte de mitigare.
  3. Programează actualizarea de kernel (sau aplică livepatch-ul KernelCare) și verifică versiunea.
  4. Elimină mitigarea temporară abia după ce ai confirmat că rulezi un kernel corectat.

Referințe