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-mysterious-emu-of-fertility-951c69@sudeepholla>
Date: Wed, 7 May 2025 12:52:18 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: "Heyne, Maximilian" <mheyne@...zon.de>
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 08:08:47PM +0000, Heyne, Maximilian wrote:
> 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.
> 

Just to understand, this node is absolutely processor node with no
private resources ? I find it hard to trust this as most of the CPUs
do have L1 I&D caches. If they were present the table can't abruptly end
like this.

-- 
Regards,
Sudeep