Birbla

Discussion summary

A recent CVE-2026-53359 vulnerability affects KVM/x86, raising security concerns in resource sharing. Discussions highlight trade-offs between cost, management, and security in server and container setups.

What the discussion says

  • Sharing resources reduces costs but increases security risks.
  • Running dedicated servers offers more security but at higher costs.
  • Managing larger scale deployments becomes more complex.
  • Some users prefer affordable hosting options like Hetzner.
  • Linux device files can be exploited due to permissions.
“Sharing resources reduces costs but increases security risks.”
— rballpug
“Managing larger scale deployments becomes more complex.”
— antonvs

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • KVM, or x86 identified mail validation.
    by rballpug
  • xenchads dabbing on kvmvirgins once again
    by anonym29
  • > 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?

    by codedokode
  • Very many "devices" aren't at all device-like.
    by colechristensen
  • Linux controls access using configurable file permissions, so this has a false premise. The better question is doesn't RHEL really use a kvm group to limit access like other distributions? If so, why?
    by fulafel
  • 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.

    by yjftsjthsd-h
  • ???

    That's been the case forever: /dev/null, /dev/zero, /dev/stdin, ...

    by cyberax
  • 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.
    by Intralexical
  • 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
    by tryauuum
  • Some of the comments here talk about the risk this poses for multi tenant vm providers.

    Wouldn't this also be a risk for people using VMs to sandbox untrusted code running on trusted hosts?

    by CoastalCoder
  • In that case you'd have to combine this vulnerability with a local privilege escalation to reach guest kernel mode.

    Also the vulnerability requires enabling nested virtualization on the VM.

    by bonzini
  • Anyone know if "-cpu ${CPU},vmx=off,svm=off" in QEMU is a safe workaround for this?

    (To disable nested virtualization on a per-VM basis. Only against exploitation from within that specific VM, obviously does nothing against users with access to /dev/kvm on the host.)

    by eqvinox
  • KVM maintainer here, yes it is.
    by bonzini
  • 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 one dedicated server

    So if your hourly is worth anywhere upwards of 5$/hr, and your project has any semblance of seriousness, just use a dedicated server, and avoid a whole class of LPE vulnerabilities just to save some $.

    Businesses have expenses, let's stop pretending that all of these non dedicated server infrastructures are serious. Shell out 200$/month or stick to hobby status.

    No, I don't sell dedicated servers, but I should

    by TZubiri
  • A dedicated server is a bunch of risk and skilled administration work compared to using a container platform or serverless. Many more people have been pwned by consequences of neglected server administration than managed serverless/container platform VM escapes.
    by fulafel
  • I'm a bit confused. So you're saying instead of running 20 containers for an app that are 1-4Gi and some odd CPU I should replace them with 20 dedicated servers?

    By your own numbers that's 200x+ as expensive.

    Really 20 containers is a pretty small app considering 5 app server containers, a DB, a cache, a load balancer, some monitoring/alerting crap 2x for redundancy.

    by nijave
  • In your context you still "share" with a dedicated server too. It's not your rack, it's not your IPMI/OOB, even on bare metal. Components in the server are running all sorts of their own code.

    All of these layers are a form of risk

    by marysol5
  • 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 you don’t have to. This is as serious as it gets in business. Managing your own hardware makes very little sense for many, if not most companies.

    by antonvs
  • I run 3 servers for 200 EUR, thanks to Hetzner, exactly for this reason (and I’m cheap and I never understood cloud/services like Vercel and Railway as serious alternatives ;-)).
    by Scotrix
  • "If you operate an x86 KVM host that accepts multi-tenant guests and supports nested virtualization, or use an instance on top of one"

    does this mean that you must have nested virtualization enabled to br vulnerable. does disabling this feature in the host os or bios, make you immune to this bug?

    by br0ceph
  • Yes you can disable it via kernel module parameters kvm_intel.nested=0 or kvm_amd.nested=0.
    by bonzini
  • Nested virtualization prompts the use of shadow paging (where the bug is), is my understanding, where non-nested cases use hardware accelerated translation instead.
    by kurisufag
  • Nested virt on x86 is curiously painful; you'd kind of think each layer would be isolated, so that the L0 (hardware) would only have to worry about it's VM (L1), and L1 would have to worry about it's VM (L2); but nope - the L0 top level hypervisor sees faults from the L2 and has to figure out that they are actually L2 not L0. IMHO the extra complexity (and historical flakiness of it) - makes me say that enabling nesting is a bad idea for public VM hosts.
    by trebligdivad
  • but that's the entire point of kvm. that leak is the feature! that's how you get the performance boost.
    by iririririr
  • The alternatives are the L0 emulates a hypervisor-privileged mode to the L1 which would be a performance cost (and does not really avoid the problem since the L0 would have to emulate vmenter/vmrun and therefore be aware of the L2 anyway, or the hardware would have to provide some nested virtualization facility which seems like it would be complicated and expensive for little benefit, though I could be mistaken.

    Does anything do a "real" nested virtualization in hardware? s390 might but I know ~nothing about it and it probably does not expose its bare metal hardware layers to Linux/KVM anyway.

    by stinkbeetle
  • The full write up is here: [0].

    This is a very nasty vulnerability and risks any service that uses and allows nested x86 virtualization features at risk. Including those running VMs as a service.

    > Running the PoC inside a guest VM can trigger a host kernel panic. A full escape exploit that works in a controlled environment also exists, but it is not released at this time and is planned to be released in the very distant future.

    The first commit that introduced this vulnerability was in 2010. [1] So it was undiscovered for 16 years until now [2].

    It was only a matter of time that a vulnerability in KVM would appear. This one is really not good as it is the first KVM guest-to-host exploit working on both AMD and Intel.

    [0] https://github.com/V4bel/Januscape/blob/main/assets/write-up...

    [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

    [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

    by rvz
  • > So it was undiscovered for 16 years until now

    Publicly undiscovered

    by TedDoesntTalk
  • KVM maintainer here.

    For what it's worth, this is a variant of a vulnerability discovered via fuzzing last April, CVE-2026-46113.

    by bonzini