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);
}
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.