Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 152878 - Modutils needs rebuilding when zlib complete
Summary: Modutils needs rebuilding when zlib complete
Alias: None
Product: Fedora Legacy
Classification: Retired
Component: Package request
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Fedora Legacy Bugs
QA Contact:
Whiteboard: 1, LEGACY
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-31 17:17 UTC by David Eisenstein
Modified: 2008-05-01 15:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)

Description David Lawrence 2005-03-30 23:30:43 UTC
This bugzilla entry comes from Bug 2043, in which it was determined that Fedora
Core 1's modutils binary package needs to be rebuilt when zlib (Bug 2043) is
patched and fixed, since zlib is statically linked in this package.


------- Additional Comments From 2004-12-31 12:29:51 ----

Question:  Will we need to publish a new SRPM and bump the version number, 
a la
even though the sources will not have changed?

------- Additional Comments From 2005-01-01 00:34:13 ----

Remember that the new zlib must be part of the installed system when modutils is
being rebuilt in mach, because otherwise the modutils will be linked against the
_broken_ zlib.  So, zlib should be rebuilt and installed in mach asap.

As for the name, the better name would be (IMHO)

I don't know if bumping the release number and adding a changelog requires a
package or not.. but there's no need to figure that out if 
someone produces the SRPM which just bumps the version number (+adds changelog
for that), and someone +PUBLISH'es that.  I can do the PUBLISH part if someone
creates the package.

------- Additional Comments From 2005-01-01 06:14:45 ----

No packages are necessary, we'll just rebuild the old srpm with a new release tag.

------- Additional Comments From 2005-02-05 13:19:31 ----

I can't seem to build modutils successfully in mach. The resulting packages
create en empty /etc/modprobe.conf.dist file.

I am going to release the updated zlib without modutils for now.

------- Additional Comments From 2005-02-11 02:33:22 ----

That's fine with me, Marc.  

I would guess that there is a very low probability that a gzipped kernel
module from a reputable source would end up malevolently manipulated by
somebody such that it would cause an application crash in one of the
modutils programs.  Any author of a tampered-with kernel module would
want the thing to load, not to cause modutils to crash.

In other words, if one receives one's loadable kernel modules (LKM's) from a
reputable source, such as from an RPM created by Red Hat or Fedora Core or
Fedora Legacy project, then the probability of this CAN-2004-0797 vulnera-
bility in zlib ever actually *causing* a denial-of-service in modutils is
pretty low.  Zlib itself doesn't create gzipped-encoded data that causes
its decoder to crash.

And if one ends up using some loadable kernel module from a source dubious
enough that such a denial-of-service in modutils would be of concern, my 
guess is that modutils crashing would be the least of one's problems!
(e.g., trojanned LKM's, rootkit stuff).

My temptation is to suggest that this bug is therefore minor enough to think
about resolving this WONTFIX.  Not sure this is a good solution though.

Want me to try & build this on my FC1 (non-mach) box and see if it will build

------- Additional Comments From 2005-02-11 03:00:40 ----

You're right. No sense in using a zlib vulnerability when the kernel module is
essentially run as root anyway.

Other distros have not released updates modutils.

I'm closing this.

------- Bug moved to this database by 2005-03-30 18:30 -------

This bug previously known as bug 2364 at
Originally filed under the Fedora Legacy product and Package request component.
Bug depends on bug(s) 2043.

Unknown priority P3. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

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