ghsa-72rq-7p7f-9f9j
Vulnerability from github
Published
2025-09-15 15:31
Modified
2025-09-15 15:31
Details

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/

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-53231"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-15T15:15:50Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: Fix detection of atomic context\n\nCurrent check for atomic context is not sufficient as\nz_erofs_decompressqueue_endio can be called under rcu lock\nfrom blk_mq_flush_plug_list(). See the stacktrace [1]\n\nIn such case we should hand off the decompression work for async\nprocessing rather than trying to do sync decompression in current\ncontext. Patch fixes the detection by checking for\nrcu_read_lock_any_held() and while at it use more appropriate\n!in_task() check than in_atomic().\n\nBackground: Historically erofs would always schedule a kworker for\ndecompression which would incur the scheduling cost regardless of\nthe context. But z_erofs_decompressqueue_endio() may not always\nbe in atomic context and we could actually benefit from doing the\ndecompression in z_erofs_decompressqueue_endio() if we are in\nthread context, for example when running with dm-verity.\nThis optimization was later added in patch [2] which has shown\nimprovement in performance benchmarks.\n\n==============================================\n[1] Problem stacktrace\n[name:core\u0026]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291\n[name:core\u0026]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi\n[name:core\u0026]preempt_count: 0, expected: 0\n[name:core\u0026]RCU nest depth: 1, expected: 0\nCPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S      W  OE      6.1.25-android14-5-maybe-dirty-mainline #1\nHardware name: MT6897 (DT)\nCall trace:\n dump_backtrace+0x108/0x15c\n show_stack+0x20/0x30\n dump_stack_lvl+0x6c/0x8c\n dump_stack+0x20/0x48\n __might_resched+0x1fc/0x308\n __might_sleep+0x50/0x88\n mutex_lock+0x2c/0x110\n z_erofs_decompress_queue+0x11c/0xc10\n z_erofs_decompress_kickoff+0x110/0x1a4\n z_erofs_decompressqueue_endio+0x154/0x180\n bio_endio+0x1b0/0x1d8\n __dm_io_complete+0x22c/0x280\n clone_endio+0xe4/0x280\n bio_endio+0x1b0/0x1d8\n blk_update_request+0x138/0x3a4\n blk_mq_plug_issue_direct+0xd4/0x19c\n blk_mq_flush_plug_list+0x2b0/0x354\n __blk_flush_plug+0x110/0x160\n blk_finish_plug+0x30/0x4c\n read_pages+0x2fc/0x370\n page_cache_ra_unbounded+0xa4/0x23c\n page_cache_ra_order+0x290/0x320\n do_sync_mmap_readahead+0x108/0x2c0\n filemap_fault+0x19c/0x52c\n __do_fault+0xc4/0x114\n handle_mm_fault+0x5b4/0x1168\n do_page_fault+0x338/0x4b4\n do_translation_fault+0x40/0x60\n do_mem_abort+0x60/0xc8\n el0_da+0x4c/0xe0\n el0t_64_sync_handler+0xd4/0xfc\n el0t_64_sync+0x1a0/0x1a4\n\n[2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/",
  "id": "GHSA-72rq-7p7f-9f9j",
  "modified": "2025-09-15T15:31:29Z",
  "published": "2025-09-15T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53231"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/12d0a24afd9ea58e581ea64d64e066f2027b28d9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/597fb60c75132719687e173b75cab8f6eb1ca657"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.