[PATCH] ACPI: APEI: EINJ: Validate length of the Vendor Error Type Extension structure

[PATCH] ACPI: APEI: EINJ: Validate length of the Vendor Error Type Extension structure

[Zenghui Yu]

Add a sanity check for the length field of the Vendor Error Type Extension
structure to guard against a buggy BIOS, in the same way einjv2_init()
checks the EINJv2 Extension length.

The BIOS on my machine provides a zeroed structure, so the length is 0 and
vendor_size in get_oem_vendor_struct() underflows to a huge value. The
vendor error data is then exposed to user sapce through the "oem_error"
debugfs file with that bogus size, and reading it walks out of the mapped
area and panics the kernel.

Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
---

The BIOS on my machine is obviously buggy (non-zero Vendor Extension offset
pointing to zeroed memory, and bit 31 is not set in the error type either)
and needs fixing. I'm not sure if it is necessary to add such a sanity
check for EINJ at all.

The PAGE_SIZE upper bound is borrowed from the EINJv2 check in
einjv2_init(). Not sure if it is reasonable here.

 drivers/acpi/apei/einj-core.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
index 1f3fa2278584..947f32812cfe 100644
--- a/drivers/acpi/apei/einj-core.c
+++ b/drivers/acpi/apei/einj-core.c
@@ -275,6 +275,12 @@ static void check_vendor_extension(u64 paddr,
 	if (!p)
 		return;
 	memcpy_fromio(&v, p, sizeof(v));
+	if (v.length < sizeof(v) || v.length > PAGE_SIZE) {
+		pr_warn(FW_BUG "Invalid vendor error extension length %u\n",
+			v.length);
+		acpi_os_unmap_iomem(p, sizeof(v));
+		return;
+	}
 	get_oem_vendor_struct(paddr, offset, &v);
 	sbdf = v.pcie_sbdf;
 	sprintf(vendor_dev, "%x:%x:%x.%x vendor_id=%x device_id=%x rev_id=%x\n",
-- 
2.33.0