At least CAN-2005-0750 from this Fedora update https://www.redhat.com/archives/fedora-announce-list/2005-March/msg00075.html affects us -- linux >= 2.4.6 <= 2.4.30-rc1. And I assume the ISO issues do as well.
From the FC2 advisory: CAN-2005-0210 affects only 2.6 kernels; not rh9/fc1. CAN-2005-0384 seems to affect us as well -- see RHEL bug #151240 CAN-2005-0531 advisory didn't test 2.4, but debian says it applies to 2.4.27. not sure if our 2.4.20 is affected. No RHEL update seems available. CAN-2005-0400 affects us, but doesn't seem to severe -- apparently you need to be superuser to see the exposed info. RHEL bug #152400 CAN-2005-0449 firewall bypass, remote oops, affects 2.4 -- RHEL bug #151805 CAN-2005-0736 is 2.6 only. CAN-2005-0749 is a local kernel crash -- affects 2.4 -- RHEL bug #152411 CAN-2005-0750 local root exploit, affects 2.4, RHEL bug #152178 (test kernels with patch available at that bug) CAN-2005-0767 I think this is 2.6 only. CAN-2005-0815 corrupt iso images cause oops -- could be bad for lab machines. This affects us, and is RHEL bug #152406
RHEL advisory is out: https://rhn.redhat.com/errata/RHSA-2005-293.html Need to review what's covered there vs what's mentioned above....
Created attachment 113619 [details] a patch which makes kernel-2.4.21-27.0.4.EL.src.rpm compilable on rh7.3 I tried to recompile "as is" on an RH7.3 system sources referenced in RHSA-2005-293. This did not work right away. In various places there are asignments which precede declarations and a double initialization in a structure. Also '__attribute__((always_inline))' in brlock.h is causing a constant stream of warnings that a compiler is going to ignore that. In a definition of 'kernel_prereq' we have 'modutils >= 2.4.18' but later this 'BuildPreReq' wants a higher version which is not available. After changing that in spec to 2.4.18 and applying an attached patch is is possible to recompile that kernel on an 7.3 installation and results do boot and run. 'rpm' wants some newer versions in user space (SysVinit >= 2.84-13, pam >= 0.75-48, vixie-cron >= 3.0.1-73) and at least for vixie-cron this looks like a valid request. OTOH my system is operational with this kernel even with these dependencies not satisfied. I tried only one compilation target (--target=athlon).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are new kernel packages to QA for rh7.3: * Mon Apr 25 2005 Marc Deslauriers <marcdeslauriers> 2.4.20-43.7.legacy - - Added patch for CAN-2004-1058 proc_pid_cmdline race based on part of the linux-2.4.18-smallpatches.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2004-1333 vtresize based on vtresize from kernel-source-2.4.20.SuSE-133.src.rpm - - Added patch for CAN-2005-0384 based on linux-2.4.21-netfixes.patch in kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0400 (ext2 mkdir leak) from bitkeeper (see patch header) - - Added patch for CAN-2005-0449 (ipfrag flush) from rediffed linux-2.4.21-ipfrag-flush.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0504 moxy CAP_SYS_RAWIO from Bitkeeper (see patch header) - - Added patch for CAN-2005-0749 load_elf_library DoS based on linux-2.4.21-binfmt-elf.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0750 bluetooth security issue based on linux-2.4.21-netfixes.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0815 (isofs range checking flaw) from bitkeeper (see patch header) f4bbf06b67aa55f20f77f4b11b281935c982b589 kernel-2.4.20-43.7.legacy.athlon.rpm c1b02cb874c6b15a4d84248dcef09599ae09ee78 kernel-2.4.20-43.7.legacy.i386.rpm 470022e3bc78ad40a4d450bdca3a3a418917068a kernel-2.4.20-43.7.legacy.i586.rpm 1a9c6983ccae51d17462ae853f0389654bb5598e kernel-2.4.20-43.7.legacy.i686.rpm b79fd5c695d2da1e2da35385424379aac0776c05 kernel-2.4.20-43.7.legacy.src.rpm 5a8b8a8b6c35ae9492ef504c091feab83f076130 kernel-bigmem-2.4.20-43.7.legacy.i686.rpm ffd727d19874d03b48c3865404af311db5f311d9 kernel-BOOT-2.4.20-43.7.legacy.i386.rpm d8b0df04d1261883e24e5d92caf413ae33991bab kernel-doc-2.4.20-43.7.legacy.i386.rpm 5cfbe265c381329a93b0cce8db7c44b46e7a756b kernel-smp-2.4.20-43.7.legacy.athlon.rpm 55d61ae0ab700d276fab247d958b5e285c7c08de kernel-smp-2.4.20-43.7.legacy.i586.rpm ae3f46f385291a867e8163eee60b9b038c481195 kernel-smp-2.4.20-43.7.legacy.i686.rpm 7dcee6685ca4db9002a7953c212340a8bd2fc007 kernel-source-2.4.20-43.7.legacy.i386.rpm Source package: http://www.infostrategique.com/linuxrpms/legacy/7.3/kernel-2.4.20-43.7.legacy.src.rpm Binaries: http://www.infostrategique.com/linuxrpms/legacy/7.3/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbsq0LMAs/0C4zNoRAkoSAJ9JMvYDNV5Xb8iWci/84iWH1WX9gwCeOnBg vWQnTvIY48xYdZzP+KD4q0U= =y3bB -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are new kernel packages for rh9 to QA: * Mon Apr 25 2005 Marc Deslauriers <marcdeslauriers> 2.4.20-43.7.legacy - - Added patch for CAN-2004-1058 proc_pid_cmdline race based on part of the linux-2.4.18-smallpatches.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2004-1333 vtresize based on vtresize from kernel-source-2.4.20.SuSE-133.src.rpm - - Added patch for CAN-2005-0384 based on linux-2.4.21-netfixes.patch in kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0400 (ext2 mkdir leak) from bitkeeper (see patch header) - - Added patch for CAN-2005-0449 (ipfrag flush) from rediffed linux-2.4.21-ipfrag-flush.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0504 moxy CAP_SYS_RAWIO from Bitkeeper (see patch header) - - Added patch for CAN-2005-0749 load_elf_library DoS based on linux-2.4.21-binfmt-elf.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0750 bluetooth security issue based on linux-2.4.21-netfixes.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0815 (isofs range checking flaw) from bitkeeper (see patch header) 02a2824d9cbd96ab5b562923de39b2b8d7145657 kernel-2.4.20-43.9.legacy.athlon.rpm a7a60d4c31337d68f871306e25afe281e5fb914b kernel-2.4.20-43.9.legacy.i386.rpm 83a8ea427ef0d07573e9500966c4a10d1c98f611 kernel-2.4.20-43.9.legacy.i586.rpm 25cb880b113c289adaa34b2d0934fa905f23b3e2 kernel-2.4.20-43.9.legacy.i686.rpm 879acf8cb2c2af126c5c514fe6b8a406d7b33e3d kernel-2.4.20-43.9.legacy.src.rpm 71d01b73a2355db95f5861a38427ac7c64edb54c kernel-bigmem-2.4.20-43.9.legacy.i686.rpm 3e059aee85019700f0d1e29f56afe3b27635244d kernel-BOOT-2.4.20-43.9.legacy.i386.rpm 8eb67f3eb3a22723b884fe59956ca31d304c17fd kernel-doc-2.4.20-43.9.legacy.i386.rpm 24d406286fbd2c0fc1571010015e47f5c6a3d297 kernel-smp-2.4.20-43.9.legacy.athlon.rpm 4bcad7363ddc0bc819b31fa89470c71f4d2c53e1 kernel-smp-2.4.20-43.9.legacy.i586.rpm 2c36b58457c678d523b9d3c06db84bd7a565b8da kernel-smp-2.4.20-43.9.legacy.i686.rpm 0b6721ef6a83378c9917137e226b267ef22ea15b kernel-source-2.4.20-43.9.legacy.i386.rpm Source package: http://www.infostrategique.com/linuxrpms/legacy/9/kernel-2.4.20-43.9.legacy.src.rpm Binary packages: http://www.infostrategique.com/linuxrpms/legacy/9/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbsyZLMAs/0C4zNoRAvFOAKCHdKstG7Rq/auZDI5sDwv3LX8YdQCZAW9d NNLV16nIxBVxsTLdOf9fhLI= =TT7k -----END PGP SIGNATURE-----
Thanks Marc. Would it annoy you if I cloned the rh7.3 part off as a separate bug? (And FC1 too.)
I wouldn't annoy me if we worked with a cvs repository...but since we don't (yet), I'd much rather track everything in the same bug. But, if you think it would be better, go ahead.
By the way, for people doing QA on the rh7.3 and rhl9 kernel source packages: they are identical apart from a build flag at the beginning of the spec file, so QA done on one of them is good for the other.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are updated kernel packages to QA for FC1: * Tue Apr 26 2005 Marc Deslauriers <marcdeslauriers> 2.4.22-1.2199.5.legacy.nptl - - Added patch for CAN-2004-1058 proc_pid_cmdline race based on part of the linux-2.4.18-smallpatches.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2004-1333 vtresize based on vtresize from kernel-source-2.4.20.SuSE-133.src.rpm - - Added patch for CAN-2005-0384 based on linux-2.4.21-netfixes.patch in kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0400 (ext2 mkdir leak) from bitkeeper (see patch header) - - Added patch for CAN-2005-0449 (ipfrag flush) from rediffed linux-2.4.21-ipfrag-flush.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0749 load_elf_library DoS based on linux-2.4.21-binfmt-elf.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0750 bluetooth security issue based on linux-2.4.21-netfixes.patch from kernel-2.4.21-27.0.4.EL.src.rpm - - Added patch for CAN-2005-0815 (isofs range checking flaw) from bitkeeper (see patch header) a2be308711ad540802a01df3462118ee93d383ad kernel-2.4.22-1.2199.5.legacy.nptl.athlon.rpm 799a71f887012561427fee0e13d68eb793ad88d6 kernel-2.4.22-1.2199.5.legacy.nptl.i586.rpm 8ee3e199e85228a8dd33db66dfbe2093312e3ff0 kernel-2.4.22-1.2199.5.legacy.nptl.i686.rpm 9ee2ca2ee92a05679e8cb3e38fc2dd9004b6e3c7 kernel-2.4.22-1.2199.5.legacy.nptl.src.rpm 56390f0cbcfe6024c3ff8c023f29b855aac036a6 kernel-smp-2.4.22-1.2199.5.legacy.nptl.athlon.rpm 26d86fcc3d9d7a18450ca76959da2d149053937f kernel-smp-2.4.22-1.2199.5.legacy.nptl.i586.rpm 0894929814034924e278172454505acbda5aa693 kernel-smp-2.4.22-1.2199.5.legacy.nptl.i686.rpm Source package: http://www.infostrategique.com/linuxrpms/legacy/1/kernel-2.4.22-1.2199.5.legacy.nptl.src.rpm Select binaries: http://www.infostrategique.com/linuxrpms/legacy/1/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCb5YNLMAs/0C4zNoRApAzAJ4p3MKupRlFIPYg6K/irvE3hg9TCgCeIj5I 0dyvpZ+GVW64PtRw9ydBYN4= =6JoF -----END PGP SIGNATURE-----
Thanks Marc -- will look at the RHL9 packages today. Given your comments on the mailing list, I'm going to leave this one as one bug and change the version to 'unspecified'.
Just a quick preliminary note -- the changelog appears to include all vulnerabilities listed in my commment #1 (except CAN-2005-0531, which as I note above is probably 2.6 only). The additional vulnerabilites addreessed in https://rhn.redhat.com/errata/RHSA-2005-293.html are either 2.6 only or Itanium-specific, with one x86_64 (CAN-2005-0204). That leaves CAN-2005-0403, which is bug #144059 and appears to basically fix a crash -- not sure of the security implications, though. Also, did you mean "2.4.20-43.7.legacy" in the RHL9 package changelog?
CAN-2005-0531 is indeed 2.6 only. CAN-2005-0403 is a crash specific to the Red Hat nptl backport. I looked at it a bit, but am not sure if we're vulnerable to it or not as the nptl backport in the rh9 kernel is a little different. Since it appeared to be a local DoS issue and I don't seem to find similar crash reports with the rh9 kernel, I didn't spend much time with it. Since the rhl7.3 and rhl9 packages are identical besides the nptl switch at top, I didn't bother to change the release number in the changelog...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i did QA on marc's fc1 kernel package: 9ee2ca2ee92a05679e8cb3e38fc2dd9004b6e3c7 kernel-2.4.22-1.2199.5.legacy.nptl.src.rpm sha1sum matches spec file looks good origin of patches verified rebuilds ok installs ok boots and seems to run ok +PUBLISH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCb92mtU2XAt1OWnsRAvijAJ46+XMBlW85e4N3v4RVINrlQrYYyACdFzHf J0sHiHnxokUNDhj2/mU4LLs= =QkHH -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for RHL 9 packages from comment #5: * verified that the only changes this package vs earlier FL release are the addition of patches as specified in the changelog * the patches all match their given sources, which all seem good * kernel rebuilds okay, resulting package looks fine * installed on test system; boots and runs well enough to write this message +PUBLISH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCcBOIz8vebpLJCdYRAop8AKCfSvE6aivaWofAo4yLk8bFAsIK1ACfS7yV txX+PiICTSj4dF1k1Cw1Zk0= =v6zS -----END PGP SIGNATURE-----
I have three different machines running on kernel-2.4.20-43.7.legacy for some time. That means at least fourteen hours or more so far. All Athlons but with quite different hardware. No problems observed.
RHEL 2.1 advisory is out: https://rhn.redhat.com/errata/RHSA-2005-283.html Was CAN-2004-0619 (Broadcom 5820 integer overflow) already fixed in FL?
From the changelog for the rhl9 package: * Fri Jul 02 2004 Jon Peatfield <jp107.ac.uk> [...] - Drop Broadcom 5820 driver due to code quality concerns. I think any further vulnerabilities should get their own new bugs -- let's get this one out.
Packages were pushed to updates-testing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for RHL 73 srpm (but building on SL3 and running on RH8) from comment #4: * sha1sum matches * verified that the only specfile changes from -41.7.legacy are the changed patches -- Patch 2600/linux-2.4.20-CAN-2004-0814-tty.patch became linux-2.4.29-CAN-2004-0814-tty_ldisc.patch and Patch2601/linux-2.4.29-CAN-2004-0814-tty_ldisc-nptl.patch for NPTL case and the additional extra patches linux-2.4.20-CAN-2004-1058-proc_pid_cmdline_race.patch, linux-2.4.20-CAN-2004-1333-vtresize.patch, linux-2.4.20-CAN-2005-0384-pppd_dos.patch, linux-2.4.20-CAN-2005-0400-ext2_mkdir_leak.patch, linux-2.4.20-ipfrag-flush.patch, linux-2.4.20-CAN-2005-0504-moxa_rawio.patch, linux-2.4.20-CAN-2005-0749-elf_dos.patch, linux-2.4.20-CAN-2005-0750-bluetooth.patch, linux-2.4.20-CAN-2005-0815-isofs_range_flaw.patch The CAN-2004-0814 patches are far too big for me to understand but the others seem to be doing fairly sane things. * kernel rebuilds okay, resulting packages looks fine * installed on test systems; boots and seems ok +PUBLISH (though since I rebuilt the kernels on SL3 for RH8 you may not want to fully count this). Interestingly I also looked at building 2.4.21-27.0.4.EL for RH8 (built on RH8) but didn't _spot_ any of the compilation problems mentioned in comment #3 so it probably depends on the versions of gcc involved. On a test i686 machine the resulting kernel seemed to work fine EXCEPT that ntpd kept dying (and I get "out of memory" syslog messages). There are also warnings about crond signal handling but they don't seem to be fatal. Running ntpd under gdb showed that it crashes (with a SEGV) inside libc calling syslog() (as it reports the change of uid). I thought maybe that backing out the RHEL patch which moves the mmap default address (which affects where shared-libraries get mapped) might fix it, but it doesn't. Nor did updating to the ntpd version from RHEL3 help at all. So far ntpd is the only thing which shows any problems, but I suspect that whatever the real problem is will probably affect (a few) others too. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCeM2+S5LuHfP34NgRAtHDAKCzM6kk8diP3gswguYehfJjz7DjJgCff3BA 7fRhpIsrLhf3AnJibNJTQCE= =Dt1u -----END PGP SIGNATURE-----
For what it's worth, no reports of ntp dying on the RHL9-based machines we've got this running on here.
Rebuilding a RHEL3 kernel for RHL 7.3 and 8.0 is not a viable solution as the kernel contains the backported nptl code. A bunch of other packages not compatible with nptl would need to get backported also, including a new glibc... In other words, way too complicated to get working properly...
What about moving to that for rhl9?
Well, since rh7.3 and rh9 share the same kernel, it would actually be _more_ work for us if we do that for rh9.
Okay, sounds like pretty solid reasoning. :)
Re: Comment #21 I haven't looked at the kernel source for RHEL3, but in the RHL9 kernel source building for RHL7.3 is just a matter of changing %nptlarchs. Is there a similar switch in the RHEL3 kernel source?
Unfortunately, no. If I remember correctly the last time I checked it out, the nptl patches were integrated with a bunch of other stuff also, as was done with the FC1 kernel.
Just to clear things up, comment 19 was saying the RHEL kernel he tried to build was breaking things, not the rh9 kernel that we've got in updates-testing.
Indeed! The rh73 (essentially since rh8 is also lacking the ntpl stuff) based kernels are working fine on ~200 machines. I had *reasoned* that even if a kernel offers nptl facilities code/libs which know nothing about that won't try to use them (after all statically linked non-nptl aware code works fine on RHEL systems). However something else clearly also changed at about the same time (maybe something as small as the precise locations where allocations happen to occur, and that showed up some problem inside libc). That ntpd happened to be the first (only one I noticed) app which fails just shows that it was more sensitive to whatever the changes were. A co-worker with RH9 machines tested a RHEL3 kernel and ntpd dies for him too. Strange but true.
Created attachment 114534 [details] CAN-2005-1263 another one ... btw: I'm running kernel-2.4.22-1.2199.5 without problems for some time now ...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Verifying for RHL73 and RHL9: signature/PGP key OK, installed uniprocessor versions, which seem to work fine so far. +VERIFY RHL73, RHL9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFCnA+ZGHbTkzxSL7QRAnsNAKCC414CkpZdr+6pp2glzezP+UDkcgCg15Mu O2QkNFmPDIXJszL28WSuI68= =X1W2 -----END PGP SIGNATURE----- FWIW, ntpd works fine here..
I installed the -bigmem kernel (with ReiserFS patches added) on a production webserver Friday. Today the webserver crashed with lots of kernel: Out of Memory: Killing process.... Has anyone had similar issues?
Not particularly with this kernel.
I'm afraid I can't tell (I still don't understand the FL procedures), what is needed to move this one along to publish status. The patches in the srpms mentioned in #4 (and #5) seem entriely reasonable and I've personally been running essentially the RH73 version from #4 (though rebuilt on RH8), on ~220 machines since 10th May (a bit longer on ~5 test boxes). As more security pathces become needed will this one drag on like some of the earlier attempts to provide updated kernels? Since I don't personally have any RH73/9/FC1 boxes there is probably not much I can actually do involving verifications etc. I'm happy to lift patches from here (and elsewhere) and verify that they seem to be doing sane things, but that may not help you much... -- Jon
I am going to release this tonight or tomorrow...
These were officially released.