DF-4616 — ips_morpheus_poll computes its deadline in seconds but command->timeout counts 10-second watchdog ticks: the crash-dump poll window is 10× too short

What

sys/dev/raid/ips/ips.c:607-616:

void
ips_morpheus_poll(ips_command_t *command)
{
    uint32_t ts;

    ts = time_uptime + command->timeout;
    while (command->timeout != 0 &&
        ips_morpheus_check_intr(command->sc) == 0 &&
        (ts > time_uptime))
        DELAY(1000);
}

• command->timeout is set to 10 at issue time (ips_issue_morpheus_cmd, ips.c:601) and is decremented once per 10-second watchdog tick by ips_timeout (callout every 10 * hz, ips.c:369, decrement at ips.c:342). Its unit is therefore "10-second ticks": a command is allowed ~100 s by the watchdog.
• time_uptime is seconds. ts = time_uptime + 10 yields a deadline 10 seconds in the future — a 10× unit mismatch.

ips_morpheus_poll is the synchronous-completion engine of the crash-dump path: ipsd_dump_map_sg (ips_disk.c:322) calls sc->ips_poll_cmd(command) immediately after issuing the write, with interrupts disabled — polling is the only completion mechanism during a dump. When the controller takes longer than 10 s (large dump block through a busy cache-flushing controller — exactly the state a machine is in when it is crashing), the poll bails out with the command still outstanding:

• ipsd_dump_map_sg returns as if the block had been written;
• the dump proceeds on an unacknowledged write → missing/garbage blocks in the crash dump (silent evidence corruption), or a dump that fails downstream when the command eventually completes into a dead kernel.

Also in the same function: ips_morpheus_check_intr is invoked without queue_lock here (the real handler takes it, ips.c:585) — harmless in the dump context where interrupts are off, but a latent race if any other caller ever appears.

Build / run

Requires a morpheus ServeRAID controller (0x1014:0x01BD) and a kernel crash on a machine whose dump device is an ips volume. The audit guest has no such hardware (env.txt).

Contents

VERDICT.md, env.txt, fix.diff, manifest.json, verdict.json.

VERDICT — DF-4616

Status: not_reproduced — requires a morpheus ServeRAID controller as the dump device of a crashing kernel; the audit guest has no ServeRAID hardware (env.txt). The unit mismatch itself is arithmetically certain from the source; the dump-corruption consequence is the likely downstream effect (confidence: certain for the bug, likely for the worst-case consequence).

Trace

• Unit of timeout: ips_issue_morpheus_cmd sets command->timeout = 10 (ips.c:601). ips_timeout runs every 10 * hz (ips.c:369) and decrements each outstanding command's timeout once per run (ips.c:342) → 1 unit ≈ 10 s; the watchdog reaps at ~100 s.
• Unit of the deadline: time_uptime is seconds (kern_clock); so ts = time_uptime + command->timeout (ips.c:611) = now + 10 s.
• Poll exit: (ts > time_uptime) fails after 10 s regardless of command->timeout != 0 (which stays 10: during a crash dump no callouts run to decrement it).

Caller: ipsd_dump_map_sg (ips_disk.c:321-322) — sc->ips_issue_cmd(command); sc->ips_poll_cmd(command); with the kernel dumping (interrupts disabled; ips_copperhead_poll for the other family just prints "not implemented", which is its own statement about how little this path is exercised). After ips_morpheus_poll returns early:

• ipsd_dump_map_sg returns → ipsd_dump treats the block as written;
• the controller may still be mid-transfer when the dump moves on → unacknowledged/interleaved blocks in the crash dump — silent corruption of forensic evidence; or a hang if the dump loop later waits on the same command's completion.

Honest ceiling

Crash-dump integrity on morpheus ServeRAID hardware; not a runtime privilege or memory-safety issue. Low severity, filed because it is a plain arithmetic defect in an evidence-critical path.

Fix

Scale the deadline by the watchdog period: ts = time_uptime + (uint32_t)command->timeout * 10; (and ideally bound the loop regardless). See fix.diff.

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.