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

Fix ipv6 flow label inheritance

2007-03-23T19:49:25+00:00

[IPV6]: ipv6_fl_socklist is inadvertently shared.

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: Greg Kroah-Hartman

Fix another NULL pointer deref in ipv6_sockglue.c

2007-03-23T19:49:18+00:00

[IPV6]: Fix for ipv6_setsockopt NULL dereference

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: Greg Kroah-Hartman

nf_conntrack: fix incorrect classification of IPv6 fragments as ESTABLISHED

2007-03-13T18:26:46+00:00

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

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: Greg Kroah-Hartman

ip6_route_me_harder should take into account mark

2007-03-13T18:26:46+00:00

[NETFILTER]: ip6_route_me_harder should take into account mark

Signed-off-by: Yasuyuki Kozakai 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

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

2007-03-09T18:50:33+00:00

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8134

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

Fix anycast procfs device leak

2007-03-09T18:50:27+00:00

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

From: David Stevens 

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.

From: David Stevens 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Don't add anycast reference to device multiple times

2007-03-09T18:50:27+00:00

[IPV6]: anycast refcnt fix

This patch fixes a bug in Linux IPv6 stack which caused anycast address
to be added to a device prior DAD has been completed. This led to
incorrect reference count which resulted in infinite wait for
unregister_netdevice completion on interface removal.

Signed-off-by: Michal Wrobel 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

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

2007-03-09T18:50:21+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: Greg Kroah-Hartman

Fix allocation failure handling in multicast

2007-03-09T18:50:20+00:00

[IPV4/IPV6] multicast: Check add_grhead() return value

add_grhead() allocates memory with GFP_ATOMIC and in at least two places skb
from it passed to skb_put() without checking.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

[IPV6]: fix BUG of ndisc_send_redirect()

2007-01-30T22:33:20+00:00

  When I tested IPv6 redirect function about kernel 2.6.19.1, and found
that the kernel can send redirect packets whose target address is global
address, and the target is not the actual endpoint of communication.

  But the criteria conform to RFC2461, the target address defines as
following:

  Target Address An IP address that is a better first hop to use for
                 he ICMP Destination Address.  When the target is
                 the actual endpoint of communication, i.e., the
                 destination is a neighbor, the Target Address field
                 MUST contain the same value as the ICMP Destination
                 Address field.  Otherwise the target is a better
                 first-hop router and the Target Address MUST be the
                 router's link-local address so that hosts can
                 uniquely identify routers.

According to this definition, when a router redirect to a host, the
target address either the better first-hop router's link-local address
or the same as the ICMP destination address field. But the function of
ndisc_send_redirect() in net/ipv6/ndisc.c, does not check the target
address correctly.

There is another definition about receive Redirect message in RFC2461:

8.1.  Validation of Redirect Messages

   A host MUST silently discard any received Redirect message that does
   not satisfy all of the following validity checks:
   ......
   - The ICMP Target Address is either a link-local address (when
     redirected to a router) or the same as the ICMP Destination
     Address (when redirected to the on-link destination).
   ......

And the receive redirect function of ndisc_redirect_rcv() implemented
this definition, checks the target address correctly.
    if (ipv6_addr_equal(dest, target)) {
        on_link = 1;
    } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
        ND_PRINTK2(KERN_WARNING
               "ICMPv6 Redirect: target address is not link-local.\n");
        return;
    }

So, I think the send redirect function must check the target address
also.

Signed-off-by: Li Yewang 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller