linux-kernel - [PATCH 5.19 1074/1157] net/9p: Initialize the iounit field during fid creation

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220815180523.080296854@linuxfoundation.org>
Date:   Mon, 15 Aug 2022 20:07:10 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Tyler Hicks <tyhicks@...ux.microsoft.com>,
        Christian Schoenebeck <linux_oss@...debyte.com>,
        Dominique Martinet <asmadeus@...ewreck.org>,
        Sasha Levin <sashal@...nel.org>
Subject: [PATCH 5.19 1074/1157] net/9p: Initialize the iounit field during fid creation

From: Tyler Hicks <tyhicks@...ux.microsoft.com>

[ Upstream commit aa7aeee169480e98cf41d83c01290a37e569be6d ]

Ensure that the fid's iounit field is set to zero when a new fid is
created. Certain 9P operations, such as OPEN and CREATE, allow the
server to reply with an iounit size which the client code assigns to the
p9_fid struct shortly after the fid is created by p9_fid_create(). On
the other hand, an XATTRWALK operation doesn't allow for the server to
specify an iounit value. The iounit field of the newly allocated p9_fid
struct remained uninitialized in that case. Depending on allocation
patterns, the iounit value could have been something reasonable that was
carried over from previously freed fids or, in the worst case, could
have been arbitrary values from non-fid related usages of the memory
location.

The bug was detected in the Windows Subsystem for Linux 2 (WSL2) kernel
after the uninitialized iounit field resulted in the typical sequence of
two getxattr(2) syscalls, one to get the size of an xattr and another
after allocating a sufficiently sized buffer to fit the xattr value, to
hit an unexpected ERANGE error in the second call to getxattr(2). An
uninitialized iounit field would sometimes force rsize to be smaller
than the xattr value size in p9_client_read_once() and the 9P server in
WSL refused to chunk up the READ on the attr_fid and, instead, returned
ERANGE to the client. The virtfs server in QEMU seems happy to chunk up
the READ and this problem goes undetected there.

Link: https://lkml.kernel.org/r/20220710141402.803295-1-tyhicks@linux.microsoft.com
Fixes: ebf46264a004 ("fs/9p: Add support user. xattr")
Cc: stable@...r.kernel.org
Signed-off-by: Tyler Hicks <tyhicks@...ux.microsoft.com>
Reviewed-by: Christian Schoenebeck <linux_oss@...debyte.com>
Signed-off-by: Dominique Martinet <asmadeus@...ewreck.org>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---
 net/9p/client.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -886,16 +886,13 @@ static struct p9_fid *p9_fid_create(stru
 	struct p9_fid *fid;

 	p9_debug(P9_DEBUG_FID, "clnt %p\n", clnt);
-	fid = kmalloc(sizeof(*fid), GFP_KERNEL);
+	fid = kzalloc(sizeof(*fid), GFP_KERNEL);
 	if (!fid)
 		return NULL;

-	memset(&fid->qid, 0, sizeof(fid->qid));
 	fid->mode = -1;
 	fid->uid = current_fsuid();
 	fid->clnt = clnt;
-	fid->rdir = NULL;
-	fid->fid = 0;
 	refcount_set(&fid->count, 1);

 	idr_preload(GFP_KERNEL);