[PATCH] ALSA: ctxfi: Avoid writing uninitialized variable in uaa_to_xfi()

[PATCH] ALSA: ctxfi: Avoid writing uninitialized variable in uaa_to_xfi()

[Yizhuo Zhai]

Inside the function uaa_to_xfi(), variable "l_timer" could be
uninitialized if pci_bus_read_config_dword() returns
PCIBIOS_BAD_REGISTER_NUMBER. However, it is write back to PCI
config space via pci_write_config_dword(), which is potentially
unsafe.

Signed-off-by: Yizhuo <yzhai003@ucr.edu>
---
 sound/pci/ctxfi/cthw20k1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/ctxfi/cthw20k1.c b/sound/pci/ctxfi/cthw20k1.c
index 0cea4982ed7d..7c3436499974 100644
--- a/sound/pci/ctxfi/cthw20k1.c
+++ b/sound/pci/ctxfi/cthw20k1.c
@@ -1789,7 +1789,7 @@ static struct capabilities hw_capabilities(struct hw
*hw)
 static int uaa_to_xfi(struct pci_dev *pci)
 {
        unsigned int bar0, bar1, bar2, bar3, bar4, bar5;
-       unsigned int cmd, irq, cl_size, l_timer, pwr;
+       unsigned int cmd, irq, cl_size, l_timer = ~0, pwr;
        unsigned int is_uaa;
        unsigned int data[4] = {0};
        unsigned int io_base;
-- 
2.31.1

-- 
Kind Regards,

*Yizhuo Zhai*

*Computer Science, Graduate Student*
*University of California, Riverside *

Re: [PATCH] ALSA: ctxfi: Avoid writing uninitialized variable in uaa_to_xfi()

[Takashi Iwai]

On Mon, 19 Apr 2021 18:41:33 +0200,
Yizhuo Zhai wrote:
> 
> Inside the function uaa_to_xfi(), variable "l_timer" could be
> uninitialized if pci_bus_read_config_dword() returns
> PCIBIOS_BAD_REGISTER_NUMBER. However, it is write back to PCI
> config space via pci_write_config_dword(), which is potentially
> unsafe.

Thanks for the patch.  But it cannot be taken as is.

First off, practically seen, reading PCI_LATENCY_TIMER would never
fail.  And, even if it were to fail, it's not safer at all to proceed
with a value -1.

If any, it should return an error instead.  Also, there are a few
other similar PCI config reads and those have to be treated as well.
But it's likely not worth.  If it's a device that is used on VM, you
might have more chance to break something unexpectedly, but on a real
hardware, it's not.  And it's about the init sequence, which won't
bring to anything actually crashing the kernel.


Takashi

> 
> Signed-off-by: Yizhuo <yzhai003@ucr.edu>
> ---
>  sound/pci/ctxfi/cthw20k1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/pci/ctxfi/cthw20k1.c b/sound/pci/ctxfi/cthw20k1.c
> index 0cea4982ed7d..7c3436499974 100644
> --- a/sound/pci/ctxfi/cthw20k1.c
> +++ b/sound/pci/ctxfi/cthw20k1.c
> @@ -1789,7 +1789,7 @@ static struct capabilities hw_capabilities(struct hw
> *hw)
>  static int uaa_to_xfi(struct pci_dev *pci)
>  {
>         unsigned int bar0, bar1, bar2, bar3, bar4, bar5;
> -       unsigned int cmd, irq, cl_size, l_timer, pwr;
> +       unsigned int cmd, irq, cl_size, l_timer = ~0, pwr;
>         unsigned int is_uaa;
>         unsigned int data[4] = {0};
>         unsigned int io_base;
> -- 
> 2.31.1
> 
> --
> Kind Regards,
> 
> Yizhuo Zhai
> 
> Computer Science, Graduate Student
> University of California, Riverside 
> 
>