Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

github.com

Post reply on HN
Print view View original

21–30 of 67 posts

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#21

Post by TZubiri »

antonvs wrote: post #9
TZubiri wrote: post #7

hey, here's a good rule of thumb. If you share resources, that reduces costs, but increases security risks. choose whether to share a filesystem, an OS, a kernel, hardware, or just use a dedicated server. The economics of sharing resources are all in a tiny sliver of the budget spectrum, the shoestring budget range : 0-1$/mo: serverless 1$-5$/mo containers 5$-200$/mo Virtual Machine(s) 200$-1Billion$/month , at least…

If you can run everything you need on two or three servers, what you describe can work. But it’s still hobby status, basically. The equation changes when the scale gets significantly bigger. Managing a non-trivial hardware fleet requires people, and people cost money. The reason “managed services” of all kinds, including cloud services, are so widespread in business is because someone else is managing things so that…

There seems to be some confusion, although one other user interpreted the same thing, I still believe it's a misinterpretation.

I said dedicated servers, I never said anything about owning or managing the hardware. You can rent a dedicated server.

The decision to virtualize and the decision to own the hardware are separate decisions.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#22

Post by codedokode »

tryauuum wrote: post #13
codedokode wrote: post #12

> LPE: On distributions such as RHEL, /dev/kvm is world-writable (0666), so an unprivileged user can also use this vulnerability as a reliable LPE to gain root. Why on Linux device files are accessible by untrusted applications?

Not all device files, only /dev/kvm. I assume the logic was "with /dev/kvm access the user can ...allocate memory and execute code, which they already can, so why not allow it?". Could also make rootless isolation easier

Different kernel modules might have different vulnerabilities.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#23

Post by Intralexical »

codedokode wrote: post #12

> LPE: On distributions such as RHEL, /dev/kvm is world-writable (0666), so an unprivileged user can also use this vulnerability as a reliable LPE to gain root. Why on Linux device files are accessible by untrusted applications?

Because if /dev/kvm isn't accessible to unprivileged users, then people will start using `sudo` to run anything involving virtualization, which would be much worse for security overall.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#24

Post by yjftsjthsd-h »

codedokode wrote: post #12

> LPE: On distributions such as RHEL, /dev/kvm is world-writable (0666), so an unprivileged user can also use this vulnerability as a reliable LPE to gain root. Why on Linux device files are accessible by untrusted applications?

1: As siblings note, some device files are wide open, some are limited to a given user group, and some are root-only.

2: Because it's desirable for users to be able to run VMs.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#25

Post by calvinmorrison »

cyberax wrote: post #18
codedokode wrote: post #16

Earlier quoted context omitted.

One server is enough for many small businesses. And for large business (like X or Instagram) it is economically more profitable to own their servers. For example, in my country top companies like VK or Yandex own their datacenters and sell cloud services instead of paying for someone's else cloud. Also if you have several servers you do not need to hire a full-time sysadmin. > Managing a non-trivial hardware fleet re…

Suppose that you are a midsize company or a b2b service, so you want to make sure that your service has minimum downtime. This means that you need sysadmins in close proximity to your hardware to do hardware swapping/troubleshooting. Or you need to engineer your system to not have a SPOF (which is not easy). So you're looking at employing at least 2 engineers near your datacenter.

Really? We basically never go onsight. Ticket in with the colo and they can help.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#26

Post by CoastalCoder »

Intralexical wrote: post #23
codedokode wrote: post #12

> LPE: On distributions such as RHEL, /dev/kvm is world-writable (0666), so an unprivileged user can also use this vulnerability as a reliable LPE to gain root. Why on Linux device files are accessible by untrusted applications?

Because if /dev/kvm isn't accessible to unprivileged users, then people will start using `sudo` to run anything involving virtualization, which would be much worse for security overall.

I'm just starting to read up on capabilities-based security in Linux.

Would they potentially be a solution to sudo's all-or-nothing granularity in this domain?

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#28

Post by cyberax »

calvinmorrison wrote: post #25
cyberax wrote: post #18

Earlier quoted context omitted.

Suppose that you are a midsize company or a b2b service, so you want to make sure that your service has minimum downtime. This means that you need sysadmins in close proximity to your hardware to do hardware swapping/troubleshooting. Or you need to engineer your system to not have a SPOF (which is not easy). So you're looking at employing at least 2 engineers near your datacenter.

Really? We basically never go onsight. Ticket in with the colo and they can help.

That really works well while you have a rack or so. Afterwards, you really need people who know all the details of networking and storage. Especially if you're designing something without a SPOF.

What's changing is the scope of things that you can run on that one rack. 15 years ago, I was running clusters of 30 computers to do things that I now can do with 1.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#29

Post by msm_ »

CoastalCoder wrote: post #26
Intralexical wrote: post #23

Earlier quoted context omitted.

Because if /dev/kvm isn't accessible to unprivileged users, then people will start using `sudo` to run anything involving virtualization, which would be much worse for security overall.

I'm just starting to read up on capabilities-based security in Linux. Would they potentially be a solution to sudo's all-or-nothing granularity in this domain?

Linux capabilities have many problems (they are too coarse-grained and too many capabilities are root-equivalent). But anyway this is an overkill in this case probably. In may distributions access to /dev/kvm is guarded by membership in the kvm group - no need for new capability, just regular old filesystem permissions.

Re: Januscape: Guest-to-Host Escape in KVM/x86 [CVE-2026-53359]

#30

Post by Intralexical »

msm_ wrote: post #29
CoastalCoder wrote: post #26

Earlier quoted context omitted.

I'm just starting to read up on capabilities-based security in Linux. Would they potentially be a solution to sudo's all-or-nothing granularity in this domain?

Linux capabilities have many problems (they are too coarse-grained and too many capabilities are root-equivalent). But anyway this is an overkill in this case probably. In may distributions access to /dev/kvm is guarded by membership in the kvm group - no need for new capability, just regular old filesystem permissions.

Would capabilities enable granting access to specific programs and not just users? Like using AppArmor profiles. So QEMU, gVisor, Docker etc. can still use KVM for unprivileged users, but malware wouldn't be able to access it directly.
Post reply on HN