Linux block layer
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org
Subject: Re: UAF in blk_add_rq_to_plug()?
Date: Tue, 1 Nov 2022 00:54:13 +0000	[thread overview]
Message-ID: <Y2BuNekc14t35SpO@ZenIV> (raw)
In-Reply-To: <67fa977f-a490-4201-f56b-1e20d37c3863@kernel.dk>

On Mon, Oct 31, 2022 at 06:06:34PM -0600, Jens Axboe wrote:

> >> Am I missing something subtle here?  It's been a long time since
> >> I've read through that area - as the matter of fact, I'm trying
> >> to refresh my memories of the bio_submit()-related code paths
> >> at the moment...
> > 
> > With blk-mq, which all drivers are these days, the request memory is
> > statically allocated when the driver is setup. I'm not denying that you
> > could very well have issued AND completed the request which 'last'
> > points to by the time we dereference it, but that won't be a UAF unless
> > the device has also been quiesced and removed in between. Which I guess
> > could indeed be a possibility since it is by definition on a different
> > queue (->multiple_queues would be true, however, but that's also what
> > would be required to reach that far into that statement).
> > 
> > This is different from the older days of a request being literally freed
> > when it completes, which is what I initially reacted to.

Got it (and my memories of struct request lifetime rules had been stale,
indeed).  

> > As mentioned in the original reply, I do think we should just clear
> > 'last' as you suggest. But it's not something we've seen on the FB fleet
> > of servers, even with the majority of hosts running this code (and on
> > VMs).
> 
> Forgot to ask - do you want to send a patch for that, or do you just
> want me to cook one up with a reported-by for you?

You mean, try and put together a commit message for that one-liner? ;-)

[PATCH] blk_add_rq_to_plug(): 'last' is stale after flush, if we end up doing one

blk_mq_flush_plug_list() empties ->mq_list and request we'd peeked there
before that call is gone; in any case, we are not dealing with a mix
of requests for different queues now - there's no requests left in the
plug.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 8070b6c10e8d..a0e044a645b3 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1257,6 +1257,7 @@ static void blk_add_rq_to_plug(struct blk_plug *plug, struct request *rq)
 		   (!blk_queue_nomerges(rq->q) &&
 		    blk_rq_bytes(last) >= BLK_PLUG_FLUSH_SIZE)) {
 		blk_mq_flush_plug_list(plug, false);
+		last = NULL;
 		trace_block_plug(rq->q);
 	}
 

  reply	other threads:[~2022-11-01  0:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31 22:12 UAF in blk_add_rq_to_plug()? Al Viro
2022-10-31 22:42 ` Jens Axboe
2022-10-31 23:35   ` Al Viro
2022-11-01  0:03     ` Jens Axboe
2022-11-01  0:06       ` Jens Axboe
2022-11-01  0:54         ` Al Viro [this message]
2022-11-01  2:23           ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y2BuNekc14t35SpO@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox