Yi Zhang

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a null pointer dereference in the Linux kernel when configuring 'power' and 'submit queues' concurrently, which can trigger a kernel panic. This occurs because del gendisk() can run concurrently with blk mq update nr hw queues(). The problem can be fixed by reusing the global mutex to protect nullb device power store() and nullb update nr hw queues() from configfs. **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 6.6.37 Description: The vulnerability is related to a memory leak in the RDMA/cma component of the Linux kernel. The issue arises when the `rdma put gid attr` function is not called when `sgid attr` is set to `ERR PTR(-ENODEV)`. This can lead to a kernel memory leak, which can be detected by the kernel memory leak detector. The vulnerability can be exploited to cause a denial of service. Recommendations: To resolve the issue, update the Linux kernel to version 6.6.37 or later. This version includes the fix for the RDMA/cma memory leak vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.37 **Description** The issue arises when the multi-devices feature is enabled in the Linux kernel, specifically with the f2fs file system. In this scenario, the `f2fs map blocks()` function may return a zero block address in non-primary devices, which is a valid block address. However, the `f2fs iomap begin()` function treats this as an invalid block address, triggering a warning in the iomap framework code. This warning is caught during the zbd/010 test, which checks for gap zone support with F2FS. The root cause of the issue is the incorrect assumption in `f2fs iomap begin()` about the physical block address of the whole f2fs file system. To fix this issue, a more direct approach is used, checking the `(map.m flags & F2FS MAP MAPPED)` condition instead of `(map.m pblk != NULL ADDR)`. **Recommendations** To resolve this issue, update the Linux kernel to version 6.6.37 or later. As a temporary workaround, consider disabling the multi-devices feature in the f2fs file system until the update can be applied.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to errors in resource management in the blk-mq component of the Linux kernel, specifically in the functions `blk mq get new requests()`, `blk mq get cached request()`, and `blk mq submit bio()`. Exploitation of this issue may allow an attacker to cause a denial of service. The problem arises when `blk integrity unregister()` is called without holding the queue usage counter for a bio with integrity prepared, potentially leading to a kernel panic. It is also noted that `bio integrity prep()` needs to be called before bio merge. **Recommendations** - Call `bio integrity prep()` with one queue usage counter grabbed reliably. - Call `bio integrity prep()` before bio merge. 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 memory leak was found in the Linux kernel's i2c piix4 driver, specifically in the EFCH MMIO support code. The leak occurred because `release resource()` only removes the resource from the tree without freeing its memory, whereas `release mem region()` is required to free the memory. This issue was introduced by the recently added support for EFCH MMIO regions. **Recommendations** To resolve this issue, update the Linux kernel to a version that includes the fix for the memory leak in the i2c piix4 driver. As a temporary workaround, consider applying the patch that replaces `release resource()` with `release mem region()` in the affected code path.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the SCSI host release mechanism in the Linux kernel. When a SCSI device is freed, the SCSI host release is triggered, and it is essential to ensure that the low-level device driver module is not unloaded before the SCSI host instance is released. This is because the `shost->hostt` is required in the release handler. The problem can lead to a kernel panic with the message 'BUG: unable to handle page fault for address'. The issue was reported by Changhui and Yi. **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.12.0-rc3 and earlier **Description** The vulnerability is related to incorrect locking in the state change sk callback of the nvmet-tcp module. This can cause a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state change callbacks on the host and on the controller side have a causal relationship. The issue is reported by lockdep with blktests, indicating an inconsistent lock state. **Recommendations** To resolve this issue, update the Linux kernel to a version that includes the fix for the incorrect locking in the state change sk callback of the nvmet-tcp module. Specifically, versions later than 5.12.0-rc3 should include this fix. If updating is not possible, consider disabling the nvmet-tcp module or restricting its use to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Android versions Kernel-3.18 **Description** The issue is related to an information disclosure vulnerability in the HTC input driver, which could allow a local malicious application to access data outside of its permission levels. This could potentially lead to unauthorized data access. The vulnerability is rated as moderate because it first requires compromising a privileged process. **Recommendations** For Android version Kernel-3.18, consider restricting access to sensitive data until a patch is available. As a temporary workaround, review and limit applications with privileged process access to minimize the risk of exploitation.