Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow

Jon Peatfield J.S.Peatfield at damtp.cam.ac.uk
Fri Jul 2 15:58:02 UTC 2004


I didn't follow-up to the list earlier 'cos I hoped that people would
take it as fairly obvious that I also don't think that should delay
release of the 2.4.20-35.x.legacy update kernels (and I even said so
in the bugzilla for 1804).

None of the "obvious" tests I carried out with the existing nfs server
code allowed me to chgrp a file I didn't own, so I'm not exactly sure
under what circumstances the is actually exploitable anyway (maybe it
needs root-squash turning off or something, in which case it would
only affect hosts you nfs export (rw) to which are untrustworthy).

Does anyone actually know the circumstances which can trigger a
problem?

[ I now have built (one) RH9 kernel with the fchown fix and am running
it on a test box... ]

Maybe now would be a good time to start thinking about moving (in a
few months maybe) to a kernel tree based on 2.4.26/27pre just to
reduce the total number of overlapping patches.

Now that 2.4 is firmly in "maintenance mode" there won't be any new
features added so it should be possible to remove a great number of
the existing patches just by using a more modern starting point.

e.g. the number of patches in fc1 (based on 2.4.22) is ~106 while we
have ~182 in 2.4.20-35.x.legacy

Of course without understanding what _all_ of the patches are doing it
is always a bit risky to decide which would still need to stay or be
changed to be relevant against 2.4.26/27...

Currently RedHat (etc) are maintaining kernels based on:

  RHEL 2.1        2.4.9
  RHEL 3          2.4.21

Fedora are maintaining 2.4.22 for fc1 

and we have 2.4.20 for RH73/80/9 etc.

Wouldn't it make sense to produce a srpm which would be usable for all
these systems once fc1 stops being maintained by Fedora?

[ I know this will be a lot of work of course! ]

 -- Jon





More information about the fedora-legacy-list mailing list