Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp2925224rwb; Mon, 15 Aug 2022 14:10:12 -0700 (PDT) X-Google-Smtp-Source: AA6agR5CAMjx54wUYEp9Lb3lrXYa5BBAsj7gK34hdT2GXjDNdCKXVTsXAoVQYUJOgsPagLw1pdyb X-Received: by 2002:aa7:da10:0:b0:443:6bbd:a6ce with SMTP id r16-20020aa7da10000000b004436bbda6cemr11323295eds.191.1660597812802; Mon, 15 Aug 2022 14:10:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660597812; cv=none; d=google.com; s=arc-20160816; b=Ik0mrnysUzpOF5b//OAsAeSmj4ZsJVaWiHA96z01s/GS0e84LeuDtBOzUDlKRIXSEF BYBgGywF/JiEKt7LbuNqs/OPPkOn4133XZyo9pNRdrZ6gpCt3MU8rNRMEOpV06R+wFMx 81EqvQEmf2bgXGTTxkO/AyZaj8YAoeEaL81slSX0ihq3nbXjdJ/Ad0X8aUrOSB1kTIFK nfc/LPmRYLJnDYaeEGV6gujrKAOs2YVlUWveqiw9tBiAD4aNbVFcSTMKqW3nm/ucCEWP dYRu+9Ao2GnWo3f6KP5LtRDqsVlXfibporJoGC1FN9kTtfNa/xlQ66AjPBSnpq0RFyJR DcVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=likaoFnLOIfUy5MeWDBM1i5RpH6c+BfbpaqoqbglNM8=; b=0pCiwjsxRQ08hAgywNj50W0RKJoQnu1mWH7YG7csZtG5E1uW62zTGwf9kXQBHBZpQ0 2uai+YpdorhfXGFSMc6F9FSBd2Hq4ZmTCTy1b3YfDBR4KGw3E1oz+iPweQZENG5x8/nM Cq0EaIznMPIrm74EYAwSPpAYeeoQrzjaRiIDDsDNi3DRxtg91e4iwjnZzcCqybxMktv4 XHJnx2zLi4B4YR1S4HBLlRTEV3vqqrGjmzbYP0iwQn6QZu55jC8kHNUfpf9lCupmKE+O TRDFKEu1K1FPuFMIp0AnsXJXI4OmbeIrKW5dQV+fQCNfzq3SQBZoidOtuLCv6gx7ueLE XnqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="c6kOC/tI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hv18-20020a17090760d200b0073068883291si10203362ejc.836.2022.08.15.14.09.47; Mon, 15 Aug 2022 14:10:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="c6kOC/tI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345435AbiHOTyA (ORCPT + 99 others); Mon, 15 Aug 2022 15:54:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241834AbiHOTw5 (ORCPT ); Mon, 15 Aug 2022 15:52:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 434E174CF8; Mon, 15 Aug 2022 11:50:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D51A861124; Mon, 15 Aug 2022 18:50:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E398DC433C1; Mon, 15 Aug 2022 18:50:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660589449; bh=q44A+jOKC2968I3FZ8Bj23bK8j+2x2m6xVfyNM+BKh8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c6kOC/tI2MY9Ymwj2PtSwSPytNTKhNHooM1YTmK9R1S/SrgPlIqzGwdRscMGyGGy8 AA/VOn6hNyL1LUNxt2gVx2dE39llAMGW4boOxZ+hpzwkKmwxIL5nvy5lZEMpzRi5V6 d97m787wz2LuUfv98JQUlcaENXmXX6Z+zdthmMNU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tyler Hicks , Christian Schoenebeck , Dominique Martinet , Sasha Levin Subject: [PATCH 5.15 721/779] net/9p: Initialize the iounit field during fid creation Date: Mon, 15 Aug 2022 20:06:05 +0200 Message-Id: <20220815180408.290651873@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220815180337.130757997@linuxfoundation.org> References: <20220815180337.130757997@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Tyler Hicks [ 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@vger.kernel.org Signed-off-by: Tyler Hicks Reviewed-by: Christian Schoenebeck Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin --- net/9p/client.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) 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); -- 2.35.1