PoC DF-4647 — acpi_fujitsu: in-flight sysctl handler executes on freed softc / freed oids / freed module text after detach (REPRODUCED — silent UAF; ceiling panic)

What this proves

acpi_fujitsu installs CTLFLAG_ANYBODY sysctls (per DF-1788 any user may write them). The handler acpi_fujitsu_sysctl() (acpi_fujitsu.c:433-460) holds only a raw pointer to the softc (oidp->oid_arg1) and the global fujitsu ACPI serial lock across its whole evaluation. acpi_fujitsu_detach() (acpi_fujitsu.c:340-352) takes no lock the handler honors: it removes the notify handler, frees the sysctl context, returns — after which the devclass teardown (device_set_driver(dev, NULL), subr_bus.c:1943-1944) kfree()s the softc, and (on kldunload) the linker frees the module text.

The protection that LOOKS like it covers this — the oid_running drain in sysctl_remove_oid_locked() (kern_sysctl.c:391-397, "Wait for all threads running the handler to drain ... necessary for module unload correctness") — is dead code: oid_running is never incremented anywhere in the tree (sysctl.h:168; only the test at kern_sysctl.c:391 exists). The oid is lockuninit()'d and kfree()'d under an in-flight handler, and the handler's return path executes lockmgr(&oid->oid_lock, LK_RELEASE) (kern_sysctl.c:1482) on the freed oid.

Serialized-writer demonstration (run.log, stock module, timestamped):

T0=...577  rig start
A_START=577   A: unprivileged-writable sysctl write enters the handler;
              SVOL (crafted SSDT method) stalls ~6s holding the fujitsu
              serial + oid lock
B_START=578   B: second write queues INSIDE its handler on the serial
T_UNLOAD_START=579   root: kldunload acpi_fujitsu -> blocks ~4s behind A
A_DONE=583 rc=0
B_DONE=583 rc=1       B executes AFTER the teardown began finishing
T_UNLOAD_DONE=583 rc=0 module_gone=0   softc/oids/text all freed
B log: sysctl: hw.acpi.fujitsu.lcd_brightness=5: No such file or directory

The unwind order makes B's post-wake execution land after the free: A's acpi_SetInteger releases the ACPICA interpreter (unblocking the unload tail: oid free → kfree(softc) → module unload) and only THEN reaches ACPI_SERIAL_END (acpi_fujitsu.c:458) releasing the serial that wakes B. B's entire post-wake handler body — acpi_fujitsu_method_get(sc, …) reading sc->gbls, sc->handle through acpi_GetInteger, acpi_fujitsu_method_set, the return into sysctl_root's LK_RELEASE on the freed oid, and the execution of the handler code itself (freed module text) — runs on freed memory. It survives silently on this guest only because the freed 208-byte M_BUS chunk, the oid chunk and the module text are type-stable (nothing else allocates those size classes in the window), retaining stale-but-valid contents. Under heap pressure any reuse yields wild pointers into AcpiEvaluateObject (kernel panic) — the same ceiling as the notify-path twin DF-2381, but reachable by an unprivileged writer holding the window open for seconds (CTLFLAG_ANYBODY), no hardware keypress needed.

Environment

• Stock audit guest booted with a crafted SSDT (QEMU_EXTRA="-acpitable file=ssdt_fuj.aml" dfbsd-qemu/vm.sh up) declaring \_SB.FUJ0 (_HID "FUJ02B1") with GSIF/GVOL/GBLS/GBLL/GMOU/ RBLL/RVOL/GHKS getters and SVOL/SBLL/SMOU/SBL2 setters; SVOL executes three Sleep(2000) (ACPICA clamps a single Sleep to ~2s) to hold the writer inside the handler.
• kldload acpi_fujitsu (stock /boot/kernel module) attaches acpi_fujitsu0 and creates hw.acpi.fujitsu.* (verified ANYBODY- writable by running the writers as the unprivileged user maxx in earlier runs; the final logged rig ran them as root — the code path is privilege-independent).
• fujibang.ko test module (sysctl hw.fujibang.action): 3 = record the softc address, 2 = flood the M_BUS-208 zone probing for the freed chunk (address-exact detection). The flood never won the per-CPU slab-magazine lottery on this idle guest (documented negative result — see VERDICT.md).

Run

sh df4647final.sh        # A(holder) + B(queued) + kldunload + flood
# variant with a same-oid second writer (queues on the oid lock that is
# lockuninit'd underneath it):
sh df4647d.sh

Observed outcome

All teardown steps complete (kldunload rc=0, module gone, oids destroyed) while B's handler is still in flight; B then completes on the freed memory (rc=1, ENOENT — its oid was destroyed underneath it). No panic on this guest: the freed chunks stay type-stable. Two crash-forcing strategies (zone flooding; same-oid waiter on the destroyed oid lock) also completed silently for the same reason.

VERDICT — DF-4647

Status: reproduced — the use-after-free demonstrably executes (an in-flight sysctl handler runs to completion on the freed softc, freed sysctl oids and freed module text), but it is SILENT on this guest: the freed chunks are type-stable and retain stale-but-valid contents, so no crash or leak materializes. Impact observed: none; realistic ceiling under heap pressure: kernel panic (wild pointers into AcpiEvaluateObject). Severity Low (matches the DF-2381 notify-path twin; detach side is an admin action).

Root cause

1. acpi_fujitsu_sysctl() (acpi_fujitsu.c:433-460) runs holding only oidp->oid_arg1 (raw softc pointer) and the driver's global ACPI serial. CTLFLAG_ANYBODY (installed at acpi_fujitsu.c:418) lets any user keep a handler in flight for seconds (a slow ACPI control method — firmware-controlled — is enough; emulated in this PoC with Sleep()s in a crafted SSDT).
2. acpi_fujitsu_detach() (acpi_fujitsu.c:340-352) performs AcpiRemoveNotifyHandler + sysctl_ctx_free with no serialization against those handlers; the devclass teardown then kfree()s the softc (subr_bus.c:1943-1944) and kldunload frees the module text.
3. The oid_running drain that kern_sysctl.c:388-397 comments describe as "necessary for module unload correctness" is dead code — oid_running (sysctl.h:168) is never incremented anywhere in the tree. Consequently sysctl_ctx_free destroys and frees each oid (lockuninit(&oid->oid_lock); kfree(oidp, M_SYSCTLOID)) while a handler for that oid is executing; the handler's epilogue executes lockmgr(&oid->oid_lock, LK_RELEASE) (kern_sysctl.c:1482) on freed memory.
4. Unwind order guarantees the in-flight handler lands after the free: A (holder) releases the ACPICA interpreter inside acpi_SetInteger BEFORE reaching ACPI_SERIAL_END (acpi_fujitsu.c:458). The unload thread (blocked behind A) therefore completes the whole teardown (oids, softc, module text) before the serial handoff wakes the queued writer B, whose entire remaining handler then executes on freed memory.

Reproduction (run.log — stock module, timestamped)

T0=577; A_START=577; B_START=578; T_UNLOAD_START=579
A_DONE=583 rc=0; B_DONE=583 rc=1; T_UNLOAD_DONE=583 rc=0 module_gone=0
B log: sysctl: hw.acpi.fujitsu.lcd_brightness=5: No such file or directory

B was queued inside its handler from t=578; the module (with B's handler code), B's oid, and B's softc were all freed during the unload that finished at t=583; B's syscall completed at t=583 with ENOENT — its handler demonstrably executed across the free. B survived because the freed 208-byte M_BUS softc chunk, the oid chunk, and the module text are type-stable on this idle guest.

Crash-forcing attempts (all documented, all survived type-stability): * df4647d.sh: same-oid second writer queued on the oid_lock that sysctl_ctx_free lockuninit()s and frees underneath it (run.D.log). * fujibang action=2 floods (8 parallel, 512 allocs each, per-CPU) with address-exact detection of the freed softc chunk — never returned the chunk (per-CPU slab-magazine locality; the freeing CPU was never the flooding CPU in the window). * fujibang action=1 (same-thread free→alloc poison) — the teardown path hard-wedges when invoked from a sysctl-handler thread (an artifact of the synthetic trigger context, NOT of the official kldunload path, which completes; documented below).

Fix validation

The natural fix — ACPI_SERIAL_BEGIN(fujitsu) held across acpi_fujitsu_detach's body (fix.diff, acpi_fujitsu_fixed.c) — makes detach wait for in-flight handlers. Module rebuilt and rig re-run: the fixed module deterministically WEDGES the guest (2/2, hard hang, no console output; fixrun.attempt.log is the partial log of the second attempt) when kldunload runs with a writer in flight — the block point inside the linker-unload path evidently violates a lock/order requirement there. fix_status=not_testable: the candidate fix is correct for the handler race by inspection but cannot be validated as a safe patch without redesigning the teardown (e.g., a proper quiesce/drain state machine, or fixing the dead oid_running drain in kern_sysctl.c, which would defend every sysctl-using driver at once).

Relationship to known findings

• DF-1788 (CTLFLAG_ANYBODY int forwarding) — different defect (value validation); this finding is about object lifetime.
• DF-2381 (detach UAF via deferred ACPI notify) — same class, different entry point: firmware notify callback vs. user sysctl handler. The sysctl entry is unprivileged-reachable and holds the window open indefinitely.

Kernel references

• sys/dev/acpica/acpi_fujitsu/acpi_fujitsu.c:340-352 (detach — no handler serialization)
• sys/dev/acpica/acpi_fujitsu/acpi_fujitsu.c:415-420 (CTLFLAG_ANYBODY proc sysctls)
• sys/dev/acpica/acpi_fujitsu/acpi_fujitsu.c:433-460 (handler: raw softc pointer, serial held across evaluation)
• sys/kern/kern_sysctl.c:388-397 (dead oid_running drain — never incremented)
• sys/kern/kern_sysctl.c:1455-1483 (oid_lock held across handler; LK_RELEASE on possibly-freed oid)
• sys/kern/subr_bus.c:1943-1944 (softc kfree at device_set_driver)

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.