From: Dominique Martinet <asmadeus@codewreck.org>
To: Edward Adam Davis <eadavis@qq.com>, Eric Sandeen <sandeen@redhat.com>
Cc: ericvh@kernel.org, linux-kernel@vger.kernel.org,
linux_oss@crudebyte.com, lucho@ionkov.net,
syzbot+30c83da54e948f6e9436@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com, v9fs@lists.linux.dev
Subject: Re: [PATCH next V2] 9p: Correct the session info
Date: Sat, 23 Aug 2025 15:34:12 +0900 [thread overview]
Message-ID: <aKlg5Ci4WC11GZGz@codewreck.org> (raw)
In-Reply-To: <tencent_85467F89852EDEEEF58C8F67D446F592F106@qq.com>
Edward Adam Davis wrote on Sat, Aug 23, 2025 at 07:22:13AM +0800:
> syz report a shift-out-of-bounds in v9fs_get_tree.
>
> This is because the maxdata value is 0, causing fls to return 32, meaning
> the s_blocksize_bits value is 32, which causes an out of bounds error.
> The root cause of this is incorrect session information obtained during
> fill super. Since v9ses is stored in sb, it is used directly.
Thanks for the patch.
Eric, ignore the other part of the thread -- I guess the int max limit
wasn't related...
What I'm not following now is how the v9ses is created/handled around
the new mount API:
- in v9fs_get_tree a v9ses is allocated and passed along in
fc->s_fs_info (that this patches now uses)
- but in v9fs_init_fs_context then a `v9fs_context` is created that
also embeds (not a pointer) a v9ses struct, which is accessed through
fc->fs_private as the code before this patch.
So at least for some time we have two v9ses which obviously don't hold
the same fields, and I'm not confident I can review which is used where
and when.
Now I probably should read up about the "new" mount API, but I don't
like that there are two v9ses around.
I don't have a clue about the fs_context lifetime: is it kept around all
the time the fs is mounted and can we rely on it to be present (and get
rid of the v9ses allocated in v9fs_get_tree), or is the context only a
temporary thing and we should avoid having a v9ses in there instead?
(I'd be tempted to think the later?)
Edward, thanks for investingating this; at this point I'm worried there
are other inconsistencies so I'll just remove the new mount API patches
from my -next branch instead of applying the patch, but this is really
appreciated.
> Fixes: 4d18c32a395d ("9p: convert to the new mount API")
> Reported-by: syzbot+30c83da54e948f6e9436@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=30c83da54e948f6e9436
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> V1 -> V2: remove the unused ctx
>
> fs/9p/vfs_super.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/9p/vfs_super.c b/fs/9p/vfs_super.c
> index f6065b5e0e5d..bcb6ebdb8037 100644
> --- a/fs/9p/vfs_super.c
> +++ b/fs/9p/vfs_super.c
> @@ -49,8 +49,7 @@ static int v9fs_set_super(struct super_block *s, struct fs_context *fc)
> static int v9fs_fill_super(struct super_block *sb, struct fs_context *fc)
> {
> int ret;
> - struct v9fs_context *ctx = fc->fs_private;
> - struct v9fs_session_info *v9ses = &ctx->v9ses;
> + struct v9fs_session_info *v9ses = sb->s_fs_info;
>
> sb->s_maxbytes = MAX_LFS_FILESIZE;
> sb->s_blocksize_bits = fls(v9ses->maxdata - 1);
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2025-08-23 6:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 2:58 [syzbot] [v9fs?] UBSAN: shift-out-of-bounds in v9fs_get_tree syzbot
2025-08-21 3:48 ` Dominique Martinet
2025-08-21 4:06 ` syzbot
2025-09-24 23:14 ` Eric Sandeen
2025-08-21 8:47 ` Hillf Danton
2025-08-21 9:23 ` syzbot
2025-08-22 13:31 ` Yuichiro Tsuji
2025-08-22 14:56 ` syzbot
2025-08-22 13:45 ` Yuichiro Tsuji
2025-08-22 17:47 ` syzbot
2025-08-22 14:27 ` Edward Adam Davis
2025-08-22 18:05 ` syzbot
2025-08-22 14:41 ` [PATCH next] 9p: Correct the session info Edward Adam Davis
2025-08-22 23:22 ` [PATCH next V2] " Edward Adam Davis
2025-08-23 6:34 ` Dominique Martinet [this message]
2025-09-24 22:19 ` Eric Sandeen
2025-09-25 2:17 ` Dominique Martinet
2025-09-25 4:29 ` Eric Sandeen
2025-09-25 7:24 ` Dominique Martinet
2025-09-28 4:00 ` Forwarded: Re: [syzbot] [v9fs?] UBSAN: shift-out-of-bounds in v9fs_get_tree syzbot
2025-09-28 19:04 ` syzbot
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=aKlg5Ci4WC11GZGz@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=eadavis@qq.com \
--cc=ericvh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=sandeen@redhat.com \
--cc=syzbot+30c83da54e948f6e9436@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=v9fs@lists.linux.dev \
/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.