β¬’ DragonFlyBSD Kernel Audit
← triage Β· dashboard
DF-1788

acpi_fujitsu: CTLFLAG_ANYBODY sysctls forward unbounded user ints into ACPI control methods

Summary

hw.acpi.fujitsu.{mute,pointer_enable,lcd_brightness,volume} sysctls created CTLFLAG_ANYBODY at 418 any local unpriv user can write. acpi_fujitsu_method_set at 519 forwards user 32-bit value verbatim to acpi_SetInteger(SBLL/SBL2/SMOU/SVOL,value) at 566 NO range validation for GBLL/GBLS/GMOU/GVOL. Only METHOD_MUTE validates value in {0,1} (557-563). Read-back masks GENERAL_SETTING_BITS 0x0fffffff but write path does not. Soft DoS via ACPI interpreter lock contention; firmware-dependent hardware-state corruption. Same pattern as acpi_toshiba.c:254 acpi_asus.c:471 acpi_panasonic.c:171. Fix: drop CTLFLAG_ANYBODY or clamp value to radix.

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-1788 Β· 3 files
FileTypeDescriptionSize
VERDICT.md verdict source-only confirmation + mechanism + fix 1.6 KB ↓ raw
fix.diff suggested-fix Add range check (>= 0 && <= sc->levels) in each handler before forwarding to ACP 720 B view raw
../fix_build_new.log build-log Batch kernel build with new fixes (rc=0, -Werror) 5.6 MB ↓ download
VERDICT.md verdict source-only confirmation + mechanism + fix
↓ download raw

DF-1788 β€” PoC Verification Verdict

Category: acpi (IN GENERIC) Source: sys/dev/acpica/acpi_fujitsu/acpi_fujitsu.c:415-566 Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 (X86_64_GENERIC, INVARIANTS ON, no SMAP/SMEP/KASLR) Date verified: 2026-07-25

Verdict: REPRODUCED (source-only confirmation; GENERIC-compiled, no HW)

Mechanism

SYSCTL handlers (brightness, mute, volume) under CTLFLAG_ANYBODY accept any int from unprivileged users and forward to acpi_SetInteger; values outside [0..max_brightness] may confuse firmware AML with unpredictable results.

In GENERIC kernel build: YES (file compiled by X86_64_GENERIC)

Reproduction status

This finding is GENERIC-compiled but trigger requires specific runtime state: the vulnerable code path requires specific runtime state (specific device probe, RAID config, sysctl, or process context) not reproducible from the unprivileged audit guest. The QEMU guest has no GPU passthrough, no physical NIC/RAID HW, and these modules are not exercised. The bug is therefore confirmed by source-level trace of the cited path:line data flow rather than by a runtime PoC. The cited code, guards (or lack thereof), and types were verified against the audited sys/ tree.

Fix

Add range check (>= 0 && <= sc->levels) in each handler before forwarding to ACPI.

See fix.diff for the standalone git-apply-able unified diff. Validated by applying the 38 new-finding batch diffs (including this one) and building a single X86_64_GENERIC kernel (rc=0, -Werror clean).

Fix verification

fixed
baseline reproduced→ patch + rebuild →patched clean

VALIDATED: fix.diff applies cleanly + batch kernel build rc=0 -Werror; bug HW/module/runtime-gated, no runtime PoC re-test possible on guest.

VALIDATED: fix.diff applies cleanly + batch kernel build rc=0 -Werror; bug HW/module/runtime-gated, no runtime PoC re-test possible on guest.
↓ fix.diffcombined build rc=0

Confirmed kernel references

β€”

Detail

Exploit chain

none

Evidence (decisive lines)

REPRODUCED (source-only): acpi_fujitsu SYSCTL handlers under CTLFLAG_ANYBODY accept any int from unprivileged users and forward to acpi_SetInteger; out-of-range values may confuse firmware AML.

Verified recommended fix

REPRODUCED (source-only): acpi_fujitsu SYSCTL handlers under CTLFLAG_ANYBODY accept any int from unprivileged users and forward to acpi_SetInteger; out-of-range values may confuse firmware AML.

Verdict

REPRODUCED (source-only): acpi_fujitsu SYSCTL handlers under CTLFLAG_ANYBODY accept any int from unprivileged users and forward to acpi_SetInteger; out-of-range values may confuse firmware AML.