On 2/25/20 3:20 AM, Ming Lei wrote: > 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? Queued up for 5.6, thanks everyone. -- Jens Axboe
