linux-ext4 - Re: [PATCH] ext4: Fix bh->b

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] [day] [month] [year] [list]

Message-ID: <20160219050824.GB12743@thunk.org>
Date:	Fri, 19 Feb 2016 00:08:24 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Jan Kara <jack@...e.cz>
Cc:	Nikolay Borisov <kernel@...p.com>, linux-ext4@...r.kernel.org,
	Jan Kara <jack@...e.com>, stable@...r.kernel.org
Subject: Re: [PATCH] ext4: Fix bh->b_state corruption

On Thu, Feb 18, 2016 at 05:09:48PM +0100, Jan Kara wrote:
> On Thu 07-01-16 17:55:21, Jan Kara wrote:
> > From: Jan Kara <jack@...e.com>
> > 
> > ext4 can update bh->b_state non-atomically in _ext4_get_block() and
> > ext4_da_get_block_prep(). Usually this is fine since bh is just a
> > temporary storage for mapping information on stack but in some cases it
> > can be fully living bh attached to a page. In such case non-atomic
> > update of bh->b_state can race with an atomic update which then gets
> > lost. Usually when we are mapping bh and thus updating bh->b_state
> > non-atomically, nobody else touches the bh and so things work out fine
> > but there is one case to especially worry about: ext4_finish_bio() uses
> > BH_Uptodate_Lock on the first bh in the page to synchronize handling of
> > PageWriteback state. So when blocksize < pagesize, we can be atomically
> > modifying bh->b_state of a buffer that actually isn't under IO and thus
> > can race e.g. with delalloc trying to map that buffer. The result is
> > that we can mistakenly set / clear BH_Uptodate_Lock bit resulting in the
> > corruption of PageWriteback state or missed unlock of BH_Uptodate_Lock.
> > 
> > Fix the problem by always updating bh->b_state bits atomically.
> > 
> > CC: stable@...r.kernel.org
> > Reported-by: Nikolay Borisov <kernel@...p.com>
> > Signed-off-by: Jan Kara <jack@...e.cz>
> 
> Ping Ted? This seems to have fallen through the cracks?

Oops, sorry.  Thanks, applied.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html