LKML Archive on
help / color / mirror / Atom feed
From: Nick Piggin <>
To: Andrew Morton <>,
	Linux Kernel Mailing List <>
Subject: [patch 1/2] fs: fix libfs data leak
Date: Thu, 15 Feb 2007 02:32:29 +0100	[thread overview]
Message-ID: <> (raw)

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

Signed-off-by: Nick Piggin <>

Index: linux-2.6/fs/libfs.c
--- linux-2.6.orig/fs/libfs.c
+++ linux-2.6/fs/libfs.c
@@ -335,17 +335,18 @@ int simple_prepare_write(struct file *fi
 			kunmap_atomic(kaddr, KM_USER0);
-		SetPageUptodate(page);
 	return 0;
 int simple_commit_write(struct file *file, struct page *page,
-			unsigned offset, unsigned to)
+			unsigned from, unsigned to)
 	struct inode *inode = page->mapping->host;
 	loff_t pos = ((loff_t)page->index << PAGE_CACHE_SHIFT) + to;
+	if (!PageUptodate(page))
+		SetPageUptodate(page);
 	 * No need to use i_size_read() here, the i_size
 	 * cannot change under us because we hold the i_mutex.
Index: linux-2.6/Documentation/filesystems/vfs.txt
--- linux-2.6.orig/Documentation/filesystems/vfs.txt
+++ linux-2.6/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
+	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

             reply	other threads:[~2007-02-15  1:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-15  1:32 Nick Piggin [this message]
2007-02-15  1:33 ` [patch 2/2] fs: fix nobh " Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: [patch 1/2] fs: fix libfs data leak' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).