This is a note to let you know that I've just added the patch titled

    reiserfs: Fix use after free in journal teardown

to the 3.16-stable tree which can be found at:
    
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     reiserfs-fix-use-after-free-in-journal-teardown.patch
and it can be found in the queue-3.16 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


>From 01777836c87081e4f68c4a43c9abe6114805f91e Mon Sep 17 00:00:00 2001
From: Jan Kara <[email protected]>
Date: Wed, 6 Aug 2014 19:43:56 +0200
Subject: reiserfs: Fix use after free in journal teardown

From: Jan Kara <[email protected]>

commit 01777836c87081e4f68c4a43c9abe6114805f91e upstream.

If do_journal_release() races with do_journal_end() which requeues
delayed works for transaction flushing, we can leave work items for
flushing outstanding transactions queued while freeing them. That
results in use after free and possible crash in run_timers_softirq().

Fix the problem by not requeueing works if superblock is being shut down
(MS_ACTIVE not set) and using cancel_delayed_work_sync() in
do_journal_release().

Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
 fs/reiserfs/journal.c |   22 ++++++++++++++++------
 fs/reiserfs/super.c   |    6 +++++-
 2 files changed, 21 insertions(+), 7 deletions(-)

--- a/fs/reiserfs/journal.c
+++ b/fs/reiserfs/journal.c
@@ -1947,8 +1947,6 @@ static int do_journal_release(struct rei
                }
        }
 
-       /* wait for all commits to finish */
-       cancel_delayed_work(&SB_JOURNAL(sb)->j_work);
 
        /*
         * We must release the write lock here because
@@ -1956,8 +1954,14 @@ static int do_journal_release(struct rei
         */
        reiserfs_write_unlock(sb);
 
+       /*
+        * Cancel flushing of old commits. Note that neither of these works
+        * will be requeued because superblock is being shutdown and doesn't
+        * have MS_ACTIVE set.
+        */
        cancel_delayed_work_sync(&REISERFS_SB(sb)->old_work);
-       flush_workqueue(REISERFS_SB(sb)->commit_wq);
+       /* wait for all commits to finish */
+       cancel_delayed_work_sync(&SB_JOURNAL(sb)->j_work);
 
        free_journal_ram(sb);
 
@@ -4292,9 +4296,15 @@ static int do_journal_end(struct reiserf
        if (flush) {
                flush_commit_list(sb, jl, 1);
                flush_journal_list(sb, jl, 1);
-       } else if (!(jl->j_state & LIST_COMMIT_PENDING))
-               queue_delayed_work(REISERFS_SB(sb)->commit_wq,
-                                  &journal->j_work, HZ / 10);
+       } else if (!(jl->j_state & LIST_COMMIT_PENDING)) {
+               /*
+                * Avoid queueing work when sb is being shut down. Transaction
+                * will be flushed on journal shutdown.
+                */
+               if (sb->s_flags & MS_ACTIVE)
+                       queue_delayed_work(REISERFS_SB(sb)->commit_wq,
+                                          &journal->j_work, HZ / 10);
+       }
 
        /*
         * if the next transaction has any chance of wrapping, flush
--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -100,7 +100,11 @@ void reiserfs_schedule_old_flush(struct
        struct reiserfs_sb_info *sbi = REISERFS_SB(s);
        unsigned long delay;
 
-       if (s->s_flags & MS_RDONLY)
+       /*
+        * Avoid scheduling flush when sb is being shut down. It can race
+        * with journal shutdown and free still queued delayed work.
+        */
+       if (s->s_flags & MS_RDONLY || !(s->s_flags & MS_ACTIVE))
                return;
 
        spin_lock(&sbi->old_work_lock);


Patches currently in stable-queue which might be from [email protected] are

queue-3.16/reiserfs-fix-corruption-introduced-by-balance_leaf-refactor.patch
queue-3.16/reiserfs-fix-use-after-free-in-journal-teardown.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to