CVE-2023-53231: erofs: Fix detection of atomic context
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/20210317035448.13921-1-huangjianan@oppo.com/
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel availability issue in EROFS decompression. In some local read paths, the kernel may try work that can sleep while it is under an RCU lock, causing an invalid-context failure. The practical concern is denial of service, not data theft or data modification.
Executive priority
Handle through normal kernel patch management with moderate priority. Raise priority for Android, embedded, appliance, or fleet systems that rely on EROFS and have local multi-user or workload isolation exposure.
Technical view
z_erofs_decompressqueue_endio() can be reached from blk_mq_flush_plug_list() while an RCU read lock is held. The prior atomic-context check missed that state, allowing synchronous decompression that may take a mutex. The fix detects RCU-held and non-task contexts and hands decompression to async processing.
Likely exposure
Exposure is most relevant to affected Linux kernels using compressed EROFS paths. The CVSS vector is local, low-privilege, no user interaction, unchanged scope, with high availability impact and no stated confidentiality or integrity impact.
Exploitation context
The source bundle does not cite active exploitation, public exploit availability, or CISA KEV listing. It describes a kernel bug path and stack trace. Treat this as a local denial-of-service risk unless vendor advisories provide additional evidence.
Researcher notes
Evidence is limited to the CVE record, kernel description, CVSS, and stable commit references. The affected-version listing is not fully explained in the bundle, so validate downstream kernel status through vendor advisories rather than assuming all kernels in a broad range are affected.
Mitigation direction
Update to a kernel or vendor build containing the referenced stable fixes.
Check Linux distribution, Android, or appliance vendor guidance for backported patches.
Prioritize systems that use EROFS or compressed EROFS images.
If patching is delayed, reduce untrusted local user access on affected systems.
Monitor vendor advisories for affected version clarification and operational workarounds.
Validation and detection
Inventory kernel versions and vendor patch levels on Linux systems.
Identify systems mounting or booting from EROFS file systems.
Confirm whether referenced stable commits or downstream backports are present.
Review crash logs for invalid-context or EROFS decompression warnings.
Run existing regression tests after kernel updates on EROFS-dependent devices.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-53231 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.