Re: About pci_ioremap_bar null dereference

Re: About pci_ioremap_bar null dereference

[Andy Shevchenko]

Cc'ed to Linux PCI ML in case somebody has better knowledge about.

On Fri, Jan 10, 2020 at 1:54 PM P J P <ppandit@redhat.com> wrote:
>
>    Hello Andy, Navid
>
>   -> https://git.kernel.org/linus/ea5ab2e422de0ef0fc476fe40f0829abe72684cd
>
> I was trying to understand this NULL dereference. IIUC, pci_ioremap_bar()
> returning NULL indicates insufficient memory OR if the pci device is
> configured to use I/O port address, instead of memory mapped region.
>
> I was wondering if(or how) it is reproducible for unprivileged user? Do you
> happen to have a reproducer for it?

It's very unlikely to see IRL such problem. Theoretically  it may
happen if the system in question has a LOT of devices connected to PCI
and suddenly there is no window for a resource left (usually 4k) under
PCI Root Bridge. Other than that I can't imagine what can go wrong.
Ah, of course the virtual space starvation is another possibility.


-- 
With Best Regards,
Andy Shevchenko

Re: About pci_ioremap_bar null dereference

[Bjorn Helgaas]

On Fri, Jan 10, 2020 at 02:10:22PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 10, 2020 at 1:54 PM P J P <ppandit@redhat.com> wrote:
> >
> >    Hello Andy, Navid
> >
> >   -> https://git.kernel.org/linus/ea5ab2e422de0ef0fc476fe40f0829abe72684cd
> >
> > I was trying to understand this NULL dereference. IIUC, pci_ioremap_bar()
> > returning NULL indicates insufficient memory OR if the pci device is
> > configured to use I/O port address, instead of memory mapped region.
> >
> > I was wondering if(or how) it is reproducible for unprivileged user? Do you
> > happen to have a reproducer for it?
> 
> It's very unlikely to see IRL such problem. Theoretically  it may
> happen if the system in question has a LOT of devices connected to PCI
> and suddenly there is no window for a resource left (usually 4k) under
> PCI Root Bridge. Other than that I can't imagine what can go wrong.
> Ah, of course the virtual space starvation is another possibility.

pci_ioremap_bar() can return NULL if the BAR is an I/O port BAR or if
it's a memory BAR but we haven't assigned space for it.  It's a good
idea to check the return value of pci_ioremap_bar().

ea5ab2e422de ("8250_lpss: check null return when calling
pci_ioremap_bar") looks like a valid patch to add that check.  My
guess is that the patch was prompted by a static checker like
Coverity, not by an observed problem.  In any event, this code is in a
quirk only used for Intel Quark SoC X1000 HS-UART devices.

drivers/dma/dw/core.c (for the Synopsys DesignWare DMA Controller)
*does* use that pointer via dma_readl(), but the references in the
commit log (drivers/dma/dw/core.c:1154 and drivers/dma/dw/core.c:1168)
are obsolete and not very useful.

Bjorn

Re: About pci_ioremap_bar null dereference

[P J P]

  Hello Andy, Bjorn,

+-- On Fri, 10 Jan 2020, Bjorn Helgaas wrote --+
| On Fri, Jan 10, 2020 at 02:10:22PM +0200, Andy Shevchenko wrote:
| > On Fri, Jan 10, 2020 at 1:54 PM P J P <ppandit@redhat.com> wrote:
| > >   -> https://git.kernel.org/linus/ea5ab2e422de0ef0fc476fe40f0829abe72684cd
| > >
| > > I was wondering if(or how) it is reproducible for unprivileged user? Do you
| > > happen to have a reproducer for it?
| > 
| > It's very unlikely to see IRL such problem. Theoretically  it may
| > happen if the system in question has a LOT of devices connected to PCI
| > and suddenly there is no window for a resource left (usually 4k) under
| > PCI Root Bridge. Other than that I can't imagine what can go wrong.
| > Ah, of course the virtual space starvation is another possibility.
| 
| pci_ioremap_bar() can return NULL if the BAR is an I/O port BAR or if it's a 
| memory BAR but we haven't assigned space for it.  It's a good idea to check 
| the return value of pci_ioremap_bar().

  It is good to check the return value.
 
| ea5ab2e422de ("8250_lpss: check null return when calling pci_ioremap_bar") 
| looks like a valid patch to add that check.  My guess is that the patch was 
| prompted by a static checker like Coverity, not by an observed problem.

  Right, likely.

| drivers/dma/dw/core.c (for the Synopsys DesignWare DMA Controller) *does* 
| use that pointer via dma_readl(), but the references in the commit log 
| (drivers/dma/dw/core.c:1154 and drivers/dma/dw/core.c:1168) are obsolete and 
| not very useful.

  I see, okay. Thank you for the information.

Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D