linux-kernel - Re: [syzbot] [mm?] WARNING in alloc_frozen_pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5288409.JjrPIszM2I@silver>
Date: Fri, 15 Aug 2025 15:17:45 +0200
From: Christian Schoenebeck <linux_oss@...debyte.com>
To: Harry Yoo <harry.yoo@...cle.com>,
 Dominique Martinet <asmadeus@...ewreck.org>
Cc: syzbot <syzbot+3f9768ec54c86997ddfb@...kaller.appspotmail.com>,
 akpm@...ux-foundation.org, apopple@...dia.com, byungchul@...com,
 david@...hat.com, gourry@...rry.net, joshua.hahnjy@...il.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, matthew.brost@...el.com,
 rakie.kim@...com, Eric Van Hensbergen <ericvh@...nel.org>,
 Latchesar Ionkov <lucho@...kov.net>, syzkaller-bugs@...glegroups.com,
 ying.huang@...ux.alibaba.com, ziy@...dia.com
Subject: Re: [syzbot] [mm?] WARNING in alloc_frozen_pages_noprof

On Wednesday, August 13, 2025 6:49:02 AM CEST Dominique Martinet wrote:
> Harry Yoo wrote on Wed, Aug 13, 2025 at 09:31:34AM +0900:
> > The warning is:
> > 
> > 	/*
> > 	 * There are several places where we assume that the order value is sane
> > 	 * so bail out early if the request is out of bound.
> > 	 */
> > 	if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp))
> > 		return NULL;
> > 
> > There's not much the buddy allocator can do when a user requests
> > order > MAX_PAGE_ORDER allocations.
> > 
> > >  alloc_pages_mpol+0x1e4/0x460 mm/mempolicy.c:2416
> > >  alloc_frozen_pages_noprof+0xe0/0x210 mm/mempolicy.c:2487
> > >  ___kmalloc_large_node+0xac/0x154 mm/slub.c:4306
> > >  __kmalloc_large_node_noprof+0x2c/0x8c mm/slub.c:4337
> > >  __do_kmalloc_node mm/slub.c:4353 [inline]
> > >  __kmalloc_noprof+0x3bc/0x4c8 mm/slub.c:4377
> > >  kmalloc_noprof include/linux/slab.h:909 [inline]
> > >  kzalloc_noprof include/linux/slab.h:1039 [inline]
> > >  v9fs_fid_get_acl+0x64/0x114 fs/9p/acl.c:32
> > 
> > So... 9p FS shouldn't really request that?
> > 
> > Cc'ing 9p FS folks.
> 
> Thanks for the Cc.
> 
> So, this comes up once in a while, everytime we discuss limiting the
> xattr size, then someone says we should do something else or I'm using
> the wrong define or I don't remember and then when I ask what we should
> do never reply again.
> 
> See [1] or [2] for the last two time this happened.
> [1] https://lore.kernel.org/all/20240304-xattr_maxsize-v1-1-322357ec6bdf@codewreck.org/T/#u
> [2] https://lore.kernel.org/lkml/20240202121319.21743-1-pchelkin@ispras.ru/
> 
> I'll be happy to take any patch you send (or one of the older patches if
> you tell me which is "correct"), I don't care anymore.
> 

Not that I would care much either, but as nobody else responded, I still think
the following is the way to go:

diff --git a/fs/9p/xattr.c b/fs/9p/xattr.c
index 8604e3377ee7..97f60b73bf16 100644
--- a/fs/9p/xattr.c
+++ b/fs/9p/xattr.c
@@ -37,8 +37,8 @@ ssize_t v9fs_fid_xattr_get(struct p9_fid *fid, const char *name,
 	if (attr_size > buffer_size) {
 		if (buffer_size)
 			retval = -ERANGE;
-		else if (attr_size > SSIZE_MAX)
-			retval = -EOVERFLOW;
+		else if (attr_size > KMALLOC_MAX_SIZE)
+			retval = -E2BIG;
 		else /* request to get the attr_size */
 			retval = attr_size;
 	} else {

---

Values > KMALLOC_MAX_SIZE are triggering the reported warning.

XATTR_SIZE_MAX (64k) would be much smaller than KMALLOC_MAX_SIZE (4M).

The call stack in question comes from ACL handling. In this case there is no 
XATTR_SIZE_MAX limit involved on 9p client side. If 9p server side does,
then server responds with an error anyway. If however server does not have
this limit then why limiting it to XATTR_SIZE_MAX on client side for all?

And if OTOH the call stack comes from the general purpose xattr API (i.e. not
ACL stuff), then there is already a XATTR_SIZE_MAX check on xattr VFS layer.
So no need to check for XATTR_SIZE_MAX on 9p layer for a 2nd time:

https://github.com/torvalds/linux/blob/d7ee5bdce7892643409dea7266c34977e651b479/fs/xattr.c#L616

In the end it is merely a theoretical issue. POSIX ACLs are quite compact
encoded into xattrs. To fill 64k you need a ridiculous large set of ACLs.

/Christian