as usual, paul starzetz disclosed linux kernel vulnerabilities (CAN-2004-1070,1071,1072,1073). see http://isec.pl/vulnerabilities/isec-0017-binfmt_elf.txt and then florian heinz reported a DOS (CAN-2004-1074). see http://marc.theaimsgroup.com/?l=linux-kernel&m=110021173607372 and then stefan esser reported smbfs-related vulns (CAN-2004-0883,0949). see http://security.e-matters.de/advisories/142004.html ------- Additional Comments From bugzilla.fedora.us 2004-12-12 05:43:59 ---- there's also this DOS-able resource leak: http://marc.theaimsgroup.com/?l=linux-kernel&m=109776571411003 ------- Additional Comments From bugzilla.fedora.us 2004-12-14 08:51:17 ---- and now starzetz has found more exploitable bugs (CAN-2004-1137). http://isec.pl/vulnerabilities/isec-0018-igmp.txt ------- Additional Comments From bugzilla.fedora.us 2004-12-14 09:01:33 ---- starzetz never lets up... now, a local DOS (CAN-2004-1016). http://isec.pl/vulnerabilities/isec-0019-scm.txt ------- Additional Comments From bugzilla.fedora.us 2004-12-14 13:15:05 ---- this bug should probably be duped on bug 2128, which already seems to be tracking new dawn attack fixes (modified rose attack), CAN-2004-0814, CAN-2004-1056, CAN-2004-0883, CAN-2004-0949, etc. ------- Additional Comments From siegert 2005-01-06 15:20:21 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have compiled new kernel packages for RH 7.3: They include patches for CAN-2004-0814, CAN-2004-0883, CAN-2004-0949, CAN-2004-1016, CAN-2004-1017, CAN-2004-1056, CAN-2004-1068, CAN-2004-1070, CAN-2004-1071, CAN-2004-1072, CAN-2004-1073, CAN-2004-1074, CAN-2004-1234. Most of the patches are from the SuSE-8.2 kernel-source-2.4.20.SuSE-127 package simply because those patches are for a 2.4.20 kernel. changelog: * Mon Jan 3 2005 Martin Siegert <siegert> - - replace patch for CAN-2004-0814 with slightly modified version of the gentoo-sources-2.4.20-CAN-2004-0814 patch. (http://dev.gentoo.org/~plasmaroo/patches/kernel/misc/security/) - - include drm_lock patch (CAN-2004-1056); modified version of patch from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138534 - - include elf-loader-setuid patch from kernel-source-2.4.20.SuSE-127 (CAN-2004-1070,CAN-2004-1071,CAN-2004-1072, and CAN-2004-1073) modified to apply after patch 11032 - - include smbfs-overflows.patch from kernel-source-2.4.20.SuSE-127 (CAN-2004-0883 and CAN-2004-0949) - - include aout-leak patch from kernel-source-2.4.20.SuSE-127 (CAN-2004-1074) - - include linux-2.4.20-nfsd-signed and linux-2.4.20-nfsd-xdr-write-wrap patches from kernel-source-2.4.20.SuSE-127 - - include cmsg-signedness patch from kernel-source-2.4.20.SuSE-127 (CAN-2004-1016) - - include dgram_recvmsg patch from kernel-source-2.4.20.SuSE-127 (CAN-2004-1068) - - include linux-2.4.20-ip-options-leak.patch from kernel-source-2.4.20.SuSE-127 - - include binfmt_elf patch from http://linux.bkbits.net:8080/linux-2.4/gnupatch@4076466d_SqUm4azg4_v3FIG2-X6XQ (CAN-2004-1234) - - include linux-2.4.21-CAN-2004-1017-io_edgeport.patch from the linux-2.4.21-usb-update.patch from RedHat's kernel-2.4.21-27.0.1.EL (CAN-2004-1017) The packages are available from ftp://ftp.sfu.ca/pub/linux/fedoralegacy/ # sha1sum kernel* 9cdfd23b7ac5c955418211c61af5699bd38e5be4 kernel-2.4.20-39.7.legacy.athlon.rpm 2693972e8cc77e7384c99ba6bcc0f64b30f42dc5 kernel-2.4.20-39.7.legacy.i386.rpm 5df0a24e5c4423f27970dfd8f96129708ea29b09 kernel-2.4.20-39.7.legacy.i586.rpm 1bb84f0677e0d2d3219ad25b3e55ef5361459885 kernel-2.4.20-39.7.legacy.i686.rpm 8dc8a5f0810918dc484b51adc4505d53faba7015 kernel-2.4.20-39.7.legacy.src.rpm 9355dcf01059cbe380489bffd042dacf84a1e79a kernel-bigmem-2.4.20-39.7.legacy.i686.rpm 474ef0c7d96b2381280cbcaab8aa83523987d986 kernel-BOOT-2.4.20-39.7.legacy.i386.rpm ecee66ccd9cbaeb1e1a7fe2b893867a6419e5d4e kernel-doc-2.4.20-39.7.legacy.i386.rpm adc33f03667c9c6c2d050334877f21f0e23bd09e kernel-smp-2.4.20-39.7.legacy.athlon.rpm 8035aef504bb630ed509c456858d439b427f1dab kernel-smp-2.4.20-39.7.legacy.i586.rpm e259212c3b3a55974a8c0819a0a12fb133c32345 kernel-smp-2.4.20-39.7.legacy.i686.rpm 1972ae8cc40dfecc457c9d9537d3a9c433b20de4 kernel-source-2.4.20-39.7.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFB3eMeBJ3vItFhAFcRAnANAJwOHrJ8wDRdAIcSl94Y1cACEft7twCeJOoC Jg8cz/KqV4KcuPf8B9RKs88= =fYW+ -----END PGP SIGNATURE----- ------- Additional Comments From siegert 2005-01-06 15:27:30 ---- Created an attachment (id=961) tar file with kernel patches Just for convenience I created a tarball containing all the patches that I incorporate in the 2.4.20-39.7 kernel. ------- Additional Comments From rob.myers.edu 2005-01-07 09:53:02 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 here are updated kernel rpms to QA for FC1: these are the CAN numbers i looked at, and the file that i believe fixes them (if the CAN applied). please look closely to make sure that each of these CANs are properly closed. also please let me know if i missed any CANs. the patches should include information on they are from, or from what they were inspired by. CAN-2004-0177 - already fixed CAN-2004-0565 - not vulnerable since FL does not do ia64 CAN-2004-0685 - kernel-2.4-usb-CAN-2004-0685.patch CAN-2004-0814 - linux-2.4.28-tty-CAN-2004-0814.patch CAN-2004-0883 - linux-2.4-smbfs-CAN-2004-0883-CAN-2004-0949.patch CAN-2004-0949 - linux-2.4-smbfs-CAN-2004-0883-CAN-2004-0949.patch CAN-2004-1016 - linux-2.4.21-cmsg-validation-CAN-2004-1016.patch CAN-2004-1017 - linux-2.4.22-io_edgeport-CAN-2004-1017.patch CAN-2004-1056 - linux-2.4-drm-lock-CAN-2004-1056.patch CAN-2004-1058 - 2.6 only CAN-2004-1068 - linux-2.4-unix-serialization-CAN-2004-1068.patch CAN-2004-1070 - linux-2.4.22-binfmt_elf.patch CAN-2004-1071 - linux-2.4.22-binfmt_elf.patch CAN-2004-1072 - linux-2.4.22-binfmt_elf.patch CAN-2004-1073 - linux-2.4.22-binfmt_elf.patch CAN-2004-1074 - linux-2.4.22-aout-CAN-2004-1074.patch CAN-2004-1137 - linux-2.4.22-igmp-CAN-2004-1137.patch CAN-2004-1144 - not vulnerable since FL does not do x86-64 CAN-2004-1151 - not vulnerable since FL does not do x86-64 CAN-2004-1234 - linux-2.4.22-binfmt_elf.patch CAN-2004-1235 - linux-2.4.29-rc1-sys_uselib-race-CAN-2004-1235.patch i found exploit code for three CAN's: CAN-2004-1074 - perl -e'print"\x07\x01".("\x00"x13)."\xc0".("\x00"x16)'>eout ; sysctl -w vm.overcommit_memory=1 ; ./eout CAN-2004-1137 - see: http://isec.pl/vulnerabilities/isec-0018-igmp.txt CAN-2004-1235 - see: http://isec.pl/vulnerabilities/isec-0021-uselib.txt included patches with no known CAN assigned: linux-2.4-ip-options-leak.patch beware: these rpms have only been modestly tested. changelog: * Fri Jan 7 2005 Rob Myers <rob.myers.edu> 2.4.22-1.2199.3.legacy.nptl - - add patches for CAN-2004-1235 CAN-2004-1017 - - add patch for ip options leak * Fri Jan 7 2005 Rob Myers <rob.myers.edu> 2.4.22-1.2199.2.legacy.nptl - - clean up spec, rebuild * Thu Jan 6 2005 Rob Myers <rob.myers.edu> 2.4.22-1.2199.1.legacy.nptl - - patch CAN-2004-0685 CAN-2004-0814 CAN-2004-0883 CAN-2004-0949 CAN-2004-1016 CAN-2004-1056 CAN-2004-1068 CAN-2004-1070 CAN-2004-1071 CAN-2004-1072 CAN-2004-1073 CAN-2004-1074 CAN-2004-1137 CAN-2004-1234 sha1sum: 0e172199a60ea78d59b23dbf6965e05875875d4f kernel-2.4.22-1.2199.3.legacy.nptl.src.rpm files: http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-2.4.22-1.2199.3.legacy.nptl.src.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel.fc1.txt.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFB3ufptU2XAt1OWnsRAuKkAJwKe93QEsDy2yrVZFybJhJGg0WQ7ACfadIO sgun5TKwO7cJDYhhWrDYIl4= =T/5J -----END PGP SIGNATURE----- ------- Additional Comments From rob.myers.edu 2005-01-07 17:15:03 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 in case anyone wanted binary rpms... this file is availabe here: http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel.fc1.bin.txt.asc files: http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-2.4.22-1.2199.3.legacy.nptl.i686.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-debuginfo-2.4.22-1.2199.3.legacy.nptl.i686.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-smp-2.4.22-1.2199.3.legacy.nptl.i686.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-BOOT-2.4.22-1.2199.3.legacy.nptl.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-doc-2.4.22-1.2199.3.legacy.nptl.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-debuginfo-2.4.22-1.2199.3.legacy.nptl.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-source-2.4.22-1.2199.3.legacy.nptl.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-2.4.22-1.2199.3.legacy.nptl.i586.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-debuginfo-2.4.22-1.2199.3.legacy.nptl.i586.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-smp-2.4.22-1.2199.3.legacy.nptl.i586.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-2.4.22-1.2199.3.legacy.nptl.athlon.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-debuginfo-2.4.22-1.2199.3.legacy.nptl.athlon.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-smp-2.4.22-1.2199.3.legacy.nptl.athlon.rpm sha1sums: 7306fd0521989875950bd73adbf50aedf6fa2563 kernel-2.4.22-1.2199.3.legacy.nptl.i686.rpm b5136bbc34cf764f023925f4557cb6519ed4f28f kernel-debuginfo-2.4.22-1.2199.3.legacy.nptl.i686.rpm bef50b036df270cd3c115181738ba23bb94b20b0 kernel-smp-2.4.22-1.2199.3.legacy.nptl.i686.rpm 7c77a1c27024e9871b6483d7332b3f9e6acb1a00 kernel-BOOT-2.4.22-1.2199.3.legacy.nptl.i386.rpm 9a8f690ce77f1186da39abd258c8f8ed939d0622 kernel-doc-2.4.22-1.2199.3.legacy.nptl.i386.rpm aeb3f4febd8b739d832d69c180c9d24f1ff66cf5 kernel-debuginfo-2.4.22-1.2199.3.legacy.nptl.i386.rpm 2fd95a440a8c1208508e9bc265c8d5458842ed31 kernel-source-2.4.22-1.2199.3.legacy.nptl.i386.rpm 8aa65f866e6d7e888a1d74610ec95b0c2f90bbd9 kernel-2.4.22-1.2199.3.legacy.nptl.i586.rpm c875e957b1f9c3851ac3e7a6927511ea2a7db283 kernel-debuginfo-2.4.22-1.2199.3.legacy.nptl.i586.rpm b2ebc7a08f56f69a0e80e893f9c6967bea4f5978 kernel-smp-2.4.22-1.2199.3.legacy.nptl.i586.rpm 64a8c4ef7d4ee6fdb9f471e600c30639ddaad26d kernel-2.4.22-1.2199.3.legacy.nptl.athlon.rpm 852bfae874a93de49cc6d2b18797794e7cfec2bd kernel-debuginfo-2.4.22-1.2199.3.legacy.nptl.athlon.rpm c7860326210ec510f00dc3c891489367dbad9d4b kernel-smp-2.4.22-1.2199.3.legacy.nptl.athlon.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFB308otU2XAt1OWnsRAgJmAKCAy07SymAjK3nPQSJK1xDfCijILQCgm4AZ n2tlKjxT3KA8fbXhGKhPOUc= =bD6N -----END PGP SIGNATURE----- ------- Additional Comments From dwb7.edu 2005-01-07 18:50:27 ---- Per the 7.3 kernels, should a patch for CAN-2004-1235 (the local root exploit mentioned on slashdot, today) get in there before this one goes out? ------- Additional Comments From simon 2005-01-07 19:56:27 ---- Yes definitely. I'm working on backporting the patch for 1235 right now. - Si ------- Additional Comments From simon 2005-01-07 21:36:41 ---- After having a good look through the code on our current 7.3 kernel src, I'm not convinced that 1235 is applicable. The structure of fs/binfmt_aout.c and fs/binfmt_elf.c look very different in our 7.3 2.4.20-x to the later 2.4.x kernel trees. I compiled the exploit in question and I have yet to see if run successfully on any of my 7.3 test boxes: ./elflbl child 1 VMAs 0 [+] moved stack bfffd000, task_size=0xc0000000, map_base=0xbf800000 [+] vmalloc area 0xcfc00000 - 0xdf597000 Wait... | [-] FAILED: try again (Cannot allocate memory) Killed ./elflbl -n 2 -w 20 [+] SLAB cleanup child 1 VMAs 65527 child 2 VMAs 65527 child 3 VMAs 65527 child 4 VMAs 65527 child 5 VMAs 65527 child 6 VMAs 64739 [+] moved stack bfffd000, task_size=0xc0000000, map_base=0xbf800000 [+] vmalloc area 0xcfc00000 - 0xdf597000 Wait... | [-] FAILED: uselib (Cannot allocate memory) Killed root@localhost fs]# uname -a Linux localhost.localdomain 2.4.20-37.7.legacy #1 Mon Sep 27 21:50:48 EDT 2004 i686 unknown I would appreciate some other comment on this, as it's a nasty local root exploit. redhat 9 definitely needs to be patched though: ./elflbl -n 2 -w 20 child 1 VMAs 0 [+] moved stack bfffd000, task_size=0xc0000000, map_base=0xbf800000 [+] vmalloc area 0xcfc00000 - 0xdf544000 Wait... - [+] race won maps=54887 expanded VMA (0xbfffc000-0xffffe000) [!] try to exploit 0xd08f6000 [+] gate modified ( 0xffec9074 0x0804ec00 ) [+] exploited, uid=0 uname -a Linux localhost.localdomain 2.4.20-37.9.legacy #1 Mon Sep 27 19:40:23 EDT 2004 i686 athlon i386 GNU/Linux - Si ------- Additional Comments From simon 2005-01-08 07:19:35 ---- ok, I take my previous comment back, I've now managed to exploit 7.3. - Si ------- Additional Comments From simon 2005-01-08 16:31:32 ---- I've backported a CAN-2004-1235 patch to 7.3 and I'm currently testing the new kernel. I'll finish building the i686 kernels and then post a url. - Si ------- Additional Comments From simon 2005-01-08 19:50:06 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Updated Redhat 7.3 test kernel packages are below. These include a backported CAN-2004-1235 patch. Please test these with caution. I am currently running a couple of machines on this kernel and it does seem to be stable. I have also done testing against the exploit, and this kernel does appear to protect against it. I would appreciate some people having a good look at the patch. * Fri Jan 7 2005 Simon Weller <simon> - - back ported 2.4.29 sys_uselib-race-CAN-2004-1235 patch sha1sum: 0c12d3cd59dfd788b036195369cff009f193a67e *kernel-2.4.20-40.7.legacy.i386.rpm f550b45021342b4ffbb81cbfada33ea803f17430 *kernel-BOOT-2.4.20-40.7.legacy.i386.rpm 40f3b4ca87bb3c155187409680020da93050a81c *kernel-doc-2.4.20-40.7.legacy.i386.rpm ea57b667c4f6db1d171e28b8d1c0ac5f2f913ed1 *kernel-source-2.4.20-40.7.legacy.i386.rpm 3da739ab5610b736bba534e9b0b2f46e37cb35b4 *kernel-2.4.20-40.7.legacy.i686.rpm 534cd02a97285885f4098057b910cc045140179e *kernel-bigmem-2.4.20-40.7.legacy.i686.rpm c4ff00ca16881db4c081b6d442090f620035ae68 *kernel-smp-2.4.20-40.7.legacy.i686.rpm SRPM: c144ffe28dc7334ea520d78c4c51615424cc99f3 *kernel-2.4.20-40.7.legacy.src.rpm Available here: http://fedoralegacy.potelweller.com/73testing/ - - Si -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB4LpwMLOCzgCQslsRAifvAKCwBXWTcOvApBqC+GHXqlTRLToXyQCgrRBZ fff9CAx63MPaCX6hLY3vZ+c= =/lUj -----END PGP SIGNATURE----- ------- Additional Comments From bugzilla.fedora.us 2005-01-09 11:26:52 ---- what are we doing with bug 2128? ------- Additional Comments From dwb7.edu 2005-01-10 05:46:24 ---- Looks like we might still be missing CAN-2004-0177 and CAN-2004-0744 on rh7.3. 0177 is an ext3 security hole (in the rhel2.1 kernel) and 0744 is the tcp fragmentation problem. ------- Additional Comments From rob.myers.edu 2005-01-10 06:14:31 ---- re comment #16: it is not clear to me what fixes CAN-2004-0744. if the changesets below resolve CAN-2004-0744, then 2.4.22-1.2199.3.legacy is still vulnerable to this issue. http://linux.bkbits.net:8080/linux-2.4/gnupatch@4123c971hKzmQKDWgBjD2OMQ5pd0Jw http://linux.bkbits.net:8080/linux-2.4/gnupatch@4132a90b_ZR2MJK9KLAcYgPV5naI5A there is attack code for CAN-2004-0744, so i guess i could attack with and without patches to see what happens... ------- Additional Comments From bugzilla.fedora.us 2005-01-10 11:55:12 ---- brad spengler recently disclosed some more kernel bugs. http://www.securityfocus.com/archive/1/386374 don't think they have CVE numbers, yet. ------- Additional Comments From dom 2005-01-11 02:39:12 ---- re comment #18: http://article.gmane.org/gmane.linux.kernel/268444 gives the impression that none of these bugs will be privilege escalation for us. We don't AFAIK ship any kernels with kernel capabilities enabled. This being the case I would suggest leaving this for now and concentrate on QA for the existing kernels from comment #7 and comment #14 (note that comment #14 applies to redhat 9 too with a quick spec file change - for completeness an SRPM for rh9 should be uploaded too). ------- Additional Comments From abo 2005-01-11 03:13:38 ---- Regarding CAN-2004-1235. I compared this Gentoo patch: http://bugs.gentoo.org/attachment.cgi?id=47970&action=view with this RHEL patch: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=109343&action=view The following was the only real difference, but I'm not sure what it means. It's not in the patch in kernel-2.4.20-40.7.legacy (comment #14). Gentoo bug is http://bugs.gentoo.org/show_bug.cgi?id=77025 --- linux-2.4.28-gentoo-r4/fs/binfmt_elf.c 2005-01-07 20:33:12.000000000 +0000 +++ linux-2.4.28-gentoo-r5/fs/binfmt_elf.c 2005-01-07 20:20:46.000000000 +0000 @@ -295,7 +297,9 @@ static unsigned long load_elf_interp(str */ if (interp_elf_ex->e_phentsize != sizeof(struct elf_phdr)) goto out; - if (interp_elf_ex->e_phnum > 65536U / sizeof(struct elf_phdr)) + + if (interp_elf_ex->e_phnum < 1 || + interp_elf_ex->e_phnum > 65536U / sizeof(struct elf_phdr)) goto out; /* Now read in all of the header information */ ------- Additional Comments From dom 2005-01-11 03:37:50 ---- regarding comment #14: the rpm is not GPG-signed, and I cannot successfully verify the GPG signature in comment. Please could you repost to correct these problems? ------- Additional Comments From simon 2005-01-11 06:28:04 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, this is a repost as requested. Updated Redhat 7.3 test kernel packages are below. These include a backported CAN-2004-1235 patch. Please test these with caution. I am currently running a couple of machines on this kernel and it does seem to be stable. I have also done testing against the exploit, and this kernel does appear to protect against it. I would appreciate some people having a good look at the patch. * Fri Jan 7 2005 Simon Weller <simon> - - back ported 2.4.29 sys_uselib-race-CAN-2004-1235 patch sha1sum: 0c12d3cd59dfd788b036195369cff009f193a67e *kernel-2.4.20-40.7.legacy.i386.rpm f550b45021342b4ffbb81cbfada33ea803f17430 *kernel-BOOT-2.4.20-40.7.legacy.i386.rpm 40f3b4ca87bb3c155187409680020da93050a81c *kernel-doc-2.4.20-40.7.legacy.i386.rpm ea57b667c4f6db1d171e28b8d1c0ac5f2f913ed1 *kernel-source-2.4.20-40.7.legacy.i386.rpm 3da739ab5610b736bba534e9b0b2f46e37cb35b4 *kernel-2.4.20-40.7.legacy.i686.rpm 534cd02a97285885f4098057b910cc045140179e *kernel-bigmem-2.4.20-40.7.legacy.i686.rpm c4ff00ca16881db4c081b6d442090f620035ae68 *kernel-smp-2.4.20-40.7.legacy.i686.rpm SRPM: c144ffe28dc7334ea520d78c4c51615424cc99f3 *kernel-2.4.20-40.7.legacy.src.rpm Available here: http://fedoralegacy.potelweller.com/73testing/ - - Si -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB4/teMLOCzgCQslsRAkz9AJ9DCvBwoPdvqhkFqBi59C80FEuQuQCdF8NH yU1o7Cg2vm+sF6GruSiPMWA= =oQNM -----END PGP SIGNATURE----- ------- Additional Comments From simon 2005-01-11 06:46:19 ---- I will patch the redhat 9 spec and build some kernels this evening. - Si ------- Additional Comments From siegert 2005-01-11 12:08:29 ---- Created an attachment (id=965) alternative CAN-2004-1235 patch I checked the CAN-2004-1235 patch from comment #14 (or #22) by basically recreating the patch: since the code that is touched by the CAN-2004-1235 patch (mainly binfmt_elf.c) is unchanged from 2.4.20 to 2.4.28 it should be possible to create the patch by simply using the binfmt_elf.c part from the latest kernel patch-2.4.29-rc1. This results in the attached patch. This patch is almost identical with Simon's patch with respect to those sections that are touched by both patches. The only difference is the definition of the set_brk function in binfmt_elf.c: static int set_brk instead of static void set_brk. This is probably without consequence although the patched function returns a value. The real problem is that my patch is bigger and touches other parts of binfmt_elf.c that are not patched by the original CAN-2004-1235 from linux.bkbits.net. This could mean that we are missing some other binfmt_elf.c patches that are not directly related to CAN-2004-1235. Are we? ------- Additional Comments From simon 2005-01-11 12:55:28 ---- That is possible. The main thing that I was concerned about at the time was applying code patches that might break our kernel, as some of the changes looked pretty drastic. I'm not a kernel hacking expert, hence I was staying on the safer side of the fence. - Si ------- Additional Comments From simon 2005-01-11 16:17:22 ---- I'm going to hold off on the redhat 9 rpm's until we have decided on the patch. You are correct in that the static int set_brk should be static void set_brk. - Si ------- Additional Comments From siegert 2005-01-11 16:33:36 ---- Sorry, I was clear, but I meant that it should be static int set_brk(unsigned long start, unsigned long end) And don't take me wrong: I am by no means a kernel expert and it could very well be that your patch is sufficient. I was just hoping that there is somebody on the list who would be able to give an answer ... I simply do not know. I am compiling a kernel with the modified patch right now for test purposes. If that crashes right away then we know. ------- Additional Comments From simon 2005-01-11 17:10:54 ---- Obviously I must be tired tonight ;-). I actually meant the other way around. void should be static as it's returning a value. - Si ------- Additional Comments From dom 2005-01-12 06:40:55 ---- Paul Starzetz has disclosed another kernel bug with CAN-2005-0001: http://isec.pl/vulnerabilities/isec-0022-pagefault.txt Exploitable on SMP/hyperthreaded machines only. ------- Additional Comments From simon 2005-01-12 07:29:20 ---- No patches available yet for CAN-2005-0001 as far as I can see. - Si ------- Additional Comments From pekkas 2005-01-12 08:24:37 ---- With regard to #24, #27 etc. I'd suggest we stick to the patches distributions or the upstream are using, as far as possible. QA is easier if the source of the patch is identified as clearly as possible.. ------- Additional Comments From dom 2005-01-12 13:56:15 ---- Not in bitkeeper yet, but 2.4.29-rc2 is out which fixes CAN-2005-0001 and updates another few fixes. ------- Additional Comments From rob.myers.edu 2005-01-13 05:40:20 ---- re comment 17: i have not been able to reliably reproduce load spikes with the latest fc1 kernels (both up and smp). i have not seen any other linux patches referencing CAN-2004-0744. are there any? it may still be wise to apply the patches linked in comment #17 in the next round of bugfixes. ------- Additional Comments From dwb7.edu 2005-01-13 12:55:08 ---- In the link mentioned for 2005-0001, it says, in the credits section: Paul Starzetz <ihaquer> has identified the vulnerability and performed further research. RedHat reported that a customer also pointed out some problems with the page fault handler on SMP about 20.12.2004 and they already included a patch for this vulnerability in the kernel-2.4.21-27.EL release, however the bug did not make it to the security division. Not clear on whether this means 2005-0001 is patched in that kernel, or not. Grabbing the srpm now to take a look. ------- Additional Comments From dwb7.edu 2005-01-14 06:14:47 ---- Created an attachment (id=967) 2.4.29-rc1 to rc2 expand_stack patch (CAN-2005-0001) This is the portion of the 2.4.29-rc1-rc2 diff incremental which would appear to be relevant to CAN-2005-0001. ------- Additional Comments From simon 2005-01-16 09:01:16 ---- I'll have new packages for 7.3 available later today. They will include Dave Botsch's CAN-2005-0001 patch, and the small fix in the CAN-2004-1235 patch changing static void set_brk to static int set_brk as spotted by Martin Siegert. - Si ------- Additional Comments From simon 2005-01-16 15:38:22 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Updated Redhat 7.3 test kernel packages are below. %changelog * Sun Jan 16 2005 Simon Weller <simon> - - Back ported CAN-2005-0001 expand_stack patch based on Dave Botsch's patch - - void changes to int in CAN-2004-1245 patch set_brk function - thanks to Martin Siegert sha1sum: 5dd024498b70e97843e111e5f7346a7ee7e6b8ec *kernel-2.4.20-41.7.legacy.i386.rpm 4652bfe444f1fe799125ce007f1e84cdc04423e4 *kernel-2.4.20-41.7.legacy.i686.rpm 0527f6144ea94f75e8224ff4e77176ef2be19fea *kernel-2.4.20-41.7.legacy.src.rpm 821c8f45156bcbb948ece875bce8222474083662 *kernel-bigmem-2.4.20-41.7.legacy.i686.rpm 4897b4292aa8aef0481d9ff0e0f0072e6548f1c7 *kernel-BOOT-2.4.20-41.7.legacy.i386.rpm eeb2c645daffbac6c5ab7a580faa5e90b0398963 *kernel-doc-2.4.20-41.7.legacy.i386.rpm 9bb2c9068d04bde7b053be5fa92b2cffe0abbd7e *kernel-smp-2.4.20-41.7.legacy.i686.rpm 244937b9711d748588e3910f21fc27548320f76d *kernel-source-2.4.20-41.7.legacy.i386.rpm Available here: http://fedoralegacy.potelweller.com/73testing/ - - Si -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB6xejMLOCzgCQslsRAiwYAKDH6v95x12bGEjASmqUjI56svQiMACgkAZF PC66zFL1YMEH75xxJUyZ+L8= =PNVv -----END PGP SIGNATURE----- ------- Additional Comments From dwb7.edu 2005-01-17 09:11:51 ---- While it seems to build ok, whilst building the rh7.3 binary i386 rpms, got the following errors (trimmed somewhat): ... warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/scm.h warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/slhc_vj.h warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/snmp.h warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/sock.h warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/spx.h warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/syncppp.h warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/tcp.h warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/tcp_ecn.h warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/transp_v6.h warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/tux.h warning: File listed twice: /usr/src/linux-2.4.20-41.7.legacy.ccmr.1/include/net/tux_u.h ... ------- Additional Comments From dom 2005-01-17 15:25:44 ---- That error has always occured with the FL branch of the kernel - I wouldn't worry about it. ------- Additional Comments From rob.myers.edu 2005-01-18 04:48:19 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 here are updated kernel rpms to QA for FC1: these are the CAN numbers i looked at, and the file that i believe fixes them (if the CAN applied). please look closely to make sure that each of these CANs are properly closed. also please let me know if i missed any CANs. the patches should include information on they are from, or from what they were inspired by. CAN-2004-0177 - already fixed CAN-2004-0565 - not vulnerable since FL does not do ia64 CAN-2004-0685 - kernel-2.4-usb-CAN-2004-0685.patch CAN-2004-0814 - linux-2.4.28-tty-CAN-2004-0814.patch CAN-2004-0883 - linux-2.4-smbfs-CAN-2004-0883-CAN-2004-0949.patch CAN-2004-0949 - linux-2.4-smbfs-CAN-2004-0883-CAN-2004-0949.patch CAN-2004-1016 - linux-2.4.21-cmsg-validation-CAN-2004-1016.patch CAN-2004-1017 - linux-2.4.22-io_edgeport-CAN-2004-1017.patch CAN-2004-1056 - linux-2.4-drm-lock-CAN-2004-1056.patch CAN-2004-1058 - 2.6 only CAN-2004-1068 - linux-2.4-unix-serialization-CAN-2004-1068.patch CAN-2004-1070 - linux-2.4.22-binfmt_elf.patch CAN-2004-1071 - linux-2.4.22-binfmt_elf.patch CAN-2004-1072 - linux-2.4.22-binfmt_elf.patch CAN-2004-1073 - linux-2.4.22-binfmt_elf.patch CAN-2004-1074 - linux-2.4.22-aout-CAN-2004-1074.patch CAN-2004-1137 - linux-2.4.22-igmp-CAN-2004-1137.patch CAN-2004-1144 - not vulnerable since FL does not do x86-64 CAN-2004-1151 - not vulnerable since FL does not do x86-64 CAN-2004-1234 - linux-2.4.22-binfmt_elf.patch CAN-2004-1235 - linux-2.4.29-rc1-sys_uselib-race-CAN-2004-1235.patch CAN-2005-0001 - linux-2.4.29-rc3-CAN-2005-0001.patch i found exploit code for four CAN's: CAN-2004-1074 - perl -e'print"\x07\x01".("\x00"x13)."\xc0".("\x00"x16)'>eout ; sysctl -w vm.overcommit_memory=1 ; ./eout CAN-2004-1137 - see: http://isec.pl/vulnerabilities/isec-0018-igmp.txt CAN-2004-1235 - see: http://isec.pl/vulnerabilities/isec-0021-uselib.txt CAN-2005-0001 - see: http://packetstormsecurity.org/0501-exploits/stackgrow2.c included patches with no known CAN assigned: leak ip options - linux-2.4-ip-options-leak.patch RLIMIT_MEMLOCK bypass (Brad Spengler) - linux-2.4.29-rc3-CAN-2005-0001.patch random poolsize sysctl integer overflow (Brad Spengler) - linux-2.4.29-rc2-security-fixes.patch moxa serial driver bss overflow (Brad Spengler) - linux-2.4.29-rc2-security-fixes.patch xfs misc fixes (Coverity/SGI) - linux-2.4.29-rc2-security-fixes.patch rose_rt_ioctl (Coverity) - linux-2.4.29-rc2-security-fixes.patch sdla_xfer (Coverity) - linux-2.4.29-rc2-security-fixes.patch coda tainted scalars (Coverity) - linux-2.4.29-rc2-security-fixes.patch beware: these rpms have only been modestly tested. changelog: * Fri Jan 14 2005 Rob Myers <rob.myers.edu> 2.4.22-1.2199.4.legacy.nptl - - patch for expand_stack SMP race CAN-2005-0001 - - patch for RLIMIT_MEMLOCK bypass NO-CAN-ASSIGNED - - patch for random poolsize sysctl handler integer overflow NO-CAN-ASSIGNED - - patch for moxa serial driver bss overflow NO-CAN-ASSIGNED - - patch for xfs misc fixes - NO-CAN-ASSIGNED - - patch for rose_rt_ioctl - lack of bounds checking NO-CAN-ASSIGNED - - patch for sdla_xfer - lack of bounds checking NO-CAN-ASSIGNED - - patch for coda - add bounds checking for tainted scalars NO-CAN-ASSIGNED * Fri Jan 7 2005 Rob Myers <rob.myers.edu> 2.4.22-1.2199.3.legacy.nptl - - add patches for CAN-2004-1235 CAN-2004-1017 - - add patch for ip options leak * Fri Jan 7 2005 Rob Myers <rob.myers.edu> 2.4.22-1.2199.2.legacy.nptl - - clean up spec, rebuild * Thu Jan 6 2005 Rob Myers <rob.myers.edu> 2.4.22-1.2199.1.legacy.nptl - - patch CAN-2004-0685 CAN-2004-0814 CAN-2004-0883 CAN-2004-0949 CAN-2004-1016 CAN-2004-1056 CAN-2004-1068 CAN-2004-1070 CAN-2004-1071 CAN-2004-1072 CAN-2004-1073 CAN-2004-1074 CAN-2004-1137 CAN-2004-1234 sha1sums: 77c0687dcc41fc690a3628eafcdc3a1070ae2936 kernel-2.4.22-1.2199.4.legacy.nptl.athlon.rpm 1bd95d9897c1e264f91ec0a3dbd5e25181ba3b62 kernel-2.4.22-1.2199.4.legacy.nptl.i686.rpm 3d4728c390620f532a55ece51a66ac7130da36b9 kernel-2.4.22-1.2199.4.legacy.nptl.src.rpm 18314ec8515f72b317ec7c7214a9ea389f0fc4cf kernel-BOOT-2.4.22-1.2199.4.legacy.nptl.i386.rpm 062b2d2587953bd72b334cf51429b6d0af3e865b kernel-debuginfo-2.4.22-1.2199.4.legacy.nptl.athlon.rpm 95ebd52edea08b19b32e4744f6bc500d3292f512 kernel-debuginfo-2.4.22-1.2199.4.legacy.nptl.i386.rpm 57b9563a920497a7014068654f6bec000e465df1 kernel-debuginfo-2.4.22-1.2199.4.legacy.nptl.i686.rpm 0872a93b229cf84ec3f2f4dd4b8a93d6e3eb3a7a kernel-doc-2.4.22-1.2199.4.legacy.nptl.i386.rpm 0798760f5bb53bc6ef2f448702db141928911186 kernel-smp-2.4.22-1.2199.4.legacy.nptl.athlon.rpm 805884e9f0a15d43de5ccec3930ecb896933188e kernel-smp-2.4.22-1.2199.4.legacy.nptl.i686.rpm 044aad4e67f0265573c028f6427df96113435b63 kernel-source-2.4.22-1.2199.4.legacy.nptl.i386.rpm files: http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel.fc1.txt.asc http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-2.4.22-1.2199.4.legacy.nptl.src.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-2.4.22-1.2199.4.legacy.nptl.athlon.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-smp-2.4.22-1.2199.4.legacy.nptl.athlon.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-debuginfo-2.4.22-1.2199.4.legacy.nptl.athlon.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-BOOT-2.4.22-1.2199.4.legacy.nptl.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-doc-2.4.22-1.2199.4.legacy.nptl.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-source-2.4.22-1.2199.4.legacy.nptl.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-debuginfo-2.4.22-1.2199.4.legacy.nptl.i386.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-2.4.22-1.2199.4.legacy.nptl.i686.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-smp-2.4.22-1.2199.4.legacy.nptl.i686.rpm http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/kernel-debuginfo-2.4.22-1.2199.4.legacy.nptl.i686.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFB7SEctU2XAt1OWnsRAie2AJ9Xk7qZl6pmfgm4lMiTuyQ603Br5gCdFUSo hn4Xz85qu1tw34DyxEgD9co= =Z7HR -----END PGP SIGNATURE----- ------- Additional Comments From jss.ac.uk 2005-01-19 06:15:05 ---- I notice the 2.4.20-41.7.legacy kernels appear to have a date of Sun Oct 31 09:19:11 CST 2004 (at least on the i686 kernel). Is there a problem here or was the computer clock set wrong? ------- Additional Comments From dwb7.edu 2005-01-19 06:47:06 ---- rpmlint shows the following on the srpm: W: kernel patch-not-applied Patch682: linux-2.4.20-acpi-fixes.patch W: kernel patch-not-applied Patch680: linux-2.4.20-intel-acpi-safe-update.pat W: kernel patch-not-applied Patch681: linux-2.4.20-acpi-relaxed-aml.patch W: kernel patch-not-applied Patch1280: linux-2.4.20-speakup.patch W: kernel patch-not-applied Patch611: linux-2.4.18-cpu-partitioning.patch W: kernel patch-not-applied Patch1271: linux-2.4.18-ethtool.patch W: kernel patch-not-applied Patch1270: linux-2.4.9-pcmcia-ethtool.patch W: kernel patch-not-applied Patch1110: linux-2.4.7-usb-bug50218.patch W: kernel patch-not-applied Patch5091: linux-2.4.6-bcm5820-2.patch W: kernel patch-not-applied Patch7000: linux-2.4.18-mmap-sem-debug.patch W: kernel patch-not-applied Patch750: linux-2.4.19-vmacache.patch W: kernel patch-not-applied Patch2470: linux-2.4.20-xattr-ext3.patch W: kernel patch-not-applied Patch1240: linux-2.4.17-usb-55878.patch W: kernel patch-not-applied Patch7010: linux-2.4.18-gfp-valid.patch W: kernel patch-not-applied Patch1060: linux-2.4.20-orinoco.patch W: kernel patch-not-applied Patch900: linux-2.4.20-oopsmeharder.patch W: kernel patch-not-applied Patch11002: linux-2.4.20-futex-debug.patch W: kernel patch-not-applied Patch11003: linux-2.4.20-softlockup.patch W: kernel patch-not-applied Patch1330: linux-2.4.18-scsi-whitelist.patch W: kernel patch-not-applied Patch3: linux-2.4.18-unselected-ac-bits.patch W: kernel patch-not-applied Patch2380: linux-2.4.17-watchdog-nowayout.patch W: kernel patch-not-applied Patch5094: linux-2.4.18-bcm5820-update.patch W: kernel patch-not-applied Patch5093: linux-2.4.7-bcm5820-17.patch W: kernel patch-not-applied Patch5092: linux-2.4.7-bcm5820-16.patch W: kernel patch-not-applied Patch2300: linux-2.4.9-ide-tape.patch W: kernel patch-not-applied Patch5090: linux-2.4.6-bcm5820.patch W: kernel patch-not-applied Patch2471: linux-2.4.20-xattr-mbcache.patch W: kernel patch-not-applied Patch58: linux-2.4.0-ia64-free_dma.patch W: kernel patch-not-applied Patch7001: linux-2.4.18-mmap-sem-debug-i386.patch W: kernel patch-not-applied Patch1390: linux-2.4.18-irixnfs.patch W: kernel patch-not-applied Patch670: linux-2.4.20-modulealloc.patch W: kernel patch-not-applied Patch2481: linux-2.4.20-acl-intermezzo-fix.patch W: kernel patch-not-applied Patch2480: linux-2.4.20-acl.patch W: kernel patch-not-applied Patch2485: linux-2.4.20-acl-xattr.patch W: kernel patch-not-applied Patch2487: linux-2.4.20-acl-ext3.patch W: kernel patch-not-applied Patch2488: linux-2.4.20-acl-ms-posixacl.patch W: kernel patch-not-applied Patch2320: linux-2.4.18-usb-bug50225.patch ------- Additional Comments From simon 2005-01-19 13:41:45 ---- There are a series of patches at the front end of the spec that I assume take care of those patches that have been commented out if they are still relevant to the src tree we're using: Patch1: patch-2.4.21-pre3.bz2 Patch2: linux-2.4.20-selected-ac-bits.patch Patch3: linux-2.4.18-unselected-ac-bits.patch Patch4: linux-2.4.18-noramfs.patch Patch5: linux-2.4.20-later-ac-updates.patch I have not changed any structure, I'm merely adding onto what was already there. Martin Siegert built 2.4.20-39 based on 2.4.20-37, and I've just built the 2 addition patches on top of that. In regards to the timestamp, I used a vmware virtual machine to build this, and obviously didn't check the date inside the vm. - Si ------- Additional Comments From mattdm 2005-01-19 18:28:06 ---- I'm sorry, but I'm a bit confused here. I'd like to help test RHL9 updates for this -- did any candidates for that ever get posted? I see comment #23 and comment #26, which seem to indicate "nothing yet". Is this correct? ------- Additional Comments From jp107.ac.uk 2005-01-20 08:59:20 ---- I'm currently testing packages built from kernel-2.4.20-41.7.legacy.src.rpm on 6 (soon to be 8) machines, though they are in fact RH8 based not 7.x (not that this matters much). So far no problems have turned up. ------- Additional Comments From jpdalbec 2005-01-24 04:54:57 ---- Re: comment #44 In principle you should be able to switch the version number and the NPTL switch and it should build OK. Unfortunately some of the new patches fail with NPTL. The "right" way to fix this would be to create NPTL and non-NPTL versions of the patches and select which patch to apply based on the NPTL switch. Re: RHEL AS 2.1 kernel update Do we have fixes for all these issues? Topic Updated kernel packages that fix several security issues in Red Hat Enterprise Linux 2.1 are now available. Description The Linux kernel handles the basic functions of the operating system. This advisory includes fixes for the following security issues: iSEC Security Research discovered a VMA handling flaw in the uselib(2) system call of the Linux kernel. A local user could make use of this flaw to gain elevated (root) privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1235 to this issue. iSEC Security Research discovered a flaw in the page fault handler code that could lead to local users gaining elevated (root) privileges on multiprocessor machines. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0001 to this issue. iSEC Security Research and Georgi Guninski independently discovered a flaw in the scm_send function in the auxiliary message layer. A local user could create a carefully crafted auxiliary message which could cause a denial of service (system hang). The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1016 to this issue. Kirill Korotaev found a flaw in load_elf_binary affecting kernels prior to 2.4.26. A local user could create a carefully crafted binary in such a way that it would cause a denial of service (system crash). The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1234 to this issue. These packages also fix issues in the io_edgeport driver (CAN-2004-1017), a memory leak in ip_options_get (CAN-2004-1335), and missing VM_IO flags in some drivers (CAN-2004-1057). A recent Internet Draft by Fernando Gont recommended that ICMP Source Quench messages be ignored by hosts. A patch to ignore these messages is included. ------- Additional Comments From dwb7.edu 2005-01-25 07:18:37 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rebuilt the kernel srpm on rh7.3. Built and installed ok. Have been running for a few days, and have not yet noticed any problems. The output of rpmlint has already been included in earlier comments. sha1sum: 0527f6144ea94f75e8224ff4e77176ef2be19fea *kernel-2.4.20-41.7.legacy.src.rpm +PUBLISH - -DWB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB9n8ZSY7s7uPf/IURAjUkAKCE8UGKEuuRjdh96VaH12Y9waea4wCcDG8c w2ioKxLhxfp1GdHEum5tRBc= =FiH4 -----END PGP SIGNATURE----- ------- Additional Comments From jss.ac.uk 2005-01-26 04:39:17 ---- I believe there's a problem with the 7.3 kernels. With the last fedora legacy kernel my UPS works, with the new one it doesn't: kernel-2.4.20-41.7.legacy Jan 26 13:34:10 xserv2 newapc: Serial port read timed out Jan 26 13:34:30 xserv2 newapc: Network UPS Tools (version 0.45.4) - APC Smart protocol driver Jan 26 13:34:30 xserv2 newapc: ^IDriver $Revision: 1.1.2.27 $, command table $Revision: 1.1.2.13 $ Jan 26 13:34:30 xserv2 newapc: Unable to detect an APC Smart protocol UPS on port /dev/ttyS0 Jan 26 13:34:30 xserv2 newapc: Check the cabling, port name or model name and try again I rebooted several times and this isn't a one off. This occurs on two separate computers. ------- Additional Comments From dwb7.edu 2005-01-26 04:59:08 ---- And rebooting to the previous kernel, it works fine? Did your UPS use a kernel module to do some of what it did? Or some other module? Or is /dev/ttyS0 support now just broken? Perhaps the UPS software just needs to be reinstalled? ------- Additional Comments From jss.ac.uk 2005-01-26 05:22:32 ---- It works fine just rebooting the previous kernel. With the working kernel the following modules are loaded (with the UPS working and running): xserv2:~> /sbin/lsmod Module Size Used by Not tainted nfs 75644 2 (autoclean) lp 8544 0 (autoclean) parport 34112 0 (autoclean) [lp] autofs 11844 4 (autoclean) nfsd 76736 8 (autoclean) lockd 57088 1 (autoclean) [nfs nfsd] sunrpc 76916 1 (autoclean) [nfs nfsd lockd] eepro100 21068 1 mii 3976 0 [eepro100] ipt_state 1344 1 (autoclean) ip_conntrack 26228 1 (autoclean) [ipt_state] iptable_filter 2560 1 (autoclean) ip_tables 13952 2 [ipt_state iptable_filter] ide-cd 32256 0 (autoclean) cdrom 32128 0 (autoclean) [ide-cd] ext3 65952 2 jbd 47564 2 [ext3] raid1 14404 3 I don't see any module there for serial connections, so I assume it is statically loaded. I'm not convinced reinstalling the UPS software will help, as there's no problem under any previous kernel. It looks like there's something wrong with serial support with this new kernel. Does anyone else have serial devices? xserv2:~> cat /proc/interrupts CPU0 0: 578446 XT-PIC timer 1: 216 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 2634422 XT-PIC eth0 4: 51976 XT-PIC serial 8: 1 XT-PIC rtc 9: 654401 XT-PIC ide2, ide3 10: 26300 XT-PIC ide4 14: 646122 XT-PIC ide0 15: 20 XT-PIC ide1 NMI: 0 ERR: 0 Working kernel: Jan 26 13:41:39 xserv2 kernel: Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled Jan 26 13:41:39 xserv2 kernel: ttyS0 at 0x03f8 (irq = 4) is a 16550A Not working kernel: Jan 26 13:38:22 xserv2 kernel: Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled Jan 26 13:38:22 xserv2 kernel: ttyS0 at 0x03f8 (irq = 4) is a 16550A Looks very similar. ------- Additional Comments From dwb7.edu 2005-01-26 15:27:34 ---- I connected my palm up to my 7.3 box using the serial sync cable. It worked just fine. I suppose that it is possible that pilot-xfer uses some alternate method to talk to the serial port... Does the kernel message log show anything useful or interesting? Does /proc/interrupts on the serial port increase after trying to talk to the ups? Is there some client utility program that you can run and/or strace to try and talk to the ups? Are the serial port settings the same under both kernels? Save that, I'm tempted to say that some in kernel call that is made no longer works, assuming it is kernel related at all. Perhaps some interaction with some other lib that no longer works. If there is code to compile, would still be interested to know if a fresh compile/install works, or if some other OSS software can see the UPS. ------- Additional Comments From jpdalbec 2005-02-01 08:02:29 ---- Created an attachment (id=980) gpg signed patch to spec file and NPTL version of CAN-2004-0814 To build an RHL 9 kernel, copy linux-2.4.20-CAN-2004-0814-tty.patch to linux-2.4.20-CAN-2004-0814-tty-nptl.patch and apply this patch to kernel-2.4.spec and linux-2.4.20-CAN-2004-0814-tty-nptl.patch. I'll try to upload RPMs soon. ------- Additional Comments From jpdalbec 2005-02-02 04:23:29 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New RHL 9 RPMs are available from http://www.fedoralegacy.org/contrib/kernel/ sha1sums: be12b85051e17d1acda4b46502eecbf7aba438f7 kernel-2.4.20-41.9.legacy.i386.rpm 8ebc1eb4eb0a91a5e4e02d2a7e82815d85b57fb6 kernel-2.4.20-41.9.legacy.i686.rpm 2ee7540c1c20612e935b0f92c59a7886ec6b998f kernel-2.4.20-41.9.legacy.src.rpm 3381b0507fc0910509050516e4325ef131895a44 kernel-bigmem-2.4.20-41.9.legacy.i686.rpm 4cb42d65b37d998c8fe3708f8a335363fa06301a kernel-BOOT-2.4.20-41.9.legacy.i386.rpm 5e57898a4e820339e32dabeff86276a0d0554893 kernel-doc-2.4.20-41.9.legacy.i386.rpm 7f35af62aacaa5608a374c0b3510b87aa5126062 kernel-smp-2.4.20-41.9.legacy.i686.rpm 6fe23e7559701b6f4da8ee2a45e6da6790e0209f kernel-source-2.4.20-41.9.legacy.i386.rpm I installed kernel-bigmem and kernel-source on a VMware box. No obvious problems. I didn't try building for i586. See my earlier attachment for .spec file changes and the differences between the original and NPTL versions of the CAN-2004-0814 patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCANRyJL4A+ldA7asRAg2CAKCHXevjR9q/jmeoo+n08jj6E9XU1QCdEWXw Kw0UNGrzrEYp1DjYxn2V9Bw= =/dRN -----END PGP SIGNATURE----- ------- Additional Comments From siegert 2005-02-02 08:37:30 ---- Created an attachment (id=983) new version of tty_ldisc-CAN-2004-0814 patch -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With respect to Comment #48: the CAN-2004-0814 patch changes a lot of the code that deals with serial connections. I found that that patch misses the definition of proc_mkdir_mode in proc_fs.h. Rather than trying to fix the patch I have extracted a newer version of the patch from patch-2.4.29-pre2-pre3. That patch (linux-2.4.29-tty_ldisc-CAN-2004-0814.patch) is attached. I cannot tell whether it fixes the problem though. I'll build new kernels for 7.3 sometime today. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFCARyNBJ3vItFhAFcRAoHOAJ9TuSCg+k3GS2vaNLGLw0Z7Ezw3LACdF16J DqvBAnFPs8mCjLl+lmoxfgI= =hkgl -----END PGP SIGNATURE----- ------- Additional Comments From siegert 2005-02-03 10:28:31 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 kernel packages for 7.3 with the changed CAN-2004-0814 patch are available from ftp://ftp.sfu.ca/pub/linux/fedoralegacy/ %changelog * Wed Feb 2 2005 Martin Siegert <siegert> - - replace patch for CAN-2004-0814 with patch extracted from the official kernel patch-2.4.29 (including previously missing patch for proc_fs.h). # sha1sum kernel*2.4.20-42.7.legacy*.rpm 7cf1ce1a38f8180dbc9bd4eb654ad309fe1ec44b kernel-2.4.20-42.7.legacy.athlon.rpm 506b30c8af1af25847070d9269e3002e2968f9fa kernel-2.4.20-42.7.legacy.i386.rpm 0e9a002c8aa136f795f6cb9951dd4095402d58a4 kernel-2.4.20-42.7.legacy.i586.rpm dcbea8072211d8c4b0eff9d77c21630bd3ab25b7 kernel-2.4.20-42.7.legacy.i686.rpm b7296e6c9b926bf15880e2ab2edf497cdc29d31d kernel-2.4.20-42.7.legacy.src.rpm 745b995b8b412e5d5388104789b8c86639738bb3 kernel-bigmem-2.4.20-42.7.legacy.i686.rpm 51f588e71f9c02bb28a530f5cc2fb58e748ecd31 kernel-BOOT-2.4.20-42.7.legacy.i386.rpm c93f8ef9ec5a3130720357b6baee5aab475e4b69 kernel-doc-2.4.20-42.7.legacy.i386.rpm ca34312141e61a73dff4e96e887974dfa79fbfb1 kernel-smp-2.4.20-42.7.legacy.athlon.rpm 73b9e2feb3c47cb7982506b21c8407f476a3e57f kernel-smp-2.4.20-42.7.legacy.i586.rpm 822e57ebb030bf4be8143102bc247b7dcaa1ffa1 kernel-smp-2.4.20-42.7.legacy.i686.rpm 1d7ae00189c3223978625031c616db689cf29cee kernel-source-2.4.20-42.7.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFCAoi4BJ3vItFhAFcRAg85AJ4w40/E3s/7QuCR7EEapvW4TBB+0ACeN9fF Nk5uzlyLxpa+hhvY/hEULa8= =dc9R -----END PGP SIGNATURE----- ------- Additional Comments From jss.ac.uk 2005-02-03 23:50:45 ---- Yes - kernel-2.4.20-42.7.legacy.i686.rpm fixed the ups problems for me. Great! ------- Additional Comments From jpdalbec 2005-02-04 10:08:58 ---- It looks like one problem in -41.7 was this runaway comment: + + /* Defer ldisc switch */ + /* tty_deferred_ldisc_switch(N_TTY); + The new patch in -42.7 restores two missing lines including the "*/". + + /* Defer ldisc switch */ + /* tty_deferred_ldisc_switch(N_TTY) + This should get done automatically when the port closes and + tty_release is called */ + ------- Additional Comments From dwb7.edu 2005-02-04 19:28:20 ---- Do we need new patches for rh9 and fc1 so that the serial port won't break under those oses as it did under rh7.3? ------- Additional Comments From rob.myers.edu 2005-02-05 07:20:07 ---- re comment #58: this is not a problem for the fc1 kernel. i have not reviewed the rh9 patch. feel free to review the fc1 patch: http://www.stl.gtri.gatech.edu/viewcvs/*checkout*/FC-1-legacy/kernel/linux-2.4.28-tty-CAN-2004-0814.patch?rev=1.1&sortby=date ------- Additional Comments From jpdalbec 2005-02-07 05:48:01 ---- I'm working on building new RHL 9 kernels. ------- Additional Comments From dwb7.edu 2005-02-08 16:44:33 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rebuilt the newly fixed kernel srpm on rh7.3. Built and installed ok. It's running w/o a problem, so far, altho, I have not specifically tested out the serial port, as of yet. sha1sum: sha1sum -b kernel-2.4.20-42.7.legacy.src.rpm b7296e6c9b926bf15880e2ab2edf497cdc29d31d *kernel-2.4.20-42.7.legacy.src.rpm +PUBLISH - -DWB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCCXjOSY7s7uPf/IURAtp6AKDKbPuo6JJ1uwMS5ECDgWTk46c4kgCgvRo2 FuxuF3rXA4ZTOIGdqTYAwIM= =nezA -----END PGP SIGNATURE----- ------- Additional Comments From jpdalbec 2005-02-09 12:03:24 ---- b7296e6c9b926bf15880e2ab2edf497cdc29d31d kernel-2.4.20-42.7.legacy.src.rpm does not appear to be signed. rpm --checksig reports: kernel-2.4.20-42.7.legacy.src.rpm: sha1 md5 OK However, comment #55 is signed and contains the package sha1sum. Is this a problem? ------- Additional Comments From jpdalbec 2005-02-09 12:37:07 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New RHL 9 packages are available from http://www.fedoralegacy.org/contrib/kernel/ based on the RHL 7.3 package b7296e6c9b926bf15880e2ab2edf497cdc29d31d kernel-2.4.20-42.7.legacy.src.rpm sha1sums: 99878e8e71ac46aa6345f7729adaa8f642b7d11f kernel-2.4.20-42.9.legacy.i386.rpm 63d2666aa5f1cb0bc8bec12181965cd6c311b1cc kernel-2.4.20-42.9.legacy.i586.rpm 7390bd07ac8a13e70d283bfff62957c22a6dedf9 kernel-2.4.20-42.9.legacy.i686.rpm 04a0474ab3be52ce939139dd01b14863153902ba kernel-2.4.20-42.9.legacy.src.rpm 30693d1c90238a50632edfe241a2064b25def3e3 kernel-bigmem-2.4.20-42.9.legacy.i686.rpm 21647e8a055703a3fb27af8b10bae5077dbbcdfa kernel-BOOT-2.4.20-42.9.legacy.i386.rpm 3d09b3b824b808eb28e6a38f17f46253d992a946 kernel-doc-2.4.20-42.9.legacy.i386.rpm e4d4ff7b658f3efdaf5d2199c37aac385b1036db kernel-smp-2.4.20-42.9.legacy.i586.rpm cc914417ab980a7602ecc253a2ce7342871d2c66 kernel-smp-2.4.20-42.9.legacy.i686.rpm 504a5a15b1bc9dc4dc0b0cdd4bab432997e0d884 kernel-source-2.4.20-42.9.legacy.i386.rpm The VMware virtual machine I'm typing this on is running kernel-bigmem. I installed kernel-source and used it to build the VMware vmhgfs kernel module. Changelog entry I should have added but forgot to: * Wed Feb 9 2005 John Dalbec <jpdalbec> - - add NPTL version of CAN-2004-0814 patch, rebuild for RHL 9 If people really want me to add that to the changelog, I'll rebuild the packages, but it'll take a while. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCCosFJL4A+ldA7asRAvifAKDICsgEfqfGrJGFCNCf1jNUYM+/uwCg1DEU Y/4Y/scrqstEesvjHew7UBA= =xgKr -----END PGP SIGNATURE----- ------- Additional Comments From pekkas 2005-02-18 04:32:47 ---- I suggest that we stop adding new fixes, unless a remote hole or something equally serious is found, in order to get at least _one_ kernel update out in a reasonable time. When I look at this, it seems that: - RHL9 RPMs are waiting for a PUBLISH - RHL73 RPMs are probably also waiting for PUBLISHes (not sure?) - do FC1 RPMs require revising? ------- Additional Comments From marcdeslauriers 2005-02-18 14:49:57 ---- There seems to be a problem with one of the patches in the FC1 kernel from comment #40: linux-2.4-smbfs-CAN-2004-0883-CAN-2004-0949.patch This section is ok: --- a/fs/smbfs/proc.c 2005-01-07 04:34:15 -08:00 +++ b/fs/smbfs/proc.c 2005-01-07 04:34:15 -08:00 @@ -1289,9 +1289,11 @@ data_len = WVAL(buf, 1); /* we can NOT simply trust the data_len given by the server ... */ - if (data_len > server->packet_size - (buf+3 - server->packet)) { + if (data_len > count || + data_len > server->packet_size - (buf+3 - server->packet)) { printk(KERN_ERR "smb_proc_read: invalid data length!! " - "%d > %d - (%p - %p)\n", + "%d > %d || %d > %d - (%p - %p)\n", + data_len, count, data_len, server->packet_size, buf+3, server->packet); result = -EIO; goto out; but then this section breaks it instead of patching similar code later in the file: --- a/fs/smbfs/proc.c 2005-01-07 04:35:12 -08:00 +++ b/fs/smbfs/proc.c 2005-01-07 04:35:12 -08:00 @@ -1290,11 +1290,11 @@ /* we can NOT simply trust the data_len given by the server ... */ if (data_len > count || - data_len > server->packet_size - (buf+3 - server->packet)) { - printk(KERN_ERR "smb_proc_read: invalid data length!! " - "%d > %d || %d > %d - (%p - %p)\n", + (buf+3 - server->packet) + data_len > server->packet_size) { + printk(KERN_ERR "smb_proc_read: invalid data length/offset!! " + "%d > %d || (%p - %p) + %d > %d\n", data_len, count, - data_len, server->packet_size, buf+3, server->packet); + buf+3, server->packet, data_len, server->packet_size); result = -EIO; goto out; } Take a look at the original patch: http://linux.bkbits.net:8080/linux-2.4/gnupatch@418e1b09MoAGAjd5ZLQzkiFiOkEfUw ------- Additional Comments From marcdeslauriers 2005-02-18 14:51:26 ---- Could the 7.x and 9 rpms be missing CAN-2004-0177 and CAN-2004-0685? Or do they not apply? ------- Additional Comments From siegert 2005-02-18 16:08:31 ---- Re Comment #66: The patch for CAN-2004-0177 is included in linux-2.4.25pre-selected-bits.patch (Patch950, last part). The patch for CAN-2004-0685 according to the changelog is Patch2590: linux-usb-sparse.patch. ------- Additional Comments From pekkas 2005-02-18 21:15:42 ---- With regard to #64, in a later changeset (from http://www.stl.gtri.gatech.edu/viewcvs/FC-1-legacy/kernel/linux-2.4-smbfs-CAN-2004-0883-CAN-2004-0949.patch?rev=1.1&view=markup): # ChangeSet # 2004/11/12 12:32:51-02:00 s.esser # [PATCH] Improved smbfs client overflow fix # # the patches in v2.4.28-rc2 are incomplete. They do not fix # any of the possible leaks. .. so it looks as if the first changeset did not fix the problem correctly. I didn't analyze this in depth though. ------- Additional Comments From marcdeslauriers 2005-02-19 03:27:11 ---- Oups! Yes, you're right. The patch is correct. It looked odd, but I understand now why by looking at the second patch. Please diregard my comment #65, the patch is OK. ------- Additional Comments From marcdeslauriers 2005-02-19 03:30:04 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did QA on the FC1 kernel from comment #40: 3d4728c390620f532a55ece51a66ac7130da36b9 kernel-2.4.22-1.2199.4.legacy.nptl.src.rpm - - Source files match previous release - - Patch files look good and match upstream and elsewhere - - Spec file changes are good - - Patch files fix all of the CAN numbers I have. +PUBLISH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCFz+3LMAs/0C4zNoRAshoAJ9qMqVbj88H/ixbE2JnGp2QwdaMZACdHvEo UQUoSc9cu5d6Vsu6BYY3kkM= =v0aN -----END PGP SIGNATURE----- ------- Additional Comments From marcdeslauriers 2005-02-19 04:32:34 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did QA on the rh73 kernel from comment #55: b7296e6c9b926bf15880e2ab2edf497cdc29d31d kernel-2.4.20-42.7.legacy.src.rpm - - Source files match previous release - - Patch files look good and match upstream and elsewhere - - Spec file changes are good - - Patch files fix all of the CAN numbers I have. Would have liked the patch from bug #2205 included, but it can wait for the next time. +PUBLISH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCF05aLMAs/0C4zNoRAq87AJ9Acv4//HS0VmL3HijkkOyRwwwHhwCgh2H0 oyq08iB1FSZgjGGnk9gkO8g= =z9fE -----END PGP SIGNATURE----- ------- Additional Comments From marcdeslauriers 2005-02-19 04:39:54 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did QA on the rh9 kernel from comment #63: 04a0474ab3be52ce939139dd01b14863153902ba kernel-2.4.20-42.9.legacy.src.rpm - - Source files match rh73 kernel kernel-2.4.20-42.7.legacy.src.rpm - - NPTL patch looks good - - Spec file changes are good Would have liked the patch from bug #2205 included, but it can wait for the next time. +PUBLISH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCF1ARLMAs/0C4zNoRAiRrAJ9NxfasmixmgkxSYqttouj4An6XkwCfWyXI F0ywv5Xa6tNVuGnIVYsQVNQ= =sftO -----END PGP SIGNATURE----- ------- Additional Comments From marcdeslauriers 2005-02-19 04:40:56 ---- We now have packages ready to be built for updates-testing for rh73, rh9 and fc1. If any new bugs appear for the kernel, please open a new bug instead of adding to this one. ------- Additional Comments From marcdeslauriers 2005-02-20 17:15:56 ---- packages were pushed to updates-testing ------- Additional Comments From mgerber 2005-02-21 17:45:52 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * sha1sum and gpg sig ok * package installs fine * boots fine and survives my beating * couldn't exploit CAN-2004-1235 * CAN-2004-1137 is untested as I'm not even getting far exploiting the older kernels * CAN-2005-0001 is untested: no SMP machine handy * fixes kernel crash with CAN-2004-1074 tested a.out binary: perl -e'print"\x07\x01".("\x00"x13)."\xc0".("\x00"x16)'>eout that crashed my old kernels if I have vm.overcommit_memory=1 and binfmt_aout loaded. I vote to VERIFY RHL73 dad7ced597c96a258e11d0de8437356ac82e40f3 kernel-2.4.20-42.7.legacy.i386.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCGqoKMNEywxI1brERAvQoAJ97qrG0FZTp0IErBv4wYoAzzC2JkgCfQD95 l7zHnLjOH6ej8dunrTAJse+IPwMFAUIaqgoKOzD6Y3lq+REC9CgAn1RJ66PHuD+C BGipTq3OfImpe2DrAJ41J7sTb5VzrsgmRdDoHbcb5+mXZg== =CMHY -----END PGP SIGNATURE----- ------- Additional Comments From pekkas 2005-02-21 23:58:18 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for RHL9: - GPG signatures OK - installs nicely - booted nicely and there hasn't been any issues (I haven't done extensive vulnerability tests, etc.) +VERIFY RHL9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFCGwIWGHbTkzxSL7QRAggsAJ0XBxyV50/0ScprbbFy2gE0A3VxgACgz8oF pBnvn2tge76Pe4Qh4aWvs2s= =0nc/ -----END PGP SIGNATURE----- ------- Additional Comments From rob.myers.edu 2005-02-23 03:55:28 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 GPG signatures ok for these FC1 kernel packages: 5b093d72e5f7398f3b829c6ce557eb9817042732 kernel-2.4.22-1.2199.4.legacy.nptl.i686.rpm 4c5895f14271a8b5bc6e5489c053fba1f96e71f8 kernel-doc-2.4.22-1.2199.4.legacy.nptl.i386.rpm d307317b04336c289cddde005e11c30b188119cb kernel-smp-2.4.22-1.2199.4.legacy.nptl.i686.rpm 3b0301c812ad4379c6eb7bbd7970ab4f9602b37c kernel-source-2.4.22-1.2199.4.legacy.nptl.i386.rpm installs ok works ok +VERIFY FC1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCHIsctU2XAt1OWnsRAjLQAKCA69+rI0Lq0xqVB4Lj1QGanV4c3ACdEbnx oUQMBB/gIiWza/RY/aLhAnI= =eFWD -----END PGP SIGNATURE----- ------- Additional Comments From rmy.uk 2005-02-24 01:35:28 ---- -----BEGIN PGP SIGNED MESSAGE----- I've installed these kernels on a couple of rh73 systems: kernel-2.4.20-42.7.legacy.i686.rpm kernel-smp-2.4.20-42.7.legacy.i686.rpm SHA1 checksums and GPG signatures are OK. Both installed without any problems and have been running our usual workloads just fine (Oracle, user-mode Linux). +VERIFY rh73 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iQCVAwUBQh27jB2/joqPEUdFAQF4HAP7Bt356IAGCYSmD861oxf/lG9O/uwttEOP +JHUj8VSiSUpmk3MCv8EYEVlWn8OX9nWe39byxhgtUL9fK36d7ZI6Lw5UxyFqfBG O1jm5/9jr7qPUrPx5aOq9UpYRkDbww1klUNCX1DC7IqqOVypkVLX0sABF4zefUL2 1Hx2npZWoj0= =INl9 -----END PGP SIGNATURE----- ------- Additional Comments From marcdeslauriers 2005-02-24 17:40:32 ---- Packages were released to official updates. ------- Bug moved to this database by dkl 2005-03-30 18:30 ------- This bug previously known as bug 2336 at https://bugzilla.fedora.us/ https://bugzilla.fedora.us/show_bug.cgi?id=2336 Originally filed under the Fedora Legacy product and Package request component. Attachments: tar file with kernel patches https://bugzilla.fedora.us/attachment.cgi?action=view&id=961 alternative CAN-2004-1235 patch https://bugzilla.fedora.us/attachment.cgi?action=view&id=965 2.4.29-rc1 to rc2 expand_stack patch (CAN-2005-0001) https://bugzilla.fedora.us/attachment.cgi?action=view&id=967 gpg signed patch to spec file and NPTL version of CAN-2004-0814 https://bugzilla.fedora.us/attachment.cgi?action=view&id=980 new version of tty_ldisc-CAN-2004-0814 patch https://bugzilla.fedora.us/attachment.cgi?action=view&id=983 Unknown priority P2. Setting to default priority "normal". Unknown platform PC. Setting to default platform "All". The original reporter of this bug does not have an account here. Reassigning to the person who moved it here, dkl. Previous reporter was bugzilla.fedora.us. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.