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: <20180227175756.GB12756@e107981-ln.cambridge.arm.com>
Date:   Tue, 27 Feb 2018 17:57:56 +0000
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Rolf Evers-Fischer <embedded24@...rs-fischer.de>
Cc:     kishon@...com, bhelgaas@...gle.com, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org, andy.shevchenko@...il.com,
        Rolf Evers-Fischer <rolf.evers.fischer@...iv.com>
Subject: Re: [PATCH v3 2/2] pci: endpoint: Fix kernel panic after put_device()

On Tue, Feb 27, 2018 at 11:02:30AM +0100, Rolf Evers-Fischer wrote:
> From: Rolf Evers-Fischer <rolf.evers.fischer@...iv.com>
> 
> 'put_device()' calls the relase function 'pci_epf_dev_release()',
> which already frees 'epf->name' and 'epf'.
> 
> Therefore we must not free them again after 'put_device()'.
> 
> Fixes: 5e8cb4033807 ("PCI: endpoint: Add EP core layer to enable EP controller and EP functions")
> 
> Signed-off-by: Rolf Evers-Fischer <rolf.evers.fischer@...iv.com>
> ---
>  drivers/pci/endpoint/pci-epf-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c
> index 1f2506f32bb9..1878a6776519 100644
> --- a/drivers/pci/endpoint/pci-epf-core.c
> +++ b/drivers/pci/endpoint/pci-epf-core.c
> @@ -232,7 +232,7 @@ struct pci_epf *pci_epf_create(const char *name)
>  
>  put_dev:
>  	put_device(dev);
> -	kfree(epf->name);
> +	return ERR_PTR(ret);

Another thing you could do, which would get rid of these multiple return
statements (yes there is another one) would consist in removing the goto
labels completely and handle the errors at the respective call site and
just return instead of jumping around.

Thanks,
Lorenzo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ