linux.git/net/ipv6, branch v2.6.12

[IPv6] Don't generate temporary for TUN devices

2005-06-13T22:01:34+00:00

Userland layer-2 tunneling devices allocated through the TUNTAP driver 
(drivers/net/tun.c) have a type of ARPHRD_NONE, and have no link-layer 
address. The kernel complains at regular interval when IPv6 Privacy 
extension are enabled because it can't find an hardware address :

Dec 29 11:02:04 auguste kernel: __ipv6_regen_rndid(idev=cb3e0c00): 
cannot get EUI64 identifier; use random bytes.

IPv6 Privacy extensions should probably be disabled on that sort of 
device. They won't work anyway. If userland wants a more usual 
Ethernet-ish interface with usual IPv6 autoconfiguration, it will use a 
TAP device with an emulated link-layer  and a random hardware address 
rather than a TUN device.

As far as I could fine, TUN virtual device from TUNTAP is the very only 
sort of device using ARPHRD_NONE as kernel device type.

Signed-off-by: R�mi Denis-Courmont 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

[IPV6]: Ensure to use icmpv6_socket in non-preemptive context.

2005-06-13T21:59:44+00:00

We saw following trace several times:

|BUG: using smp_processor_id() in preemptible [00000001] code: httpd/30137
|caller is icmpv6_send+0x23/0x540
| [] smp_processor_id+0x9b/0xb8
| [] icmpv6_send+0x23/0x540

This is because of icmpv6_socket, which is the only one user of
smp_processor_id() in icmpv6_send(), AFAIK.

Since it should be used in non-preemptive context,
let's defer the dereference after disabling preemption
(by icmpv6_xmit_lock()).

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

[IPV6]: Update parm.link in ip6ip6_tnl_change()

2005-06-08T21:54:38+00:00

Signed-off-by: Gabor Fekete 
Signed-off-by: David S. Miller

[IPV6]: Kill export of fl6_sock_lookup.

2005-06-02T20:06:36+00:00

There is no usage of this EXPORT_SYMBOL in the kernel.

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

[IPV6]: Clear up user copy warning in flowlabel code.

2005-05-30T03:28:01+00:00

We are intentionally ignoring the copy_to_user() value,
make it clear to the compiler too.

Noted by Jeff Garzik.

Signed-off-by: David S. Miller

From: Kazunori Miyazawa

2005-05-26T19:58:04+00:00

[XFRM] Call dst_check() with appropriate cookie

This fixes infinite loop issue with IPv6 tunnel mode.

Signed-off-by: Kazunori Miyazawa 
Signed-off-by: Hideaki YOSHIFUJI 
Signed-off-by: David S. Miller

[IPV6]: Fix xfrm tunnel oops with large packets

2005-05-23T20:11:07+00:00

Signed-off-by: Herbert Xu 
Acked-by: Hideaki YOSHIFUJI 
Signed-off-by: David S. Miller

[IPV4/IPV6] Ensure all frag_list members have NULL sk

2005-05-19T05:52:33+00:00

Having frag_list members which holds wmem of an sk leads to nightmares
with partially cloned frag skb's.  The reason is that once you unleash
a skb with a frag_list that has individual sk ownerships into the stack
you can never undo those ownerships safely as they may have been cloned
by things like netfilter.  Since we have to undo them in order to make
skb_linearize happy this approach leads to a dead-end.

So let's go the other way and make this an invariant:

	For any skb on a frag_list, skb->sk must be NULL.

That is, the socket ownership always belongs to the head skb.
It turns out that the implementation is actually pretty simple.

The above invariant is actually violated in the following patch
for a short duration inside ip_fragment.  This is OK because the
offending frag_list member is either destroyed at the end of the
slow path without being sent anywhere, or it is detached from
the frag_list before being sent.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

[IPSEC]: Store idev entries

2005-05-03T23:27:10+00:00

I found a bug that stopped IPsec/IPv6 from working.  About
a month ago IPv6 started using rt6i_idev->dev on the cached socket dst
entries.  If the cached socket dst entry is IPsec, then rt6i_idev will
be NULL.

Since we want to look at the rt6i_idev of the original route in this
case, the easiest fix is to store rt6i_idev in the IPsec dst entry just
as we do for a number of other IPv6 route attributes.  Unfortunately
this means that we need some new code to handle the references to
rt6i_idev.  That's why this patch is bigger than it would otherwise be.

I've also done the same thing for IPv4 since it is conceivable that
once these idev attributes start getting used for accounting, we
probably need to dereference them for IPv4 IPsec entries too.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller

[NETLINK]: Synchronous message processing.

2005-05-03T21:55:09+00:00

Let's recap the problem.  The current asynchronous netlink kernel
message processing is vulnerable to these attacks:

1) Hit and run: Attacker sends one or more messages and then exits
before they're processed.  This may confuse/disable the next netlink
user that gets the netlink address of the attacker since it may
receive the responses to the attacker's messages.

Proposed solutions:

a) Synchronous processing.
b) Stream mode socket.
c) Restrict/prohibit binding.

2) Starvation: Because various netlink rcv functions were written
to not return until all messages have been processed on a socket,
it is possible for these functions to execute for an arbitrarily
long period of time.  If this is successfully exploited it could
also be used to hold rtnl forever.

Proposed solutions:

a) Synchronous processing.
b) Stream mode socket.

Firstly let's cross off solution c).  It only solves the first
problem and it has user-visible impacts.  In particular, it'll
break user space applications that expect to bind or communicate
with specific netlink addresses (pid's).

So we're left with a choice of synchronous processing versus
SOCK_STREAM for netlink.

For the moment I'm sticking with the synchronous approach as
suggested by Alexey since it's simpler and I'd rather spend
my time working on other things.

However, it does have a number of deficiencies compared to the
stream mode solution:

1) User-space to user-space netlink communication is still vulnerable.

2) Inefficient use of resources.  This is especially true for rtnetlink
since the lock is shared with other users such as networking drivers.
The latter could hold the rtnl while communicating with hardware which
causes the rtnetlink user to wait when it could be doing other things.

3) It is still possible to DoS all netlink users by flooding the kernel
netlink receive queue.  The attacker simply fills the receive socket
with a single netlink message that fills up the entire queue.  The
attacker then continues to call sendmsg with the same message in a loop.

Point 3) can be countered by retransmissions in user-space code, however
it is pretty messy.

In light of these problems (in particular, point 3), we should implement
stream mode netlink at some point.  In the mean time, here is a patch
that implements synchronous processing.  

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller