Validating the unvalidated: SMI input handling.

Part 2 of 4: the Lenovo WmiBiosSetupSmm disclosure. Start with Part 1 for the architecture and the escalation chain.

Part 1 named the target: WmiBiosSetupSmm, software SMI 0xDE, on the Lenovo Legion 5 15IRX10 (BIOS QNCN33WW v1.33, InsydeH2O). This part opens the handler and shows exactly which input-validation checks were missing, and proves it on the physical device.

What the handler does

The handler entry point sits at 0x11850. It reads an opcode from the ACPI BNVS buffer at [0x14500] and dispatches to a query path (opcode 0xA0) or a set path (opcode 0xA1). The set path parses comma-delimited name,value strings, looks each up in a hardcoded settings table, writes the value straight into the Setup / PchSetup / SaSetup / CpuSetup structures, then persists via SetVariable.

The settings it will write are a long list of power, memory and PCIe controls, Cstates, PackageCstateLimit, SAGV, the DRAM channel controllers, EnableVMDController, the PCH and CPU PCIExpressRootPort entries, ASPM, L1Substates, PCIeSpeed, AdvancedErrorReporting. Forty-plus firmware settings, reachable from ring 0, with no user interaction and no audit trail.

The missing checks

Two of the four CVEs are input-validation gaps:

CVE-2026-10587: no SmmIsBufferOutsideSmmValid(). The module contains zero calls to it. A handler is supposed to confirm any OS-influenced buffer lives outside SMRAM before touching it; this one never asks.

CVE-2026-10589: no CommBufferSize validation. The SW SMI callback receives the standard parameters:

EFI_STATUS Handler(EFI_HANDLE DispatchHandle, CONST VOID *Context,
                   VOID *CommBuffer, UINTN *CommBufferSize)

…and ignores CommBuffer / CommBufferSize entirely, reading instead from the internal BNVS buffer.

An honest nuance

Because BNVS is itself SMM-allocated (via SmmAllocatePool, a fixed 0x404-byte region), the standard CommBuffer path can’t be used for direct SMRAM corruption, a genuine mitigating factor I flagged in the report. What remains, and what the CVE tracks, is that the handler has no way to verify the size or integrity of the data it processes, and no re-validation that the BNVS content wasn’t tampered with between the ACPI write and the SMI. Lenovo assessed the resulting exposure as reachable to code execution in SMM; I’ve kept my own description to what the disassembly supports.

Reproduction

The core claim, the handler runs with no validation, is directly reproducible. The PoC snapshots the four BIOS-setup EFI variables, fires SW SMI 0xDE by writing to port 0xB2 through /dev/port, and snapshots again:

── PHASE 4: SW SMI 0xDE Trigger ──
  [*] Writing 0xDE to I/O port 0xB2 via /dev/port...
  [+] SMI triggered via /dev/port
  [+] CPU entered SMM → WmiBiosSetupSmm handler executed → returned

── BIOS Setup EFI Variables — AFTER SMI ──
  [CpuSetup]  sha256=2751f840…  [=] UNCHANGED
  [Setup]     sha256=5ad38c83…  [=] UNCHANGED
  [PchSetup]  sha256=2f3b1576…  [=] UNCHANGED
  [SaSetup]   sha256=f1e31b18…  [=] UNCHANGED

  SMI 0xDE successfully triggered from ring-0 (no auth required).
  WmiBiosSetupSmm executed without CommBuffer/Size validation.

This is deliberately conservative: it fires the handler in a query-mode path, proves it enters SMM and returns without authorization or buffer validation, and leaves firmware state untouched (every hash UNCHANGED). It demonstrates the missing gate, not a weaponized modification, which is the responsible way to prove a firmware handler is reachable and unguarded.

The checks that should have been there

• Call SmmIsBufferOutsideSmmValid() on any OS-influenced buffer before use.
• Validate the BNVS structure bounds / CommBufferSize before parsing.
• Re-validate content that the OS can write between the ACPI store and the SMI.

Next, Part 3: the authorization boundary, the SMRAM leak, and the one module in the same firmware that did all of this right.