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

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

2007-08-25T15:24:17+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 
Cc: Marcus Meissner 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

[PATCH] Fix TCP IPV6 MD5 bug.

2007-08-25T15:24:01+00:00

[TCPv6] MD5SIG: Ensure to reset allocation count to avoid panic.

After clearing all passwords for IPv6 peers, we need to
set allocation count to zero as well as we free the storage.
Otherwise, we panic when a user trys to (re)add a password.

Discovered and fixed by MIYAJIMA Mitsuharu .

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

[PATCH] Fix ipv6 link down handling.

2007-08-25T15:23:59+00:00

[IPV6]: Call inet6addr_chain notifiers on link down

Currently if the link is brought down via ip link or ifconfig down,
the inet6addr_chain notifiers are not called even though all
the addresses are removed from the interface.  This caused SCTP
to add duplicate addresses to it's list.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

[PATCH] Fix error queue socket lookup in ipv6

2007-08-25T15:23:59+00:00

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

From: Dmitry Butskoy 

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: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

[PATCH] IPV6 ROUTE: No longer handle ::/0 specially.

2007-06-11T18:37:14+00:00

We do not need to handle ::/0 routes specially any longer.
This should fix BUG #8349.

Signed-off-by: YOSHIFUJI Hideaki 
Acked-by: Yuji Sekiya 
Signed-off-by: David S. Miller 
[chrisw: backport to 2.6.20]
Signed-off-by: Chris Wright

[PATCH] IPSEC: Fix panic when using inter address familiy IPsec on loopback.

2007-06-11T18:37:12+00:00

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

[PATCH] pv6: track device renames in snmp6

2007-06-11T18:37:07+00:00

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: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

IPV6: Fix for RT0 header ipv6 change.

2007-04-27T21:26:22+00:00

[IPV6]: Fix thinko in ipv6_rthdr_rcv() changes.

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

[PATCH] IPV6: Disallow RH0 by default.

2007-04-26T05:06:33+00:00

[IPV6]: Disallow RH0 by default.

A security issue is emerging.  Disallow Routing Header Type 0 by default
as we have been doing for IPv4.
Note: We allow RH2 by default because it is harmless.

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix length validation in rawv6_sendmsg()

2007-04-13T20:47:04+00:00

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

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