Bug 17888

'isomarkboot' from 'aboot-0.7a' dismally fails at least on some
CD images.  Below is a copy of my letter from July 23rd to aboot
maintainer (dhd) with a fix.  This was supposed
to be incorporated in the next aboot release.  I do not know
when this will happen.

  Michal
  michal


David,
there is a problem with 'isomarkboot' from aboot-0.7 and 0.7a.
With 0.6b things were all right.  When I tried to use it on some
iso images then, depending on a compiler and/or compilation
options I was getting either an infinite loop or SIGSEV.
From attempts to print some values and to track things in gdb
it was soon rather obvious that a stack is destroyed.

After lots of teeth gnashing, tons of lost hair and time I tracked
that eventually to isolib.c.  It turns out that this code:

                  char retname[de->name_len[0] + 1];
                  dlen = get_rock_ridge_filename(de, retname, dir);

in a loop of iso_find_entry() is responsible (not always, things go
haywire from time to time).

The following trivial patch makes 'isomarkboot' to behave.


--- aboot-0.7a/lib/isolib.c~    Tue May  2 21:58:23 2000
+++ aboot-0.7a/lib/isolib.c     Sun Jul 23 18:30:18 2000
@@ -547,7 +547,8 @@
                }
     
                {
-                 char retname[de->name_len[0] + 1];
+                 /* char retname[de->name_len[0] + 1]; */
+                 char retname[256];
                  dlen = get_rock_ridge_filename(de, retname, dir);
                  if (dlen) {
                    strcpy(de->name, retname);

I see with it this:

# tools/isomarkboot /dev/loop0 boot/bootlx
iso: Max size:321573   Log zone size:2048
iso: First datazone:35   Root inode number 71680
tools/isomarkboot: boot/bootlx is at offset 632492032 and is 82432 bytes
long

'de->name_len[0]' is one byte so 'retname[256]' is wide enough always
but even if one would like to risk this dynamic allocation then
'de->name_len[0]' should be cast to (unsigned int) in any case.