CVE-2023-53216
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-15

Last updated on: 2025-12-03

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: arm64: efi: Make efi_rt_lock a raw_spinlock Running a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs the following: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by kworker/u320:0/9: #0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #1: ffff80000861bdd0 ((work_completion)(&efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) Preemption disabled at: efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248) CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G W 6.2.0-rc3-rt1 Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18 Workqueue: efi_rts_wq efi_call_rts Call trace: dump_backtrace (arch/arm64/kernel/stacktrace.c:158) show_stack (arch/arm64/kernel/stacktrace.c:165) dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) dump_stack (lib/dump_stack.c:114) __might_resched (kernel/sched/core.c:10134) rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4)) efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) [...] This seems to come from commit ff7a167961d1 ("arm64: efi: Execute runtime services from a dedicated stack") which adds a spinlock. This spinlock is taken through: efi_call_rts() \-efi_call_virt() \-efi_call_virt_pointer() \-arch_efi_call_virt_setup() Make 'efi_rt_lock' a raw_spinlock to avoid being preempted. [ardb: The EFI runtime services are called with a different set of translation tables, and are permitted to use the SIMD registers. The context switch code preserves/restores neither, and so EFI calls must be made with preemption disabled, rather than only disabling migration.]
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-15
Last Modified
2025-12-03
Generated
2026-05-07
AI Q&A
2025-09-15
EPSS Evaluated
2026-05-05
NVD
CVE-2023-53216
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.10.165 (inc) to 5.10.175 (exc)
linux linux_kernel From 5.15.90 (inc) to 5.15.103 (exc)
linux linux_kernel From 6.1.8 (inc) to 6.1.18 (exc)
linux linux_kernel From 6.2 (inc) to 6.2.5 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-NVD-CWE-noinfo
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves the Linux kernel on arm64 architecture where the efi_rt_lock was not implemented as a raw_spinlock. This caused issues when calling EFI runtime services, which require preemption to be disabled due to their use of different translation tables and SIMD registers. The problem led to a BUG triggered by a sleeping function being called from an invalid context, causing kernel instability. The fix was to make efi_rt_lock a raw_spinlock to properly disable preemption during EFI runtime service calls.


How can this vulnerability impact me? :

This vulnerability can cause kernel instability or crashes when EFI runtime services are called on affected arm64 Linux kernels. It may result in BUG messages and potentially disrupt system operation, especially on systems using real-time kernels and EFI runtime services, leading to reliability issues.


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 BUG messages related to sleeping functions called from invalid contexts involving efi_rt_lock. You can check the kernel log using commands like 'dmesg | grep -i efi_rt_lock' or 'journalctl -k | grep -i efi_rt_lock' to find traces of the BUG message and related stack traces indicating the issue.


What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation is to update the Linux kernel to a version that includes the fix, which makes efi_rt_lock a raw_spinlock to avoid preemption issues. Until then, avoid running the vulnerable kernel version (6.2.0-rc3-rt1) on affected hardware, or disable EFI runtime services if possible.


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