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: http://marc.theaimsgroup.com/?l=bugtraq&m=108802653409053&w=2 ------- Additional Comments From marcdeslauriers 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. Dave ------- Additional Comments From marcdeslauriers 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. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0497 http://www.redhat.com/archives/fedora-announce-list/2004-July/msg00005.html ------- Additional Comments From jp107.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!) http://www.damtp.cam.ac.uk/user/jp107/legacy/9/SRPMS/kernel.changes 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! http://www.damtp.cam.ac.uk/user/jp107/legacy/9/SRPMS/kernel-2.4.20-36.9.legacy.src.rpm I'm testing building it now on RH9... ------- Additional Comments From dom 2004-07-02 04:58:13 ---- *** Bug 1810 has been marked as a duplicate of this bug. *** ------- Additional Comments From jp107.ac.uk 2004-07-02 10:55:58 ---- I'm testing the 686 kernel now running on a pair of RH9 test boxes. http://www.damtp.cam.ac.uk/user/jp107/legacy/9/bug-1804-proto-qa.asc will turn into a qa at some point when I'm not so late for the pub... ------- Additional Comments From marcdeslauriers 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. http://cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-0587 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126396 ------- Additional Comments From jp107.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 defined. 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 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 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, to + 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.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 2004-07-13 14:47:07 ---- Here's another flaw: http://www.securityfocus.com/archive/1/366752/2004-06-19/2004-06-25/0 ------- Additional Comments From marcdeslauriers 2004-07-13 14:48:14 ---- CAN Reference for last flaw: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0658 ------- Additional Comments From jp107.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 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. https://rhn.redhat.com/errata/RHSA-2004-418.html ------- Additional Comments From michal 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.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 update. We are still waiting for -35 to make it from updates-testing/ and into updates/ arn't we? ------- Additional Comments From michal 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.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.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.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-NEW/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(®s, addr, sizeof(regs))) diff -ur RPM-ORIG/SOURCES/linux-2.4.9-qla2200.patch RPM-NEW/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.ac.uk 2004-08-05 15:42:21 ---- CAN-2004-0685 usb sparse fixes in 2.4 see fc1 bugzilla entry http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127921 Includes a pointer to the upstream fix http://linux.bkbits.net:8080/linux-2.4/cset@410582380U3H9KOx8J2YZmMT0bhXQw I'll add this to the set of patches for the next round... ------- Additional Comments From jp107.ac.uk 2004-08-06 04:12:42 ---- Unless anyone objects strongly I plan to include the patch for this NFS locking bug too: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125996 http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/2.4.23-rc1/linux-2.4.23-03-fix_osx.dif 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.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.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 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 2004-08-30 08:19:24 ---- http://www-astro.physics.ox.ac.uk/~dom/legacy/SRPMS/kernel-2.4.20-37.7.legacy.src.rpm availble for completeness (identical to Jon's 37.9.legacy except for the usual NPTL stuff). ------- Additional Comments From dom 2004-09-11 04:50:24 ---- -----BEGIN PGP SIGNED MESSAGE----- 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 OK linux-2.4.27pre-nfs-fchown.patch patches - - fs/attr.c OK linux-2.4.9-qla2200.patch (fix applied inside patch) OK 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. PUBLISH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBQw/2YzuFKFF44qURAiPRAKCHcF4Z12W0B4B40pqW56aUtc0WtgCfdLhu ELV6oRvzSnB+3rdksI3Lhrg= =6F+j -----END PGP SIGNATURE----- ------- Additional Comments From dom 2004-09-17 15:30:10 ---- Draft advisory: http://www-astro.physics.ox.ac.uk/~dom/legacy/advisories/1804-kernel-draft.txt ------- Additional Comments From marcdeslauriers 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 2004-09-18 00:24:23 ---- Fixed, thanks. ------- Additional Comments From barryn 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 2004-09-29 01:00:13 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 8a1c65a280190c3fc5102bb5a37db4a6d38dc38c 7.3/updates-testing/i386/kernel-2.4.20-37.7.legacy.athlon.rpm b7a9696838f7c981fa9dc7f016c626f068d77f32 7.3/updates-testing/i386/kernel-2.4.20-37.7.legacy.i386.rpm b01d2fc73b95e89a67b9490b7f7c4261be0b2d92 7.3/updates-testing/i386/kernel-2.4.20-37.7.legacy.i586.rpm 2c64ea0f6f088eeb2a47eed62f20fce086695f1f 7.3/updates-testing/i386/kernel-2.4.20-37.7.legacy.i686.rpm e76f2bbdb94c0baa2d8c81df33f1f001b4eb6515 7.3/updates-testing/i386/kernel-bigmem-2.4.20-37.7.legacy.i686.rpm 302b9f0ae8e4b8dc975b0243ada68287508d85e9 7.3/updates-testing/i386/kernel-BOOT-2.4.20-37.7.legacy.i386.rpm c63c54ec6da4d10a21cd768d9596edb463dab3f3 7.3/updates-testing/i386/kernel-doc-2.4.20-37.7.legacy.i386.rpm ca0abce4704e89972b4d55edc615d1ac77c9038a 7.3/updates-testing/i386/kernel-smp-2.4.20-37.7.legacy.athlon.rpm e151c2fe55bfb2ecc802ccbc82b176b6e6e32e27 7.3/updates-testing/i386/kernel-smp-2.4.20-37.7.legacy.i586.rpm 8cddf2b85c8e0aa6442d111a4190c2b2ebc65d45 7.3/updates-testing/i386/kernel-smp-2.4.20-37.7.legacy.i686.rpm 40595f8d08b8b631742cfb891168a96de36364f0 7.3/updates-testing/i386/kernel-source-2.4.20-37.7.legacy.i386.rpm d5122c56d20371d25921a789f20b4a429f0ed0ee 7.3/updates-testing/SRPMS/kernel-2.4.20-37.7.legacy.src.rpm f93b63bc5a40f24351a2d7855aaa66aacf6b1349 9/updates-testing/i386/kernel-2.4.20-37.9.legacy.athlon.rpm 15c94e731201db0ad89b41d9b2c35e7f85d6f517 9/updates-testing/i386/kernel-2.4.20-37.9.legacy.i386.rpm 5ee67818d1902c1e7ef919e1986c4c6f5cb58b6c 9/updates-testing/i386/kernel-2.4.20-37.9.legacy.i586.rpm 4a61fc7fd41a7d35cfcc25178ec5cb659ed3f6fe 9/updates-testing/i386/kernel-2.4.20-37.9.legacy.i686.rpm 790eef91cb194f60ab6c9ec5b0c4f08365b02022 9/updates-testing/i386/kernel-bigmem-2.4.20-37.9.legacy.i686.rpm dd464f337d30580cd60b279d3b28f1ff972b718c 9/updates-testing/i386/kernel-BOOT-2.4.20-37.9.legacy.i386.rpm 6283845b3af07cf065902f3e75312a3ef7b5c90a 9/updates-testing/i386/kernel-doc-2.4.20-37.9.legacy.i386.rpm 25f86ab0bb3cfb9e1cf03e71af16c3d58e3db12b 9/updates-testing/i386/kernel-smp-2.4.20-37.9.legacy.athlon.rpm c3f2461bd36aba58139e3cb29e34ecf9e97f6daf 9/updates-testing/i386/kernel-smp-2.4.20-37.9.legacy.i586.rpm d03acba749f539607b3068670d8d2b12e7a98c02 9/updates-testing/i386/kernel-smp-2.4.20-37.9.legacy.i686.rpm 65079b01af9d60ca90b6650690634aa5d0c79cfa 9/updates-testing/i386/kernel-source-2.4.20-37.9.legacy.i386.rpm 4fdcc24dba64ef30ce49b170f6bbd3be98a129d8 9/updates-testing/SRPMS/kernel-2.4.20-37.9.legacy.src.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWpWWYzuFKFF44qURAiUtAKDP52x/5llqkj+CoYmwZGwCTafP7wCfZMY+ TBtYm4v/efdPj5AMPDqnzRg= =cxwp -----END PGP SIGNATURE----- ------- Additional Comments From b.pennacchi.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... b. ------- Additional Comments From dom 2004-10-08 01:34:51 ---- Hi, 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. Thanks! ------- Additional Comments From b.pennacchi.it 2004-10-08 02:07:45 ---- -----BEGIN PGP SIGNED MESSAGE----- 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 :-) b. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBZoK/kYABghcrexsRAvJFAJ9MIjeb7fWv927c2x8bWOLzcNVvvQCbBLBC 5gDEam3SV+GW2DBoZlRulGs= =nt/J -----END PGP SIGNATURE----- ------- Additional Comments From S.J.Thompson.ac.uk 2004-10-13 14:12:07 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Testing RedHat 9 versions only (don't have any RH7.3 boxes I can test this on) SRPM: 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. rpm 6283845b3af07cf065902f3e75312a3ef7b5c90a kernel-doc-2.4.20-37.9.legacy.i386.rpm dd464f337d30580cd60b279d3b28f1ff972b718c kernel-BOOT-2.4.20-37.9.legacy.i386.rp m 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. rpm 25f86ab0bb3cfb9e1cf03e71af16c3d58e3db12b kernel-smp-2.4.20-37.9.legacy.athlon.r pm 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). +VERIFY -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBbcOn6PpxfDLZ0SgRArODAJsE+w8YfSKnrumH0cvhl96fFjcbkwCfREwh e7T0u+hAWrD2KPgCuO5dZpY= =rwQv -----END PGP SIGNATURE----- ------- Additional Comments From mgerber 2004-10-14 05:24:28 ---- -----BEGIN PGP SIGNED MESSAGE----- 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: http://pgp.mit.edu:11371/pks/lookup?search=Mike+Gerber&op=index -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBbpltCjsw+mN5avkRAvwVAJ9yQjwwgwx2ra4iRlf8OUhrRK0M4gCbBH6D 5T/7blE1Ceh+/9tomVlyTWs= =HUXZ -----END PGP SIGNATURE----- ------- Additional Comments From dom 2004-10-14 12:23:30 ---- -----BEGIN PGP SIGNED MESSAGE----- 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. VERIFY -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBbvw8YzuFKFF44qURApA3AKDTEbFaFhhekYCp2pX+X/E67s1eaQCg9Wsg J9LsTe/RUqGAe/vTboHveTA= =HHNz -----END PGP SIGNATURE----- ------- Additional Comments From mattdm 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 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 2004-10-18 01:31:16 ---- Released to updates. ------- Bug moved to this database by dkl 2005-03-30 18:25 ------- This bug previously known as bug 1804 at https://bugzilla.fedora.us/ https://bugzilla.fedora.us/show_bug.cgi?id=1804 Originally filed under the Fedora Legacy product and Package request component. Attachments: proto patch for the file-offset-fixes https://bugzilla.fedora.us/attachment.cgi?action=view&id=796 Proto QA for test kernel for RH9 https://bugzilla.fedora.us/attachment.cgi?action=view&id=800 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.