CVE-2023-53231 in Linux
Summary
by MITRE • 09/15/2025
In the Linux kernel, the following vulnerability has been resolved:
erofs: Fix detection of atomic context
Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1]
In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic().
Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown
improvement in performance benchmarks.
============================================== [1] Problem stacktrace
[name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291
[name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi
[name:core&]preempt_count: 0, expected: 0
[name:core&]RCU nest depth: 1, expected: 0
CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4
[2] Link: https://lore.kernel.org/all/[email protected]/
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 01/11/2026
The vulnerability CVE-2023-53231 affects the Linux kernel's erofs (embedded read-only file system) implementation and stems from an insufficient detection mechanism for atomic context during decompression operations. This flaw manifests when the function z_erofs_decompressqueue_endio is invoked under an RCU lock context through blk_mq_flush_plug_list(), which creates a scenario where synchronous decompression attempts are made in an environment where sleeping functions cannot be safely executed. The issue directly relates to improper context checking that fails to account for RCU read lock states, leading to potential system instability and kernel oops conditions. The root cause lies in the use of in_atomic() which does not adequately detect all non-sleeping contexts, particularly those involving RCU locks that are not properly identified by the existing detection logic. This vulnerability is classified under CWE-362, which deals with concurrent execution using shared resources without proper synchronization mechanisms, and aligns with ATT&CK technique T1059.003 for kernel-level code injection and execution.
The technical implementation flaw occurs within the decompression subsystem where the kernel attempts to optimize performance by performing decompression work directly in the calling context when possible, rather than always scheduling it for a kworker. This optimization was introduced to reduce scheduling overhead but has become problematic when the context checking logic fails to recognize when the current execution environment prohibits synchronous operations. The stack trace reveals a clear path of execution from blk_mq_flush_plug_list through bio_endio to z_erofs_decompressqueue_endio, where the system attempts to acquire a mutex lock while already within an RCU context that does not allow sleeping operations. This results in a kernel BUG triggered by __might_sleep() function that detects the invalid context for sleeping function calls, specifically when the system attempts to acquire a mutex while in atomic context. The fix addresses this by incorporating rcu_read_lock_any_held() checks to properly identify when RCU locks are active and ensuring that decompression work is properly offloaded to asynchronous processing rather than attempting synchronous operations in inappropriate contexts.
The operational impact of this vulnerability is significant for systems utilizing erofs with dm-verity or similar cryptographic verification mechanisms, where the file system may be under heavy I/O load with plug flushing operations. Systems running with high concurrency or those performing frequent read operations on compressed file systems may experience kernel panics, system hangs, or data corruption scenarios when the decompression logic encounters the problematic atomic context conditions. The vulnerability particularly affects embedded systems and mobile platforms where the kernel's RCU mechanisms are heavily utilized for performance optimization, and where dm-verity verification is common. The performance implications extend beyond immediate system stability, as the improper handling of decompression contexts can cause cascading failures in I/O subsystems and lead to degraded user experience or complete system lockups. The vulnerability demonstrates a critical flaw in kernel subsystem context management and highlights the importance of proper synchronization primitives in high-performance kernel code.
Mitigation strategies for this vulnerability involve applying the kernel patch that enhances context detection by implementing proper rcu_read_lock_any_held() checks and utilizing more appropriate !in_task() checks instead of the generic in_atomic() function. System administrators should prioritize updating to kernel versions that include this fix, particularly those that have addressed the RCU context detection issue in the erofs subsystem. Organizations deploying systems with erofs and dm-verity should conduct thorough testing of their kernel configurations to ensure that decompression operations are properly handled under various I/O and locking conditions. Additionally, monitoring systems should be enhanced to detect potential kernel oops or BUG conditions related to mutex acquisition in atomic contexts, as early detection can prevent system crashes. The fix aligns with best practices for kernel development and follows the principle of defensive programming by ensuring that all kernel subsystems properly validate their execution contexts before attempting operations that may cause system instability. Regular kernel security updates and proper testing of kernel modifications are essential to maintain system integrity and prevent exploitation of similar context-related vulnerabilities in other kernel subsystems.