Re: [PATCH] virt: vmgenid: set driver_data before registering notification handlers

[Jason A. Donenfeld]

On Tue, Aug 25, 2026 at 09:50:54PM +0800, Zhichen Wang wrote:
> 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().
> 
> Fixes: 7b1bcd6b50a6 ("virt: vmgenid: add support for devicetree bindings")
> Fixes: e07606713a90 ("virt: vmgenid: change implementation to use a platform driver")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Zhichen Wang <wangzhichen@xxxxxxxx>
> ---
> Verified on Firecracker v1.14 (aarch64, devicetree) with a snapshot
> taken before the vmgenid driver had probed, so the injected
> notification IRQ is pending when the restored guest reaches probe:
> the unpatched kernel panics with the trace above, while the patched
> kernel handles the pending IRQ as soon as devm_request_irq()
> registers the handler (/proc/interrupts shows the vmgenid IRQ count
> at 1) and boot completes normally. The ACPI path change is
> compile-tested; the window there is analogous but much harder to hit.
 

This patch went to gmail spam! I only saw it by accident just now.

Thanks for this. I'll try to test and verify this on Monday. Do you have
a handy repro script you were using that you can share? Also, wondering
if you saw this happen in the wild.

Jason