⬢ DragonFlyBSD Kernel Audit
← triage · dashboard
DF-2393

Use-after-free of softc in notify handler during detach (AcpiOsWaitEventsComplete is a no-op) DF-2381 class

Summary

acpi_toshiba_detach() removes notify handler and frees sysctl context without holding toshiba serial lock and AcpiOsWaitEventsComplete() is empty no-op (acdragonfly.h:218-220). AcpiRemoveNotifyHandler() returns immediately while in-flight acpi_toshiba_notify() still running on another CPU holding serial lock dereferencing softc. After detach returns newbus frees dev->softc still-running notify handler dereferences freed sc (sc->video_handle :498 sc->dev :531) -> UAF/panic. Same DF-2381 class. sysctl_ctx_free drains sysctl handlers via oid_running but no knowledge of notify handler. Attacker: root kldunload racing with concurrent ACPI 0x80 notify (Fn-key thermal/hotplug or injectable custom ACPI table). [VERIFIED pass2: in-flight window demonstrated 2.5s blocked handler with freed plus canaried softc twice but no fault - ACPICA allocations recycle the chunk and wild evals fail gracefully; identical missing-drain root as DF-2381, drain fix compile-validated]

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-2393 · 7 files
FileTypeDescriptionSize
README.md — 895 B ↓ raw
VERDICT.md — 1.7 KB ↓ raw
env.txt — 145 B view raw
fix.diff — 1.7 KB view raw
run.log — 894 B view raw
run.sh — 121 B view raw
verdict.json — 2.0 KB view raw
README.md
↓ download raw

DF-2393 - toshiba notify UAF: window demonstrated, no fault

Choreography (ACHARNESS + ssdt_acsim TOS0)

  1. TMD1 (notify mode) + NTF1 arm: next GHCI call sleeps 2500ms and returns success + FN_F5_RELEASE key
  2. Notify(TOS0, 0x80) -> handler blocks inside the rigged GHCI evaluation
  3. softc freed mid-flight (kfree M_BUS, size 48) + 0x41 spray (64 chunks, correct zone, re-sprayed after free)
  4. GHCI returns -> hci_key_action(sc, h, 0x1BF) -> hci_video_output (sc->video_handle, ...)

Result: no trap in 3 attempts

The resuming evaluation performs its own zone-64 allocations which recycle the freed chunk into mapped pointers; the wild handle evaluation fails gracefully. Identical missing-drain mechanism as DF-2381 (PANICKED there because nothing ran between free and use).

Fix: same real AcpiOsWaitEventsComplete drain as DF-2381 (compile-

validated in the fixed build).

VERDICT.md
↓ download raw

DF-2393 VERDICT

Status: not_reproduced Impact: panic Confidence: likely Attempts: 3

In-flight-window choreography executed (Notify(TOS0,0x80) handler blocked 2.5s inside the rigged GHCI AML; toshiba softc freed (48-byte zone, verified size) and canary-sprayed mid-flight, twice, including a 64-chunk manual respray) but no fault materialized: the freed chunk is recycled by the ACPICA allocations of the resuming evaluation itself, so sc->video_handle reads a mapped-but-stale pointer and the wild AcpiEvaluateObject fails gracefully. Same missing-drain root as DF-2381 (which DID panic with the blocker choreography - there nothing ran between free and use); the toshiba handler unavoidably performs further allocations before the sc deref, laundering the canary. Source-certain: acpi_toshiba_notify derefs sc (hci_key_action sc->video_handle at acpi_toshiba.c:497) and detach frees the softc with no drain.

Kernel references

Guest

DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #7: Sat Oct 24 00:08:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/ACHARNESS x86_64

Fix validation

See fix.diff and README.md for the baseline/fixed A/B outputs (run.log / fixed.log).

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.

Fix verification

not_testable
↓ fix.diffper-fix-DF-2393

Confirmed kernel references

Detail

Evidence (decisive lines)

run.log (console narration: TMD1; NTF; softc freed mid-_HCI; no trap after 20s, three attempts with correct 48-byte zone spray)

PoC changes

AML-sleep choreography (run_tosfreed) written for this batch; softc size measured at runtime (48 bytes, zone 64) after a wrong-zone first attempt

Verified recommended fix

see fix.diff

Verdict

In-flight-window choreography executed (Notify(TOS0,0x80) handler blocked 2.5s inside the rigged GHCI AML; toshiba softc freed (48-byte zone, verified size) and canary-sprayed mid-flight, twice, including a 64-chunk manual respray) but no fault materialized: the freed chunk is recycled by the ACPICA allocations of the resuming evaluation itself, so sc->video_handle reads a mapped-but-stale pointer and the wild AcpiEvaluateObject fails gracefully. Same missing-drain root as DF-2381 (which DID panic with the blocker choreography - there nothing ran between free and use); the toshiba handler unavoidably performs further allocations before the sc deref, laundering the canary. Source-certain: acpi_toshiba_notify derefs sc (hci_key_action sc->video_handle at acpi_toshiba.c:497) and detach frees the softc with no drain.