diff mbox series

[1/2] mmc: v4.14: Fix null pointer dereference in mmc_init_request

Message ID 20190508185833.187068-1-rrangel@chromium.org (mailing list archive)
State New, archived
Headers show
Series [1/2] mmc: v4.14: Fix null pointer dereference in mmc_init_request | expand

Commit Message

Raul Rangel May 8, 2019, 6:58 p.m. UTC
It is possible for queuedata to be cleared in mmc_cleanup_queue before
the request has been started. This will result in dereferencing a null
pointer.

Signed-off-by: Raul E Rangel <rrangel@chromium.org>
---
I think we should cherry-pick 41e3efd07d5a02c80f503e29d755aa1bbb4245de
https://lore.kernel.org/patchwork/patch/856512/ into 4.14. It fixes a
potential resource leak when shutting down the request queue. Once this
patch is applied, there is a potential for a null pointer dereference.
That's what this patch fixes. The next patch is just an optimization to
stop processing earlier.

See https://patchwork.kernel.org/patch/10925469/ for the initial
motivation.

This commit applies to v4.14.116.

This doesn't apply to 5.1 since mmc has been migrated to blk-mq.

Thanks,
Raul

 drivers/mmc/core/queue.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

Comments

Christoph Hellwig May 9, 2019, 6:04 a.m. UTC | #1
On Wed, May 08, 2019 at 12:58:32PM -0600, Raul E Rangel wrote:
> It is possible for queuedata to be cleared in mmc_cleanup_queue before
> the request has been started.

Errm.  I think we need to fix that problem instead of working around it.
Raul Rangel May 9, 2019, 6:42 p.m. UTC | #2
On Wed, May 08, 2019 at 11:04:56PM -0700, Christoph Hellwig wrote:
> On Wed, May 08, 2019 at 12:58:32PM -0600, Raul E Rangel wrote:
> > It is possible for queuedata to be cleared in mmc_cleanup_queue before
> > the request has been started.
> 
> Errm.  I think we need to fix that problem instead of working around it.
So mmc_request_fn already has a null check, it was just missing on
mmc_init_request.

I could move `blk_cleanup_queue(q)` above `q->queuedata = NULL` and the
lock. So that would mean cherry-picking
https://lore.kernel.org/patchwork/patch/856512/ and then a patch with
moving blk_cleanup_queue.

Should I do that instead?

Thanks,
Raul
Raul Rangel May 13, 2019, 5:19 p.m. UTC | #3
> > Errm.  I think we need to fix that problem instead of working around it.
> So mmc_request_fn already has a null check, it was just missing on
> mmc_init_request.
>
So I got 189650 random connect/disconnect iterations over the weekend
with these patches. I think they are fine. I'm going to send them to
stable@ unless anyone has any objections.

Thanks,
Raul
diff mbox series

Patch

diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 0a4e77a5ba33..4bf1a9c6440b 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -159,8 +159,14 @@  static int mmc_init_request(struct request_queue *q, struct request *req,
 {
 	struct mmc_queue_req *mq_rq = req_to_mmc_queue_req(req);
 	struct mmc_queue *mq = q->queuedata;
-	struct mmc_card *card = mq->card;
-	struct mmc_host *host = card->host;
+	struct mmc_card *card;
+	struct mmc_host *host;
+
+	if (!mq)
+		return -ENODEV;
+
+	card = mq->card;
+	host = card->host;
 
 	mq_rq->sg = mmc_alloc_sg(host->max_segs, gfp);
 	if (!mq_rq->sg)