DF-4485 — vo_get_brightness_levels() leaks the _BCL ACPI evaluation buffer on every successful call

Impact

Low. Kernel memory leak in M_ACPICA (unbounded in the number of firmware-initiated REPROBE notifies): each successful _BCL evaluation during attach/rebind leaks the ACPI_BUFFER returned by AcpiEvaluateObject. The leak size per event is controlled by the ACPI table (package size), so a crafted table leaks arbitrarily large chunks per notify → kernel memory exhaustion.

Where (sys/dev/acpica/acpi_video/acpi_video.c)

• :992-1003 — success path: *levelp = levels; return (n); — returns WITHOUT freeing bcl_buf.Pointer (the ACPI_OBJECT package). Only the failure paths reach the out: label that frees it (:1005-1007).
• Compare vid_enum_outputs() :960-963 which frees dod_buf.Pointer on every path including success.

Reproduction (guest-verified)

SSDT ssdt_dfb.asl: _BCL returns a 64-entry package (~3.3 KB eval buffer) and always succeeds; _DCS fires Notify(VGT0, 0x81) (REPROBE) on every read from the 2nd on, so each sysctl read of hw.acpi.video.lcd0.active rebinds both outputs and leaks both _BCL eval buffers.

run_df4485.sh (log: run.log):

kldload acpi_video
vmstat -m | grep acpica        # baseline: 51 allocs, 10.2K in use
sleep 10; vmstat -m ...        # control: unchanged (51 / 10.2K) — idle churn = 0
40 × sysctl read lcd0.active   # 39 REPROBEs × 2 outputs = 78 leaked buffers
vmstat -m | grep acpica        # after: 209 allocs, 267K in use

+158 allocations / +257 KB attributable to the reads; ≈3.3 KB per leaked _BCL buffer, exactly the 64-entry package size. Guest stayed up, rebinds kept working (levels still correct after the loop).

Verdict summary

reproduced — deterministic, measurable kernel memory growth under firmware-controlled notify frequency (impact: memory-exhaustion DoS). Attacker model: crafted ACPI table (boot/loader privilege) or firmware bug; hence Low severity.

Fix

fix.diff (validated on the guest): free bcl_buf.Pointer on the success path of vo_get_brightness_levels() before returning.

VERDICT — DF-4485 (vo_get_brightness_levels() leaks the _BCL eval buffer)

Status: reproduced. One guest boot with SSDT-B (ssdt_dfb.asl), measured via the M_ACPICA malloc type in vmstat -m.

Chain

1. vo_get_brightness_levels (acpi_video.c:966-1009) evaluates _BCL into bcl_buf (ACPI_ALLOCATE_BUFFER). On success it copies the integers into a fresh levels array and returns at :1002-1003 WITHOUT freeing bcl_buf.Pointer — only the failure paths reach the out: free at :1005-1007. (Compare vid_enum_outputs :960-963 which always frees.)
2. Every acpi_video_vo_bind — at attach and at every 0x81 REPROBE rebind — therefore leaks one eval buffer per output, sized by the ACPI table's _BCL package.

Measurement (run.log)

• baseline (after attach): acpica 51 allocs, 10.2K in use
• idle 10 s control: acpica 51 allocs, 10.2K — background churn is zero
• 40 sysctl reads of lcd0.active → 39 REPROBE notifies → 39 rebinds × 2 outputs: acpica 209 allocs, 267K in use
• Δ = +158 allocations / +257 KB ⇒ ≈3.3 KB per leaked buffer — exactly the 64-entry _BCL package this table returns. Levels stayed correct and the guest stayed up throughout (memory-exhaustion class, not a crash).

Ceiling

The notify frequency is firmware-controlled, and the per-event leak size is table-controlled (_BCL package of N integers ⇒ ~48·N+overhead bytes), so a crafted table can drain kernel memory arbitrarily fast. Requires firmware/loader control (or buggy firmware reprobing) — Low severity.

Fix validation

fix.diff (shared with DF-4484) frees bcl_buf.Pointer on the success path. Re-tested on the patched kernel with the identical 40-read loop: the acpica arena stayed flat (see fix_run.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.