DF-4178 — Verification Verdict

Status: inconclusive (hardware-gated: no 3ware Escalade controller in the QEMU guest) Impact: none on this guest (source-certain kernel memory corruption on affected hardware) Confidence: likely (control flow source-certain; trigger needs a controller that completes a command after the 5 s poll window)

Mechanism (source trace)

1. twe_ioctl TWEIO_GET_PARAM → twe_get_param() (sys/dev/raid/twe/twe.c:770) with func == NULL uses twe_immediate_request() (twe.c:810).
2. twe_immediate_request() (twe.c:981) sets tr->tr_status = TWE_CMD_BUSY, twe_map_request() posts the command — twe_start() (twe.c:1126-1158) sets BUSY and twe_enqueue_busy(tr) (twe_freebsd.c:1144 via twe_setup_data_dmamap → twe_start).
3. Poll loop (twe.c:1003-1006) waits at most 5000 ms, then falls out and returns 1 with the request still on twe_busy and still posted to the controller (twe.c:1010).
4. Caller error path twe_get_param err: (twe.c:826-833) — twe_release_request(tr) → twe_enqueue_free(tr) (twe.c:1623-1631). The request is now double-linked (busy + free).
5. The free list turns over in microseconds under I/O; another consumer pops the request (twe_get_request, twe.c:1594) and re-submits it.
6. The controller eventually completes the old command: twe_done() (twe.c:1177) → tr = sc->twe_lookup[rq.u.response_id] (twe.c:1199). tr->tr_status != TWE_CMD_BUSY → only prints "completion event for nonbusy command" (twe.c:1203-1204) and then falls through: - tr->tr_status = TWE_CMD_COMPLETE (twe.c:1205) — clobbers the new owner's SETUP/BUSY state; - twe_remove_busy(tr) (twe.c:1209) — TAILQ_REMOVE on a request that is not on twe_busy: writes through the stale tr_link pointers (twevar.h:249-253) — kernel memory corruption; - twe_enqueue_complete(tr) → twe_complete() dispatches the new owner's tr_complete (e.g. twe_completeio, twe.c:1017 → twed_intr(bio) → biodone() on a bio still in flight).

Identical release-while-busy patterns: twe_set_param out: (twe.c:909-914), twe_dump_blocks (twe.c:506-510), twe_init_connection (twe.c:946-947).

Related but distinct: twe_wait_request() (twe.c:960-973, TWEIO_COMMAND) has no timeout at all — a never-completing controller hangs the ioctl forever, each such ioctl permanently consuming one of the 255 requests.

Why it cannot be reproduced on this guest

The twe driver binds to PCI vendor 0x13c1 devices only (twe_freebsd.c:172-174). The QEMU guest has no 3ware controller (pciconf -l shows no 13c1 device, no /dev/twe* node exists), so the trigger path cannot be exercised. PoC builds and runs; open("/dev/twe0") fails with ENOENT (see run.log).

Phase V: escalation assessment

The primitive (once a late completion arrives) is a write-what-where-ish TAILQ corruption inside the driver's request queues plus a forced completion callback with attacker-influenced tr_private/tr_data — enough for kernel RCE in principle on affected hardware. On this guest the path is not exercisable at all (device absent), so no chain can be developed here. Gate: root-only control device (0600 root:operator, twe_freebsd.c:339-342) + a controller that completes commands late.

Fix validation

fix.diff (two hunks: timeout path unmaps + dequeues + marks ERROR; twe_done consumes-and-drops stale responses instead of falling through) applies cleanly to the guest's /usr/src and was batch-compiled with the other four fixes of this batch into X86_64_GENERIC — see fix_build.log / fix_verdict in verdict.json.

Residual (documented in fix.diff header): the caller still kfree()s the 512-byte parameter buffer after a timeout while the controller may late-write it; a full fix needs a controller-side abort (TWE_OP_ABORT) before freeing.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.