{"id":"CVE-2025-38365","summary":"btrfs: fix a race between renames and directory logging","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix a race between renames and directory logging\n\nWe have a race between a rename and directory inode logging that if it\nhappens and we crash/power fail before the rename completes, the next time\nthe filesystem is mounted, the log replay code will end up deleting the\nfile that was being renamed.\n\nThis is best explained following a step by step analysis of an interleaving\nof steps that lead into this situation.\n\nConsider the initial conditions:\n\n1) We are at transaction N;\n\n2) We have directories A and B created in a past transaction (\u003c N);\n\n3) We have inode X corresponding to a file that has 2 hardlinks, one in\n   directory A and the other in directory B, so we'll name them as\n   \"A/foo_link1\" and \"B/foo_link2\". Both hard links were persisted in a\n   past transaction (\u003c N);\n\n4) We have inode Y corresponding to a file that as a single hard link and\n   is located in directory A, we'll name it as \"A/bar\". This file was also\n   persisted in a past transaction (\u003c N).\n\nThe steps leading to a file loss are the following and for all of them we\nare under transaction N:\n\n 1) Link \"A/foo_link1\" is removed, so inode's X last_unlink_trans field\n    is updated to N, through btrfs_unlink() -\u003e btrfs_record_unlink_dir();\n\n 2) Task A starts a rename for inode Y, with the goal of renaming from\n    \"A/bar\" to \"A/baz\", so we enter btrfs_rename();\n\n 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling\n    btrfs_insert_inode_ref();\n\n 4) Because the rename happens in the same directory, we don't set the\n    last_unlink_trans field of directoty A's inode to the current\n    transaction id, that is, we don't cal btrfs_record_unlink_dir();\n\n 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY\n    and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode()\n    (actually the dir index item is added as a delayed item, but the\n    effect is the same);\n\n 6) Now before task A adds the new entry \"A/baz\" to directory A by\n    calling btrfs_add_link(), another task, task B is logging inode X;\n\n 7) Task B starts a fsync of inode X and after logging inode X, at\n    btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since\n    inode X has a last_unlink_trans value of N, set at in step 1;\n\n 8) At btrfs_log_all_parents() we search for all parent directories of\n    inode X using the commit root, so we find directories A and B and log\n    them. Bu when logging direct A, we don't have a dir index item for\n    inode Y anymore, neither the old name \"A/bar\" nor for the new name\n    \"A/baz\" since the rename has deleted the old name but has not yet\n    inserted the new name - task A hasn't called yet btrfs_add_link() to\n    do that.\n\n    Note that logging directory A doesn't fallback to a transaction\n    commit because its last_unlink_trans has a lower value than the\n    current transaction's id (see step 4);\n\n 9) Task B finishes logging directories A and B and gets back to\n    btrfs_sync_file() where it calls btrfs_sync_log() to persist the log\n    tree;\n\n10) Task B successfully persisted the log tree, btrfs_sync_log() completed\n    with success, and a power failure happened.\n\n    We have a log tree without any directory entry for inode Y, so the\n    log replay code deletes the entry for inode Y, name \"A/bar\", from the\n    subvolume tree since it doesn't exist in the log tree and the log\n    tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY\n    item that covers the index range for the dentry that corresponds to\n    \"A/bar\").\n\n    Since there's no other hard link for inode Y and the log replay code\n    deletes the name \"A/bar\", the file is lost.\n\nThe issue wouldn't happen if task B synced the log only after task A\ncalled btrfs_log_new_name(), which would update the log with the new name\nfor inode Y (\"A/bar\").\n\nFix this by pinning the log root during renames before removing the old\ndirectory entry, and unpinning af\n---truncated---","modified":"2026-03-20T12:42:49.459114Z","published":"2025-07-25T12:47:35.387Z","related":["MGASA-2025-0218","MGASA-2025-0219","SUSE-SU-2025:02853-1","SUSE-SU-2025:02923-1","SUSE-SU-2025:02969-1","SUSE-SU-2025:02996-1","SUSE-SU-2025:02997-1","SUSE-SU-2025:03011-1","SUSE-SU-2025:03023-1","SUSE-SU-2025:20577-1","SUSE-SU-2025:20586-1","SUSE-SU-2025:20601-1","SUSE-SU-2025:20602-1","SUSE-SU-2025:21074-1","SUSE-SU-2025:21139-1","SUSE-SU-2025:21179-1","openSUSE-SU-2025:20081-1"],"database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/38xxx/CVE-2025-38365.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/2088895d5903082bb9021770b919e733c57edbc1"},{"type":"WEB","url":"https://git.kernel.org/stable/c/3ca864de852bc91007b32d2a0d48993724f4abad"},{"type":"WEB","url":"https://git.kernel.org/stable/c/51bd363c7010d033d3334daf457c824484bf9bf0"},{"type":"WEB","url":"https://git.kernel.org/stable/c/8c6874646c21bd820cf475e2874e62c133954023"},{"type":"WEB","url":"https://git.kernel.org/stable/c/aeeae8feeaae4445a86f9815273e81f902dc1f5b"},{"type":"WEB","url":"https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/38xxx/CVE-2025-38365.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38365"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"259c4b96d78dda8477a3ac21d6b3cf0eb9f75c8b"},{"fixed":"51bd363c7010d033d3334daf457c824484bf9bf0"},{"fixed":"aeeae8feeaae4445a86f9815273e81f902dc1f5b"},{"fixed":"2088895d5903082bb9021770b919e733c57edbc1"},{"fixed":"8c6874646c21bd820cf475e2874e62c133954023"},{"fixed":"3ca864de852bc91007b32d2a0d48993724f4abad"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2025-38365.json"}}],"schema_version":"1.7.5"}