Bug 17888 - isomarkboot from aboot-0.7a fails on some images
isomarkboot from aboot-0.7a fails on some images
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: aboot (Show other bugs)
7.3
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-09-26 17:43 EDT by Michal Jaegermann
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-09-26 17:43:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2000-09-26 17:43:02 EDT
'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@linuxcare.com) with a fix.  This was supposed
to be incorporated in the next aboot release.  I do not know
when this will happen.

  Michal
  michal@harddata.com


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.
Comment 1 Matt Wilson 2001-01-26 22:17:32 EST
will be in next rawhide.

Note You need to log in before you can comment on or make changes to this bug.