Marek Marczykowski-Górecki

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a crash when removing a netfront device directly after a suspend/resume cycle, potentially caused by queues not being set up again. This can be fixed by checking if the queues exist before attempting to stop them. The vulnerability may allow a remote attacker to cause a denial of service. **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 closing of an event channel in the Linux kernel can result in a deadlock. This happens when the close is being performed in parallel to an unrelated Xen console action and the handling of a Xen console interrupt in an unprivileged guest. The closing of an event channel is triggered by removal of a paravirtual device on the other side, which can cause console messages to be issued on the other side quite often, making the chance of triggering the deadlock not neglectable. Note that 32-bit Arm-guests are not affected, as the 32-bit Linux kernel on Arm doesn't use queued-RW-locks, which are required to trigger the issue. **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 versions prior to 5.16.10-1.32.fc32.qubes.x86 64+ #226 **Description** The vulnerability is related to the xen/netfront component of the Linux kernel. It occurs because xennet destroy queues() relies on info->netdev->real num tx queues to delete queues. However, since the update in the unregistration path, unregister netdev() indirectly sets real num tx queues to 0. As a result, xennet destroy queues() called from xennet remove() cannot perform its job because it is called after unregister netdev(). This leads to kfree-ing queues that are still linked in napi, causing a crash due to a kernel NULL pointer dereference. **Recommendations** To resolve this issue, call xennet destroy queues() from xennet uninit() when real num tx queues is still available. This ensures that queues are destroyed when real num tx queues is set to 0, regardless of how unregister netdev() was called. 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 use-after-free error in the iwlwifi module of the Linux kernel. When no firmware is present or all firmware files fail to parse, the device release driver() function is called, leading to the removal of the 'drv' struct. However, the new code still attempts to access the freed struct, causing an error. Setting 'failure=false' can avoid this access. The vulnerability may impact the confidentiality, integrity, and availability of protected information. **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 versions 5.9.x through 5.11.3 **Description** The issue relates to misuse of guest physical addresses when a configuration has CONFIG XEN UNPOPULATED ALLOC but not CONFIG XEN BALLOON MEMORY HOTPLUG, allowing an x86 PV guest OS user to crash a Dom0 or driver domain via a large amount of I/O activity in some less-common configurations. This can lead to a denial of service. **Recommendations** For Linux kernel versions 5.9.x through 5.11.3, consider disabling the `CONFIG XEN UNPOPULATED ALLOC` configuration option or enabling the `CONFIG XEN BALLOON MEMORY HOTPLUG` option as a temporary workaround to minimize the risk of exploitation. 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** Xen versions prior to 4.13 **Description** The issue allows attackers to gain host OS privileges via DMA in a situation where an untrusted domain has access to a physical device. This is due to an incomplete fix for a previous issue. The vulnerability can be exploited when an untrusted domain with access to a physical device can DMA into host memory, leading to privilege escalation. Only systems where guests are given direct access to physical devices capable of DMA (PCI pass-through) are vulnerable. Systems which do not use PCI pass-through are not vulnerable. **Recommendations** For Xen versions prior to 4.13, consider disabling the use of PCI pass-through to minimize the risk of exploitation until a patch is available. Restrict access to physical devices capable of DMA to prevent untrusted domains from accessing them.