diff options
author | Jean Delvare <jdelvare@suse.de> | 2015-03-20 09:59:47 +0100 |
---|---|---|
committer | Matt Fleming <matt.fleming@intel.com> | 2015-03-27 11:53:46 +0100 |
commit | bfbaafae8519d82d10da6abe75f5766dd5b20475 (patch) | |
tree | d876c1735a8ea9718a3c6f5e122d5aee91547812 /fs/efivarfs | |
parent | firmware: dmi_scan: Fix dmi_len type (diff) | |
download | linux-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