| Urgent: GhostLock (CVE-2026-43499) on OpenVZ 7 Where is the patch for WebPros / SolusVM users? [message #53891] |
Fri, 10 July 2026 11:21  |
viadck
Messages: 3
Registered: January 2018
|
Junior Member |
|
|
Hello everyone,
The current situation regarding the GhostLock root exploit (CVE-2026-43499) has reached a critical bottleneck for hosting providers running production workloads on OpenVZ 7.
According to official ecosystem roadmaps, OpenVZ 7 is supposed to remain supported. Yet, we are currently facing a severe, host-breaking local privilege escalation vulnerability with no clear path to mitigation or patching for open-source OpenVZ users.
The Corporate & Licensing Trap
Let's look at the reality of the WebPros ecosystem:
1. Virtuozzo maintains OpenVZ.
2. WebPros owns Virtuozzo, as well as SolusVM, which is actively licensed as management software for KVM and OpenVZ VPS nodes.
3. Due to internal corporate partnerships, third-party tools like KernelCare do not support OpenVZ 7, pointing users directly to Virtuozzo's native ReadyKernel instead.
This has created an absolute trap. My production host nodes are fully up to date on disk, running the latest stable release: 3.10.0-1160.119.1.vz7.224.4. However, running readykernel info yields Loaded patches: 0. Why? Because WebPros/Virtuozzo gatekeeps the live patch repository behind licensing channels that SolusVM/OpenVZ customers are not even given an option to purchase or order in their portals.
SolusVM support is currently deflecting tickets by stating that OpenVZ 7 security coverage is uncertain and that it's a "vendor issue." WebPros is the vendor for both sides of this equation. You cannot license orchestration software for a virtualization tier, block third-party security vendors, and then completely abandon the community when a major exploit hits.
If anyone from Virtuozzo or WebPros engineering is monitoring this forum, we need an official kernel update pushed to the public repositories immediately, or the ReadyKernel patch channels opened up for this critical CVE.
Leaving paying ecosystem customers stranded with an active root exploit because of broken licensing workflows is unacceptable.
Kind regards!
|
|
|
|
| Re: Urgent: GhostLock (CVE-2026-43499) on OpenVZ 7 Where is the patch for WebPros / SolusVM users? [message #53892 is a reply to message #53891] |
Sun, 12 July 2026 00:44  |
dmc_dtc
Messages: 17
Registered: May 2014
Location: Serbia
|
Junior Member |
|
|
I am not related nor associated with OpenVZ team, just a long time user here.
I knew this would happen sooner or later - some big vulnerability and no patch form OpenVZ (yet)... Last time we got lucky because kernel 3.10 was not affected by copyfail and some other vulnerabilities.
So i did some research when copyfail striked, and found out their OpenVZ repo on bitbucket where they are still actually commit patches before release (latest is in april 2026)
you can download latest branch (as of this writing) from https://bitbucket.org/openvz/vzkernel/src/branch-rh7-3.10.0- 1160.129.1.vz7.226.x-ovz/
Use
git clone -b branch-rh7-3.10.0-1160.129.1.vz7.226.x-ovz --single-branch --depth 1 https://YOURUSERNAME@bitbucket.org/openvz/vzkernel.git
Then you have latest unreleased OpenVZ kernel
So latest official release is 1160.119 - But in this repo it is 129 version - there are already patches missing from official release but nevertheless there is no patch for GhostLock (yet)
So - i made one with help of Claude  and apparently i was successful but still haven't tested it in production to see if every software that uses mutex works - but proof of concept from nebula no longer works and all tests show that all mutex related things works, so i think this should work.. of course, consider this no warranty and not 100% tested patch but it seems to work - use on your own responsibility - here is instruction how to compile your own kernel with GhockLock patched on OpenVZ 7 (Should work on vanilla CentOS 7 too)
git clone -b branch-rh7-3.10.0-1160.129.1.vz7.226.x-ovz --single-branch --depth 1 https://USERNAME@bitbucket.org/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)
Thats it .. make new kernel default and reboot into kernel
best to do it on test env to see if it works
If anyone have better solution or if ive made some critical mistake i will be glad to hear and correct... perhaps i will make .rpm or some repo .. i am just lazy ATM, still waiting to see if OpenVZ team is going to do something officially before i do something on my own.... If they dont patch this then this project is really dead and migrate ASAP, but i have a feeling we will see patch soon.
Have fun!
>> dmc / dtc <<
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
