[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200619204730.26124-1-mcgrof@kernel.org>
Date: Fri, 19 Jun 2020 20:47:22 +0000
From: Luis Chamberlain <mcgrof@...nel.org>
To: axboe@...nel.dk, viro@...iv.linux.org.uk, bvanassche@....org,
gregkh@...uxfoundation.org, rostedt@...dmis.org, mingo@...hat.com,
jack@...e.cz, ming.lei@...hat.com, nstange@...e.de,
akpm@...ux-foundation.org
Cc: mhocko@...e.com, yukuai3@...wei.com, martin.petersen@...cle.com,
jejb@...ux.ibm.com, linux-block@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Luis Chamberlain <mcgrof@...nel.org>
Subject: [PATCH v7 0/8] blktrace: fix debugfs use after free
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(-)
--
2.26.2
Powered by blists - more mailing lists