From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752716AbbCZNPP (ORCPT ); Thu, 26 Mar 2015 09:15:15 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45560 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751673AbbCZNPM (ORCPT ); Thu, 26 Mar 2015 09:15:12 -0400 Subject: Re: [PATCH] firmware: dmi_scan: Prevent dmi_num integer overflow From: Jean Delvare To: Matt Fleming Cc: LKML , Matt Fleming , Ard Biesheuvel , Ivan Khoronzhuk In-Reply-To: <20150326130651.GC6525@codeblueprint.co.uk> References: <20150320095947.644f9c67@endymion.delvare> <20150326130651.GC6525@codeblueprint.co.uk> Content-Type: text/plain; charset="UTF-8" Organization: Suse Linux Date: Thu, 26 Mar 2015 14:15:05 +0100 Message-ID: <1427375705.4261.2.camel@chaos.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Matt, Le Thursday 26 March 2015 à 13:06 +0000, Matt Fleming a écrit : > 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? I don't actually have a tree, so feel free to pick it. Thanks, -- Jean Delvare SUSE L3 Support