An invalid server may reply with an xattr size which still fits into
ssize_t but is large enough to cause splat during kzalloc().
Add __GFP_NOWARN flag for the allocation. It seems client side can't do
much more about sanity checking here so it's better to return ENOMEM
silently.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Fixes: 85ff872d3f4a ("fs/9p: Implement POSIX ACL permission checking function")
Reported-by: [email protected]
Closes: https://lore.kernel.org/lkml/[email protected]/
Reported-by: [email protected]
Closes: https://lore.kernel.org/lkml/[email protected]/
Suggested-by: Pavel Skripkin <[email protected]>
Signed-off-by: Fedor Pchelkin <[email protected]>
---
fs/9p/acl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/9p/acl.c b/fs/9p/acl.c
index eed551d8555f..e19a46192d2e 100644
--- a/fs/9p/acl.c
+++ b/fs/9p/acl.c
@@ -29,7 +29,7 @@ static struct posix_acl *v9fs_fid_get_acl(struct p9_fid *fid, const char *name)
if (size == 0)
return ERR_PTR(-ENODATA);
- value = kzalloc(size, GFP_NOFS);
+ value = kzalloc(size, GFP_NOFS | __GFP_NOWARN);
if (!value)
return ERR_PTR(-ENOMEM);
--
2.43.0
Fedor Pchelkin wrote on Fri, Feb 02, 2024 at 03:13:17PM +0300:
> An invalid server may reply with an xattr size which still fits into
> ssize_t but is large enough to cause splat during kzalloc().
Ah, sorry for not replying to this earlier.. and I had forgotten about
it when something similar came up just now.
I've submitted a patch to limit such allocations to 64k:
https://lkml.kernel.org/r/[email protected]
Would you agree this makes this patch obsolete?
I'll go ahead and add the reported-by/closes you cited in this mail to
my commit.
--
Dominique Martinet | Asmadeus
On 24/03/04 10:09PM, Dominique Martinet wrote:
> Fedor Pchelkin wrote on Fri, Feb 02, 2024 at 03:13:17PM +0300:
> > An invalid server may reply with an xattr size which still fits into
> > ssize_t but is large enough to cause splat during kzalloc().
>
>
> Ah, sorry for not replying to this earlier.. and I had forgotten about
> it when something similar came up just now.
>
> I've submitted a patch to limit such allocations to 64k:
> https://lkml.kernel.org/r/[email protected]
>
> Would you agree this makes this patch obsolete?
Yes, thanks! Checking against the VFS limits is more appropriate.
>
> I'll go ahead and add the reported-by/closes you cited in this mail to
> my commit.
Okay.
--
Fedor