CVE-2024-50082 in Linux
Summary
by MITRE • 10/29/2024
In the Linux kernel, the following vulnerability has been resolved:
blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race
We're seeing crashes from rq_qos_wake_function that look like this:
BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI
CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ...
So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock).
p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash.
What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this:
rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^
Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue.
The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order.
Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/21/2025
The vulnerability described in CVE-2024-50082 affects the Linux kernel's block request queue quality of service subsystem, specifically within the blk-rq-qos module. This issue manifests as a kernel crash due to a race condition between the functions rq_qos_wait and rq_qos_wake_function, which can lead to a page fault when attempting to access invalid memory addresses. The crash occurs when the kernel attempts to acquire a spinlock on a process structure that has already been freed or modified by another execution path, resulting in a supervisor write access violation that ultimately causes a kernel oops and system instability.
The technical flaw stems from improper synchronization between the waiter and waker functions in the kernel's block I/O subsystem. During normal operation, rq_qos_wait prepares a process to wait on a queue and sets up a waitqueue entry on the stack. When rq_qos_wake_function is invoked, it attempts to wake up the waiting process by calling wake_up_process with a task pointer that was previously stored in the waitqueue entry. However, due to a race condition, the waitqueue entry may have already been removed by the waiter thread before the waker thread attempts to access it, leading to a dereference of freed or corrupted memory. This condition is particularly dangerous because it occurs in kernel space where invalid memory access can result in system crashes or potential privilege escalation.
The operational impact of this vulnerability is significant for Linux systems running affected kernel versions, as it can cause unexpected system crashes and potential denial of service conditions. Systems heavily reliant on block I/O operations, such as servers handling large volumes of disk I/O or storage-intensive applications, are particularly vulnerable to this race condition. The crash pattern indicates that the vulnerability is triggered during concurrent access scenarios involving block request queue management, which can occur during high I/O load conditions or when multiple processes are simultaneously accessing storage resources. The specific error code 0x0002 indicating a not-present page fault and the memory address ff7ffe180a40084 suggest that the kernel is attempting to access memory that has been deallocated or moved, which is a classic symptom of improper synchronization in concurrent systems.
The fix for this vulnerability involves reordering the operations within the rq_qos_wake_function to ensure proper synchronization between the waiter and waker threads. The solution requires changing the order of operations so that the waitqueue entry is deleted before attempting to wake up the process, which aligns with the proper pattern used by autoremove_wake_function. Additionally, using list_del_init_careful() instead of the standard list_del_init() ensures that the check performed in finish_wait() matches the deletion operation, preventing the race condition from occurring. This fix directly addresses the root cause by ensuring that memory access patterns are properly synchronized and that the waitqueue entry is not accessed after it has been removed from the queue. The mitigation strategy aligns with established kernel development practices for handling concurrent access patterns and follows the principles of proper lock ordering and memory synchronization as recommended in various kernel security guidelines and best practices.
This vulnerability can be classified under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, which is a well-known category of race conditions in concurrent systems. The issue also relates to ATT&CK technique T1068: Exploitation for Privilege Escalation, as kernel crashes can potentially be leveraged to gain elevated privileges, though the primary impact here is system stability and availability. The fix demonstrates the importance of careful synchronization in kernel code, particularly when dealing with waitqueue operations and shared data structures, as outlined in various kernel security best practices and the Linux kernel documentation regarding proper waitqueue usage and concurrent access control mechanisms.