Ye Bin

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.61 Description: The issue is related to a wild-memory-access in the proto unregister function of the Bluetooth BNEP module. The problem occurs because bnep init() ignores the return value of bnep sock init(), which cleans up all resources. When the bnep module is removed, bnep sock cleanup() is called to clean up the socket's resources, leading to a potential wild-memory-access. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited. Recommendations: For Linux kernel versions prior to 6.6.61, update to version 6.6.61 or later to resolve the issue. As a temporary workaround, consider modifying the bnep exit() function to return the return value of bnep sock init() to prevent the wild-memory-access. Restrict access to the vulnerable BNEP module to minimize the risk of exploitation. Avoid using the BNEP module until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A use-after-free vulnerability has been resolved in the Linux kernel. The issue occurs in the `bfad im module exit()` function, where a double release is triggered when `bfad im module init()` fails. This can lead to a slab-use-after-free error in the ` lock acquire()` function. The vulnerability is caused by the `bfad im module exit()` function being called even when `bfad im module init()` fails, resulting in a double release of the `fc release transport()` function. **Recommendations** To resolve the issue, ensure that `bfad im module exit()` is not called when `bfad im module init()` fails. This can be achieved by modifying the `bfad init()` function to only call `bfad im module exit()` when `bfad im module init()` is successful. 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 occurs when concurrently installing the f2fs.ko module and mounting the f2fs file system, resulting in a null-ptr-deref in the `f2fs submit page bio()` function. This happens because the biset of the f2fs file system is not initialized before registering `f2fs fs type`. The problem can be addressed by registering `f2fs fs type` at the end of `init f2fs fs()` and ensuring that all f2fs file system resources are initialized. **Recommendations** To resolve the issue, register `f2fs fs type` at the last in `init f2fs fs()`. Ensure that all f2fs file system resources are initialized. As a temporary workaround, consider disabling the `f2fs submit page bio()` function until a patch is available. Restrict access to the vulnerable `f2fs` module to minimize the risk of exploitation. Avoid using the `f2fs.ko` module in the affected API endpoint until the issue is resolved. 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** A potential memory leak in the Linux kernel has been resolved. The issue occurs in the `vfio intx enable()` function when `vfio irq ctx alloc()` fails, leading to a memory leak of the `name` variable. **Recommendations** Update to Linux kernel version 6.6.37 or later to resolve the issue. As a temporary workaround, consider restricting access to the `vfio intx enable()` function until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 5.10.0+ **Description** A use-after-free issue has been identified in the ext4 rename dir prepare function of the Linux kernel. This issue arises when the first directory entry's 'rec len' is 34478, resulting in an illegal parent entry. The problem occurs because the directory entry is not checked after reading the directory block in 'ext4 get first dir block'. The estimated number of potentially affected devices is not provided, and there is no information about real-world incidents where this issue was exploited. **Recommendations** To resolve this issue, check the directory entry in 'ext4 get first dir block' to prevent the use-after-free error. As a temporary workaround, consider disabling the `ext4 rename dir prepare` function until a patch is available. However, the provided information does not specify a fixed version, so the recommendation is to update to a version where this issue has been resolved, but the exact version is not specified. 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 an out-of-bound read in the `resp readcap16()` function. This can lead to a denial of service. The problem arises when the `alloc len` value is set to -1104926854, causing a huge `arr len` to be passed to `fill from dev buffer()`, but the `arr` is only 32 bytes, resulting in an out-of-bounds (OOB) condition in `sg copy buffer()`. To solve this issue, it is recommended to define `alloc len` as `u32`. **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 vulnerability has been resolved in the Linux kernel, specifically in the ext4 file system. The issue occurs when the file system is remounted read-only, causing a race condition where the kmmpd thread can exit and point to freed memory, which can be tripped over by the call to `ext4 stop mmpd()`. This is fixed by only allowing the kmmpd thread to exit when it is stopped via `ext4 stop mmpd()`. **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 bug has been fixed in the Linux kernel's ext4 file system, specifically in the `ext4 es cache extent` function, which is called by `ext4 split extent at`. The issue occurs when running `fsstress` with injected IO faults, resulting in a kernel bug and internal error. The call trace includes functions such as `ext4 es cache extent`, `ext4 cache extents`, `ext4 find extent`, and `ext4 ext map blocks`. The patch modification is based on a suggestion by Jan Kara to properly fix the extent tree in case of ENOSPC and EDQUOT errors, which can be easily triggered by users. **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 the commit 014c9caa29d3 **Description** The issue is related to the ext4 file system in the Linux kernel. Before commit 014c9caa29d3, a series of commands could trigger a panic. The commands include mounting a file system with the "errors=panic" option and then remounting it with the "abort" option. After the commit, remounting with the "abort" option no longer triggers a panic. However, this change also introduces a new behavior where a different series of commands will cause a panic, which previously did not. The commands that now cause a panic include mounting with "errors=panic" and then writing to a specific file system trigger. This change makes the ext4 behavior more consistent. **Recommendations** To resolve the issue, update the Linux kernel to a version that includes the commit 014c9caa29d3 or later. As a temporary workaround, consider avoiding the use of the "errors=panic" and "abort" mount options together until a patch is available. Restrict access to the file system trigger to minimize the risk of exploitation.