DF-4897 — complete_raid5_write() builds and writes RAID-4/5 parity from FAILED (undefined) first-phase reads — garbage parity committed to stable storage; corruption persists through retries and surfaces later as silently corrupt recovered data

Root cause (inspection-certain)

sys/dev/raid/vinum/vinuminterrupt.c:194-196:

} else if ((rqg->flags & (XFR_NORMAL_WRITE | XFR_DEGRADED_WRITE))
&&(rqg->active == 1))
complete_raid5_write(rqe);

The gate never tests bp->b_flags & B_ERROR, and complete_raid5_write() contains no error handling of any kind. The XOR machinery consumes rqe->b.b_data of the participating rqes:

• degraded pass :331-348 — pdata[count] ^= sdata[count]
• normal pass :362-385 — old-data-out / new-data-in XORs

For a component whose READ failed, that buffer is a non-zeroed malloc (build_rq_buffer(), vinumrequest.c:834 — Malloc(bp->b_bcount)) with undefined contents (stale kernel heap). The computed parity is therefore XOR(garbage_old_data_of_failed_member, good members), and it is written to disk by the unconditional parity launch at :433-464 (rqe->b.b_cmd = BUF_CMD_WRITE; ... vn_strategy/dev_dstrategy).

Why the damage is permanent

The request does fail at the top level (rq->error is set by the error path at :92-140; volume ops go to the ioerror daemon → retry or EIO), so the caller sees an error. But the corrupted parity is already on disk. If the failure was transient, the daemon retry succeeds — and the retry's own read-modify-write computes parity' = parity_stored ^ old_data ^ new_data where parity_stored is the poisoned value: the stripe parity stays wrong forever (until a manual vinum parity rebuild). A later subdisk failure reconstructed through this stripe (XFR_RECOVERY_READ XOR at :165-193) then returns corrupted data to the user with no error indication anywhere — the classic worst-case RAID integrity failure, triggered by a single transient component read error.

Trigger / PoC

Requires one failed component read during a RAID-4/5 group write (failing device). Not injectable on this guest (md devices cannot be made to fail; re-verified 2026-09-24 — gpt destroy/gpt remove under open vinum I/O leaves the stale cdev serving). Untested, certain by inspection (error flow + XOR dataflow verified line-by-line).

Fix (proposed; not applied)

Do not run the parity update from failed components — fail the group instead (the error path already crashes the sd; the request completes through the error branch):

--- a/sys/dev/raid/vinum/vinuminterrupt.c +++ b/sys/dev/raid/vinum/vinuminterrupt.c @@ -193,7 +193,8 @@ } else if ((rqg->flags & (XFR_NORMAL_WRITE | XFR_DEGRADED_WRITE)) / RAID 4/5 group write operation / - &&(rqg->active == 1)) / and this is the last active request / + &&(rqg->active == 1) / and this is the last active request / + &&((bp->b_flags & B_ERROR) == 0)) / and its read did not fail / complete_raid5_write(rqe);

Note: a full fix should also check the OTHER members' B_ERROR (any member's read failing poisons the parity XOR); gating on the completing bp catches the common last-member case, and the sd crashed by the error path prevents future groups from using the bad component.

(severity Low: requires a component read failure; impact is persistent silent on-disk parity corruption — integrity, not memory safety.)