| Message ID | E1a5tlb-0000UY-81@rmk-PC.arm.linux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 7 December 2015 at 12:15, Russell King <rmk+kernel@arm.linux.org.uk> 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@arm.linux.org.uk> > --- > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 07, 2015 at 05:10:29PM +0100, Ulf Hansson wrote: > On 7 December 2015 at 12:15, Russell King <rmk+kernel@arm.linux.org.uk> 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? This is over a year old, and I forget the details now. I'll drop the patch for now.
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); }
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 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. Fix this by ensuring that the delayed work is properly cancelled before freeing the underlying memory. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> --- drivers/mmc/core/host.c | 1 + 1 file changed, 1 insertion(+)