CVE-2023-52791 in Linux
Summary
by MITRE • 05/21/2024
In the Linux kernel, the following vulnerability has been resolved:
i2c: core: Run atomic i2c xfer when !preemptible
Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is disabled. However, non-atomic i2c transfers require preemption (e.g. in wait_for_completion() while waiting for the DMA).
panic() calls preempt_disable_notrace() before calling emergency_restart(). Therefore, if an i2c device is used for the restart, the xfer should be atomic. This avoids warnings like:
[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0
[ 12.676926] Voluntary context switch within RCU read-side critical section!
... [ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114
[ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70
... [ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58
[ 13.001050] machine_restart from panic+0x2a8/0x32c
Use !preemptible() instead, which is basically the same check as pre-v5.2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2025
This vulnerability resides within the Linux kernel's i2c subsystem, specifically addressing a critical flaw in how i2c transfers are handled when preemption is disabled. The issue emerged from changes made in commit bae1d3a05a8b where i2c transfers were modified to become non-atomic when preemption is disabled. However, this change created an inconsistency because non-atomic i2c transfers inherently require preemption mechanisms to function properly, particularly during DMA operations that rely on wait_for_completion() calls. The problem becomes evident when emergency system restarts occur, as the panic() function invokes preempt_disable_notrace() before calling emergency_restart(), creating a scenario where i2c transfers must remain atomic to prevent system instability.
The technical flaw manifests when the kernel attempts to perform i2c transfers during system panic conditions, specifically when emergency restart mechanisms are triggered. During these critical moments, the system enters a state where preemption is disabled, yet the i2c subsystem attempts to execute non-atomic operations that depend on preemptive scheduling for proper completion. This creates a direct conflict with RCU (Read-Copy-Update) subsystem operations, as evidenced by the kernel warnings showing voluntary context switches within RCU read-side critical sections. The error trace demonstrates the chain of function calls leading to system instability, starting from rcu_note_context_switch through schedule_timeout and wait_for_completion_timeout to ultimately reach machine_restart and panic functions, all while attempting to complete i2c transfers that require preemptive capabilities.
The operational impact of this vulnerability extends beyond simple kernel warnings to potentially cause system panics and complete system failures during critical error recovery scenarios. When an i2c device is used for emergency restart operations, the non-atomic transfer behavior can trigger kernel oops messages and system crashes, particularly affecting embedded systems and hardware platforms that rely heavily on i2c communication for system management functions. This vulnerability directly affects systems where i2c devices are used for power management, hardware monitoring, or emergency restart capabilities, making it particularly dangerous in production environments where system reliability is paramount. The issue becomes more pronounced in ARM-based systems and embedded platforms that utilize Tegra i2c controllers, as demonstrated by the specific function calls in the error trace.
The fix implemented addresses this by reverting to the pre-v5.2 check using !preemptible() instead of the problematic preemption state detection. This approach ensures that i2c transfers maintain atomic behavior whenever preemption is not available, preventing the kernel from entering inconsistent states during emergency operations. The solution aligns with established kernel security practices and follows the principle of least privilege by ensuring that critical system operations maintain proper synchronization mechanisms regardless of the preemption state. This change effectively resolves the conflict between i2c subsystem requirements and RCU subsystem behavior, preventing the warnings and potential system crashes that occurred during emergency restart scenarios. The fix demonstrates proper adherence to kernel design principles and maintains backward compatibility while addressing the specific edge case where preemption is disabled during critical system operations.
This vulnerability maps directly to CWE-362, which describes a race condition that occurs due to improper synchronization, and aligns with ATT&CK technique T1490, specifically targeting system destruction through kernel-level manipulation. The issue represents a classic case of improper resource management where atomic operations are required but not properly enforced during system recovery operations. The fix maintains the kernel's integrity by ensuring proper synchronization mechanisms are preserved even when preemption is disabled, which is crucial for maintaining system stability in embedded and real-time environments where emergency restart capabilities are essential for system recovery.