linux-kernel - Re: Linux ISO-9660 Rock Ridge bug needs fix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200610172114.30268.ismail@pardus.org.tr>
Date:	Tue, 17 Oct 2006 21:14:29 +0300
From:	Ismail Donmez <ismail@...dus.org.tr>
To:	Luca Tettamanti <kronos.it@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Joerg Schilling <schilling@...us.fraunhofer.de>
Subject: Re: Linux ISO-9660 Rock Ridge bug needs fix

17 Eki 2006 Sal 21:02 tarihinde, Luca Tettamanti şunları yazmıştı: 
> Ismail Donmez <ismail@...dus.org.tr> ha scritto:
> >> while working on better ISO-9660 support for the Solaris Kernel,
> >> I recently enhanced mkisofs to support the Rock Ridge Standard version
> >> 1.12 from 1994.
> >>
> >> The difference bewteen version 1.12 and 1.10 (this is what previous
> >> mkisofs versions did implement) is that the "PX" field is now 8 Byte
> >> bigger than before (44 instead of 36 bytes).
> >
> > Is there a test iso file somewhere? I think the attached *untested* patch
> > will fix it.
>
> I was also looking at this ;) I cannot reproduce the failure even with
> images generated with the new version of mkisofs (I actually _see_ that
> PX record size is changed, but isofs doesn't seem to care...).
>
> > diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c
> > index f3a1db3..061a633 100644
> > --- a/fs/isofs/rock.c
> > +++ b/fs/isofs/rock.c
> > @@ -349,6 +349,7 @@ #endif
> >                         inode->i_nlink = isonum_733(rr->u.PX.n_links);
> >                         inode->i_uid = isonum_733(rr->u.PX.uid);
> >                         inode->i_gid = isonum_733(rr->u.PX.gid);
> > +                       inode->i_ino = isonum_733(rr->u.PX.ino);
> >                         break;
>
> I don't think it's correct. When reading disk with old format i_ino will
> be filled with garbage.
> Now, who is in charge of isofs?

I was just trying a fast hack to see it works ;-) but iso files produced by 
latest mkisofs works fine even without patching.

Regards,
ismail
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/