Authorization boundaries in SMM communication.

Part 3 of 4: the Lenovo WmiBiosSetupSmm disclosure. See Part 1 (the chain) and Part 2 (the missing validation).

Missing size and buffer checks make a handler fragile. Two more gaps make it usable: it authenticates nobody, and it hands the attacker a map. This part is about the authorization boundary in SMM communication, where it sits, how it’s crossed here, and what one well-built module in the same firmware tells us about doing it right.

Where the boundary should sit

An SMI handler runs at the highest privilege on the platform, on behalf of a caller it cannot see. The authorization boundary is the gate that answers: is this caller allowed to invoke this function? For a handler that rewrites BIOS settings, the answer should almost never be “anyone in ring 0.”

CVE-2026-10590: no authentication

SW SMI 0xDE has no authentication mechanism: no password check, no Secure Boot verification, no UEFI variable-based access control. The only gate is that a setting name must match a hardcoded table entry. Any ring-0 code can write WMI data into the BNVS OpRegion and trigger the handler with out 0xB2, 0xDE. The trigger path:

OS WMI call → Lenovo kernel driver → ACPI method (WMIU/WMIS/…)
  → store data into the BNVS OpRegion
  → WSMI: out 0xB3 (command), out 0xB2 (0xDE)   ; hardware raises the SW SMI
  → PchSmiDispatcher routes to WmiBiosSetupSmm
  → handler reads BNVS from SMRAM, acts, writes result back

CVE-2026-10588: the leak that crosses the boundary

On its own, an unauthenticated handler is dangerous. Paired with an address leak, it becomes a roadmap. During initialization, the module scans the DSDT and patches the ACPI OpRegion field with the address of its SMM-allocated BNVS buffer:

mov dword [rbx + 7], eax   ; write SMM buffer address into the ACPI OpRegion field

That buffer lives inside SMRAM, and its address is now written into a DSDT structure mapped into OS memory. The result: a live SMRAM address (observed as 0x00000000719DD518) is exposed through the IhisiParamBuffer EFI variable with NV+BS+RT attributes: readable through the standard EFI variable API without root. That’s CWE-200 at the worst possible layer, because SMM’s entire model depends on SMRAM being opaque.

The same firmware, one module over, did it right

The most useful thing the audit surfaced wasn’t a bug, it was a counter-example. LenovoVariableSmm, sitting in the same firmware, is well built: a custom SmmIsBufferOutsideSmmValid with four-plus validation layers (address-mask, SMRAM-descriptor overlap, GCD map, EFI memory map, page-table checks), overflow-safe (mask - size + 1) arithmetic, and an AES-CBC-authenticated channel with a checksum. Same platform, same team, same threat model, one module earns the checks, the other skips them all. That contrast is the lesson: firmware security isn’t a property you have, it’s a gate every single SMI entry point has to re-earn by hand.

What a defender should look for

When auditing SMM communication buffers, the fast signal is the absence of three things:

• No SmmIsBufferOutsideSmmValid() on any buffer the OS can influence.
• No caller authentication on state-changing SMIs (setting writes, flash, variables).
• Any SMRAM pointer written into an OS-readable structure, an ACPI OpRegion, a runtime (RT) EFI variable, a shared page.

This is the same class as CVE-2025-4421 / -4422 (Insyde H2O IHISI CommBuffer failures) and CVE-2021-3970 (an earlier unvalidated Lenovo WMI SMI handler). The pattern recurs because every new firmware feature adds new SMI entry points, and each one has to be validated from scratch.

Next, Part 4: the LEN-213632 timeline, what Lenovo accepted and rejected, and the remediation.