public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Ashley <dash@xdr.com>
To: linux-kernel@vger.kernel.org
Subject: Serious filesystem bug in linux
Date: Sun, 26 Jan 2003 15:18:49 -0800	[thread overview]
Message-ID: <200301262318.h0QNInq10032@xdr.com> (raw)

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.

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.

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

             reply	other threads:[~2003-01-26 23:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-26 23:18 David Ashley [this message]
2003-01-26 23:49 ` Serious filesystem bug in linux Andries Brouwer
2003-01-27  4:32 ` Andrew McGregor

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=200301262318.h0QNInq10032@xdr.com \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox