Message ID | 3e37f05c7593f1016f0a46de188b3357cbbd0c0b.1695060389.git.christophe.jaillet@wanadoo.fr |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp3110127vqi; Mon, 18 Sep 2023 20:41:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHKikEWJjjYdqx/nZ9jvKC4df0Q+vzfMyDTSaJz7JpXc4GTgFaC6U/mDJRMKtpFyAQDZd2c X-Received: by 2002:a17:90a:1189:b0:274:2523:fc7f with SMTP id e9-20020a17090a118900b002742523fc7fmr8697416pja.47.1695094908434; Mon, 18 Sep 2023 20:41:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695094908; cv=none; d=google.com; s=arc-20160816; b=C3krw8zIJqJ2aEjYLQh3x4aiYK3y5/2CG3pgwZTai8OmiOjzmiLnZKeWpntCgsoEkH i3JBEYDUunrzH1ysWhI1Swl7yCQqPwk7elgLSEB4h7XizulK0nq2IEwo2YccdwMkDvOe C9/45XRcVFrYQFjLlezHceqVarsu5PFzVdxeXPv/B3Odpgm9coG1nqX+uZxP/tDG8JeG 23bB5bnjsqZ2CU0FtfG8Zzjr1w5qDDXRFrEWCIOANG3p/BrklOXFzkwYTDFNo8Oh5Jy7 PM/KFL+2fOa7FOm4Rk08dBCaa/Umhc2HFr+OwEQCzYCZMAcluUC8+iQSI1fgYDNR2r6K k3Sg== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=d+X2wITyFfL/y+Yy8uB6Xs65leRLSEF6uVDE/v7+kls=; fh=HtaQOX9SV/BhkCkkWejtyHh7OYRPZfUh1ivts6rBaUs=; b=wQajlmJiLshRfLLWQFYuhOBLVodkSRx9PJfcnExfgr88FAFNOpIsESiDiKjK7Htm5/ 4ESS6XAOTPLQCmEzXMIkPV5etAvmdLDlxroRqZzYALSLiBrRqyPnFeU/Ar6WSu+MO2hf /GBOJEPJBWHbitXfPfg1fA10b3JnG7l1wy5JzEQ/hLzTabc8RqXBoHujrnYDOMHdpQge bPmaL7CNwu8N/Vw1GHamBYhd6FwwjuV+j60ZSvItbK6M3bMOFXZfsITsyG9wiEWYH3Qs VUewQqngtTAzZSKps54VW5KWZCnzwr3/5VD6tjyB/MLNEe6vHDwvTsGIK8TXN6dNE6nu IXvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=L1bEOuwO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wanadoo.fr Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id ot9-20020a17090b3b4900b00256d7cc5b67si9446738pjb.133.2023.09.18.20.41.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Sep 2023 20:41:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=L1bEOuwO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wanadoo.fr Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 56CDF80972B1; Mon, 18 Sep 2023 11:47:20 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229718AbjIRSrC (ORCPT <rfc822;kernel.ruili@gmail.com> + 25 others); Mon, 18 Sep 2023 14:47:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229784AbjIRSrB (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 18 Sep 2023 14:47:01 -0400 Received: from smtp.smtpout.orange.fr (smtp-17.smtpout.orange.fr [80.12.242.17]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23F5C109 for <linux-kernel@vger.kernel.org>; Mon, 18 Sep 2023 11:46:49 -0700 (PDT) Received: from pop-os.home ([86.243.2.178]) by smtp.orange.fr with ESMTPA id iJGfq2zsLGkZJiJGfqxMkN; Mon, 18 Sep 2023 20:46:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wanadoo.fr; s=t20230301; t=1695062806; bh=d+X2wITyFfL/y+Yy8uB6Xs65leRLSEF6uVDE/v7+kls=; h=From:To:Cc:Subject:Date; b=L1bEOuwOXWbx6/SttJuEJqrYcA9alZxHkKfVLjjvl+XixqZ4/xbo/VsEyz8I6RGp7 Tag+J0AAVIrMLJ52s103AV5YaUdi6IZNBPT8xs3HN8fybRllCblVgPZPmGRPAlDEVs kBx8CRvTcUIu6LiSqYue2Czilo6R42ki/2DI+3eTAWWqGJw+u0pk3IGtPXr9T0yS57 D19bErru1a31d+k8nJ5sqGwiaf/yhl3vMXtUeVKW9kM4IwZEDvWK6mQcIJwFmrJ6VK i73Fj9FxeOVbwurBKYYhlIUu0AAG9kLlCHa92qYkX3vp2Dh15WepmhTO5RNMLD9Kmr 1gQR11uX9XaOA== X-ME-Helo: pop-os.home X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Mon, 18 Sep 2023 20:46:46 +0200 X-ME-IP: 86.243.2.178 From: Christophe JAILLET <christophe.jaillet@wanadoo.fr> To: Gerd Hoffmann <kraxel@redhat.com>, Sumit Semwal <sumit.semwal@linaro.org>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, Daniel Vetter <daniel.vetter@ffwll.ch> Cc: linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Christophe JAILLET <christophe.jaillet@wanadoo.fr>, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org Subject: [PATCH] udmabuf: Fix a potential (and unlikely) access to unallocated memory Date: Mon, 18 Sep 2023 20:46:35 +0200 Message-Id: <3e37f05c7593f1016f0a46de188b3357cbbd0c0b.1695060389.git.christophe.jaillet@wanadoo.fr> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 18 Sep 2023 11:47:20 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777404884019330584 X-GMAIL-MSGID: 1777435838591241400 |
Series |
udmabuf: Fix a potential (and unlikely) access to unallocated memory
|
|
Commit Message
Christophe JAILLET
Sept. 18, 2023, 6:46 p.m. UTC
If 'list_limit' is set to a very high value, 'lsize' computation could
overflow if 'head.count' is big enough.
In such a case, udmabuf_create() will access to memory beyond 'list'.
Use size_mul() to saturate the value, and have memdup_user() fail.
Fixes: fbb0de795078 ("Add udmabuf misc device")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/dma-buf/udmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Le 18/09/2023 à 05:10, Gustavo A. R. Silva a écrit : > > > On 9/18/23 12:46, Christophe JAILLET wrote: >> If 'list_limit' is set to a very high value, 'lsize' computation could >> overflow if 'head.count' is big enough. >> >> In such a case, udmabuf_create() will access to memory beyond 'list'. >> >> Use size_mul() to saturate the value, and have memdup_user() fail. >> >> Fixes: fbb0de795078 ("Add udmabuf misc device") >> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> >> --- >> drivers/dma-buf/udmabuf.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c >> index c40645999648..fb4c4b5b3332 100644 >> --- a/drivers/dma-buf/udmabuf.c >> +++ b/drivers/dma-buf/udmabuf.c >> @@ -314,13 +314,13 @@ static long udmabuf_ioctl_create_list(struct >> file *filp, unsigned long arg) >> struct udmabuf_create_list head; >> struct udmabuf_create_item *list; >> int ret = -EINVAL; >> - u32 lsize; >> + size_t lsize; >> if (copy_from_user(&head, (void __user *)arg, sizeof(head))) >> return -EFAULT; >> if (head.count > list_limit) >> return -EINVAL; >> - lsize = sizeof(struct udmabuf_create_item) * head.count; >> + lsize = size_mul(sizeof(struct udmabuf_create_item), head.count); >> list = memdup_user((void __user *)(arg + sizeof(head)), lsize); >> if (IS_ERR(list)) >> return PTR_ERR(list); > > How about this, and we get rid of `lsize`: Keeping or removing lsize is mostly a matter of taste, I think. Using sizeof(*list) is better. Let see if there are some other comments, and I'll send a v2. Thanks for the feed-back. CJ > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index c40645999648..5cf9d849aaa8 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -314,14 +314,13 @@ static long udmabuf_ioctl_create_list(struct file > *filp, unsigned long arg) > struct udmabuf_create_list head; > struct udmabuf_create_item *list; > int ret = -EINVAL; > - u32 lsize; > > if (copy_from_user(&head, (void __user *)arg, sizeof(head))) > return -EFAULT; > if (head.count > list_limit) > return -EINVAL; > - lsize = sizeof(struct udmabuf_create_item) * head.count; > - list = memdup_user((void __user *)(arg + sizeof(head)), lsize); > + list = memdup_user((void __user *)(arg + sizeof(head)), > + size_mul(sizeof(*list), head.count)); > if (IS_ERR(list)) > return PTR_ERR(list); > > > -- > Gustavo >
On Mon, Sep 18, 2023 at 09:22:44PM +0200, Christophe JAILLET wrote: > Le 18/09/2023 à 05:10, Gustavo A. R. Silva a écrit : > > > > > > On 9/18/23 12:46, Christophe JAILLET wrote: > > > If 'list_limit' is set to a very high value, 'lsize' computation could > > > overflow if 'head.count' is big enough. > > > > > > In such a case, udmabuf_create() will access to memory beyond 'list'. > > > > > > Use size_mul() to saturate the value, and have memdup_user() fail. > > > > > > Fixes: fbb0de795078 ("Add udmabuf misc device") > > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > > --- > > > drivers/dma-buf/udmabuf.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > > > index c40645999648..fb4c4b5b3332 100644 > > > --- a/drivers/dma-buf/udmabuf.c > > > +++ b/drivers/dma-buf/udmabuf.c > > > @@ -314,13 +314,13 @@ static long udmabuf_ioctl_create_list(struct > > > file *filp, unsigned long arg) > > > struct udmabuf_create_list head; > > > struct udmabuf_create_item *list; > > > int ret = -EINVAL; > > > - u32 lsize; > > > + size_t lsize; > > > if (copy_from_user(&head, (void __user *)arg, sizeof(head))) > > > return -EFAULT; > > > if (head.count > list_limit) > > > return -EINVAL; > > > - lsize = sizeof(struct udmabuf_create_item) * head.count; > > > + lsize = size_mul(sizeof(struct udmabuf_create_item), head.count); > > > list = memdup_user((void __user *)(arg + sizeof(head)), lsize); > > > if (IS_ERR(list)) > > > return PTR_ERR(list); > > > > How about this, and we get rid of `lsize`: > > Keeping or removing lsize is mostly a matter of taste, I think. I'm on the fence, but kind of lean towards keeping lsize, but I think it's fine either way. > Using sizeof(*list) is better. That I agree with, yes. > Let see if there are some other comments, and I'll send a v2. I note that this looks like a use-case for the very recently proposed memdup_array_user(): https://lore.kernel.org/all/ACD75DAA-AF42-486C-B44B-9272EF302E3D@kernel.org/ (i.e. a built-in size_mul) -Kees
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index c40645999648..fb4c4b5b3332 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -314,13 +314,13 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg) struct udmabuf_create_list head; struct udmabuf_create_item *list; int ret = -EINVAL; - u32 lsize; + size_t lsize; if (copy_from_user(&head, (void __user *)arg, sizeof(head))) return -EFAULT; if (head.count > list_limit) return -EINVAL; - lsize = sizeof(struct udmabuf_create_item) * head.count; + lsize = size_mul(sizeof(struct udmabuf_create_item), head.count); list = memdup_user((void __user *)(arg + sizeof(head)), lsize); if (IS_ERR(list)) return PTR_ERR(list);