Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp979557pxb; Wed, 3 Mar 2021 23:19:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJz9nGJY4zB6gs/TDP0uP4L9zKcccLzzo5szbD3MHtommOSncfMRap84yc4sICPKr8UmRD6v X-Received: by 2002:a17:906:1c13:: with SMTP id k19mr2702073ejg.457.1614842365468; Wed, 03 Mar 2021 23:19:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614842365; cv=none; d=google.com; s=arc-20160816; b=i9NXGqw11m3buvGAcU0KHk3cWosCT9DTTd0gLlkwz8dAy+GWhxx8No2QQpOiGng4cK K+FbQFivaXexWpKF0sdSvs+yjQyMUryqyyRcEo1gieuMBOAKKz7dt9Xa/YP+dCKieXWA i2IbbUs3JN/SGt4IoRPLeHQIdN9Qohrnta3O8ukoUtzJY/0zJfpHQOvBEUBXKac3NywZ 94u2jI74ZtziGo2A0Z7DwuxpLKi+LOwOAX3atxFZAPNaD7o6l4wx6/VsOzbM57Fz2lnO dFRkTuhU1TvJYLbRy4CwAHN0MqhuJyhjEdZsQhlHyNcM7AVChcD8RHU0Grfi4w33bDjd SX4w== 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 :references:in-reply-to:message-id:subject:cc:to:from:date; bh=EXYrUOxdbvzv66Qxr50yAi+MtlaD33oYRl6/1s8YmEI=; b=RmS9jpQRtYGQOc8gij6/twcsNwX9w6yPu1MVy4AUBOACqivToQuztV3SYO0YMV9aS1 z5XeDk8yrTOWziC9feLM3e2XsVlQT53v7VCFvFBoll6Do94LLiKzxhOmfabo1zBsiG/v rQefHsRWeUZe/mcJAg3dZCXq4IxVYucT6VxHroJUC76MivlkCVW2HYtngswASrz2nMM3 NxMwO8Ve3ZDwGTZFrkF+K9gA5CLgzK2BbdR2ZZNKUC10ZXpP8VFRPJECUeaMh4ll40Qy QxnRVHJuK4EAxw5oZwSkgfOz1wSSIauD9FmJzYFQuS4l3s11LRWAUn4Jcwbb1B/NTpjz xMig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id eb8si18709505edb.6.2021.03.03.23.18.59; Wed, 03 Mar 2021 23:19:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2360529AbhCBWVk (ORCPT + 99 others); Tue, 2 Mar 2021 17:21:40 -0500 Received: from einhorn-mail-out.in-berlin.de ([217.197.80.21]:37565 "EHLO einhorn-mail-out.in-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1384055AbhCBV3k (ORCPT ); Tue, 2 Mar 2021 16:29:40 -0500 X-Greylist: delayed 548 seconds by postgrey-1.27 at vger.kernel.org; Tue, 02 Mar 2021 16:29:39 EST X-Envelope-From: stefanr@s5r6.in-berlin.de Received: from authenticated.user (localhost [127.0.0.1]) by einhorn.in-berlin.de with ESMTPSA id 122LJC2r005582 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 2 Mar 2021 22:19:27 +0100 Date: Tue, 2 Mar 2021 22:19:11 +0100 From: Stefan Richter To: Dan Carpenter Cc: linux1394-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [PATCH] firewire: prevent integer overflow on 32bit systems Message-ID: <20210302221911.6c1582e2@kant> In-Reply-To: References: X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mar 02 Dan Carpenter wrote: > In TCODE_STREAM_DATA mode, on 32bit systems, the "sizeof(*e) + > request->length" operation can overflow leading to memory corruption. > > Fixes: 18e9b10fcdc0 ("firewire: cdev: add closure to async stream ioctl") > Signed-off-by: Dan Carpenter > --- > drivers/firewire/core-cdev.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/firewire/core-cdev.c b/drivers/firewire/core-cdev.c > index fb6c651214f3..314de0384035 100644 > --- a/drivers/firewire/core-cdev.c > +++ b/drivers/firewire/core-cdev.c > @@ -587,6 +587,9 @@ static int init_request(struct client *client, > request->length < 4) > return -EINVAL; > > + if (request->length > ULONG_MAX - sizeof(*e)) > + return -EINVAL; > + > e = kmalloc(sizeof(*e) + request->length, GFP_KERNEL); > if (e == NULL) > return -ENOMEM; There is already a length check for asynchronous stream requests. It happens in ioctl_send_stream_packet(). -- Stefan Richter -======--=-= --== ---=- http://arcgraph.de/sr/