mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: Eric Van Hensbergen <ericvh@kernel.org>,
	Latchesar Ionkov <lucho@ionkov.net>,
	Dominique Martinet <asmadeus@codewreck.org>,
	Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>,
	syzbot+de6fd6789748a8aa64a0@syzkaller.appspotmail.com
Cc: v9fs@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 9p: bound the xattr size used to allocate the ACL buffer
Date: Sat, 19 Sep 2026 15:02:25 +0200	[thread overview]
Message-ID: <8777483.NyiUUSuA9g@weasel> (raw)
In-Reply-To: <20260919102958.142460-1-ngocthang2710.1999@gmail.com>

On Saturday, 19 September 2026 12:29:58 CEST Nguyen Ngoc Thang wrote:
> v9fs_fid_get_acl() sizes its kzalloc() buffer from the xattr length
> reported by the 9p server. A server, or a syzbot-style fake one, can
> report an arbitrarily large value. When it exceeds what the page
> allocator can serve, mounting with posixacl,access=client trips:
> 
>   WARNING: mm/page_alloc.c:5340 at __alloc_frozen_pages_noprof
>    ___kmalloc_large_node
>    v9fs_fid_get_acl
>    v9fs_get_acl
>    v9fs_inode_from_fid_dotl
>    v9fs_get_tree
> 
> A valid POSIX ACL always fits in an xattr value, so reject sizes above
> XATTR_SIZE_MAX. __v9fs_get_acl() already maps this error to -EIO.

What it currently does is calling kzalloc() and if that fails, it remaps the 
error to -EIO. However the Linux ACL subsystem does currently not impose its 
own limit, and therefore ACL size > XATTR_SIZE_MAX doesn't necessarily render 
it invalid, at least not if 9p server supports larger (9p) xattrs.

> Reported-by: syzbot+de6fd6789748a8aa64a0@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=de6fd6789748a8aa64a0
> Fixes: 85ff872d3f4a ("fs/9p: Implement POSIX ACL permission checking
> function") Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
> ---
>  fs/9p/acl.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/9p/acl.c b/fs/9p/acl.c
> index ae7e7cf7523a..0dd7e72bbdd3 100644
> --- a/fs/9p/acl.c
> +++ b/fs/9p/acl.c
> @@ -29,6 +29,9 @@ static struct posix_acl *v9fs_fid_get_acl(struct p9_fid
> *fid, const char *name) return ERR_PTR(size);
>  	if (size == 0)
>  		return ERR_PTR(-ENODATA);
> +	/* the size is server-controlled; a valid ACL fits in an xattr */
> +	if (size > XATTR_SIZE_MAX)
> +		return ERR_PTR(-E2BIG);

We already had related discussions about this before (without decision), i.e. 
XATTR_SIZE_MAX vs. KMALLOC_MAX_SIZE. Note the source location was different, 
but it is the same issue:

https://lore.kernel.org/all/Z1n-Ue19Pa_AWVu0@codewreck.org/

XATTR_SIZE_MAX < KMALLOC_MAX_SIZE

KMALLOC_MAX_SIZE is currently (already) the real effective upper bound, and 
therefore catching KMALLOC_MAX_SIZE here would basically just silence syzbot 
reports. The only actual reason to address this issue at all.

Capping to XATTR_SIZE_MAX here would make sense, assuming 9p server is a Linux 
system as well. But it may not be. So for non-Linux 9p servers (and for Linux 
9p servers that do not map 9p xattrs to filesystem xattrs) you would 
unnecessarily lower the size limit for ACLs, and ACLs can be huge.

> 
>  	value = kzalloc(size, GFP_NOFS);
>  	if (!value)



  reply	other threads:[~2026-09-19 13:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-19 10:29 Nguyen Ngoc Thang
2026-09-19 13:02 ` Christian Schoenebeck [this message]
2026-09-19 13:29   ` [PATCH v2] " Nguyen Ngoc Thang

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=8777483.NyiUUSuA9g@weasel \
    --to=linux_oss@crudebyte.com \
    --cc=asmadeus@codewreck.org \
    --cc=ericvh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=ngocthang2710.1999@gmail.com \
    --cc=syzbot+de6fd6789748a8aa64a0@syzkaller.appspotmail.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 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®