From: Bjorn Helgaas <helgaas@kernel.org>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: Jingoo Han <jingoohan1@gmail.com>,
Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
linux-pci@vger.kernel.org, patchwork-lst@pengutronix.de,
kernel@pengutronix.de
Subject: Re: [PATCH] PCI: dwc: avoid OOB read in find_next_bit
Date: Fri, 12 Jul 2019 09:07:52 -0500 [thread overview]
Message-ID: <20190712140752.GE46935@google.com> (raw)
In-Reply-To: <20190712132611.3374-1-l.stach@pengutronix.de>
On Fri, Jul 12, 2019 at 03:26:11PM +0200, Lucas Stach wrote:
> Find_next_bit works on a long type, which causes a OOB read on the
> u32 input when used on ARM64.
s/Find_next_bit/find_next_bit()/ so it's obviously a function name and
we can directly grep for it (in subject also, and capitalize "Avoid").
Please spell out "OOB"; I *assume* that means "out of bounds"?
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/pci/controller/dwc/pcie-designware-host.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 77db32529319..81a2139d68d6 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -78,15 +78,16 @@ static struct msi_domain_info dw_pcie_msi_domain_info = {
> irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
> {
> int i, pos, irq;
> - u32 val, num_ctrls;
> + u32 num_ctrls;
> irqreturn_t ret = IRQ_NONE;
> + unsigned long val;
>
> num_ctrls = pp->num_vectors / MAX_MSI_IRQS_PER_CTRL;
>
> for (i = 0; i < num_ctrls; i++) {
> dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS +
> (i * MSI_REG_CTRL_BLOCK_SIZE),
> - 4, &val);
> + 4, (u32 *)&val);
I agree that the "val" we pass to find_next_bit() needs to be an
"unsigned long", so I like that part.
It's not completely obvious to me that it's safe to cast "val" to
"u32 *" here; does that do the right thing regardless of byte order?
Doing something like:
u32 status;
unsigned long val;
dw_pcie_rd_own_conf(..., &status);
val = status;
find_next_bit(&val, ...);
would be more obvious to me.
> if (!val)
> continue;
>
> --
> 2.20.1
>
prev parent reply other threads:[~2019-07-12 14:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-12 13:26 [PATCH] PCI: dwc: avoid OOB read in find_next_bit Lucas Stach
2019-07-12 13:54 ` Ahmad Fatoum
2019-07-12 14:07 ` Bjorn Helgaas [this message]
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=20190712140752.GE46935@google.com \
--to=helgaas@kernel.org \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=patchwork-lst@pengutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.