Zhihao Cheng

A deadlock issue in the Linux kernel has been identified, specifically in the ubifs file system. This occurs when concurrent rename whiteout and inode writeback processes are executed, causing tasks to hang. The issue arises from the locking mechanism used by the `ubifs rename` and `ubifs write inode` functions, which can lead to a deadlock situation. The problem is triggered by the `SYS renameat2` system call when used with the `RENAME WHITEOUT` flag, and it can be reproduced by consuming available space before the kernel performs budgeting for the whiteout operation.

A double-free issue has been identified in the Linux kernel, specifically in the `ubifs` module. The problem occurs when the `rename whiteout` operation fails due to a space budget issue, causing the `whiteout ui->data` to be freed twice. This is confirmed by KASAN reports, which indicate a double-free or invalid-free error in `ubifs free inode`. The issue arises from the `rename whiteout` process, where `whiteout ui->data` is allocated and then freed, but also freed again in `ubifs free inode`. The estimated number of potentially affected devices is not provided.

The issue is related to a use-after-free vulnerability in the btrfs file system. It can be triggered when mounting btrfs from two images with the same fsid and different dev uuids in a specific order. The vulnerability affects the `device->bdev file` variable in the ` btrfs free extra devids()` function. This can lead to unauthorized access and modification of sensitive information. The exploitation of this vulnerability may allow an attacker to impact the confidentiality, integrity, and availability of protected information.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: A vulnerability in the Linux kernel related to ext4 file systems has been fixed. The issue arises in the dax iomap rw() function, which maps written blocks and copies user data to blocks. If the process is killed by the user, the copied data will be returned and added to the inode size, potentially exceeding the inode size and causing fsck to fail. The problem is fixed by truncating extents if the written length is smaller than expected. 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 dax iomap rw() function until a patch is available. Restrict access to the ext4 file system to minimize the risk of exploitation. Avoid using the `iter->pos` and `iocb->ki pos` variables in the affected code until the issue is resolved.

The vulnerability is related to the `dispose list` function in the Linux kernel's vfs component. It is caused by incorrect resource cleanup or release, which can lead to a deadlock when the inode reclaiming process tries to destroy inodes marked with the `I FREEING` flag. This issue can occur when certain filesystems, such as ext4 with the `ea inode` feature or ubifs with xattr, perform inode lookups in the inode evicting callback function under the inode lru traversing context. The vulnerability can result in a denial-of-service (DoS) condition. Technical details about exploitation include: - **API Endpoints:** None mentioned. - **Vulnerable Parameters or Variables:** `i ea`, `i reg`, `ixa`, `ib`, `ia`. - **Function Names:** `prune icache sb`, `find inode fast`, `ext4 evict inode`, `ubifs jnl write inode`, `inode lru isolate`, ` iget`, `iget locked`, `ext4 iget`, `ubifs iget`.

The issue is related to the ubifs component of the Linux kernel, where page cache reads are lockless. This allows a simultaneous reader to see old data if the freshly allocated page is set uptodate before the new data is copied into it. The vulnerability can be exploited to cause a denial of service. The `SetPageUptodate` call has been moved to `ubifs write end()`, after the new data has been copied into the page, to resolve the issue. The functions `write begin slow()`, `ubifs write begin()`, and `ubifs write end()` in `fs/ubifs/file.c` are involved in the vulnerability.

A use-after-free issue exists in the Linux kernel, specifically in the `ubi create volume()` function. The problem arises when volume creation fails, and there is an attempt to access the `eba tbl` after it has been freed. This occurs due to redundant releasing of `eba tbl`. The issue is related to the `ubi eba replace table()` and `ubi eba destroy table()` functions, and the `tbl->entries` are freed after the `eba tbl` has been destroyed, leading to a use-after-free condition.

A bug in the Linux kernel's UBIFS (Unsorted Block Image File System) has been identified, which can cause a page migration issue. The problem arises when the `PG private` flag is set on a page without incrementing the reference count. This can lead to a situation where the page migration process believes the page is not in use by any other processes and attempts to migrate it, resulting in concurrent access to the page reference count. This can cause a kernel bug, leading to a crash.

The issue is an use-after-free problem in the Linux kernel's blktrace functionality. This problem is triggered by a specific process involving the removal of a block trace by sysfs, followed by the access of the removed trace. The vulnerability can be reproduced by using the ioctl function on /dev/sda and /dev/sdb with specific parameters, and then removing the block trace while it is still being accessed. The vulnerability results in a kernel NULL pointer dereference. Technical details about exploitation include: - **API Endpoints:** The ioctl function is used with the following endpoints: /dev/sda and /dev/sdb. - **Vulnerable Parameters or Variables:** The `buf size` variable in the `blk user trace setup` function is set to 127. - **Function Names:** The vulnerability involves the `blk trace remove queue`, `synchronize rcu`, `blk trace free`, `relay close`, `rcu read lock`, ` blk add trace`, `trace note tsk`, `relay close buf`, `relay destroy buf`, `kfree`, `trace note`, and `relay reserve` functions.

The issue arises from concurrent `xattr {set|get}` and `listxattr` operations in UBIFS, potentially leading to problems such as assertion failure, memory corruption, and stale xattr values. This is resolved by introducing a new rw-lock in `@ubifs inode` to serialize write operations on xattr, allowing concurrent read operations to remain effective.