linux-toradex.git/net/ipv4, branch v2.6.23.12

TCP: illinois: Incorrect beta usage

2007-12-14T17:51:07+00:00

[TCP] illinois: Incorrect beta usage

[ Upstream commit: a357dde9df33f28611e6a3d4f88265e39bcc8880 ]

Lachlan Andrew observed that my TCP-Illinois implementation uses the
beta value incorrectly:
The parameter  beta  in the paper specifies the amount to decrease
*by*:  that is, on loss,
 W <-  W -  beta*W
but in   tcp_illinois_ssthresh() uses  beta  as the amount
to decrease  *to*: W <- beta*W

This bug makes the Linux TCP-Illinois get less-aggressive on uncongested network,
hurting performance. Note: since the base beta value is .5, it has no
impact on a congested network.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

TCP: MTUprobe: fix potential sk_send_head corruption

2007-12-14T17:51:04+00:00

[TCP] MTUprobe: fix potential sk_send_head corruption

[ Upstream commit: 6e42141009ff18297fe19d19296738b742f861db ]

When the abstraction functions got added, conversion here was
made incorrectly. As a result, the skb may end up pointing
to skb which got included to the probe skb and then was freed.
For it to trigger, however, skb_transmit must fail sending as
well.

Signed-off-by: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Cc: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

TCP: Problem bug with sysctl_tcp_congestion_control function

2007-12-14T17:51:04+00:00

[TCP]: Problem bug with sysctl_tcp_congestion_control function

[ Upstream commit: 5487796f0c9475586277a0a7a91211ce5746fa6a ]

sysctl_tcp_congestion_control seems to have a bug that prevents it
from actually calling the tcp_set_default_congestion_control
function. This is not so apparent because it does not return an error
and generally the /proc interface is used to configure the default TCP
congestion control algorithm.  This is present in 2.6.18 onwards and
probably earlier, though I have not inspected 2.6.15--2.6.17.

sysctl_tcp_congestion_control calls sysctl_string and expects a successful
return code of 0. In such a case it actually sets the congestion control
algorithm with tcp_set_default_congestion_control. Otherwise, it returns the
value returned by sysctl_string. This was correct in 2.6.14, as sysctl_string
returned 0 on success. However, sysctl_string was updated to return 1 on
success around about 2.6.15 and sysctl_tcp_congestion_control was not updated.
Even though sysctl_tcp_congestion_control returns 1, do_sysctl_strategy
converts this return code to '0', so the caller never notices the error.

Signed-off-by: David S. Miller 
Cc: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

IPV4: Remove bogus ifdef mess in arp_process

2007-12-14T17:51:03+00:00

[IPV4]: Remove bogus ifdef mess in arp_process

[ Upstream commit: 3660019e5f96fd9a8b7d4214a96523c0bf7b676d ]

The #ifdef's in arp_process() were not only a mess, they were also wrong
in the CONFIG_NET_ETHERNET=n and (CONFIG_NETDEV_1000=y or
CONFIG_NETDEV_10000=y) cases.

Since they are not required this patch removes them.

Also removed are some #ifdef's around #include's that caused compile
errors after this change.

Signed-off-by: Adrian Bunk 
Signed-off-by: Herbert Xu 
Cc: David Miller 
Signed-off-by: Greg Kroah-Hartman

NET: Corrects a bug in ip_rt_acct_read()

2007-12-14T17:51:03+00:00

[NET]: Corrects a bug in ip_rt_acct_read()

[ Upstream commit: 483b23ffa3a5f44767038b0a676d757e0668437e ]

It seems that stats of cpu 0 are counted twice, since
for_each_possible_cpu() is looping on all possible cpus, including 0

Before percpu conversion of ip_rt_acct, we should also remove the
assumption that CPU 0 is online (or even possible)

Signed-off-by: Eric Dumazet 
Cc: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netfilter: Fix kernel panic with REDIRECT target.

2007-12-14T17:51:02+00:00

This patch fixes a NAT regression in 2.6.23, resulting in a
crash when a connection is NATed and matches a conntrack
helper after NAT.

Please apply, thanks.
[NETFILTER]: Fix kernel panic with REDIRECT target.

Upstream commit 1f305323ff5b9ddc1a4346d36072bcdb58f3f68a

When connection tracking entry (nf_conn) is about to copy itself it can
have some of its extension users (like nat) as being already freed and
thus not required to be copied.

Actually looking at this function I suspect it was copied from
nf_nat_setup_info() and thus bug was introduced.

Report and testing from David .

[ Patrick McHardy states:

        I now understand whats happening:

        - new connection is allocated without helper
        - connection is REDIRECTed to localhost
        - nf_nat_setup_info adds NAT extension, but doesn't initialize it yet
        - nf_conntrack_alter_reply performs a helper lookup based on the
           new tuple, finds the SIP helper and allocates a helper extension,
           causing reallocation because of too little space
        - nf_nat_move_storage is called with the uninitialized nat extension

        So your fix is entirely correct, thanks a lot :)  ]

Signed-off-by: Evgeniy Polyakov 
Acked-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

nf_nat: fix memset error

2007-12-14T17:51:02+00:00

This patch fixes an incorrect memset in the NAT code, causing
misbehaviour when unloading and reloading the NAT module.
Applies to stable-2.6.22 and stable-2.6.23.

Please apply, thanks.
[NETFILTER]: nf_nat: fix memset error

Upstream commit e0bf9cf15fc30d300b7fbd821c6bc975531fab44

The size passing to memset is the size of a pointer. Fixes
misbehaviour when unloading and reloading the NAT module.

Signed-off-by: Li Zefan 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

TCP: Make sure write_queue_from does not begin with NULL ptr (CVE-2007-5501)

2007-11-16T18:10:56+00:00

patch 96a2d41a3e495734b63bff4e5dd0112741b93b38 in mainline.

NULL ptr can be returned from tcp_write_queue_head to cached_skb
and then assigned to skb if packets_out was zero. Without this,
system is vulnerable to a carefully crafted ACKs which obviously
is remotely triggerable.

Besides, there's very little that needs to be done in sacktag
if there weren't any packets outstanding, just skipping the rest
doesn't hurt.

Signed-off-by: Ilpo Järvinen 
Signed-off-by: David S. Miller

Fix crypto_alloc_comp() error checking.

2007-11-16T16:27:38+00:00

[IPSEC]: Fix crypto_alloc_comp error checking

[ Upstream commit: 4999f3621f4da622e77931b3d33ada6c7083c705 ]

The function crypto_alloc_comp returns an errno instead of NULL
to indicate error.  So it needs to be tested with IS_ERR.

This is based on a patch by Vicenç Beltran Querol.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

[TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed

2007-10-08T06:43:10+00:00

When only GSO skb was partially ACKed, no hints are reset,
therefore fastpath_cnt_hint must be tweaked too or else it can
corrupt fackets_out. The corruption to occur, one must have
non-trivial ACK/SACK sequence, so this bug is not very often
that harmful. There's a fackets_out state reset in TCP because
fackets_out is known to be inaccurate and that fixes the issue
eventually anyway.

In case there was also at least one skb that got fully ACKed,
the fastpath_skb_hint is set to NULL which causes a recount for
fastpath_cnt_hint (the old value won't be accessed anymore),
thus it can safely be decremented without additional checking.

Reported by Cedric Le Goater 

Signed-off-by: Ilpo Järvinen 
Signed-off-by: David S. Miller