linux.git/net/ipv4, branch v2.6.17

[IPV4]: Increment ipInHdrErrors when TTL expires.

2006-06-12T20:09:59+00:00

Signed-off-by: Weidong 
Signed-off-by: David S. Miller

[TCP]: continued: reno sacked_out count fix

2006-06-12T04:18:56+00:00

From: Aki M Nyrhinen 

IMHO the current fix to the problem (in_flight underflow in reno)
is incorrect.  it treats the symptons but ignores the problem. the
problem is timing out packets other than the head packet when we
don't have sack. i try to explain (sorry if explaining the obvious).

with sack, scanning the retransmit queue for timed out packets is
fine because we know which packets in our retransmit queue have been
acked by the receiver.

without sack, we know only how many packets in our retransmit queue the
receiver has acknowledged, but no idea which packets.

think of a "typical" slow-start overshoot case, where for example
every third packet in a window get lost because a router buffer gets
full.

with sack, we check for timeouts on those every third packet (as the
rest have been sacked). the packet counting works out and if there
is no reordering, we'll retransmit exactly the packets that were 
lost.

without sack, however, we check for timeout on every packet and end up
retransmitting consecutive packets in the retransmit queue. in our
slow-start example, 2/3 of those retransmissions are unnecessary. these
unnecessary retransmissions eat the congestion window and evetually
prevent fast recovery from continuing, if enough packets were lost.

Signed-off-by: David S. Miller

[TCP]: Avoid skb_pull if possible when trimming head

2006-06-05T22:03:37+00:00

Trimming the head of an skb by calling skb_pull can cause the packet
to become unaligned if the length pulled is odd.  Since the length is
entirely arbitrary for a FIN packet carrying data, this is actually
quite common.

Unaligned data is not the end of the world, but we should avoid it if
it's easily done.  In this case it is trivial.  Since we're discarding
all of the head data it doesn't matter whether we move skb->data forward
or back.

However, it is still possible to have unaligned skb->data in general.
So network drivers should be prepared to handle it instead of crashing.

This patch also adds an unlikely marking on len < headlen since partial
ACKs on head data are extremely rare in the wild.  As the return value
of __pskb_trim_head is no longer ever NULL that has been removed.

Signed-off-by: Herbert Xu ~{PmV>HI~} 
Signed-off-by: David S. Miller

[TCP] tcp_highspeed: Fix problem observed by Xiaoliang (David) Wei

2006-06-03T00:51:08+00:00

When snd_cwnd is smaller than 38 and the connection is in
congestion avoidance phase (snd_cwnd > snd_ssthresh), the snd_cwnd
seems to stop growing.

The additive increase was confused because C array's are 0 based.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller

[NETFILTER]: PPTP helper: fix sstate/cstate typo

2006-05-29T05:51:05+00:00

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

[NETFILTER]: mark H.323 helper experimental

2006-05-29T05:50:40+00:00

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

[NETFILTER]: Fix small information leak in SO_ORIGINAL_DST (CVE-2006-1343)

2006-05-29T05:50:18+00:00

It appears that sockaddr_in.sin_zero is not zeroed during
getsockopt(...SO_ORIGINAL_DST...) operation. This can lead
to an information leak (CVE-2006-1343).

Signed-off-by: Marcel Holtmann 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

[NETFILTER]: SNMP NAT: fix memleak in snmp_object_decode

2006-05-23T22:15:13+00:00

If kmalloc fails, error path leaks data allocated from asn1_oid_decode().

Signed-off-by: Chris Wright 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

[NETFILTER]: H.323 helper: fix sequence extension parsing

2006-05-23T22:15:10+00:00

When parsing unknown sequence extensions the "son"-pointer points behind
the last known extension for this type, don't try to interpret it.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

[NETFILTER]: H.323 helper: fix parser error propagation

2006-05-23T22:15:08+00:00

The condition "> H323_ERROR_STOP" can never be true since H323_ERROR_STOP
is positive and is the highest possible return code, while real errors are
negative, fix the checks. Also only abort on real errors in some spots
that were just interpreting any return value != 0 as error.

Fixes crashes caused by use of stale data after a parsing error occured:

BUG: unable to handle kernel paging request at virtual address bfffffff
 printing eip:
c01aa0f8
*pde = 1a801067
*pte = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: ip_nat_h323 ip_conntrack_h323 nfsd exportfs sch_sfq sch_red cls_fw sch_hfsc  xt_length ipt_owner xt_MARK iptable_mangle nfs lockd sunrpc pppoe pppoxx
CPU:    0
EIP:    0060:[]    Not tainted VLI
EFLAGS: 00210646   (2.6.17-rc4 #8)
EIP is at memmove+0x19/0x22
eax: d77264e9   ebx: d77264e9   ecx: e88d9b17   edx: d77264e9
esi: bfffffff   edi: bfffffff   ebp: de6a7680   esp: c0349db8
ds: 007b   es: 007b   ss: 0068
Process asterisk (pid: 3765, threadinfo=c0349000 task=da068540)
Stack: <0>00000006 c0349e5e d77264e3 e09a2b4e e09a38a0 d7726052 d7726124 00000491
       00000006 00000006 00000006 00000491 de6a7680 d772601e d7726032 c0349f74
       e09a2dc2 00000006 c0349e5e 00000006 00000000 d76dda28 00000491 c0349f74
Call Trace:
 [] mangle_contents+0x62/0xfe [ip_nat]
 [] ip_nat_mangle_tcp_packet+0xa1/0x191 [ip_nat]
 [] set_addr+0x74/0x14c [ip_nat_h323]
 [] process_setup+0x11b/0x29e [ip_conntrack_h323]
 [] process_setup+0x14c/0x29e [ip_conntrack_h323]
 [] process_q931+0x3c/0x142 [ip_conntrack_h323]
 [] q931_help+0xe0/0x144 [ip_conntrack_h323]
...

Found by the PROTOS c07-h2250v4 testsuite.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller