lkml.org 
[lkml]   [2006]   [Sep]   [3]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 3 Sep 2006 19:11:08 +0400
FromSergey Vlasov <>
SubjectUDF 1GB file size limit after CVE-2006-4145 fix
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.

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?
Is someone working to fix these problems?

-- 
Sergey Vlasov
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2006-09-03 17:15    [from the cache]
©2003-2008