# DF-4411 VERDICT — untested (source-verified hygiene defect; firmware-gated)

## Reproduced?

No. Status `untested`: requires matching ASUS/Samsung/EeePC firmware with
(at least) two ATK0100-class devices or a reprobe cycle — the audit guest
has zero such nodes (`env.txt`). No unprivileged trigger; impact is feature
loss / silent model misconfiguration, not memory corruption.

## Defect (certain from source)

Static driver-wide tables are mutated during probe/attach:

- `acpi_asus.c:682, 689, 697, 705` — the "looks like" quirk branches write
  `model->lcd_get`, `model->wled_set`, `model->mled_set` directly into the
  matched entry of `static struct acpi_asus_model acpi_asus_models[]`
  (`acpi_asus.c:146`) — and crucially they mutate the *borrowed* entry
  (L3C, M6R, xxN), not a copy.
- `acpi_asus.c:807-808` — attach writes `sc->model->n_func` (same class).

Because the entries are shared driver-wide and probe can run more than once
(multiple children, bus rescan), the second probe of an actually-matching
model observes the mutated entry: an L2B probe leaves `L3C.lcd_get == NULL`
forever, so a real L3C loses `dev.acpi.N.asus.lcd_backlight`
(`acpi_asus_sysctl_init`, `acpi_asus.c:1133-1166`, returns FALSE on NULL
lcd_get). An A3G probe leaves `M6R.lcd_get` pointing at a method that only
exists on A3G firmware. Concurrent probes on SMP additionally race on these
unsynchronized stores (word-sized pointer writes; not exploitable, but
technically a data race).

Also note the borrowed-entry mutation is per-boot-persistent: the driver
cannot be detached and re-attached to recover the original table.

## Impact ceiling

Info: silent feature loss/misconfiguration on multi-device or reprobe
scenarios; enables the DF-4409 removal-mismatch hazard class. No security
impact beyond that.

## Fix

`fix.diff` sketch: keep the tables `const`, copy the matched entry into a
softc-embedded `struct acpi_asus_model model_copy` in probe, and apply all
quirks (including the n_func default from attach) to the copy. Not validated
(no applicable hardware on the guest) → 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.