CVE-2025-22113 in Linux
Summary
by MITRE • 04/16/2025
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid journaling sb update on error if journal is destroying
Presently we always BUG_ON if trying to start a transaction on a journal marked with JBD2_UNMOUNT, since this should never happen. However, while ltp running stress tests, it was observed that in case of some error handling paths, it is possible for update_super_work to start a transaction after the journal is destroyed eg:
(umount) ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work)
/* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT)
Hence, introduce a new mount flag to indicate journal is destroying and only do a journaled (and deferred) update of sb if this flag is not set. Otherwise, just fallback to an un-journaled commit.
Further, in the journal destroy path, we have the following sequence:
1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updates
This sequence is important as it ensures that, after this point, there is no sb update that might be journaled so it is safe to update the sb outside the journal. (To avoid race discussed in 2d01ddc86606)
Also, we don't need a similar check in ext4_grp_locked_error since it is only called from mballoc and AFAICT it would be always valid to schedule work here.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 02/15/2026
The vulnerability described in CVE-2025-22113 affects the Linux kernel's ext4 filesystem implementation and specifically addresses a race condition during journal destruction and superblock update operations. This issue manifests when the ext4 filesystem attempts to perform journal operations on a journal that has already been marked for destruction, leading to a kernel panic through the BUG_ON mechanism. The problem occurs during the unmount process where the journal destruction sequence conflicts with ongoing superblock update operations that may attempt to start new transactions on a journal that is already in the process of being torn down.
The technical flaw stems from the kernel's handling of journal state management during filesystem shutdown. When the ext4 filesystem begins unmounting, the journal is marked with JBD2_UNMOUNT flag to indicate it is being destroyed, yet certain error handling paths can still attempt to start new transactions on this already-marked journal. The sequence described in the vulnerability involves the generic_shutdown_super function calling sync_filesystem which commits all transactions, followed by evict_inodes which might start new transactions, and finally jbd2_journal_destroy which sets the JBD2_UNMOUNT flag. This creates a window where update_super_work function can be scheduled to execute after the journal is marked for destruction but before the full destruction sequence completes, causing the BUG_ON condition to trigger.
This vulnerability directly relates to CWE-362, which describes a race condition in concurrent programming where the execution order of operations affects the system's behavior. The issue also maps to ATT&CK technique T1490, which involves data destruction through filesystem manipulation. The kernel's failure to properly distinguish between normal operation and journal destruction states during error handling creates an exploitable condition that could lead to system crashes and potential denial of service scenarios. The vulnerability demonstrates poor state management in the journal subsystem where the system does not adequately protect against attempting operations on already-destroyed resources.
The operational impact of this vulnerability is significant for systems running ext4 filesystems, particularly those under stress testing or experiencing I/O errors during shutdown operations. The kernel panic caused by the BUG_ON condition results in immediate system instability and requires manual intervention to recover. This vulnerability is particularly concerning in production environments where filesystem stability is critical, as it can lead to unexpected system crashes during routine operations such as unmounting filesystems or handling I/O errors. The race condition can be triggered by stress testing scenarios like those performed by LTP (Linux Test Project) or during actual system failures when error handling paths attempt to update superblock information while the journal is in the process of being destroyed.
The mitigation strategy implemented in the fix involves introducing a new mount flag to indicate when the journal is in the process of being destroyed, allowing the system to distinguish between normal journal operations and operations that should be avoided during destruction. When the journal is marked as destroying, the system falls back to un-journaled superblock updates rather than attempting to perform journaled updates that would fail. The fix also enforces a proper sequence during journal destruction: first setting the destruction flag, then forcing a commit and waiting for it to complete, and finally flushing pending superblock updates. This ensures that no further journal operations can occur after the destruction sequence begins, preventing the race condition that led to the original vulnerability. The solution also clarifies that ext4_grp_locked_error does not require similar protection since it is only called from mballoc and always valid to schedule work there, indicating the fix is targeted specifically at the problematic superblock update path rather than affecting broader filesystem operations.