Re: [PATCH] blktrace: Protect q->blk_trace with RCU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux