Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936800Ab3DJK1m (ORCPT ); Wed, 10 Apr 2013 06:27:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17375 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751897Ab3DJK1l (ORCPT ); Wed, 10 Apr 2013 06:27:41 -0400 Message-ID: <51653E81.4090102@redhat.com> Date: Wed, 10 Apr 2013 18:27:13 +0800 From: Lingzhu Xiang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Hutchings , Luis Henriques , Seiji Aguchi CC: linux-kernel@vger.kernel.org, stable@vger.kernel.org, kernel-team@lists.ubuntu.com, Matthew Garrett , Josh Boyer , Michael Schroeder , "Lee, Chun-Yi" , Matt Fleming Subject: Re: [PATCH 097/102] efivars: explicitly calculate length of VariableName References: <1365414657-29191-1-git-send-email-luis.henriques@canonical.com> <1365414657-29191-98-git-send-email-luis.henriques@canonical.com> <1365547506.5814.36.camel@deadeye.wl.decadent.org.uk> In-Reply-To: <1365547506.5814.36.camel@deadeye.wl.decadent.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3000 Lines: 68 On 04/10/2013 06:45 AM, Ben Hutchings wrote: > On Mon, 2013-04-08 at 10:50 +0100, Luis Henriques wrote: >> 3.5.7.10 -stable review patch. If anyone has any objections, please let me know. >> >> ------------------ >> >> From: Matt Fleming >> >> commit ec50bd32f1672d38ddce10fb1841cbfda89cfe9a upstream. >> >> It's not wise to assume VariableNameSize represents the length of >> VariableName, as not all firmware updates VariableNameSize in the same >> way (some don't update it at all if EFI_SUCCESS is returned). There >> are even implementations out there that update VariableNameSize with >> values that are both larger than the string returned in VariableName >> and smaller than the buffer passed to GetNextVariableName(), which >> resulted in the following bug report from Michael Schroeder, >> >> > On HP z220 system (firmware version 1.54), some EFI variables are >> > incorrectly named : >> > >> > ls -d /sys/firmware/efi/vars/*8be4d* | grep -v -- -8be returns >> > /sys/firmware/efi/vars/dbxDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c >> > /sys/firmware/efi/vars/KEKDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c >> > /sys/firmware/efi/vars/SecureBoot-pport8be4df61-93ca-11d2-aa0d-00e098032b8c >> > /sys/firmware/efi/vars/SetupMode-Information8be4df61-93ca-11d2-aa0d-00e098032b8c >> >> The issue here is that because we blindly use VariableNameSize without >> verifying its value, we can potentially read garbage values from the >> buffer containing VariableName if VariableNameSize is larger than the >> length of VariableName. >> >> Since VariableName is a string, we can calculate its size by searching >> for the terminating NULL character. >> >> Reported-by: Frederic Crozat >> Cc: Matthew Garrett >> Cc: Josh Boyer >> Cc: Michael Schroeder >> Cc: Lee, Chun-Yi >> Cc: Lingzhu Xiang >> Cc: Seiji Aguchi >> Signed-off-by: Matt Fleming >> [ Backported for 3.4-stable. Removed workqueue code added in a93bc0c 3.9-rc1. ] > [...] > > I thought the workqueue addition was a worthwhile fix in its own right, > so for 3.2.y I cherry-picked that as well. FWIW, the workqueue patch is 1/2 of this patchset[1] fixing closely related problems. The other one is 81fa4e58. [1]: http://article.gmane.org/gmane.linux.kernel/1439570 I tried to avoid pulling too much for stable because the patchset is quite large and I suspect the problem it fixes is only theoretical. I reported the original bug but was unable to break anything except getting call traces with various CONFIG_DEBUG_*. What's your opinion, Seiji? Lingzhu Xiang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/