Bug 152743 - CAN-2004-0619,0497,0587,0658,0415 Kernel fixes
CAN-2004-0619,0497,0587,0658,0415 Kernel fixes
Product: Fedora Legacy
Classification: Retired
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Fedora Legacy Bugs
LEGACY, rh73, rh90
Depends On:
  Show dependency treegraph
Reported: 2004-07-01 05:07 EDT by Marc Deslauriers
Modified: 2007-04-18 13:22 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-05 19:16:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Lawrence 2005-03-30 18:25:54 EST
Integer overflow in the ubsec_keysetup function for Linux Broadcom 5820
cryptonet driver allows local users to cause a denial of service (crash) and
possibly execute arbitrary code via a negative add_dsa_buf_bytes variable, which
leads to a buffer overflow.

More Info:

------- Additional Comments From marcdeslauriers@videotron.ca 2004-07-01 17:53:15 ----

Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow

    * From: Dave Jones <davej redhat com>
    * To: fedora-legacy-list redhat com
    * Subject: Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow
    * Date: Thu, 1 Jul 2004 19:09:55 +0100

This turned up on bugtraq a few days ago, which affects RHL.
The same driver was in FC1. I went to go look into fixing this,
and found a whole bunch of stuff that almost made me lose my lunch.

For FC1, I've not heard a single complaint about this (which
means it's either perfect[after reading the code, I very much
doubt it], or no-one uses it).  For this reason, I'm going to drop
it in the next FC1 update.

If someone heroic wants to fix it up for RHL, feel free, but
this is unlikely to happen in FC, as it was one of the
'we had this in rhl, lets drag it along for fc too'.
It never made it into FC2 either, and no-one complained.

This hardware is so 'niche' that I doubt anyone will complain
if you dropped it from RHL too. Worse case, someone can
grab the driver from broadcom if they feel like its worth it.


------- Additional Comments From marcdeslauriers@videotron.ca 2004-07-02 02:06:15 ----

Looks like another issue as well:

During an audit of the Linux kernel, SUSE discovered a flaw that allowed
a user to make unauthorized changes to the group ID of files in certain
circumstances. In the 2.4 kernel, as shipped with Fedora Core 1,
the only way this could happen is through the kernel nfs server.
A user on a system that mounted a remote file system from a vulnerable
machine may be able to make unauthorized changes to the group ID of
exported files. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2004-0497 to this issue.


------- Additional Comments From jp107@damtp.cam.ac.uk 2004-07-02 04:21:12 ----

Lifting the nfs fchown patch from fc1 and disabling the broadcom driver looks
fairly easy, so I've got the following proposed patch (not that I think that
this should delay release of the previous 2.4.20-35.x.legacy release!)


if people don't want to apply that to the -35 srpm here is one with it applied.
 No signatures or anything 'cos I don't even know (yet) if it compiles!


I'm testing building it now on RH9...

------- Additional Comments From dom@earth.li 2004-07-02 04:58:13 ----

*** Bug 1810 has been marked as a duplicate of this bug. ***

------- Additional Comments From jp107@damtp.cam.ac.uk 2004-07-02 10:55:58 ----

I'm testing the 686 kernel now running on a pair of RH9 test boxes.


will turn into a qa at some point when I'm not so late for the pub...

------- Additional Comments From marcdeslauriers@videotron.ca 2004-07-05 16:56:45 ----

Here's another:

Insecure permissions for the /proc/scsi/qla2300/HbaApiNode file in Linux allows
local users to cause a denial of service.


------- Additional Comments From jp107@damtp.cam.ac.uk 2004-07-12 13:23:00 ----

The RHL 2.4.20 based kernels don't include the driver for the qla2300 etc,
though there is a similar hole in the "addon" qla2200 driver.  It looks like the
fc1 patch just fixes this directly in the SOURCES/linux-2.4.9-qla2200.patch
patch which adds the driver to the kernel (unless I'm missing something here).

The fc1 version of this patch IS somewhat different from the one in RHL.  To my
eye it looks like a bunch of extra debugging was added if QL_DEBUG_LEVEL_3 is

Anyone know for sure?  Would anyone strongly object to a patch which just took
the fc1 (update) version of this patch instead of the one we already have?

Does anyone actually have a system using the qla2200 on which this stuff can be
tested or would just disabling it (as with the broadcom driver) be safer?

------- Additional Comments From marcdeslauriers@videotron.ca 2004-07-12 14:32:24 ----

In response to comment 7:

The qla2200 driver is for pretty common hardware, disabling it is not an option.
(Although I unfortunately don't have one handy to test)

------- Additional Comments From marcdeslauriers@videotron.ca 2004-07-12 14:54:28 ----

All we have to do in the current linux-2.4.9-qla2200.patch that's in the Fedora
Legacy kernel is change this line:

+       proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir,


+       proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir,

and the problem will be fixed. No need to use the patch from Fedora Core.

------- Additional Comments From jp107@damtp.cam.ac.uk 2004-07-12 15:08:24 ----

I know that the one-liner would fix the permissions issue.  Does anyone
know/understand what the other changes in the fc1 version of the qla2200 code
are _actually_ for?  Was this some outstanding bug/hole that was missed in RHL
for some reason.

Does anyone know when these other changes were added to the fc1 version?  I
can't see any reference to it in the changelog...

------- Additional Comments From marcdeslauriers@videotron.ca 2004-07-13 14:47:07 ----

Here's another flaw:


------- Additional Comments From marcdeslauriers@videotron.ca 2004-07-13 14:48:14 ----

CAN Reference for last flaw:


------- Additional Comments From jp107@damtp.cam.ac.uk 2004-07-15 07:26:44 ----

I've seen no activity about the CAN-2004-0658 hole so I don't know if there are
possible patches (or just not yet).  Searching http://www.linux1394.org came up
with no hits nor does the 1394 bug tracking system seem to have any mention of it.

The report implies that the maintainers were contacted a few days before the
22nd June.

Has the bug been reported in against fc1 or RHEL?  I can't find it in bugzilla
(but I am very poor at searching)...

------- Additional Comments From marcdeslauriers@videotron.ca 2004-08-04 13:30:32 ----

Another issue:

Paul Starzetz discovered flaws in the Linux kernel when handling file
offset pointers. These consist of invalid conversions of 64 to 32-bit file
offset pointers and possible race conditions. A local unprivileged user
could make use of these flaws to access large portions of kernel memory.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0415 to this issue.


------- Additional Comments From michal@harddata.com 2004-08-04 17:53:28 ----

I forgot that we have already new kernel bug report opened even when the
old one is not closed and put a series of patches which, hopefuly, should
take care of CAN-2004-0415, CAN-2004-0535 and CAN-2004-0587 as attachments
to bug #1484.  Should I repost them here or this reference is enough?

------- Additional Comments From jp107@damtp.cam.ac.uk 2004-08-05 05:18:04 ----

I think that the e1000 and qla patches are probably equivalent to the ones we
already have (at least I hope so).

However we are probably going to find it easier to look at the patches from the
RHEL-AS3 (etc) series than the RHEL-2.1 series since I'd guess that their
kernel-2.4.21-15.0.4.EL is (probably) a good deal closer to the 2.4.20-* used in
RH73/9 for legacy.

https://rhn.redhat.com/errata/RHSA-2004-413.html lists the following CAN fixes:

CAN-2004-0178   sb16 driver
CAN-2004-0415   64-bit pointer conversion 
CAN-2004-0447   local DOS for IA64
CAN-2004-0535   e1000 driver
CAN-2004-0587   qla2* driver

of these I think we already have patches for all but 0415 and 0447 (but that is
IA64 only and an earlier IA64-only patch failed to get into -legacy).

If we are lucky the patch for 0415 will be small and apply cleanly to the proto

We are still waiting for -35 to make it from updates-testing/ and into updates/
arn't we?

------- Additional Comments From michal@harddata.com 2004-08-05 05:45:06 ----

> I think that the e1000 and qla patches are probably equivalent to the ones we
> already have (at least I hope so).

I did not see that patch to qla in kernel-2.4.20-35.7.legacy.src.rpm.
That one-liner for e1000 is cleaning up a newly allocated memory so I should
have describe it as an additional part of that patch which was not there.
The rest is already in.  As I wrote in notes all that is for 2.4.20-35.7.legacy.
If this was already patched elsewhere then even better.

Should we worry about ia64 issues for this kernel?

------- Additional Comments From jp107@damtp.cam.ac.uk 2004-08-05 07:22:06 ----

The QLA patch isn't in -35 since it went for QA (and into updates-testing)
before the bug was reported.  This bug entry was opened for another couple of
earlier bugs:

 - add patch to fix missing checks in fchown() (CAN-2004-0497)
 - Drop Broadcom 5820 driver due to code quality concerns.

I made a test -36 for this but no-one wanted to delay release of -35 since it
had already been running for FAR too long.  I was expecting -35 to reach
updates/ and then we could add the other bugs reported since etc.  Comments 6
through 10 discuss the qla problem, though I'd already taken down my test RH9
machine so didn't offer a kernel at that time.

Since I'm about to roll in these patches for my own use (on my RH8 boxes), I'll
try to get round to building a RH9 version too for people to look at.

 -- Jon

------- Additional Comments From jp107@damtp.cam.ac.uk 2004-08-05 10:39:13 ----

Created an attachment (id=796)
proto patch for the file-offset-fixes

based on file-offset-fixes from RHEL AS3

------- Additional Comments From jp107@damtp.cam.ac.uk 2004-08-05 10:44:51 ----

I've just completed one build using that patch in addition to the existing
patches in the -36.  

I also added in the following patch changes for the extra e1000 and qla stuff:

diff -ur RPM-ORIG/SOURCES/linux-2.4.27pre-e1000-fix.patch
--- RPM-ORIG/SOURCES/linux-2.4.27pre-e1000-fix.patch    2004-06-23
16:00:01.000000000 +0100
+++ RPM-NEW/SOURCES/linux-2.4.27pre-e1000-fix.patch     2004-08-05
21:43:29.000000000 +0100
@@ -1,5 +1,14 @@
 --- 1.28/drivers/net/e1000/e1000_ethtool.c     2004-06-17 10:21:22 -07:00
 +++ 1.29/drivers/net/e1000/e1000_ethtool.c     2004-06-17 10:21:22 -07:00
+@@ -165,6 +165,8 @@
+ {
+       struct e1000_hw *hw = &adapter->hw;
++      memset(regs_buff, 0, E1000_REGS_LEN * sizeof(uint32_t));
+       regs->version = (1 << 24) | (hw->revision_id << 16) | hw->device_id;
+       regs_buff[0]  = E1000_READ_REG(hw, CTRL);
 @@ -1514,6 +1514,9 @@
                if(copy_from_user(&regs, addr, sizeof(regs)))
diff -ur RPM-ORIG/SOURCES/linux-2.4.9-qla2200.patch
--- RPM-ORIG/SOURCES/linux-2.4.9-qla2200.patch  2003-12-09 22:31:25.000000000 +0000
+++ RPM-NEW/SOURCES/linux-2.4.9-qla2200.patch   2004-08-05 21:43:46.000000000 +0100
@@ -46553,7 +46553,7 @@
 +                      host->hostt->proc_dir->name, 
 +                      APIDEV_NODE, apidev_major);)
-+      proc_mknod(APIDEV_NODE, 0777+S_IFCHR, host->hostt->proc_dir,
++      proc_mknod(APIDEV_NODE, 0600+S_IFCHR, host->hostt->proc_dir,
 +                      (kdev_t)MKDEV(apidev_major, 0));
 +      return 0;

I dislike patching patches, but is is what RH do.

Once I've rebuild my RH9 test machine I'll check it build there too.

------- Additional Comments From jp107@damtp.cam.ac.uk 2004-08-05 15:42:21 ----

CAN-2004-0685 usb sparse fixes in 2.4 see fc1 bugzilla entry

Includes a pointer to the upstream fix

I'll add this to the set of patches for the next round...

------- Additional Comments From jp107@damtp.cam.ac.uk 2004-08-06 04:12:42 ----

Unless anyone objects strongly I plan to include the patch for this NFS locking
bug too:



this made it into 2.4.23 so has probably been tested a good deal now.  I've been
using it on my machines for a while now with no obvious ill effects.

------- Additional Comments From jp107@damtp.cam.ac.uk 2004-08-07 22:08:25 ----

Created an attachment (id=800)
Proto QA for test kernel for RH9

The propose patch 796 needed minor corrections for
it to be usable on RH9.

As the QA says I currently have this kernel running on one
i686 RH9 machine (only for a few hours so far).

------- Additional Comments From jp107@damtp.cam.ac.uk 2004-08-16 03:44:42 ----

I should perhaps add that I've now been running RH8 versions of these kernels on
7 machines for about 8 days and we upgraded the rest of our ~190 RH8 machines to
use them last wednesday.  So far no obvious problems have been reported.

------- Additional Comments From michal@harddata.com 2004-08-16 05:59:35 ----

I am running similar kernels on a few 7.3 machines for over three weeks now.
They are not exactly equivalent to what Jon ended up with but where they
differ it is not used on my hosts.

------- Additional Comments From dom@earth.li 2004-08-30 08:19:24 ----

availble for completeness (identical to Jon's 37.9.legacy except for the usual
NPTL stuff).

------- Additional Comments From dom@earth.li 2004-09-11 04:50:24 ----

Hash: SHA1

QA for rh 7.3 and rh9:

af710edd4bb44e1fd7225550cb594df54e578aff  kernel-2.4.20-37.7.legacy.src.rpm
26a857dc390c066618412cf5c32a881c98f78e31  kernel-2.4.20-37.9.legacy.src.rpm

builds, installs, runs cleanly (running on ~ 100 rh7.3 machines for three
weeks including 1 and 2 processor Xeons, Athlons and P4s. Runs on 1 test
rh9 box too)

Details breakdown of changes vs. 35.7.legacy:

linux-2.4.18-missing-license-tags.patch patches
- - drivers/crypto/bcm/dispatch.c

all OK

linux-2.4.21-file-offset-fixes.patch patches
- - lots of stuff...

This patch is identical to that in 2.4.21-15.0.4.EL with the exceptions:
- - arch/cris/drivers/eeprom.c not patched
- - arch/ia64/kernel/efivars.c not patched
- - arch/ia64/kernel/salinfo.c not patched
- - arch/mips/sibyte/sb1250/bcm1250_tbprof.c not patched
- - arch/ppc/kernel/ppc_htab.c not patched
- - arch/ppc/platforms/proc_rtas.c not patched
- - arch/ppc64/kernel/lparcfg.c not patched
- - arch/ppc64/kernel/nvram.c not patched
- - arch/ppc64/kernel/proc_pmc.c not patched
- - arch/ppc64/kernel/rtas-proc.c not patched
- - arch/ppc64/kernel/rtas_flash.c not patched
- - arch/s390/kernel/debug.c not patched
- - arch/s390x/kernel/debug.c not patched
- - drivers/s390/char/tape_char.c not patched
- - drivers/s390/net/qeth.c not patched
- - drivers/s390/scsi/zfcp.c not patched

All of the above do not relate to our arch so can be ignored.

- - drivers/acpi/system.c not patched
  (file does not exist in our tree but is the vulnerable code elsewhere?
   greps indicate not)
- - drivers/char/raw.c not fully patched
  (needs checking)
- - drivers/oprofile/oprofilefs.c not fully patched
  (not used in our tree so ok)
- - mm/shmem.c not fully patched
  (needs checking)

so drivers/char/raw.c and mm/shmem.c need a quick check through by someone
who groks more C than I do.

linux-2.4.23-03-fix_osx.dif patches
- - fs/lockd/svclock.c
- - fs/lockd/xdr.c
- - fs/lockd/xdr4.c
- - include/linux/lockd/debug.h
- - include/linux/lockd/xdr.h

linux-2.4.27pre-e1000-fix.patch patches
- - drivers/net/e1000/e1000_ethtool.c


linux-2.4.27pre-nfs-fchown.patch patches
- - fs/attr.c


linux-2.4.9-qla2200.patch (fix applied inside patch)


linux-RHEL-missing-fixes.patch patches
- - fs/proc/proc_tty.c
- - fs/binfmt_elf.c
- - net/unix/af_unix.c
- - net/socket.c
- - drivers/char/vt.c
- - drivers/char/consolemap.c
- - drivers/cdrom/cdu31a.c
- - drivers/isdn/pcbit/capi.c
- - drivers/isdn/isdn_ppp.h
- - drivers/isdn/isdn_common.c
- - arch/i386/kernel/mtrr.c
- - arch/i386/kernel/traps.c
- - arch/i386/kernel/entry.S

Looks OK

linux-usb-sparse.patch patched
- - drivers/usb/audio.c
- - drivers/usb/brlvger.c
- - drivers/usb/serial/io_edgeport.c
- - rivers/usb/vicam.c

matches upstream, OK

I'd say get this built for updates-testing ASAP.

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


------- Additional Comments From dom@earth.li 2004-09-17 15:30:10 ----

Draft advisory:

------- Additional Comments From marcdeslauriers@videotron.ca 2004-09-17 17:20:10 ----

CAN-2004-0003 seems to be listed twice in the advisory and in the summary up at
top. Wow, now that's a lot of CAN numbers :)

------- Additional Comments From dom@earth.li 2004-09-18 00:24:23 ----

Fixed, thanks.

------- Additional Comments From barryn@pobox.com 2004-09-23 10:57:28 ----

The URLs for the Red Hat 9 packages look wrong in the draft advisory. 39.7? I
think those "39.7"'s should all be "37.9".

------- Additional Comments From dom@earth.li 2004-09-29 01:00:13 ----

Hash: SHA1

This update can be downloaded from:



Version: GnuPG v1.2.4 (GNU/Linux)


------- Additional Comments From b.pennacchi@istc.cnr.it 2004-10-08 01:31:08 ----

Downloaded it more than one week ago, running it now as default kernel at bootup
after 4 bootups as "test", no problems found yet, so far.

For me, maybe it counts as a VERIFY. Do I have to mark it as verified too? I'm
still a bit new to this bugzilla...


------- Additional Comments From dom@earth.li 2004-10-08 01:34:51 ----


No, don't mark it as VERIFIED, that flag should only be set when sufficient
formal verifies have taken place.

To make your report more useful could you:

- PGP sign your report
- include the sha1sums of the files you have used
See for example https://bugzilla.fedora.us/show_bug.cgi?id=2072#c11.


------- Additional Comments From b.pennacchi@istc.cnr.it 2004-10-08 02:07:45 ----

Hash: SHA1
Ok, will try to make it more useful as per Dominc's suggestions :-)
Installed it more than one week ago, running it now as default kernel at
bootup, after 4 bootups as "test". No problems found yet, so far.
For me, this might count as one VERIFY.
> $ rpm --checksig -v kernel-2.4.20-37.9.legacy.i686.rpm
> kernel-2.4.20-37.9.legacy.i686.rpm:
>     Header V3 DSA signature: OK, key ID 731002fa
>     Header SHA1 digest: OK (72d10e2c6a5326ad79b87f8252de217e61e531e1)
>     MD5 digest: OK (e475da6817a1058a6ae725c352bd2ec6)
>     V3 DSA signature: OK, key ID 731002fa
> $ sha1sum kernel-2.4.20-37.9.legacy.i686.rpm
> 4a61fc7fd41a7d35cfcc25178ec5cb659ed3f6fe  kernel-2.4.20-37.9.legacy.i686.rpm
> $ md5sum kernel-2.4.20-37.9.legacy.i686.rpm
> 7722a8593503d5ba5c917b1f11f60a2b  kernel-2.4.20-37.9.legacy.i686.rpm
sha1sum checks with the one sent by Dominic in abovesaid kernel's
email announcement.
(trying now to pgp-sign it :p -- sorry for my clumsiness :-)
Version: GnuPG v1.2.1 (GNU/Linux)

------- Additional Comments From S.J.Thompson@cs.bham.ac.uk 2004-10-13 14:12:07 ----

Hash: SHA1

Testing RedHat 9 versions only (don't have any RH7.3 boxes I can test this on)

4fdcc24dba64ef30ce49b170f6bbd3be98a129d8  kernel-2.4.20-37.9.legacy.src.rpm
Builds ok for i386, i686 and athlon

RPMS Tested:
4a61fc7fd41a7d35cfcc25178ec5cb659ed3f6fe  kernel-2.4.20-37.9.legacy.i686.rpm
d03acba749f539607b3068670d8d2b12e7a98c02  kernel-smp-2.4.20-37.9.legacy.i686.rpm
65079b01af9d60ca90b6650690634aa5d0c79cfa  kernel-source-2.4.20-37.9.legacy.i386.
6283845b3af07cf065902f3e75312a3ef7b5c90a  kernel-doc-2.4.20-37.9.legacy.i386.rpm
dd464f337d30580cd60b279d3b28f1ff972b718c  kernel-BOOT-2.4.20-37.9.legacy.i386.rp

RPMS non tested (no suitable machine to run them on):
f93b63bc5a40f24351a2d7855aaa66aacf6b1349  kernel-2.4.20-37.9.legacy.athlon.rpm
15c94e731201db0ad89b41d9b2c35e7f85d6f517  kernel-2.4.20-37.9.legacy.i386.rpm
5ee67818d1902c1e7ef919e1986c4c6f5cb58b6c  kernel-2.4.20-37.9.legacy.i586.rpm
790eef91cb194f60ab6c9ec5b0c4f08365b02022  kernel-bigmem-2.4.20-37.9.legacy.i686.
25f86ab0bb3cfb9e1cf03e71af16c3d58e3db12b  kernel-smp-2.4.20-37.9.legacy.athlon.r
c3f2461bd36aba58139e3cb29e34ecf9e97f6daf  kernel-smp-2.4.20-37.9.legacy.i586.rpm

Running 'rpm --checksig -v' on all packages (including those not actually instal
led) indicates packages are correctly signed.

Tested on a couple of machines using i686 kernel, both the up and smp versions (
the smp on a hyper-threaded machine). All machines tested have been up for sever
al days without any problems and have taken their usual beating from our users.

The -BOOT kernel seems fine (have rebuilt a CD image with the updated kernel inc
luded and done a PXE network install running the new kernel).

The NFS server seems to work ok - the machine I net-installed from was NFS mouti
ng the updated CD image from a machine running the updated kernel. Mounting shar
es from the linux box has also been possible on fBSD and Solaris systems. (Comme
nt #22).

Have rebuilt the kernel on a machine running the updated kernel to give it a bit
 of work to do.

Kernels install ok into lilo (not checked grub).

Version: GnuPG v1.2.1 (GNU/Linux)


------- Additional Comments From mgerber@leitwerk.de 2004-10-14 05:24:28 ----

Hash: SHA1

For RH73:

b7a9696838f7c981fa9dc7f016c626f068d77f32  kernel-2.4.20-37.7.legacy.i386.rpm
kernel-2.4.20-37.7.legacy.i386.rpm: md5 gpg OK

Kernel RPM installs and runs fine. No issues here. It survives my load tests 
on test machine, so I vote for VERIFY. (Can't provide better testing here 
as we are using IPSec-patched kernel packages otherwise, which are still 
based on an older release with my custom patches.)

I'm using a fresh GPG key, the older ones expired, see the keys here:
Version: GnuPG v1.2.4 (GNU/Linux)


------- Additional Comments From dom@earth.li 2004-10-14 12:23:30 ----

Hash: SHA1

f93b63bc5a40f24351a2d7855aaa66aacf6b1349  kernel-2.4.20-37.9.legacy.athlon.rpm
4fdcc24dba64ef30ce49b170f6bbd3be98a129d8  kernel-2.4.20-37.9.legacy.src.rpm

- - source package builds
- - binary package installs boots, and runs for a day or so without problems.

Version: GnuPG v1.2.4 (GNU/Linux)


------- Additional Comments From mattdm@mattdm.org 2004-10-14 15:14:20 ----

I have several people here (BU) testing this, and it's been fine for most
people, but with one report of a system hanging with matlab running a
calculation + compiling the kernel. New processes wouldn't start, perhaps as if
the machine were memory starved -- but it was a 4GB system. I'll try to get more
details and see if we can recreate the problem. Not trying to hold this up any
further. :)

------- Additional Comments From mattdm@mattdm.org 2004-10-15 09:32:36 ----

Re: my comment #39 -- we can't recreate this. So don't let it be a holdup.

------- Additional Comments From dom@earth.li 2004-10-18 01:31:16 ----

Released to updates.

------- Bug moved to this database by dkl@redhat.com 2005-03-30 18:25 -------

This bug previously known as bug 1804 at https://bugzilla.fedora.us/
Originally filed under the Fedora Legacy product and Package request component.

proto patch for the file-offset-fixes
Proto QA for test kernel for RH9

Unknown priority P2. 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.