)]}'
{
  "commit": "7c65144a905a3e351487b1df6c22b1ac94994451",
  "tree": "2c863f63e10da3b2b2596205da17e9a9dceba25d",
  "parents": [
    "c3443b2b1e5779756e6d0a053eae8cb15294ba8c"
  ],
  "author": {
    "name": "Sasha Levin",
    "email": "sashal@kernel.org",
    "time": "Tue Dec 30 22:26:30 2025 -0500"
  },
  "committer": {
    "name": "Greg Kroah-Hartman",
    "email": "gregkh@linuxfoundation.org",
    "time": "Fri Jan 02 16:14:28 2026 +0100"
  },
  "message": "CVE-2025-68168: Add .vulnerable file\n\nRoot Cause Commit: 95e2b352c03b0a86c5717ba1d24ea20969abcacc\nTitle: \"FS: JFS: Check for read-only mounted filesystem in txBegin\"\nAuthor: Immad Mir\nDate: June 23, 2023\n\nTechnical Details:\n\nThe Fix Commit (300b072df72694ea330c4c673c035253e07827b8)\n\nThe fix modifies txInit() in fs/jfs/jfs_txnmgr.c to ensure all\nTxBlock[] entries have their waitqueues initialized, including\nTxBlock[0]:\n\nBefore:\n    for (k \u003d 1; k \u003c nTxBlock - 1; k++) {\n        TxBlock[k].next \u003d k + 1;\n        init_waitqueue_head(\u0026TxBlock[k].gcwait);\n        init_waitqueue_head(\u0026TxBlock[k].waitor);\n    }\n    TxBlock[k].next \u003d 0;\n    init_waitqueue_head(\u0026TxBlock[k].gcwait);\n    init_waitqueue_head(\u0026TxBlock[k].waitor);\n\nAfter:\n    for (k \u003d 0; k \u003c nTxBlock; k++) {\n        init_waitqueue_head(\u0026TxBlock[k].gcwait);\n        init_waitqueue_head(\u0026TxBlock[k].waitor);\n    }\n    for (k \u003d 1; k \u003c nTxBlock - 1; k++) {\n        TxBlock[k].next \u003d k + 1;\n    }\n\nThe Bug Chain:\n\n1. Original Design (since Linux 2.6.12-rc2, commit 1da177e4c3f4):\n   - TxBlock[0] was intentionally not initialized because tid\u003d0 was\n     \"reserved\" and never used\n   - The code comment at fs/jfs/jfs_txnmgr.c:289 states: \"tid \u003d 0 is\n     reserved.\"\n   - txBegin() would NEVER return 0 - it would block and retry via\n     TXN_SLEEP() if no tids were available\n   - TxAnchor.freetid was initialized to 1, not 0\n\n2. Root Cause (commit 95e2b352c03b, June 2023):\nThis commit added a read-only filesystem check at the beginning of\ntxBegin():\n\n       if (!log) {\n           jfs_error(sb, \"read-only filesystem\\n\");\n           return 0;  // \u003c-- BUG INTRODUCED HERE\n       }\n\n   This creates a NEW code path where txBegin() returns tid\u003d0.\n\n3. Exploitation Path:\n   - When a JFS filesystem is mounted read-only, JFS_SBI(sb)-\u003elog is\n     NULL\n   - txBegin() now returns tid\u003d0\n   - Callers like jfs_write_inode() don\u0027t check for tid\u003d0 and proceed to\n     call txEnd(tid)\n   - txEnd(0) calls tid_to_tblock(0) which expands to \u0026TxBlock[0]\n     (defined\n     in fs/jfs/jfs_txnmgr.h:13)\n   - txEnd() then calls TXN_WAKEUP(\u0026tblk-\u003ewaitor) at line 504\n   - TxBlock[0].waitor was NEVER initialized, causing a lockdep warning\n     and crash:\n         INFO: trying to register non-static key in txEnd\n\nWhy Commit 95e2b352c03b is the Root Cause:\n\nBefore this commit:\n- txBegin() would always return a valid tid \u003e\u003d 1 or block waiting\n- The loop \"if ((t \u003d TxAnchor.freetid) \u003d\u003d 0) { TXN_SLEEP(...); goto\n  retry; }\" ensured no 0 return\n- TxBlock[0] not being initialized was irrelevant since it was never\n  accessed\n\nAfter this commit:\n- txBegin() can return 0 immediately on read-only filesystems\n- Callers proceed to use this tid\u003d0, eventually calling txEnd(0)\n- txEnd(0) accesses the uninitialized TxBlock[0].waitor, triggering the\n  crash\n\nThe commit intended to fix a NULL pointer dereference on log access,\nbut inadvertently broke the invariant that tid\u003d0 is never used, exposing\nthe latent uninitialized memory in TxBlock[0].\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "d9e9a0ea23623ed1dbbb3b5ae25b15735950775f",
      "new_mode": 33188,
      "new_path": "cve/published/2025/CVE-2025-68168.vulnerable"
    }
  ]
}