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

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

[Raul E Rangel]

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(-)

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)
-- 
2.21.0.1020.gf2820cf01a-goog

[PATCH 2/2] mmc: v4.14: Kill the request if the queuedata has been removed

[Raul E Rangel]

No reason to even try processing the request if the queue is shutting
down.

Signed-off-by: Raul E Rangel <rrangel@chromium.org>
---
This commit applies to v4.14.116.

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

 drivers/mmc/core/queue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 4bf1a9c6440b..28c9646a4de9 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -30,7 +30,7 @@ static int mmc_prep_request(struct request_queue *q, struct request *req)
 {
 	struct mmc_queue *mq = q->queuedata;
 
-	if (mq && (mmc_card_removed(mq->card) || mmc_access_rpmb(mq)))
+	if (!mq || mmc_card_removed(mq->card) || mmc_access_rpmb(mq))
 		return BLKPREP_KILL;
 
 	req->rq_flags |= RQF_DONTPREP;
-- 
2.21.0.1020.gf2820cf01a-goog

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

[Christoph Hellwig]

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.

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

[Raul Rangel]

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

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

[Raul Rangel]

> > 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