linux-ext4 - Re: Odd "leak" of extent info into data blocks?

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: <20090908233644.GV22901@mit.edu>
Date:	Tue, 8 Sep 2009 19:36:44 -0400
From:	Theodore Tso <tytso@....edu>
To:	Curt Wohlgemuth <curtw@...gle.com>
Cc:	Valerie Aurora <vaurora@...hat.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Odd "leak" of extent info into data blocks?

On Tue, Sep 08, 2009 at 02:18:35PM -0700, Curt Wohlgemuth wrote:
> 
> All bforget() does is clear the buffer's dirty bit.  Meanwhile, the
> page is still marked dirty, and can be in the middle of writeback;
> it's true that __block_write_full_page() will check the dirty bit for
> each buffer in the page, but there doesn't seem to be any
> synchronization to ensure that the write won't take place at some
> point in time after bforget() is called.  Which means it can be called
> after the bitmap is changed.

Let me make sure I got this right.  The problem that you're worried
about is a block that had previously contained an extent tree node for
an inode that gets deleted, and then that blocks gets reallocated for
use as a data block.  In ext3 and ext4, metadata blocks (such as
extent tree blocks), aren't stored in the page cache.

So I'm not sure why you're worried about the page being marked dirty.
What's the scenario you are concerned about?

If it's the case where a data block for a deleted inode getting
rewritten after the inode is deleted, when the inode is deleted,
truncate_inode_apges() end up dropping the pages from the page cache
*before* the block allocation bitmap is dropped.

> This is why I opted to wait for the buffer to be written out before
> continuing on to ext4_free_blocks().

Just to be clear, which buffer are you talking about here?

     	   	  	       	       - 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