linux-kernel - Re: [PATCH] [RFC] fix potential access after free: return value of blk_check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160406003003.GA57524@clm-mbp.masoncoding.com>
Date:	Tue, 5 Apr 2016 20:30:03 -0400
From:	Chris Mason <clm@...com>
To:	Lars Ellenberg <lars.ellenberg@...bit.com>
CC:	Neil Brown <neilb@...e.de>, Jens Axboe <axboe@...nel.dk>,
	Josef Bacik <jbacik@...com>, David Sterba <dsterba@...e.com>,
	<linux-raid@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-btrfs@...r.kernel.org>
Subject: Re: [PATCH] [RFC] fix potential access after free: return value of
 blk_check_plugged() must be used schedule() safe

On Tue, Apr 05, 2016 at 03:36:57PM +0200, Lars Ellenberg wrote:
> blk_check_plugged() will return a pointer
> to an object linked on current->plug->cb_list.
> 
> That list may "at any time" be implicitly cleared by
> blk_flush_plug_list()
>  flush_plug_callbacks()
> either as a result of blk_finish_plug(),
> or implicitly by schedule() [and maybe other implicit mechanisms?]
> 
> If there is no protection against an implicit unplug
> between the call to blk_check_plug() and using its return value,
> that implicit unplug may have already happened,
> even before the plug is actually initialized or populated,
> and we may be using a pointer to already free()d data.
> 
> I suggest that both raid1 and raid10 can easily be fixed
> by moving the call to blk_check_plugged() inside the spinlock.
> 
> For md/raid5 and btrfs/raid56,
> I'm unsure how (if) this needs to be fixed.

I think you're right, digging in to see if there's something I missed.
But as Neil said, it looks like we just got saved by preemption being
off by default.

-chris