lkml.org 
[lkml]   [2001]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectFilling holes in ext2
I've been looking at generic_file_write() a lot recently, and I'm a 
little bothered by this section, as mangled here by Mozilla:

status = mapping->a_ops->prepare_write(file, page, offset, offset+bytes);
if (status)
goto unlock;
status = __copy_from_user(kaddr+offset, buf, bytes);
flush_dcache_page(page);
if (status)
goto fail_write;
status = mapping->a_ops->commit_write(file, page, offset, offset+bytes);

If the __copy_from_user() does fail when writing to a hole or extending
a file on ext2, disk blocks get added to the file, but are never
cleared. The result is that data from a free block appears in the file.

I've not managed to trigger this in a real system, but I have explored
the failure path by running UML under gdb. I filled the filesystem with
data as root (yes > /mnt/test), deleted the files, then triggered this
path on an application running as a normal user. The result was that
root's old data appeared in the user file.

So:
Can this really happen on the mainstream kernel? (The kernel I tested on
was 2.4.7 with the corresponding UML patch.)

Can this actually be exploited? I assume the test on __copy_from_user()
is there in case another thread changes memory mappings while
generic_file_write() is running. My attempts to do this haven't yet
succeeded.

If this can happen, does it matter? Should ext2 have an abort_write()
operation like ext3() has?

--
Adrian Cox http://www.humboldt.co.uk/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:57    [W:0.182 / U:1.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site