From nobody Sat Jun 20 04:59:54 2026 Received: from mx2.cyberprotect.ru (mx2.cyberprotect.ru [176.10.93.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEAD530EF95 for ; Mon, 20 Apr 2026 10:10:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=176.10.93.31 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776679849; cv=none; b=tt6eSGGqFAz15VlO5K4oCkFFLts2FZbDvVN4ZpOGT6PXhKOe9SYQWQrThsSNvcBqtdpdvk9BmT5cEJqNj8Wxj1YovhtNA1OIRKvQwWOwR+GMQrp9mqSJp76VEljZO3n4Y4Owa/O1o1ADQtDVJyDTk65ms53ouTvvxXnpFiFTDWw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776679849; c=relaxed/simple; bh=dd720mxHy2sI8K00hXllX9GCH3tuZTVH2nAU+taL0Is=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Hq6ZDfAKzKlh8rkb6k0VLrHICAIYmFLDPA7wJExaW9u5pY/179YrnuruqOTMi5qvg+bMoXod99iofLeEweWnP5TW1UmQ7EnCYQ3zvwFLjXorbq838B528EHq9p4QGXHVFLeS/a0z1oVOi8LKiZwwgkDgP949O+qG1swhQT8rBM0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=cyberprotect.ru; spf=pass smtp.mailfrom=cyberprotect.ru; dkim=pass (2048-bit key) header.d=cyberprotect.ru header.i=@cyberprotect.ru header.b=fDLa19TR; dkim=permerror (0-bit key) header.d=cyberprotect.ru header.i=@cyberprotect.ru header.b=cv3z6pPH; arc=none smtp.client-ip=176.10.93.31 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=cyberprotect.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cyberprotect.ru Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cyberprotect.ru header.i=@cyberprotect.ru header.b="fDLa19TR"; dkim=permerror (0-bit key) header.d=cyberprotect.ru header.i=@cyberprotect.ru header.b="cv3z6pPH" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cyberprotect.ru; s=dkim-r; h=MIME-Version:Date:From:Sender:Reply-To; bh=mz9CQHA7o3rjpRsMyGHAcvLiblzyf8jQKOq+34jl4L4=; b=fDLa19TRysc+mC0JjaI3mtxzP/ iZ41PqyJrcDwkvV0BeY1xC75rcoi4YS54WL8/l+ODGYrKquMZ/H8Y7LqF7OZ5OUHgfx5y4MZC68X0 XSrYOMHEW3dL7F2vo5Dd8Bt6L9TUL1vWPCBwz6M6NhBN5eqR3DLdTU9CgCHl7p0fe+IELgmpCNeUw vtM7xD2JXXjpbc8lRdcivrAiSJeRacEFn2q97zjmbatvcXsyQyDI2YXkrVtnoMycq/TNgsLkUyynZ mAJcDVioViyuF5fya/b5i0KtT4srlyZ3utAck3KWxUl2gjnxwtr0Tgx+UtgnqeV17+z5BB6A0KVye UT+YxVSg==; DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=cyberprotect.ru; s=dkim; h=MIME-Version:Date:From:Sender:Reply-To; bh=mz9CQHA7o3rjpRsMyGHAcvLiblzyf8jQKOq+34jl4L4=; b=cv3z6pPHaqKRLxByNnZndFu0E4 roSPNk5UTBAkwLvmp4HDHUoEofcKvcS7sXlea+JfYKxC5gR2o26UeWhmgpAQ==; From: Dmitriy Chumachenko To: David Woodhouse CC: Richard Weinberger , Al Viro , David Howells , , , Subject: [PATCH] jffs2: fix BUG_ON in jffs2_start_garbage_collect_thread on reconfigure Date: Mon, 20 Apr 2026 12:52:20 +0300 Message-ID: <20260420095220.18769-1-Dmitry.Chumachenko@cyberprotect.ru> X-Mailer: git-send-email 2.49.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: AIP-EXCH-1.aip.ooo (10.77.28.101) To AIP-EXCH-2.aip.ooo (10.77.28.102) Content-Type: text/plain; charset="utf-8" During fuzz testing, the following issue was discovered. kernel BUG at fs/jffs2/background.c:40! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5060 Comm: syz-executor108 Not tainted 6.8.0-syzkaller-08951-gf= e46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Goo= gle 03/27/2024 RIP: 0010:jffs2_start_garbage_collect_thread+0x1f5/0x200 fs/jffs2/backgroun= d.c:40 Call Trace: jffs2_do_remount_fs+0x15b/0x1d0 fs/jffs2/fs.c:415 reconfigure_super+0x445/0x880 fs/super.c:1071 vfs_cmd_reconfigure fs/fsopen.c:267 [inline] vfs_fsconfig_locked fs/fsopen.c:296 [inline] __do_sys_fsconfig fs/fsopen.c:476 [inline] __se_sys_fsconfig+0xab5/0xec0 fs/fsopen.c:349 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 When reconfiguring a mount without explicitly setting mount flags, fc->sb_flags and fc->sb_flags_mask are both zero. jffs2_do_remount_fs() skips stopping the GC thread because the superblock is read-only, but starts a new one because fc->sb_flags lacks SB_RDONLY. The superblock remains read-only, so on the next reconfigure the same path triggers BUG_ON(c->gc_task) since the previous thread is still running. Fix this by computing the effective new superblock flags using the same formula as reconfigure_super() so the start decision reflects the actual future state of the superblock. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: ec10a24f10c8 ("vfs: Convert jffs2 to use the new mount API") Signed-off-by: Dmitriy Chumachenko --- fs/jffs2/fs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c index d175cccb7c55..abfe6eead880 100644 --- a/fs/jffs2/fs.c +++ b/fs/jffs2/fs.c @@ -396,6 +396,8 @@ void jffs2_dirty_inode(struct inode *inode, int flags) int jffs2_do_remount_fs(struct super_block *sb, struct fs_context *fc) { struct jffs2_sb_info *c =3D JFFS2_SB_INFO(sb); + unsigned long s_flags_new =3D (sb->s_flags & ~fc->sb_flags_mask) | + (fc->sb_flags & fc->sb_flags_mask); =20 if (c->flags & JFFS2_SB_FLAG_RO && !sb_rdonly(sb)) return -EROFS; @@ -411,7 +413,7 @@ int jffs2_do_remount_fs(struct super_block *sb, struct = fs_context *fc) mutex_unlock(&c->alloc_sem); } =20 - if (!(fc->sb_flags & SB_RDONLY)) + if (!(s_flags_new & SB_RDONLY)) jffs2_start_garbage_collect_thread(c); =20 fc->sb_flags |=3D SB_NOATIME; --=20 2.49.0