dmcdtc/openvz-cve-patch-2026GhostLock - Patch de rétroportage CVE-2026-43499 pour openVZ 7
Correctif de rétroportage CVE-2026-43499 pour le noyau openVZ 7 vzkernel-3.10.0-1160.129.1.ovz7.226.2
Comme l'équipe OpenVZ n'a pas (encore) déployé de correctif pour le noyau OpenVZ, j'ai créé celui-ci avec l'aide de Claude et il semble fonctionner ! (je l'ai testé sur deux serveurs en production, aucun problème jusqu'à présent)
USAGE:
git clone -b branch-rh7-3.10.0-1160.129.1.vz7.226.x-ovz --single-branch --depth 1 https://[email protected]/openvz/vzkernel.git
cd vzkernel
patch -p0 kernel/rtmutex.c < /patch/CVE-2026-43499-vzkernel3.10.patch (or just overwrite rtmutex.c from my attachments)
cp config.OpenVZ .config
make olddefconfig
make -j10 bzImage
make -j10 modules
make modules_install
cp arch/x86/boot/bzImage /boot/vmlinuz-3.10.0-1160.129.1.ovz7.226.2
dracut /boot/initramfs-3.10.0-1160.129.1.ovz7.226.2.img 3.10.0-1160.129.1.ovz7.226.2
grub2-mkconfig -o /boot/grub2/grub.cfg (or if EFI then EFI path)
C'est tout .. définissez le nouveau noyau par défaut et redémarrez sur ce noyau il est préférable de le faire sur un environnement de test pour vérifier que cela fonctionne
Si quelqu'un a une meilleure solution ou si j'ai commis une erreur critique, je serai ravi de l'entendre et de la corriger... je créerai peut-être un .rpm ou un dépôt .. je suis simplement paresseux pour le moment, j'attends encore de voir si l'équipe OpenVZ va faire quelque chose officiellement avant d'agir de mon côté...
J'ai maintenant ajouté un noyau binaire pour openvz avec le noyau officiel 119 corrigé .. vous avez le .spec et le patch dans la version binaire .. il est préférable de recompiler avec le src.rpm original d'openVZ pour être sûr, pour des raisons de sécurité
MISE À JOUR 24-Jul_26
Il existe désormais un correctif officiel que vous pouvez consulter ici
https://bitbucket.org/openvz/vzkernel/commits/branch/branch-rh7-3.10.0-1160.129.1.vz7.226.x-ovz mis à jour
Binaires : https://download.openvz.org/virtuozzo/factory/x86_64/os/Packages/v/