linux-stable.git/net, branch v3.8.2

svcrpc: fix rpc server shutdown races

2013-03-03T22:03:37+00:00

commit cc630d9f476445927fca599f81182c7f06f79058 upstream.

Rewrite server shutdown to remove the assumption that there are no
longer any threads running (no longer true, for example, when shutting
down the service in one network namespace while it's still running in
others).

Do that by doing what we'd do in normal circumstances: just CLOSE each
socket, then enqueue it.

Since there may not be threads to handle the resulting queued xprts,
also run a simplified version of the svc_recv() loop run by a server to
clean up any closed xprts afterwards.

Tested-by: Jason Tibbitts 
Tested-by: Paweł Sikora 
Acked-by: Stanislav Kinsbursky 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

svcrpc: make svc_age_temp_xprts enqueue under sv_lock

2013-03-03T22:03:37+00:00

commit e75bafbff2270993926abcc31358361db74a9bc2 upstream.

svc_age_temp_xprts expires xprts in a two-step process: first it takes
the sv_lock and moves the xprts to expire off their server-wide list
(sv_tempsocks or sv_permsocks) to a local list.  Then it drops the
sv_lock and enqueues and puts each one.

I see no reason for this: svc_xprt_enqueue() will take sp_lock, but the
sv_lock and sp_lock are not otherwise nested anywhere (and documentation
at the top of this file claims it's correct to nest these with sp_lock
inside.)

Tested-by: Jason Tibbitts 
Tested-by: Paweł Sikora 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

mac80211: always unblock CSA queue stop when disconnecting

2013-02-28T13:38:41+00:00

Commit 5b36ebd8249f403c7edf7cf68d68e9a0d0f55243 upstream.

In some cases when disconnecting after (or during?) CSA
the queues might not recover, and then the only way to
recover is reloading the module.

Fix this by always unblocking the queue CSA reason when

disconnecting.

Reported-by: Jan-Michael Brummer 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

sock_diag: Fix out-of-bounds access to sock_diag_handlers[]

2013-02-28T13:38:41+00:00

[ Upstream commit 6e601a53566d84e1ffd25e7b6fe0b6894ffd79c0 ]

Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY
with a family greater or equal then AF_MAX -- the array size of
sock_diag_handlers[]. The current code does not test for this
condition therefore is vulnerable to an out-of-bound access opening
doors for a privilege escalation.

Signed-off-by: Mathias Krause 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: fix SYN-data space mis-accounting

2013-02-28T13:38:41+00:00

[ Upstream commit 1b63edd6ecc55c3a61b40297b49e2323783bddfd ]

In fast open the sender unncessarily reduces the space available
for data in SYN by 12 bytes.  This is because in the sender
incorrectly reserves space for TS option twice in tcp_send_syn_data():
tcp_mtu_to_mss() already accounts for TS option space. But it further
reserves MAX_TCP_OPTION_SPACE when computing the payload space.

Signed-off-by: Yuchung Cheng 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv4: fix error handling in icmp_protocol.

2013-02-28T13:38:41+00:00

[ Upstream commit 5b0520425e5ea81ba95ec486dd6bbb59a09fff0e ]

Now we handle icmp errors in each transport protocol's err_handler,
for icmp protocols, that is ping_err. Since this handler only care
of those icmp errors triggered by echo request, errors triggered
by echo reply(which sent by kernel) are sliently ignored.

So wrap ping_err() with icmp_err() to deal with those icmp errors.

Signed-off-by: Li Wei 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: use a stronger hash for tcp

2013-02-28T13:38:41+00:00

[ Upstream commit 08dcdbf6a7b9d14c2302c5bd0c5390ddf122f664 ]

It looks like its possible to open thousands of TCP IPv6
sessions on a server, all landing in a single slot of TCP hash
table. Incoming packets have to lookup sockets in a very
long list.

We should hash all bits from foreign IPv6 addresses, using
a salt and hash mix, not a simple XOR.

inet6_ehashfn() can also separately use the ports, instead
of xoring them.

Reported-by: Neal Cardwell 
Signed-off-by: Eric Dumazet 
Cc: Yuchung Cheng 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv4: fix a bug in ping_err().

2013-02-28T13:38:40+00:00

[ Upstream commit b531ed61a2a2a77eeb2f7c88b49aa5ec7d9880d8 ]

We should get 'type' and 'code' from the outer ICMP header.

Signed-off-by: Li Wei 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: fix race condition regarding dst->expires and dst->from.

2013-02-28T13:38:40+00:00

[ Upstream commit ecd9883724b78cc72ed92c98bcb1a46c764fff21 ]

Eric Dumazet wrote:
| Some strange crashes happen in rt6_check_expired(), with access
| to random addresses.
|
| At first glance, it looks like the RTF_EXPIRES and
| stuff added in commit 1716a96101c49186b
| (ipv6: fix problem with expired dst cache)
| are racy : same dst could be manipulated at the same time
| on different cpus.
|
| At some point, our stack believes rt->dst.from contains a dst pointer,
| while its really a jiffie value (as rt->dst.expires shares the same area
| of memory)
|
| rt6_update_expires() should be fixed, or am I missing something ?
|
| CC Neil because of https://bugzilla.redhat.com/show_bug.cgi?id=892060

Because we do not have any locks for dst_entry, we cannot change
essential structure in the entry; e.g., we cannot change reference
to other entity.

To fix this issue, split 'from' and 'expires' field in dst_entry
out of union.  Once it is 'from' is assigned in the constructor,
keep the reference until the very last stage of the life time of
the object.

Of course, it is unsafe to change 'from', so make rt6_set_from simple
just for fresh entries.

Reported-by: Eric Dumazet 
Reported-by: Neil Horman 
CC: Gao Feng 
Signed-off-by: YOSHIFUJI Hideaki 
Reviewed-by: Eric Dumazet 
Reported-by: Steinar H. Gunderson 
Reviewed-by: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xfrm: release neighbor upon dst destruction

2013-02-28T13:38:40+00:00

[ Upstream commit 18cf0d0784b4a634472ed24d0d7ca1c721d93e90 ]

Neighbor is cloned in xfrm6_fill_dst but seems to never be released.
Neighbor entry should be released when XFRM6 dst entry is destroyed
in xfrm6_dst_destroy, otherwise references may be kept forever on
the device pointed by the neighbor entry.

I may not have understood all the subtleties of XFRM & dst so I would
be happy to receive comments on this patch.

Signed-off-by: Romain Kuntz 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman