mbox series

[v7,0/8] blktrace: fix debugfs use after free

Message ID 20200619204730.26124-1-mcgrof@kernel.org (mailing list archive)
Headers show
Series blktrace: fix debugfs use after free | expand

Message

Luis Chamberlain June 19, 2020, 8:47 p.m. UTC
Its been a fun ride, but all patch series come to an end. My hope is
that this is it. The simplification of the fix is considerable now,
with only a few lines of code and with no data structure changes.

We were only creating the debugfs_dir upon initialization only if
you had CONFIG_BLK_DEBUG_FS for for make_request block drivers
(multiqueue). That's where the UAF bug could happen. Folks liked
the idea of open coding the debugfs initialization even if
CONFIG_BLK_DEBUG_FS was disabled, given that debugfs code will
simply ignore that code if debugfs is disabled, but to make
the fix easier to backport, that shift is done now in another
patch. Likewise, although we were only creating the debugfs_dir
only for make_request block drivers (multiqueue), the same new
additional patch also creates the debugfs_dir for request-based
block drivers. That *begged* us to just rename the mutex to
clarify its for the debugfs_dir, blktrace then just becomes
its biggest user.

The only patches changed here is the last one from the last series,
which actually fixed the UAF oops, and that one is now split in 3
patches, which makes a secondary fix much clearer.

I've waited a while to post these, to let 0-day give me its blessings,
both for Linus' tree and linux-next. No issues have been found. I've
also taken time to run blktests prior and after this series and I have
found no regressions. In fact, I think I should just extend blktests
with the break-blktrace tests, I'll do that later.

Luis Chamberlain (8):
  block: add docs for gendisk / request_queue refcount helpers
  block: clarify context for refcount increment helpers
  block: revert back to synchronous request_queue removal
  blktrace: annotate required lock on do_blk_trace_setup()
  loop: be paranoid on exit and prevent new additions / removals
  blktrace: fix debugfs use after free
  blktrace: ensure our debugfs dir exists
  block: create the request_queue debugfs_dir on registration

 block/blk-core.c        | 31 +++++++++++++----
 block/blk-mq-debugfs.c  |  5 ---
 block/blk-sysfs.c       | 52 ++++++++++++++++------------
 block/blk.h             |  2 --
 block/genhd.c           | 73 ++++++++++++++++++++++++++++++++++++++-
 drivers/block/loop.c    |  4 +++
 include/linux/blkdev.h  |  7 ++--
 kernel/trace/blktrace.c | 76 ++++++++++++++++++++++++-----------------
 8 files changed, 179 insertions(+), 71 deletions(-)

Comments

Jens Axboe June 20, 2020, 9:18 p.m. UTC | #1
On 6/19/20 2:47 PM, Luis Chamberlain wrote:
> Its been a fun ride, but all patch series come to an end. My hope is
> that this is it. The simplification of the fix is considerable now,
> with only a few lines of code and with no data structure changes.
> 
> We were only creating the debugfs_dir upon initialization only if
> you had CONFIG_BLK_DEBUG_FS for for make_request block drivers
> (multiqueue). That's where the UAF bug could happen. Folks liked
> the idea of open coding the debugfs initialization even if
> CONFIG_BLK_DEBUG_FS was disabled, given that debugfs code will
> simply ignore that code if debugfs is disabled, but to make
> the fix easier to backport, that shift is done now in another
> patch. Likewise, although we were only creating the debugfs_dir
> only for make_request block drivers (multiqueue), the same new
> additional patch also creates the debugfs_dir for request-based
> block drivers. That *begged* us to just rename the mutex to
> clarify its for the debugfs_dir, blktrace then just becomes
> its biggest user.
> 
> The only patches changed here is the last one from the last series,
> which actually fixed the UAF oops, and that one is now split in 3
> patches, which makes a secondary fix much clearer.
> 
> I've waited a while to post these, to let 0-day give me its blessings,
> both for Linus' tree and linux-next. No issues have been found. I've
> also taken time to run blktests prior and after this series and I have
> found no regressions. In fact, I think I should just extend blktests
> with the break-blktrace tests, I'll do that later.
> 
> Luis Chamberlain (8):
>   block: add docs for gendisk / request_queue refcount helpers
>   block: clarify context for refcount increment helpers
>   block: revert back to synchronous request_queue removal
>   blktrace: annotate required lock on do_blk_trace_setup()
>   loop: be paranoid on exit and prevent new additions / removals
>   blktrace: fix debugfs use after free
>   blktrace: ensure our debugfs dir exists
>   block: create the request_queue debugfs_dir on registration

Applied for 5.9, thanks.