Part 1 of 4. The Lenovo WmiBiosSetupSmm disclosure (CVE-2026-10587 to -10590), coordinated with Lenovo PSIRT under case LEN-213632 and published in advisory LEN-220440 on 14 July 2026.
Most vulnerability write-ups live in the operating system, the browser, or an app. This series lives underneath all of them, in System Management Mode (SMM), the “ring -2” execution mode the OS, the hypervisor, and even Secure Boot cannot see into. Four coordinated CVEs in the BIOS of the Lenovo Legion 5 15IRX10 come down to a single unglamorous root cause: an SMI handler that trusts input it was never supposed to trust, and leaks an SMRAM address on the way.
Why ring -2 matters
SMM is a CPU mode entered via a System Management Interrupt (SMI). Code running there lives in a protected region called SMRAM and executes at the highest privilege on the platform, below the kernel, below the hypervisor. It’s the layer where firmware implants live, precisely because nothing above them can see or evict them. A foothold here outlasts an OS reinstall.
The OS invokes an SMM handler by writing a byte to I/O port 0xB2 (the “software SMI” trigger) and passing data through a shared communication buffer. Because that data originates on the untrusted OS side, a well-written handler validates the buffer’s location and size, and authorizes the caller, before acting. This one does none of that.
Mapping the attack surface
Starting from a 32 MB SPI flash dump, I extracted the firmware (2,717 files, 449 PE modules) and mapped the SMM attack surface: 23 modules consuming EFI_SMM_SW_DISPATCH2_PROTOCOL, plus ~30 more SMM drivers, 53 in total. Radare2 disassembly of the eight Lenovo/Insyde-specific handlers put one at the top of the list immediately:
| Module | SW SMI | Size | Validation |
|---|---|---|---|
IhisiServicesSmm | IHISI | 90 KB | dual-mode (pre/post auth) |
WmiBiosSetupSmm | 0xDE | 41 KB | none |
LfcWmiServiceSmm | LFC | 29 KB | none |
LenovoVariableSmm | Var | 57 KB | custom 4-layer |
WmiBiosSetupSmm (GUID f412361d-a25e-4860-8be3-d31f764df5aa) registers a handler on SW SMI 0xDE and performs none of the three checks a firmware handler owes its callers.
The chain
That single gap decomposes into four separately-tracked CVEs that, together, form a clean escalation path from ring 0 into ring -2:
| CVE | The gap |
|---|---|
| CVE-2026-10588 | An EFI variable leaks a live SMRAM address (the map) |
| CVE-2026-10587 | No SmmIsBufferOutsideSmmValid(): the handler trusts an unvalidated buffer |
| CVE-2026-10589 | No CommBufferSize validation on SMI 0xDE |
| CVE-2026-10590 | No authentication: any ring-0 caller drives the handler at will |
leaked SMRAM address (10588) → unvalidated buffer the handler trusts (10587 / 10589) → targeted SMM manipulation, with no authentication stopping any of it (10590).
“But it’s only Medium”
Lenovo published these as Medium (CVSS ~4.4–6.0). Don’t shrug at that. CVSS punishes the precondition: you need local, ring-0 access first, which drags the score down hard. What it doesn’t capture is the prize: code and state manipulation beneath the OS, the hypervisor, attestation, and Secure Boot. A Medium-scored SMM foothold can outlast a Critical-scored userland RCE. Read firmware CVEs by capability, not by number.
In this series
- Part 2 – Validating the unvalidated: the handler internals, the missing size/buffer checks, and the reproduction.
- Part 3 – Authorization boundaries: the missing auth, the SMRAM leak, and how one module in the same firmware got it right.
- Part 4 – Coordinated disclosure with Lenovo PSIRT: the LEN-213632 timeline and remediation.
References: CVE-2026-10587 · -10588 · -10589 · -10590 · Lenovo advisory LEN-220440.
