Re: Preparing the first security update for kernel-source-2.6.8
On Thu, Jun 30, 2005 at 04:24:32PM -0400, Joey Hess wrote:
> Horms wrote:
> > * arch-x86_64-kernel-ptrace-canonical-rip-1.dpatch,
> > arch-x86_64-kernel-ptrace-canonical-rip-2.dpatch
> > This works around an AMD Erratum by
> > checking if the ptrace RIP is canonical.
> > (Simon Horman)
> >
> > * [SECURITY] arch-x86_64-kernel-smp-boot-race.dpatch
> > Keep interrupts disabled during smp bootup
> > This avoids a race that breaks SMP bootup on some machines.
> > (Simon Horman)
> >
> > * [SECURITY] arch-x86_64-mm-ioremap-page-lookup.dpatch
> > Don't look up struct page pointer of physical address in iounmap as it may
> > be in a memory hole not mapped in mem_map and that causes the hash lookup
> > to go off to nirvana.
> > (Simon Horman)
>
> Does anyone know what CVE ids apply to these holes? I'm guessing that
> it's some of the reserved IDs CAN-2005-1765, CAN-2005-1764,
> CAN-2005-1763, and CAN-2005-1762, but I'm not sure which fix was left
> out or which fix applies to which hole, since there's not much public
> information.
>
> Having bugs in the bts would make tracking this stuff ever so much
> easier.
Hi Joey,
I am not sure either. I think that having references, like the CAN
entry, for bugs is very important. But undfortunately CAN entries
tend to be somewhat vauge, they are rarely noted in upstream bug fixes
and sometimes they lie reserved for a long time. In short, associating
fixes with CAN entries isn't as easy as it should be. If anyone has
information that relates fixes to CAN entries, I am more than happy
to add this to the changelog.
--
Horms
Reply to: