Baokun Li

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A memory leak issue has been identified in the Linux kernel, specifically in the jffs2 file system. The leak occurs when `jffs2 iget()` or `d make root()` in `jffs2 do fill super()` returns an error, causing unreferenced objects to remain in memory. This issue is resolved by calling `jffs2 sum exit()` to release the allocated resources. **Recommendations** To resolve this issue, ensure that `jffs2 sum exit()` is called to release resources allocated in `jffs2 sum init()` when an error occurs in `jffs2 do fill super()`. As a temporary workaround, consider implementing error handling to release resources properly in case of errors during the `jffs2 do fill super()` function. 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 issue has been identified in the Linux kernel, specifically in the jffs2 file system. The leak occurs when the `jffs2 build filesystem()` function in `jffs2 do mount fs()` returns an error, causing unreleased resources allocated in `jffs2 sum init()`. This results in a memory leak, as evidenced by kmemleak reports. The issue can be resolved by calling `jffs2 sum exit()` to release the allocated resources. **Recommendations** To resolve the issue, call `jffs2 sum exit()` to release the resources allocated in `jffs2 sum init()` when `jffs2 build filesystem()` returns an error. 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 issue has been identified in the jffs2 file system. The leak occurs when an error is returned in `jffs2 scan eraseblock()` and some memory has been added to the `jffs2 summary *s`. This can lead to memory leaks, as observed in the kmemleak report. The issue is caused by the failure to release the memory added in `s` when an error occurs. To fix this, `jffs2 sum reset collected(s)` should be called on exit to release the memory. Additionally, a new tag "out buf" is added to prevent NULL pointer references. **Recommendations** To resolve the issue, call `jffs2 sum reset collected(s)` on exit to release the memory added in `s`. As a temporary workaround, consider disabling the `jffs2 scan medium()` function until a patch is available. Restrict access to the `jffs2` file system 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: Linux kernel versions prior to 6.6.58 Description: The issue is related to the ext4 file system in the Linux kernel, where a vulnerability in the ext4 ext try to merge up() function can cause a double release of a buffer, potentially leading to memory corruption and other issues. This can occur when the function is called with a specific set of circumstances, such as when the path->p depth is 0 and the ext4 split extent at function is called. The vulnerability can be triggered by a series of events, including the ext4 ext map blocks, ext4 ext handle unwritten extents, and ext4 split convert extents functions. The estimated number of potentially affected devices is not specified. Recommendations: For Linux kernel versions prior to 6.6.58, update to version 6.6.58 or later to resolve the issue. As a temporary workaround, consider restricting access to the vulnerable ext4 file system until a patch is available. Avoid using the `path[1].p bh` variable in the affected API endpoint until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: The issue is related to a use-after-free vulnerability in the ext4 file system, specifically in the `ext4 ext show leaf()` function. This vulnerability can be triggered when `EXT DEBUG` is defined, but it does not affect the functionality of the system. The problem arises when the `path` variable is freed by error or reallocated in `ext4 find extent()`, and then used again in `ext4 ext show leaf()`, potentially leading to a use-after-free condition. The vulnerability may allow an attacker to impact the confidentiality, integrity, and availability of protected information. Recommendations: For Linux kernel versions prior to 6.6.58, update to version 6.6.58 or later to resolve the issue. As a temporary workaround, consider disabling the `EXT DEBUG` definition to prevent the vulnerability from being triggered. Additionally, restrict access to the `ext4 ext show leaf()` function and related components to minimize the risk of exploitation.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: The issue is related to a slab-use-after-free vulnerability in the `ext4 split extent at()` function of the Linux kernel's ext4 file system. This vulnerability can be triggered when the `ext4 split extent at()` function is called, leading to a use-after-free error. The vulnerability may allow an attacker to impact the confidentiality, integrity, and availability of protected information. The vulnerability is caused by the reuse of previously freed memory. Recommendations: To resolve the issue, update the Linux kernel to version 6.6.58 or later. As a temporary workaround, consider restricting access to the vulnerable `ext4 split extent at()` function until a patch is available. Avoid using the `ext4 ext show leaf()` function with the `path` variable as input until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.58 **Description** The issue is related to the function `ext4 ext replay update ex()` in the Linux kernel's ext4 file system module. It involves a double-free vulnerability, where previously freed memory is accessed again, potentially leading to confidentiality, integrity, and availability impacts. The vulnerability occurs when `ext4 force split extent at()` is called within `ext4 ext replay update ex()`, updating `ppath` but freeing `path`, which can trigger a double-free. The fix involves dropping the unnecessary `ppath` and using `path` directly, as well as using `ext4 find extent()` to update `path` and propagate its error return. **Recommendations** For Linux kernel versions prior to 6.6.58, update to version 6.6.58 or later to resolve the issue. As a temporary workaround, consider restricting access to the vulnerable `ext4 ext replay update ex()` function until a patch is available. Additionally, avoid using the `ppath` variable in the affected code path to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.52 **Description** A vulnerability in the Linux kernel has been resolved, which is related to the fscache module. The `fscache cookie lru timer` is initialized when the fscache module is inserted, but it is not deleted when the module is removed. If `timer reduce()` is called before removing the fscache module, the `fscache cookie lru timer` will be added to the timer list of the current CPU, triggering a use-after-free in the softIRQ after removing the module. This can lead to a page fault and potentially allow an attacker to impact the confidentiality, integrity, and availability of protected information. **Recommendations** To resolve this issue, update the Linux kernel to version 6.6.52 or later. As a temporary workaround, consider disabling the fscache module until a patch is available. Restrict access to the vulnerable module to minimize the risk of exploitation. Avoid using the `fscache cookie lru timer` in the affected API endpoint until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: A dentry leak may occur in the Linux kernel when a lookup cookie and a cull are concurrent. This happens because the reference count obtained by `lookup one positive unlocked()` in `cachefiles look up object()` is not released. As a result, a WARNING is triggered when the backend folder is umounted, indicating that a dentry is still in use. Recommendations: To resolve this issue, update to Linux kernel version 6.6.58 or later. As a temporary workaround, consider disabling the `cachefiles open file()` function until a patch is available. Restrict access to the vulnerable `cachefiles` module to minimize the risk of exploitation. Avoid using the `lookup one positive unlocked()` function in the affected `cachefiles look up object()` function until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: A NULL pointer dereference or path memory leak issue has been identified in the Linux kernel. The problem occurs in the `ext4 find extent()` function when the path is not big enough, and after reallocating and successfully initializing the path, the `*orig path` is not updated. This can cause the caller to receive a valid path but a NULL `ppath`, leading to a NULL pointer dereference or a path memory leak. The issue is demonstrated in the `ext4 split extent` function, where a NULL pointer dereference can occur when trying to access `path[depth].p ext`. Recommendations: For Linux kernel versions prior to 6.6.58, update to version 6.6.58 or later to resolve the issue. As a temporary workaround, consider disabling the `ext4 find extent()` function until a patch is available. Restrict access to the vulnerable `ext4` module to minimize the risk of exploitation. Avoid using the `ppath` variable in the affected API endpoints until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.43 Description: The vulnerability is related to a slab-use-after-free issue in the `fscache withdraw volume()` function. This issue can be triggered when a mount fails or a daemon exits, leading to a use-after-free error. The vulnerability may allow an attacker to impact the confidentiality, integrity, and availability of protected information. The issue is caused by the `fscache volume` being freed while its reference count may still be 0, and can be avoided by using the new `fscache try get volume()` helper function to get its reference count. Recommendations: To resolve the issue, update the Linux kernel to version 6.6.43 or later. As a temporary workaround, consider disabling the `cachefiles withdraw volume()` function until a patch is available. Additionally, restrict access to the vulnerable `fscache withdraw volume()` function to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.43 **Description** The vulnerability is related to a slab-use-after-free issue in the `cachefiles withdraw cookie()` function. This issue can be triggered by a race condition between the `cachefiles daemon release()` and `cachefiles withdraw cache()` functions, leading to a use-after-free error. The vulnerability can be exploited to impact the confidentiality, integrity, and availability of protected information. **Recommendations** To resolve the issue, update the Linux kernel to version 6.6.43 or later. As a temporary workaround, consider disabling the `cachefiles withdraw cookie()` function until a patch is available. However, this may have unintended consequences and should be carefully evaluated before implementation. Note: At the moment, there is no information about other versions that contain a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The vulnerability is related to the cachefiles function in the Linux kernel, where the reuse of `msg id` after a maliciously completed reopen request can cause a read request to remain unprocessed and result in a hung task. This issue arises due to the incorrect allocation of `msg id`, which can be exploited to trigger a hung task when read requests are waiting for the reopen to complete. The `cachefiles ondemand send req(OPEN)` function is involved in this process, and the reuse of `msg id` can lead to unexpected behavior, including the execution of a successful `copen` when it is expected to fail. **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 slab-use-after-free vulnerability in the `cachefiles ondemand daemon read()` function. This vulnerability can be triggered by a fuzz test of randomly issuing the restore command. The process that triggers the issue involves multiple threads and the use of `kzalloc` and `kmem cache free` functions. The vulnerability can be avoided by grabbing the reference count of the object before `xa unlock` to ensure it has not been freed yet. **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.8.0-rc7-dirty #542 **Description** The issue is caused by a slab-use-after-free vulnerability in the `cachefiles ondemand daemon read` function. This occurs when a restore command is issued while the daemon is still alive, resulting in a request being processed multiple times and triggering a use-after-free (UAF) error. The vulnerability can be exploited by issuing a restore command when the daemon is still alive. Technical details about exploitation include: - The `cachefiles ondemand get fd` function is vulnerable to a UAF error. - The `REQ A` variable is used to store a request, and its `done` field is waited on using `wait for completion`. - The `cachefiles ondemand daemon read` function reads data from a file descriptor, and the `copy to user` function is used to copy data to a user-space buffer. - The `xas for each` function is used to iterate over a set of requests, and the `xas set mark` function is used to set a mark on a request. - The `cachefiles ondemand restore` function is used to restore a request, and the `xa erase` function is used to erase a request from a cache. **Recommendations** To resolve the issue, add an additional reference count to `cachefiles req`, which is held while waiting and reading, and then released when the waiting and reading is over. As a temporary workaround, consider disabling the `cachefiles ondemand daemon read` function until a patch is available. Restrict access to the vulnerable `cachefiles ondemand get fd` function to minimize the risk of exploitation. Avoid using the `REQ A` variable in the affected API endpoint until the issue is resolved.

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 cachefiles component of the Linux kernel. This vulnerability can be exploited to potentially elevate privileges. The vulnerability occurs when requests are not properly removed from the cache during flushing, allowing for the possibility of accessing freed requests. The `cachefiles flush reqs` function is involved in this issue, and the `req->msg.opcode` is checked against `CACHEFILES OP READ`. The vulnerability can be exploited due to a concurrency issue between `daemon thread1` and `daemon thread2`, where a request may be used after it has been freed. 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 use-after-free vulnerability in the sata fsl component of the Linux kernel. This vulnerability can be triggered when the `rmmod sata fsl.ko` command is executed in the PPC64 GNU/Linux environment, leading to a bug report. The vulnerability is caused by the execution of the `iounmap` and `kfree` functions in the wrong order, resulting in a use-after-free condition. The vulnerability can potentially allow an attacker to elevate privileges in the system. 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 prevents malicious processes from completing random copen/cread requests and crashing the system. Added checks include: * Generic, copen can only complete open requests, and cread can only complete read requests. * For copen, `ondemand id` must not be 0, because this indicates that the request has not been read by the daemon. * For cread, the object corresponding to `fd` and `req` should be the same. **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.43 **Description** The issue arises when the `copen` function is maliciously called in user mode, potentially deleting a request corresponding to a random id before it has been read. If the object is set to reopen, the open request will be done with the still reopen state, causing the request to be skipped in the `select req` function. As a result, the read request is never completed and blocks other processes. This can occur when the `ondemand id` is less than 0. **Recommendations** To resolve the issue, update to Linux kernel version 6.6.43 or later. As a temporary workaround, consider disabling the `copen` function until a patch is available. Restrict access to the `cachefiles` module to minimize the risk of exploitation. Avoid using the `ondemand id` parameter in the affected kernel functions until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the use of memory after it has been freed in the cachefiles module of the Linux kernel. This can cause a cache Use After Free (UAF) condition. The problem arises when an anonymous file descriptor is installed and then closed, potentially before the reference count of the cache is obtained. To resolve this, the cache reference count should be grabbed before installing the file descriptor. By kernel convention, the file descriptor is taken over by user land after installation, and the kernel should not call close on it after that. The fix involves calling fd install after everything is ready, specifically after copy to user succeeds. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.