)]}'
{
  "commit": "783b0a82b31debe930ab76e5b0a391ccbfe16c2b",
  "tree": "d6794f997ed2cdb37bcd75d7d55c266dc2c34a23",
  "parents": [
    "b230ee0b0742ad986c75a3dda3ba53b4e4d6e28c"
  ],
  "author": {
    "name": "Robbie Ko",
    "email": "robbieko@synology.com",
    "time": "Thu Dec 11 13:30:33 2025 +0800"
  },
  "committer": {
    "name": "Miri Amarilio",
    "email": "mirilio@google.com",
    "time": "Fri Feb 06 15:04:15 2026 -0800"
  },
  "message": "btrfs: fix deadlock in wait_current_trans() due to ignored transaction type\n\ncommit 5037b342825df7094a4906d1e2a9674baab50cb2 upstream.\n\nWhen wait_current_trans() is called during start_transaction(), it\ncurrently waits for a blocked transaction without considering whether\nthe given transaction type actually needs to wait for that particular\ntransaction state. The btrfs_blocked_trans_types[] array already defines\nwhich transaction types should wait for which transaction states, but\nthis check was missing in wait_current_trans().\n\nThis can lead to a deadlock scenario involving two transactions and\npending ordered extents:\n\n  1. Transaction A is in TRANS_STATE_COMMIT_DOING state\n\n  2. A worker processing an ordered extent calls start_transaction()\n     with TRANS_JOIN\n\n  3. join_transaction() returns -EBUSY because Transaction A is in\n     TRANS_STATE_COMMIT_DOING\n\n  4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes\n\n  5. A new Transaction B is created (TRANS_STATE_RUNNING)\n\n  6. The ordered extent from step 2 is added to Transaction B\u0027s\n     pending ordered extents\n\n  7. Transaction B immediately starts commit by another task and\n     enters TRANS_STATE_COMMIT_START\n\n  8. The worker finally reaches wait_current_trans(), sees Transaction B\n     in TRANS_STATE_COMMIT_START (a blocked state), and waits\n     unconditionally\n\n  9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START\n     according to btrfs_blocked_trans_types[]\n\n  10. Transaction B is waiting for pending ordered extents to complete\n\n  11. Deadlock: Transaction B waits for ordered extent, ordered extent\n      waits for Transaction B\n\nThis can be illustrated by the following call stacks:\n  CPU0                              CPU1\n                                    btrfs_finish_ordered_io()\n                                      start_transaction(TRANS_JOIN)\n                                        join_transaction()\n                                          # -EBUSY (Transaction A is\n                                          # TRANS_STATE_COMMIT_DOING)\n  # Transaction A completes\n  # Transaction B created\n  # ordered extent added to\n  # Transaction B\u0027s pending list\n  btrfs_commit_transaction()\n    # Transaction B enters\n    # TRANS_STATE_COMMIT_START\n    # waiting for pending ordered\n    # extents\n                                        wait_current_trans()\n                                          # waits for Transaction B\n                                          # (should not wait!)\n\nTask bstore_kv_sync in btrfs_commit_transaction waiting for ordered\nextents:\n\n  __schedule+0x2e7/0x8a0\n  schedule+0x64/0xe0\n  btrfs_commit_transaction+0xbf7/0xda0 [btrfs]\n  btrfs_sync_file+0x342/0x4d0 [btrfs]\n  __x64_sys_fdatasync+0x4b/0x80\n  do_syscall_64+0x33/0x40\n  entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nTask kworker in wait_current_trans waiting for transaction commit:\n\n  Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs]\n  __schedule+0x2e7/0x8a0\n  schedule+0x64/0xe0\n  wait_current_trans+0xb0/0x110 [btrfs]\n  start_transaction+0x346/0x5b0 [btrfs]\n  btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs]\n  btrfs_work_helper+0xe8/0x350 [btrfs]\n  process_one_work+0x1d3/0x3c0\n  worker_thread+0x4d/0x3e0\n  kthread+0x12d/0x150\n  ret_from_fork+0x1f/0x30\n\nFix this by passing the transaction type to wait_current_trans() and\nchecking btrfs_blocked_trans_types[cur_trans-\u003estate] against the given\ntype before deciding to wait. This ensures that transaction types which\nare allowed to join during certain blocked states will not unnecessarily\nwait and cause deadlocks.\n\nBUG\u003db/482089499\nTEST\u003dpresubmit\nRELEASE_NOTE\u003dFixed CVE-2025-71194 in the Linux kernel.\n\ncos-patch: security-moderate\nReviewed-by: Filipe Manana \u003cfdmanana@suse.com\u003e\nChange-Id: I3c161f240e6274036b0c091e21a9f3900e314ed1\nSigned-off-by: Robbie Ko \u003crobbieko@synology.com\u003e\nSigned-off-by: Filipe Manana \u003cfdmanana@suse.com\u003e\nReviewed-by: David Sterba \u003cdsterba@suse.com\u003e\nSigned-off-by: David Sterba \u003cdsterba@suse.com\u003e\nCc: Motiejus Jakštys \u003cmotiejus@jakstys.lt\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\nSigned-off-by: Kernel CVE Triage Automation \u003ccloud-image-kernel-cve-triage-automation@prod.google.com\u003e\nReviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/130403\nTested-by: Cusky Presubmit Bot \u003cpresubmit@cos-infra-prod.iam.gserviceaccount.com\u003e\nReviewed-by: Miri Amarilio \u003cmirilio@google.com\u003e\nReviewed-by: Chenglong Tang \u003cchenglongtang@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1a029392eac524c57f2a3e20021c2186567f9075",
      "old_mode": 33188,
      "old_path": "fs/btrfs/transaction.c",
      "new_id": "e666595e77794ec9414bb1c4ea24b4b4917ccff3",
      "new_mode": 33188,
      "new_path": "fs/btrfs/transaction.c"
    }
  ]
}