Message ID | f75d0426a17b57dbddacd7da345c1c62a3dbb7ce.1708278363.git.christophe.jaillet@wanadoo.fr |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-70465-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp884383dyc; Sun, 18 Feb 2024 09:47:26 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVtez7MCjOd+VL41pMBM5UNDUhFNU87RSRsSy7gRTeXr1cEXNeoIOAwallaDnAJoNYegLdrrXEdKJkfxbXVNV/D2P6Mxg== X-Google-Smtp-Source: AGHT+IFe60arUJFECLuLzIvf44tLq8G10IkB20Y4wzS+/4sc2BBalZeZ/QHwTC9XLAsl/nP6BW/O X-Received: by 2002:a05:6808:1393:b0:3c1:4ddf:38cb with SMTP id c19-20020a056808139300b003c14ddf38cbmr5951469oiw.37.1708278446088; Sun, 18 Feb 2024 09:47:26 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708278446; cv=pass; d=google.com; s=arc-20160816; b=j+rnOGOUoY9Ov+0LcawFHAnkRza5A/C2/0f7BXZtU4k/TTCEp2jybD8DyXzydujuj5 rKv5FesDWberkqxQfLMeilXGdTkWZgo0dthYz5ew5MT+FMzqQfwj090ND3AI0re2A9Pg ebD+US8UYH22YfiVY8niHbjJMOwD7utgMPdFtzQDmecTbXZBRL2uWRwU57UfhLsIiVMF IM+7dBGC0AzrAkSZ213HDmS+PSyRX3942BOuqsClJAYNXxmOI9db08RUwyGLN2N503dV WISZclfSaloNEXQmB7tZ3EqueuyDOXIJ+kX9CudQq+2wWOtU/7omMlok/dQbCIsX+M+g TByQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=y2+kKbrWEFY2/pmLK9szqs3+euOSxAcesJDdReAip00=; fh=ygYG+FZ7S+UcmpM265p8aiazood6sG0uLiuAEUUoOCo=; b=CufNXoMrDbRylzNCTo98BLR0NNz+t555K47bClGNe06pE4DTFXluWBdrJArDKQ35id SkYEhEoXuUJKpCJFRIynJMWmBtfA+hLngfH1RbAgnJdehyjZKv44GktDHgQEBaxzeo8L y1ywgh/HrmZIh1tMhZH8LWV+x4Ej5hcjnZ4yZC3KYGPjrQmOhTQI1w0PXXWF3R/2v9BX /L9hmrBZE7N8+kOEDSfMKro8gDrIij0uoIgglj1OSzzsFors4jCJnYr6JnBeDWHhcsaf yx96nX0Y0TM8kVd5KxErhVWuD7+rxXT55fBeuFPoYsftu6hMAxImcFDszpq0J2hdle1V CRIQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=SD9wlefO; arc=pass (i=1 spf=pass spfdomain=wanadoo.fr dkim=pass dkdomain=wanadoo.fr dmarc=pass fromdomain=wanadoo.fr); spf=pass (google.com: domain of linux-kernel+bounces-70465-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-70465-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=wanadoo.fr Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id g6-20020a0562141cc600b0068f0699ab3csi4583146qvd.400.2024.02.18.09.47.25 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Feb 2024 09:47:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-70465-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=SD9wlefO; arc=pass (i=1 spf=pass spfdomain=wanadoo.fr dkim=pass dkdomain=wanadoo.fr dmarc=pass fromdomain=wanadoo.fr); spf=pass (google.com: domain of linux-kernel+bounces-70465-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-70465-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=wanadoo.fr Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id DA2211C209DE for <ouuuleilei@gmail.com>; Sun, 18 Feb 2024 17:47:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B13C86F08F; Sun, 18 Feb 2024 17:47:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=wanadoo.fr header.i=@wanadoo.fr header.b="SD9wlefO" Received: from smtp.smtpout.orange.fr (smtp-19.smtpout.orange.fr [80.12.242.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 47C5B6E2C3 for <linux-kernel@vger.kernel.org>; Sun, 18 Feb 2024 17:47:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.12.242.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708278428; cv=none; b=VJD0lVhhk5tcvhCsWYJ0jz/ej0+iStok+n8iEGd6zWyx0MfIU9dKG0pb85KpwHcP5kd0xsdRlHr0Dk67vpucue4R7R5JhE/7H3XP+t+2qDxTl8OoF1yUy9N0fDxXKx9LnZZhwNBJwAaoD+LgzSusUr70Z2056TV0Ayf9UXxWPnY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708278428; c=relaxed/simple; bh=72fk0PVXRZ8Q4JWxUxUYDfHppG9f2BAjRRu5pbDdVro=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=iiM6+p3ffeFXxnU8XQFXg3d2bgfouig1T3x5A13/OyvxD43KMGjramhIdLvBkHPFV/I4uqjS9RqXPLGf6oFt88gMie6hQ1WsVb1FG1w6ZM5LHSz5kBgW+mnysvq268zCO2CuF4zELyksTKBRQMXGl4mDS0FzVqhhzpPcoOQwWXs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wanadoo.fr; spf=pass smtp.mailfrom=wanadoo.fr; dkim=pass (2048-bit key) header.d=wanadoo.fr header.i=@wanadoo.fr header.b=SD9wlefO; arc=none smtp.client-ip=80.12.242.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wanadoo.fr Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wanadoo.fr Received: from fedora.home ([92.140.202.140]) by smtp.orange.fr with ESMTPA id blFbr8qYHiCLsblFer7StJ; Sun, 18 Feb 2024 18:46:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wanadoo.fr; s=t20230301; t=1708278417; bh=y2+kKbrWEFY2/pmLK9szqs3+euOSxAcesJDdReAip00=; h=From:To:Cc:Subject:Date; b=SD9wlefOwXg6avVhwSrVQdg+pRLNLNGc+ZUkn8lC/1XFjrHZc30uIj2jPvkEWP5cb wiHSjYsY5V2op+Ln67qbUlLXw/7k3gDzmSapsEgNjU2FE7ZQFZeRAuDAkPHNJi0+9i 3O0ClCSTsfy7DletOKheud1v1mlIm1LkH2827FumbJLNPbd7ozcZdiM34zTIQM6eIp iFy+zsBoGPfT58YXmqfV0/faepuFDWLu0whT+sljy78xCEZdC8SGTXALv3bim/xS+r z6Hjxmm8jvIpbKthLpg3OcdQEbqDKstm8BPQdu3EnvoPuV1rqWapIbUpBqLWwioruD Hs+GmnM6RYFgQ== X-ME-Helo: fedora.home X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Sun, 18 Feb 2024 18:46:57 +0100 X-ME-IP: 92.140.202.140 From: Christophe JAILLET <christophe.jaillet@wanadoo.fr> To: gustavo@embeddedor.com, keescook@chromium.org, 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-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 v2] udmabuf: Fix a potential (and unlikely) access to unallocated memory Date: Sun, 18 Feb 2024 18:46:44 +0100 Message-ID: <f75d0426a17b57dbddacd7da345c1c62a3dbb7ce.1708278363.git.christophe.jaillet@wanadoo.fr> X-Mailer: git-send-email 2.43.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791259779765345027 X-GMAIL-MSGID: 1791259779765345027 |
Series |
[v2] udmabuf: Fix a potential (and unlikely) access to unallocated memory
|
|
Commit Message
Christophe JAILLET
Feb. 18, 2024, 5: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() would access to memory beyond 'list'. Use memdup_array_user() which checks for overflow. While at it, include <linux/string.h>. Fixes: fbb0de795078 ("Add udmabuf misc device") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> --- v2: - Use memdup_array_user() [Kees Cook] - Use sizeof(*list) [Gustavo A. R. Silva] - Add include <linux/string.h> v1: https://lore.kernel.org/all/3e37f05c7593f1016f0a46de188b3357cbbd0c0b.1695060389.git.christophe.jaillet@wanadoo.fr/ Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> --- drivers/dma-buf/udmabuf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Comments
On Sun, Feb 18, 2024 at 06:46:44PM +0100, Christophe JAILLET wrote: > If 'list_limit' is set to a very high value, 'lsize' computation could > overflow if 'head.count' is big enough. > The "list_limit" is set via module parameter so if you set that high enough to lead to an integer overflow then you kind of deserve what you get. This patch is nice for kernel hardening and making the code easier to read/audit but the real world security impact is negligible. regards, dan carpenter
Le 19/02/2024 à 09:37, Dan Carpenter a écrit : > On Sun, Feb 18, 2024 at 06:46:44PM +0100, Christophe JAILLET wrote: >> If 'list_limit' is set to a very high value, 'lsize' computation could >> overflow if 'head.count' is big enough. >> > > The "list_limit" is set via module parameter so if you set that high > enough to lead to an integer overflow then you kind of deserve what > you get. > > This patch is nice for kernel hardening and making the code easier to > read/audit but the real world security impact is negligible. Agreed. That is what I meant by "and unlikely". Maybe the commit message could be more explicit if needed. Let me know if ok as-is or if I should try to re-word the description. CJ > > regards, > dan carpenter > > >
On 2/18/24 11: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() would access to memory beyond 'list'. > > Use memdup_array_user() which checks for overflow. > > While at it, include <linux/string.h>. > > Fixes: fbb0de795078 ("Add udmabuf misc device")' I don't think this tag is needed in this case. Also, please, CC linux-hardening next time. > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> In any case, LGTM: Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Thanks! -- Gustavo > --- > v2: - Use memdup_array_user() [Kees Cook] > - Use sizeof(*list) [Gustavo A. R. Silva] > - Add include <linux/string.h> > > v1: https://lore.kernel.org/all/3e37f05c7593f1016f0a46de188b3357cbbd0c0b.1695060389.git.christophe.jaillet@wanadoo.fr/ > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > --- > drivers/dma-buf/udmabuf.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index c40645999648..5728948ea6f2 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -11,6 +11,7 @@ > #include <linux/module.h> > #include <linux/shmem_fs.h> > #include <linux/slab.h> > +#include <linux/string.h> > #include <linux/udmabuf.h> > #include <linux/vmalloc.h> > #include <linux/iosys-map.h> > @@ -314,14 +315,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_array_user((void __user *)(arg + sizeof(head)), > + sizeof(*list), head.count); > if (IS_ERR(list)) > return PTR_ERR(list); >
On Mon, Feb 19, 2024 at 06:59:02PM +0100, Christophe JAILLET wrote: > Le 19/02/2024 à 09:37, Dan Carpenter a écrit : > > On Sun, Feb 18, 2024 at 06:46:44PM +0100, Christophe JAILLET wrote: > > > If 'list_limit' is set to a very high value, 'lsize' computation could > > > overflow if 'head.count' is big enough. > > > > > > > The "list_limit" is set via module parameter so if you set that high > > enough to lead to an integer overflow then you kind of deserve what > > you get. > > > > This patch is nice for kernel hardening and making the code easier to > > read/audit but the real world security impact is negligible. > > Agreed. > > That is what I meant by "and unlikely". > Maybe the commit message could be more explicit if needed. > > Let me know if ok as-is or if I should try to re-word the description. No, it's fine. But in the future if there is an integer overflow then lets mention in the commit message who it affects or what the impact is. regards, dan carpenter
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index c40645999648..5728948ea6f2 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -11,6 +11,7 @@ #include <linux/module.h> #include <linux/shmem_fs.h> #include <linux/slab.h> +#include <linux/string.h> #include <linux/udmabuf.h> #include <linux/vmalloc.h> #include <linux/iosys-map.h> @@ -314,14 +315,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_array_user((void __user *)(arg + sizeof(head)), + sizeof(*list), head.count); if (IS_ERR(list)) return PTR_ERR(list);