CVE-2023-54113
Unknown Unknown - Not Provided
Spinlock Deadlock Vulnerability in Linux Kernel RCU Component

Publication date: 2025-12-24

Last updated on: 2025-12-24

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: rcu: dump vmalloc memory info safely Currently, for double invoke call_rcu(), will dump rcu_head objects memory info, if the objects is not allocated from the slab allocator, the vmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need to be held, since the call_rcu() can be invoked in interrupt context, therefore, there is a possibility of spinlock deadlock scenarios. And in Preempt-RT kernel, the rcutorture test also trigger the following lockdep warning: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 3 locks held by swapper/0/1: #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0 #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370 #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70 irq event stamp: 565512 hardirqs last enabled at (565511): [<ffffffffb379b138>] __call_rcu_common+0x218/0x940 hardirqs last disabled at (565512): [<ffffffffb5804262>] rcu_torture_init+0x20b2/0x2370 softirqs last enabled at (399112): [<ffffffffb36b2586>] __local_bh_enable_ip+0x126/0x170 softirqs last disabled at (399106): [<ffffffffb43fef59>] inet_register_protosw+0x9/0x1d0 Preemption disabled at: [<ffffffffb58040c3>] rcu_torture_init+0x1f13/0x2370 CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xb0 dump_stack+0x14/0x20 __might_resched+0x1aa/0x280 ? __pfx_rcu_torture_err_cb+0x10/0x10 rt_spin_lock+0x53/0x130 ? find_vmap_area+0x1f/0x70 find_vmap_area+0x1f/0x70 vmalloc_dump_obj+0x20/0x60 mem_dump_obj+0x22/0x90 __call_rcu_common+0x5bf/0x940 ? debug_smp_processor_id+0x1b/0x30 call_rcu_hurry+0x14/0x20 rcu_torture_init+0x1f82/0x2370 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_init+0x10/0x10 do_one_initcall+0x6c/0x300 ? debug_smp_processor_id+0x1b/0x30 kernel_init_freeable+0x2b9/0x540 ? __pfx_kernel_init+0x10/0x10 kernel_init+0x1f/0x150 ret_from_fork+0x40/0x50 ? __pfx_kernel_init+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> The previous patch fixes this by using the deadlock-safe best-effort version of find_vm_area. However, in case of failure print the fact that the pointer was a vmalloc pointer so that we print at least something.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-24
Last Modified
2025-12-24
Generated
2026-05-07
AI Q&A
2025-12-24
EPSS Evaluated
2026-05-05
NVD
CVE-2023-54113
EUVD
EUVD-2023-60332
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 6.5.0-rc4-rt2-yocto-preempt-rt
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel involves a potential spinlock deadlock scenario when the call_rcu() function is invoked twice. Specifically, if rcu_head objects are not allocated from the slab allocator, the vmalloc_dump_obj() function is called, which requires holding the vmap_area_lock spinlock. Since call_rcu() can be called in interrupt context, this can lead to a deadlock. The issue also triggers lockdep warnings in the Preempt-RT kernel during rcutorture tests. The fix involves using a deadlock-safe, best-effort version of find_vm_area and printing a message if the pointer is a vmalloc pointer to avoid deadlocks while still providing debug information.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to deadlock due to spinlock contention when call_rcu() is invoked in certain contexts, potentially leading to system hangs or crashes. This can affect system stability and reliability, especially in real-time or interrupt-driven environments where call_rcu() is used. Such deadlocks can disrupt normal operation and may require system reboot or intervention.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing kernel logs for specific lockdep warnings and BUG messages related to spinlock deadlocks and invalid context calls, especially those triggered by the rcutorture test in Preempt-RT kernels. Monitoring kernel messages for lines similar to 'BUG: sleeping function called from invalid context' and spinlock deadlock traces involving vmap_area_lock and call_rcu() can indicate the presence of this issue. Using kernel debugging tools like dmesg or journalctl to check for these messages is recommended.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves applying the patch that uses the deadlock-safe best-effort version of find_vm_area to avoid spinlock deadlocks. Until the patch is applied, avoid running workloads or tests (such as rcutorture) that trigger call_rcu() in interrupt context leading to this deadlock scenario. Monitoring and updating the Linux kernel to a version that includes this fix is essential.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart