Názory k článku
Zapscape: únik z KVM a eskalace práv

Podobně jako u měsíc starého Januscape CVE-2026-53359 tomu mohla zabránit vypnutá nested virtualizace a na úrovni hypervizoru (host) pak také utažená příst. práva k /dev/kvm.

Takže pokud nested nepoužíváte, určitě bych ji vypnul. Default na distribucích je různý (RHEL a SLES to má vypnuté, Ubuntu třeba zapnuté na AMD..).
Do /etc/modprobe.d udělat pro sichr nějaký konfig s:
options kvm_intel nested=0
options kvm_amd nested=0

Stran těch práv na /dev/kvm je to ve výchozím stavu trochu kompromis pro ty virtuály, co se spouští pod běžným uživatelem (např. libvirt přes qemu:///session přes GNOME Boxes, virt manager) atp.
Ale na serverech to typicky jede přes systémový libvirtd a přistup mají pouze správci ve skupině libvrt, takže by neměl být problém to utáhnout na 0660 (přerazit nějakým přidaným udev pravidlem na konec parsování).

U toho vypnutí nested virtualizace pozor. Syntaxe se mezi Intelem a AMD liší.

Správně to je:
options kvm_intel nested=N
options kvm_amd nested=0

Viz https://pve.proxmox.com/wiki/Nested_Virtualization#Enable_Nested_Hardware-assisted_Virtualization

Je sice pravda, že Intel má nested parametr jako boolean a AMD jako integer..
$ modinfo kvm_intel | grep nest
parm: nested:bool
$ modinfo kvm_amd | grep nest
parm: nested:int

Ale když se boolean tomu pošle nula nebo jedna, tak se to korektně interpretuje jako false nebo true, podobně jako pak n,N resp. y,Y.
Tzn. u Intelu můžete být v klidu i s různými způsoby zápisu. U AMD pak musíte napsat jen číslo 0 nebo 1, tam logicky žádný převod ekvivalentního zápisu není.

Takže to, co jsem napsal předtím s vypnutí přes číslo 0, by mělo fungovat.