DF-3794 — ACPIIO_DO_MCALL leaks the copied-in object list when copyinstr faults

• File: sys/dev/acpica/acpi.c (pass 2)
• Lines: 3341–3378 (leak at 3356–3357)
• Class: CWE-401 (missing release of memory on error path) / CWE-772
• Severity: Low (root + boot-tunable gated) · Confidence: certain (measured on guest)

What

params = (struct acpi_mcall_ioctl_arg *)addr;
args = acpi_copyin_object_list(&params->args);   /* kernel allocations */
if (!args)
    return EINVAL;
if (copyinstr(params->path, path, sizeof(path), NULL))
    return EINVAL;                               /* <-- `args` never freed */

acpi_copyin_object_list() allocates sizeof(ACPI_OBJECT_LIST) + Count*sizeof(ACPI_OBJECT) bytes (plus per-STRING/BUFFER payloads) from M_ACPICA. If the user-supplied path pointer faults on copyinstr, the ioctl returns EINVAL without freeing args. Every failing call leaks exactly that allocation set. There is no bound on repetitions.

Note: ACPIIO_DO_MCALL is reachable only with FWRITE on /dev/acpi (root; mode 0644) and the boot tunable debug.acpi.allow_method_calls=1 — hence severity Low (robustness/DoS by a privileged-but-untrusted process, e.g. a root daemon exposing the ioctl, and defense-in-depth for the debugging path).

Measured on the guest (DragonFly 6.5-DEVELOPMENT, tunable enabled)

vmstat -m | grep acpica
             acpica      46   6.39K       0    390M     138K   <- baseline
+100,000 faulted DO_MCALL (args: 2 INTEGER objects)
             acpica   97.7K   6.11M       0    390M     236K
+1,000,000 faulted DO_MCALL
             acpica   1.05M   67.1M       0    390M    1.18M
+100,000 faulted DO_MCALL (second session)
             acpica   1.14M   73.2M       0    390M    1.33M
+ 20,000 *valid* DO_MCALL (control, copyinstr succeeds -> args freed)
             acpica   1.14M   73.2M       0    390M    1.36M   <- InUse unchanged

64 bytes/call (16 + 2×24) as predicted; control run leaks nothing. 1.1M iterations took seconds ⇒ a privileged looping process can exhaust kernel heap unboundedly.

Reproduce

1. debug.acpi.allow_method_calls=1 in /boot/loader.conf.local, reboot.
2. cc -O -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica/source/include \ -o mcallleak mcallleak.c
3. vmstat -m | grep acpica; ./mcallleak 100000; vmstat -m | grep acpica (and ./mcallctrl 20000 for the no-leak control).

Fix

See fix.diff: free args on the copyinstr failure path.

DF-3794 VERDICT

Status: reproduced (measured kernel heap leak, gated on root + tunable)

Guest: DragonFly dfbsd 6.5-DEVELOPMENT (X86_64_GENERIC) with debug.acpi.allow_method_calls=1 (loader tunable), /dev/acpi mode crw-r--r-- root:wheel (ioctl needs FWRITE ⇒ root).

What was run

mcallleak.c (this pack): 2-INTEGER argument list, path = (char *)0x10 so copyinstr faults after acpi_copyin_object_list() succeeded. mcallctrl.c: identical ioctl with a valid path (control).

Measured with vmstat -m | grep acpica (M_ACPICA type, InUse bytes):

baseline                                       46 allocs    6.39K
+100,000  faulted calls (1st session)       97.7K allocs    6.11M
+1,000,000 faulted calls                  1.05M allocs   67.1M
+100,000  faulted calls (2nd session)      1.14M allocs   73.2M
+ 20,000  valid-path control calls         1.14M allocs   73.2M  <- unchanged

Exactly 64 bytes/call (16 + 2×24 = sizeof(ACPI_OBJECT_LIST) + 2 ACPI_OBJECTs), unbounded, seconds for a million iterations ⇒ memory-exhaustion DoS available to any process holding /dev/acpi O_RDWR when the debug tunable is enabled. Control run leaks nothing, isolating the leak to the copyinstr failure return at acpi.c:3356-3357.

Impact ceiling

dos (kernel heap exhaustion). Not memory corruption; not reachable unprivileged (FWRITE gate acpi.c:3427 + boot tunable acpi.c:3459).

Exploit chain

n/a (resource leak; privileged+debug-gated).

Fix validation

fix.diff (free args before the EINVAL return) applied in the guest's /usr/src, kernel rebuilt and booted; the same mcallleak 100000 run then showed zero growth of M_ACPICA InUse. See run_patched.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.