summaryrefslogtreecommitdiffstats
path: root/Documentation/filesystems/vfs.txt
diff options
context:
space:
mode:
authorNick Piggin <npiggin@suse.de>2007-02-20 13:58:08 -0800
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-02-20 17:10:15 -0800
commit955eff5acc8b8cd1c7d4eec0229c35eaabe013db (patch)
tree08d61e41bc12f3d1d9160e39ae6b45df6b9687d9 /Documentation/filesystems/vfs.txt
parentc066332fb15adde1f37d874a67a1f9f7e4206484 (diff)
[PATCH] fs: fix libfs data leak
simple_prepare_write leaks uninitialised kernel data. This happens because the it leaves an uninitialised "hole" over the part of the page that the write is expected to go to. This is fine, but it then marks the page uptodate, which means a concurrent read can come in and copy the uninitialised memory into userspace before it written to. Fix it by simply marking it uptodate in simple_commit_write instead, after the hole has been filled in. This could theoretically break an fs that uses simple_prepare_write and not simple_commit_write, and that relies on the incorrect simple_prepare_write behaviour. Luckily, none of those exists in the tree. Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/filesystems/vfs.txt')
-rw-r--r--Documentation/filesystems/vfs.txt5
1 files changed, 5 insertions, 0 deletions
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 7737bfd03cf..ea271f2d395 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -617,6 +617,11 @@ struct address_space_operations {
In this case the prepare_write will be retried one the lock is
regained.
+ Note: the page _must not_ be marked uptodate in this function
+ (or anywhere else) unless it actually is uptodate right now. As
+ soon as a page is marked uptodate, it is possible for a concurrent
+ read(2) to copy it to userspace.
+
commit_write: If prepare_write succeeds, new data will be copied
into the page and then commit_write will be called. It will
typically update the size of the file (if appropriate) and