summaryrefslogtreecommitdiffstats
path: root/fs/efivarfs
diff options
context:
space:
mode:
authorJean Delvare <jdelvare@suse.de>2015-03-20 09:59:47 +0100
committerMatt Fleming <matt.fleming@intel.com>2015-03-27 11:53:46 +0100
commitbfbaafae8519d82d10da6abe75f5766dd5b20475 (patch)
treed876c1735a8ea9718a3c6f5e122d5aee91547812 /fs/efivarfs
parentfirmware: dmi_scan: Fix dmi_len type (diff)
downloadlinux-bfbaafae8519d82d10da6abe75f5766dd5b20475.tar.xz
linux-bfbaafae8519d82d10da6abe75f5766dd5b20475.zip
firmware: dmi_scan: Prevent dmi_num integer overflow
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. This bug was introduced with the initial SMBIOS 3.0 support in commit fc43026278b2 ("dmi: add support for SMBIOS 3.0 64-bit entry point"). Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Matt Fleming <matt.fleming@intel.com> Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Cc: <stable@vger.kernel.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Diffstat (limited to 'fs/efivarfs')
0 files changed, 0 insertions, 0 deletions