The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Adrian Cox <adrian@humboldt.co.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Filling holes in ext2
Date: Wed, 22 Aug 2001 11:34:39 -0700	[thread overview]
Message-ID: <3B83FB3F.A0BDC056@zip.com.au> (raw)
In-Reply-To: <3B83E9FD.6020801@humboldt.co.uk>

Adrian Cox wrote:
> 
> 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.

Yup.

> 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.)

Yes, it can.

> 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.

I'd expect it to occur if you simply pass an unmapped address
to write()?
 
> If this can happen, does it matter?

It matters.  -ac kernels handle this by clearing out the blocks
on the error path in __block_prepare_write().  If you retest with
-ac kernels, you should just see zeroes.

> Should ext2 have an abort_write() operation like ext3() has?

abort_write() is an expediency - it was (much) easier and safer
to add a new operation rather than running all over the kernel
and redefining the commit_write() API.

ext3 definitely needs to know about prepare/commit imbalance in
lo_send() and generic_file_write(), and in block_symlink() if that
is ever changed to error out after the prepare_write().

But long-term, we need to change the commit_write() definition so
that it is called even in the error case, thus informing the
underlying fs of the partial write.

-

  reply	other threads:[~2001-08-22 18:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-22 17:21 Filling holes in ext2 Adrian Cox
2001-08-22 18:34 ` Andrew Morton [this message]
2001-08-22 18:59   ` Adrian Cox
2001-08-23 17:22   ` Adrian Cox
2001-08-23 17:46     ` Andrew Morton
2001-08-23 19:17       ` Adrian Cox
2001-08-23 19:23         ` Alan Cox
2001-08-23 19:41         ` Andrew Morton
2001-08-23 21:21           ` Adrian Cox
2001-08-23 17:47     ` Alan Cox

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=3B83FB3F.A0BDC056@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=adrian@humboldt.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox