linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Sergey Vlasov <vsu@altlinux.ru>
Cc: Ben Fennema <bfennema@falcon.csc.calpoly.edu>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: UDF 1GB file size limit after CVE-2006-4145 fix
Date: Mon, 4 Sep 2006 12:06:03 +0200	[thread overview]
Message-ID: <20060904100603.GF4710@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <20060903151108.GA27102@procyon.home>

  Hello,

> On Tue, Aug 15, 2006 at 01:56:26PM +0200, Jan Kara wrote:
> > UDF code is not really ready to handle extents larger that 1GB. This is
> > the easy way to forbid creating those.
> > 
> > Also truncation code did not count with the case when there are no
> > extents in the file and we are extending the file.
> > 
> > Signed-off-by: Jan Kara <jack@suse.cz>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > ---
> >  fs/udf/super.c    |    2 +-
> >  fs/udf/truncate.c |   64 ++++++++++++++++++++++++++++++++---------------------
> >  2 files changed, 40 insertions(+), 26 deletions(-)
> > 
> > diff --git a/fs/udf/super.c b/fs/udf/super.c
> > index 7de172e..fcce1a2 100644
> > --- a/fs/udf/super.c
> > +++ b/fs/udf/super.c
> > @@ -1659,7 +1659,7 @@ #endif
> >  		iput(inode);
> >  		goto error_out;
> >  	}
> > -	sb->s_maxbytes = MAX_LFS_FILESIZE;
> > +	sb->s_maxbytes = 1<<30;
> [... rest of patch skipped ...]
> 
> After this change the size of files which can be created on an UDF
> filesystem becomes limited to 1GB.  This is very unfortunate - in
> particular, it means that there will be no way to write a file larger
> than 4GB to a DVD under Linux (mkisofs -udf does not support files
> larger than 4GB, so the typical workaround was to use mkudffs and
> mount -o loop).  In fact, this change may be considered as a
> regression - large files on UDF seemed to work before (at least in
> simple cases), and now they are forbidden.
  Actually I've been trying this and I have not been able to create file
larger than 1GB on my computer without UDF corrupting slab or doing some
other nasty thing. OK, maybe if you created it in 1GB pieces it could
work but anyway the problem is that currently if you have UDF rw-mounted,
ordinary user could make UDF corrupt kernel memory... So consider this
limitation more as a hotfix to the security problem - real fix is to
rewrite UDF write path to not create extents larger than 1 GB but that
is quite some work and will definitely need more testing.

> Files larger than 1GB can be read even after this patch (because
> s_maxbytes is not checked in read paths, and udf does not use
> generic_file_lseek()), so old disks at least can be read.
> 
> What issues with files larger than 1GB have been found in the code?
  See above.

> Is someone working to fix these problems?
  Yes, I plan to have a look into a proper fix of this problem (i.e. fix
UDF write path).

								Honza
-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs

-- 
VGER BF report: H 0.000799476

      reply	other threads:[~2006-09-04 10:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-03 15:11 UDF 1GB file size limit after CVE-2006-4145 fix Sergey Vlasov
2006-09-04 10:06 ` Jan Kara [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=20060904100603.GF4710@atrey.karlin.mff.cuni.cz \
    --to=jack@suse.cz \
    --cc=bfennema@falcon.csc.calpoly.edu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vsu@altlinux.ru \
    /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;
as well as URLs for NNTP newsgroup(s).