CVSS 3.1
Вероятност да бъде експлоатирана в следващите 30 дни (EPSS)
Атакува се
Време до експлоатация
Атакува се по мрежата, без особени условия, без вход и без действие от потребителя.
Описание
Оригинално описание
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 file was also persisted in a past transaction (< N). The steps leading to a file loss are the following and for all of them we are under transaction N: 1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir(); 2) Task A starts a rename for inode Y, with the goal of renaming from "A/bar" to "A/baz", so we enter btrfs_rename(); 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref(); 4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir(); 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same); 6) Now before task A adds t
Засегнати продукти
- Linux Linux: 259c4b96d78dda8477a3ac21d6b3cf0eb9f75c8b преди 51bd363c7010d033d3334daf457c824484bf9bf0; 259c4b96d78dda8477a3ac21d6b3cf0eb9f75c8b преди aeeae8feeaae4445a86f9815273e81f902dc1f5b; 259c4b96d78dda8477a3ac21d6b3cf0eb9f75c8b преди 2088895d5903082bb9021770b919e733c57edbc1; 259c4b96d78dda8477a3ac21d6b3cf0eb9f75c8b преди 8c6874646c21bd820cf475e2874e62c133954023; 259c4b96d78dda8477a3ac21d6b3cf0eb9f75c8b преди 3ca864de852bc91007b32d2a0d48993724f4abad
- Linux Linux: 5.18; преди 5.18; 6.1.143 до 6.1.*; 6.6.96 до 6.6.*; 6.12.36 до 6.12.*; 6.15.5 до 6.15.*; от 6.16 нататък
История
- 25 юли 2025 Публикувано
Други уязвимости в Linux Linux
Първоизточници
- https://www.cve.org/CVERecord?id=CVE-2025-38365
- https://nvd.nist.gov/vuln/detail/CVE-2025-38365
- https://git.kernel.org/stable/c/51bd363c7010d033d3334daf457c824484bf9bf0
- https://git.kernel.org/stable/c/aeeae8feeaae4445a86f9815273e81f902dc1f5b
- https://git.kernel.org/stable/c/2088895d5903082bb9021770b919e733c57edbc1
- https://git.kernel.org/stable/c/8c6874646c21bd820cf475e2874e62c133954023
- https://git.kernel.org/stable/c/3ca864de852bc91007b32d2a0d48993724f4abad
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html