[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

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

[Luck, Tony]

> 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.

Production machine? Or just an internal development machine?  I.e. is this broken
BIOS out in the wild for others to hit this bug?

>
>
> +     if (v.length < sizeof(v) || v.length > PAGE_SIZE) {
> +             pr_warn(FW_BUG "Invalid vendor error extension length %u\n",

The "FW_BUG" tag was created specifically to point blame at BIOS and thus
encourage OEMs to fix their BIOS. So correct use of it here :-)

> +                     v.length);
> +             acpi_os_unmap_iomem(p, sizeof(v));
> +             return;
> +     }

The fix looks reasonable. If this has been seen on a production system, then
seems a good idea to apply your patch.

Reviewed-by: Tony Luck <tony.luck@intel.com>

-Tony

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

[Zenghui Yu]

Hi Tony,

On 2026/11/13 8:27, Luck, Tony wrote:
> > 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.
> 
> Production machine? Or just an internal development machine?  I.e. is this broken
> BIOS out in the wild for others to hit this bug?

The bug was hit on one of my development machines. The BIOS is pretty old.

$ cat /sys/class/dmi/id/bios_vendor 
Huawei Corp.
$ cat /sys/class/dmi/id/bios_date 
09/18/2019

I'm afraid that I can't tell whether this exact BIOS version ever shipped
on production machines.

So this patch may effectively just be a workaround for my old machine. I'll
leave the decision on whether it's worth taking to maintainers. ;-)

> >
> > +     if (v.length < sizeof(v) || v.length > PAGE_SIZE) {
> > +             pr_warn(FW_BUG "Invalid vendor error extension length %u\n",
> 
> The "FW_BUG" tag was created specifically to point blame at BIOS and thus
> encourage OEMs to fix their BIOS. So correct use of it here :-)
> 
> > +                     v.length);
> > +             acpi_os_unmap_iomem(p, sizeof(v));
> > +             return;
> > +     }
> 
> The fix looks reasonable. If this has been seen on a production system, then
> seems a good idea to apply your patch.
> 
> Reviewed-by: Tony Luck <tony.luck@intel.com>

Thanks for your review!

Zenghui

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

[Mauro Carvalho Chehab]

On Fri, 13 Nov 2026 00:27:20 +0000
"Luck, Tony" <tony.luck@intel.com> wrote:

> > 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.  
> 
> Production machine? Or just an internal development machine?  I.e. is this broken
> BIOS out in the wild for others to hit this bug?

As a reminder, any VM runs with a BIOS that is not produced by an OEM, and 
there are lots of production environments running VMs out there.

So, I'd say that, if the fix is good, better apply it.

From my side:

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


Thanks,
Mauro