Zhang Yi

**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.50 **Description** The issue occurs due to an uninitialized `extent status` struct when doing `fast commit` replay, causing an infinite loop. The `ext4 ext determine insert hole()` function does not detect the replay and calls `ext4 es find extent range()`, which returns immediately without initializing the `es` variable. As a result, `es` contains garbage, leading to a potential integer overflow and infinite loop in the function. This can be easily reproduced using `fstest generic/039`. The problem is fixed by unconditionally initializing the structure in the `ext4 es find extent range()` function. **Recommendations** Update to Linux kernel version 6.6.50 or later to resolve the issue. As a temporary workaround, consider restricting access to the `ext4 es find extent range()` function until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to the fixed version **Description** A NULL pointer issue has been identified in the Linux kernel when resizing a corrupt ext4 image with the resize inode feature disabled. This issue can be reproduced by creating an ext4 filesystem, disabling the resize inode feature, mounting the filesystem, and then resizing it. The problem occurs because the es->s reserved gdt blocks is not reduced to zero when the resize inode feature is cleared, leading to a call to reserve backup gdb() with an uninitialized resize inode. This results in a kernel NULL pointer dereference. **Recommendations** For Linux kernel versions prior to the fixed version, consider applying the fix that adds a check in ext4 resize begin() to ensure that the es->s reserved gdt blocks is zero when the resize inode feature is disabled. As a temporary workaround, avoid disabling the resize inode feature when creating an ext4 filesystem to minimize the risk of exploitation.