DF-4410 — acpi_asus LED state changes run in an undrained async task: detach/led_destroy frees the softc under a pending acpi_asus_led_task (use-after-free)

• File: sys/dev/acpica/acpi_asus/acpi_asus.c (+ sys/dev/misc/led/led.c interplay)
• Class: CWE-416 (use after free) / CWE-362 (race window)
• Severity: Low — the write side is root-only (/dev/led/* are created 0600 root:wheel, led.c:305-306), and the free side requires root (device detach / module unload). No unprivileged path.

Defect (path:line)

LED write path (root writes /dev/led/bled etc., or led_create_state at attach calls sc->func(...) directly, led.c:312):

acpi_asus_led()            acpi_asus.c:922-935
        if (led->busy)             /* racy check, no lock */
                return;
        led->busy = 1;
        led->state = state;
        AcpiOsExecute(OSL_NOTIFY_HANDLER, acpi_asus_led_task, led);  /* async */

The task (acpi_asus.c:877-920) later dereferences led->sc, sc->model->bled_set, sc->handle and calls acpi_SetInteger, then led->busy = 0.

Nothing drains that pending task at detach:

acpi_asus_detach()   acpi_asus.c:832-874
        led_destroy(sc->s_bled.cdev);   /* frees the ledsc immediately;
                                           led.c:318-341 has no OSL-queue
                                           flush and does not know about the
                                           acpi_asus_led_task */
        ...
        sysctl_ctx_free(&sc->sysctl_ctx); /* softc itself freed by newbus
                                             right after detach returns */

The tree's ACPICA OSL has no AcpiOsWaitEvents()-style drain (sys/dev/acpica/Osd/OsdSchedule.c only implements AcpiOsExecute), so a task queued microseconds before led_destroy runs after both the ledsc and the acpi_asus_softc are freed → led->sc / sc->model->bled_set / acpi_SetInteger(sc->handle, ...) all operate on freed memory → UAF read + AML engine call with attacker-uncontrolled-but-recycled pointers.

Secondary: led->busy check/set (acpi_asus.c:928-931) is unlocked, so two concurrent LED writes can both queue a task (benign duplication, but shows the glue has no serialization at all); and the default: arm of acpi_asus_led_task (acpi_asus.c:912-915) returns without clearing led->busy, permanently wedging that LED.

Build / run

Not runnable on the audit guest: no /dev/led consumers exist (no ASUS nodes — env.txt), and both sides of the race are root-only. On matching hardware: echo 1 > /dev/led/bled & kldunload acpi_asus in a loop → panic in acpi_asus_led_task on freed softc.

Recommended fix

Track outstanding LED tasks in the softc and drain them in detach before led_destroy (dying flag + counter + wait), see fix.diff.

DF-4410 VERDICT — untested (source-verified UAF window; root-gated, firmware-gated)

Reproduced?

No. Status untested: needs an attached acpi_asus (guest has zero ATK0100/ASUS010 nodes — env.txt) plus root on both sides of the race (/dev/led/* is 0600 root:wheel per led.c:305-306; softc freeing requires detach/kldunload). No unprivileged trigger.

Defect (certain from source)

• acpi_asus_led (acpi_asus.c:922-935) defers every LED state change into AcpiOsExecute(OSL_NOTIFY_HANDLER, acpi_asus_led_task, led) — an asynchronous OSL work-queue — after a lock-free check/set of led->busy.
• acpi_asus_led_task (acpi_asus.c:877-920) later dereferences led->sc (i.e. the enclosing acpi_asus_softc), reads sc->model->bled_set/…->gled_set/… and executes acpi_SetInteger(sc->handle, method, state).
• acpi_asus_detach (acpi_asus.c:832-874) calls led_destroy() for each LED (acpi_asus.c:841-857). led_destroy (led.c:318-341) immediately unlinks and kfrees the ledsc; it has no knowledge of the queued acpi_asus_led_task. The softc itself is freed by newbus when detach returns. The tree's OSL provides no drain primitive (sys/dev/acpica/Osd/OsdSchedule.c — only AcpiOsExecute), and detach never synchronizes with the OSL queue at all.
• Result: any LED write (root) landing within the OSL-queue latency before detach produces a task that runs on freed memory: UAF reads (led->type, led->sc, sc->model->…) and a call into the AML interpreter with recycled pointer values (sc->handle). Window is the notify-handler queue depth — real, but small and root-gated.
• Same glue also: (a) default: arm of the task returns without led->busy = 0 (acpi_asus.c:912-915) — permanent wedge of that LED; (b) the busy flag itself is racy (acpi_asus.c:928-931), so duplicate tasks can be queued.

Impact ceiling

Root-gated kernel panic / corruption of freed slab memory. Not an escalation primitive (the freed slot is not attacker-shaped, and reaching the race already requires root).

Fix

fix.diff: per-softc led_lock + led_dying flag + outstanding-task counter; acpi_asus_led only queues while alive; the task drops the count and wakes detach; detach waits for quiescence before destroying the LED devices. Not validated on hardware (fix_status: not_testable).

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.