cbcvebase.
CVE-2025-68778
published 2026-01-13

CVE-2025-68778: In the Linux kernel, the following vulnerability has been resolved: btrfs: don't log conflicting inode if it's a dir moved in the current transaction We can't…

PriorityP423medium6.4
EPSS
0.17%
6.5th percentile
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't log conflicting inode if it's a dir moved in the current transaction We can't log a conflicting inode if it's a directory and it was moved from one parent directory to another parent directory in the current transaction, as this can result an attempt to have a directory with two hard links during log replay, one for the old parent directory and another for the new parent directory. The following scenario triggers that issue: 1) We have directories "dir1" and "dir2" created in a past transaction. Directory "dir1" has inode A as its parent directory; 2) We move "dir1" to some other directory; 3) We create a file with the name "dir1" in directory inode A; 4) We fsync the new file. This results in logging the inode of the new file and the inode for the directory "dir1" that was previously moved in the current transaction. So the log tree has the INODE_REF item for the new location of "dir1"; 5) We move the new file to some other directory. This results in updating the log tree to included the new INODE_REF for the new location of the file and removes the INODE_REF for the old location. This happens during the rename when we call btrfs_log_new_name(); 6) We fsync the file, and that persists the log tree changes done in the previous step (btrfs_log_new_name() only updates the log tree in memory); 7) We have a power failure; 8) Next time the fs is mounted, log replay happens and when processing the inode for directory "dir1" we find a new INODE_REF and add that link, but we don't remove the old link of the inode since we have not logged the old parent directory of the directory inode "dir1". As a result after log replay finishes when we trigger writeback of the subvolume tree's extent buffers, the tree check will detect that we have a directory a hard link count of 2 and we get a mount failure. The errors and stack traces reported in dmesg/syslog are like this: [ 3845.729764] BTRF

Affected

44 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.162-1 (bookworm)linux 6.1.162-1 (bookworm)
debianlinux-6.1< linux 6.1.162-1 (bookworm)linux 6.1.162-1 (bookworm)
linuxlinux
linuxlinux>= 44f714dae50a2e795d3268a6831762aa6fa54f55 < d64f3834dffef80f0a9185a037617a54ed7f4bd2d64f3834dffef80f0a9185a037617a54ed7f4bd2
linuxlinux>= 44f714dae50a2e795d3268a6831762aa6fa54f55 < 7359e1d39c78816ecbdb0cb4e93975794ce539737359e1d39c78816ecbdb0cb4e93975794ce53973
linuxlinux>= 44f714dae50a2e795d3268a6831762aa6fa54f55 < d478f50727c3ee46d0359f0d2ae114f70191816ed478f50727c3ee46d0359f0d2ae114f70191816e
linuxlinux>= 44f714dae50a2e795d3268a6831762aa6fa54f55 < a35788ddf8df65837897ecbb0ddb2896b863159ea35788ddf8df65837897ecbb0ddb2896b863159e
linuxlinux>= 44f714dae50a2e795d3268a6831762aa6fa54f55 < 266273eaf4d99475f1ae57f687b3e42bc71ec6f0266273eaf4d99475f1ae57f687b3e42bc71ec6f0
linuxlinux_kernel>= 0 < 6.1.162-16.1.162-1
linuxlinux_kernel>= 0 < 6.12.69-16.12.69-1
linuxlinux_kernel>= 0 < 6.18.3-16.18.3-1
linuxlinux_kernel>= 4.8.0 < 6.1.1606.1.160
linuxlinux_kernel>= 6.13.0 < 6.18.36.18.3
linuxlinux_kernel>= 6.2.0 < 6.6.1206.6.120
linuxlinux_kernel>= 6.7.0 < 6.12.646.12.64
ubuntulinux-aws
ubuntulinux-aws-6.17
ubuntulinux-aws-fips
ubuntulinux-azure
ubuntulinux-azure-6.17
ubuntulinux-azure-6.8
ubuntulinux-azure-fips
ubuntulinux-fips
ubuntulinux-gcp
ubuntulinux-gcp-6.17

CVSS provenance

vendor_ubuntu6.4MEDIUM
vendor_redhat5.5LOW
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.