RHSB-2026-014 și ZDI-CAN fără CVE; kernel-uri CloudLinux de producție pentru ZDI-CAN-33367, mitigare namespace și KernelCare — separat de CVE-2026-98432.
Pe 24 octombrie 2026, Red Hat a publicat RHSB-2026-014 despre un grup de probleme de kernel divulgate prin Zero Day Initiative. La publicare, analiza pentru produsele Red Hat era preliminară: patch-uri upstream incomplete din perspectiva atribuirii și fără CVE pentru aceste ID-uri ZDI.
Nu confunda acest subiect cu CVE-2026-98432 / RHSB-2026-016: identificatori, vectori și remedieri diferite. Un kernel sau un livepatch pentru una dintre probleme nu dovedește remedierea celeilalte.
Informații din buletinul Red Hat (istoric / RHEL)
Identificatorii ZDI-CAN-… nu sunt coduri CVE până la atribuire.
Neafectate pe versiunile RHEL suportate (modulele vizate nu sunt construite sau funcțiile nu sunt activate), conform RHSB-2026-014:
- ZDI-CAN-33774
- ZDI-CAN-33549
Potențial afectate (investigație; Important în buletin):
- ZDI-CAN-33367
- ZDI-CAN-34068
- ZDI-CAN-34076
RHSB-ul Red Hat nu stabilește singur starea pe Ubuntu, Debian, AlmaLinux sau CloudLinux. Reîncarcă buletinul înainte de concluzii.
Situația CloudLinux pentru ZDI-CAN-33367
Verificare pe CloudLinux Status și materialele TuxCare/CloudLinux legate de incident: 1 noiembrie 2026. Nu există CVE atribuit pentru ZDI-CAN-33367 la data verificării.
Conform incidentului CloudLinux: defect în stiva de rețea a kernelului; un utilizator local poate ajunge la privilegii ridicate; există exploit public. Expunerea crește când utilizatorii obișnuiți pot crea namespace-uri. CloudLinux 7 nu este afectat; CloudLinux 7 hybrid este expus în configurația livrată. Pe CL8/8 ELS/9/9 ELS, instalările mai noi (din jurul mijlocului lui 2024) pot avea namespace-urile neprivilegiate închise implicit; instalările mai vechi pot fi expuse. CL10 și CloudLinux for Ubuntu 22.04: închise implicit în descrierea incidentului. Remedierea pentru Dirty Frag (CVE-2026-43284) nu protejează împotriva ZDI-CAN-33367.
Versiunile de kernel anunțate pentru CVE-2026-98432 (de exemplu fluxul 553.180 / 687.61.2 / 211.69.2) nu sunt dovezi de remediere pentru ZDI-CAN-33367. Folosește doar tablele și identificatorii din incidentul ZDI.
Kernel-uri remediate în producție (CloudLinux)
Conform actualizărilor recente ale incidentului ZDI-CAN-33367 pe status page (inclusiv 29 și 31 octombrie 2026), kernel-urile de mai jos sunt reperele publicate pentru producție (sau mai noi pe același flux):
| Versiune | Kernel remediat (producție) | Canal / instalare | Verificare fix în kernel |
|---|---|---|---|
| CloudLinux 7h | 4.18.0-553.177.1.lve.1.el7h | Producție; update obișnuit de kernel + reboot (repository-ul cloudlinux-rollout-2-bypass nu mai e necesar după promovare) | Changelog: CLKRN-2389 |
| CloudLinux 8 | 4.18.0-553.177.1.lve.1.el8 | Producție; yum/dnf update 'kernel*' + reboot | Changelog: CLKRN-2389 |
| CloudLinux 9 | 5.14.0-687.60.1.el9_8 | Producție prin actualizările de kernel AlmaLinux; dnf update + reboot | Compară uname -r cu reperul (sau mai nou) |
| CloudLinux 10 | 6.12.0-211.69.1.el10_2 | Producție prin AlmaLinux; dnf update + reboot | Compară uname -r cu reperul (sau mai nou) |
După instalare, kernelul remediat este activ doar după reboot (sau după un livepatch KernelCare confirmat). Vezi și kernel instalat versus kernel pornit.
# verificare după reboot (CL7h / CL8):
rpm -q --changelog kernel-core-$(uname -r) | grep CLKRN-2389
uname -rMitigare CloudLinux (până la patch)
sudo sysctl -w user.max_user_namespaces=0
# pentru persistență, adaugă în /etc/sysctl.d/ conform procedurii tale
sysctl user.max_user_namespacesValoarea 0 închide calea pe namespace-uri neprivilegiate și poate opri containerele rootless pentru conturi obișnuite. Nu necesită reboot.
KernelCare: aplicare versus verificare
La data verificării, status page anunța livepatch pe feed-urile EL10 / CloudLinux 10 și EL9 / CloudLinux 9 (inclusiv ePortal pentru EL9 din 28 octombrie). Pentru EL8: pregătit pentru lansare / încă nerelansat public — confirmă pe status page înainte de concluzii.
Aplicarea actualizărilor KernelCare (comandă care modifică starea):
kcarectl --updateVerificarea stării (nu aplică patch-ul). Identificatorii din metadatele livepatch-ului pot fi ID-uri de tip K20261023_… (de exemplu K20261023_0016 pentru AlmaLinux 9 / CloudLinux 9), nu neapărat textul 33367. Lipsa unui rezultat la grep 33367 nu dovedește singură că remedierea lipsește:
kcarectl --patch-info
kcarectl --patch-info | grep -E 'K20261023_001[5-9]|33367|CLKRN-2389'
# Folosește --patch-info, nu doar --infoCompară ieșirea cu ID-urile publicate pe status page pentru linia ta (EL8/EL9/EL10), nu doar cu șirul ZDI.
Inventar pe server (cu limite clare)
uname -r
cat /etc/os-release
sysctl user.max_user_namespaces
lsmod | sort
find /lib/modules/$(uname -r) -type f -name '*.ko*' | wc -llsmod listează doar modulele încărcate acum. Absența unui nume din listă nu dovedește că sistemul nu e afectat: funcționalitatea poate fi compilată în kernel (built-in) sau modulul poate fi încărcat ulterior. Folosește modinfo, configurația kernelului și advisory-ul care numește concret componenta, când acesta există.
Când un aviz ulterior menționează un modul anume, verifică-l pe baza acelui document — nu inventa liste.
Activarea unui kernel nou pe disc: verificări înainte și după restart. Pe Ubuntu, politica de update automat: unattended-upgrades.
Pe un VPS XSERVERE cu acces root, notează data controlului, uname -r și URL-ul buletinului citit. Starea pe fiecare server trebuie confirmată local; nu deduce remedierea dintr-un alt CVE sau dintr-un alt tip de serviciu.
Data verificării surselor: 1 noiembrie 2026.
Ți-a fost util acest articol?