CVSS: 7.0EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26976 – KVM: Always flush async #PF workqueue when vCPU is being destroyed
https://notcve.org/view.php?id=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. • https://git.kernel.org/stable/c/af585b921e5d1e919947c4b1164b59507fe7cd7b https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5 https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264 https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98 https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce • CWE-400: Uncontrolled Resource Consumption •
CVSS: 5.8EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26974 – crypto: qat - resolve race condition during AER recovery
https://notcve.org/view.php?id=CVE-2024-26974
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - resolve race condition during AER recovery During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: qat: resuelve la condición de ejecución durante la recuperación de AER Durante el proceso de recuperación de errores del sistema PCI AER, el controlador del kernel puede encontrar una condición de ejecución al liberar la memoria de la estructura reset_data. Si el reinicio del dispositivo demora más de 10 segundos, la función que programa el reinicio se cerrará debido a un tiempo de espera y se liberará la estructura reset_data. • https://git.kernel.org/stable/c/d8cba25d2c68992a6e7c1d329b690a9ebe01167d https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7 https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81 https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71 https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7 https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26973 – fat: fix uninitialized field in nostale filehandles
https://notcve.org/view.php?id=CVE-2024-26973
In the Linux kernel, the following vulnerability has been resolved: fat: fix uninitialized field in nostale filehandles When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fat: corrige el campo no inicializado en los identificadores de archivos notale Cuando fat_encode_fh_nostale() codifica el identificador de archivo sin un padre, almacena solo los primeros 10 bytes del identificador de archivo. • https://git.kernel.org/stable/c/ea3983ace6b79c96e6ab3d3837e2eaf81ab881e2 https://git.kernel.org/stable/c/9840d1897e28f8733cc1e38f97e044f987dc0a63 https://git.kernel.org/stable/c/f52d7663a10a1266a2d3871a6dd8fd111edc549f https://git.kernel.org/stable/c/a276c595c3a629170b0f052a3724f755d7c6adc6 https://git.kernel.org/stable/c/b7fb63e807c6dadf7ecc1d43448c4f1711d7eeee https://git.kernel.org/stable/c/c8cc05de8e6b5612b6e9f92c385c1a064b0db375 https://git.kernel.org/stable/c/03a7e3f2ba3ca25f1da1d3898709a08db14c1abb https://git.kernel.org/stable/c/74f852654b8b7866f15323685f1e178d3 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26972 – ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
https://notcve.org/view.php?id=CVE-2024-26972
In the Linux kernel, the following vulnerability has been resolved: ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think. • https://git.kernel.org/stable/c/2c58d548f5706d085c4b009f6abb945220460632 https://git.kernel.org/stable/c/3faea7810e2b3e9a9a92ef42d7e5feaeb8ff7133 https://git.kernel.org/stable/c/62b5ae00c2b835639002ce898ccb5d82c51073ae https://git.kernel.org/stable/c/6379b44cdcd67f5f5d986b73953e99700591edfa •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26970 – clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays
https://notcve.org/view.php?id=CVE-2024-26970
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: gcc-ipq6018: corrección de terminación de matrices de tablas de frecuencia Se supone que las matrices de tablas de frecuencia terminan con un elemento vacío. Agregue dicha entrada al final de las matrices donde falta para evitar un posible acceso fuera de los límites cuando la tabla es atravesada por funciones como qcom_find_freq() o qcom_find_freq_floor(). Solo compilar probado. • https://git.kernel.org/stable/c/d9db07f088af01a1080d01de363141b673c7d646 https://git.kernel.org/stable/c/ae60e3342296f766f88911d39199f77b05f657a6 https://git.kernel.org/stable/c/b4527ee3de365a742215773d20f07db3e2c06f3b https://git.kernel.org/stable/c/852db52b45ea96dac2720f108e7c7331cd3738bb https://git.kernel.org/stable/c/421b135aceace99789c982f6a77ce9476564fb52 https://git.kernel.org/stable/c/dcb13b5c9ae8743f99a96f392186527c3df89198 https://git.kernel.org/stable/c/db4066e3ab6b3d918ae2b92734a89c04fe82cc1d https://git.kernel.org/stable/c/cdbc6e2d8108bc47895e5a901cfcaf799 • CWE-125: Out-of-bounds Read •