UBUNTU-CVE-2024-26976
In the Linux kernel, the following vulnerability has been resolved: KVM: Always flush async #PF workqueue when vCPU is being destroyed Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---
02 / AFFECTED SOFTWARE
Affected packages
11 explicit affected versions
31 explicit affected versions
45 explicit affected versions
50 explicit affected versions
6 explicit affected versions
12 explicit affected versions
19 explicit affected versions
6 explicit affected versions
54 explicit affected versions
4 explicit affected versions
40 explicit affected versions
61 explicit affected versions
51 explicit affected versions
40 explicit affected versions
10 explicit affected versions
3 explicit affected versions
47 explicit affected versions
191 explicit affected versions
7 explicit affected versions
46 explicit affected versions
88 explicit affected versions
13 explicit affected versions
85 explicit affected versions
35 explicit affected versions
7 explicit affected versions
14 explicit affected versions
18 explicit affected versions
9 explicit affected versions
118 explicit affected versions
34 explicit affected versions
5 explicit affected versions
90 explicit affected versions
13 explicit affected versions
4 explicit affected versions
121 explicit affected versions
23 explicit affected versions
7 explicit affected versions
1 explicit affected versions
21 explicit affected versions
16 explicit affected versions
10 explicit affected versions
45 explicit affected versions
5 explicit affected versions
7 explicit affected versions
12 explicit affected versions
111 explicit affected versions
38 explicit affected versions
12 explicit affected versions
14 explicit affected versions
7 explicit affected versions
78 explicit affected versions
12 explicit affected versions
93 explicit affected versions
101 explicit affected versions
12 explicit affected versions
89 explicit affected versions
120 explicit affected versions
10 explicit affected versions
10 explicit affected versions
37 explicit affected versions
13 explicit affected versions
10 explicit affected versions
27 explicit affected versions
1 explicit affected versions
31 explicit affected versions
26 explicit affected versions
13 explicit affected versions
144 explicit affected versions
6 explicit affected versions
1 explicit affected versions
29 explicit affected versions
81 explicit affected versions
13 explicit affected versions
51 explicit affected versions
1 explicit affected versions
77 explicit affected versions
49 explicit affected versions
93 explicit affected versions
11 explicit affected versions
33 explicit affected versions
23 explicit affected versions
10 explicit affected versions
188 explicit affected versions
11 explicit affected versions
12 explicit affected versions
7 explicit affected versions
12 explicit affected versions
92 explicit affected versions
138 explicit affected versions
2 explicit affected versions
39 explicit affected versions
32 explicit affected versions
132 explicit affected versions
48 explicit affected versions
165 explicit affected versions
154 explicit affected versions
10 explicit affected versions
26 explicit affected versions
6 explicit affected versions
27 explicit affected versions
1 explicit affected versions
6 explicit affected versions
13 explicit affected versions
5 explicit affected versions
139 explicit affected versions
51 explicit affected versions
16 explicit affected versions
51 explicit affected versions
6 explicit affected versions
40 explicit affected versions
116 explicit affected versions
3 explicit affected versions
93 explicit affected versions
1 explicit affected versions
2 explicit affected versions
58 explicit affected versions
51 explicit affected versions
92 explicit affected versions
3 explicit affected versions
12 explicit affected versions
37 explicit affected versions
27 explicit affected versions
23 explicit affected versions
1 explicit affected versions
1 explicit affected versions
98 explicit affected versions
8 explicit affected versions
12 explicit affected versions
5 explicit affected versions
8 explicit affected versions
1 explicit affected versions
10 explicit affected versions
2 explicit affected versions
13 explicit affected versions
81 explicit affected versions
13 explicit affected versions
45 explicit affected versions
7 explicit affected versions
140 explicit affected versions
94 explicit affected versions
43 explicit affected versions
10 explicit affected versions
12 explicit affected versions
12 explicit affected versions
80 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
13 explicit affected versions
26 explicit affected versions
37 explicit affected versions
37 explicit affected versions
6 explicit affected versions
14 explicit affected versions
38 explicit affected versions
167 explicit affected versions
40 explicit affected versions
9 explicit affected versions
40 explicit affected versions
11 explicit affected versions
48 explicit affected versions
7 explicit affected versions
21 explicit affected versions
97 explicit affected versions
52 explicit affected versions
121 explicit affected versions
4 explicit affected versions
1 explicit affected versions
1 explicit affected versions
46 explicit affected versions
13 explicit affected versions
43 explicit affected versions
46 explicit affected versions
10 explicit affected versions
8 explicit affected versions
1 explicit affected versions
14 explicit affected versions
81 explicit affected versions
4 explicit affected versions
70 explicit affected versions
11 explicit affected versions
1 explicit affected versions
69 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: KVM: Always flush async #PF workqueue when vCPU is being destroyed Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/3d75b8aa5c29058a512db29da7cbee8052724157
- https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724157
- https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce7b4a750
- https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb
- https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac
- https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98
- https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5
- https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff
- https://git.kernel.org/stable/c/caa9af2e27c275e089d702cfbaaece3b42bca31b
- https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264
- https://ubuntu.com/security/CVE-2024-26976
- https://ubuntu.com/security/notices/USN-6816-1
- https://ubuntu.com/security/notices/USN-6817-1
- https://ubuntu.com/security/notices/USN-6817-2
- https://ubuntu.com/security/notices/USN-6817-3
- https://ubuntu.com/security/notices/USN-6878-1
- https://ubuntu.com/security/notices/USN-6896-1
- https://ubuntu.com/security/notices/USN-6896-2
- https://ubuntu.com/security/notices/USN-6896-3
- https://ubuntu.com/security/notices/USN-6896-4
- https://ubuntu.com/security/notices/USN-6896-5
- https://ubuntu.com/security/notices/USN-6898-1
- https://ubuntu.com/security/notices/USN-6898-2
- https://ubuntu.com/security/notices/USN-6898-3
- https://ubuntu.com/security/notices/USN-6898-4
- https://ubuntu.com/security/notices/USN-6917-1
- https://ubuntu.com/security/notices/USN-6919-1
- https://ubuntu.com/security/notices/USN-6927-1
- https://ubuntu.com/security/notices/USN-7019-1
- https://www.cve.org/CVERecord?id=CVE-2024-26976