Skip to content
Heist/ feed
Back to feed
UnratedFix available

btrfs: don't log conflicting inode if it's a dir moved in the current transaction

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: btrfs: don't log conflicting inode if it's a dir moved in the current transaction We can't log a conflicting inode if it's a directory and it was moved from one parent directory to another parent directory in the current transaction, as this can result an attempt to have a directory with two hard links during log replay, one for the old parent directory and another for the new parent directory. The following scenario triggers that issue: 1) We have directories "dir1" and "dir2" created in a past transaction. Directory "dir1" has inode A as its parent directory; 2) We move "dir1" to some other directory; 3) We create a file with the name "dir1" in directory inode A; 4) We fsync the new file. This results in logging the inode of the new file and the inode for the directory "dir1" that was previously moved in the current transaction. So the log tree has the INODE_REF item for the new location of "dir1"; 5) We move the new file to some other directory. This results in updating the log tree to included the new INODE_REF for the new location of the file and removes the INODE_REF for the old location. This happens during the rename when we call btrfs_log_new_name(); 6) We fsync the file, and that persists the log tree changes done in the previous step (btrfs_log_new_name() only updates the log tree in memory); 7) We have a power failure; 8) Next time the fs is mounted, log replay happens and when processing the inod

Products
Kernel
Affected versions
Not specified
Fixed versions
6.1.160, 6.12.64, 6.18.3, 6.6.120
CVEs
CVE-2025-68778
Confirmed fixed CVEs
Not specified
Updated in this feed
3 Nov 2026, 12:28 UTC · Revision 1

Source evidence

btrfs: don't log conflicting inode if it's a dir moved in the current transaction

core-osv · Original source

Published 13 Jan 2026, 15:28 UTC

In the Linux kernel, the following vulnerability has been resolved: btrfs: don't log conflicting inode if it's a dir moved in the current transaction We can't log a conflicting inode if it's a directory and it was moved from one parent directory to another parent directory in the current transaction, as this can result an attempt to have a directory with two hard links during log replay, one for the old parent directory and another for the new parent directory. The following scenario triggers that issue: 1) We have directories "dir1" and "dir2" created in a past transaction. Directory "dir1" has inode A as its parent directory; 2) We move "dir1" to some other directory; 3) We create a file with the name "dir1" in directory inode A; 4) We fsync the new file. This results in logging the inode of the new file and the inode for the directory "dir1" that was previously moved in the current transaction. So the log tree has the INODE_REF item for the new location of "dir1"; 5) We move the new file to some other directory. This results in updating the log tree to included the new INODE_REF for the new location of the file and removes the INODE_REF for the old location. This happens during the rename when we call btrfs_log_new_name(); 6) We fsync the file, and that persists the log tree changes done in the previous step (btrfs_log_new_name() only updates the log tree in memory); 7) We have a power failure; 8) Next time the fs is mounted, log replay happens and when processing the inod

osv:CVE-2025-68778

Kernel

Fixed versions: 6.1.160, 6.6.120, 6.12.64, 6.18.3

Complete source record
{
  "id": "18dd7ac19efc204040f403ccdc8ec5364db78c36db63d99780bff6e3d6403697",
  "url": "https://osv.dev/vulnerability/CVE-2025-68778",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "btrfs: don't log conflicting inode if it's a dir moved in the current transaction",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't log conflicting inode if it's a dir moved in the current transaction We can't log a conflicting inode if it's a directory and it was moved from one parent directory to another parent directory in the current transaction, as this can result an attempt to have a directory with two hard links during log replay, one for the old parent directory and another for the new parent directory. The following scenario triggers that issue: 1) We have directories \"dir1\" and \"dir2\" created in a past transaction. Directory \"dir1\" has inode A as its parent directory; 2) We move \"dir1\" to some other directory; 3) We create a file with the name \"dir1\" in directory inode A; 4) We fsync the new file. This results in logging the inode of the new file and the inode for the directory \"dir1\" that was previously moved in the current transaction. So the log tree has the INODE_REF item for the new location of \"dir1\"; 5) We move the new file to some other directory. This results in updating the log tree to included the new INODE_REF for the new location of the file and removes the INODE_REF for the old location. This happens during the rename when we call btrfs_log_new_name(); 6) We fsync the file, and that persists the log tree changes done in the previous step (btrfs_log_new_name() only updates the log tree in memory); 7) We have a power failure; 8) Next time the fs is mounted, log replay happens and when processing the inod",
    "evidence": "osv:CVE-2025-68778",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.1.160",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.6.120",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.12.64",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.3",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "unknown",
    "structured": {
      "id": "CVE-2025-68778",
      "aliases": [
        "CVE-2025-68778"
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "44f714dae50a2e795d3268a6831762aa6fa54f55"
                },
                {
                  "fixed": "d64f3834dffef80f0a9185a037617a54ed7f4bd2"
                },
                {
                  "fixed": "7359e1d39c78816ecbdb0cb4e93975794ce53973"
                },
                {
                  "fixed": "d478f50727c3ee46d0359f0d2ae114f70191816e"
                },
                {
                  "fixed": "a35788ddf8df65837897ecbb0ddb2896b863159e"
                },
                {
                  "fixed": "266273eaf4d99475f1ae57f687b3e42bc71ec6f0"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-68778.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "4.8.0"
                },
                {
                  "fixed": "6.1.160"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.2.0"
                },
                {
                  "fixed": "6.6.120"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.7.0"
                },
                {
                  "fixed": "6.12.64"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.18.3"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-68778.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:28.540828866Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/266273eaf4d99475f1ae57f687b3e42bc71ec6f0",
        "https://git.kernel.org/stable/c/7359e1d39c78816ecbdb0cb4e93975794ce53973",
        "https://git.kernel.org/stable/c/a35788ddf8df65837897ecbb0ddb2896b863159e",
        "https://git.kernel.org/stable/c/d478f50727c3ee46d0359f0d2ae114f70191816e",
        "https://git.kernel.org/stable/c/d64f3834dffef80f0a9185a037617a54ed7f4bd2",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/68xxx/CVE-2025-68778.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2025-68778",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/68xxx/CVE-2025-68778.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2025-68778",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": null
  },
  "source_id": "core-osv",
  "document_id": 495392,
  "published_at": "2026-01-13T15:28:54.107+00:00"
}