![](/assets/img/cve_300x82_sin_bg.png)
CVE-2024-36912 – Drivers: hv: vmbus: Track decrypted status in vmbus_gpadl
https://notcve.org/view.php?id=CVE-2024-36912
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Track decrypted status in vmbus_gpadl In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. In order to make sure callers of vmbus_establish_gpadl() and vmbus_teardown_gpadl() don't return decrypted/shared pages to allocators, add a field in struct vmbus_gpadl to keep track of the decryption status of the buffers. This will allow the callers to know if they should free or leak the pages. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: vmbus: Seguimiento del estado descifrado en vmbus_gpadl En máquinas virtuales CoCo, es posible que el host que no es de confianza provoque que set_memory_encrypted() o set_memory_decrypted() falle de manera que se devuelva un error y la memoria resultante se comparte. Las personas que llaman deben tener cuidado al manejar estos errores para evitar devolver memoria descifrada (compartida) al asignador de páginas, lo que podría provocar problemas funcionales o de seguridad. • https://git.kernel.org/stable/c/1999644d95194d4a58d3e80ad04ce19220a01a81 https://git.kernel.org/stable/c/8e62341f5c45b27519b7d193bcc32ada416ad9d8 https://git.kernel.org/stable/c/bfae56be077ba14311509e70706a13458f87ea99 https://git.kernel.org/stable/c/211f514ebf1ef5de37b1cf6df9d28a56cfd242ca • CWE-1258: Exposure of Sensitive System Information Due to Uncleared Debug Information •
![](/assets/img/cve_300x82_sin_bg.png)
CVE-2024-36911 – hv_netvsc: Don't free decrypted memory
https://notcve.org/view.php?id=CVE-2024-36911
In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Don't free decrypted memory In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The netvsc driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hv_netvsc: no liberar memoria descifrada. En las máquinas virtuales CoCo, es posible que el host que no es de confianza provoque que set_memory_encrypted() o set_memory_decrypted() falle, de modo que se devuelva un error y el resultado La memoria es compartida. • https://git.kernel.org/stable/c/a56fe611326332bf6b7126e5559590c57dcebad4 https://git.kernel.org/stable/c/4aaed9dbe8acd2b6114458f0498a617283d6275b https://git.kernel.org/stable/c/bbf9ac34677b57506a13682b31a2a718934c0e31 •
![](/assets/img/cve_300x82_sin_bg.png)
CVE-2024-36910 – uio_hv_generic: Don't free decrypted memory
https://notcve.org/view.php?id=CVE-2024-36910
In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Don't free decrypted memory In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The VMBus device UIO driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: uio_hv_generic: no liberar memoria descifrada. En las máquinas virtuales CoCo, es posible que el host que no es de confianza provoque que set_memory_encrypted() o set_memory_decrypted() falle, de modo que se devuelva un error y el resultado La memoria es compartida. • https://git.kernel.org/stable/c/dabf12bf994318d939f70d47cfda30e47abb2c54 https://git.kernel.org/stable/c/6466a0f6d235c8a18c602cb587160d7e49876db9 https://git.kernel.org/stable/c/fe2c58602354fbd60680dc42ac3a0b772cda7d23 https://git.kernel.org/stable/c/3d788b2fbe6a1a1a9e3db09742b90809d51638b7 • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •
![](/assets/img/cve_300x82_sin_bg.png)
CVE-2024-36909 – Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encrypted
https://notcve.org/view.php?id=CVE-2024-36909
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encrypted In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The VMBus ring buffer code could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the struct vmbus_gpadl for the ring buffers to decide whether to free the memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: vmbus: no liberar búferes de anillo que no se pudieron volver a cifrar. En las máquinas virtuales CoCo, es posible que el host que no es de confianza cause set_memory_encrypted() o set_memory_decrypted( ) falle de modo que se devuelva un error y se comparta la memoria resultante. • https://git.kernel.org/stable/c/2f622008bf784a9f5dd17baa19223cc2ac30a039 https://git.kernel.org/stable/c/82f9e213b124a7d2bb5b16ea35d570260ef467e0 https://git.kernel.org/stable/c/a9212a4e2963a7fbe3864ba33dc551d4ad8d0abb https://git.kernel.org/stable/c/30d18df6567be09c1433e81993e35e3da573ac48 •
![](/assets/img/cve_300x82_sin_bg.png)
CVE-2024-36908 – blk-iocost: do not WARN if iocg was already offlined
https://notcve.org/view.php?id=CVE-2024-36908
In the Linux kernel, the following vulnerability has been resolved: blk-iocost: do not WARN if iocg was already offlined In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-iocost: no ADVERTIR si iocg ya estaba desconectado. En iocg_pay_debt(), se activa una advertencia si 'active_list' está vacía, lo que pretende confirmar que iocg está activo cuando deuda. • https://git.kernel.org/stable/c/1c172ac7afe4442964f4153b2c78fe4e005d9d67 https://git.kernel.org/stable/c/14b3275f93d4a0d8ddc02195bc4e9869b7a3700e https://git.kernel.org/stable/c/01bc4fda9ea0a6b52f12326486f07a4910666cf6 •