{
  "cveId": "CVE-2025-68774",
  "url": "https://patchblox.com/security/cve/CVE-2025-68774",
  "summary": "CVE-2025-68774 is fixed in linux on 1 platform, first by DEBIAN-CVE-2025-68774, released January 13, 2026. It is not reported as exploited. Patch Radar priority: High.",
  "title": "hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create",
  "description": "In the Linux kernel, the following vulnerability has been resolved:  hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create  When sync() and link() are called concurrently, both threads may enter hfs_bnode_find() without finding the node in the hash table and proceed to create it.  Thread A:   hfsplus_write_inode()     -\u003E hfsplus_write_system_inode()       -\u003E hfs_btree_write()         -\u003E hfs_bnode_find(tree, 0)           -\u003E __hfs_bnode_create(tree, 0)  Thread B:   hfsplus_create_cat()     -\u003E hfs_brec_insert()       -\u003E hfs_bnode_split()         -\u003E hfs_bmap_alloc()           -\u003E hfs_bnode_find(tree, 0)             -\u003E __hfs_bnode_create(tree, 0)  In this case, thread A creates the bnode, sets refcnt=1, and hashes it. Thread B also tries to create the same bnode, notices it has already been inserted, drops its own instance, and uses the hashed one without getting the node.  \u0060\u0060\u0060  \tnode2 = hfs_bnode_findhash(tree, cnid); \tif (!node2) {                                 \u003C- Thread A \t\thash = hfs_bnode_hash(cnid); \t\tnode-\u003Enext_hash = tree-\u003Enode_hash[hash]; \t\ttree-\u003Enode_hash[hash] = node; \t\ttree-\u003Enode_hash_cnt\u002B\u002B; \t} else {                                      \u003C- Thread B \t\tspin_unlock(\u0026tree-\u003Ehash_lock); \t\tkfree(node); \t\twait_event(node2-\u003Elock_wq, \t\t\t!test_bit(HFS_BNODE_NEW, \u0026node2-\u003Eflags)); \t\treturn node2; \t} \u0060\u0060\u0060  However, hfs_bnode_find() requires each call to take a reference. Here both threads end up setting refcnt=1. When they later put the node, this triggers:  BUG_ON(!atomic_read(\u0026node-\u003Erefcnt))  In this scenario, Thread B in fact finds the node in the hash table rather than creating a new one, and thus must take a reference.  Fix this by calling hfs_bnode_get() when reusing a bnode newly created by another thread to ensure the refcount is updated correctly.  A similar bug was fixed in HFS long ago in commit a9dc087fd3c4 (\u0022fix missing hfs_bnode_get() in __hfs_bnode_create\u0022) but the same issue remained in HFS\u002B until now.",
  "published": "2026-01-13T16:15:56Z",
  "severity": "Moderate",
  "cvss": 7.5,
  "cvssVector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
  "epss": 0.00587,
  "epssPercentile": 0.4831,
  "priority": "High",
  "priorityTier": 3,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "vendorAdvisory": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-68774",
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 12.15 (bookworm)",
      "fixedVersion": "6.1.162-1",
      "fix": "DEBIAN-CVE-2025-68774",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2025-68774",
      "released": "2026-01-13T16:15:56Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 13.5 (trixie)",
      "fixedVersion": "6.12.69-1",
      "fix": "DEBIAN-CVE-2025-68774",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2025-68774",
      "released": "2026-01-13T16:15:56Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "6.18.3-1",
      "fix": "DEBIAN-CVE-2025-68774",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2025-68774",
      "released": "2026-01-13T16:15:56Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T19:12:23Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}