UBUNTU-CVE-2024-50082
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 <f0> 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: <IRQ> 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().
02 / AFFECTED SOFTWARE
Affected packages
11 explicit affected versions
41 explicit affected versions
57 explicit affected versions
50 explicit affected versions
6 explicit affected versions
12 explicit affected versions
19 explicit affected versions
6 explicit affected versions
67 explicit affected versions
19 explicit affected versions
52 explicit affected versions
72 explicit affected versions
60 explicit affected versions
53 explicit affected versions
10 explicit affected versions
11 explicit affected versions
17 explicit affected versions
59 explicit affected versions
7 explicit affected versions
58 explicit affected versions
14 explicit affected versions
99 explicit affected versions
13 explicit affected versions
85 explicit affected versions
16 explicit affected versions
35 explicit affected versions
19 explicit affected versions
19 explicit affected versions
18 explicit affected versions
18 explicit affected versions
118 explicit affected versions
41 explicit affected versions
19 explicit affected versions
101 explicit affected versions
13 explicit affected versions
4 explicit affected versions
23 explicit affected versions
24 explicit affected versions
1 explicit affected versions
1 explicit affected versions
21 explicit affected versions
16 explicit affected versions
10 explicit affected versions
56 explicit affected versions
20 explicit affected versions
7 explicit affected versions
12 explicit affected versions
111 explicit affected versions
1 explicit affected versions
50 explicit affected versions
12 explicit affected versions
14 explicit affected versions
7 explicit affected versions
1 explicit affected versions
88 explicit affected versions
12 explicit affected versions
104 explicit affected versions
112 explicit affected versions
12 explicit affected versions
14 explicit affected versions
99 explicit affected versions
15 explicit affected versions
11 explicit affected versions
6 explicit affected versions
10 explicit affected versions
37 explicit affected versions
1 explicit affected versions
13 explicit affected versions
12 explicit affected versions
10 explicit affected versions
34 explicit affected versions
1 explicit affected versions
37 explicit affected versions
26 explicit affected versions
13 explicit affected versions
12 explicit affected versions
1 explicit affected versions
29 explicit affected versions
92 explicit affected versions
13 explicit affected versions
64 explicit affected versions
13 explicit affected versions
14 explicit affected versions
1 explicit affected versions
87 explicit affected versions
59 explicit affected versions
104 explicit affected versions
22 explicit affected versions
33 explicit affected versions
23 explicit affected versions
10 explicit affected versions
1 explicit affected versions
11 explicit affected versions
12 explicit affected versions
7 explicit affected versions
12 explicit affected versions
102 explicit affected versions
138 explicit affected versions
50 explicit affected versions
44 explicit affected versions
132 explicit affected versions
60 explicit affected versions
154 explicit affected versions
10 explicit affected versions
26 explicit affected versions
18 explicit affected versions
37 explicit affected versions
1 explicit affected versions
10 explicit affected versions
23 explicit affected versions
13 explicit affected versions
19 explicit affected versions
139 explicit affected versions
62 explicit affected versions
16 explicit affected versions
63 explicit affected versions
22 explicit affected versions
51 explicit affected versions
116 explicit affected versions
3 explicit affected versions
93 explicit affected versions
1 explicit affected versions
1 explicit affected versions
2 explicit affected versions
69 explicit affected versions
51 explicit affected versions
92 explicit affected versions
7 explicit affected versions
20 explicit affected versions
12 explicit affected versions
47 explicit affected versions
27 explicit affected versions
34 explicit affected versions
1 explicit affected versions
1 explicit affected versions
98 explicit affected versions
15 explicit affected versions
8 explicit affected versions
24 explicit affected versions
5 explicit affected versions
8 explicit affected versions
1 explicit affected versions
10 explicit affected versions
18 explicit affected versions
13 explicit affected versions
91 explicit affected versions
13 explicit affected versions
55 explicit affected versions
7 explicit affected versions
140 explicit affected versions
2 explicit affected versions
94 explicit affected versions
52 explicit affected versions
10 explicit affected versions
12 explicit affected versions
15 explicit affected versions
91 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
13 explicit affected versions
26 explicit affected versions
45 explicit affected versions
37 explicit affected versions
23 explicit affected versions
14 explicit affected versions
38 explicit affected versions
167 explicit affected versions
52 explicit affected versions
9 explicit affected versions
51 explicit affected versions
11 explicit affected versions
13 explicit affected versions
7 explicit affected versions
60 explicit affected versions
7 explicit affected versions
33 explicit affected versions
63 explicit affected versions
121 explicit affected versions
4 explicit affected versions
1 explicit affected versions
1 explicit affected versions
1 explicit affected versions
58 explicit affected versions
13 explicit affected versions
43 explicit affected versions
57 explicit affected versions
10 explicit affected versions
8 explicit affected versions
17 explicit affected versions
14 explicit affected versions
92 explicit affected versions
4 explicit affected versions
78 explicit affected versions
11 explicit affected versions
1 explicit affected versions
69 explicit affected versions
14 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
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 <f0> 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: <IRQ> 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().
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/e972b08b91ef48488bae9789f03cfedb148667fb
- https://git.kernel.org/stable/c/04f283fc16c8d5db641b6bffd2d8310aa7eccebc
- https://git.kernel.org/stable/c/3bc6d0f8b70a9101456cf02ab99acb75254e1852
- https://git.kernel.org/stable/c/455a469758e57a6fe070e3e342db12e4a629e0eb
- https://git.kernel.org/stable/c/4c5b123ab289767afe940389dbb963c5c05e594e
- https://git.kernel.org/stable/c/b5e900a3612b69423a0e1b0ab67841a1fb4af80f
- https://git.kernel.org/stable/c/e972b08b91ef48488bae9789f03cfedb148667fb
- https://ubuntu.com/security/CVE-2024-50082
- https://ubuntu.com/security/notices/USN-7276-1
- https://ubuntu.com/security/notices/USN-7277-1
- https://ubuntu.com/security/notices/USN-7288-1
- https://ubuntu.com/security/notices/USN-7288-2
- https://ubuntu.com/security/notices/USN-7289-1
- https://ubuntu.com/security/notices/USN-7289-2
- https://ubuntu.com/security/notices/USN-7289-3
- https://ubuntu.com/security/notices/USN-7289-4
- https://ubuntu.com/security/notices/USN-7291-1
- https://ubuntu.com/security/notices/USN-7293-1
- https://ubuntu.com/security/notices/USN-7294-1
- https://ubuntu.com/security/notices/USN-7294-2
- https://ubuntu.com/security/notices/USN-7294-3
- https://ubuntu.com/security/notices/USN-7294-4
- https://ubuntu.com/security/notices/USN-7295-1
- https://ubuntu.com/security/notices/USN-7305-1
- https://ubuntu.com/security/notices/USN-7308-1
- https://ubuntu.com/security/notices/USN-7310-1
- https://ubuntu.com/security/notices/USN-7331-1
- https://ubuntu.com/security/notices/USN-7383-1
- https://ubuntu.com/security/notices/USN-7383-2
- https://ubuntu.com/security/notices/USN-7384-1
- https://ubuntu.com/security/notices/USN-7384-2
- https://ubuntu.com/security/notices/USN-7385-1
- https://ubuntu.com/security/notices/USN-7386-1
- https://ubuntu.com/security/notices/USN-7388-1
- https://ubuntu.com/security/notices/USN-7389-1
- https://ubuntu.com/security/notices/USN-7390-1
- https://ubuntu.com/security/notices/USN-7393-1
- https://ubuntu.com/security/notices/USN-7401-1
- https://ubuntu.com/security/notices/USN-7403-1
- https://ubuntu.com/security/notices/USN-7413-1
- https://ubuntu.com/security/notices/USN-7451-1
- https://ubuntu.com/security/notices/USN-7458-1
- https://ubuntu.com/security/notices/USN-7468-1
- https://ubuntu.com/security/notices/USN-7523-1
- https://ubuntu.com/security/notices/USN-7524-1
- https://ubuntu.com/security/notices/USN-7539-1
- https://ubuntu.com/security/notices/USN-7540-1
- https://www.cve.org/CVERecord?id=CVE-2024-50082