From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752997AbbCZNHA (ORCPT ); Thu, 26 Mar 2015 09:07:00 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:32801 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752333AbbCZNG4 (ORCPT ); Thu, 26 Mar 2015 09:06:56 -0400 Date: Thu, 26 Mar 2015 13:06:52 +0000 From: Matt Fleming To: Jean Delvare Cc: LKML , Matt Fleming , Ard Biesheuvel , Ivan Khoronzhuk Subject: Re: [PATCH] firmware: dmi_scan: Prevent dmi_num integer overflow Message-ID: <20150326130651.GC6525@codeblueprint.co.uk> References: <20150320095947.644f9c67@endymion.delvare> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150320095947.644f9c67@endymion.delvare> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Mar, at 09:59:47AM, Jean Delvare wrote: > dmi_num is a u16, dmi_len is a u32, so this construct: > > dmi_num = dmi_len / 4; > > would result in an integer overflow for a DMI table larger than > 256 kB. I've never see such a large table so far, but SMBIOS 3.0 > makes it possible so maybe we'll see such tables in the future. > > So instead of faking a structure count when the entry point does > not provide it, adjust the loop condition in dmi_table() to properly > deal with the case where dmi_num is not set. > > Signed-off-by: Jean Delvare > Cc: Matt Fleming > Cc: Ard Biesheuvel > Cc: Ivan Khoronzhuk > --- > drivers/firmware/dmi_scan.c | 22 +++++++--------------- > 1 file changed, 7 insertions(+), 15 deletions(-) Jean, are you taking this through your tree? -- Matt Fleming, Intel Open Source Technology Center