linux-kernel - Re: [PATCH] ACPI/PPTT: fix off-by-one error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250506-dialog-57th-c4e70064@mheyne-amazon>
Date: Tue, 6 May 2025 20:08:47 +0000
From: "Heyne, Maximilian" <mheyne@...zon.de>
To: Sudeep Holla <sudeep.holla@....com>
CC: "stable@...r.kernel.org" <stable@...r.kernel.org>, "Rafael J. Wysocki"
	<rafael@...nel.org>, Len Brown <lenb@...nel.org>, Ard Biesheuvel
	<ardb@...nel.org>, Jeremy Linton <jeremy.linton@....com>, Catalin Marinas
	<catalin.marinas@....com>, "linux-acpi@...r.kernel.org"
	<linux-acpi@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ACPI/PPTT: fix off-by-one error

On Tue, May 06, 2025 at 02:43:39PM +0100, Sudeep Holla wrote:
> On Tue, May 06, 2025 at 01:13:02PM +0000, Heyne, Maximilian wrote:
> > Commit 7ab4f0e37a0f ("ACPI PPTT: Fix coding mistakes in a couple of
> > sizeof() calls") corrects the processer entry size but unmasked a longer
> > standing bug where the last entry in the structure can get skipped due
> > to an off-by-one mistake if the last entry ends exactly at the end of
> > the ACPI subtable.
> >
> 
> Unless the firmware has populated an incorrect value for the header length, I
> don't see how this is possible. The table_end should point to the address
> immediately following the last byte of the table. None of the headers are only
> one byte long, so what am I missing that could explain this apparent
> off-by-one issue?.
> 
> -- 
> Regards,
> Sudeep

Maybe calling it off-by-one is not very exact. You're right table_end
points to the address following the last byte *but*
  (unsigned long)entry + proc_sz
also points to this very byte if it's the last entry. And in this case
the while condition is not taken which means we're ignoring the last
processor node.

For example, in our specific case the table has a length of 0xCBE and
the last processor node entry is at 0xCAA with a length of 0x14 fitting
exactly into the table but 0xCAA + 0x14 == 0xCBE which turns the
condition false.

Disclaimer: I'm not an expert in this topic but stumbled upon this bug
when looking at the latest kernels.

Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597