Hi Andy,
On 14-Sep-25 3:24 PM, Andy Shevchenko wrote:
> On Sat, Sep 13, 2025 at 1:19 AM Hans de Goede <hansg@xxxxxxxxxx> wrote:
>>
>> Before commit 8b4f52ef7a41 ("gpiolib: acpi: Deduplicate some code in
>> __acpi_find_gpio()") and the follow-up fix commit 7c010d463372 ("gpiolib:
>> acpi: Make sure we fill struct acpi_gpio_info"). The struct acpi_gpio_info
>> used during lookups was part of struct acpi_gpio_lookup which gets
>> memset() to 0 before use.
>>
>> And then after a successful lookup, acpi_gpio_resource_lookup() would
>> copy the content of the zeroed acpi_gpio_lookup.info to the on
>> stack struct acpi_gpio_info in __acpi_find_gpio(), overwriting any
>> uninitialized memory contents there.
>>
>> But now instead a pointer to the on stack struct acpi_gpio_info in
>> __acpi_find_gpio() is passed around, but that struct is never
>> initialized.
>>
>> This passing around of the uninitialized struct breaks index based
>> lookups of GpioInt GPIOs because info->quirks now contains some random
>> on stack data which may contain ACPI_GPIO_QUIRK_ONLY_GPIOIO.
>>
>> Initialize the on stack struct acpi_gpio_info to 0 to fix this.
>
> Ah, very good catch! I missed that field that can have garbage as we
> don't file it. I'll take it on Monday and prepare a PR next week.
Thank you, but please take the more complete fix from Sébastien
available here:
https://lore.kernel.org/linux-gpio/20250912-gpiolib-acpi-fix-v1-1-1a41acbffadf@xxxxxxxxxxxx/
That also initializes a second case of an uninitialized
struct acpi_gpio_info on the stack.
Regards,
Hans
