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@vger.kernel.org Reported-by: Tristan tristmd@gmail.com Signed-off-by: Jan Kara jack@suse.cz
Jens, do you plan to pick up the patch? Also the reporter asked me to update the reference as:
Reported-by: Tristan Madani tristmd@gmail.com
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@redhat.com
Jens, any chance to take a look at this CVE issue?
Queued up for 5.6, thanks everyone.