linux/net/ipv6/netfilter, branch v2.6.13

[NETFILTER]: Fix HW checksum handling in ip_queue/ip6_queue

2005-08-23T17:10:35Z

The checksum needs to be filled in on output, after mangling a packet ip_summed needs to be reset. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller

[NETFILTER]: Fix ip6t_LOG MAC format

2005-07-22T19:52:47Z

I broke this in the patch that consolidated MAC logging. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller

[NETFILTER]: Fix deadlock in ip6_queue

2005-07-22T19:49:30Z

Already fixed in ip_queue, ip6_queue was missed. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller

[NETFILTER]: Fix ip6t_LOG sit tunnel logging

2005-06-21T21:07:13Z

Sit tunnel logging is currently broken: MAC=01:23:45:67:89:ab->01:23:45:47:89:ac TUNNEL=123.123. 0.123-> 12.123. 6.123 Apart from the broken IP address, MAC addresses are printed differently for sit tunnels than for everything else. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller

[NETFILTER]: Missing owner-field initialization in ip6table_raw

2005-06-21T21:03:01Z

I missed this one when fixing up iptable_raw. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller

[NETFILTER]: Kill lockhelp.h

2005-06-21T21:01:30Z

Signed-off-by: Patrick McHardy 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

Linux-2.6.12-rc2

2005-04-16T22:20:36Z

Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!