New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
If you haven't rebooted enough, there is GhostLock (CVE-2026-43499, https://www.openwall.com/lists/oss-security/2026/07/08/12). Proxmox doesn't mention it in their security announcements forum yet, so I guess it's still vulnerable in 7.0.14-4.
lol… we need something like kernelcare specifically for CVE patches that’s open source and not a monthly subscription cost, and supports all distros not just some..
Well, there is /dev/mem, so any reboot is just the operator/admin lacking skills
Not an issue for Debian stable (6.12), so probably not an issue for Proxmox.
No, Proxmox uses a Kernel independent from Debian, only the Userspace is Debian-based.
The PVE Kernel is Ubuntu based, with their own patches (see their git repo).
I assumed it would still be based on an LTS.
IIRC, Proxmox bases their kernel on the latest stable Ubuntu kernel (not LTS), at least for the non-enterprise repo.
Ubuntu 26.04 fixed GhostLock, which isn't mentioned in the PVE Security Announcements, but Ubuntu is vulnerable to Bad-Epoll which PVE has already fixed.
EDIT: added links
Unfortunately if you patch Anuscape the whole system will lose its function,
Anuscape is unpatchabale.
You just said all that matters on this subject, no need to say more.
huh?
Who pays for the QA?
Haven't thought that far yet.
https://stats.neoon.net/#sort=desc:4
So many providers didn't reboot.
Please don't tell me they do live migration.
Which would mean, LET is premium now? Or is this data rigged?
I can confirm that Skhron patched fully as of 11:00 UTC today, mitigation was applied for all new guests in Sweden since this vuln was announced, and Poland had nested virt disabled since forever.
Kernelcare costs 2$ in bulk, not so premium.
BTW. Im really baffled that OVH is rebooting all hypervisors (they taliking about 100k psychical machines) instead of deploying some kind of live patch system
Hi,
according to
https://forum.proxmox.com/threads/cve-2026-43499-ghostlock.184937/
was already patched before...
Some might do live migration.
Honestly, not bad. How quick are they to actual provide patches though to critical CVEs? Faster than someone posting on X about a major exploit and some roundabout way to protect yourself from it in the meantime?
$2/mo is nothing when most of us are already paying $18/mo~ or so for individual hypervisor licensing (VirtFusion) and running larger, dense hypervisors.
If kernelcare doesn't have some insane invasive privacy concerns and they're actually quick to provide patches to critical stuff I'll go ahead and deploy it across the fleet. Never thought much of it before but nowadays it'll pay for itself the first time something like this happens and I don't have to spend a day or two patching stuff and being in a minor state of panic when some things don't come back up as expected (Woops, had a few hypervisors that didn't want to come back as easily as others causing extended downtimes).
Wait, am I correct in understanding KernelCare hasn't even patched for this yet?
Most of our stuff is Debian 12 or Debian 13, but selecting some Alma options too:
https://patches.kernelcare.com/?type=kernel&distro=debian13,debian12,almalinux10,almalinux8,almalinux9,almalinux9.6-esu&cve
Doesn't look like they have patched for it yet. So, whats the point then, I guess?
They did for AlmaLinux 9 for sure.
Ah, the search/sort function isn't all that great. Searching for "2026-53359" or "CVE-2026-53359" doesn't bring up anything but if you hover over specific releases without specifying it specifically, you may see it mentioned. Good to know.
https://patches.kernelcare.com/?cve=CVE-2026-53359&distro= this one works for me
Ah, perfect.
Will look into it more and may implement fleet-wide this coming week. Cost is very reasonable for the overall peace of mind and for automating a relatively tedious (repetitive) task.
I remember considering it some years ago just as an added-value feature in our earlier days but that was of course before the bi-weekly "Ah fuck, gotta go apply some updates right now." type of critical CVEs were dropping.
Still, full hypervisor reboot to update the system cleanly with a live migration is the best option, but needs some spare capacity available, which I lack.
same here, yet even so, moving 320TB would take too long and doing that for a lot of nodes is not sustainable/efficient. it would take too much time.
also. not all nodes have the same cpu freq, so most of the vps will end up in kernel crash.
cleanest way is to just reboot the node, easy and it is what it is.
Last I checked, they didn’t have it ready for rocky9 and debian12 unfortunately. However they were quick with deb 13 and el10.
That won't cause a kernel panic. If there's a panic when migrating, it will be due to something else (e.g. using host CPU passthrough while AVX512 is being used then being suddenly migrated to a system with only AVX2).