CVE-2026-98841 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
virt: vmgenid: set driver_data before registering notification handlers
Both probe paths register their notification handler before assigning driver_data, which the handler dereferences.
In the devicetree path, the notification IRQ can fire as soon as devm_request_irq() registers the handler: the interrupt may already be pending at probe time, for example when a VMM injects the generation-changed notification while restoring a guest from a snapshot that was taken before the driver had probed (Firecracker does exactly this on snapshot restore). The IRQ is also requested with IRQF_SHARED, so another device sharing the line can trigger the handler just as early. The handler then calls vmgenid_notify(), which dereferences the still-NULL driver_data and panics:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.38+ #1 PREEMPT(none) Hardware name: linux,dummy-virt (DT) pc : vmgenid_notify.isra.0+0x24/0x8c lr : vmgenid_of_irq_handler+0x14/0x34 Call trace: vmgenid_notify.isra.0+0x24/0x8c (P) vmgenid_of_irq_handler+0x14/0x34 __handle_irq_event_percpu+0x44/0x1bc handle_irq_event+0x4c/0xb4 handle_fasteoi_irq+0xf8/0x1f8
The ACPI path has the same ordering problem: the handler is installed with acpi_install_notify_handler() before driver_data is assigned. ACPI notifications are dispatched asynchronously from a workqueue, so the window is narrow, but a notification arriving between the two calls hits the same NULL dereference.
Assign driver_data before registering the handlers. The state is fully initialized at that point, so the handlers are safe to run. Should registration fail, the probe error path leaves no dangling pointer behind: the driver core clears driver_data in device_unbind_cleanup().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel vulnerability identified involves a race condition within the virtio vmgenid driver, specifically concerning the initialization sequence during device probing for both Device Tree and ACPI paths. The core technical flaw lies in the order of operations where notification handlers are registered with the system before the driver-specific data structure is assigned to the device's private data field. This ordering error creates a critical window of vulnerability where an interrupt or asynchronous notification can be received by the kernel before the necessary context required for safe handling has been established. In the Device Tree implementation, the interrupt request line is requested using devm_request_irq with the IRQF_SHARED flag, which allows other devices sharing that hardware interrupt line to trigger the handler immediately upon registration. Furthermore, virtual machine monitors such as Firecracker may inject a generation-changed notification during guest restoration from snapshots taken prior to driver initialization, resulting in an immediate pending interrupt at probe time. Similarly, the ACPI path utilizes acpi_install_notify_handler which dispatches notifications asynchronously via a workqueue, creating a narrow but exploitable timing gap where a notification arriving between handler installation and data assignment will trigger the same failure mode.
The operational impact of this flaw is severe, manifesting as a kernel panic due to an invalid memory access. When the vmgenid_notify function executes in response to either an IRQ or ACPI event, it attempts to dereference driver_data which remains NULL at that moment. This results in a null pointer dereference exception, typically occurring at offset 0x10 within the notify routine as indicated by kernel crash traces showing calls from vmgenid_of_irq_handler and acpi_install_notify_handler contexts. The system becomes unstable or unresponsive until rebooted, affecting availability for virtualized workloads relying on this driver for generation ID updates. This vulnerability aligns with CWE-362 which describes concurrent execution issues leading to race conditions, as well as CWE-476 concerning NULL pointer dereferences that occur when software fails to properly initialize pointers before use. From a threat modeling perspective using the MITRE ATT&CK framework, this represents an availability impact where an attacker or misconfigured hypervisor could potentially cause denial of service through crafted snapshot states or interrupt injection strategies without requiring privilege escalation beyond what is already present in the virtualization layer.
The resolution involves reordering the initialization sequence so that driver_data is assigned to the device structure before any notification handlers are registered with the kernel subsystems. This ensures that when vmgenid_notify is invoked, whether synchronously via IRQ or asynchronously via ACPI workqueues, it has access to valid memory references and can operate safely without risking a crash. The fix also accounts for error handling paths; if handler registration fails after driver_data assignment, the device unbind cleanup routine properly clears any dangling pointers preventing use-after-free scenarios in subsequent probe attempts. This approach maintains system integrity by guaranteeing that all required state is fully initialized before external events can interact with the driver logic. Mitigation strategies include applying this kernel patch to affected versions and ensuring virtualization platforms do not inject generation notifications until after guest drivers have completed their initialization phases, although the code fix remains the primary defense against this specific race condition in modern Linux kernels supporting virtio devices.