linux-toradex.git/net/ipv6, branch v2.6.16.51

[IPV6]: Disallow RH0 by default (CVE-2007-2242)

2007-04-30T23:31:47+00:00

A security issue is emerging.  Disallow Routing Header Type 0 by default
as we have been doing for IPv4.

This version already includes a fix for the original patch.

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: Adrian Bunk

[IPv6]: Fix incorrect length check in rawv6_sendmsg()

2007-04-13T20:58:26+00:00

In article <20070329.142644.70222545.davem@davemloft.net> (at Thu, 29 Mar 2007 14:26:44 -0700 (PDT)), David Miller  says:

> From: Sridhar Samudrala 
> Date: Thu, 29 Mar 2007 14:17:28 -0700
>
> > The check for length in rawv6_sendmsg() is incorrect.
> > As len is an unsigned int, (len < 0) will never be TRUE.
> > I think checking for IPV6_MAXPLEN(65535) is better.
> >
> > Is it possible to send ipv6 jumbo packets using raw
> > sockets? If so, we can remove this check.
>
> I don't see why such a limitation against jumbo would exist,
> does anyone else?
>
> Thanks for catching this Sridhar.  A good compiler should simply
> fail to compile "if (x < 0)" when 'x' is an unsigned type, don't
> you think :-)

Dave, we use "int" for returning value,
so we should fix this anyway, IMHO;
we should not allow len > INT_MAX.

Signed-off-by: YOSHIFUJI Hideaki 
Acked-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

[IPV6] HASHTABLES: Use appropriate seed for caluculating ehash index.

2007-03-28T20:04:44+00:00

Tetsuo Handa  told me that connect(2) with TCPv6
socket almost always took a few minutes to return when we did not have any
ports available in the range of net.ipv4.ip_local_port_range.

The reason was that we used incorrect seed for calculating index of
hash when we check established sockets in __inet6_check_established().

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

[NETFILTER]: nf_conntrack: fix incorrect classification of IPv6 fragments as ESTABLISHED

2007-03-24T20:30:06+00:00

The individual fragments of a packet reassembled by conntrack have the
conntrack reference from the reassembled packet attached, but nfctinfo
is not copied. This leaves it initialized to 0, which unfortunately is
the value of IP_CT_ESTABLISHED.

The result is that all IPv6 fragments are tracked as ESTABLISHED,
allowing them to bypass a usual ruleset which accepts ESTABLISHED
packets early.

Signed-off-by: Patrick McHardy 
Signed-off-by: Adrian Bunk

NETFILTER: nf_conntrack_ipv6: fix crash when handling fragments

2007-03-24T20:22:33+00:00

When IPv6 connection tracking splits up a defragmented packet into
its original fragments, the packets are taken from a list and are
passed to the network stack with skb->next still set. This causes
dev_hard_start_xmit to treat them as GSO fragments, resulting in
a use after free when connection tracking handles the next fragment.

Signed-off-by: Patrick McHardy 
Signed-off-by: Adrian Bunk

[IPV6]: ipv6_fl_socklist is inadvertently shared.

2007-03-20T22:23:13+00:00

The ipv6_fl_socklist from listening socket is inadvertently shared
with new socket created for connection.  This leads to a variety of
interesting, but fatal, bugs. For example, removing one of the
sockets may lead to the other socket's encountering a page fault
when the now freed list is referenced.

The fix is to not share the flow label list with the new socket.

Signed-off-by: Masayuki Nakagawa 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

[IPV6] fix ipv6_getsockopt_sticky copy_to_user leak

2007-03-11T06:43:46+00:00

User supplied len < 0 can cause leak of kernel memory.
Use unsigned compare instead.

Signed-off-by: Chris Wright 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

[IPV6]: Fix for ipv6_setsockopt NULL dereference

2007-03-11T06:42:33+00:00

I came across this bug in http://bugzilla.kernel.org/show_bug.cgi?id=8155

Signed-off-by: Olaf Kirch 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

[IPV6]: Handle np->opt being NULL in ipv6_getsockopt_sticky(). (CVE-2007-1000)

2007-03-09T06:15:40+00:00

Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

[IPV6]: /proc/net/anycast6 unbalanced inet6_dev refcnt

2007-03-08T07:40:07+00:00

Reading /proc/net/anycast6 when there is no anycast address
on an interface results in an ever-increasing inet6_dev reference
count, as well as a reference to the netdevice you can't get rid of.

Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk