smic_read_byte() writes a status code (SC_SMS_RD_NEXT 0xC5) into the control register instead of the command code (CC_SMS_RD_NEXT 0x45) — out-of-spec SMIC control write on every reply byte
Summary
Status/command constant confusion at the read-next site (all other sites correct) - on spec-compliant silicon every SMIC read fails, feeding the DF-2003 hang class; inherited from FreeBSD ~19 years. One-token fix.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4949 · 1 files| File | Type | Description | Size | |
|---|---|---|---|---|
| verdict.json | file | 1022 B | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Exploit chain
every SMIC reply byte -> out-of-spec 0xC5 control write -> BMC rejects/misinterprets -> read fails/retries/hang-feed
Evidence (decisive lines)
findings/poc/DF-4949/ (this verdict)
Verdict
Functional protocol defect (Low; no SMIC silicon on guest/QEMU): smic_read_byte writes the STATUS code SC_SMS_RD_NEXT (0xC5) into the control register where the COMMAND code CC_SMS_RD_NEXT (0x45) is required - every other transaction site in the file uses correct CC codes, making this an internal inconsistency (typo) inherited verbatim from FreeBSD ~19 years ago. On spec-compliant silicon every SMIC read fails (EIO storms, 3x retries, recovery only via wait_for_not_busy - feeding the DF-2003 hang class); a hostile BMC could interpret the stray opcode as a different command. One-token fix.
No comments yet.