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 <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > 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 <[email protected]>
SuSE CR Labs
--
VGER BF report: H 0.000799476
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]