# DF-4425 — VIRTIO_BLK_F_MQ with num_queues=0: modulo-by-zero panic in vtblk_attach

virtio_blk.c:289-298:
    sc->vtblk_nqs = min(blkcfg.num_queues, ncpus);   /* 0 if device says 0 */
    ...
    sc->vtblk_nqs = min(sc->vtblk_nqs, sc->vtblk_nintrs);
virtio_blk.c:323-326:
    for (i = 0; i < ncpus; i++)
        sc->vtblk_vqmap[i] = i % sc->vtblk_nqs;      /* idiv #DE -> panic */

A device that negotiates VIRTIO_BLK_F_MQ (offered by VTBLK_FEATURES) and
reports num_queues = 0 (u32 config field) drives nqs to 0; the first loop
iteration executes 0 % 0 -> integer divide exception -> kernel panic
during attach (boot-time panic when the boot disk does this).

Live verification attempt: QEMU 7.2.22 monitor
    device_add virtio-blk-pci,drive=hd2,id=vtq0,num-queues=0
    -> "Error: num-queues property must be larger than 0"
so mainstream QEMU cannot construct the malicious device; the code path
remains trivially reachable by any other VMM or a crafted/emulated device.
Same malicious-device family as DF-1603/DF-1604; distinct site (MQ path).

Fix: validate blkcfg.num_queues >= 1 when MQ is negotiated (return EINVAL),
or clamp nqs = max(1, ...).