CVE-2026-90129

virtio_balloon: quiesce balloon work before device shutdown

N/A
Published: September 17, 2026 at 04:06 PM UTC
Updated: October 21, 2026 at 01:20 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: virtio_balloon: quiesce balloon work before device shutdown Commit 8bd2fa086a04 ("virtio: break and reset virtio devices on device_shutdown()") added a generic virtio bus .shutdown handler that breaks and resets every virtio device during device_shutdown(), i.e. on reboot and kexec. virtio_balloon 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, virtqueue_add_inbuf() in virtballoon_free_page_report() returns -EIO and trips its WARN_ON_ONCE(). On a kernel booted with panic_on_warn that turns an ordinary reboot, for example a kexec based upgrade, into a fatal panic in the middle of device_shutdown(), so the machine never reaches the new kernel. Relaxing that single WARN_ON_ONCE() would only hide the symptom: the inflate/deflate and OOM paths do not warn, they call wait_event(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 virtballoon_quiesce() helper while the device is still alive, and only then breaks and resets it via virtio_device_shutdown(). Unlike virtballoon_remove() the balloon workqueue is not destroyed, as shutdown does not free the device and cancel_work_sync() together with stop_update already prevent any further work from being queued.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

1eaa83fd94ed5e40d43139025f5acb7bcfed3b5f6.12.1146.14.96.156.6.1608bd2fa086a04886798b505f28db4002525895203acdfe206be6c70ec55dc8bfdb1a22036d10fae26aee42f3d57bfa37b2716df4584edeecf63b9df4c
Vendor states this is fixed in 6dd28e32f4d81a0d57c732b9900de24184e60a7d (fixed)
Vendor states this is fixed in 7e17eef04600c399c7e0f5ce765da5cf9d40d8e1 (fixed)
Vendor states this is fixed in bdef50a8226fc04899ef6815dd08a002247d47d5 (fixed)
Vendor states this is fixed in 6.15 (unaffected)
Vendor states this is fixed in 6.18.52 (unaffected)
Vendor states this is fixed in 7.2.6 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card