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@xxxxxxxxxx> 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
