Summary

apple_gmux_detach() calls AcpiRemoveNotifyHandler() expecting it to drain in-flight deferred notify dispatches before resources freed. DragonFlyBSD AcpiOsWaitEventsComplete() is compile-time no-op stub (acdragonfly.h:218-220 comment XXX TBI) so AcpiRemoveNotifyHandler (evxface.c:505-506) returns immediately after freeing ACPI_OPERAND_OBJECT handler via AcpiUtRemoveReference while previously-queued AcpiEvNotifyDispatch task (scheduled by AcpiOsExecute at evmisc.c:295 onto ACPI helper thread OsdSchedule.c:118-144) still holds raw captured pointer to freed object. When helper thread runs dispatch it dereferences HandlerObj->Notify.Handler (function pointer) and HandlerObj->Notify.Context from freed/reallocated memory then invoked gmux_notify_handler touches sc->io_res and sc->powerchange_done which detach already released. AcpiDisableGpe at :920 does not help GPE that already fired before line 920 already queued deferred dispatch and non-GPE ACPI Notify from unrelated AML not gated by AcpiDisableGpe. Attacker: root on MacBook with apple_gmux loaded (kldunload most reliable trigger system shutdown other path). Trigger: repeatedly writing OFF/ON to /dev/vga_switcheroo (root-only mode 0600) provokes POWER-status Notify callbacks then kldunload. Impact: near-certain kernel panic local DoS or if freed slab re-groomed with attacker bytes HandlerObj->Notify.Handler becomes controlled function pointer kernel arbitrary-call primitive. Systemic issue affects ALL DragonFlyBSD ACPI drivers not just apple_gmux.