On Wed, Apr 27, 2022 at 09:31:50AM -0700, Samuel Mendoza-Jonas wrote: > On Tue, Apr 26, 2022 at 11:27:01AM -0700, Samuel Mendoza-Jonas wrote: > > From: Ritesh Harjani <riteshh@xxxxxxxxxxxxx> > > > > commit cc16eecae687912238ee6efbff71ad31e2bc414e upstream. > > > > jbd2_journal_wait_updates() is called with j_state_lock held. But if > > there is a commit in progress, then this transaction might get committed > > and freed via jbd2_journal_commit_transaction() -> > > jbd2_journal_free_transaction(), when we release j_state_lock. > > So check for journal->j_running_transaction everytime we release and > > acquire j_state_lock to avoid use-after-free issue. > > > > Link: https://lore.kernel.org/r/948c2fed518ae739db6a8f7f83f1d58b504f87d0.1644497105.git.ritesh.list@xxxxxxxxx > > Fixes: 4f98186848707f53 ("jbd2: refactor wait logic for transaction updates into a common function") > > Cc: stable@xxxxxxxxxx > > Reported-and-tested-by: syzbot+afa2ca5171d93e44b348@xxxxxxxxxxxxxxxxxxxxxxxxx > > Reviewed-by: Jan Kara <jack@xxxxxxx> > > Signed-off-by: Ritesh Harjani <riteshh@xxxxxxxxxxxxx> > > Signed-off-by: Theodore Ts'o <tytso@xxxxxxx> > > [backport to 4.9-4.19 in original jbd2_journal_commit_transaction() > > location before the refactor in > > 4f9818684870 "jbd2: refactor wait logic for transaction updates into a > > common function"] > > Signed-off-by: Samuel Mendoza-Jonas <samjonas@xxxxxxxxxx> > > Fixes: 1da177e4c3f41524 > > Cc: stable@xxxxxxxxxx # 4.9.x - 4.19.x > > --- > > While marked for 5.17 stable, it looks like this fix also applies to the > > original location in jbd2_journal_commit_transaction() before it was > > refactored to use jbd2_journal_wait_updates(). This applies the same > > change there. > > Jan kindly pointed out this was a false alarm: > https://lore.kernel.org/all/20220427111726.3wdyxbqoxs7skdzf@xxxxxxxxxx/ > > So the existing patch is fine and these can be ignored! Thanks for the update, now all dropped from my queue. greg k-h
