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: <20250507-bruin-gavel-d3a9c0c0@mheyne-amazon>
Date: Wed, 7 May 2025 12:17:22 +0000
From: "Heyne, Maximilian" <mheyne@...zon.de>
To: "Rafael J. Wysocki" <rafael@...nel.org>
CC: Jeremy Linton <jeremy.linton@....com>, Sudeep Holla
	<sudeep.holla@....com>, "stable@...r.kernel.org" <stable@...r.kernel.org>,
	Len Brown <lenb@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, "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 Wed, May 07, 2025 at 01:59:12PM +0200, Rafael J. Wysocki wrote:
> On Wed, May 7, 2025 at 1:53???PM Heyne, Maximilian <mheyne@...zon.de> wrote:
> >
> > On Tue, May 06, 2025 at 03:11:20PM -0500, Jeremy Linton wrote:
> > > Hi,
> > >
> > > On 5/6/25 8:43 AM, 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?.
> > >
> > > More likely its because the sizeof() fix was merged without proper review
> > > and is wrong because the type isn't actually known on the object until the
> > > header is checked.
> >
> > I agree that the type might not be known at this point but the condition
> >
> >         proc_sz = sizeof(struct acpi_pptt_processor);
> >           while((unsigned long)entry + proc_sz <= table_end)
> >
> > would make sure that there could potentially be a node of type
> > acpi_pptt_processor because there is at least space for it. If the entry
> > can't be of that size because it would go over table_end then it can't
> > be an acpi_pptt_processor.
> 
> I don't follow.
> 
> If it is an acpi_pptt_processor entry, the original condition would be
> sufficient (assuming the correctness of the table header), wouldn't
> it?

On our hardware we have the following situation:
For CPU 63, the acpi_pptt_processor starts at 0xCAA and it has a length
of 0x14. The PPTT table has length 0xCBE. This is exactly the case I'm
describing. You're traversing the entries in the table and arrive at the
last entry but currently you exit the loop because 0xCAA + 0x14 ==
0xCBE (it's not < 0xCBE which is table_end). So you skip over the last
CPU node.

> 
> > Therefore, I don't think the sizeof() fix is that wrong but we just need
> > to adjust the while condition.
> 
> The sizeof() fix is correct, it makes the code work as designed.
> 
> > Alternatively, we could at least make sure that we can safely access
> > (without crossing table_end) the acpi_subtable_header to check the type.
> 
> Yes.
> 
> > But the current approach seems cleaner to me.
> 
> Why do you think so?

Because the first line in the loop casts straight to
acpi_pptt_processor. That's why I think it makes sense to check the
entry at which you arrived can actually be a acpi_pptt_processor
space-wise.



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