From: "Heyne, Maximilian" <mheyne@amazon.de>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: "stable@vger.kernel.org" <stable@vger.kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
Jeremy Linton <jeremy.linton@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ACPI/PPTT: fix off-by-one error
Date: Wed, 7 May 2025 11:56:48 +0000 [thread overview]
Message-ID: <20250507-blend-revel-3d94099b@mheyne-amazon> (raw)
In-Reply-To: <20250507-mysterious-emu-of-fertility-951c69@sudeepholla>
On Wed, May 07, 2025 at 12:52:18PM +0100, Sudeep Holla wrote:
> 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.
Yes looks like it. In our case the ACPI subtable has length 0x14 which is
exactly sizeof(acpi_pptt_processor).
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
next prev parent reply other threads:[~2025-05-07 11:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 13:13 [PATCH] ACPI/PPTT: fix off-by-one error Heyne, Maximilian
2025-05-06 13:43 ` Sudeep Holla
2025-05-06 20:08 ` Heyne, Maximilian
2025-05-07 11:52 ` Sudeep Holla
2025-05-07 11:56 ` Heyne, Maximilian [this message]
2025-05-07 12:30 ` Sudeep Holla
2025-05-07 12:35 ` Rafael J. Wysocki
2025-05-07 12:42 ` Heyne, Maximilian
2025-05-07 12:50 ` Rafael J. Wysocki
2025-05-07 13:01 ` Sudeep Holla
2025-05-07 12:56 ` Sudeep Holla
2025-05-07 14:29 ` Heyne, Maximilian
2025-05-07 15:12 ` Sudeep Holla
2025-05-06 20:11 ` Jeremy Linton
2025-05-07 11:53 ` Heyne, Maximilian
2025-05-07 11:59 ` Rafael J. Wysocki
2025-05-07 12:17 ` Heyne, Maximilian
2025-05-07 15:25 ` Jeremy Linton
2025-05-07 15:42 ` Rafael J. Wysocki
2025-05-07 15:51 ` Jeremy Linton
2025-05-07 16:12 ` Rafael J. Wysocki
2025-05-07 16:28 ` Sudeep Holla
2025-05-07 16:31 ` Jeremy Linton
2025-05-07 16:38 ` Jeremy Linton
2025-05-07 16:41 ` Jeremy Linton
2025-05-07 17:01 ` Rafael J. Wysocki
2025-05-07 17:35 ` Jeremy Linton
2025-05-07 17:59 ` Jeremy Linton
2025-05-07 15:47 ` Sudeep Holla
2025-05-07 15:52 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250507-blend-revel-3d94099b@mheyne-amazon \
--to=mheyne@amazon.de \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=jeremy.linton@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=stable@vger.kernel.org \
--cc=sudeep.holla@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox