Re: [PATCH for-5.10] spi: rpc-if: Fix use-after-free on unbind

[Lukas Wunner <lukas@xxxxxxxxx>]

On Mon, Nov 30, 2020 at 10:18:12PM +0300, Sergey Shtylyov wrote:
> On 11/29/20 2:35 PM, Lukas Wunner wrote:
> > > Not sure why spi_unregister_controller() drops the device reference
> > > while spi_register_controller() itself doesn't allocate the memory... 
> > 
> > Yes, that's exactly what I'm trying to move away from with
> > devm_spi_alloc_master() (introduced in v5.10-rc5 by 5e844cc37a5c).
> > The API as it has been so far has made it really easy to shoot oneself
> > in the foot.
> 
> Maybe it needs to be fixed, rather than using the managed device API?

devm_spi_alloc_master() *is* the fix, or at least a means to get there:

No longer dropping the reference in spi_unregister_controller() requires
that the drivers drop the reference.  So every single SPI driver needs to
be touched.  However, upon closer examination I've found tons of bugs in
the ->probe and ->remove hooks of SPI drivers, some of them related to
reference counting (leaks or use-after-free), others related to not
disabling clocks properly etc.  Ideally, the fixes for those bugs should
be backported to stable.

devm_spi_alloc_master() allows me to do that and at the same time it
allows stretching the migration across multiple releases.  That's because
spi_unregister_controller() auto-senses if devm_spi_alloc_master() was
used, and if so, it no longer drops a reference.

devm_spi_alloc_master() has the additional advantage of simplifying
probe error paths, as is apparent from the diffstat of the $subject patch:

 drivers/spi/spi-rpc-if.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

I think the vast majority of SPI drivers can be converted to
devm_spi_alloc_master() and the few that can't will be amended to
explicitly drop a reference.


> > > Perhaps the order of the calls in the remove() method could be reversed? 
> > 
> > I'm not familiar with power management on these Renesas controllers
> > but rpcif_disable_rpm() calls pm_runtime_put_sync(), which I assume
> > may put the controller to sleep.
> 
> Sigh, that's a stupid typo on my part, being fixed now to
> pm_runtim_disable()...

Okay in that case the order of the two calls in	rpcif_spi_remove()
won't matter, i.e. it would actually be possible to fix the UAF by
calling rpcif_disable_rpm() before spi_unregister_controller().

However, I still recommend fixing the UAF in the way proposed by
the $subject patch because of the simplified probe error path and
reduced LoC.


> > The only thing that looks confusing is that rpcif_enable_rpm() calls
> > pm_runtime_enable(), whereas rpcif_disable_rpm() calls
> > pm_runtime_put_sync().  That looks incongruent.
> 
> Do you need a link to the fix (it a whole patchset of minor fixes)?

I don't *need* it, but am happy to take a look.  Glad that I was able to
point out another bug. :)

Thanks,

Lukas