CVE-2025-22113

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid journaling sb update on error if journal is destroying<br /> <br /> Presently we always BUG_ON if trying to start a transaction on a journal marked<br /> with JBD2_UNMOUNT, since this should never happen. However, while ltp running<br /> stress tests, it was observed that in case of some error handling paths, it is<br /> possible for update_super_work to start a transaction after the journal is<br /> destroyed eg:<br /> <br /> (umount)<br /> ext4_kill_sb<br /> kill_block_super<br /> generic_shutdown_super<br /> sync_filesystem /* commits all txns */<br /> evict_inodes<br /> /* might start a new txn */<br /> ext4_put_super<br /> flush_work(&amp;sbi-&gt;s_sb_upd_work) /* flush the workqueue */<br /> jbd2_journal_destroy<br /> journal_kill_thread<br /> journal-&gt;j_flags |= JBD2_UNMOUNT;<br /> jbd2_journal_commit_transaction<br /> jbd2_journal_get_descriptor_buffer<br /> jbd2_journal_bmap<br /> ext4_journal_bmap<br /> ext4_map_blocks<br /> ...<br /> ext4_inode_error<br /> ext4_handle_error<br /> schedule_work(&amp;sbi-&gt;s_sb_upd_work)<br /> <br /> /* work queue kicks in */<br /> update_super_work<br /> jbd2_journal_start<br /> start_this_handle<br /> BUG_ON(journal-&gt;j_flags &amp;<br /> JBD2_UNMOUNT)<br /> <br /> Hence, introduce a new mount flag to indicate journal is destroying and only do<br /> a journaled (and deferred) update of sb if this flag is not set. Otherwise, just<br /> fallback to an un-journaled commit.<br /> <br /> Further, in the journal destroy path, we have the following sequence:<br /> <br /> 1. Set mount flag indicating journal is destroying<br /> 2. force a commit and wait for it<br /> 3. flush pending sb updates<br /> <br /> This sequence is important as it ensures that, after this point, there is no sb<br /> update that might be journaled so it is safe to update the sb outside the<br /> journal. (To avoid race discussed in 2d01ddc86606)<br /> <br /> Also, we don&amp;#39;t need a similar check in ext4_grp_locked_error since it is only<br /> called from mballoc and AFAICT it would be always valid to schedule work here.