Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: P J P <ppandit@redhat.com>,
	linux-pci@vger.kernel.org,
	Navid Emamdoost <navid.emamdoost@gmail.com>
Subject: Re: About pci_ioremap_bar null dereference
Date: Fri, 10 Jan 2020 14:12:58 -0600	[thread overview]
Message-ID: <20200110201258.GA83593@google.com> (raw)
In-Reply-To: <CAHp75Ve4WhwqKft_7nMi5Ys9N4Fs98G1FgKxpKZ59e_UyCsKuw@mail.gmail.com>

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

  reply	other threads:[~2020-01-10 20:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <nycvar.YSQ.7.76.2001101712310.129933@xnncv>
2020-01-10 12:10 ` About pci_ioremap_bar null dereference Andy Shevchenko
2020-01-10 20:12   ` Bjorn Helgaas [this message]
2020-01-11  8:29     ` P J P

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200110201258.GA83593@google.com \
    --to=helgaas@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=navid.emamdoost@gmail.com \
    --cc=ppandit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox