Patch "net/9p: Initialize the iounit field during fid creation" has been added to the 5.15-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    net/9p: Initialize the iounit field during fid creation

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     net-9p-initialize-the-iounit-field-during-fid-creati.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 8822529cea86104c1bbae6788949871a68c2d490
Author: Tyler Hicks <tyhicks@xxxxxxxxxxxxxxxxxxx>
Date:   Sun Jul 10 09:14:02 2022 -0500

    net/9p: Initialize the iounit field during fid creation
    
    [ 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@xxxxxxxxxxxxxxxxxxx
    Fixes: ebf46264a004 ("fs/9p: Add support user. xattr")
    Cc: stable@xxxxxxxxxxxxxxx
    Signed-off-by: Tyler Hicks <tyhicks@xxxxxxxxxxxxxxxxxxx>
    Reviewed-by: Christian Schoenebeck <linux_oss@xxxxxxxxxxxxx>
    Signed-off-by: Dominique Martinet <asmadeus@xxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/9p/client.c b/net/9p/client.c
index 866f02e88c79..565aee6dfcc6 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -888,16 +888,13 @@ static struct p9_fid *p9_fid_create(struct p9_client *clnt)
 	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);



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux