scsi: target: Disable interrupts while holding delayed_cmd_lock
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: - Every ORDERED command is put on dev->delayed_cmd_list by target_handle_task_attr() and dispatched from there by target_do_delayed_work(), which marks it SCF_TASK_ORDERED_SYNC. Its completion therefore goes
- Products
- Linux
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-99207
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 1 Nov 2026, 02:45 UTC · Revision 1
Source evidence
scsi: target: Disable interrupts while holding delayed_cmd_lock
core-cve · Original sourcePublished 28 Oct 2026, 10:36 UTC
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: - Every ORDERED command is put on dev->delayed_cmd_list by target_handle_task_attr() and dispatched from there by target_do_delayed_work(), which marks it SCF_TASK_ORDERED_SYNC. Its completion therefore goes
cve:CVE-2026-99207
Linux
Fixed versions: Not specified
Linux
Fixed versions: Not specified
Complete source record
{
"id": "bdbe17df200ca78166b9d492da99ffea8b52937f95883837c52e49741622d8b6",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-99207",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "scsi: target: Disable interrupts while holding delayed_cmd_lock",
"summary": "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: - Every ORDERED command is put on dev->delayed_cmd_list by target_handle_task_attr() and dispatched from there by target_do_delayed_work(), which marks it SCF_TASK_ORDERED_SYNC. Its completion therefore goes",
"evidence": "cve:CVE-2026-99207",
"products": [
{
"name": {
"value": "Linux",
"evidence": "/containers/cna/affected/0/product"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": []
},
{
"name": {
"value": "Linux",
"evidence": "/containers/cna/affected/1/product"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-99207",
"aliases": [
"CVE-2026-99207"
],
"metrics": [],
"affected": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "06933066d88a3093953b062922c016a67d2cdbf8",
"lessThan": "7563650522732041ccfb2e4593878b5ea98d498c",
"versionType": "git"
},
{
"status": "affected",
"version": "06933066d88a3093953b062922c016a67d2cdbf8",
"lessThan": "04a67a8b1a4460345d22fe75d93430cbf7e651d7",
"versionType": "git"
}
],
"programFiles": [
"drivers/target/target_core_transport.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "7.1"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "7.1",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "7.2.13",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"drivers/target/target_core_transport.c"
],
"defaultStatus": "affected"
}
],
"modified": "2026-10-28T10:36:00.728Z",
"provider": "cve",
"references": [
"https://git.kernel.org/stable/c/7563650522732041ccfb2e4593878b5ea98d498c",
"https://git.kernel.org/stable/c/04a67a8b1a4460345d22fe75d93430cbf7e651d7"
],
"provider_metadata": {
"cna": {
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux",
"dateUpdated": "2026-10-28T10:36:00.728Z"
}
}
},
"related_cves": [
{
"value": "CVE-2026-99207",
"evidence": "/cveMetadata/cveId"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-cve",
"document_id": 425377,
"published_at": "2026-10-28T10:36:00.728+00:00"
}