Re: [PATCH] reiserfs old data bug 2.2.x (was: ReiserFS? How reliable ...)

[Chris Mason <mason@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]



On Thursday, April 05, 2001 02:13:55 AM +0100 Alan Cox
<alan@lxorguk.ukuu.org.uk> wrote:

>> This is a reiserfs security issue, but only of theoretical nature (Even
>> i= f
>> triggered, it won't harm you). But the reason for this bug is in NFS
>> (v2,=
> 
> If the blocks contained my old /etc/shadow I'd be a bit upset.
> 

I think we're talking about different things here.  Alan, I think you are
referring to the ability to get old data in files during mmap.  Where the
exploit roughly looks like this:

truncate(file, 0)
truncate(file, X)
char *foo = mmap(file, X)
write(file, foo, X)

This should produce all zeros, but under 2.2.x reiserfs can instead include
old file data.  Turns out this is because during the write, the block
pointer is inserted before the newly allocated (and zero'd) buffer was set
up to date.  If a readpage is triggered when reiserfs_file_write calls
copy_from_user, you get the old data.  The fix is to mark the buffer up to
date right after zeroing.

Two patches attached, one for 3.5.32 (uptodate_hole.diff.gz) and one for
older reiserfs versions (uptodate_hole-old.diff.gz).  Both are small,
gzip'd because my mailer is dumb.

3.5.33 should come out soon with this included.  2.4.x reiserfs doesn't
need this patch.

-chris

[-- Attachment #2: uptodate_hole-old.diff.gz --]
[-- Type: application/x-gunzip, Size: 502 bytes --]

[-- Attachment #3: uptodate_hole.diff.gz --]
[-- Type: application/x-gunzip, Size: 234 bytes --]