ghsa-jxrr-3gxj-w229
Vulnerability from github
Published
2025-04-01 18:30
Modified
2025-04-01 18:30
Details

In the Linux kernel, the following vulnerability has been resolved:

mm/slab/kvfree_rcu: Switch to WQ_MEM_RECLAIM wq

Currently kvfree_rcu() APIs use a system workqueue which is "system_unbound_wq" to driver RCU machinery to reclaim a memory.

Recently, it has been noted that the following kernel warning can be observed:

workqueue: WQ_MEM_RECLAIM nvme-wq:nvme_scan_work is flushing !WQ_MEM_RECLAIM events_unbound:kfree_rcu_work WARNING: CPU: 21 PID: 330 at kernel/workqueue.c:3719 check_flush_dependency+0x112/0x120 Modules linked in: intel_uncore_frequency(E) intel_uncore_frequency_common(E) skx_edac(E) ... CPU: 21 UID: 0 PID: 330 Comm: kworker/u144:6 Tainted: G E 6.13.2-0_g925d379822da #1 Hardware name: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM20 02/01/2023 Workqueue: nvme-wq nvme_scan_work RIP: 0010:check_flush_dependency+0x112/0x120 Code: 05 9a 40 14 02 01 48 81 c6 c0 00 00 00 48 8b 50 18 48 81 c7 c0 00 00 00 48 89 f9 48 ... RSP: 0018:ffffc90000df7bd8 EFLAGS: 00010082 RAX: 000000000000006a RBX: ffffffff81622390 RCX: 0000000000000027 RDX: 00000000fffeffff RSI: 000000000057ffa8 RDI: ffff88907f960c88 RBP: 0000000000000000 R08: ffffffff83068e50 R09: 000000000002fffd R10: 0000000000000004 R11: 0000000000000000 R12: ffff8881001a4400 R13: 0000000000000000 R14: ffff88907f420fb8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88907f940000(0000) knlGS:0000000000000000 CR2: 00007f60c3001000 CR3: 000000107d010005 CR4: 00000000007726f0 PKRU: 55555554 Call Trace: ? __warn+0xa4/0x140 ? check_flush_dependency+0x112/0x120 ? report_bug+0xe1/0x140 ? check_flush_dependency+0x112/0x120 ? handle_bug+0x5e/0x90 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? timer_recalc_next_expiry+0x190/0x190 ? check_flush_dependency+0x112/0x120 ? check_flush_dependency+0x112/0x120 __flush_work.llvm.1643880146586177030+0x174/0x2c0 flush_rcu_work+0x28/0x30 kvfree_rcu_barrier+0x12f/0x160 kmem_cache_destroy+0x18/0x120 bioset_exit+0x10c/0x150 disk_release.llvm.6740012984264378178+0x61/0xd0 device_release+0x4f/0x90 kobject_put+0x95/0x180 nvme_put_ns+0x23/0xc0 nvme_remove_invalid_namespaces+0xb3/0xd0 nvme_scan_work+0x342/0x490 process_scheduled_works+0x1a2/0x370 worker_thread+0x2ff/0x390 ? pwq_release_workfn+0x1e0/0x1e0 kthread+0xb1/0xe0 ? __kthread_parkme+0x70/0x70 ret_from_fork+0x30/0x40 ? __kthread_parkme+0x70/0x70 ret_from_fork_asm+0x11/0x20 ---[ end trace 0000000000000000 ]---

To address this switch to use of independent WQ_MEM_RECLAIM workqueue, so the rules are not violated from workqueue framework point of view.

Apart of that, since kvfree_rcu() does reclaim memory it is worth to go with WQ_MEM_RECLAIM type of wq because it is designed for this purpose.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-21983"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-01T16:15:29Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slab/kvfree_rcu: Switch to WQ_MEM_RECLAIM wq\n\nCurrently kvfree_rcu() APIs use a system workqueue which is\n\"system_unbound_wq\" to driver RCU machinery to reclaim a memory.\n\nRecently, it has been noted that the following kernel warning can\nbe observed:\n\n\u003csnip\u003e\nworkqueue: WQ_MEM_RECLAIM nvme-wq:nvme_scan_work is flushing !WQ_MEM_RECLAIM events_unbound:kfree_rcu_work\n  WARNING: CPU: 21 PID: 330 at kernel/workqueue.c:3719 check_flush_dependency+0x112/0x120\n  Modules linked in: intel_uncore_frequency(E) intel_uncore_frequency_common(E) skx_edac(E) ...\n  CPU: 21 UID: 0 PID: 330 Comm: kworker/u144:6 Tainted: G            E      6.13.2-0_g925d379822da #1\n  Hardware name: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM20 02/01/2023\n  Workqueue: nvme-wq nvme_scan_work\n  RIP: 0010:check_flush_dependency+0x112/0x120\n  Code: 05 9a 40 14 02 01 48 81 c6 c0 00 00 00 48 8b 50 18 48 81 c7 c0 00 00 00 48 89 f9 48 ...\n  RSP: 0018:ffffc90000df7bd8 EFLAGS: 00010082\n  RAX: 000000000000006a RBX: ffffffff81622390 RCX: 0000000000000027\n  RDX: 00000000fffeffff RSI: 000000000057ffa8 RDI: ffff88907f960c88\n  RBP: 0000000000000000 R08: ffffffff83068e50 R09: 000000000002fffd\n  R10: 0000000000000004 R11: 0000000000000000 R12: ffff8881001a4400\n  R13: 0000000000000000 R14: ffff88907f420fb8 R15: 0000000000000000\n  FS:  0000000000000000(0000) GS:ffff88907f940000(0000) knlGS:0000000000000000\n  CR2: 00007f60c3001000 CR3: 000000107d010005 CR4: 00000000007726f0\n  PKRU: 55555554\n  Call Trace:\n   \u003cTASK\u003e\n   ? __warn+0xa4/0x140\n   ? check_flush_dependency+0x112/0x120\n   ? report_bug+0xe1/0x140\n   ? check_flush_dependency+0x112/0x120\n   ? handle_bug+0x5e/0x90\n   ? exc_invalid_op+0x16/0x40\n   ? asm_exc_invalid_op+0x16/0x20\n   ? timer_recalc_next_expiry+0x190/0x190\n   ? check_flush_dependency+0x112/0x120\n   ? check_flush_dependency+0x112/0x120\n   __flush_work.llvm.1643880146586177030+0x174/0x2c0\n   flush_rcu_work+0x28/0x30\n   kvfree_rcu_barrier+0x12f/0x160\n   kmem_cache_destroy+0x18/0x120\n   bioset_exit+0x10c/0x150\n   disk_release.llvm.6740012984264378178+0x61/0xd0\n   device_release+0x4f/0x90\n   kobject_put+0x95/0x180\n   nvme_put_ns+0x23/0xc0\n   nvme_remove_invalid_namespaces+0xb3/0xd0\n   nvme_scan_work+0x342/0x490\n   process_scheduled_works+0x1a2/0x370\n   worker_thread+0x2ff/0x390\n   ? pwq_release_workfn+0x1e0/0x1e0\n   kthread+0xb1/0xe0\n   ? __kthread_parkme+0x70/0x70\n   ret_from_fork+0x30/0x40\n   ? __kthread_parkme+0x70/0x70\n   ret_from_fork_asm+0x11/0x20\n   \u003c/TASK\u003e\n  ---[ end trace 0000000000000000 ]---\n\u003csnip\u003e\n\nTo address this switch to use of independent WQ_MEM_RECLAIM\nworkqueue, so the rules are not violated from workqueue framework\npoint of view.\n\nApart of that, since kvfree_rcu() does reclaim memory it is worth\nto go with WQ_MEM_RECLAIM type of wq because it is designed for\nthis purpose.",
  "id": "GHSA-jxrr-3gxj-w229",
  "modified": "2025-04-01T18:30:54Z",
  "published": "2025-04-01T18:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21983"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/656e35bf66a11e1adde44c4c12050086dc39f241"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a74979dce9e9c61f6d797c3761020252c4d8dc63"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dfd3df31c9db752234d7d2e09bef2aeabb643ce4"
    }
  ],
  "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.