CVE-2026-99207 in Linux
Sumário
de VulDB • 28/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
scsi: target: Desativar interrupções enquanto o delayed_cmd_lock estiver sendo mantido
O `target_do_delayed_work()` adquire `dev->delayed_cmd_lock` com um `spin_lock()` simples. Ele é executado no `system_percpu_wq`, portanto, as interrupções permanecem habilitadas enquanto a trava está sendo mantida. Todas as outras aquisições dessa trava usam `spin_lock_irqsave()`: `target_handle_task_attr()` e `transport_complete_ordered_sync()` em `target_core_transport.c`, bem como `target_non_ordered_release()` em `target_core_device.c`.
Isso era seguro enquanto todos os chamadores de `transport_complete_task_attr()` estivessem executando no contexto do processo: `target_complete_ok_work()` a partir do `target_completion_wq`, `transport_complete_qf()` da fila de trabalho `dev->qf_work_queue` e `transport_generic_request_failure()` dos caminhos de envio (submit) e execução.
Desde o commit 06933066d88a ("scsi: target: Adicionar suporte para conclusão de comandos a partir do contexto do backend"), isso já não é mais verdade. Com `complete_type=1` em uma fabric que define `direct_compl_supp`, o `target_complete()` executa `target_complete_ok_work()` inline no contexto de conclusão do backend, o qual `target_complete_cmd_with_sense()` documenta como "Pode ser chamado a partir do contexto de interrupção". Para iblock, esse é o final_io da bio.
O `target_complete_ok_work()` inicia com `transport_complete_task_attr()`, que adquire `delayed_cmd_lock` de duas maneiras:
- Cada comando ORDERED é colocado na lista `dev->delayed_cmd_list` por `target_handle_task_attr()` e despachado a partir daí pelo `target_do_delayed_work()`, que o marca como SCF_TASK_ORDERED_SYNC. Sua conclusão, portanto, passa por `transport_complete_ordered_sync()`.
- Um comando SIMPLE que é concluído enquanto um comando ORDERED está pendente reduz a última referência para o `dev->non_ordered` morto, e o `percpu_ref_put()` então executa `target_non_ordered_release()` no contexto de conclusão.
Ambos adquirem a trava e, se houver comandos aguardando, chamam `schedule_work(&dev->delayed_cmd_work)`, que enfileira no `system_percpu_wq`, ou seja, na CPU que realizou a conclusão. Conclusões adicionais para a mesma fila são tipicamente entregues lá também, portanto, uma chegada enquanto o trabalho mantém a trava gira em loop indefinidamente (spins on it forever).
Alcançar essa situação requer `complete_type=1`, que não é o padrão (vhost-scsi, a única fabric com `direct_compl_supp`, usa por padrão TARGET_QUEUE_COMPL), um backend cuja E/S é concluída no contexto de interrupção e comandos ORDERED vindos do initiator. Os convidados Linux virtio_scsi enviam apenas VIRTIO_SCSI_S_SIMPLE e nunca seguem o caminho ordenado; qualquer convidado que use o atributo de tarefa ORDERED, que vhost-scsi aceita, segue esse caminho.
O `target_do_delayed_work()` é um item de trabalho (work item) e sempre executa no contexto do processo, portanto, `spin_lock_irq()` é suficiente.
Encontrada por inspeção; sem relatório em tempo de execução. Um único comando ORDERED passa pelas duas aquisições, portanto, com CONFIG_PROVE_LOCKING, a primeira conclusão via conclusão direta deve produzir um relatório de estado inconsistente da trava no delayed_cmd_lock (hardirq ou softirq, dependendo de onde o backend conclui).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.