linux/net, branch v2.6.16.44

[IPV6] fix ipv6_getsockopt_sticky copy_to_user leak

2007-03-11T06:43:46Z

User supplied len < 0 can cause leak of kernel memory. Use unsigned compare instead. Signed-off-by: Chris Wright Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[IPV6]: Fix for ipv6_setsockopt NULL dereference

2007-03-11T06:42:33Z

I came across this bug in http://bugzilla.kernel.org/show_bug.cgi?id=8155 Signed-off-by: Olaf Kirch Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[IPV6]: Handle np->opt being NULL in ipv6_getsockopt_sticky(). (CVE-2007-1000)

2007-03-09T06:15:40Z

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

[TCP]: Fix minisock tcp_create_openreq_child() typo.

2007-03-08T07:43:47Z

On 2/28/07, KOVACS Krisztian wrote: > > Hi, > > While reading TCP minisock code I've found this suspiciously looking > code fragment: > > - 8< - > struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req, struct sk_buff *skb) > { > struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC); > > if (newsk != NULL) { > const struct inet_request_sock *ireq = inet_rsk(req); > struct tcp_request_sock *treq = tcp_rsk(req); > struct inet_connection_sock *newicsk = inet_csk(sk); > struct tcp_sock *newtp; > - 8< - > > The above code initializes newicsk to inet_csk(sk), isn't that supposed > to be inet_csk(newsk)? As far as I can tell this might leave > icsk_ack.last_seg_size zero even if we do have received data. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

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

2007-03-08T07:40:07Z

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 Signed-off-by: Adrian Bunk

[IPV6]: anycast refcnt fix

2007-03-08T07:38:52Z

This patch fixes a bug in Linux IPv6 stack which caused anycast address to be added to a device prior DAD has been completed. This led to incorrect reference count which resulted in infinite wait for unregister_netdevice completion on interface removal. Signed-off-by: Michal Wrobel Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[UDP]: Reread uh pointer after pskb_trim

2007-03-08T07:21:15Z

The header may have moved when trimming. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[DECNET]: Fix sfuzz hanging on 2.6.18

2007-02-26T22:47:11Z

Dave Jones wrote: > sfuzz D 724EF62A 2828 28717 28691 (NOTLB) > cd69fe98 00000082 0000012d 724ef62a 0001971a 00000010 00000007 df6d22b0 > dfd81080 725bbc5e 0001971a 000cc634 00000001 df6d23bc c140e260 00000202 > de1d5ba0 cd69fea0 de1d5ba0 00000000 00000000 de1d5b60 de1d5b8c de1d5ba0 > Call Trace: > [] lock_sock+0x75/0xa6 > [] dn_getname+0x18/0x5f [decnet] > [] sys_getsockname+0x5c/0xb0 > [] sys_socketcall+0xef/0x261 > [] syscall_call+0x7/0xb > DWARF2 unwinder stuck at syscall_call+0x7/0xb > > I wonder if the plethora of lockdep related changes inadvertantly broke something? Looks like unbalanced locking. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[TCP]: Prevent pseudo garbage in SYN's advertized window

2007-02-26T00:36:47Z

TCP may advertize up to 16-bits window in SYN packets (no window scaling allowed). At the same time, TCP may have rcv_wnd (32-bits) that does not fit to 16-bits without window scaling resulting in pseudo garbage into advertized window from the low-order bits of rcv_wnd. This can happen at least when mss <= (1< Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[IPV4/IPV6] multicast: Check add_grhead() return value

2007-02-26T00:31:58Z

add_grhead() allocates memory with GFP_ATOMIC and in at least two places skb from it passed to skb_put() without checking. Adrian Bunk: backported to 2.6.16 Signed-off-by: Alexey Dobriyan Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk