linux/net/ipv6, branch v2.6.16.54

[IPV6]: MSG_ERRQUEUE messages do not pass to connected raw sockets

2007-07-22T16:29:30Z

Taken from http://bugzilla.kernel.org/show_bug.cgi?id=8747 Problem Description: It is related to the possibility to obtain MSG_ERRQUEUE messages from the udp and raw sockets, both connected and unconnected. There is a little typo in net/ipv6/icmp.c code, which prevents such messages to be delivered to the errqueue of the correspond raw socket, when the socket is CONNECTED. The typo is due to swap of local/remote addresses. Consider __raw_v6_lookup() function from net/ipv6/raw.c. When a raw socket is looked up usual way, it is something like: sk = __raw_v6_lookup(sk, nexthdr, daddr, saddr, IP6CB(skb)->iif); where "daddr" is a destination address of the incoming packet (IOW our local address), "saddr" is a source address of the incoming packet (the remote end). But when the raw socket is looked up for some icmp error report, in net/ipv6/icmp.c:icmpv6_notify() , daddr/saddr are obtained from the echoed fragment of the "bad" packet, i.e. "daddr" is the original destination address of that packet, "saddr" is our local address. Hence, for icmpv6_notify() must use "saddr, daddr" in its arguments, not "daddr, saddr" ... Steps to reproduce: Create some raw socket, connect it to an address, and cause some error situation: f.e. set ttl=1 where the remote address is more than 1 hop to reach. Set IPV6_RECVERR . Then send something and wait for the error (f.e. poll() with POLLERR|POLLIN). You should receive "time exceeded" icmp message (because of "ttl=1"), but the socket do not receive it. If you do not connect your raw socket, you will receive MSG_ERRQUEUE successfully. (The reason is that for unconnected socket there are no actual checks for local/remote addresses). Signed-off-by: Andrew Morton Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[IPV6]: Reverse sense of promisc tests in ip6_mc_input

2007-05-22T23:01:53Z

Reverse the sense of the promiscuous-mode tests in ip6_mc_input(). Signed-off-by: Corey Mutter Signed-off-by: David L Stevens Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[IPV6]: Send ICMPv6 error on scope violations.

2007-05-22T22:55:49Z

When an IPv6 router is forwarding a packet with a link-local scope source address off-link, RFC 4007 requires it to send an ICMPv6 destination unreachable with code 2 ("not neighbor"), but Linux doesn't. Fix below. Signed-off-by: David L Stevens Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[IPV6]: Track device renames in snmp6.

2007-05-22T22:39:52Z

When network device's are renamed, the IPV6 snmp6 code gets confused. It doesn't track name changes so it will OOPS when network device's are removed. The fix is trivial, just unregister/re-register in notify handler. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[IPV6]: Fix slab corruption running ip6sic

2007-05-22T22:38:17Z

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

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

2007-04-30T23:31:47Z

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:26Z

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:44Z

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:06Z

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:33Z

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