[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel security bug #307900

On Sun, Jun 05, 2005 at 12:22:07PM +1000, Brian May wrote:
> Whats the deal with bug #307900?

> As far as I can tell from reading the bug report, the bug has not been
> fixed in sarge, will not be fixed for the release, but the bug has
> been closed.

kernel-source-2.6.8 2.6.8-15 has been in testing for some time now.

kernel-image packages built against 2.6.8-16 are available in sarge for the
past week or so for i386, alpha, and ia64.

kernel-image packages built against 2.6.8-15 are also available in sarge for
sparc; the amd64 kernels for the i386 architecture are also built against
this revision.  There are further security fixes in -16, so these images
should be rebuilt, but they include the fix for 307900.

Fixed kernel-image packages were not available for the other architectures
prior to the freeze, so will need to be handled via security.debian.org.
However, AIUI the exploit that exists in the wild for this hole is
i386-specific (please correct me if I'm wrong).

In light of the announcement at the beginning of May that sarge is
security-supported, I think it would be a good idea for any DSAs issued over
these holes to include mention of the relevant kernel versions for i386
etc., so that users who have upgraded earlier know that they need to upgrade
and reboot.

Most of the architectures that are still shipping unfixed 2.6.8 kernels in
sarge are outside the purview of the kernel team AIUI, so it may take a bit
of time to get packages synced up for a DSA.

> Have we come to the point where making a release is more important
> then fixing known security bugs?

What is known is that new security holes that affect sarge have been
appearing on a roughly weekly basis, and new security holes affecting the
kernel are being reported on a roughly monthly basis.  You can't get to a
release with no known security holes using those kinds of numbers; you can
pick and choose *which* security fixes you think are important enough to
wait on, but we just don't have the kind of turnaround on fixes to be able
to foresee a point where we can say that no package, anywhere in sarge, has
a known security hole.

> Does this mean people who want secure pre-compiled kernels have to
> resort to unstable until the issue is fixed?

Currently, unstable is in the same state as sarge wrt kernel security.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: