CVE-2025-71194: btrfs: fix deadlock in wait_current_trans() due to ignored transaction type

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix deadlock in waitcurrenttrans() due to ignored transaction type

When waitcurrenttrans() is called during starttransaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfsblockedtranstypes[] array already defines which transaction types should wait for which transaction states, but this check was missing in waitcurrenttrans().

This can lead to a deadlock scenario involving two transactions and pending ordered extents:

1. Transaction A is in TRANSSTATECOMMITDOING state

2. A worker processing an ordered extent calls starttransaction() with TRANSJOIN

3. jointransaction() returns -EBUSY because Transaction A is in TRANSSTATECOMMITDOING

4. Transaction A moves to TRANSSTATEUNBLOCKED and completes

5. A new Transaction B is created (TRANSSTATERUNNING)

6. The ordered extent from step 2 is added to Transaction B's pending ordered extents

7. Transaction B immediately starts commit by another task and enters TRANSSTATECOMMITSTART

8. The worker finally reaches waitcurrenttrans(), sees Transaction B in TRANSSTATECOMMITSTART (a blocked state), and waits unconditionally

9. However, TRANSJOIN should NOT wait for TRANSSTATECOMMITSTART according to btrfsblockedtranstypes[]

10. Transaction B is waiting for pending ordered extents to complete

11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B

This can be illustrated by the following call stacks: CPU0 CPU1 btrfsfinishorderedio() starttransaction(TRANSJOIN) jointransaction() # -EBUSY (Transaction A is # TRANSSTATECOMMITDOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfscommittransaction() # Transaction B enters # TRANSSTATECOMMITSTART # waiting for pending ordered # extents waitcurrenttrans() # waits for Transaction B # (should not wait!)

Task bstorekvsync in btrfscommittransaction waiting for ordered extents:

schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfscommittransaction+0xbf7/0xda0 [btrfs] btrfssyncfile+0x342/0x4d0 [btrfs] x64sysfdatasync+0x4b/0x80 dosyscall64+0x33/0x40 entrySYSCALL64afterhwframe+0x44/0xa9

Task kworker in waitcurrenttrans waiting for transaction commit:

Workqueue: btrfs-synonocow btrfsworkhelper [btrfs] schedule+0x2e7/0x8a0 schedule+0x64/0xe0 waitcurrenttrans+0xb0/0x110 [btrfs] starttransaction+0x346/0x5b0 [btrfs] btrfsfinishorderedio.isra.0+0x49b/0x9c0 [btrfs] btrfsworkhelper+0xe8/0x350 [btrfs] processonework+0x1d3/0x3c0 workerthread+0x4d/0x3e0 kthread+0x12d/0x150 retfromfork+0x1f/0x30

Fix this by passing the transaction type to waitcurrenttrans() and checking btrfsblockedtranstypes[curtrans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.