Supermicro ATEN Physical Memory Access

Executive summary #

Supermicro ATEN-based BMCs expose a second OEM IPMI command that reads and writes arbitrary physical memory, distinct from the 0x30/0x70 memory command: NetFn 0x30 command 0xae (OEMHW1Command) sub-command 0x22 (HW1LcdFwUpdate). The handler takes a caller-supplied 32-bit physical address and a 32-bit value, both big-endian, maps the target page through /dev/mem, reads the existing word (returned in the response), and then unconditionally writes the supplied value. There is no address allowlist, no bounds check, and, unlike the 0x30/0x70 write command on the same generation, no System Lockdown gate. A single authenticated IPMI Administrator session therefore reads and writes the BMC's entire physical address space through this command even on a unit where System Lockdown is engaged. This vulnerability has an estimated CVSSv3.1 score of CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H (7.2, High), and is an instance of CWE-749 (Exposed Dangerous Method or Function) and CWE-123 (Write-what-where Condition).

Technical details #

The request is NetFn 0x30 command 0xae with the OEMHW1 sub-command byte 0x22 first, then the 32-bit big-endian target address and the 32-bit big-endian value:

30 ae 22 <a31_24> <a23_16> <a15_8> <a7_0>  <v31_24> <v23_16> <v15_8> <v7_0>

OEMHW1Command switches on the request byte at offset 0xf; case 0x22 dispatches HW1LcdFwUpdate. That handler reads the address at request offset 0x10 and the value at offset 0x14, byte-swaps both (so they are big-endian on the wire), opens /dev/mem with O_RDWR|O_SYNC, mmaps one 4 KiB page at addr & 0xfffff000 with PROT_READ|PROT_WRITE and MAP_SHARED, loads the word at addr & 0xfff into the response, and stores the supplied value at the same offset. Nothing between the argument decode and the open inspects the address; the two access() calls in the function guard only debug logging (/nv/ConsoleLogEn, /nv/DebugLogEn), not the memory access. The OEM command table registers OEMHW1Command at NetFn 0x30, command 0xae, minimum privilege Administrator, with no channel restriction.

Because the handler always writes, a non-destructive read targets a write-immune register. The AST2600 SCU silicon-revision register at 0x1e6e2004 is read-only and protected by the SCU write-key, so writing 0 there is a hardware no-op and the response returns the register value. The four response bytes are the pre-write word at 0x1e6e2004, most-significant byte first. A request from a session below Administrator returns completion code 0xd4; a build that does not route sub-command 0x22 returns 0xcc.

Attacker value #

This issue allows an authenticated IPMI Administrator to read and write arbitrary BMC physical memory and thereby execute arbitrary code on the underlying BMC operating system, effective creating a privilege escalation path from IPMI Administrator to total control of the device. The write reaches DRAM, the whole system-on-chip register space, the SCU, the FMC/SPI flash controller, and the AST2600 eMMC and watchdog blocks, so it is a direct path to persistent control of the BMC; the read returns the pre-write word at the target address, disclosing arbitrary BMC memory including the cleartext account passwords the firmware keeps resident. Because the response carries the original word, the command doubles as an arbitrary read oracle.

The precondition is an IPMI Administrator RMCP+ session; where Administrator is reachable without a password as described by CVE-2026-18449 or via the reserved role-byte escalation issue described by CVE-2026-65220. This primitive chains behind those and becomes reachable without a valid administrative credential. The significant property beyond the sibling 0x30/0x70 command is that this one has no System Lockdown gate, so it remains a full arbitrary write on a locked-down X13 2401MS 01.07.01 unit, where the 0x30/0x70 write is refused with 0xd4 while lockdown is on.

Credit #

This issue was discovered by HD Moore with the help of AI tools. Disclosure was coordinated by Tod Beardsley.

Timeline #

• 2026-08-12 (Wed): Initial findings discovered and documented
• 2026-07-21 (Tue): CVE-2026-65211 reserved
• 2026-08-27 (Thu): Vendor notified
• 2026-10-23 (Fri): Transferred CVE to the vendor for record management
• 2026-10-26 (Mon): This public disclosure