CVE-2023-54316
Unknown Unknown - Not Provided
Use-After-Initialization Bug in Linux Kernel refscale Causes Kernel Crash

Publication date: 2025-12-30

Last updated on: 2025-12-30

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: refscale: Fix uninitalized use of wait_queue_head_t Running the refscale test occasionally crashes the kernel with the following error: [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8 [ 8569.952900] #PF: supervisor read access in kernel mode [ 8569.952902] #PF: error_code(0x0000) - not-present page [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0 [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI [ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021 [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 : [ 8569.952940] Call Trace: [ 8569.952941] <TASK> [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale] [ 8569.952959] kthread+0x10e/0x130 [ 8569.952966] ret_from_fork+0x1f/0x30 [ 8569.952973] </TASK> The likely cause is that init_waitqueue_head() is called after the call to the torture_create_kthread() function that creates the ref_scale_reader kthread. Although this init_waitqueue_head() call will very likely complete before this kthread is created and starts running, it is possible that the calling kthread will be delayed between the calls to torture_create_kthread() and init_waitqueue_head(). In this case, the new kthread will use the waitqueue head before it is properly initialized, which is not good for the kernel's health and well-being. The above crash happened here: static inline void __add_wait_queue(...) { : if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash here The offset of flags from list_head entry in wait_queue_entry is -0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_task structure is zero initialized, the instruction will try to access address 0xffffffffffffffe8, which is exactly the fault address listed above. This commit therefore invokes init_waitqueue_head() before creating the kthread.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-30
Last Modified
2025-12-30
Generated
2026-05-07
AI Q&A
2025-12-30
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
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 occurs because a wait queue head is used before it is properly initialized. Specifically, the function init_waitqueue_head() is called after creating a kernel thread (kthread) that uses this wait queue head. If the kthread starts running before the wait queue head is initialized, it can cause the kernel to crash due to accessing invalid memory addresses. The issue arises from a race condition where the kthread may be delayed between its creation and the initialization call, leading to uninitialized use of wait_queue_head_t and resulting in a page fault and kernel crash.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to crash unexpectedly when running the refscale test or similar workloads that trigger this race condition. Such kernel crashes can lead to system instability, downtime, and potential data loss or corruption. It affects the reliability and availability of systems running vulnerable kernel versions.


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

This vulnerability can be detected by monitoring the system kernel logs for crash messages similar to the following: [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8 [ 8569.952900] #PF: supervisor read access in kernel mode [ 8569.952902] #PF: error_code(0x0000) - not-present page [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 You can check kernel logs using commands such as: - dmesg | grep -i 'BUG: unable to handle page fault' - journalctl -k | grep -i 'BUG: unable to handle page fault' These commands help identify if the kernel has crashed due to this issue.


What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation is to apply the patch that ensures init_waitqueue_head() is called before creating the kthread, preventing the uninitialized use of wait_queue_head_t. Until the patch is applied, avoid running the refscale test or any workload that triggers the ref_scale_reader kthread to prevent kernel crashes.


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