linux/net/decnet, branch v2.6.13

[DECNET]: Fix RCU race condition in dn_neigh_construct().

2005-08-17T19:05:27Z

Signed-off-by: Paul E. McKenney Signed-off-by: David S. Miller

[DECNET]: Use sk_stream_error function rather than DECnet's own

2005-08-10T18:32:57Z

Signed-off-by: Steven Whitehouse Signed-off-by: David S. Miller

[NET]: move config options out to individual protocols

2005-07-12T04:13:56Z

Move the protocol specific config options out to the specific protocols. With this change net/Kconfig now starts to become readable and serve as a good basis for further re-structuring. The menu structure is left almost intact, except that indention is fixed in most cases. Most visible are the INET changes where several "depends on INET" are replaced with a single ifdef INET / endif pair. Several new files were created to accomplish this change - they are small but serve the purpose that config options are now distributed out where they belongs. Signed-off-by: Sam Ravnborg Signed-off-by: David S. Miller

[NET]: Transform skb_queue_len() binary tests into skb_queue_empty()

2005-07-08T21:57:23Z

This is part of the grand scheme to eliminate the qlen member of skb_queue_head, and subsequently remove the 'list' member of sk_buff. Most users of skb_queue_len() want to know if the queue is empty or not, and that's trivially done with skb_queue_empty() which doesn't use the skb_queue_head->qlen member and instead uses the queue list emptyness as the test. Signed-off-by: David S. Miller

[DECNET]: Fix memset overflow on 64bit archs while dumping decnet routing rules

2005-07-05T22:01:25Z

Signed-off-by: Thomas Graf Signed-off-by: David S. Miller

[DECNET]: Remove unnecessary initilization of unused variable entries

2005-06-19T05:55:02Z

This patch was supposed to be part of the neighbour tables related patchset but apparently got lost. Signed-off-by: Thomas Graf Signed-off-by: David S. Miller

[NETLINK]: Correctly set NLM_F_MULTI without checking the pid

2005-06-19T05:54:12Z

This patch rectifies some rtnetlink message builders that derive the flags from the pid. It is now explicit like the other cases which get it right. Also fixes half a dozen dumpers which did not set NLM_F_MULTI at all. Signed-off-by: Jamal Hadi Salim Signed-off-by: Thomas Graf Signed-off-by: David S. Miller

[DECNET]: Fix build after C99 netlink initializer change.

2005-05-05T20:13:29Z

Signed-off-by: Rafael J. Wysocki Signed-off-by: David S. Miller

[NETLINK]: Fix infinite loops in synchronous netlink changes.

2005-05-03T22:30:05Z

The qlen should continue to decrement, even if we pop partially processed SKBs back onto the receive queue. Signed-off-by: David S. Miller

[NETLINK]: Synchronous message processing.

2005-05-03T21:55:09Z

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