CVE-2026-90129: virtio_balloon: quiesce balloon work before device shutdown
In the Linux kernel, the following vulnerability has been resolved:
virtioballoon: quiesce balloon work before device shutdown
Commit 8bd2fa086a04 ("virtio: break and reset virtio devices on deviceshutdown()") added a generic virtio bus .shutdown handler that breaks and resets every virtio device during deviceshutdown(), i.e. on reboot and kexec.
virtioballoon provides no .shutdown of its own, so that generic path runs while the balloon's asynchronous work is still armed. Once the device has been broken, virtqueueaddinbuf() in virtballoonfreepagereport() returns -EIO and trips its WARNONONCE(). On a kernel booted with paniconwarn that turns an ordinary reboot, for example a kexec based upgrade, into a fatal panic in the middle of deviceshutdown(), so the machine never reaches the new kernel.
Relaxing that single WARNONONCE() would only hide the symptom: the inflate/deflate and OOM paths do not warn, they call waitevent(vb->acked, ...) and would instead block forever on a broken queue that can no longer complete. The device has to be quiesced, not just kept quiet.
Add a .shutdown handler that quiesces the balloon via the shared virtballoonquiesce() helper while the device is still alive, and only then breaks and resets it via virtiodeviceshutdown(). Unlike virtballoonremove() the balloon workqueue is not destroyed, as shutdown does not free the device and cancelworksync() together with stopupdate already prevent any further work from being queued.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to the shutdown failure?
Systems using the Linux kernel virtio_balloon device are affected during device shutdown, including reboot and kexec paths. The issue occurs because asynchronous balloon work can remain armed while the generic virtio shutdown handler breaks and resets the device.
What is the observable impact during a reboot or kexec upgrade?
Page-reporting work can receive -EIO from virtqueue_add_inbuf() and trigger WARN_ON_ONCE(). If panic_on_warn is enabled, an otherwise ordinary reboot or kexec-based upgrade can instead end in a fatal panic before the new kernel is reached.
Could the problem present as a hang rather than a warning?
Yes. The inflate, deflate, and OOM paths can wait indefinitely for acknowledgements from a broken virtqueue, because that queue can no longer complete requests after the device has been reset.