Michael Kelley

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.37 **Description** In CoCo VMs, it is possible for the untrusted host to cause `set memory encrypted()` or `set memory decrypted()` to fail, resulting in shared memory. Callers need 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. Checking the `decrypted` field in the `gpadl` can decide whether to free the memory. **Recommendations** To resolve the issue, update to Linux kernel version 6.6.37 or later. As a temporary workaround, consider checking the `decrypted` field in the `gpadl` to decide whether to free the memory, and handle errors from `set memory encrypted()` and `set memory decrypted()` to avoid returning decrypted (shared) memory to the page allocator.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a functional regression in the Linux kernel's swiotlb component, which causes double-allocation of slots due to broken alignment handling. This can lead to buffer corruption and/or a hang when using vsock in a virtual machine with a restricted DMA SWIOTLB pool. The problem occurs because swiotlb alloc() expects a page-aligned allocation but returns a pointer to the 'struct page' corresponding to the allocation, resulting in double-allocation of the first half of the 4KiB page. The issue is resolved by treating the allocation alignment separately from any additional alignment requirements from the device. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** In CoCo VMs, it is possible for the untrusted host to cause `set memory encrypted()` or `set memory decrypted()` to fail, resulting in shared memory. Callers need to handle these errors to avoid returning decrypted 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. Checking the `decrypted` field in the `struct vmbus gpadl` for the ring buffers can help decide whether to free the memory. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a swiotlb bounce buffer leak in confidential VMs. The `storvsc queuecommand()` function maps the scatter/gather list using `scsi dma map()`, which allocates swiotlb bounce buffers in a confidential VM. If the I/O submission fails in `storvsc do io()`, the I/O is typically retried by higher-level code, but the bounce buffer memory is never freed. This can lead to a denial of service, as enough bounce buffer memory leaks can cause the confidential VM to be unable to perform any I/O. The same problem can arise in non-confidential VMs with the kernel boot parameter `swiotlb=force`. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.