From: Andrew McGregor <andrew@indranet.co.nz>
To: David Ashley <dash@xdr.com>, linux-kernel@vger.kernel.org
Subject: Re: Serious filesystem bug in linux
Date: Mon, 27 Jan 2003 17:32:56 +1300 [thread overview]
Message-ID: <21300000.1043641976@localhost.localdomain> (raw)
In-Reply-To: <200301262318.h0QNInq10032@xdr.com>
--On Sunday, January 26, 2003 15:18:49 -0800 David Ashley <dash@xdr.com>
wrote:
> This problem has happened on 2.4.4 and 2.4.20, on an ext2 filesystem as
> well as a jfs filesystem. Through normal file operations a file is
> operated on and its size becomes something way too large, like this:
> -rw-r--r-- 1 root root 1965107636224 Jan 26 14:59 output1.iso
>
> The file should be 4.5 gb or so.
> It is opened with this:
> fd=open(savename,O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE,0644);
>
> Operations done on the file handle are read,write, lseek64 and close.
> All reads/writes to the file are in units of 2048 bytes. First something
> like 4+ gigs is written to the file. Then without closing the file it
> is all read out again 2048 bytes at a time. Before every read is an
> lseek64, almost always right to where the file position would have been
> anyway. Finally some fraction of the sectors are rewritten, on the order
> of 1/150, spread pretty much evenly thoughout the file. Before every
> write there is an lseek64. Then the file is closed.
Are you sure you are not lseek64'ing to a position corresponding to the new
size? If you do that and then write, the write will succeed and you get a
sparse file. To test for that, what does ls -lsk say for that file? The
first column will be the number of kilobytes actually stored in the file.
If that is different from the length, it's a sparse file.
> I'm not certain but it may be that if I do this operation as root then
> sometimes the problem occurs. I'm not certain if the problem has ever
> occured when not running as root.
>
> The resultant file can be read out beyond the actual size of the file.
> What can it be reading? I'm assuming the contents of the hard drive in
> other areas not part of the original file, as in other user's files.
> As such it is a very real security risk.
Or it could just be sparse, and reading synthetic zeros that don't really
exist anywhere, which is no problem.
> The hard drives are IDE in both cases. 2.4.4 was ext2, and 2.4.20 was jfs.
> I figure it must relate to the O_LARGEFILE since that probably hasn't been
> exercised as much.
>
> -Dave
Andrew
prev parent reply other threads:[~2003-01-27 4:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-26 23:18 Serious filesystem bug in linux David Ashley
2003-01-26 23:49 ` Andries Brouwer
2003-01-27 4:32 ` Andrew McGregor [this message]
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=21300000.1043641976@localhost.localdomain \
--to=andrew@indranet.co.nz \
--cc=dash@xdr.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.