Josef Bacik

The vulnerability is related to the improper termination of timers for kernel sockets in the Linux kernel. When TCP sockets are closed, the function `inet csk clear xmit timers()` is called to stop the timers. However, this function can be called from any context, including when the socket lock is held, which can lead to ongoing timers finishing much later. For kernel sockets, this can cause the netns to be freed before the timer can complete, because kernel sockets do not hold a reference on the netns. The patch adds a new function `inet csk clear xmit timers sync()` that uses `sk stop timer sync()` to ensure all timers are terminated before the kernel socket is released.

The issue is related to a NULL pointer dereference in the `ff layout cancel io()` function, which can cause a panic when `nfs4 ff layout prepare ds()` fails. The problem arises from an inconsistent check for `mirror ds`, where the code only checks for `!mirror->mirror ds` instead of `IS ERR OR NULL(mirror ds)`. This inconsistency can lead to a panic when an error occurs. The vulnerability is related to the NFS component of the Linux kernel.

The issue is related to a use-after-free vulnerability in the direct writes functionality of the Network File System (NFS) in the Linux kernel. This occurs when the `nfs direct request` is completed twice in a row, leading to a `refcount t` underflow and a use-after-free warning. The source of this issue is the completion path for commit requests, where asynchronous requests may complete before the next one is submitted, resulting in the `nfs direct request` being completed twice. The estimated number of potentially affected devices worldwide is not specified. There is no information about real-world incidents where this issue was exploited. Technical details about exploitation include: - The vulnerable function is `nfs direct write schedule work()`. - The issue arises from the repeated completion of `nfs direct request`. - The `nfs commit end()` function is involved in the completion path for commit requests. - The `get dreq()` and `put dreq()` calls are used around event processing and completion paths.

The issue arises when the Linux kernel fails to write out the free space cache in one instance and then attempts to write it again. On the second pass, it calls `btrfs get extent()` on the inode to get the extent mapping, but since this is a new block group and the free space inode always searches the commit root to avoid deadlocking with the tree, it finds nothing and returns a `EXTENT MAP HOLE` for the requested range. This happens because the first time the kernel tries to write the space cache out, it hits an error and drops the extent mapping, which is normal for normal files but not for the free space cache inode, where the extent map is always expected to be correct. As a result, the second time through, the kernel ends up with a bogus extent map.

The issue is related to the btrfs component of the Linux kernel and involves an error in handling chunk tree lookup in the `btrfs relocate sys chunks()` function. This error can lead to corruption and potentially allow an attacker to cause a denial of service. The vulnerability is caused by two impossible conditions: the search key being set up to look for a chunk tree item with an offset of -1, and the found key corresponding to a chunk item after a successful search. The offset is decremented by 1 before the next loop, making it impossible to find a chunk item due to alignment and size constraints.

A deadlock vulnerability has been resolved in the Linux kernel, specifically in the btrfs file system. The issue occurs when the fiemap and extent locking mechanisms interact, potentially causing a deadlock. This happens because the extent lock is held for the entire range during the fiemap operation, which can lead to a situation where a page fault occurs while the lock is still held, resulting in a deadlock. The vulnerability exists in the normal code but was not previously noticed due to the lack of lockdep annotations. To fix this, the patch simply does not take the extent lock for the entire duration of the fiemap, which is safe because the code keeps track of its position in the tree.

The issue occurs due to incorrect abort logic in the `btrfs replace file extents` function. Error injection testing revealed a case where a corrupt file system with a missing extent in the middle of a file could occur. The problem arises because the if statement to decide if an abort is necessary is incorrect. The only situation where an abort would happen is if a specific error code (`-EOPNOTSUPP`) is not returned and the call comes from the file clone code. However, the prealloc code also uses this path, and instead, an abort should occur if there is an error, except for the `-EOPNOTSUPP` error when coming from the clone file code.

The issue occurs in the btrfs file system when a rename exchange operation fails to insert the second inode reference, resulting in a dangling inode reference and potential file system corruption. This happens because the inode reference for one side of the rename is inserted first, and if the insertion of the second inode reference fails, the first one is left dangling. The problem was uncovered through error injection stress testing. The fix involves aborting the operation if the insertion of the first inode reference is successful.

A vulnerability has been resolved in the Linux kernel, specifically in the btrfs file system. The issue occurred when error injection testing caused a panic due to an invalid opcode. The error path for this code handles errors properly, and instead of panicking, it should simply return the error. This vulnerability was identified during error injection testing and is related to the `link to fixup dir` function in the `fs/btrfs/tree-log.c` file.