Hi all,

While reviewing drivers/gpio/gpiolib-acpi-core.c in linux-next,
I noticed two bounds-checking issues in the ACPI GPIO handling paths.

The first issue is in acpi_gpio_adr_space_handler(), where the
64-bit ACPI OperationRegion address is truncated to u16 before
validation against pin_table_length. This can cause out-of-range
addresses to wrap around and access unintended GPIO entries.

Depending on platform firmware configuration, this could potentially
affect GPIO lines associated with sensitive hardware controls.

The second issue is in acpi_gpio_package_count(), where malformed
_DSD packages can cause pointer advancement past the package end
during element parsing, potentially resulting in out-of-bounds reads.

This series fixes both issues by:

- Validating the full address range before truncation
- Making the length calculation overflow-safe
- Validating remaining package elements before pointer advancement

The fixes are intentionally minimal and preserve the existing
behavior of capping ranges that extend past the end of the pin table.

Patch 1 also converts the related loop variables to unsigned types
for consistency with the updated arithmetic.

Thanks,
Marco

Marco Scardovi (2):
gpiolib: acpi: prevent address truncation in OperationRegion handler
gpiolib: acpi: fix out-of-bounds pointer arithmetic in
acpi_gpio_package_count

drivers/gpio/gpiolib-acpi-core.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)

--
2.54.0

On Sat, May 30, 2026 at 11:40:10AM +0200, Marco Scardovi wrote:

> While reviewing drivers/gpio/gpiolib-acpi-core.c in linux-next,
> I noticed two bounds-checking issues in the ACPI GPIO handling paths.
> 
> The first issue is in acpi_gpio_adr_space_handler(), where the
> 64-bit ACPI OperationRegion address is truncated to u16 before
> validation against pin_table_length. This can cause out-of-range
> addresses to wrap around and access unintended GPIO entries.
> 
> Depending on platform firmware configuration, this could potentially
> affect GPIO lines associated with sensitive hardware controls.
> 
> The second issue is in acpi_gpio_package_count(), where malformed
> _DSD packages can cause pointer advancement past the package end
> during element parsing, potentially resulting in out-of-bounds reads.
> 
> This series fixes both issues by:
> 
> - Validating the full address range before truncation
> - Making the length calculation overflow-safe
> - Validating remaining package elements before pointer advancement
> 
> The fixes are intentionally minimal and preserve the existing
> behavior of capping ranges that extend past the end of the pin table.
> 
> Patch 1 also converts the related loop variables to unsigned types
> for consistency with the updated arithmetic.

You got me lost. There was v3 of something, what is this?!

-- 
With Best Regards,
Andy Shevchenko

In data martedì 2 giugno 2026 09:52:46 Ora legale dell’Europa centrale, Andy 
Shevchenko ha scritto:
> On Sat, May 30, 2026 at 11:40:10AM +0200, Marco Scardovi wrote:
> > While reviewing drivers/gpio/gpiolib-acpi-core.c in linux-next,
> > I noticed two bounds-checking issues in the ACPI GPIO handling paths.
> > 
> > The first issue is in acpi_gpio_adr_space_handler(), where the
> > 64-bit ACPI OperationRegion address is truncated to u16 before
> > validation against pin_table_length. This can cause out-of-range
> > addresses to wrap around and access unintended GPIO entries.
> > 
> > Depending on platform firmware configuration, this could potentially
> > affect GPIO lines associated with sensitive hardware controls.
> > 
> > The second issue is in acpi_gpio_package_count(), where malformed
> > _DSD packages can cause pointer advancement past the package end
> > during element parsing, potentially resulting in out-of-bounds reads.
> > 
> > This series fixes both issues by:
> > 
> > - Validating the full address range before truncation
> > - Making the length calculation overflow-safe
> > - Validating remaining package elements before pointer advancement
> > 
> > The fixes are intentionally minimal and preserve the existing
> > behavior of capping ranges that extend past the end of the pin table.
> > 
> > Patch 1 also converts the related loop variables to unsigned types
> > for consistency with the updated arithmetic.
> 
> You got me lost. There was v3 of something, what is this?!

Hi Andy,

yes I messed up the patches on my side and made way too noise for my own, and 
yours, peace of mind. Please don't consider this thread anymore.