CVE-2021-47178 in Linux
Summary
by MITRE • 03/25/2024
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: core: Avoid smp_processor_id() in preemptible code
The BUG message "BUG: using smp_processor_id() in preemptible [00000000]
code" was observed for TCMU devices with kernel config DEBUG_PREEMPT.
The message was observed when blktests block/005 was run on TCMU devices with fileio backend or user:zbc backend [1]. The commit 1130b499b4a7
("scsi: target: tcm_loop: Use LIO wq cmd submission helper") triggered the symptom. The commit modified work queue to handle commands and changed 'current->nr_cpu_allowed' at smp_processor_id() call.
The message was also observed at system shutdown when TCMU devices were not cleaned up [2]. The function smp_processor_id() was called in SCSI host
work queue for abort handling, and triggered the BUG message. This symptom was observed regardless of the commit 1130b499b4a7 ("scsi: target: tcm_loop: Use LIO wq cmd submission helper").
To avoid the preemptible code check at smp_processor_id(), get CPU ID with raw_smp_processor_id() instead. The CPU ID is used for performance improvement then thread move to other CPU will not affect the code.
[1]
[ 56.468103] run blktests block/005 at 2021-05-12 14:16:38
[ 57.369473] check_preemption_disabled: 85 callbacks suppressed
[ 57.369480] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1511
[ 57.369506] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1510
[ 57.369512] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1506
[ 57.369552] caller is __target_init_cmd+0x157/0x170 [target_core_mod]
[ 57.369606] CPU: 4 PID: 1506 Comm: fio Not tainted 5.13.0-rc1+ #34
[ 57.369613] Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 1302 03/15/2018
[ 57.369617] Call Trace:
[ 57.369621] BUG: using smp_processor_id() in preemptible [00000000] code: fio/1507
[ 57.369628] dump_stack+0x6d/0x89
[ 57.369642] check_preemption_disabled+0xc8/0xd0
[ 57.369628] caller is __target_init_cmd+0x157/0x170 [target_core_mod]
[ 57.369655] __target_init_cmd+0x157/0x170 [target_core_mod]
[ 57.369695] target_init_cmd+0x76/0x90 [target_core_mod]
[ 57.369732] tcm_loop_queuecommand+0x109/0x210 [tcm_loop]
[ 57.369744] scsi_queue_rq+0x38e/0xc40
[ 57.369761] __blk_mq_try_issue_directly+0x109/0x1c0
[ 57.369779] blk_mq_try_issue_directly+0x43/0x90
[ 57.369790] blk_mq_submit_bio+0x4e5/0x5d0
[ 57.369812] submit_bio_noacct+0x46e/0x4e0
[ 57.369830] __blkdev_direct_IO_simple+0x1a3/0x2d0
[ 57.369859] ? set_init_blocksize.isra.0+0x60/0x60
[ 57.369880] generic_file_read_iter+0x89/0x160
[ 57.369898] blkdev_read_iter+0x44/0x60
[ 57.369906] new_sync_read+0x102/0x170
[ 57.369929] vfs_read+0xd4/0x160
[ 57.369941] __x64_sys_pread64+0x6e/0xa0
[ 57.369946] ? lockdep_hardirqs_on+0x79/0x100
[ 57.369958] do_syscall_64+0x3a/0x70
[ 57.369965] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 57.369973] RIP: 0033:0x7f7ed4c1399f
[ 57.369979] Code: 08 89 3c 24 48 89 4c 24 18 e8 7d f3 ff ff 4c 8b 54 24 18 48 8b 54 24 10 41 89 c0 48 8b 74 24 08 8b 3c 24 b8 11 00 00 00 0f 05 3d 00 f0 ff ff 77 31 44 89 c7 48 89 04 24 e8 cd f3 ff ff 48 8b
[ 57.369983] RSP: 002b:00007ffd7918c580 EFLAGS: 00000293 ORIG_RAX: 0000000000000011
[ 57.369990] RAX: ffffffffffffffda RBX: 00000000015b4540 RCX: 00007f7ed4c1399f
[ 57.369993] RDX: 0000000000001000 RSI: 00000000015de000 RDI: 0000000000000009
[ 57.369996] RBP: 00000000015b4540 R08: 0000000000000000 R09: 0000000000000001
[ 57.369999] R10: 0000000000e5c000 R11: 0000000000000293 R12: 00007f7eb5269a70
[ 57.370002] R13: 0000000000000000 R14: 0000000000001000 R15: 00000000015b4568
[ 57.370031] CPU: 7 PID: 1507 Comm: fio Not tainted 5.13.0-rc1+ #34
[ 57.370036] Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 1302 03/15/2018
[ 57.370039] Call Trace:
[ 57.370045] dump_stack+0x6d/0x89
[ 57.370056] ch
---truncated---
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/04/2025
The vulnerability described in CVE-2021-47178 resides within the Linux kernel's SCSI target core subsystem, specifically affecting the TCMU (Target Core Modulo Unit) framework. This issue manifests as a kernel BUG message indicating improper usage of the smp_processor_id() function in preemptible code contexts. The problem occurs when running blktests block/005 against TCMU devices configured with either fileio backend or user:zbc backend, and is directly linked to commit 1130b499b4a7 which modified work queue command handling and altered the 'current->nr_cpu_allowed' field during smp_processor_id() calls. The vulnerability is particularly concerning because it can trigger during normal system operations including test execution and system shutdown when TCMU devices are not properly cleaned up, making it a persistent threat to system stability.
The technical root cause of this vulnerability stems from the misuse of kernel functions designed for specific execution contexts. The smp_processor_id() function is intended for use in non-preemptible contexts where the kernel can guarantee that the calling thread will not be migrated between CPUs. However, when this function is invoked within work queue handlers or other preemptible code paths, it violates kernel safety mechanisms designed to prevent race conditions and ensure consistent CPU affinity. The kernel's DEBUG_PREEMPT configuration detects this violation and generates the BUG message to alert developers and administrators to the problematic code path. This behavior directly aligns with CWE-398, which addresses "Indicator of Poor Code Quality" and specifically mentions improper use of kernel functions in incorrect contexts. The call stack shows that the issue originates from __target_init_cmd function within target_core_mod, demonstrating how the problematic function call propagates through the SCSI target subsystem's command initialization pipeline.
The operational impact of this vulnerability extends beyond simple kernel crashes, as it can lead to system instability, unexpected shutdowns, and potential data corruption during I/O operations involving TCMU devices. When the BUG message appears during blktests execution, it indicates that the system is operating in an unsafe state where kernel assumptions about CPU affinity and preemption are violated. During system shutdown, the issue manifests when TCMU devices are not properly torn down, causing abort handling code to invoke smp_processor_id() inappropriately within work queue contexts. This vulnerability affects systems using TCMU with fileio or user:zbc backends, and the risk is heightened in environments where SCSI target functionality is heavily utilized. The presence of this issue in the kernel's core subsystem means that any application or service relying on these SCSI target capabilities could experience unexpected behavior, making this a critical concern for enterprise storage solutions and virtualization platforms that depend on kernel-level I/O handling.
Mitigation strategies for CVE-2021-47178 focus on modifying the kernel source code to replace smp_processor_id() with raw_smp_processor_id() in the affected code paths. This change is necessary because raw_smp_processor_id() does not perform the preemption checks that cause the BUG message, while still providing the required CPU identification functionality for performance optimization purposes. The fix specifically targets the SCSI target core's work queue handling code, ensuring that CPU ID retrieval does not violate kernel preemption safety mechanisms. This solution aligns with ATT&CK technique T1547.001, which involves modifying system boot or startup processes, as it requires kernel-level code modification to address the underlying vulnerability. System administrators should ensure their kernels are updated to versions containing this fix, particularly in production environments where TCMU devices are actively used. Organizations should also consider monitoring for the specific BUG message patterns in kernel logs, as early detection can help prevent system instability and provide insight into potential security implications of kernel-level vulnerabilities. The fix implementation demonstrates the importance of understanding kernel execution contexts and proper function usage in multi-threaded, preemptible environments, as highlighted in the Linux kernel documentation and security best practices.