{"vulnerability": "CVE-2025-21983", "sightings": [{"uuid": "eab2b3c9-94d7-4615-b4d1-5c7b92558cf5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21983", "type": "seen", "source": "https://t.me/cvedetector/21784", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21983 - Linux Kernel - NVMe WQ_MEM_RECLAIM Workqueue Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21983 \nPublished : April 1, 2025, 4:15 p.m. | 1\u00a0hour, 15\u00a0minutes ago \nDescription : 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  \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     \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     \n  ---[ end trace 0000000000000000 ]---  \n  \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. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"01 Apr 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-04-01T19:44:26.000000Z"}]}