All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tristan Madani <tristmd@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>,
	Richard Weinberger <richard@nod.at>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org,
	Tristan Madani <tristan@talencesecurity.com>,
	syzbot+e84662c5f30b8c401437@syzkaller.appspotmail.com
Subject: [PATCH 1/3] jffs2: always stop garbage collection thread on unmount
Date: Fri,  1 May 2026 11:02:44 +0000	[thread overview]
Message-ID: <20260501110246.50647-1-tristmd@gmail.com> (raw)

From: Tristan Madani <tristan@talencesecurity.com>

jffs2_kill_sb() skips stopping the GC thread when the filesystem
is mounted read-only.  However, a filesystem can be remounted
read-only while the GC thread is still running.  In that case,
jffs2_stop_garbage_collect_thread() is never called, and the GC
thread continues to run after kfree(c), accessing freed memory.

The GC thread accesses c->gc_task, c->gc_mtd, and the full
jffs2_sb_info structure during jffs2_garbage_collect_pass().
After kfree(c), any of these accesses is a use-after-free.

Remove the sb_rdonly() check so the GC thread is always stopped
before freeing the superblock info.  jffs2_stop_garbage_collect_thread()
already handles the case where gc_task is NULL (no thread running),
so this is safe for the common case of a clean read-only mount.

Reported-by: syzbot+e84662c5f30b8c401437@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e84662c5f30b8c401437
Tested-by: syzbot+e84662c5f30b8c401437@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
 fs/jffs2/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 81396a092ba88..c846b435a38b6 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -345,7 +345,7 @@ static void jffs2_put_super (struct super_block *sb)
 static void jffs2_kill_sb(struct super_block *sb)
 {
 	struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
-	if (c && !sb_rdonly(sb))
+	if (c)
 		jffs2_stop_garbage_collect_thread(c);
 	kill_mtd_super(sb);
 	kfree(c);
-- 
2.47.3


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Tristan Madani <tristmd@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>,
	Richard Weinberger <richard@nod.at>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org,
	Tristan Madani <tristan@talencesecurity.com>,
	syzbot+e84662c5f30b8c401437@syzkaller.appspotmail.com
Subject: [PATCH 1/3] jffs2: always stop garbage collection thread on unmount
Date: Fri,  1 May 2026 11:02:44 +0000	[thread overview]
Message-ID: <20260501110246.50647-1-tristmd@gmail.com> (raw)

From: Tristan Madani <tristan@talencesecurity.com>

jffs2_kill_sb() skips stopping the GC thread when the filesystem
is mounted read-only.  However, a filesystem can be remounted
read-only while the GC thread is still running.  In that case,
jffs2_stop_garbage_collect_thread() is never called, and the GC
thread continues to run after kfree(c), accessing freed memory.

The GC thread accesses c->gc_task, c->gc_mtd, and the full
jffs2_sb_info structure during jffs2_garbage_collect_pass().
After kfree(c), any of these accesses is a use-after-free.

Remove the sb_rdonly() check so the GC thread is always stopped
before freeing the superblock info.  jffs2_stop_garbage_collect_thread()
already handles the case where gc_task is NULL (no thread running),
so this is safe for the common case of a clean read-only mount.

Reported-by: syzbot+e84662c5f30b8c401437@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e84662c5f30b8c401437
Tested-by: syzbot+e84662c5f30b8c401437@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
 fs/jffs2/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 81396a092ba88..c846b435a38b6 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -345,7 +345,7 @@ static void jffs2_put_super (struct super_block *sb)
 static void jffs2_kill_sb(struct super_block *sb)
 {
 	struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
-	if (c && !sb_rdonly(sb))
+	if (c)
 		jffs2_stop_garbage_collect_thread(c);
 	kill_mtd_super(sb);
 	kfree(c);
-- 
2.47.3


             reply	other threads:[~2026-05-01 11:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-01 11:02 Tristan Madani [this message]
2026-05-01 11:02 ` [PATCH 1/3] jffs2: always stop garbage collection thread on unmount Tristan Madani
2026-05-01 11:02 ` [PATCH 2/3] jffs2: clean up xattr refs in jffs2_del_ino_cache instead of BUG_ON Tristan Madani
2026-05-01 11:02   ` Tristan Madani
2026-05-01 11:02 ` [PATCH 3/3] jffs2: fix GC thread BUG_ON during reconfigure via fspick Tristan Madani
2026-05-01 11:02   ` Tristan Madani
2026-05-05 12:55 ` [PATCH 1/3] jffs2: always stop garbage collection thread on unmount Tristan Madani
2026-05-31 14:14   ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260501110246.50647-1-tristmd@gmail.com \
    --to=tristmd@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+e84662c5f30b8c401437@syzkaller.appspotmail.com \
    --cc=tristan@talencesecurity.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.