CVE-2026-90129: Linux Vulnerability

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.

Metrics

EPSS Probability

0.21%

10.7th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 8bd2fa086a04886798b505f28db4002525895203, < 6dd28e32f4d81a0d57c732b9900de24184e60a7d; >= 8bd2fa086a04886798b505f28db4002525895203, < bdef50a8226fc04899ef6815dd08a002247d47d5; >= 8bd2fa086a04886798b505f28db4002525895203, < 7e17eef04600c399c7e0f5ce765da5cf9d40d8e1; 0c03e32494dd0bbcc301523e5ae567c2f567a7d9; acdfe206be6c70ec55dc8bfdb1a22036d10fae26; 1eaa83fd94ed5e40d43139025f5acb7bcfed3b5f; aee42f3d57bfa37b2716df4584edeecf63b9df4c; >= 6.1.191, < 6.2; >= 6.6.160, < 6.7; >= 6.12.114, < 6.13; >= 6.14.9, < 6.15
Linux	Linux	6.15

References

Timeline

Published: Sep 17, 2026
Last Modified: Oct 30, 2026
Status: Received

Frequently Asked Questions

What is CVE-2026-90129?

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.

How severe is CVE-2026-90129?

Severity scoring for CVE-2026-90129 is pending analysis. The EPSS model estimates a 0.21% probability of exploitation in the next 30 days.

How do I fix CVE-2026-90129?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →