Vulnerabilidad en Linux (CVE-2025-71194)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: corrige interbloqueo en wait_current_trans() debido a un tipo de transacción ignorado<br /> <br /> Cuando se llama a wait_current_trans() durante start_transaction(), actualmente espera por una transacción bloqueada sin considerar si el tipo de transacción dado realmente necesita esperar por ese estado de transacción particular. El array btrfs_blocked_trans_types[] ya define qué tipos de transacción deben esperar por qué estados de transacción, pero esta verificación faltaba en wait_current_trans().<br /> <br /> Esto puede llevar a un escenario de interbloqueo que involucra dos transacciones y extensiones ordenadas pendientes:<br /> <br /> 1. La Transacción A está en estado TRANS_STATE_COMMIT_DOING<br /> 2. Un worker que procesa una extensión ordenada llama a start_transaction() con TRANS_JOIN<br /> 3. join_transaction() devuelve -EBUSY porque la Transacción A está en TRANS_STATE_COMMIT_DOING<br /> 4. La Transacción A pasa a TRANS_STATE_UNBLOCKED y se completa<br /> 5. Se crea una nueva Transacción B (TRANS_STATE_RUNNING)<br /> 6. La extensión ordenada del paso 2 se añade a las extensiones ordenadas pendientes de la Transacción B<br /> 7. La Transacción B inicia inmediatamente la confirmación por otra tarea y entra en TRANS_STATE_COMMIT_START<br /> 8. El worker finalmente llega a wait_current_trans(), ve la Transacción B en TRANS_STATE_COMMIT_START (un estado bloqueado), y espera incondicionalmente<br /> 9. Sin embargo, TRANS_JOIN NO debería esperar por TRANS_STATE_COMMIT_START según btrfs_blocked_trans_types[]<br /> 10. La Transacción B está esperando que las extensiones ordenadas pendientes se completen<br /> 11. Interbloqueo: La Transacción B espera por la extensión ordenada, la extensión ordenada espera por la Transacción B<br /> <br /> Esto puede ilustrarse con las siguientes pilas de llamadas:<br /> CPU0 CPU1<br /> btrfs_finish_ordered_io()<br /> start_transaction(TRANS_JOIN)<br /> join_transaction()<br /> # -EBUSY (La Transacción A está en<br /> # TRANS_STATE_COMMIT_DOING)<br /> # La Transacción A se completa<br /> # La Transacción B creada<br /> # extensión ordenada añadida a<br /> # la lista pendiente de la Transacción B<br /> btrfs_commit_transaction()<br /> # La Transacción B entra en<br /> # TRANS_STATE_COMMIT_START<br /> # esperando por extensiones ordenadas<br /> # pendientes<br /> wait_current_trans()<br /> # espera por la Transacción B<br /> # (¡no debería esperar!)<br /> <br /> Tarea bstore_kv_sync en btrfs_commit_transaction esperando por extensiones ordenadas:<br /> <br /> __schedule+0x2e7/0x8a0<br /> schedule+0x64/0xe0<br /> btrfs_commit_transaction+0xbf7/0xda0 [btrfs]<br /> btrfs_sync_file+0x342/0x4d0 [btrfs]<br /> __x64_sys_fdatasync+0x4b/0x80<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Tarea kworker en wait_current_trans esperando por la confirmación de la transacción:<br /> <br /> Cola de trabajo: btrfs-syno_nocow btrfs_work_helper [btrfs]<br /> __schedule+0x2e7/0x8a0<br /> schedule+0x64/0xe0<br /> wait_current_trans+0xb0/0x110 [btrfs]<br /> start_transaction+0x346/0x5b0 [btrfs]<br /> btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs]<br /> btrfs_work_helper+0xe8/0x350 [btrfs]<br /> process_one_work+0x1d3/0x3c0<br /> worker_thread+0x4d/0x3e0<br /> kthread+0x12d/0x150<br /> ret_from_fork+0x1f/0x30<br /> <br /> Solucione esto pasando el tipo de transacción a wait_current_trans() y verificando btrfs_blocked_trans_types[cur_trans-&amp;gt;state] contra el tipo dado antes de decidir esperar. Esto asegura que los tipos de transacción a los que se les permite unirse durante ciertos estados bloqueados no esperarán innecesariamente y causarán interbloqueos.