ACPI: OSL: Initialize output value

Buffer variable for result (value32) is not initialized.
This can lead to unexpected behavior, if underlying platform-specific
raw_pci_read fails to report error (uninitialized value will be treated
as valid pci-read result), or exposition of unexpected data to PCI 
config space reader.

Zeroing of buffer value addresses the later problem and makes the 
behavior in the former case somewhat more predictable.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: c5f0231ee6b0 ("ACPICA: Fix acpi_os_read_pci_configuration prototype")
Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
---
  drivers/acpi/osl.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

On Fri, Nov 10, 2023 at 8:45 PM Nikita Kiryushin <kiryushin@ancud.ru> wrote:
>
> Buffer variable for result (value32) is not initialized.
> This can lead to unexpected behavior, if underlying platform-specific
> raw_pci_read fails to report error (uninitialized value will be treated
> as valid pci-read result), or exposition of unexpected data to PCI
> config space reader.
>
> Zeroing of buffer value addresses the later problem and makes the
> behavior in the former case somewhat more predictable.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: c5f0231ee6b0 ("ACPICA: Fix acpi_os_read_pci_configuration prototype")
> Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
> ---
>   drivers/acpi/osl.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index c09cc3c68633..d3c0f7f01a29 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -788,7 +788,7 @@ acpi_os_read_pci_configuration(struct acpi_pci_id
> *pci_id, u32 reg,
>                                u64 *value, u32 width)
>   {
>         int result, size;
> -       u32 value32;
> +       u32 value32 = 0U;

So wouldn't it be better to avoid modifying *value at all if
raw_pci_read() returns an error?

And if it returns a success, why wouldn't it be trusted?

>         if (!value)
>                 return AE_BAD_PARAMETER;
> --

On 11/21/23 23:05, Rafael J. Wysocki wrote:
> So wouldn't it be better to avoid modifying *value at all if
> raw_pci_read() returns an error?

Avoiding of modification of *value at all seems better idea to me than 
setting it to arbitrary initializing value, indeed.

In that case, buffer initialization can be ditched, and *value set only 
in case of success.

> And if it returns a success, why wouldn't it be trusted?
>
My concern is, that raw_pci_read() wraps platform-specific handlers, 
that should conform to the next rules:

1) in case of success, they must set value32 (or else, uninitialized 
data would leak to acpi_os_read_pci_configuration caller);

2) they should use passed &value32 only to set it (or else, 
uninitialized data would be used/passed somewhere, is it safe?);

Is there any way to be sure, that all the existing and future 
platform-specific pci-read handlers conform?