On Mon, Nov 16, 2020 at 9:44 AM Lukas Wunner <lukas@xxxxxxxxx> wrote: > If the call to devm_spi_register_master() fails on probe of the GPIO SPI > driver, the spi_master struct is erroneously not freed: > > After allocating the spi_master, its reference count is 1. The driver > unconditionally decrements the reference count on unbind using a devm > action. Before calling devm_spi_register_master(), the driver > unconditionally increments the reference count because on success, > that function will decrement the reference count on unbind. However on > failure, devm_spi_register_master() does *not* decrement the reference > count, so the spi_master is leaked. > > The issue was introduced by commits 8b797490b4db ("spi: gpio: Make sure > spi_master_put() is called in every error path") and 79567c1a321e ("spi: > gpio: Use devm_spi_register_master()"), which sought to plug leaks > introduced by 9b00bc7b901f ("spi: spi-gpio: Rewrite to use GPIO > descriptors") but missed this remaining leak. > > The situation was later aggravated by commit d3b0ffa1d75d ("spi: gpio: > prevent memory leak in spi_gpio_probe"), which introduced a > use-after-free because it releases a reference on the spi_master if > devm_add_action_or_reset() fails even though the function already > does that. > > Fix by switching over to the new devm_spi_alloc_master() helper. > > Fixes: 9b00bc7b901f ("spi: spi-gpio: Rewrite to use GPIO descriptors") > Signed-off-by: Lukas Wunner <lukas@xxxxxxxxx> > Cc: <stable@xxxxxxxxxxxxxxx> # v4.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation > Cc: <stable@xxxxxxxxxxxxxxx> # v5.1-: 8b797490b4db: spi: gpio: Make sure spi_master_put() is called in every error path > Cc: <stable@xxxxxxxxxxxxxxx> # v5.1-: 45beec351998: spi: bitbang: Introduce spi_bitbang_init() > Cc: <stable@xxxxxxxxxxxxxxx> # v5.1-: 79567c1a321e: spi: gpio: Use devm_spi_register_master() > Cc: <stable@xxxxxxxxxxxxxxx> # v5.4-: d3b0ffa1d75d: spi: gpio: prevent memory leak in spi_gpio_probe > Cc: <stable@xxxxxxxxxxxxxxx> # v4.17+ > Cc: Navid Emamdoost <navid.emamdoost@xxxxxxxxx> > Cc: Andrey Smirnov <andrew.smirnov@xxxxxxxxx> > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> That's a really good fix. Thanks to looking into this! Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> Yours, Linus Walleij