On Fri, May 12, 2023 at 01:56:29PM +0300, Andy Shevchenko wrote:
> On Tue, May 09, 2023 at 01:21:22PM -0500, Bjorn Helgaas wrote:
> > On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > > On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > > > Provide two new helper macros to iterate over PCI device resources and
> > > > convert users.
> >
> > > Applied 2-7 to pci/resource for v6.4, thanks, I really like this!
> >
> > This is 09cc90063240 ("PCI: Introduce pci_dev_for_each_resource()")
> > upstream now.
> >
> > Coverity complains about each use,
>
> It needs more clarification here. Use of reduced variant of the
> macro or all of them? If the former one, then I can speculate that
> Coverity (famous for false positives) simply doesn't understand `for
> (type var; var ...)` code.
True, Coverity finds false positives. It flagged every use in
drivers/pci and drivers/pnp. It didn't mention the arch/alpha, arm,
mips, powerpc, sh, or sparc uses, but I think it just didn't look at
those.
It flagged both:
pbus_size_io pci_dev_for_each_resource(dev, r)
pbus_size_mem pci_dev_for_each_resource(dev, r, i)
Here's a spreadsheet with a few more details (unfortunately I don't
know how to make it dump the actual line numbers or analysis like I
pasted below, so "pci_dev_for_each_resource" doesn't appear). These
are mostly in the "Drivers-PCI" component.
https://docs.google.com/spreadsheets/d/1ohOJwxqXXoDUA0gwopgk-z-6ArLvhN7AZn4mIlDkHhQ/edit?usp=sharing
These particular reports are in the "High Impact Outstanding" tab.
> > sample below from
> > drivers/pci/vgaarb.c. I didn't investigate at all, so it might be a
> > false positive; just FYI.
> >
> > 1. Condition screen_info.capabilities & (2U /* 1 << 1 */), taking true branch.
> > 556 if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
> > 557 base |= (u64)screen_info.ext_lfb_base << 32;
> > 558
> > 559 limit = base + size;
> > 560
> > 561 /* Does firmware framebuffer belong to us? */
> > 2. Condition __b < PCI_NUM_RESOURCES, taking true branch.
> > 3. Condition (r = &pdev->resource[__b]) , (__b < PCI_NUM_RESOURCES), taking true branch.
> > 6. Condition __b < PCI_NUM_RESOURCES, taking true branch.
> > 7. cond_at_most: Checking __b < PCI_NUM_RESOURCES implies that __b may be up to 16 on the true branch.
> > 8. Condition (r = &pdev->resource[__b]) , (__b < PCI_NUM_RESOURCES), taking true branch.
> > 11. incr: Incrementing __b. The value of __b may now be up to 17.
> > 12. alias: Assigning: r = &pdev->resource[__b]. r may now point to as high as element 17 of pdev->resource (which consists of 17 64-byte elements).
> > 13. Condition __b < PCI_NUM_RESOURCES, taking true branch.
> > 14. Condition (r = &pdev->resource[__b]) , (__b < PCI_NUM_RESOURCES), taking true branch.
> > 562 pci_dev_for_each_resource(pdev, r) {
> > 4. Condition resource_type(r) != 512, taking true branch.
> > 9. Condition resource_type(r) != 512, taking true branch.
> >
> > CID 1529911 (#1 of 1): Out-of-bounds read (OVERRUN)
> > 15. overrun-local: Overrunning array of 1088 bytes at byte offset 1088 by dereferencing pointer r. [show details]
> > 563 if (resource_type(r) != IORESOURCE_MEM)
> > 5. Continuing loop.
> > 10. Continuing loop.
> > 564 continue;
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
