Bug 152878

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 1.2.0.7 is statically linked in this package.

SRPM = 
  http://download.fedoralegacy.org/fedora/1/os/SRPMS/modutils-2.4.25-13.src.rpm



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

Question:  Will we need to publish a new SRPM and bump the version number, 
a la
     modutils-2.4.25-14.legacy.src.rpm 
even though the sources will not have changed?



------- Additional Comments From pekkas 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)
modutils-2.4.25-13.1.legacy.src.rpm.

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 marcdeslauriers 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 marcdeslauriers 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 deisenst 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
there?



------- Additional Comments From marcdeslauriers 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 dkl 2005-03-30 18:30 -------

This bug previously known as bug 2364 at https://bugzilla.fedora.us/
https://bugzilla.fedora.us/show_bug.cgi?id=2364
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.