[PATCH] clk: fixed: fix double free in resource managed fixed-factor clock

[Stephen Boyd]

Quoting Dmitry Baryshkov (2021-04-07 15:57:01)
> On Thu, 8 Apr 2021 at 01:41, Stephen Boyd <sboyd at kernel.org> wrote:
> >
> > Quoting Dmitry Baryshkov (2021-04-06 16:06:06)
> > > devm_clk_hw_register_fixed_factor_release(), the release function for
> > > the devm_clk_hw_register_fixed_factor(), calls
> > > clk_hw_unregister_fixed_factor(), which will kfree() the clock. However
> > > after that the devres functions will also kfree the allocated data,
> > > resulting in double free/memory corruption. Just call
> > > clk_hw_unregister() instead, leaving kfree() to devres code.
> > >
> > > Reported-by: Rob Clark <robdclark at chromium.org>
> > > Cc: Daniel Palmer <daniel at 0x0f.com>
> > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> > > ---
> > >
> > > Stephen, this fix affects the DSI PHY rework. Do we have a chance of
> > > getting it into 5.12, otherwise there will be a cross-dependency between
> > > msm-next and clk-next.
> >
> > Think I can get this into the last fixes PR. One question though, I
> > think this follows the pattern that things like clk-divider.c use for
> > devm. Are those also broken?
> 
> It looks so. See e.g. the devres_release() function. It calls
> (*release) callback, then it will kfree the resource.
> Also see Documentation/driver-api/driver-model/devres.rst, which does
> not kfree() in release functions.
> 
> Do you wish for me to send all the fixes?
> 

Yes please send more fixes. They're not high priority though so I'll
probably leave them to bake in next for a week or so.