Received: by 10.192.165.148 with SMTP id m20csp1964069imm; Sat, 28 Apr 2018 09:06:47 -0700 (PDT) X-Google-Smtp-Source: AB8JxZroQHoYiVuMyoLpz5kN8kFHZ3xEEFva1o0m0sssNEX7o6Oq2wddEai3efgpIpJDaB2EZMZ8 X-Received: by 10.98.254.17 with SMTP id z17mr6194264pfh.105.1524931607620; Sat, 28 Apr 2018 09:06:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524931607; cv=none; d=google.com; s=arc-20160816; b=zP7KjKz0RLeX60YSvdvBkOUQNy22wEBWhYVHhZygMJ2pDgJg+cB3pJrbvz5ZNwW8PF 87NYx6qGhbG7LO28XqWl+ZDr6neI3sOYYUK2wa/RfCSeJ5sYZoX9qisFn//29HWenJD9 VI0GgAv49hHKn525kexGW+m8bRWWZTpcEqdBzae2H20hrXTdB1DO+t472o8E4zGvYxxX J76jdIMYD4rIM2rGkA4JJdYpI3C74lXKiJ2Tf7V2+XNWENgfmXs8JupVEFmUWGqWcXu+ i6t21cedJCPFL25xVA1CvDzIq4Vpc41yxZfnsB2OUrjEIMt/N6TU/HrTC+bjm1Phf+ul aEVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-id:content-language:accept-language:in-reply-to:references :message-id:date:thread-index:thread-topic:subject:cc:to:from :arc-authentication-results; bh=2GLVDmGb4CJWPLIe2B7Im1MXHiyjmn6Zt+YNTyxPJMM=; b=fOqzyQhCM38EPrnAWLK1hxnhgZuauUr9tMimghMMO4m8m1c9cs8p0MvAzsAepPqeEg UI8Faajp0R9a9s9qnYWRCx3otrxgsBLfaFSFVz+i3FACFaoYwSQiaPe6p9npaWMYbkVY IU6v2pD7gEnQuxU3O/teycjcDnWv8LF4C8YUnipHyJK0BNAL4FuL7UsrrdSee6jZE8BN SScyWzvJA6jMHMoyk4uZRXICYmVMjDhF7l35+GPpacUjNRK7Yl3I8BecaWzSSGNSsbQ+ T854FvF84hJT3UYJvCBf3Qun01rZbZLs8K00FUwOjYHdDxVzmr8eiTA5UuuIZeYc+vQh JRuw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o1-v6si3606132plk.577.2018.04.28.09.06.19; Sat, 28 Apr 2018 09:06:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758246AbeD1QE3 convert rfc822-to-8bit (ORCPT + 99 others); Sat, 28 Apr 2018 12:04:29 -0400 Received: from mga04.intel.com ([192.55.52.120]:54449 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757827AbeD1QE1 (ORCPT ); Sat, 28 Apr 2018 12:04:27 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2018 09:04:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,339,1520924400"; d="scan'208";a="37172456" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga008.jf.intel.com with ESMTP; 28 Apr 2018 09:04:26 -0700 Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 28 Apr 2018 09:04:26 -0700 Received: from FMSMSX109.amr.corp.intel.com ([169.254.15.174]) by FMSMSX119.amr.corp.intel.com ([169.254.14.212]) with mapi id 14.03.0319.002; Sat, 28 Apr 2018 09:04:25 -0700 From: "Dilger, Andreas" To: Wenwen Wang CC: "kjlu@umn.edu" , "Drokin, Oleg" , James Simmons , Greg Kroah-Hartman , Ben Evans , Aastha Gupta , NeilBrown , Jeff Layton , Luis de Bethencourt , "lustre-devel@lists.lustre.org" , "devel@driverdev.osuosl.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] staging: luster: llite: fix a potential missing-check bug when copying lumv Thread-Topic: [PATCH] staging: luster: llite: fix a potential missing-check bug when copying lumv Thread-Index: AQHT3oHTyuO7iDQp7kKGVoSdfIZNdqQWzXsA Date: Sat, 28 Apr 2018 16:04:25 +0000 Message-ID: <8E6ADED8-592E-4794-8CAB-913A325B1971@intel.com> References: <1524872704-13391-1-git-send-email-wang6495@umn.edu> In-Reply-To: <1524872704-13391-1-git-send-email-wang6495@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.131.45] Content-Type: text/plain; charset="us-ascii" Content-ID: <61F80F78FCC96D46A01C694E3A7C6E13@intel.com> Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Apr 27, 2018, at 17:45, Wenwen Wang wrote: > [PATCH] staging: luster: llite: fix potential missing-check bug when copying lumv (typo) s/luster/lustre/ > In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space > using Its address, i.e., lumv1 = &lumv3. If the lmm_magic field of lumv3 is > LOV_USER_MAGIV_V3, lumv3 will be modified by the second copy from the user (typo) s/MAGIV/MAGIC/ > space. The second copy is necessary, because the two versions (i.e., > lov_user_md_v1 and lov_user_md_v3) have different data formats and lengths. > However, given that the user data resides in the user space, a malicious > user-space process can race to change the data between the two copies. By > doing so, the attacker can provide a data with an inconsistent version, > e.g., v1 version + v3 data. This can lead to logical errors in the > following execution in ll_dir_setstripe(), which performs different actions > according to the version specified by the field lmm_magic. This isn't a serious bug in the end. The LOV_USER_MAGIC_V3 check just copies a bit more data from userspace (the lmm_pool field). It would be more of a problem if the reverse was possible (copy smaller V1 buffer, but change the magic to LOV_USER_MAGIC_V3 afterward), but this isn't possible since the second copy is not done if there is a V1 magic. If the user changes from V3 magic to V1 in a racy manner it means less data will be used than copied, which is harmless. > This patch rechecks the version field lmm_magic in the second copy. If the > version is not as expected, i.e., LOV_USER_MAGIC_V3, an error code will be > returned: -EINVAL. This isn't a bad idea in any case, since it verifies the data copied from userspace is still valid. Cheers, Andreas > Signed-off-by: Wenwen Wang > --- > drivers/staging/lustre/lustre/llite/dir.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/staging/lustre/lustre/llite/dir.c b/drivers/staging/lustre/lustre/llite/dir.c > index d10d272..80d44ca 100644 > --- a/drivers/staging/lustre/lustre/llite/dir.c > +++ b/drivers/staging/lustre/lustre/llite/dir.c > @@ -1185,6 +1185,8 @@ static long ll_dir_ioctl(struct file *file, unsigned int cmd, unsigned long arg) > if (lumv1->lmm_magic == LOV_USER_MAGIC_V3) { > if (copy_from_user(&lumv3, lumv3p, sizeof(lumv3))) > return -EFAULT; > + if (lumv3.lmm_magic != LOV_USER_MAGIC_V3) > + return -EINVAL; > } > > if (is_root_inode(inode)) > -- > 2.7.4 > Cheers, Andreas -- Andreas Dilger Lustre Principal Architect Intel Corporation