DF-2026 PoC — Multi-part SSIF response read loop has no iteration cap

Status: inconclusive / reproduced=0 — HW-GATED (IPMI SSIF needs a BMC; none present, ipmi.ko not loaded).

Verification method: source trace of sys/dev/misc/ipmi/ipmi_ssif.c:257 (for (;;)), lines 260-262, 274, 297-299. The multi-part READ_CONT loop has no iteration cap; a BMC that returns 0xff (or incrementing matching block numbers) on every READ_CONT spins it forever ⇒ kernel infinite-loop DoS (CWE-835). See VERDICT.md, fix.diff.

Build/run: no runtime PoC (no BMC). fix_build.log proves the fix compiles under -Werror rc=0.

DF-2026 — Multi-part SSIF response read loop has no iteration cap

Verdict

CONFIRMED (source-trace); NOT REPRODUCED AT RUNTIME — HW-GATED. Status: inconclusive, reproduced=0. The unbounded loop is real; it is unreachable on this guest (no BMC, no ichsmb/amdsmb, ipmi.ko not loaded).

Mechanism (confirmed)

The multi-part response read loop is an unconditional for (;;): - ipmi_ssif.c:257 — for (;;) { - ipmi_ssif.c:260-262 — each iteration calls smbus_bread(..., SMBUS_READ_CONT, &count, ssif_buf); so the BMC controls ssif_buf[0] (block marker) on every iteration. - ipmi_ssif.c:274 — if (ssif_buf[0] != 0xff && ssif_buf[0] != block) goto fail; a block that is neither 0xff nor the expected incrementing block number is rejected. - ipmi_ssif.c:297-299 — if (ssif_buf[0] != 0xff) break; block++;

There is no maximum iteration counter. A BMC that returns 0xff (or a sequence of incrementing/matching block numbers) on every READ_CONT keeps the loop spinning: block increments and wraps as a u_char (255 → 0 → …), and the 0xff marker short-circuits the line-274 guard, so the loop never exits. The only other exits are an smbus_bread error (goto fail) — which the BMC can simply not produce. Result: infinite kernel-loop DoS (wedge) at IPL of the SSIF thread, driven entirely by attacker-controlled BMC responses. Class: CWE-835 (reachable assertion / unbounded iteration).

(Observation, out of scope for this fix: the line-297 exit condition if (ssif_buf[0] != 0xff) break; reads as if a non-0xff block terminates the transfer, which is the inverse of the line-273 comment "0xff marks the last block"; regardless of the exact intended termination semantics, the absence of an iteration cap is the confirmed defect and the cap below closes the DoS.)

Why it is not reproduced on this guest (HW-gate)

Identical to DF-2024/2025: the loop body is only entered through ssif_polled_request(), which is only reachable with a real BMC on an SMBus block controller. No BMC on this guest ⇒ dead code at runtime. Threat actor = malicious/compromised BMC. No escalation chain (this is a DoS/infinite-loop class, not memory corruption; even on real hardware it is a wedge, not a write primitive).

PoC changes

None (source-only verification).

Fix (fix.diff)

In sys/dev/misc/ipmi/ipmi_ssif.c: add #define SSIF_MAX_READ_BLOCKS 256, declare int readblocks, initialize it before the loop, and bail (goto fail) once the iteration count exceeds the cap. 256 blocks × 31 payload bytes ≈ 8 KB, far above any legitimate IPMI response while bounding the loop deterministically. The fix does not alter the existing block-termination logic, so it is safe regardless of the 0xff/block-number semantics. Matches the finding proposal's intent (add an iteration cap).

Fix validation (Phase 8)

Combined kernel build with all four fixes: rc=0, 0 warnings, 0 errors under -Werror; ipmi_ssif.c recompiled, ipmi.ko relinked (see fix_build.log). HW-gated ⇒ fix_status = not_testable.