From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Muhammad Bilal <meatuni001@gmail.com>
Cc: platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
hdegoede@redhat.com, jorge.lopez2@hp.com,
Thomas.Weissschuh@linutronix.de, superm1@kernel.org,
W_Armin@gmx.de, stable@vger.kernel.org
Subject: Re: [PATCH v3 2/4] platform/x86: hp-bioscfg: bound ordered-list parsing by the package count
Date: Wed, 8 Jul 2026 13:58:38 +0300 (EEST) [thread overview]
Message-ID: <25a18f2d-ce84-ad42-a779-54cec281a89c@linux.intel.com> (raw)
In-Reply-To: <20260707202111.35414-3-meatuni001@gmail.com>
On Wed, 8 Jul 2026, Muhammad Bilal wrote:
> hp_populate_ordered_list_elements_from_package() differs from the other
> per-type parsers: its main loop is bounded only by the fixed per-type
> count and never checks elem against the number of elements actually
> present in the package,
>
> for (elem = 1, eloc = 1; eloc < ORD_ELEM_CNT; elem++, eloc++)
>
> whereas the string, integer, enumeration and password parsers bound
> their main loop with "elem < count" as well.
>
> This is safe today because hp_init_bios_package_attribute() rejects any
> package with fewer than ORD_ELEM_CNT elements before the parser runs. A
> later patch relaxes that check to accept shorter packages;
An upcoming change, however, relaxes ...
> once this
> loop can be handed fewer than ORD_ELEM_CNT elements it indexes
> order_obj[elem] past the end of the array - an out-of-bounds heap read.
I don't think we need this part of the explanation, it will never happen
as you're fixing it beforehand. :-) So please drop it as unnecessary
detail.
It's pretty obvious to kernel developers anyway if there's a runaway index
so there's no big need in general to tell too simple basics like that.
> Bound the loop by the validated element count as well, so it stops at
> whichever comes first, the per-type count or the real package size,
>
> for (elem = 1, eloc = 1; eloc < ORD_ELEM_CNT && elem < order_obj_count;
> elem++, eloc++)
>
> order_obj_count is the validated count plumbed in by the previous
> patch. No functional change for packages that enumerate correctly
> today.
>
> Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg")
> Cc: stable@vger.kernel.org
> Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
> ---
> drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c b/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c
> index 83ddf99f93954..a50d074125268 100644
> --- a/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c
> +++ b/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c
> @@ -145,7 +145,7 @@ static int hp_populate_ordered_list_elements_from_package(union acpi_object *ord
> if (!order_obj)
> return -EINVAL;
>
> - for (elem = 1, eloc = 1; eloc < ORD_ELEM_CNT; elem++, eloc++) {
> + for (elem = 1, eloc = 1; eloc < ORD_ELEM_CNT && elem < order_obj_count; elem++, eloc++) {
>
> switch (order_obj[elem].type) {
> case ACPI_TYPE_STRING:
>
--
i.
next prev parent reply other threads:[~2026-07-08 10:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 20:21 [PATCH v3 0/4] platform/x86: hp-bioscfg: fix ACPI package handling on HP EliteBook 840 G2 Muhammad Bilal
2026-07-07 20:21 ` [PATCH v3 1/4] platform/x86: hp-bioscfg: pass validated element count to package parsers Muhammad Bilal
2026-07-08 10:54 ` Ilpo Järvinen
2026-07-07 20:21 ` [PATCH v3 2/4] platform/x86: hp-bioscfg: bound ordered-list parsing by the package count Muhammad Bilal
2026-07-08 10:58 ` Ilpo Järvinen [this message]
2026-07-07 20:21 ` [PATCH v3 3/4] platform/x86: hp-bioscfg: accept reduced ACPI packages from older HP BIOS Muhammad Bilal
2026-07-07 20:21 ` [PATCH v3 4/4] platform/x86: hp-bioscfg: warn on element type mismatch instead of failing Muhammad Bilal
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=25a18f2d-ce84-ad42-a779-54cec281a89c@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=Thomas.Weissschuh@linutronix.de \
--cc=W_Armin@gmx.de \
--cc=hdegoede@redhat.com \
--cc=jorge.lopez2@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=meatuni001@gmail.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=superm1@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.