CVE-2025-71183
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk29th percentile - higher than 29% of all known CVEs
Summary
In the Linux kernel's Btrfs filesystem, a vulnerability was found where conflicting inodes are not detected when logging inode references after a rename exchange operation. This can cause the log replay to attempt deleting a directory containing a subvolume, resulting in a mount failure.
Risk Assessment
The risk involves potential filesystem corruption after a power failure, as log replay may try to delete a directory with a subvolume, preventing the partition from mounting and potentially causing data loss.
Recommendation
Immediately update the Linux kernel to a version containing the fix for CVE-2025-71183. Monitor official security advisories from your distribution and apply the patch as soon as it becomes available.
Other vulnerabilities in Linux kernel
See all- CVE-2026-90049Unknown
In the Linux kernel, a vulnerability in skb_zerocopy() was fixed: it incorrectly called skb_tx_error() on the source skb when copying frags. This completed the zerocopy uarg and cleared the SKBFL_SHARED_FRAG flag on an skb still in use by the network stack. Specifically on the OVS_ACTION_ATTR_USERSPACE path, the skb was not freed on error, which could lead to ESP data being decrypted in place where the skb did not privately own frags, potentially causing data corruption or other issues.
- CVE-2026-90046Unknown
In the Linux kernel, free_pages_nolock() uses spin_trylock() in NMI context on uniprocessor (UP) systems, which is unsafe. The bug affects the page freeing path and can crash the kernel. It is likely exploitable by local attackers for privilege escalation.
- CVE-2026-90045Unknown
In the Linux kernel USB gadget ffs driver, the io_data structure stores a pointer to the submitting task's mm_struct but does not hold a reference while async requests are pending. This can cause a use-after-free if the task exits before completion handling finishes. The fix takes a reference with mmgrab() when queuing and releases it with mmdrop() on completion.
- CVE-2026-90044Unknown
In the Linux kernel USB gadget f_fs driver, a use-after-free exists in the AIO error path. When ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure is freed, but the kiocb cancel function remains armed and points to the freed pointer. A concurrent cancel (e.g., sys_io_cancel()) can cause a use-after-free. The fix safely disarms the cancellation via kiocb->ki_complete() and returns -EIOCBQUEUED.
- CVE-2026-90043Unknown
In the Linux kernel zram module, the slot lock bit is set in the wrong position on 64-bit big-endian systems. Instead of landing in the flags field, it lands in ac_time, so with ZRAM_TRACK_ENTRY_ACTIME enabled, storing the access time wipes out the held lock bit and lets another CPU take the same slot lock. An access time value with that bit set can make the slot appear locked forever. The fix shifts the lock bit into the flags half on big-endian 64-bit.
- CVE-2026-90042Unknown
A vulnerability was found in the Linux kernel's Ceph filesystem where ceph_fname_to_usr() passed vmalloc() buffers to the fscrypt crypto API, which requires linear memory. This can cause kernel oopses, especially on non-x86 platforms. The fix adds support for vmalloc() buffers using a bounce buffer.
- CVE-2026-90041Unknown
In the Linux kernel, the HID sony driver fails to remove a controller from the device list when HID core input device registration fails. The devres-managed sony_sc is freed while its list node remains linked, leading to use-after-free when the next matching controller is handled.
- CVE-2026-90039Unknown
In the Linux kernel, NFSD admin state-revocation handlers (unlock_filesystem, NFSD_CMD_UNLOCK_FILESYSTEM, NFSD_CMD_UNLOCK_EXPORT) only check nn->nfsd_serv, which is set before nn->conf_id_hashtbl is allocated. This leads to a NULL dereference when the server has not yet started.
- CVE-2026-90038Unknown
In the Linux kernel, nfsd4_revoke_export_states() drops nn->client_lock but the held stateid reference does not pin the client. A concurrent client teardown can free the client while revoke_one_stid() still dereferences it, causing a use-after-free.
- CVE-2026-90037Unknown
In the Linux kernel, an nfs4_openowner left on nn->close_lru holds only a raw pointer to its nfs4_client. When the laundromat reaps entries, drops client_lock and calls nfs4_put_stid(), a concurrent force_expire_client() can free the client, causing a use-after-free.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: btrfs: always detect conflicting inodes when logging inode refs After rename exchanging (either with the rename exchange operation or regular renames in multiple non-atomic steps) two inodes and at least one of them is a directory, we can end up with a log tree that contains only of the inodes and after a power failure that can result in an attempt to delete the other inode when it should not because it was not deleted before the power failure. In some case that delete attempt fails when the target inode is a directory that contains a subvolume inside it, since the log replay code is not prepared to deal with directory entries that point to root items (only inode items). 1) We have directories "dir1" (inode A) and "dir2" (inode B) under the same parent directory; 2) We have a file (inode C) under directory "dir1" (inode A); 3) We have a subvolume inside directory "dir2" (inode B); 4) All these inodes were persisted in a past transaction and we are currently at transaction N; 5) We rename the file (inode C), so at btrfs_log_new_name() we update inode C's last_unlink_trans to N; 6) We get a rename exchange for "dir1" (inode A) and "dir2" (inode B), so after the exchange "dir1" is inode B and "dir2" is inode A. During the rename exchange we call btrfs_log_new_name() for inodes A and B, but because they are directories, we don't update their last_unlink_trans to N; 7) An fsync against the file (inode C) is done, and because its inode has a last_unlink_trans with a value of N we log its parent directory (inode A) (through btrfs_log_all_parents(), called from btrfs_log_inode_parent()). 8) So we end up with inode B not logged, which now has the old name of inode A. At copy_inode_items_to_log(), when logging inode A, we did not check if we had any conflicting inode to log because inode A has a generation lower than the current transaction (created in a past transaction); 9) After a power failure, when replaying the log tree, since we find that inode A has a new name that conflicts with the name of inode B in the fs tree, we attempt to delete inode B... this is wrong since that directory was never deleted before the power failure, and because there is a subvolume inside that directory, attempting to delete it will fail since replay_dir_deletes() and btrfs_unlink_inode() are not prepared to deal with dir items that point to roots instead of inodes. When that happens the mount fails and we get a stack trace like the following: [87.2314] BTRFS info (device dm-0): start tree-log replay [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259 [87.2332] ------------[ cut here ]------------ [87.2338] BTRFS: Transaction aborted (error -2) [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2368] Modules linked in: btrfs loop dm_thin_pool (...) [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full) [87.2489] Tainted: [W]=WARN [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2538] Code: c0 89 04 24 (...) [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286 [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000 [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840 [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0 [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10 [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000 [87. ---truncated---