Re: CAN-2005-0449
On Tue, Mar 22, 2005 at 11:01:04AM +0100, Florian Weimer wrote:
> The changelog entry for CAN-2005-0449 (in kernel-source-2.6.8) reads:
>
> * ipv4-fragment-queues-1.dpatch, ipv4-fragment-queues-2.dpatch,
> ipv4-fragment-queues-3.dpatch, ipv4-fragment-queues-4.dpatch:
> fix potential information leak by making fragment queues private.
> CAN-2005-0449 (Joshua Kwan, Simon Horman)
>
> However, the CVE entry describes a different problem:
>
> | The netfilter/iptables module in Linux before 2.6.8.1 allows remote
> | attackers to cause a denial of service (kernel crash) or bypass
> | firewall rules via crafted packets, which are not properly handled
> | by the skb_checksum_help function.
>
> Which one is correct?
These patches were grouped together as they touch similar parts of
code, but further analysis has showed that they actually fix several
different bugs.
Here is my reading of the sitiation.
ipv4-fragment-queues-1.dpatch:
Fix theoretical loop on SMP in ip_evictor().
I do not believe there is a CAN number for this.
It is not related to patches -2, -3 and -4
ipv4-fragment-queues-2.dpatch:
Flush fragment queue on conntrack unload.
This fixes a kernel crash when conntrack is unloaded.
I do not believe there is a CAN number for this.
ipv4-fragment-queues-3.dpatch:
Makes the fragment queues private, which resolves the
problem described by CAN-2005-0449.
This touches some of the same code as ipv4-fragment-queues-2.dpatch.
For more information see
http://oss.sgi.com/archives/netdev/2005-01/msg01048.html
ipv4-fragment-queues-4.dpatch:
Extra fix for CAN-2005-0449 for some code that
has been removed upstream but is still present
in kernel-source-2.4.27 and kernel-source-2.6.8.
ipv4-fragment-queues-3.dpatch, and ipv4-fragment-queues-4.dpatch
have been rolled back in kernel-souce-2.6.8-15 as they cause
an ABI change and this requires coordination with the d-i
team, which takes a bit of time.
Note that the fix for CAN-2005-0209 is also related
to the fragmentation code and discussed in the same
thread on netdev. For reference its fix is here:
http://oss.sgi.com/archives/netdev/2005-01/msg01072.html
--
Horms
Reply to: