Yu Kuai

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The current directory offset allocator stores the next offset value to return in `octx->next offset`. This mechanism typically returns values that increase monotonically over time. Eventually, though, the newly allocated offset value wraps back to a low number, which is smaller than other already-allocated offset values. After a specific commit, if a directory's offset allocator wraps, existing entries are no longer visible via `readdir/getdents` because `offset readdir()` stops listing entries once an entry's offset is larger than `octx->next offset`. These entries vanish persistently and can be looked up, but will never again appear in `readdir(3)` output. The reason for this is that the commit treats directory offsets as monotonically increasing integer values rather than opaque cookies. On 64-bit platforms, the directory offset value upper bound is 2^63 - 1, while on 32-bit platforms, LONG MAX is 2^31 - 1, and the allocator can wrap after only a few weeks. **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 **Description** A use-after-free vulnerability has been identified in the Linux kernel, specifically in the block, bfq module. The issue arises when the `bfq limit depth()` function dereferences `bfqq` from `bic` without proper locking, potentially leading to a use-after-free condition if the `io context` is shared among multiple tasks. This vulnerability can be triggered, for example, by testing bfq with `io uring` in version 6.6 of the Linux kernel. The vulnerability is related to the `bfqq group` function and can cause a slab-use-after-free error. **Recommendations** To resolve this issue, protect the `bic to bfqq()` function with `bfqd->lock`. This will prevent the use-after-free condition by ensuring that access to `bfqq` from `bic` is properly synchronized. Note: The provided information does not specify a fixed version for the vulnerability. Therefore, it is recommended to update to the latest version of the Linux kernel to ensure you have the latest security patches.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6 **Description** A use-after-free vulnerability has been identified in the Linux kernel, specifically in the block layer. The issue arises when the `blk mq clear flush rq mapping()` function is not called during the SCSI probe, leading to a situation where the `QUEUE FLAG INIT DONE` flag is cleared, causing a use-after-free error in the `blk mq find and get req()` function. This vulnerability can be exploited by an attacker to potentially gain elevated privileges or cause a denial-of-service condition. **Recommendations** To resolve this issue, update the Linux kernel to a version that includes the fix for this vulnerability. Specifically, for Linux kernel version 6.6, ensure that the patch for this issue is applied. If the patch is not available, consider disabling the affected functionality or restricting access to the vulnerable component as a temporary workaround. Note: The provided information does not include specific guidance on how to apply the patch or update the kernel. It is recommended to follow the standard procedure for updating the Linux kernel on your system.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a use-after-free vulnerability in the block and bfq components of the Linux kernel. After a specific commit, if the current process is the last holder of `bfqq`, it can be freed, leading to potential unauthorized access and exploitation. The vulnerability may allow an attacker to impact the confidentiality, integrity, and availability of protected information. The problem is fixed by adding a helper function `bfq waker bfqq()` to check if `bfqq->waker bfqq` is in the merge chain and the current process is the only holder. **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 module reference leakage from the bdev open by dev error path in the Linux kernel. When `bdev may open()` is called, a module reference is grabbed, and it should be released if `bdev may open()` fails. This problem was found through code review. **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 potential deadlock in the Linux kernel for raid456 has been identified. The issue occurs when a reshape is interrupted, and a disk is set to WantReplacement, with a new disk added to the array. The recovery process won't start until the reshape is finished, and an IO across the reshape position will wait for the reshape to make progress. Meanwhile, md start sync() finds a spare disk that can be added to the configuration, and mddev suspend() is called, leading to a deadlock. This problem was found by code review and has not been reproduced yet. The fix involves not suspending the array for interrupted reshape, which is safe because the configuration won't be changed until the reshape is done. **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.14.0+ **Description** A race condition exists between the `nbd alloc config()` function and the removal of the nbd module. When the nbd module is being removed, `nbd alloc config()` may be called concurrently by `nbd genl connect()`, leading to a potential leak of `nbd config` and its related resources, such as `recv workq`. This can cause a kernel NULL pointer dereference and an oops in `nbd read stat()` due to the unload of the nbd module. **Recommendations** For Linux kernel versions prior to 5.14.0+, update to a newer version that includes the fix for the race condition between `nbd alloc config()` and module removal. As a temporary workaround, consider disabling the `nbd` module until a patch is available. Restrict access to the `nbd` module to minimize the risk of exploitation. Avoid using the `nbd genl connect()` function in conjunction with the `nbd alloc config()` function until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 5.14.0-rc4 **Description** A race condition exists between module removal and the handling of netlink commands in the Linux kernel, which can lead to a kernel NULL pointer dereference. This issue is related to the `nbd` module and can cause an oops error, as shown in the provided stack trace. The error occurs when `genl unregister family()` is not called before `nbd cleanup()`, allowing for a potential race condition. **Recommendations** For Linux kernel versions prior to 5.14.0-rc4, consider updating to a newer version that includes the fix for this issue. As a temporary workaround, ensure that `genl unregister family()` is called before `nbd cleanup()` to prevent the race condition.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 5.18.0-rc3-next-20220422-00003-g2176915513ca **Description** A vulnerability in the Linux kernel has been identified, which can cause an io hung when disconnecting a device. This issue is triggered by "qemu-nbd" and can lead to a blocked task. The problem arises from the inability to clear requests after a commit, resulting in requests not being completed due to a timeout. The issue is related to the `nbd clear sock ioctl()` function and the `NBD CMD INFLIGHT` flag. **Recommendations** For Linux kernel versions prior to 5.18.0-rc3-next-20220422-00003-g2176915513ca, switch back to calling `nbd clear sock()` in `nbd clear sock ioctl()` to allow inflight requests to be cleared.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 5.17.0-rc4-next-20220217+ **Description** The issue is related to a use-after-free vulnerability in the blktrace component of the Linux kernel. This vulnerability can be triggered when tracing the whole disk, and 'dropped' and 'msg' files are created under 'q->debugfs dir' with 'bt->dir' being NULL, thus blk trace free() won't remove those files. As a result, accessing stale 'dropped' and 'msg' can lead to a use-after-free (UAF) condition. The vulnerability may allow an attacker to impact the confidentiality, integrity, and availability of protected information. **Recommendations** To resolve this issue, update the Linux kernel to a version that includes the fix for the blktrace use-after-free vulnerability, which is at least version 5.17.0-rc4-next-20220217+. As a temporary workaround, consider disabling the blktrace functionality until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 4.19.90-yk #5 **Description** A use-after-free issue has been identified in the Linux kernel, specifically in the block, bfq module. The issue arises from the ` bfq put async bfqq` function, which can lead to a write of size 8 at an address that has already been freed. This can cause a system crash or potentially allow an attacker to execute arbitrary code. The vulnerability is related to the `bfq put async queues` and `bfq pd offline` functions. **Recommendations** For Linux kernel version 4.19.90-yk #5 and earlier, update to a newer version that contains a fix for this issue. 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 the block layer in the Linux kernel, where the `rq qos ops->done bio` function is called even when the bio isn't tracked. This can lead to a potential kernel panic. The `rq qos` framework is only applied to request-based drivers, and `rq qos done bio()` doesn't need to be called for bio-based drivers or bios that aren't tracked. In `bio endio()`, the request queue is referred to via `bio->bi bdev->bd disk->queue`, which may be gone since the request queue refcount may not be held. Additionally, `q->rq qos` may be freed in `blk cleanup queue()` when calling into ` rq qos done bio()`. The fix is to not call `rq qos ops->done bio` if the bio isn't tracked, which is safe because both `ioc rqos done bio()` and `blkcg iolatency done bio()` are no-ops if the bio isn't tracked. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.