Maximilian Heyne

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A potential deadlock situation can occur in the Linux kernel due to the `io register iowq max workers()` function calling `io put sq data()`, which acquires the `sqd->lock` without releasing the `uring lock`. This issue is similar to a previously addressed commit. To resolve this, the `uring lock` is released before calling `io put sq data()` and then re-acquired after the function call, ensuring locks are acquired in the correct order and preventing a deadlock. **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: A corruption issue has been observed during the on-line resize of a file system larger than 16 TiB with a 4k block size. The issue can be reproduced by explicitly turning off resize inode and performing an on-line resize across an 8 GiB boundary. The corruption occurs at the location of the backup of the meta block group's block descriptor. The fix involves adding a test to determine whether the group to add is already part of the meta block group or not. 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 commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces") **Description** The issue arises from the incorrect lock order in the Linux kernel's xen/events module. Specifically, `shutdown pirq` and `startup pirq` do not take the `irq mapping update lock` due to lock inversion, leading to potential races. For instance, `shutdown pirq` can be interrupted by a function allocating an event channel, causing the `evtchn to irq` mapping to become invalid. Similarly, ` startup pirq` can race with ` unbind from irq`, potentially unsetting the mapping for an allocated event channel. This vulnerability can lead to a kernel BUG during the probing of NVMe devices, particularly when multiple devices are present, increasing the likelihood of hitting the race condition during boot. **Recommendations** To resolve this issue, apply the fix that modifies the internal [un]bind interfaces in the xen/events module, ensuring that the mappings are cleaned up before the event channel is closed. This fix is included in the commit 3fcdaf3d7634. Update the Linux kernel to a version that includes this commit or later to mitigate the vulnerability.