On 7 December 2015 at 12:15, Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> wrote:
> MMC probe cleanup is racy: consider the following sequence:
>
> - mmc_alloc_host()
> - mmc_gpio_request_cd()
> - some failure
> - mmc_free_host()
>
> mmc_gpio_request_cd() registers a handler for the card detect GPIO
> signal, and if this is triggered, it can queue the delayed work in
mmc_gpio_request_cd() requests the GPIO, but doesn't request the IRQ.
Instead that's delayed until mmc_add_host() is called.
> struct mmc_host. mmc_free_host() then frees the mmc_host structure
> with the still queued delayed work, which will then cause the timer
> subsystem to touch free'd memory, potentially oopsing the kernel.
Because of the above, I don't think this can happen..
...unless there are some specific cases when hosts dealing with
registering the GPIO CD irq themselves, is that so?
>
> Fix this by ensuring that the delayed work is properly cancelled
> before freeing the underlying memory.
>
> Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx>
> ---
> drivers/mmc/core/host.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 5466f25f0281..b246803f2f1d 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -677,6 +677,7 @@ EXPORT_SYMBOL(mmc_remove_host);
> */
> void mmc_free_host(struct mmc_host *host)
> {
> + cancel_delayed_work_sync(&host->detect);
> mmc_pwrseq_free(host);
> put_device(&host->class_dev);
> }
> --
> 2.1.0
>
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
