• File: sys/dev/acpica/acpi_cpu_cstate.c
• Lines: 530, 532, 687, 675, 1140, 1141, 1144, 1145, 943, 970, 1390
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U:C:L/I:N/A:H
• CWE: CWE-129 Improper Validation of Array Index
• Confidence: certain

Summary

acpi_cst_cx_probe_cst() unconditionally returns success (0) even when _CST contains zero valid C-state sub-packages, leaving sc->cst_cx_count==0 while the rest of the driver assumes count>=1 (C1 is mandatory).

The subsequent clamping idiom if (val > sc->cst_cx_count - 1) val = sc->cst_cx_count - 1 in acpi_cst_set_lowest_oncpu() is signed-int arithmetic: when count is 0, count - 1 becomes -1, val is clamped to -1, and sc->cst_cx_states[-1] is read from the heap.

Independently, acpi_cst_idle() indexes cst_cx_states[0] whose .enter pointer was NULL-ed by acpi_cst_free_resource()'s memset, then dereferences it (cx_next->enter(cx_next) at line 970), crashing the kernel on the first idle tick.

Root cause

acpi_cst_cx_probe_cst() sets sc->cst_cx_count = 0 at sys/dev/acpica/acpi_cpu_cstate.c:530, then iterates the _CST sub-packages (line 532).

The loop body increments cst_cx_count ONLY when a sub-package passes ACPI_PKG_VALID(pkg,4) AND acpi_PkgInt32 succeeds AND the state passes type filtering AND (for C2/C3) resource allocation or cx_setup succeeds (lines 536-617).

If every sub-package fails any of these, the loop completes with cst_cx_count still 0. The function then falls through to return (0) at line 687 — it only returns ENXIO for AcpiEvaluateObject failure (line 500) or a malformed top-level package (line 507), never for "no usable C-states".

This violates the ACPI invariant enforced in the FADT sibling path (acpi_cst_cx_probe_fadt line 388-396 always synthesizes C1).

Sink 1 (OOB read): in acpi_cst_set_lowest_oncpu() the bound sc->cst_cx_count - 1 (line 1140) is evaluated in signed int. With count==0 it is -1, so any user-supplied val>=0 satisfies val > -1 and val is reassigned to -1 (line 1141). Line 1144 then reads sc->cst_cx_states[old_lowest].type and line 1145 reads sc->cst_cx_states[val].type where val=-1 — an OOB read of sizeof(uint32_t) at &sc->cst_cx_states[0] - sizeof(struct acpi_cst_cx), i.e. heap memory preceding the softc.

atomic_swap_int at line 1142 stores -1 into sc->cst_cx_lowest, so on the next invocation old_lowest is also -1 and BOTH reads at lines 1144 and 1145 are OOB.

The reprobe path reaches this via acpi_cst_cx_probe_cst(sc,1) → line 675 acpi_cst_set_lowest_oncpu(sc, sc->cst_cx_lowest_req).

The per-cpu sysctl path reaches it via acpi_cst_lowest_sysctl → acpi_cst_set_lowest → acpi_cst_set_lowest_oncpu.

The global sysctl path also hits the same idiom at lines 1010-1011 and 1246-1247.

Sink 2 (NULL deref panic): acpi_cst_free_resource() memset()s each cst_cx_states[i] to zero (line 1390), clearing .enter (a function pointer). When cst_cx_count==0, cst_cx_states[0].enter==NULL and .type==0==ACPI_STATE_C0.

acpi_cst_idle() at line 918 starts its loop at i=sc->cst_cx_lowest (0 on initial probe, since set at line 341 and not yet mutated); cst_cx_states[0].trans_lat==0 so 0*3 <= cst_prev_sleep(1000000) selects cx_next_idx=0. Line 942 increments cst_cx_stats[0] (in-bounds). Line 943 KASSERT(cx_next->type != ACPI_STATE_C0) fires on INVARIANTS kernels.

On production kernels the KASSERT is a no-op (sys/sys/systm.h:117) and execution reaches line 970 cx_next->enter(cx_next) which dereferences NULL → double-fault/panic.

The idle hook is installed at line 786 unconditionally after postattach, so the panic fires on the first idle tick after boot.

Threat

Primary attacker position is a malicious or buggy ACPI firmware: the _CST object is AML supplied by the platform (DSDT/SSDT).

In virtualization (QEMU/KVM, VirtualBox, cloud guests) the host fully controls the ACPI tables presented to the guest, so a malicious host can panic any guest running this kernel at boot with a crafted _CST containing only invalid sub-packages (e.g. packages missing elements, wrong types, or a header count mismatch).

On bare metal, the same triggers from a buggy BIOS DSDT or a root-loaded custom SSDT (loader tunable hint.acpi.0.asl="ssdt.aml").

A local root can also amplify an existing count==0 state into the OOB-read sink by writing to hw.acpi.cpu.cx_lowest or hw.acpi.cpu.cx_lowest_req after a firmware Notify delivers a malformed _CST.

Impact is kernel panic (reliable A:H denial of service on every idle tick) plus a heap OOB read of 4 bytes whose value influences a cputimer_intr_powersave_{add,rem}req decision (C:L).

No code execution primitive demonstrated; the OOB read value is not returned to userspace but is used in kernel control flow.

Exploit / PoC

The bug reproduces deterministically from a malformed _CST. Simplest harness is a QEMU/KVM guest with a custom SSDT injected containing:

DefinitionBlock ("ssdt.aml", "SSDT", 2, "BUG ", "CSTBAD", 0)
{
    Scope (\_SB)
    {
        Processor (CPU0, 0x0, 0xFFFFFFFF, 0x0)
        {
            /* _CST header claims 2 states but both sub-packages are invalid */
            Name (_CST, Package (0x3)
            {
                0x2,
                Package (0x4) { ResourceTemplate(){Register(FFixedHW,0,0,0)},
                                 0x1, 0x0, 0x0 }, /* truncated */
                Buffer (0xF) { 0x0 }   /* wrong type, fails ACPI_PKG_VALID(pkg,4) */
            })
        }
    }
}

Boot the guest with the injected SSDT. On the first idle tick after acpi_cst_postattach() installs cpu_idle_hook (line 786), the kernel panics:

• INVARIANTS kernel: panic: assertion "cx_next->type != ACPI_STATE_C0" failed ... at acpi_cpu_cstate.c:943
• Production kernel: kernel: fatal trap 12: page fault while in kernel mode faulting on VA 0x0 from acpi_cst_idle+0x... (NULL deref of cx_next->enter at line 970).

For the OOB-read variant: ensure the guest first boots with a valid _CST (so cst_cx_lowest_req gets set), then trigger a Notify(0x81) re-evaluation that swaps in the malformed _CST. The reprobe path then reads cst_cx_states[-1].

A simpler local-root trigger on a system where count has already dropped to 0: sysctl hw.acpi.cpu.0.cx_lowest=C3 which forces set_lowest_oncpu with cst_cx_count==0 and reads the OOB .type field at line 1145.

Success criteria: kernel panic at boot (NULL deref) or on sysctl write (OOB read + subsequent panic). Both are reliable and reproducible.

Recommended fix

Ensure at least one valid C-state exists after _CST parsing by synthesizing a mandatory C1 HALT fallback when the loop produced nothing (mirroring the FADT path at lines 388-396). Also harden the signed bound idiom against count==0.

--- a/sys/dev/acpica/acpi_cpu_cstate.c
+++ b/sys/dev/acpica/acpi_cpu_cstate.c
@@ -682,6 +682,26 @@ acpi_cst_cx_probe_cst(struct acpi_cst_softc *sc, int reprobe)
      */
     acpi_cst_non_c3(sc);

+    /*
+     * ACPI guarantees C1 is always available.  If _CST contained no
+     * usable C-state (all sub-packages malformed or filtered out by
+     * quirks), synthesize a C1 HALT state so the idle loop has a
+     * safe enter method.  Without this, cst_cx_count==0 causes:
+     *   - acpi_cst_idle() to dereference cx_next->enter == NULL
+     *     (memset by acpi_cst_free_resource) -> panic.
+     *   - acpi_cst_set_lowest_oncpu() to evaluate the signed bound
+     *     `cst_cx_count - 1` as -1 and read cst_cx_states[-1]
+     *     -> heap OOB read.
+     */
+    if (sc->cst_cx_count == 0) {
+        struct acpi_cst_cx *cx1 = &sc->cst_cx_states[0];
+        int error1;
+
+        cx1->type = ACPI_STATE_C1;
+        cx1->trans_lat = 0;
+        cx1->enter = acpi_cst_c1_halt_enter;
+        error1 = acpi_cst_cx_setup(cx1);
+        if (error1)
+            panic("C1 CST fallback setup failed: %d", error1);
+        sc->cst_cx_count = 1;
+        sc->cst_non_c3 = 0;
+    }
+
     cpu_sfence();
     sc->cst_flags &= ~ACPI_CST_FLAG_PROBING;

@@ -1137,8 +1157,12 @@ acpi_cst_set_lowest_oncpu(struct acpi_cst_softc *sc, int val)
     old_lowest_req = sc->cst_cx_lowest_req;
     sc->cst_cx_lowest_req = val;

-    if (val > sc->cst_cx_count - 1)
-   val = sc->cst_cx_count - 1;
+    /* Defensive: never let val go negative even if cst_cx_count == 0. */
+    if (sc->cst_cx_count <= 0 || val < 0)
+        val = 0;
+    else if (val > sc->cst_cx_count - 1)
+        val = sc->cst_cx_count - 1;
+    if (old_lowest < 0 || old_lowest >= MAX_CX_STATES)
+        old_lowest = 0;
     old_lowest = atomic_swap_int(&sc->cst_cx_lowest, val);

     old_type = sc->cst_cx_states[old_lowest].type;

The primary fix is the post-loop C1 synthesis; the set_lowest_oncpu hardening is defense-in-depth so a future regression or a count-drop via Notify cannot reintroduce the OOB.

Equivalent clamping should also be applied to the global sysctl path at lines 1010-1011 and 1246-1247 (acpi_cst_cx_count - 1 → imax(0, acpi_cst_cx_count - 1)).

Related findings

• DF-1480 (sibling, acpi_cpu_pstate.c): signed integer underflow stack leak.