DF-5091 — acpi_button: no device_detach → ACPI notify/fixed-event handlers (context = softc) are never removed

What the finding is (source-level, certain)

sys/dev/acpica/acpi_button.c registers two kinds of ACPICA callbacks whose context is the per-device softc and never removes either:

• AcpiInstallFixedEventHandler(event, acpi_button_fixed_handler, sc) (acpi_button.c:150-151, fixed PNP0C0C/ACPI_FPB & PNP0C0E/ACPI_FSB path)
• AcpiInstallNotifyHandler(handle, ACPI_DEVICE_NOTIFY, acpi_button_notify_handler, sc) (acpi_button.c:158-159, AML path)

The methods table (acpi_button.c:74-83) has no device_detach entry — probe/attach/suspend/shutdown/resume only. Both handlers defer work via AcpiOsExecute(OSL_NOTIFY_HANDLER, ..., sc) (acpi_button.c:255, 258), and attach also enables a wake GPE that is never disabled (acpi_button.c:169-170). This is the DF-5006 (acpi_cpu) / DF-5074 (acpi_acad) family, mirrored.

Consequences: 1. If a detach path is ever added (bus re-enumeration, driver split into its own module, force-unload), the still-registered ACPICA handler fires into freed softc memory → UAF. The AcpiOsExecute indirection widens the race window past AcpiRemoveNotifyHandler's own quiesce. 2. Today it is structurally non-UAF: acpi_button.c is compiled into acpi.ko (sys/dev/acpica/Makefile:66) or into the base kernel (device acpi in X86_64_GENERIC), and the acpi bus driver's own detach is bus_generic_detach (sys/dev/acpica/acpi.c:182) — detaching acpi0 walks the children, hits the missing child detach method, gets ENXIO, and the unload aborts before any softc is freed. Resource pinning + permanently blocked kldunload acpi.

Reproduce

Nothing to build. Run on the host repo root:

findings/poc/DF-5091/run.sh     # pushes trigger.sh to the guest, runs it as root

Expected (matches run.log): - kldstat -v | grep button → acpi/acpi_button driver registered - dmesg | grep acpi_button → empty (no acpi_button device on this guest; QEMU's buttons are fixed events handled by acpi.c:1974-1993, whose "acpi0: Power Button (fixed)" line is the only button-ish dmesg output) - kldunload acpi → can't find file acpi: No such file or directory (ACPI is built into the kernel; there is no module to unload) - guest stays up (uptime at the end)

Verdict

not_reproduced / impact none: the UAF half of the gap has no reachable trigger on this system (no acpi_button device instance, no unload path at all); the pinning/blocked-teardown half is confirmed by the run. The structural gap itself is certain from source. Severity: Low (matches the DF-5006/DF-5074 family precedent).

fix.diff adds the missing acpi_button_detach (git-apply --check clean; NOT applied — sys/ is a read-only audit target). Not build-validated: fix validation is only mandatory for reproduced memory corruption.

VERDICT — DF-5091 (acpi_button no-detach teardown gap)

status: not_reproduced | reproduced: false | impact: none | confidence: certain (structural gap) guest: DragonFly dfbsd 6.5-DEVELOPMENT #0 ... x86_64 (X86_64_GENERIC), up, clean

What was claimed

acpi_button_attach() installs ACPICA callbacks with context = sc (AcpiInstallFixedEventHandler at sys/dev/acpica/acpi_button.c:150-151, AcpiInstallNotifyHandler at :158-159) and the driver has no device_detach (methods table at :74-83) — so the handlers, the AcpiOsExecute deferrals they queue (:255, :258) and the wake GPE enabled at :169-170 are never torn down. DF-5006 (acpi_cpu) / DF-5074 (acpi_acad) family mirror.

What was run (see run.log, trigger.sh)

1. uname -a — DragonFly 6.5-DEVELOPMENT, X86_64_GENERIC.
2. kldstat — kernel + ehci.ko + xhci.ko only; no acpi.ko module (ACPI compiled in via device acpi, X86_64_GENERIC:59).
3. kldstat -v | grep button — acpi/acpi_button driver registered in the builtin kernel.
4. dmesg | grep acpi_button — empty: no acpi_button device attached on this guest. The single button-ish dmesg line, acpi0: Power Button (fixed), comes from acpi.c:1974-1993 (acpi_enable_fixed_events), where acpi.c installs its own fixed-event handlers (context = acpi_softc) because QEMU's FADT declares the fixed buttons.
5. kldunload acpi → can't find file acpi (rc=1); kldunload -a → illegal option. No unload path exists on this system.
6. Guest alive (uptime), no panic, no dirt.

Why not_reproduced (and why that is the honest classification)

The finding has two halves:

• Structural gap (confirmed, certain): source shows no detach, no handler removal, no GPE undo. Runtime confirms the pinning consequence: the driver cannot be removed from the running system.
• UAF (not reachable today): freeing the softc requires a successful device_detach of an acpi_button device. On this guest there is no such device; in a module build, unloading acpi.ko routes through bus_generic_detach (sys/dev/acpica/acpi.c:182) → child DETACH method missing → ENXIO → unload aborts before any softc is freed. Hence "structurally non-UAF today" — exactly the DF-5074 conclusion, now also demonstrated live (blocked/absent unload on the running guest).

Exploit chain: none possible on this configuration. An attacker gains nothing: no user-triggerable detach path exists (DragonFly has no devd/devctl "detach" operation, no kldunload -f), and unprivileged users cannot kldunload at all (priv required).

Exploitability ceiling (if a detach path is ever added)

Power/sleep button notify → acpi_button_notify_handler → AcpiOsExecute(..., sc) fires after detach frees the softc → UAF with attacker-influenced timing (press button while unload in flight). That is the reason the fix belongs in-tree now, cheaply.

Fix

fix.diff (generated against the read-only sys/ tree; git apply --check clean; NOT applied): adds acpi_button_detach() mirroring attach — removes the fixed-event handler or the notify handler. Residual hardening note in the diff: AcpiRemoveNotifyHandler does not drain AcpiOsExecute work already queued; a generation counter in the softc would close that.

Fix validation (patched-kernel rebuild) not performed: mandatory only when a memory-corruption finding reproduces; here nothing reproduces (baseline clean, no fault to A/B). fix_status: not_testable.

Attempts

1 decisive run (run.log); guest reused from the earlier i915/acpi inspection, no reset needed (no state was modified — all probes read-only, kldunload attempts failed benignly).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.