Re: [PATCH 097/102] efivars: explicitly calculate length of VariableName

From: Lingzhu Xiang
Date: Wed Apr 10 2013 - 06:27:45 EST

On 04/10/2013 06:45 AM, Ben Hutchings wrote:
On Mon, 2013-04-08 at 10:50 +0100, Luis Henriques wrote: -stable review patch. If anyone has any objections, please let me know.


From: Matt Fleming <matt.fleming@xxxxxxxxx>

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 <fcrozat@xxxxxxxx>
Cc: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
Cc: Josh Boyer <jwboyer@xxxxxxxxxx>
Cc: Michael Schroeder <mls@xxxxxxxx>
Cc: Lee, Chun-Yi <jlee@xxxxxxxx>
Cc: Lingzhu Xiang <lxiang@xxxxxxxxxx>
Cc: Seiji Aguchi <seiji.aguchi@xxxxxxx>
Signed-off-by: Matt Fleming <matt.fleming@xxxxxxxxx>
[ 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.


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@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at