Bug 152696

I use the changelog from Debian which I've checked against kernel
kernel-source-2.4.20-30.7.legacy.i386.rpm:


  * Applied patch by Petr Vandrovec <vandrove.cz> to fix a
    possible roothole in ncpfs discovered by Arjan van de Ven
    <arjanv.redhat.com> [fs/ncpfs/dir.c, CAN-2004-0010]

      Is present -> forget it.

  * Applied patch by Sebastian Krahmer <krahmer> and Ernie
    Petrides <petrides> to fix a local root exploit in iso9660
    [fs/isofs/rock.c, CAN-2004-0109]

      Should apply cleanly. 

  * Applied patch by Alan Cox and Thomas Biege to fix local root exploit
    in the R128 DRI code [drivers/char/drm/r128_state.c, CAN-2004-0003,
    drivers/char/drm-4.0/r128_state.c] 
  * Applied additional patch by Ernie Petrides <petrides> to
    fix another intance of the same

      Partially fixed. Needs some work. Maybe it's possible to remove the
previous fix and apply debian's cleanly.

  * Applied patch by Theodore Ts'o <tytso> to fix an information
    leak in ext3 journal creation [fs/jbd/journal.c, CAN-2004-0177]

     Should apply cleanly. 

  * Applied patch by Andreas Kies <andikies> to fix local
    denial of service in the Sound Blaster driver
    [drivers/sound/sb_audio.c, CAN-2004-0178]

     Should apply cleanly, is a one-liner.


Debian's diff is here:

http://www.ibg.ac.at/~willi/diff.out

I havn't had enough time to more, especially to build rpms, and to work on a
modified patch for the r128 - problems. It's just an initial step to fix these
problems for 7.3 and 8.0



------- Additional Comments From dom 2004-04-20 10:25:30 ----

Created an attachment (id=634)
Patch for recent MS_FILTER vulnerability

http://isec.pl/vulnerabilities/isec-0015-msfilter.txt describes an additional
issue that was announced today. I've attached a patch for
net/ipv4/ip_sockglue.c extracted from the 2.4.26 diff but as I can't find much
public information on this at the moment I'm not sure whether there is more to
the patch to that. Haven't tried to work it into anything yet.



------- Additional Comments From dom 2004-04-23 06:49:05 ----

RHSA-2004:166-01 (for redhat 9) fixes most of these vulnerabilities but not the
msfilter one. Guess it's probably best to wait and see what else Red Hat come up
with in the next few days.



------- Additional Comments From dwb7.edu 2004-04-29 06:38:00 ----

Someone mentioned the kernel 2.4.20-31 from at-rpms.

Here is the top of its changelog:

%changelog
* Tue Apr 13 2004 Dave Jones <davej>
- Yet another additional r128 DRM check. (CAN-2004-0003)
- Bounds checking in ISO9660 filesystem. (CAN-2004-0109)
- Fix Information leak in EXT3 (CAN-2004-0133)
- Fix local DoS in mremap()

* Tue Feb 17 2004 Dave Jones <davej>
- Additional r128 DRM checks. (CAN-2004-0003)

* Thu Feb  5 2004 Dave Jones <davej>
- Check do_mremap return values (CAN-2004-0077)

* Mon Feb  2 2004 Dave Jones <davej>
- Fix NCPFS deep stack usage. (CAN-2004-0010)

* Fri Jan 16 2004 Dave Jones <davej>
- Check limits in R128 DRI drivers. (CAN-2004-0003)
- Fix user/kernel copying in Vicam USB driver. (CAN-2004-0075)
- Fix user/kernel copying in DRI GAMMA driver.
- Fix another NPTL local DoS.

--------------------------------------------------------

That being said, there are more holes if one looks at the recent Fedora Core 1
advisory:
* Wed Apr 21 2004 Dave Jones <davej redhat com>
- Fix memory leak in do_fork() error path
- Really fix CAN-2004-0109 and previous mremap issue.
  These patches were not applied in the previous errata.
- Fix information leak in XFS (CAN-2004-0133)
- Fix potential local denial of service in sb16 driver (CAN-2004-0178)
- Fix information leak in JFS (CAN-2004-0181)
- Add range checking to i810_dma() in DRM driver.
- Make ioctl(FBIOGETCMAP) use copy_to_user() rather than memcpy()
- Fix information leak in cpufreq userspace ioctl. (CAN-2004-0228)
- Fix possible buffer overflow in panic() (CAN-2004-0394)
- Fix setsockopt MCAST_MSFILTER integer overflow. (CAN-2004-0424)

------------------------------
So, as far as redhat linux goes, I suspect the at-rpms kernel rpms can just be
modified a bit more to have the additional patches applied.




------- Additional Comments From dom 2004-05-06 14:19:08 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've prepared packages for QA, based on the latest redhat 9 (release 31.9).
Versioning since there are additional fixes beyond those provided in the
above.

Issues fixed beyond previous fedora legacy kernel:

Redhat-provided (from kernel-2.4.20-31.9.src.rpm)

- - Additional r128 DRM checks. (CAN-2004-0003)
- - Yet another additional r128 DRM check. (CAN-2004-0003)
- - Bounds checking in ISO9660 filesystem. (CAN-2004-0109)
- - Fix Information leak in EXT3 (CAN-2004-0133)
- - Fix local DoS in mremap()

Fedora provided (from kernel-2.4.22-1.2188.nptl.src.rpm)

- - Fix potential local denial of service in sb16 driver (CAN-2004-0178)
- - Fix information leak in JFS (CAN-2004-0181)
- - Add range checking to i810_dma() in DRM driver.
- - Make ioctl(FBIOGETCMAP) use copy_to_user() rather than memcpy()
- - Fix possible buffer overflow in panic() (CAN-2004-0394)

Issues addressed in Fedora update by not this one:

- - Fix memory leak in do_fork() error path
 (this patch is messy to apply with NPTL patches and AFAICT is not a
 security issue (please correct me if this is wrong!)
- - Fix information leak in XFS (CAN-2004-0133)
 (xfs is not part of redhat kernels)
- - Fix information leak in cpufreq userspace ioctl. (CAN-2004-0228)
 (cpufreq is not a part of redhat kernels)
- - Fix setsockopt MCAST_MSFILTER integer overflow. (CAN-2004-0424)
 (not vulnerable)

Patches need sanity checking (eg that I haven't inadvertantly applied
patches that don't relate to this kernel version or are otherwise   
inconsistent as well as doing more general QA.

I'm running the Athlon rh7 kernel but haven't yet verified anything else.

2.4.20-31.7.legacy.1 applies to redhat 7.2, 7.3, 8
2.4.20-31.9.legacy.1 applies to redhat 9
 


http://www-astro.physics.ox.ac.uk/~dom/legacy/

SHA1sums:

8a88615d790630a34ee3fd997a079c53a3b713eb 
athlon/kernel-2.4.20-31.7.legacy.1.athlon.rpm
c3d7c1ad304e4a884bbb46a321e8e43efce2459d 
athlon/kernel-2.4.20-31.9.legacy.1.athlon.rpm
21ad53c3b02e60b3140c446d6f72eea0da066141 
athlon/kernel-smp-2.4.20-31.7.legacy.1.athlon.rpm
58e3f67aa09dddb862e7d2d325e93d93a822f175 
athlon/kernel-smp-2.4.20-31.9.legacy.1.athlon.rpm

c5042e1bb1545afd90c83ff8a5da9949cf562244  i386/kernel-2.4.20-31.7.legacy.1.i386.rpm
c6ec10f1a504a5fba49b11b6854caf2ade9a1b39  i386/kernel-2.4.20-31.9.legacy.1.i386.rpm
2fe5cde77a26bd82a43a7add236d8ccb8de0984c 
i386/kernel-BOOT-2.4.20-31.7.legacy.1.i386.rpm
77033d29a4810168b1658780a1b5b1374813a470 
i386/kernel-BOOT-2.4.20-31.9.legacy.1.i386.rpm
3a4e780f4a1d864b241ea6748f187b2d3e6335e0 
i386/kernel-doc-2.4.20-31.7.legacy.1.i386.rpm
b493efa7a052f32710d908c8fc0b69fa00769126 
i386/kernel-doc-2.4.20-31.9.legacy.1.i386.rpm
f3587bcb8b5dee578a545265f78856b9ddce198f 
i386/kernel-source-2.4.20-31.7.legacy.1.i386.rpm
134b32c38ae2dff2a7744d86e779db0ce4f27ee3 
i386/kernel-source-2.4.20-31.9.legacy.1.i386.rpm 

76362197a74afd5e7fd43971214215a9e34445d5  i586/kernel-2.4.20-31.7.legacy.1.i586.rpm
642500164f0051b081fbc440899711c5bf05b4c2  i586/kernel-2.4.20-31.9.legacy.1.i586.rpm
0870a7c1e716a8640f8330180c4112ae2176e63b 
i586/kernel-smp-2.4.20-31.7.legacy.1.i586.rpm
8be8cebeec848f0c1c8916671b63e7f616b68735 
i586/kernel-smp-2.4.20-31.9.legacy.1.i586.rpm 
 
3c935c8029e62fc90f004e2c3c7e085043c673a1  i686/kernel-2.4.20-31.7.legacy.1.i686.rpm
2de48eb7337ce15007ea820cc2db660df118241e  i686/kernel-2.4.20-31.9.legacy.1.i686.rpm
dad86062bd891b3ebd7e11f2eb37992428f94eb1 
i686/kernel-bigmem-2.4.20-31.7.legacy.1.i686.rpm
bf176bc9612cc99bd2e60011766c7e76a7d9f620 
i686/kernel-bigmem-2.4.20-31.9.legacy.1.i686.rpm 
bf74baa56716d02116dff8f2523c037db00c1aad 
i686/kernel-smp-2.4.20-31.7.legacy.1.i686.rpm
1fd010a9cdef93d0199cf8f29fdfcb233a13c9e3 
i686/kernel-smp-2.4.20-31.9.legacy.1.i686.rpm

76e36fff718aecfd36dfed0283dd04cd87dddd9a  SRPMS/kernel-2.4.20-31.7.legacy.1.src.rpm
8b70e53572c888d86fe57bd90211259e90ea1aaa  SRPMS/kernel-2.4.20-31.9.legacy.1.src.rpm
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAmtT9YzuFKFF44qURAjrhAJ4wp8Xa93pvyDuAElkHJeU8WTBxkwCg/c6E
XRKw9I/M0tXoUoDPYESKnVY=
=H+lM
-----END PGP SIGNATURE-----




------- Additional Comments From jonny.strom 2004-05-06 21:31:08 ----

The legacy uppdate is smaller than the latest Redhat 9 uppdate
is something missing or should it be like this?

38926459 Apr 20 18:08 kernel-source-2.4.20-31.9.i386.rpm
38732544 May  7 02:50 kernel-source-2.4.20-31.9.legacy.1.i386.rpm



------- Additional Comments From dom 2004-05-14 04:13:35 ----

New revision of the packages at 

http://www-astro.physics.ox.ac.uk/~dom/legacy/

with version 2.4.20-32.7.legacy (Red Hat Linux 7.2, 7.3, 8.0)
and          2.4.20-32.9.legacy (Red Hat Linux 9)

Changes from previous candidate:

- Fix information leak in cpufreq userspace ioctl. (CAN-2004-0228)
- Fix for C1 Halt Disconnect problem on nForce2 systems.

Packages are GPG signed. I'll post gpg signed sha1sums this evening for
completeness. Please QA, especially on nforce2 systems!

I haven't had a chance to look in the problem Johnny reported with the
kernel-source package yet.



------- Additional Comments From jkeating 2004-05-18 18:40:29 ----

I have seen no QA yet, this REALLY needs to be looked at before I push to
updates-testing...



------- Additional Comments From jpdalbec 2004-05-19 10:10:53 ----

Created an attachment (id=677)
clearsigned diff -urN between -31.9 and -32.7.legacy




------- Additional Comments From jpdalbec 2004-05-19 10:20:45 ----

Created an attachment (id=678)
clearsigned diff -urN between -31.9 and -32.9.legacy




------- Additional Comments From jpdalbec 2004-05-19 10:22:00 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Partial QA:

sha1sums:
195c09e0c3fb6c02e9eca1300a84355ab86d8b4e  kernel.7.diff.asc
5c159d9a0ec5e91d8901239a8933a14e0283b711  kernel.9.diff.asc
4878c66a975bc247b9becd6ae8b0a9f81825ef5d  kernel-2.4.20-31.9.src.rpm
b3d823c971fa613696e607e596daed71b1dd127d  kernel-2.4.20-32.7.legacy.src.rpm
22867632b9cc4e8c070fc25a685916f78942ac6c  kernel-2.4.20-32.9.legacy.src.rpm

All .src.rpms have good signatures.

All .spec and patchfile differences look reasonable to me.  I've attached "diff 
- -urN" files of the fedora-unrpm'd .src.rpms to this bug.

I haven't had a chance to test the kernels yet because I'm in the middle of 
building some packages.  I haven't noticed any problems so far building 
customized kernel packages based on the RHL 7 .src.rpm.

- -rw-rw-r--    1 jpdalbec jpdalbec 34583006 Apr 20 11:08 
kernel-2.4.20-31.9.src.rpm
- -rw-rw-r--    1 jpdalbec jpdalbec 34587072 May 13 16:15 
kernel-2.4.20-32.7.legacy.src.rpm
- -rw-rw-r--    1 jpdalbec jpdalbec 34587072 May 13 16:15 
kernel-2.4.20-32.9.legacy.src.rpm

I'm not seeing the problem Johnny Strom was describing, and my file sizes are 
noticeably smaller in both cases.  Is his "official" .src.rpm perhaps a Finnish 
i18n/l10n version?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFAq7RrJL4A+ldA7asRAmU4AJ9wdLBK7xvt4wonM9kV9vmvHtBLUgCfdXSf
yH+8wBISjykHSGxG6whwn2k=
=XXVZ
-----END PGP SIGNATURE-----




------- Additional Comments From jonny.strom 2004-05-19 10:40:45 ----

Well I am talking about the kernel-source rpm's not the src.rpm's:

So here are the info for latest two offcial RH 9 kernel-sourc rpm's that I have
downloaded from a redhat mirror:
38926014 Feb 18 21:47 kernel-source-2.4.20-30.9.i386.rpm
38926459 Apr 23 01:09 kernel-source-2.4.20-31.9.i386.rpm


And thay are not any kind of i18n/l10n version's or anyting like that,
dose the size of the uppdated kernel-source rpm's match more or less now the
original that I have?



------- Additional Comments From dom 2004-05-19 13:03:58 ----

My new package is:

38739653 May 14 11:14 kernel-source-2.4.20-32.9.legacy.i386.rpm

So again quite a descrepancy there. I can't figure out why this is, as I'm
pretty sure the sources are clean. Can someone else try building this
kernel-source package to see if there's something wrong with my environment?



------- Additional Comments From jonny.strom 2004-05-19 22:56:18 ----

I downloaded kernel-2.4.20-32.9.legacy.src.rpm and then I built it on a
Redhat 9 system and I got this result on the file size:

38945200 May 20 11:46 kernel-source-2.4.20-32.9.legacy.i386.rpm

I have put up a list of all files included in my
kernel-source-2.4.20-32.9.legacy.i386.rpm file here:
 
http://av8.netikka.fi/~johnny/kernel-source-2.4.20-32.9.txt

Please compare if they are matching our list of files.



------- Additional Comments From dom 2004-05-20 02:07:04 ----

My filelist is identical:
http://www-astro.physics.ox.ac.uk/~dom/legacy/kernel-source-2.4.20-32.9.txt.gz

However all my RPMs were built on a redhat 7.3 system so it's possible that the
older RPM tool is using slightly worse compression, or packing less metadata
into the RPM. Normally I wouldn't have put redhat 9 packages up compiled on
redhat 7.3, but for the kernel I figured that as there were so few userspace
dependencies things should work okay. Maybe this was a rash assumption.

It might be an idea for someone to put up redhat 9 compiled-on-9 binary packages
to help the QA along.



------- Additional Comments From jonny.strom 2004-05-20 02:19:08 ----

Ok well since your rpms was done on RH 7.3 and not on RH 9 then that explains the 
size differnce. And also the size of the
kernel-source-2.4.20-32.9.legacy.i386.rpm are line line with the latest relase
from Redhat built on a Redhat 9 system.



------- Additional Comments From jpdalbec 2004-05-20 03:21:32 ----

Yes, I'd call that a rash assumption.  The userland difference between 7.3 and 9
that most directly affects the kernel is glibc-2.2.5-44 vs. glibc-2.3.2-27.9.7.



------- Additional Comments From jonny.strom 2004-05-20 03:50:50 ----

I have installed kernel-source-2.4.20-32.9.legacy.i386.rpm on Redhat 9 system
and compiled my oven standard kernel from that source and everyting is working
as ok.



------- Additional Comments From marcdeslauriers 2004-06-06 11:26:52 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA for both the 7.3 and the 9 kernels:

sha1sums:
b3d823c971fa613696e607e596daed71b1dd127d  kernel-2.4.20-32.7.legacy.src.rpm
22867632b9cc4e8c070fc25a685916f78942ac6c  kernel-2.4.20-32.9.legacy.src.rpm

Compared the source files to the last rh9 kernel package. OK as only the
new patches listed in the changelog were different.

Inspected the patches. OK as everything looks reasonable.

Made sure the 7.3 kernel deactivates nptl: OK

Changelog looks OK.

Source packages built, installed and ran fine on 7.3 and 9.

Dominic did great work!

+PUBLISH


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAw4wBLMAs/0C4zNoRAhtWAKCy2TKbsP6ehTDiYcMptph7dSGtGQCgnOAW
6NmilttuWSpcUNKWymDvvAo=
=/Wir
-----END PGP SIGNATURE-----




------- Additional Comments From jpdalbec 2004-06-07 07:26:07 ----

I installed kernel-2.4.20-32.7.legacy.src.rpm, customized the .spec file to add
ReiserFS bugfixes and data-logging and quota patches, some TCP/IP fixes, and a
RAID driver update and to enable QIFACE backward compatibility, and installed
the result on two production RH 7.3 machines Friday evening.  I haven't noticed
any problems yet.  Unfortunately, I've deleted the original .src.rpm so I can't
confirm its sha1sum.  I haven't bothered signing this comment since it would be
replayable.



------- Additional Comments From dom 2004-06-14 07:13:40 ----

a local crash DoS has been reported:
http://linuxreviews.org/news/2004-06-11_kernel_crash/index.html.

Watching for a definitive patch, then I'll add it to my packages. Hopefully
we'll get something out of the door eventually...



------- Additional Comments From dom 2004-06-15 15:07:27 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

New package with
http://linux.bkbits.net:8080/linux-2.4/diffs/include/asm-i386/i387.h@1.5?nav=index.html|src/|src/include|src/include/asm-i386|hist/include/asm-i386/i387.h
applied.

(no rh9 binary test rpms this time as they are questionable built on rh7)

SRPMS:
http://www-astro.physics.ox.ac.uk/~dom/legacy/SRPMS/kernel-2.4.20-33.7.legacy.src.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/SRPMS/kernel-2.4.20-33.9.legacy.src.rpm

sha1sums:
d2fbdee37fb3469731ca95ce8e8326f5f1f8110e  kernel-2.4.20-33.7.legacy.src.rpm
76fb9ccfa4056cd3bfe48621f1876e2199b3416d  kernel-2.4.20-33.9.legacy.src.rpm

test binary RPMS:
http://www-astro.physics.ox.ac.uk/~dom/legacy/athlon/kernel-2.4.20-33.7.legacy.athlon.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/athlon/kernel-smp-2.4.20-33.7.legacy.athlon.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/i386/kernel-2.4.20-33.7.legacy.i386.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/i386/kernel-BOOT-2.4.20-33.7.legacy.i386.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/i386/kernel-doc-2.4.20-33.7.legacy.i386.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/i386/kernel-source-2.4.20-33.7.legacy.i386.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/i586/kernel-2.4.20-33.7.legacy.i586.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/i586/kernel-smp-2.4.20-33.7.legacy.i586.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/i686/kernel-2.4.20-33.7.legacy.i686.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/i686/kernel-bigmem-2.4.20-33.7.legacy.i686.rpm
http://www-astro.physics.ox.ac.uk/~dom/legacy/i686/kernel-smp-2.4.20-33.7.legacy.i686.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAz50FYzuFKFF44qURAmH5AJ9HEA/wTpC/BeZ+5UxvV6VJoH/hKwCg8q6t
c7eISfZZX3a0lUXb8+FG/rk=
=hRM8
-----END PGP SIGNATURE-----



------- Additional Comments From villegas.edu 2004-06-16 04:42:56 ----

The signature on comment 21 was apparently damaged by bugzilla (long lines),
could you (Dominic) please post a short signed message like "comment 21" is
valid? (Just to keep things tight). Will post QA results soon.



------- Additional Comments From dom 2004-06-16 05:28:26 ----

Signature verifies if you remove the line break after the text "New package with ".



------- Additional Comments From pedrocj 2004-06-16 10:42:28 ----

I'm downloading the new kernel for QA. Thanks.



------- Additional Comments From villegas.edu 2004-06-16 17:30:51 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


This applies to the kernel package with sha1sum: 

76fb9ccfa4056cd3bfe48621f1876e2199b3416d  kernel-2.4.20-33.9.legacy.src.rpm

from:

http://www-astro.physics.ox.ac.uk/~dom/legacy/SRPMS/

1. sha1sum verified ok.
2. srpm is based on RH 9 latest update, only changes are added patches
        and spec file changes.
3. the spec file is clean.
4. patches are make the same changes as from other sources, and look sane
        (the only one I didn't verify against other sources is 
        linux-2.4.26-nvidia.nforce2.patch)
5. builds ok. (didn't try the smp)
6. size looks ok for kernel-source rpm
7. kernel installs clean. (didn't try the smp)
8. kernel works fine, (didn't try POC on the vulnerabilities).

I vote PUBLISH.

Carlos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA0RATnACJnHU2u1ERAvQuAJ0bCQcS/yP+zjB11jozgJN0yLQrngCgvIjy
3ytCd9zDuoDshWZGf9I3IQc=
=3F5k
-----END PGP SIGNATURE-----



------- Additional Comments From villegas.edu 2004-06-16 17:40:06 ----


Hmmm... bugzilla damaged my signature (comment 25)...

A copy of the signed report can be found at:

http://www.math.gatech.edu/~villegas/linux/fedora-legacy/QA-kernel-2.4.20-33.9.txt.asc

Sorry.



------- Additional Comments From jkeating 2004-06-17 05:04:08 ----

another RHL9 kernel patch.
 Date: Today 04:03:45
 From: Dave Jones <davej.uk>
 To: fedora-legacy-list
 Reply to: Discussion of the Fedora Legacy Project <fedora-legacy-list>
 
There's a nasty memory leak fixed in FC1 which should have been
backported to RHL9, as its user exploitable, and can be considered
a local DoS.  This was CAN-2004-0427

I'm fairly certain this hasn't been picked up yet, so patch below.

                Dave

--- linux-2.4.20/kernel/fork.c~ 2004-06-17 11:49:24.767644168 +0100
+++ linux-2.4.20/kernel/fork.c  2004-06-17 11:49:57.011742320 +0100
@@ -971,6 +971,8 @@
        exit_namespace(p);
 bad_fork_cleanup_mm:
        exit_mm(p);
+       if (p->active_mm)
+               mmdrop(p->active_mm);
 bad_fork_cleanup_signal:
        exit_signal(p);
 bad_fork_cleanup_sighand:



------- Additional Comments From jkeating 2004-06-17 05:04:30 ----

Re: another RHL9 kernel patch.
 Date: Today 07:58:37
 From: Dave Jones <davej>
 To: Discussion of the Fedora Legacy Project <fedora-legacy-list>
 Reply to: Discussion of the Fedora Legacy Project <fedora-legacy-list>

You will however likely need these too.
ftp://ftp.linux.org.uk/pub/people/viro/misc.tar.bz2

I'm just rebuilding the FC1 update with these added.

        Dave



------- Additional Comments From dom 2004-06-17 07:23:01 ----

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0535 is another fix that
should probably go in.



------- Additional Comments From leonard.nl 2004-06-18 12:20:18 ----

I see a few fixes in the FC 1 2.4.24-1.2188 kernel that are not in the RHL 9
kernel. Not sure if these are relevant, but better safe than sorry :) .

* Wed Feb 25 2004 Dave Jones <davej>
- Default 8139too driver to PIO as some machines lock up.

* Wed Feb 18 2004 Dave Jones <davej>
- Fix security problem in gamma DRI driver.

* Tue Feb 17 2004 Dave Jones <davej>
- Fix leak in SSTFB driver.

And more before that?




------- Additional Comments From dom 2004-06-18 13:57:29 ----

They date from well before rh9 was EOLd. I don't have the energy at the moment
to follow up on these, but I think it is very unlikely that they have any
relevance to our kernels. I'm prepared to be proved wrong, however...



------- Additional Comments From dom 2004-06-19 02:26:22 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Another batch.

* Fri Jun 18 2004 Dominic Hargreaves <dom>

- - Fix memory leak in kernel/fork.c. (CAN-2004-0427)
- - Numerous userspace pointer reference bugs found with the sparse
  tool by Al Viro. (CAN-2004-0495)
- - Fix e1000 driver information leak. (CAN-2004-0535)

No NFS fix for now, on the assumption that people that need it
will have already fixed it themselves.

http://www-astro.physics.ox.ac.uk/~dom/legacy/

d88df69f8c95c2c72a1b7399e6d3f2d1bea04a20
 SRPMS/kernel-2.4.20-34.7.legacy.src.rpm
800222398453badb85ef5788458b1596b666590f
 SRPMS/kernel-2.4.20-34.9.legacy.src.rpm

201ba664c6d62fbfe86d3b6a2363e2a0ccb9f30e
 athlon/kernel-2.4.20-34.7.legacy.athlon.rpm
e2c8e820a914754199942596ba3b4340f76c471b
 athlon/kernel-smp-2.4.20-34.7.legacy.athlon.rpm
b1c685c4c1c6e8229c90697049891d458223c614
 i386/kernel-2.4.20-34.7.legacy.i386.rpm
41c57732307fc9fc012ca8481102fab15fde7b62
 i386/kernel-BOOT-2.4.20-34.7.legacy.i386.rpm
5dc2323d2ed453a2ed607dafd9f49f3542203e05
 i386/kernel-doc-2.4.20-34.7.legacy.i386.rpm
9fef1401f3fdbee5f83c1d13e902667bbb12cb96
 i386/kernel-source-2.4.20-34.7.legacy.i386.rpm
a0ac4749137ea55a1f198495034f68d14449de29
 i586/kernel-2.4.20-34.7.legacy.i586.rpm
bdf9d2c61f010ca94f02df597b872078761a803a
 i586/kernel-smp-2.4.20-34.7.legacy.i586.rpm
fefd892e65a782d3af96323a4cca2604a163fdf0
 i686/kernel-2.4.20-34.7.legacy.i686.rpm
ab9fa44ad661aff30a097d218cab0b062ce878bd
 i686/kernel-bigmem-2.4.20-34.7.legacy.i686.rpm
4777a8f05ab5f9bf6e1a52493c0cb63952e363e4
 i686/kernel-smp-2.4.20-34.7.legacy.i686.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA1DC6YzuFKFF44qURApROAJ9ARID0cK6xY5GeZp8X6lagRUrCRQCfbC2Q
OWVCQ1uJD6GsNFQQ4rLV03Q=
=TzFn
-----END PGP SIGNATURE-----




------- Additional Comments From jp107.ac.uk 2004-06-19 10:10:18 ----

I've downloaded the kernel-2.4.20-34.9.legacy.src.rpm and it looks reasonable.

I'm building binary versions now on a test RH9 box and hopefully will get to
test  the i686 version early tomorrow (on a pair of test RH9 machines).

 -- Jon




------- Additional Comments From jp107.ac.uk 2004-06-19 12:55:13 ----

sha1sum $SRPM
800222398453badb85ef5788458b1596b666590f  kernel-2.4.20-34.9.legacy.src.rpm

rpm --checksig -v $SRPM

kernel-2.4.20-34.9.legacy.src.rpm:
    Header SHA1 digest: OK (a06378dd1c16ae87340e17d822ae4e9377eea75c)
    MD5 digest: OK (41b21a2fe8a6cf8a43a2745bf6559ed9)
    V3 DSA signature: NOKEY, key ID 5178e2a5

shows it passes md5/sha1 checksums (but I can't get the gpg key to load)

diff of specfile with RH provided kernel-2.4.20-31.9.src.rpm shows
just the new patches added and changelog update etc.

Diff of the SOURCES trees shows only the new patches added:

diff -ur $ORIG/SOURCES/ SOURCES/
Only in SOURCES/: linux-2.4.20-cpufreq.sec.patch
Only in SOURCES/: linux-2.4.25pre-selected-patches.legacy.patch
Only in SOURCES/: linux-2.4.26-nvidia.nforce2.patch
Only in SOURCES/: linux-2.4.26pre-selected-patches.legacy.patch
Only in SOURCES/: linux-2.4.27pre-e1000-fix.patch
Only in SOURCES/: linux-2.4.27pre-fix-x86-clear_fpu-macro.patch
Only in SOURCES/: linux-fork_c_cleanup_mm.patch
Only in SOURCES/: linux-misc-viro-fixes.patch

Reading those patches they look like they make sense, and don't seem
unreasonable.

diff -urP $ORIG/SOURCES/ SOURCES/|more
...

Check it all unpacks/preps, rpmbuild -bp looks fine and seems to apply
all the patches fairly cleanly.

Building on a test RH9 system...

The first few binary builds of the RH9 version finished and I'm testing the i686
kernel on a Pentium-II machine at the moment.  So far no surprises...

$ uname -r
2.4.20-34.9.legacy

I'm going to leave that machine doing something significant for 12 hours (hmm,
lets build more kernels).

I'll let you know more (probably tomorrow it being 23:55 here as I type).




------- Additional Comments From jp107.ac.uk 2004-06-21 06:44:56 ----

I've done some light testing of the RH9 version (-34.9.legacy) and a slightly
modified version of the RH73/80 version (-34.7.legacy).  I don't know if this
will count as a QA or not.

Please advise if I'm missing anything.

http://www.damtp.cam.ac.uk/user/jp107/legacy/FL-QA-report.asc

is my report on RH9 (not included here since it has long lines which will be broken)

http://www.damtp.cam.ac.uk/user/jp107/legacy/FL-QA-report-RH80.asc

is for my tests on the lightly modified one for my RH80 systems.

I've built binary RH9 packages if anyone is interested in testing them.  As
usual my RPMs are signed with our "DAMTP RPM signing key":

http://www.damtp.cam.ac.uk/user/jp107/legacy/9/

RPMS/athlon/kernel-smp-2.4.20-34.9.legacy.athlon.rpm
RPMS/athlon/kernel-2.4.20-34.9.legacy.athlon.rpm
RPMS/i386/kernel-BOOT-2.4.20-34.9.legacy.i386.rpm
RPMS/i386/kernel-2.4.20-34.9.legacy.i386.rpm
RPMS/i386/kernel-doc-2.4.20-34.9.legacy.i386.rpm
RPMS/i386/kernel-source-2.4.20-34.9.legacy.i386.rpm
RPMS/i586/kernel-smp-2.4.20-34.9.legacy.i586.rpm
RPMS/i586/kernel-2.4.20-34.9.legacy.i586.rpm
RPMS/i686/kernel-bigmem-2.4.20-34.9.legacy.i686.rpm
RPMS/i686/kernel-2.4.20-34.9.legacy.i686.rpm
RPMS/i686/kernel-smp-2.4.20-34.9.legacy.i686.rpm
SRPMS/kernel-2.4.20-34.9.legacy.src.rpm

84a80f0fa9f68505625483d7bbbf42a3ba15cd3f 
RPMS/athlon/kernel-smp-2.4.20-34.9.legacy.athlon.rpm
f2cdca6b4f7d98ae892fb4d331afebaaee7cfb9d 
RPMS/athlon/kernel-2.4.20-34.9.legacy.athlon.rpm
42ce0c257c7b6646321d096f857e7aef070165a7 
RPMS/i386/kernel-BOOT-2.4.20-34.9.legacy.i386.rpm
a39c6e472f2484a16b70c7e8a4bebbc150844cf3 
RPMS/i386/kernel-2.4.20-34.9.legacy.i386.rpm
bc3e73daeab1715ef873bd3acfcad89f0498686b 
RPMS/i386/kernel-doc-2.4.20-34.9.legacy.i386.rpm
51f91dbad87bb30bf5cb964ad40f8027b46a0b78 
RPMS/i386/kernel-source-2.4.20-34.9.legacy.i386.rpm
f0c9ba1b6231a52c37d88e352219ddaf50a338ef 
RPMS/i586/kernel-smp-2.4.20-34.9.legacy.i586.rpm
5fd0ed2ae929feb59a5fe531825bd5a3a525b4f6 
RPMS/i586/kernel-2.4.20-34.9.legacy.i586.rpm
f50af58f996f947fc81b4e073a553e0e15396bfe 
RPMS/i686/kernel-bigmem-2.4.20-34.9.legacy.i686.rpm
3372ae1d9dd6b074e5db296b6825607b3c9bdcfe 
RPMS/i686/kernel-2.4.20-34.9.legacy.i686.rpm
aac17e6ca5c3b5ae02a0b3415eed798619ccf8e5 
RPMS/i686/kernel-smp-2.4.20-34.9.legacy.i686.rpm
1dd60f27f2fb82c2fab10412cff8ad3cbd14d28c  SRPMS/kernel-2.4.20-34.9.legacy.src.rpm

I see no problems with the proposed -34.9.legacy (or 34.7.legacy) proposed updates.

 -- Jon




------- Additional Comments From dwb7.edu 2004-06-22 05:38:18 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

sha1sum -b kernel-2.4.20-34.7.legacy.src.rpm 
d88df69f8c95c2c72a1b7399e6d3f2d1bea04a20 *kernel-2.4.20-34.7.legacy.src.rpm

I see the following patches added by diffing the spec files:

Patch990: linux-2.4.27pre-fix-x86-clear_fpu-macro.patch
Patch2570: linux-misc-viro-fixes.patch
Patch2580: linux-2.4.27pre-e1000-fix.patch
Patch11033: linux-fork_c_cleanup_mm.patch

rpmlint shows a lot of patches not applied:
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.patch
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 Patch7000: linux-2.4.18-mmap-sem-debug.patch
W: kernel patch-not-applied Patch7001: linux-2.4.18-mmap-sem-debug-i386.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 Patch1060: linux-2.4.20-orinoco.patch
W: kernel patch-not-applied Patch1240: linux-2.4.17-usb-55878.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 Patch2300: linux-2.4.9-ide-tape.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 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
W: kernel patch-not-applied Patch7010: linux-2.4.18-gfp-valid.patch


In process of building on rh7.3

- -DWB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFA2FIWSY7s7uPf/IURAtxtAJ42g1Jz+p0vZFsvpWQz6k3Z274MigCeMHXM
1r2k/S/+BCf8jrFFugHJaoI=
=zFsl
-----END PGP SIGNATURE-----



------- Additional Comments From hbo 2004-06-22 15:38:58 ----

I have all of Dominic's  patches applied to a customer's internal version of Red
Hat 7.3. They all applied without a problem, though the e1000 patch had an
offset of over 1000 lines.
                                                                               
                                
The modified SRPM built without error. I'm currently running the kernel on
my XW4100 workstation. I'm looking to install the kernel on a system with
an e1000 tomorrow. I realize this report has limited value since the
patches are applied to a different source base, but the fact that they
applied so smoothly in the different environment should tell you
something. 8)
                                                                               
                                
I'll be installing the FL kernel tonight on a home system.



------- Additional Comments From hbo 2004-06-22 18:13:58 ----

Regarding building kernel packages on RH 7.3, there is a problem with the last
errata gcc package released by Red Hat for that OS:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87659

I use gcc-2.96-112 to build 7.3 kernel packages to avoid the problems detailed
in that bug.



------- Additional Comments From rmy.uk 2004-06-23 04:08:39 ----

-----BEGIN PGP SIGNED MESSAGE-----

$ sha1sum kernel-2.4.20-34.7.legacy.src.rpm
d88df69f8c95c2c72a1b7399e6d3f2d1bea04a20
  kernel-2.4.20-34.7.legacy.src.rpm

I've compared the contents of the SRPM against 2.4.20-30.7.legacy,
2.4.20-31.9 (RH9) and 2.4.22-1.2194.nptl (FC1).  As compared with
the RH9 kernel 2.4.20-34.7.legacy has eight new patches.  The spec
file has been altered to suit.

Most of the new patches can be matched against similar patches in
the FC1 kernel, with some omissions.  The only exceptions being:

   linux-2.4.26-nvidia.nforce2.patch
   fbmem.c in linux-2.4.26pre-selected-patches.legacy.patch
   linux-2.4.27pre-e1000-fix.patch

The first two can be traced to LKML postings.  The e1000 fix
differs from the one in FC1's linux-2.4.27pre-selected-patches.patch.
I suspect the latter is correct.

I've built a binary i686 RPM from the supplied SRPM, and this is
now running on a machine with an e1000 ethernet card.  There have
been no obvious problems.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iQCVAwUBQNmNux2/joqPEUdFAQG05AP+IN56XBTC4U6k2tr55TUsTtq/ABdldcQb
EaS5aw8CzXDL/jCZE3u1A13s4RodWSlWnoOmmgmKyEuUJDSILu5HGOt+tFEYk6Wr
coNT7TPTdLSUfPvMmDZbV4+8MOda55Ska+62oAPx2J5nQ8b5ThUdat0MMP3pCxki
TG/JnyCtp7Q=
=XXJF
-----END PGP SIGNATURE-----



------- Additional Comments From dom 2004-06-23 13:04:53 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Another update, this time with a correct e1000 fix.

http://urchin.earth.li/~dom/legacy/

debd859dfcd750d4a84f7e96c653df04 SRPMS/kernel-2.4.20-35.7.legacy.src.rpm
d2cc1f03bac18ec8b2daa0b77e485283 SRPMS/kernel-2.4.20-35.9.legacy.src.rpm
2d43536bfcd50454954cb0dd1c5a8e8e athlon/kernel-2.4.20-35.7.legacy.athlon.rpm
5ef6fedc1724f6d96735ab7b9a3bf05e athlon/kernel-smp-2.4.20-35.7.legacy.athlon.rpm
69b1d6b71d42089527c6d723bb330fef i386/kernel-2.4.20-35.7.legacy.i386.rpm
0d3b73491cfb8d444121e990f265b91a i386/kernel-BOOT-2.4.20-35.7.legacy.i386.rpm
9678f4be20c5531c85b1da312514eae0 i386/kernel-doc-2.4.20-35.7.legacy.i386.rpm
412008f3eb60852c79db2488fded13d5 i386/kernel-source-2.4.20-35.7.legacy.i386.rpm
7f492b947188dcd633621ed612c90d55 i586/kernel-2.4.20-35.7.legacy.i586.rpm
66db8134de044dadf5331811df79975e i586/kernel-smp-2.4.20-35.7.legacy.i586.rpm
9ea4321e287da7160c8de9261fd63614 i686/kernel-2.4.20-35.7.legacy.i686.rpm
93325dfaba0788680b6fc7308de87037 i686/kernel-bigmem-2.4.20-35.7.legacy.i686.rpm
db9097f88739d226aabfdfc364bd81f3 i686/kernel-smp-2.4.20-35.7.legacy.i686.rpm

NB: md5sums this time round, sorry.

This is a correctness fix for the e1000 bugfix.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2gx8YzuFKFF44qURAu+JAKDjDsVDDvu7Dj3tpIIAo2wNH3IuPQCfXhGh
qEGC4RzCE+y5h/0ZrGP6FQk=
=KvFf
-----END PGP SIGNATURE-----



------- Additional Comments From rmy.uk 2004-06-24 03:04:41 ----

-----BEGIN PGP SIGNED MESSAGE-----

Further to comment #39, I've checked the latest SRPM for RH73:

$ md5sum kernel-2.4.20-35.7.legacy.src.rpm
debd859dfcd750d4a84f7e96c653df04  kernel-2.4.20-35.7.legacy.src.rpm

This is identical to 2.4.20-34.7.legacy apart from the version
number and the corrected e1000 patch.

I've built an i686 binary RPM which has been installed on a
machine with an e1000 ethernet interface.  The revised patch is
working as expected.  The machine is happily running seismic
processing software and a user-mode Linux development environment.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iQCVAwUBQNrQsx2/joqPEUdFAQHerAP/UlVjd+LVFihNFDdT/t7abT9Y/i9SxJAb
7ceFDx6MQyaamM2gSSOqpoK89Sp4gyTyosUQ+HzttogAIl+jlre0tieMaZ6t09mk
+lkknCCVAusv+D0VtwOh9QAKR8acy4W6f6mSjXGrZCTMmgTNGPV5Z4fyOsk6qKFo
i+2baRSTNpY=
=Dt+Q
-----END PGP SIGNATURE-----



------- Additional Comments From jp107.ac.uk 2004-06-24 04:41:26 ----

Looking at the RH9 version now, the specfile just has the version diff and the
change to SOURCES/linux-2.4.27pre-e1000-fix.patch looks reasonable (though since
we are already zeroing the entire regs_buff I's assume that the previosu patch
will still happily squash the "user getting to see 24 bytes of kernel memory"
bug anyway.

I'm building RH9 versions now and will update my previous QA report (and post
something here when I do).



------- Additional Comments From jp107.ac.uk 2004-06-24 09:11:55 ----

I'll keep it short (this bugzilla is long enough already!).

My testing of -35.9.legacy on a pair of RH9 machines shows nothing unusual, and
one of them does have an e1000 card so I know it it still working (so far).

More detailed report at

  http://www.damtp.cam.ac.uk/user/jp107/legacy/FL-QA-report.asc

if anyone wants them there are RH9 binary rpms under:

  http://www.damtp.cam.ac.uk/user/jp107/legacy/9/

I'm building some RH8 versions based on -35.7.legacy but I'm starting to loose
the will to try to keep up...




------- Additional Comments From jarod 2004-06-24 12:08:33 ----

Some QA feedback: 
 
I grabbed the 34.7 srpm, modified the e1000 patch myself (should match the 35.7 
release), built some rpms, and have them running fine on a quad-proc Xeon and a 
dual-proc PIII. No e1000 cards, but no problems to speak of. 



------- Additional Comments From michal 2004-06-24 13:52:53 ----

I have some Athlon machines running on 35.7 (one of these has patched quite
a bit RH 7.2 :-) and they are doing just fine.  I do not have anything on hands
with e1000 though.



------- Additional Comments From hbo 2004-06-24 14:46:11 ----

I have a 7.3 based custom distro with the FL patches integrated running on two
systems. On is my primary desktop, an XW4100, The other is a Dell 6450 quad box.
Both are holding up very well, the first under my normal desktop load, which
includes RPM building and X stuff, the second under a series of I/O tests
including Bonnie++. The server has an e1000, and it seems to produce reasonable
data when ethtool -d is run.

At home I have a Dell 550SC server running the 34.7 kernel. It is also running
without glitches, albeit under a lighter load. It's my email and DNS master, but
that doesn't amount to much on my one-person network. 8)




------- Additional Comments From dwb7.edu 2004-06-28 05:08:43 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

2.4.20-34.legacy is working just fine here (e1000 and all). Assuming that the
e1000 is the only diff between 34 and 35, I vote for PUBLISH.

We rebuilt from:
sha1sum -b kernel-2.4.20-34.7.legacy.src.rpm 
d88df69f8c95c2c72a1b7399e6d3f2d1bea04a20 *kernel-2.4.20-34.7.legacy.src.rpm

- -DWB



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFA4DRjSY7s7uPf/IURAnY1AJ40i9zxBILLBZM4K05NXhnN6YvYMQCfdqEv
fL/EY6fNw0c4LDZOUkaTB6k=
=syIL
-----END PGP SIGNATURE-----




------- Additional Comments From jpdalbec 2004-07-09 04:57:07 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

++VERIFY RH 7.3

d5a327b9888b830bb9226432e728f1cdf421d3be  kernel-2.4.20-35.7.legacy.src.rpm

I've added ReiserFS bugfix/quota/data-logging patches, increased some TCP/IP
stack timeouts, turned on the backward-compatible kernel quota interface, and
added a RAID controller driver to the original .spec file.  I'm running the
resulting kernel-bigmem package on four Pentium III 1GHz single-processor
production servers since Friday July 2 2004.  I haven't seen any problems that
could be attributed to the kernel since then.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFA7rH7JL4A+ldA7asRAlQ4AKCSF213mOSX4i+KpI2LLWnkBuGAEACgqPCA
SlHL/0ReOUaaFe2w02hRgVU=
=FBz0
-----END PGP SIGNATURE-----




------- Additional Comments From cra 2004-07-16 17:08:38 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tested -35.7.legacy i586 kernel on a RHL 7.3 box.  Been running for a few
days now without problems.  sha1sum:

75e49a453639b57ca295ed687915df718ca4683d  kernel-2.4.20-35.7.legacy.i586.rpm


Tested -35.9.legacy i686 and athlon kernels on several RHL 9 boxes. 
Running fine for a few days.  sha1sums:

2050252b57943da552fc17873331d702585488a4  kernel-2.4.20-35.9.legacy.i686.rpm
6374592090c07112200494e9361db824edb4511a  kernel-2.4.20-35.9.legacy.athlon.rpm

VERIFY RH 7.3
VERIFY RH 9

Vote to move to updates directory.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD4DBQFA+Jfsw2eg+Um7WIYRAob0AJ9K8qNi5h7/DLrjWHVWIN7vNBxW6ACVFwz/
AQIIhPS5hM5jzquzmPwkCQ==
=OfAq
-----END PGP SIGNATURE-----




------- Additional Comments From michal 2004-08-04 10:33:26 ----

So while we are waiting accumulating more and more unreleased bug fixes
RHSA-2004:418-01 and RHSA-2004:413-01 announce the next major hole.

Here is a quote:
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.

and kernel-2.4.9-e.48.src.rpm package includes fixes.




------- Additional Comments From michal 2004-08-04 14:00:20 ----

Created an attachment (id=791)
"synchronization" patch with RHEL 2.4 kernels

This series of patches to kernel-2.4.20-35.7.legacy.src.rpm is supposed to
bring it on the same "fix-level" as kernel-2.4.9-e.48.src.rpm.	They should
be really independent.	OTOH be careful.  At this moment they were not even
compiled and only worked trough with 'patch' and an editor.  It is possible
that I made some mistakes in this work although I tried not to.

This patch roughly synchronizes 2.4.20-35.7 with RHEL kernel.  At least some
of its components look to me like obvious bug fixes.



------- Additional Comments From michal 2004-08-04 14:04:28 ----

Created an attachment (id=792)
presumed fixes for CAN-2004-0415

At least parts of what I understand fixes this bug in kernel-2.4.9-e.48.src.rpm

were already in kernel-2.4.20-35.7.legacy.src.rpm.  Check if I not missed
something.



------- Additional Comments From michal 2004-08-04 14:06:14 ----

Created an attachment (id=793)
"clean memory in e1000" patch - fix for CAN-2004-0535




------- Additional Comments From michal 2004-08-04 14:08:04 ----

Created an attachment (id=794)
fix for wrong permissions in /proc for qla2200 - CAN-2004-0587




------- Additional Comments From marcdeslauriers 2004-08-04 16:11:19 ----

Stuff more recent than kernel-2.4.20-35.7.legacy.src.rpm should go in bug 1804.

There is already work on newer patches there.



------- Additional Comments From michal 2004-08-04 17:46:44 ----

I am sory about wrong bug number.  With all this stuff hanging I got confused.



------- Additional Comments From jp107.ac.uk 2004-08-05 07:11:33 ----

According to http://bugzilla.fedora.us/bug_status.html this bugs status should
have changed to RESOLVED when we started QA on the package, to VERIFIED once we
have a testing update and CLOSED once the update is final.  

I'd guess that this should currently be in VERIFIED until -35 makes it into the
updates/ tree.  I can't see how to do that with the interface I see though...

What actually is the procedure for moving from updates-testing/ to updates/ ? 
I'm sure it Is documented somewhere but I'm too lazy to look :-)




------- Additional Comments From jp107.ac.uk 2004-08-19 12:16:42 ----

Feel free to change the status back if I've mis-read the rules above...



------- Additional Comments From jpdalbec 2004-08-20 16:31:12 ----

69b1d6b71d42089527c6d723bb330fef i386/kernel-2.4.20-35.7.legacy.i386.rpm
is missing from updates-testing.



------- Additional Comments From dom 2004-09-07 12:20:28 ----

Bug reopened based on missing file as reported above



------- Additional Comments From mgb 2004-09-07 16:25:05 ----

Can we roll -35.9.legacy out of updates-testing so other packagers (e.g.
kernel-ntfs) can pick it up.  We're running it on 20 systems now.



------- Bug moved to this database by dkl 2005-03-30 18:24 -------

This bug previously known as bug 1484 at https://bugzilla.fedora.us/
https://bugzilla.fedora.us/show_bug.cgi?id=1484
Originally filed under the Fedora Legacy product and Package request component.

Attachments:
Patch for recent MS_FILTER vulnerability
https://bugzilla.fedora.us/attachment.cgi?action=view&id=634
clearsigned diff -urN between -31.9 and -32.7.legacy
https://bugzilla.fedora.us/attachment.cgi?action=view&id=677
clearsigned diff -urN between -31.9 and -32.9.legacy
https://bugzilla.fedora.us/attachment.cgi?action=view&id=678
"synchronization" patch with RHEL 2.4 kernels
https://bugzilla.fedora.us/attachment.cgi?action=view&id=791
presumed fixes for CAN-2004-0415
https://bugzilla.fedora.us/attachment.cgi?action=view&id=792
"clean memory in e1000" patch - fix for CAN-2004-0535
https://bugzilla.fedora.us/attachment.cgi?action=view&id=793
fix for wrong permissions in /proc for qla2200 - CAN-2004-0587
https://bugzilla.fedora.us/attachment.cgi?action=view&id=794

Unknown priority P2. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Unknown severity critical. Setting to default severity "normal".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.