CVE-2026-98841
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A timing problem in a Linux driver can cause virtual machines to crash when they are restored from snapshots.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in the vmgenid driver where notification handlers are registered before driver_data is assigned, allowing an early IRQ or ACPI notification to dereference a NULL pointer and trigger a kernel panic.
Why it matters to the business
Virtual machines may crash unpredictably during boot or snapshot restore operations, causing unplanned downtime and loss of availability in virtualized environments.
How an attack unfolds
A VMM such as Firecracker injects a generation-changed notification while restoring a guest from a snapshot taken before the driver probed; the pending or shared IRQ fires immediately after handler registration but before driver_data is set, causing vmgenid_notify to dereference NULL.
How to fix it
Update the Linux kernel to a version containing the fix that assigns driver_data before registering handlers; rebuild and reboot affected systems.
How to confirm the fix worked
Confirm the presence of the corrected probe ordering in the vmgenid source; test snapshot restore and IRQ injection scenarios to ensure no NULL dereference occurs.
Typical attack path
- VMM restores guest from pre-probe snapshot
- devicetree or ACPI probe path registers notification handler
- Pending or injected IRQ or asynchronous notification arrives
- Handler calls vmgenid_notify with still-NULL driver_data
- Kernel panics with NULL pointer dereference
How to detect it
Search kernel logs and crash dumps for the call trace containing vmgenid_notify.isra.0 and vmgenid_of_irq_handler during early boot or after snapshot restore.
What your security team should do
- Apply the upstream fix as soon as a stable kernel update is available
- Prioritize patching in environments that use snapshot/restore or Firecracker
- Monitor kernel crash logs for vmgenid_notify NULL dereference signatures
The record
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().
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|