Re: Linux ISO-9660 Rock Ridge bug needs fix

From: James Lamanna
Date: Tue Oct 17 2006 - 17:52:31 EST


On 10/17/06, Joerg Schilling <Joerg.Schilling@xxxxxxxxxxxxxxxxxxx> wrote:
James Lamanna <jlamanna@xxxxxxxxx> 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
-
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/