Bug 137182 - Short buffer allocation in getModuleLocation can cause boot failure
Short buffer allocation in getModuleLocation can cause boot failure
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda (Show other bugs)
3.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-26 11:27 EDT by Andrew Mann
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-24 15:04: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 Andrew Mann 2004-10-26 11:27:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040614 Firefox/0.9

Description of problem:
In the file loader2/modules.c, in the function getModuleLocation() the
following code appears:

    if (version == 1) {
        ret = malloc(strlen(u.release) + strlen(arch) + 1);
        sprintf(ret, "%s/%s", u.release, arch);
        return ret;

  The malloc should allocate + 2 extra bytes, not 1, since the
following sprintf adds 1 extra character and needs a terminating NULL.
  If the release string length + arch string length + 1 is a multiple
of the underlying allocation alignment size, the terminating NULL may
be overwritten by other variables.

  Trouble involving this came up when using a 23 character long kernel
release string with i386 arch strlen(release/arch)=28.  The symptoms
were that attempts to load the first module set (vgafb16.o) provided
maps with the module location having an extra non-printable character
appended after i386.  When printed, the maps looked like:
"kernel-release/i386 /vgafb16.o".  The modules failed to load and the
system failed to boot.

  The line "error ## reading header: cpio: read failed - No such file
or directory." will display on the console (though there are many
other more likely reasons for this appearing as well).

Version-Release number of selected component (if applicable):
anaconda-9.1.3

How reproducible:
Always

Steps to Reproduce:
1. Build an i386 kernel with a release string of length mod 4 = 3
(i.e. 23 characters long) based off the 2.4.21-20.EL1 kernel.
2. Create a boot disk using this kernel.
3. Attempt to boot from the boot disk.


Actual Results:  The kernel will load, and proceed normally to
"running /sbin/loader".  It will then fail to load modules and fail
the rest of the boot process.

Expected Results:  The disk should continue the boot process.

Additional info:

This bug may occur in different circumstances on other architectures. 
Changing the allocation to:
 malloc(strlen(u.release) + strlen(arch) + 2);
  
 resolved the issue.

Maked as high due to simplicity of fix, and the potential to cause
infinite frustration attempting to track down an elusive bug.
Comment 1 Jeremy Katz 2004-10-26 18:46:40 EDT
Fixed in CVS on the RHEL3 branch.  Same as bug 115948 from -HEAD
Comment 2 Jeremy Katz 2006-04-24 15:04:04 EDT
Mass-closing lots of old bugs which are in MODIFIED (and thus presumed to be
fixed).  If any of these are still a problem, please reopen or file a new bug
against the release which they're occurring in so they can be properly tracked.

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