linux-kernel - Re: [PATCH] PCI: iproc: fix resource allocation for BCMA PCIe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170208222736.GA9094@bhelgaas-glaptop.roam.corp.google.com>
Date:   Wed, 8 Feb 2017 16:27:36 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Abylay Ospan <aospan@...up.ru>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>, Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        Jon Mason <jonmason@...adcom.com>,
        bcm-kernel-feedback-list@...adcom.com, linux-pci@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Wenrui Li <wenrui.li@...k-chips.com>
Subject: Re: [PATCH] PCI: iproc: fix resource allocation for BCMA PCIe

On Wed, Feb 08, 2017 at 05:07:27PM -0500, Abylay Ospan wrote:
> Hi Bjorn,
> 
> I have checked first listed driver
> (drivers/pci/host/pcie-designware.c). Seems like into
> 'devm_request_pci_bus_resources' we supply same stack allocated 'res'
> (actual insert of this pointer to 'iomem_resource' was done inside
> '__request_resource'). This 'res' is not changed inside
> 'of_pci_get_host_bridge_resources'.
> I don't have this platforms on hand and cannot test it on real
> hadrware (to 100% verify). But investigating this code I see that the
> problem exist.
> 
> Here is a summary of flow for 'res' to show the problem:
> 
> pcie-designware.c:
>   LIST_HEAD(res);
>   ret = of_pci_get_host_bridge_resources(np, 0, 0xff, &res,
> &pp->io_base); <--- 'res' not changing here
>   ret = devm_request_pci_bus_resources(&pdev->dev, &res);
> 
>   drivers/pci/bus.c:
>     err = devm_request_resource(dev, parent, res);
> 
>     kernel/resource.c:
>       conflict = request_resource_conflict(root, new);
>         conflict = __request_resource(root, new);
>           *p = new;  <--- here we introduce stack allocated res into
> global 'iomem_resource'
> 
> 
> Please check and correct me if i'm wrong ?

The "res" in dw_pcie_host_init() is a list_head (not a struct
resource) and is on the stack.

When we call of_pci_get_host_bridge_resources(), we pass a pointer
("&res") to the empty list.  It kzallocs a struct resource for the bus
range and more for any bridge windows, and adds them to the list.

When we call devm_request_pci_bus_resources(), we pass a pointer
("&res") to the list, which is no longer empty.  It iterates through
the list and calls devm_request_resource() for each resource.  Inside
devm_request_pci_bus_resources(), "res" is the pointer to the resource
(not the list_head), and this resource is the one we kzalloc'd above.

When devm_request_resource() calls request_resource_conflict(), it
passes that pointer to the kzalloc'd resource (the pointer is called
"new" in devm_request_resource()).)

So when __request_resource() assigns "*p = new", it is copying a
pointer to a kzalloc'd struct resource.

This is certainly a twisty maze of similar names for different things,
but I think it is OK if the list_head is on the stack as long as the
struct resources are kzalloc'd.

> >   dw_pcie_host_init
> >     LIST_HEAD(res)                            # on stack
> >     of_pci_get_host_bridge_resources(np, 0, 0xff, &res, &pp->io_base)
> >       res = kzalloc()                         # different "res" from above!
> >       pci_add_resource_offset(resources, res, ...)
> >     devm_request_pci_bus_resources(&pdev->dev, &res)
> >     pci_scan_root_bus(pp->dev, pp->root_bus_nr, &dw_pcie_ops, pp, &res)
> >     error:
> >       pci_free_resource_list(&res)
> 
> > This looks good to me, but I don't think it's necessary to keep the
> > list_head in the struct iproc_pcie.  It should be safe to use
> > "LIST_HEAD(res)" on the stack like the other drivers do.  Can you
> > verify that and get an ack from Ray, Scott, or Jon?
> 
> if my investigation above is true then we need to keep 'res' all the
> time we working with the driver (or find another way to fix this
> issue).
> 
> -- 
> Abylay Ospan,
> NetUP Inc.
> http://www.netup.tv