Re: Linux ISO-9660 Rock Ridge bug needs fix

[Joerg Schilling]

James Lamanna <jlamanna@xxxxxxxxx> wrote:

>
> Joerg Shilling wrote:
> > Ismail Donmez <ismail@xxxxxxxxxxxxx> wrote:
> >
> > > > Well, this is why I did offer a preliminary version of thelatest mkisofs
> > > > sources.....
> > >
> > > Well a simple mkisofs some_file > test.iso and mounting that on a loop
> > > device 
> > > worked fine.
> > >
> > >
> > > > But note: your patch does not fix the original implementation bug and it
> > > > is
> > > > most unlikely that the hack will do the right things in all cases.
> > >
> > > Well I don't know whats the original implementation bug and rock.c seems to
> > > be 
> > > pretty much old with no active maintainer.
> > 
> > Please read again my original mail....
> > 1) you need to create images with Rock Ridge
> > 
> > 2) a correct implementation is prepared to deal with more recent versions 
> >     without a need for new changes.
> > 
> >     So, if the implementation does not deal with the new version _without_ 
> >     explicitely knowing about v1.12 it is still broken.
>
> Hi Joerg,
>
> I am unable to duplicate this bug that supposedly exists even on older
> kernels.
> For instance, on a 2.6.16 kernel I do the following:

Mm, I did not test, I did only check the source and it seems that I did 
interpret the check 

        len += offsetof(struct rock_ridge, u); 
        if (len > rs->len) { 
                printk(KERN_NOTICE "rock: directory entry would overflow " 
                                "storage\n"); 
                printk(KERN_NOTICE "rock: sig=0x%02x, size=%d, remaining=%d\n", 
                                sig, len, rs->len); 
                return -EIO; 
	}

the wrong way.... because the error text is wrong. It should be corrected into

"rock: directory entry would _underflow_ storage\n"


Using the inode field from RRip 1.12 is definitely not trivial as it may affect
many parts of the source and needs intensive testing.

Jörg

-- 
 EMail:joerg@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
       js@xxxxxxxxxxxxxxx                (uni)  
       schilling@xxxxxxxxxxxxxxxxxxx     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/