On Wed, Feb 19, 2020 at 01:59:47PM +0100, Jan Kara wrote: > On Thu 06-02-20 15:28:12, Jan Kara wrote: > > KASAN is reporting that __blk_add_trace() has a use-after-free issue > > when accessing q->blk_trace. Indeed the switching of block tracing (and > > thus eventual freeing of q->blk_trace) is completely unsynchronized with > > the currently running tracing and thus it can happen that the blk_trace > > structure is being freed just while __blk_add_trace() works on it. > > Protect accesses to q->blk_trace by RCU during tracing and make sure we > > wait for the end of RCU grace period when shutting down tracing. Luckily > > that is rare enough event that we can afford that. Note that postponing > > the freeing of blk_trace to an RCU callback should better be avoided as > > it could have unexpected user visible side-effects as debugfs files > > would be still existing for a short while block tracing has been shut > > down. > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=205711 > > CC: stable@xxxxxxxxxxxxxxx > > Reported-by: Tristan <tristmd@xxxxxxxxx> > > Signed-off-by: Jan Kara <jack@xxxxxxx> > > Jens, do you plan to pick up the patch? Also the reporter asked me to > update the reference as: > > Reported-by: Tristan Madani <tristmd@xxxxxxxxx> > > Should I resend the patch with this update & reviewed-by's or will you fix > it up on commit? Thanks. > I have run concurrent quick/repeated blktrace & long-time heavy IO, looks this patch just works fine, so: Tested-by: Ming Lei <ming.lei@xxxxxxxxxx> Jens, any chance to take a look at this CVE issue? Thanks, Ming
