CVE-2026-99207

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: Disable interrupts while holding delayed cmd lock

target do delayed work() takes dev->delayed cmd lock with a plain spin lock(). It runs from system percpu wq, so interrupts stay enabled while the lock is held. Every other acquisition of that lock uses spin lock irqsave(): target handle task attr() and transport complete ordered sync() in target core transport.c, and target non ordered release() in target core device.c.

That was safe while every caller of transport complete task attr() ran in process context: target complete ok work() from target completion wq, transport complete qf() from dev->qf work queue, and transport generic request failure() from the submit and execute paths.

Since commit 06933066d88a ("scsi: target: Add support for completing commands from backend context") that is no longer true. With complete type=1 on a fabric that sets direct compl supp, target complete() runs target complete ok work() inline in the backend's completion context, which target complete cmd with sense() documents as "May be called from interrupt context". For iblock that is the bio end io.

target complete ok work() starts with transport complete task attr(), which takes delayed cmd lock in two ways:

Both take the lock and, if commands are waiting, call schedule work(&dev->delayed cmd work), which queues on system percpu wq, i.e. on the CPU that took the completion. Further completions for the same queue are typically delivered there too, so one arriving while the work holds the lock spins on it forever.

Reaching this needs complete type=1, which is not the default (vhost-scsi, the only fabric with direct compl supp, defaults to TARGET QUEUE COMPL), a backend whose I/O completes from interrupt context, and ORDERED commands from the initiator. Linux virtio scsi guests send only VIRTIO SCSI S SIMPLE and never take the ordered path; any guest that uses the ORDERED task attribute, which vhost-scsi accepts, does.

target do delayed work() is a work item and always runs in process context, so spin lock irq() is sufficient.

Found by inspection; no runtime report. A single ORDERED command goes through both acquisitions, so with CONFIG PROVE LOCKING the first one completed through direct completion should produce an inconsistent lock state report on delayed cmd lock (hardirq or softirq, depending on where the backend completes).