Filipe Manana

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: A vulnerability in the Linux kernel has been resolved, related to the btrfs file system. The issue occurs when updating the action of an existing reference to BTRFS DROP DELAYED REF, which deletes the reference from its list using `list del()`. This leaves the reference's `add list` member not reinitialized, causing a crash when `drop delayed ref()` is called later. The crash happens because `list empty()` returns false due to the list not being reinitialized after `list del()`, leading to an invalid list access. This results in a splat if `CONFIG LIST HARDENED` and `CONFIG DEBUG LIST` are set, or invalid poison pointer dereferences otherwise. 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.58 Description: The issue is related to a race condition in the btrfs file system, specifically in the `find desired extent()` function. When multiple threads access the same file descriptor concurrently, a memory leak can occur due to the allocation of private structures by each thread. This can lead to a use-after-free problem, as one thread may free the structure while another is still using it. The issue arises from the shared use of the same cached state record in the private structure, which can result in incorrect results. The problem is fixed by protecting the private assignment and check of a file while holding the inode's spinlock and keeping track of the task that allocated the private. 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 concurrent access to the same file descriptor to minimize the risk of exploitation. Additionally, avoid using the `lseek` system call with `SEEK DATA` or `SEEK HOLE` flags on the same file descriptor from multiple threads.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.74 Description: A vulnerability has been resolved in the Linux kernel, specifically in the btrfs module. The issue is related to a possible recursive locking detected when running fstests btrfs/011 with MKFS OPTIONS="-O rst". This could lead to a deadlock scenario. The vulnerability is caused by the btrfs module trying to acquire a lock that is already held by the task. Technical details about exploitation include the `btrfs map block()` function and the `dev replace.rwsem` lock. Recommendations: To resolve the issue, update the Linux kernel to version 6.6.74 or later. As a temporary workaround, consider disabling the `btrfs dev replace by ioctl()` function until a patch is available. Restrict access to the `btrfs map block()` function to minimize the risk of exploitation. Avoid using the `dev replace.rwsem` lock in the affected API endpoints until the issue is resolved.

The issue is related to a use-after-free vulnerability in the btrfs load zone info() function, which can be triggered by a race condition with a device replace operation. This happens because the function extracts a device from the chunk map into a local variable and then uses the device while not under the protection of the device replace rwsem. If a device replace operation occurs while the device is being extracted and the device is the source of the replace operation, a use-after-free can be triggered if the replace operation finishes and frees the device before the function finishes using it. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited.

The issue is related to a race condition in the btrfs file system when detecting delalloc ranges during fiemap. This can lead to missing delalloc ranges for file regions that are currently holes, causing the caller of fiemap to be unaware of data in some file regions. This can be serious for use cases like the cp program in coreutils versions before 9.0, which used fiemap to detect holes and data in the source file. If cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, resulting in a data loss issue. Technical details about exploitation include: - The `fiemap` function is called without the `FIEMAP FLAG SYNC` flag for a file with delalloc in a range that is currently a hole. - The `fiemap` function locks the inode in shared mode and iterates the inode's subvolume tree searching for file extent items without having the whole fiemap target range locked in the inode's io tree. - The `btrfs find delalloc in range()` function is used to search for delalloc by checking for the `EXTENT DELALLOC` bit in the io tree for the range and ordered extents.

A deadlock can occur in the Linux kernel when an unmount operation is initiated while an async block group reclaim task is running and relocating a data block group. This happens because of a combination of factors, including the presence of an async metadata or data space reclaim task and the parking of the cleaner kthread during the close ctree() operation. The issue arises when the async space reclaim task runs all existing delayed iputs and the block group reclaim task creates a delayed iput, leading to a deadlock.

The issue is related to a use-after-free vulnerability in the Linux kernel's btrfs file system. Specifically, it occurs when creating a snapshot and the `btrfs commit transaction()` function fails, leading to a situation where a pending snapshot structure is freed but still accessible, resulting in a user-after-free scenario. This can happen in the following sequence: 1. A pending snapshot is allocated and added to the transaction's list of pending snapshots. 2. `btrfs commit transaction()` is called, and if it fails, the pending snapshot structure is freed. 3. Another task commits the transaction without errors, accessing the already freed pending snapshot structure, thus causing a user-after-free. The vulnerability could be detected by smatch, which produced a warning about the pending snapshot not being removed from the list. To fix this, the snapshot creation ioctl should not directly add the pending snapshot to the transaction's list. Instead, it should add the pending snapshot to the transaction handle, and then at `btrfs commit transaction()`, add the snapshot to the list only when it can be guaranteed that any error returned after that point will result in a transaction abort.

The vulnerability is related to the btrfs file system in the Linux kernel. When an inode is moved from one directory to another and both the inode and its previous parent directory were logged before, the dentry for the old parent should not exist after a power failure if the log is synced. However, there is a scenario where this does not work correctly because the old parent of the file/directory that was moved is not authoritative for a range that includes the dir index and dir item keys of the old dentry. This can be triggered by a specific layout of keys and items in the fs/subvolume btree.

A race condition exists between a task aborting a transaction during a commit, a task doing an fsync, and the transaction kthread, leading to a use-after-free of the log root tree. This results in a stack trace with errors such as "BTRFS info (device dm-0): forced readonly" and "BTRFS: error (device dm-0) in cleanup transaction:1958: errno=-5 IO failure". The issue occurs when two tasks have a transaction handle attached to the same transaction, and one task is doing an fsync while the other task calls btrfs commit transaction(), causing an error before the transaction is committed.

The issue allows local users to gain privileges or cause a denial of service (use-after-free) by leveraging improper access to a certain error field in the ext4 journal stop function.