linux-toradex.git/include/net, branch v2.6.32.15

mac80211: Retry null data frame for power save

2010-04-01T22:58:52+00:00

commit 375177bf35efc08e1bd37bbda4cc0c8cc4db8500 upstream.

Even if the null data frame is not acked by the AP, mac80211
goes into power save. This might lead to loss of frames
from the AP.
Prevent this by restarting dynamic_ps_timer when ack is not
received for null data frames.

Cc: Johannes Berg 
Signed-off-by: Vivek Natarajan 
Signed-off-by: John W. Linville 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_conntrack: fix hash resizing with namespaces

2010-02-23T15:37:53+00:00

commit d696c7bdaa55e2208e56c6f98e6bc1599f34286d upstream.

As noticed by Jon Masters , the conntrack hash
size is global and not per namespace, but modifiable at runtime through
/sys/module/nf_conntrack/hashsize. Changing the hash size will only
resize the hash in the current namespace however, so other namespaces
will use an invalid hash size. This can cause crashes when enlarging
the hashsize, or false negative lookups when shrinking it.

Move the hash size into the per-namespace data and only use the global
hash size to initialize the per-namespace value when instanciating a
new namespace. Additionally restrict hash resizing to init_net for
now as other namespaces are not handled currently.

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

netfilter: nf_conntrack: per netns nf_conntrack_cachep

2010-02-23T15:37:53+00:00

commit 5b3501faa8741d50617ce4191c20061c6ef36cb3 upstream.

nf_conntrack_cachep is currently shared by all netns instances, but
because of SLAB_DESTROY_BY_RCU special semantics, this is wrong.

If we use a shared slab cache, one object can instantly flight between
one hash table (netns ONE) to another one (netns TWO), and concurrent
reader (doing a lookup in netns ONE, 'finding' an object of netns TWO)
can be fooled without notice, because no RCU grace period has to be
observed between object freeing and its reuse.

We dont have this problem with UDP/TCP slab caches because TCP/UDP
hashtables are global to the machine (and each object has a pointer to
its netns).

If we use per netns conntrack hash tables, we also *must* use per netns
conntrack slab caches, to guarantee an object can not escape from one
namespace to another one.

Signed-off-by: Eric Dumazet 
[Patrick: added unique slab name allocation]
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

ax25: netrom: rose: Fix timer oopses

2010-02-09T12:50:56+00:00

[ Upstream commit d00c362f1b0ff54161e0a42b4554ac621a9ef92d ]

Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can
cause timer oopses (first reported with 2.6.29.6 kernel).

Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14905

Reported-by: Bernard Pidoux 
Tested-by: Bernard Pidoux 
Signed-off-by: Jarek Poplawski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netfilter: fix crashes in bridge netfilter caused by fragment jumps

2010-01-06T23:04:40+00:00

commit 8fa9ff6849bb86c59cc2ea9faadf3cb2d5223497 upstream.

When fragments from bridge netfilter are passed to IPv4 or IPv6 conntrack
and a reassembly queue with the same fragment key already exists from
reassembling a similar packet received on a different device (f.i. with
multicasted fragments), the reassembled packet might continue on a different
codepath than where the head fragment originated. This can cause crashes
in bridge netfilter when a fragment received on a non-bridge device (and
thus with skb->nf_bridge == NULL) continues through the bridge netfilter
code.

Add a new reassembly identifier for packets originating from bridge
netfilter and use it to put those packets in insolated queues.

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14805

Reported-and-Tested-by: Chong Qiao 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

ipv6: reassembly: use seperate reassembly queues for conntrack and local delivery

2010-01-06T23:04:39+00:00

commit 0b5ccb2ee250136dd7385b1c7da28417d0d4d32d upstream.

Currently the same reassembly queue might be used for packets reassembled
by conntrack in different positions in the stack (PREROUTING/LOCAL_OUT),
as well as local delivery. This can cause "packet jumps" when the fragment
completing a reassembled packet is queued from a different position in the
stack than the previous ones.

Add a "user" identifier to the reassembly queue key to seperate the queues
of each caller, similar to what we do for IPv4.

Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

tcp: Stalling connections: Fix timeout calculation routine

2009-12-18T22:05:05+00:00

[ Upstream commit 07f29bc5bbae4e53e982ab956fed7207990a7786 ]

This patch fixes a problem in the TCP connection timeout calculation.
Currently, timeout decisions are made on the basis of the current
tcp_time_stamp and retrans_stamp, which is usually set at the first
retransmission.
However, if the retransmission fails in tcp_retransmit_skb(),
retrans_stamp is not updated and remains zero. This leads to wrong
decisions in retransmits_timed_out() if tcp_time_stamp is larger than
the specified timeout, which is very likely.
In this case, the TCP connection dies after the first attempted
(and unsuccessful) retransmission.

With this patch, tcp_skb_cb->when is used instead, when retrans_stamp
is not available.

This bug has been introduced together with retransmits_timed_out() in
2.6.32, as the number of retransmissions has been used for timeout
decisions before. The corresponding commit was
6fa12c85031485dff38ce550c24f10da23b0adaa (Revert Backoff [v3]:
Calculate TCP's connection close threshold as a time value.).

Thanks to Ilpo Järvinen for code suggestions and Frederic Leroy for
testing.

Reported-by: Frederic Leroy 
Signed-off-by: Damian Lukowski 
Acked-by: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'security' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6

2009-12-01T00:47:16+00:00

* 'security' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6:
  mac80211: fix spurious delBA handling
  mac80211: fix two remote exploits

mac80211: fix spurious delBA handling

2009-11-30T18:55:51+00:00

Lennert Buytenhek noticed that delBA handling in mac80211
was broken and has remotely triggerable problems, some of
which are due to some code shuffling I did that ended up
changing the order in which things were done -- this was

  commit d75636ef9c1af224f1097941879d5a8db7cd04e5
  Author: Johannes Berg 
  Date:   Tue Feb 10 21:25:53 2009 +0100

    mac80211: RX aggregation: clean up stop session

and other parts were already present in the original

  commit d92684e66091c0f0101819619b315b4bb8b5bcc5
  Author: Ron Rindjunsky 
  Date:   Mon Jan 28 14:07:22 2008 +0200

      mac80211: A-MPDU Tx add delBA from recipient support

The first problem is that I moved a BUG_ON before various
checks -- thereby making it possible to hit. As the comment
indicates, the BUG_ON can be removed since the ampdu_action
callback must already exist when the state is != IDLE.

The second problem isn't easily exploitable but there's a
race condition due to unconditionally setting the state to
OPERATIONAL when a delBA frame is received, even when no
aggregation session was ever initiated. All the drivers
accept stopping the session even then, but that opens a
race window where crashes could happen before the driver
accepts it. Right now, a WARN_ON may happen with non-HT
drivers, while the race opens only for HT drivers.

For this case, there are two things necessary to fix it:
 1) don't process spurious delBA frames, and be more careful
    about the session state; don't drop the lock

 2) HT drivers need to be prepared to handle a session stop
    even before the session was really started -- this is
    true for all drivers (that support aggregation) but
    iwlwifi which can be fixed easily. The other HT drivers
    (ath9k and ar9170) are behaving properly already.

Reported-by: Lennert Buytenhek 
Cc: stable@kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

sctp: on T3_RTX retransmit all the in-flight chunks

2009-11-29T08:14:02+00:00

When retransmitting due to T3 timeout, retransmit all the
in-flight chunks for the corresponding  transport/path, including
chunks sent less then 1 rto ago.
This is the correct behaviour according to rfc4960 section 6.3.3
E3 and
"Note: Any DATA chunks that were sent to the address for which the
 T3-rtx timer expired but did not fit in one MTU (rule E3 above)
 should be marked for retransmission and sent as soon as cwnd
 allows (normally, when a SACK arrives). ".

This fixes problems when more then one path is present and the T3
retransmission of the first chunk that timeouts stops the T3 timer
for the initial active path, leaving all the other in-flight
chunks waiting forever or until a new chunk is transmitted on the
same path and timeouts (and this will happen only if the cwnd
allows sending new chunks, but since cwnd was dropped to MTU by
the timeout => it will wait until the first heartbeat).

Example: 10 packets in flight, sent at 0.1 s intervals on the
primary path. The primary path is down and the first packet
timeouts. The first packet is retransmitted on another path, the
T3 timer for the primary path is stopped and cwnd is set to MTU.
All the other 9 in-flight packets will not be retransmitted
(unless more new packets are sent on the primary path which depend
on cwnd allowing it, and even in this case the 9 packets will be
retransmitted only after a new packet timeouts which even in the
best case would be more then RTO).

This commit reverts d0ce92910bc04e107b2f3f2048f07e94f570035d and
also removes the now unused transport->last_rto, introduced in
 b6157d8e03e1e780660a328f7183bcbfa4a93a19.

p.s  The problem is not only when multiple paths are there.  It
can happen in a single homed environment.  If the application
stops sending data, it possible to have a hung association.

Signed-off-by: Andrei Pelinescu-Onciul 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller