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
| ||
|
Date: Wed, 8 Jan 2020 21:57:48 -0800 From: Doug Anderson <dianders@...omium.org> To: Matthias Kaehlcke <mka@...omium.org> Cc: Andy Gross <agross@...nel.org>, Mark Brown <broonie@...nel.org>, Girish Mahadevan <girishm@...eaurora.org>, linux-arm-msm <linux-arm-msm@...r.kernel.org>, linux-spi <linux-spi@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Stephen Boyd <swboyd@...omium.org>, Bjorn Andersson <bjorn.andersson@...aro.org> Subject: Re: [PATCH] spi: spi-qcom-qspi: Use device managed memory for clk_bulk_data Hi, On Wed, Jan 8, 2020 at 1:40 PM Matthias Kaehlcke <mka@...omium.org> wrote: > > Currrently the memory for the clk_bulk_data of the QSPI controller > is allocated with spi_alloc_master(). The bulk data pointer is passed > to devm_clk_bulk_get() which saves it in clk_bulk_devres->clks. When > the device is removed later devm_clk_bulk_release() is called and > uses the bulk data referenced by the pointer to release the clocks. > For this driver this results in accessing memory that has already > been freed, since the memory allocated with spi_alloc_master() is > released by spi_controller_release(), which is called before the > managed resources are released. > > Use device managed memory for the clock bulk data to fix the issue > described above. > > Signed-off-by: Matthias Kaehlcke <mka@...omium.org> > --- > > drivers/spi/spi-qcom-qspi.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) It's a little ugly, but it seems somewhat same. Basically we're saying that the caller of devm_clk_bulk_get() is in charge of keeping the list of clocks readable for the devm free function. Maybe we should also fix devm_clk_bulk_get() to always make a copy of the clocks so we can relax this limitation (though that's a lot of extra copying for the uncommon case), but even if we do change that your change would still be OK. ...so from my point of view: Reviewed-by: Douglas Anderson <dianders@...omium.org> -Doug
Powered by blists - more mailing lists