mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Wang Yibo <szwyb123@gmail.com>
To: Dave Kleikamp <shaggy@kernel.org>
Cc: jfs-discussion@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
	syzbot+cea4fad5485bc30243a9@syzkaller.appspotmail.com
Subject: [PATCH] jfs: fix statfs racing with a read-write remount
Date: Mon, 02 Nov 2026 12:29:34 +0800	[thread overview]
Message-ID: <20261102123500.34-1-szwyb123@gmail.com> (raw)

jfs_remount() rebuilds the in-memory inode and block maps when a
read-only file system is remounted read-write, so that changes made by
fsck while the volume was read-only are picked up.  The rebuild frees
the old structures first and installs the new ones afterwards:

	diUnmount()  -> kfree(imap); JFS_IP(imap)->i_imap = NULL
	diMount()    -> ...;         JFS_IP(imap)->i_imap = imap
	dbUnmount()  -> kfree(bmp);  JFS_SBI(sb)->bmap = NULL
	dbMount()    -> ...;         JFS_SBI(sb)->bmap = bmp

jfs_statfs() reads both maps without taking any lock, so a statfs that
runs while the rebuild is in progress observes the NULL - or a pointer
to memory that has just been freed - and faults:

	BUG: KASAN: user-memory-access in jfs_statfs+0x20e/0x510
	Read of size 4 at addr 00000000000050c0 by task syz-executor415/5092
	...
	 jfs_statfs fs/jfs/super.c:140
	 __x64_sys_statfs

0x50c0 is offsetof(struct inomap, im_numinos) for the reporter's
configuration, i.e. i_imap was NULL when statfs() ran.

The inode map rebuild is already serialized by RDWRLOCK_IMAP, but that
only orders the inode map users among themselves; statfs() is not one of
them.  Take the same lock for reading in jfs_statfs() and keep the write
side held across the block map rebuild too, so that both maps are at all
times either the old or the new structures.  A failed rebuild can still
leave the maps torn down, so return -EIO instead of dereferencing NULL
in that case as well.

An earlier AI-generated RFC from syzbot proposed a different fix for
the same remount window; it was never reviewed and it does not cover the
report below.  It is linked only for context.

Reported-by: syzbot+cea4fad5485bc30243a9@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=cea4fad5485bc30243a9
Link: https://lore.kernel.org/all/80218035-7c1f-4784-93d1-c34d9ccc252a@mail.kernel.org/
Signed-off-by: Wang Yibo <szwyb123@gmail.com>
---
 fs/jfs/jfs_mount.c |  9 ++++++++-
 fs/jfs/super.c     | 17 ++++++++++++++++-
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/fs/jfs/jfs_mount.c b/fs/jfs/jfs_mount.c
index dac822f15070..19099b888b53 100644
--- a/fs/jfs/jfs_mount.c
+++ b/fs/jfs/jfs_mount.c
@@ -235,6 +235,12 @@ int jfs_mount_rw(struct super_block *sb, int remount)
 		truncate_inode_pages(sbi->ipimap->i_mapping, 0);
 		truncate_inode_pages(sbi->ipbmap->i_mapping, 0);
 
+		/*
+		 * Rebuild both maps under the inode map lock so that
+		 * statfs(), which reads them without any other means of
+		 * synchronization, never observes the window where the
+		 * old structures are torn down.
+		 */
 		IWRITE_LOCK(sbi->ipimap, RDWRLOCK_IMAP);
 		diUnmount(sbi->ipimap, 1);
 		if ((rc = diMount(sbi->ipimap))) {
@@ -242,13 +248,14 @@ int jfs_mount_rw(struct super_block *sb, int remount)
 			jfs_err("jfs_mount_rw: diMount failed!");
 			return rc;
 		}
-		IWRITE_UNLOCK(sbi->ipimap);
 
 		dbUnmount(sbi->ipbmap, 1);
 		if ((rc = dbMount(sbi->ipbmap))) {
+			IWRITE_UNLOCK(sbi->ipimap);
 			jfs_err("jfs_mount_rw: dbMount failed!");
 			return rc;
 		}
+		IWRITE_UNLOCK(sbi->ipimap);
 	}
 
 	/*
diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index 8180d83d33fe..7a8365fdf2b2 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
@@ -120,9 +120,23 @@ static int jfs_statfs(struct dentry *dentry, struct kstatfs *buf)
 {
 	struct jfs_sb_info *sbi = JFS_SBI(dentry->d_sb);
 	s64 maxinodes;
-	struct inomap *imap = JFS_IP(sbi->ipimap)->i_imap;
+	struct inomap *imap;
 
 	jfs_info("In jfs_statfs");
+
+	/*
+	 * A concurrent read-write remount tears down the in-memory inode
+	 * and block maps before installing the freshly built ones, leaving
+	 * them briefly NULL.  Exclude that window, and bail out if a failed
+	 * remount left us without maps at all.
+	 */
+	IREAD_LOCK(sbi->ipimap, RDWRLOCK_IMAP);
+	imap = JFS_IP(sbi->ipimap)->i_imap;
+	if (!imap || !sbi->bmap) {
+		IREAD_UNLOCK(sbi->ipimap);
+		return -EIO;
+	}
+
 	buf->f_type = JFS_SUPER_MAGIC;
 	buf->f_bsize = sbi->bsize;
 	buf->f_blocks = sbi->bmap->db_mapsize;
@@ -150,6 +164,7 @@ static int jfs_statfs(struct dentry *dentry, struct kstatfs *buf)
 				      sizeof(sbi->uuid)/2);
 
 	buf->f_namelen = JFS_NAME_MAX;
+	IREAD_UNLOCK(sbi->ipimap);
 	return 0;
 }
 
-- 
2.25.1



                 reply	other threads:[~2026-11-02  4:30 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20261102123500.34-1-szwyb123@gmail.com \
    --to=szwyb123@gmail.com \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaggy@kernel.org \
    --cc=syzbot+cea4fad5485bc30243a9@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®