kernel/drivers/firmware/dmi_scan.c, branch linux-6.9.y

firmware: dmi: Stop decoding on broken entry

2024-07-11T10:51:01Z

[ Upstream commit 0ef11f604503b1862a21597436283f158114d77e ] If a DMI table entry is shorter than 4 bytes, it is invalid. Due to how DMI table parsing works, it is impossible to safely recover from such an error, so we have to stop decoding the table. Signed-off-by: Jean Delvare Link: https://lore.kernel.org/linux-kernel/Zh2K3-HLXOesT_vZ@liuwe-devbox-debian-v2/T/ Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

firmware: dmi: Fortify entry point length checks

2022-09-23T12:53:14Z

Ensure that the SMBIOS entry point is long enough to include all the fields we need. Otherwise it is pointless to even attempt to verify its checksum. Also fix the maximum length check, which is technically 32, not 31. It does not matter in practice as the only valid values are 31 (for SMBIOS 2.x) and 24 (for SMBIOS 3.x), but let's still have the check right in case new fields are added to either structure in the future. Signed-off-by: Jean Delvare Reported-by: Linus Torvalds Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/lkml/20220823094857.27f3d924@endymion.delvare/T/

firmware: dmi: Use the proper accessor for the version field

2022-07-30T16:28:46Z

The byte at offset 6 represents length. Don't take it and drop it immediately by using proper accessor, i.e. get_unaligned_be24(). [JD: Change the subject to something less frightening] Signed-off-by: Andy Shevchenko Signed-off-by: Jean Delvare

ASoC: soc-core: fix DMI handling

2021-03-11T13:25:09Z

When DMI information is not present, trying to assign the card long name results in the following warning. WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name! The initial solution suggested was to test if the card device is an ACPI one. This causes a regression visible to userspace on all Intel platforms, with UCM unable to load card profiles based on DMI information: the card devices are not necessarily ACPI ones, e.g. when the parent creates platform devices on Intel devices. To fix this problem, this patch exports the existing dmi_available variable and tests it in the ASoC core. Fixes: c014170408bc ("ASoC: soc-core: Prevent warning if no DMI table is present") Signed-off-by: Pierre-Louis Bossart Reviewed-by: Takashi Iwai Acked-by: Jean Delvare Link: https://lore.kernel.org/r/20210310193928.108850-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

Replace HTTP links with HTTPS ones: DMI/SMBIOS SUPPORT

2020-07-16T09:46:24Z

Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov Signed-off-by: Jean Delvare

firmware/dmi: Report DMI Bios & EC firmware release

2020-06-06T09:35:50Z

Some vendors like HPe or Dell, encode the release version of their BIOS in the "System BIOS {Major|Minor} Release" fields of Type 0. This information is used to know which bios release actually runs. It could be used for some quirks, debugging sessions or inventory tasks. A typical output for a Dell system running the 65.27 bios is : [root@t1700 ~]# cat /sys/devices/virtual/dmi/id/bios_release 65.27 [root@t1700 ~]# Servers that have a BMC encode the release version of their firmware in the "Embedded Controller Firmware {Major|Minor} Release" fields of Type 0. This information is used to know which BMC release actually runs. It could be used for some quirks, debugging sessions or inventory tasks. A typical output for a Dell system running the 3.75 bmc release is : [root@t1700 ~]# cat /sys/devices/virtual/dmi/id/ec_firmware_release 3.75 [root@t1700 ~]# Signed-off-by: Erwan Velu Signed-off-by: Jean Delvare

firmware: dmi: Add macro SMBIOS_ENTRY_POINT_SCAN_START

2020-03-23T14:44:04Z

Use SMBIOS_ENTRY_POINT_SCAN_START instead of 0xF0000, because other archtecture maybe use a special start address such as 0xFFFE000 for Loongson platform. Signed-off-by: Tiezhu Yang Reviewed-by: Jean Delvare Signed-off-by: Thomas Bogendoerfer

firmware: dmi: Add dmi_memdev_handle

2019-12-03T10:20:37Z

Add a utility function dmi_memdev_handle() which returns the DMI handle associated with a given memory slot. This will allow kernel drivers to iterate over the memory slots. Signed-off-by: Jean Delvare

firmware: dmi: Remember the memory type

2019-12-03T10:20:37Z

Store the memory type while walking the memory slots, and provide a way to retrieve it later. Signed-off-by: Jean Delvare

firmware: dmi: Fix unlikely out-of-bounds read in save_mem_devices

2019-10-14T19:41:24Z

Before reading the Extended Size field, we should ensure it fits in the DMI record. There is already a record length check but it does not cover that field. It would take a seriously corrupted DMI table to hit that bug, so no need to worry, but we should still fix it. Signed-off-by: Jean Delvare Fixes: 6deae96b42eb ("firmware, DMI: Add function to look up a handle and return DIMM size") Cc: Tony Luck Cc: Borislav Petkov