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.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: 9EXPL: 0CVE-2024-26965 – clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays
https://notcve.org/view.php?id=CVE-2024-26965
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-msm8974: 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: mmcc-msm8974: 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/d8b212014e69d6b6323773ce6898f224ef4ed0d6 https://git.kernel.org/stable/c/99740c4791dc8019b0d758c5389ca6d1c0604d95 https://git.kernel.org/stable/c/86bf75d9158f511db7530bc82a84b19a5134d089 https://git.kernel.org/stable/c/3ff4a0f6a8f0ad4b4ee9e908bdfc3cacb7be4060 https://git.kernel.org/stable/c/8f562f3b25177c2055b20fd8cf000496f6fa9194 https://git.kernel.org/stable/c/537040c257ab4cd0673fbae048f3940c8ea2e589 https://git.kernel.org/stable/c/7e9926fef71e514b4a8ea9d11d5a84d52b181362 https://git.kernel.org/stable/c/ae99e199037c580b7350bfa3596f447a5 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26962 – dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape
https://notcve.org/view.php?id=CVE-2024-26962
In the Linux kernel, the following vulnerability has been resolved: dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape For raid456, if reshape is still in progress, then IO across reshape position will wait for reshape to make progress. However, for dm-raid, in following cases reshape will never make progress hence IO will hang: 1) the array is read-only; 2) MD_RECOVERY_WAIT is set; 3) MD_RECOVERY_FROZEN is set; After commit c467e97f079f ("md/raid6: use valid sector values to determine if an I/O should wait on the reshape") fix the problem that IO across reshape position doesn't wait for reshape, the dm-raid test shell/lvconvert-raid-reshape.sh start to hang: [root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0>] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [<0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [<0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [<0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [<0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 This is because reshape can't make progress. For md/raid, the problem doesn't exist because register new sync_thread doesn't rely on the IO to be done any more: 1) If array is read-only, it can switch to read-write by ioctl/sysfs; 2) md/raid never set MD_RECOVERY_WAIT; 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'. However, I'm not sure yet how to avoid the problem in dm-raid yet. This patch on the one hand make sure raid_message() can't change sync_thread() through raid_message() after presuspend(), on the other hand detect the above 3 cases before wait for IO do be done in dm_suspend(), and let dm-raid requeue those IO. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm-raid456, md/raid456: soluciona un punto muerto para dm-raid456 mientras io concurre con reshape. Para raid456, si el reshape todavía está en progreso, entonces IO en la posición de reshape esperará remodelar para progresar. • https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1 https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304 https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26961 – mac802154: fix llsec key resources release in mac802154_llsec_key_del
https://notcve.org/view.php?id=CVE-2024-26961
In the Linux kernel, the following vulnerability has been resolved: mac802154: fix llsec key resources release in mac802154_llsec_key_del mac802154_llsec_key_del() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llsec_lookup_key() is traversing the list of keys in parallel with a key deletion: refcount_t: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Call Trace: <TASK> llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_encrypt+0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Also, ieee802154_llsec_key_entry structures are not freed by mac802154_llsec_key_del(): unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0 [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0 [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0 [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440 [<ffffffff86ff1d88>] genl_rcv+0x28/0x40 [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820 [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60 [<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0 [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 Handle the proper resource release in the RCU callback function mac802154_llsec_key_del_rcu(). Note that if llsec_lookup_key() finds a key, it gets a refcount via llsec_key_get() and locally copies key id from key_entry (which is a list element). So it's safe to call llsec_key_put() and free the list entry after the RCU grace period elapses. Found by Linux Verification Center (linuxtesting.org). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac802154: corrige la liberación de recursos de clave llsec en mac802154_llsec_key_del mac802154_llsec_key_del() puede liberar recursos de una clave directamente sin seguir las reglas de RCU para esperar antes del final de un período de gracia. Esto puede llevar a un use-after-free en caso de que llsec_lookup_key() esté recorriendo la lista de claves en paralelo con una eliminación de clave: refcount_t: suma en 0; use-after-free. • https://git.kernel.org/stable/c/5d637d5aabd85132bd85779677d8acb708e0ed90 https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531 https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821 https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88 https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1 https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b • CWE-459: Incomplete Cleanup •