CVE-2026-90129 in Linux
Summary
by MITRE • 09/17/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability identified in the virtio_balloon subsystem stems from a race condition during system shutdown procedures, specifically affecting devices managed via the virtio interface which is commonly used for virtualized environments. The root cause lies in the interaction between generic virtio bus handling and the specific lifecycle management of the balloon driver. When a system undergoes a reboot or kexec operation, the kernel invokes device_shutdown() to prepare hardware for state transfer or reset. A previous commit introduced a generic shutdown handler on the virtio bus that forcibly breaks and resets all virtio devices. However, the virtio_balloon driver did not implement its own specific .shutdown callback, leaving it reliant solely on this generic mechanism. Consequently, during the critical window of device_shutdown(), the balloon's asynchronous work items remain armed and active while the underlying virtual hardware is being abruptly disconnected.
This misalignment leads to a severe operational failure where the virtio_balloon driver attempts to interact with a now-broken virtqueue. Specifically, functions such as virtballoon_free_page_report() call virtqueue_add_inbuf(), which fails because the device has already been reset by the generic handler. This failure triggers an internal WARN_ON_ONCE assertion within the kernel code. While this warning might appear benign in standard configurations, it becomes catastrophic on kernels compiled with panic_on_warn enabled or when such warnings are escalated to panics for debugging purposes. In these scenarios, a routine reboot or kexec-based upgrade results in a fatal kernel panic before the new operating system can initialize, effectively bricking the transition process and preventing successful system updates or restarts.
The technical flaw is not merely about suppressing error messages but addressing the fundamental lack of quiescence for asynchronous tasks associated with the balloon device. Simply relaxing the WARN_ON_ONCE check would mask the symptom without resolving the underlying issue. The inflate, deflate, and Out-Of-Memory (OOM) handling paths within the driver rely on waiting for acknowledgments from the host via wait_event loops. If these threads continue to operate after the virtqueue is broken by the generic shutdown handler, they will block indefinitely because no further completions can occur on a disconnected queue. This leads to hung tasks and potential system hangs during shutdown sequences, compromising reliability in virtualized infrastructure where graceful transitions are critical for maintenance windows and live migration scenarios.
To resolve this vulnerability, the virtio_balloon driver was updated to include its own .shutdown handler that explicitly quiesces the balloon operations before the generic device reset occurs. This is achieved by invoking a shared helper function, virtballoon_quiesce(), which ensures that all asynchronous work items are properly stopped and synchronized while the virtual device is still operational and capable of processing requests. Only after this quiescence phase is complete does the driver allow the standard virtio_device_shutdown() routine to break and reset the hardware connection. This approach preserves the integrity of the shutdown sequence by ensuring that no pending operations attempt to communicate with a disconnected backend, thereby preventing both kernel panics caused by warnings and indefinite blocking in wait loops.
From a security and stability perspective, this fix aligns with best practices for resource management during state transitions, mitigating risks associated with improper synchronization primitives and race conditions in driver shutdown paths. The vulnerability can be categorized under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'), as the failure arises from concurrent access to shared resources (the virtqueue) without proper coordination between the generic bus handler and the specific device driver logic. Furthermore, it relates to CWE-829: Inclusion of Functionality from Untrusted Control Sphere if one considers the reliance on external state during shutdown, though primarily it is a synchronization error within trusted kernel code.
In terms of ATT&CK mapping, this issue does not represent an exploitable attack vector for unauthorized access or privilege escalation but rather a reliability flaw that could be leveraged in Denial of Service (DoS) scenarios if triggered intentionally to disrupt system availability during maintenance windows. It falls under the technique T1499: Endpoint Denial of Service, specifically related to resource exhaustion or state corruption leading to service unavailability. For administrators and developers, the mitigation is inherent in applying kernel updates that include this patch. Ensuring that systems are running patched versions of the Linux kernel prevents the race condition during reboot cycles. Additionally, organizations should verify their kernel configuration settings regarding panic_on_warn to understand how such internal warnings impact system stability, although relying on configuration changes alone does not fix the underlying synchronization defect in the driver code.