Re: Linux ISO-9660 Rock Ridge bug needs fix

["James Lamanna" <jlamanna@gmail.com>]

On 10/17/06, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
> James Lamanna <jlamanna@gmail.com> wrote:
>
> >
> > Joerg Shilling wrote:
[snip...]
> >
> > 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"

Yes I saw this check and misinterpreted it initially also.

I actually think 'overflow' is still correct since its testing for the
calcuated size (directory entry) being larger than the size reported
by the filesystem (storage).

I still submit my patch to Linus et. al. for consideration that also
detects overflow in the case of a v 1.12 PX entry. I may have time to
build a git kernel today or tomorrow and actually test it against a RR
iso image.

>
>
> 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.

Yes. If it is actually correct it allows for the use of iget_locked()
in isofs/inode.c instead of iget5_locked() (per
Documentation/filesystems/vfs.txt). Though I'll let a real VFS person
decide if that has any advantages.

-- James