CVE-2025-38365

/// Technical description

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix a race between renames and directory logging

We have a race between a rename and directory inode logging that if it

happens and we crash/power fail before the rename completes, the next time

the filesystem is mounted, the log replay code will end up deleting the

file that was being renamed.

This is best explained following a step by step analysis of an interleaving

of steps that lead into this situation.

Consider the initial conditions:

1) We are at transaction N;

2) We have directories A and B created in a past transaction (< N);

3) We have inode X corresponding to a file that has 2 hardlinks, one in

directory A and the other in directory B, so we'll name them as

"A/foo_link1" and "B/foo_link2". Both hard links were persisted in a

past transaction (< N);

4) We have inode Y corresponding to a file that as a single hard link and

is located in directory A, we'll name it as "A/bar". This fil

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References