{"cve":"CVE-2025-38365","nvd":{"published":"2025-07-25T13:15:25.380","modified":"2026-07-30T06:23:10.323","status":"Modified","description":"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 (< 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 (< 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 (< 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() -> 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---","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H","score":4.7},"cwes":["CWE-362"],"references":["https://git.kernel.org/stable/c/2088895d5903082bb9021770b919e733c57edbc1","https://git.kernel.org/stable/c/3ca864de852bc91007b32d2a0d48993724f4abad","https://git.kernel.org/stable/c/51bd363c7010d033d3334daf457c824484bf9bf0","https://git.kernel.org/stable/c/8c6874646c21bd820cf475e2874e62c133954023","https://git.kernel.org/stable/c/aeeae8feeaae4445a86f9815273e81f902dc1f5b"],"products":["debian:debian_linux","linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T22:05:46.678065081+00:00"},"epss":{"cve":"CVE-2025-38365","score":0.00356,"percentile":0.29312,"date":"2026-10-31"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}