CVE-2026-23465

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: log new dentries when logging parent dir of a conflicting inode<br /> <br /> If we log the parent directory of a conflicting inode, we are not logging<br /> the new dentries of the directory, so when we finish we have the parent<br /> directory&amp;#39;s inode marked as logged but we did not log its new dentries.<br /> As a consequence if the parent directory is explicitly fsynced later and<br /> it does not have any new changes since we logged it, the fsync is a no-op<br /> and after a power failure the new dentries are missing.<br /> <br /> Example scenario:<br /> <br /> $ mkdir foo<br /> <br /> $ sync<br /> <br /> $rmdir foo<br /> <br /> $ mkdir dir1<br /> $ mkdir dir2<br /> <br /> # A file with the same name and parent as the directory we just deleted<br /> # and was persisted in a past transaction. So the deleted directory&amp;#39;s<br /> # inode is a conflicting inode of this new file&amp;#39;s inode.<br /> $ touch foo<br /> <br /> $ ln foo dir2/link<br /> <br /> # The fsync on dir2 will log the parent directory (".") because the<br /> # conflicting inode (deleted directory) does not exists anymore, but it<br /> # it does not log its new dentries (dir1).<br /> $ xfs_io -c "fsync" dir2<br /> <br /> # This fsync on the parent directory is no-op, since the previous fsync<br /> # logged it (but without logging its new dentries).<br /> $ xfs_io -c "fsync" .<br /> <br /> <br /> <br /> # After log replay dir1 is missing.<br /> <br /> Fix this by ensuring we log new dir dentries whenever we log the parent<br /> directory of a no longer existing conflicting inode.<br /> <br /> A test case for fstests will follow soon.