From: Christian Brauner <brauner@kernel.org>
To: Dominique Martinet <asmadeus@codewreck.org>
Cc: xingwei lee <xrivendell7@gmail.com>,
linux-kernel@vger.kernel.org, samsun1006219@gmail.com,
linux-fsdevel@vger.kernel.org, syzkaller@googlegroups.com,
jack@suse.cz, viro@zeniv.linux.org.uk,
Eric Van Hensbergen <ericvh@kernel.org>,
v9fs@lists.linux.dev
Subject: Re: WARNING in vfs_getxattr_alloc
Date: Mon, 4 Mar 2024 13:19:02 +0100 [thread overview]
Message-ID: <20240304-essverhalten-wortlaut-d4cc40939a3c@brauner> (raw)
In-Reply-To: <ZeW6a1OK-lhCbAf0@codewreck.org>
On Mon, Mar 04, 2024 at 09:11:23PM +0900, Dominique Martinet wrote:
> Christian Brauner wrote on Mon, Mar 04, 2024 at 12:50:12PM +0100:
> > > kernel: lastest linux 6.7.rc8 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
> > > kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=4a65fa9f077ead01
> > > with KASAN enabled
> > > compiler: gcc (GCC) 12.2.0
> > >
> > > TITLE: WARNING in vfs_getxattr_alloc------------[ cut here ]------------
> >
> > Very likely a bug in 9p. Report it on that mailing list. It seems that
> > p9_client_xattrwalk() returns questionable values for attr_size:
> > 748310584784038656
> > That's obviously a rather problematic allocation request.
>
> That's whatever the server requested -- in 9p we don't have the data at
> allocation time (xattrwalk returns the size, then we "read" it out in a
> subsequent request), so we cannot double-check that the size makes sense
> based on a payload at this point.
>
> We could obviously add a max (the current max of SSIZE_MAX is "a bit"
> too generous), but I honestly have no idea what'd make sense for this
> without breaking some weird usecase somewhere (given the content is
> "read" we're not limited by the size of a single message; I've seen
> someone return large content as synthetic xattrs so it's hard to put an
> actual number for me).
> If the linux VFS has a max hard-wired somewhere plase tell me and I'll
> be glad to change the max.
Surprisingly we have a max limit that exists in a way because the whole
xattr uapi is somewhat broken. So best to limit it at XATTR_SIZE_MAX.
See fs/xattr.c for how it's used.
prev parent reply other threads:[~2024-03-04 12:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABOYnLwY5Y499j=JgWtk9ksRneOzLoH_G9dYZTwXi=UvLbUsSg@mail.gmail.com>
2024-03-04 11:50 ` WARNING in vfs_getxattr_alloc Christian Brauner
2024-03-04 12:11 ` Dominique Martinet
2024-03-04 12:19 ` Christian Brauner [this message]
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=20240304-essverhalten-wortlaut-d4cc40939a3c@brauner \
--to=brauner@kernel.org \
--cc=asmadeus@codewreck.org \
--cc=ericvh@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=samsun1006219@gmail.com \
--cc=syzkaller@googlegroups.com \
--cc=v9fs@lists.linux.dev \
--cc=viro@zeniv.linux.org.uk \
--cc=xrivendell7@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).