CVE-2021-47178 is a vulnerability in the Linux kernel related to improper use of the smp_processor_id() function within preemptible code sections in the SCSI target core module (target_core_mod). Specifically, the issue arises when smp_processor_id() is called in contexts where preemption is enabled, such as in TCMU (Target Core Modular Userspace) devices using fileio or user:zbc backends, and during system shutdown when TCMU devices are not properly cleaned up. The kernel BUG message "BUG: using smp_processor_id() in preemptible code" is triggered in these scenarios, indicating a violation of kernel preemption rules. The root cause is that smp_processor_id() is not safe to call in preemptible code because it can lead to inconsistent CPU ID readings if the thread is rescheduled on another CPU. The vulnerability was introduced or triggered by a commit (1130b499b4a7) that modified work queue command handling and altered CPU affinity checks. The fix involves replacing smp_processor_id() with raw_smp_processor_id(), which retrieves the CPU ID without preemption checks, thus avoiding the BUG message. This change is safe because the CPU ID is used only for performance optimizations, and thread migration between CPUs does not affect correctness. The vulnerability manifests as kernel BUG messages and potential instability or crashes in affected systems, particularly when running block device tests or during shutdown sequences involving TCMU devices. Although no direct exploit code or known exploits in the wild have been reported, the issue can cause system reliability problems and may impact storage-related workloads relying on the Linux SCSI target framework.

For European organizations, especially those operating data centers, cloud infrastructure, or storage solutions based on Linux servers, this vulnerability could lead to system instability or crashes in environments using TCMU devices or SCSI target modules. This is particularly relevant for organizations deploying advanced storage virtualization or block device emulation using the Linux kernel's target core modules. Unplanned kernel BUGs can cause service interruptions, data access delays, or require system reboots, impacting availability and operational continuity. While the vulnerability does not directly expose confidentiality or integrity risks, the resulting instability could indirectly affect business operations, SLAs, and customer trust. Organizations with high-density Linux server deployments or those using custom kernel configurations with DEBUG_PREEMPT enabled for debugging or performance tuning are more susceptible. The lack of known exploits reduces immediate risk, but the potential for denial-of-service through kernel panics or crashes remains a concern. Additionally, the complexity of the Linux kernel and the specialized nature of the affected code path means that only a subset of Linux users are impacted, but those that are may experience significant operational disruption.

To mitigate this vulnerability, European organizations should: 1) Apply the official Linux kernel patches that replace smp_processor_id() with raw_smp_processor_id() in the target_core_mod and related modules as soon as they become available in their Linux distribution or kernel version. 2) Avoid running kernel configurations with DEBUG_PREEMPT enabled in production environments unless necessary for debugging, as this increases the likelihood of triggering the BUG message. 3) Conduct thorough testing of storage-related workloads, especially those involving TCMU devices or SCSI target modules, after kernel updates to ensure stability. 4) Implement robust monitoring for kernel BUG messages and system logs to detect early signs of this issue. 5) Ensure proper cleanup and shutdown procedures for TCMU devices to prevent residual states that trigger the bug. 6) Coordinate with Linux distribution vendors to receive timely updates and security advisories related to this vulnerability. 7) For critical systems, consider isolating or limiting the use of affected kernel modules until patches are applied. These steps go beyond generic advice by focusing on kernel configuration management, workload-specific testing, and operational monitoring tailored to the vulnerability's context.