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

mac80211: flush delayed work when entering suspend

2017-03-13T20:40:49+00:00

commit a9e9200d8661c1a0be8c39f93deb383dc940de35 upstream.

The issue was found when entering suspend and resume.
It triggers a warning in:
mac80211/key.c: ieee80211_enable_keys()
...
WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt ||
             sdata->crypto_tx_tailroom_pending_dec);
...

It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully
in a delayed_work during suspend. Add a flush_delayed_work to fix it.

Signed-off-by: Matt Chen 
Signed-off-by: Johannes Berg 
Signed-off-by: Jiri Slaby

net/sched: em_meta: Fix 'meta vlan' to correctly recognize zero VID frames

2017-03-13T20:40:14+00:00

commit d65f2fa680d6f91438461df54c83a331b3a631c9 upstream.

META_COLLECTOR int_vlan_tag() assumes that if the accel tag (vlan_tci)
is zero, then no vlan accel tag is present.

This is incorrect for zero VID vlan accel packets, making the following
match fail:
  tc filter add ... basic match 'meta(vlan mask 0xfff eq 0)' ...

Apparently 'int_vlan_tag' was implemented prior VLAN_TAG_PRESENT was
introduced in 05423b2 "vlan: allow null VLAN ID to be used"
(and at time introduced, the 'vlan_tx_tag_get' call in em_meta was not
 adapted).

Fix, testing skb_vlan_tag_present instead of testing skb_vlan_tag_get's
value.

Fixes: 05423b2413 ("vlan: allow null VLAN ID to be used")
Fixes: 1a31f2042e ("netsched: Allow meta match on vlan tag on receive")

Signed-off-by: Shmulik Ladkani 
Cc: Eric Dumazet 
Cc: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

sctp: deny peeloff operation on asocs with threads sleeping on it

2017-03-11T14:37:02+00:00

commit dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 upstream.

commit 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
attempted to avoid a BUG_ON call when the association being used for a
sendmsg() is blocked waiting for more sndbuf and another thread did a
peeloff operation on such asoc, moving it to another socket.

As Ben Hutchings noticed, then in such case it would return without
locking back the socket and would cause two unlocks in a row.

Further analysis also revealed that it could allow a double free if the
application managed to peeloff the asoc that is created during the
sendmsg call, because then sctp_sendmsg() would try to free the asoc
that was created only for that call.

This patch takes another approach. It will deny the peeloff operation
if there is a thread sleeping on the asoc, so this situation doesn't
exist anymore. This avoids the issues described above and also honors
the syscalls that are already being handled (it can be multiple sendmsg
calls).

Joint work with Xin Long.

Fixes: 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
Cc: Alexander Popov 
Cc: Ben Hutchings 
Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: Xin Long 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

vti4: Don't count header length twice.

2017-03-03T10:44:49+00:00

commit a32452366b7250c42e96a18ffc3ad8db9e0ca3c2 upstream.

We currently count the size of LL_MAX_HEADER and struct iphdr
twice for vti4 devices, this leads to a wrong device mtu.
The size of LL_MAX_HEADER and struct iphdr is already counted in
ip_tunnel_bind_dev(), so don't do it again in vti_tunnel_init().

Fixes: b9959fd3 ("vti: switch to new ip tunnel code")
Signed-off-by: Steffen Klassert 
Signed-off-by: Jiri Slaby

net: sctp: rework multihoming retransmission path selection to rfc4960

2017-03-03T10:31:20+00:00

commit 4c47af4d5eb2c2f78f886079a3920a7078a6f0a0 upstream.

Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.

Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.

RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:

  Some of the transport addresses of a multi-homed SCTP endpoint
  may become inactive due to either the occurrence of certain
  error conditions (see Section 8.2) or adjustments from the
  SCTP user.

  When there is outbound data to send and the primary path
  becomes inactive (e.g., due to failures), or where the SCTP
  user explicitly requests to send data to an inactive
  destination transport address, before reporting an error to
  its ULP, the SCTP endpoint should try to send the data to an
  alternate __active__ destination transport address if one
  exists.

  When retransmitting data that timed out, if the endpoint is
  multihomed, it should consider each source-destination address
  pair in its retransmission selection policy. When retransmitting
  timed-out data, the endpoint should attempt to pick the most
  divergent source-destination pair from the original
  source-destination pair to which the packet was transmitted.

  Note: Rules for picking the most divergent source-destination
  pair are an implementation decision and are not specified
  within this document.

So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.

Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.

Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.

This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.

Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann 
Cc: Gui Jianfeng 
Acked-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

ipv6: simplify detection of first operational link-local address on interface

2017-03-03T10:31:19+00:00

commit 11ffff752c6a5adc86f7dd397b2f75af8f917c51 upstream.

In commit 1ec047eb4751e3 ("ipv6: introduce per-interface counter for
dad-completed ipv6 addresses") I build the detection of the first
operational link-local address much to complex. Additionally this code
now has a race condition.

Replace it with a much simpler variant, which just scans the address
list when duplicate address detection completes, to check if this is
the first valid link local address and send RS and MLD reports then.

Fixes: 1ec047eb4751e3 ("ipv6: introduce per-interface counter for dad-completed ipv6 addresses")
Reported-by: Jiri Pirko 
Cc: Flavio Leitner 
Signed-off-by: Hannes Frederic Sowa 
Acked-by: Flavio Leitner 
Acked-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

net: 6lowpan: fix lowpan_header_create non-compression memcpy call

2017-03-03T10:31:18+00:00

commit 965801e1eb624154fe5e9dc5d2ff0b7f1951a11c upstream.

In function lowpan_header_create(), we invoke the following code
construct:

  struct ipv6hdr *hdr;
  ...
  hdr = ipv6_hdr(skb);
  ...
  if (...)
    memcpy(hc06_ptr + 1, &hdr->flow_lbl[1], 2);
  else
    memcpy(hc06_ptr, &hdr, 4);

Where the else path of the condition, that is, non-compression
path, calls memcpy() with a pointer to struct ipv6hdr *hdr as
source, thus two levels of indirection. This cannot be correct,
and likely only one level of pointer was intended as source
buffer for memcpy() here.

Fixes: 44331fe2aa0d ("IEEE802.15.4: 6LoWPAN basic support")
Signed-off-by: Daniel Borkmann 
Cc: Alexander Smirnov 
Cc: Dmitry Eremin-Solenikov 
Cc: Werner Almesberger 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

ipv6: fix the use of pcpu_tstats in ip6_tunnel

2017-03-03T10:31:18+00:00

commit abb6013cca147ad940b0e9fee260d2d9e93b7018 upstream.

when read/write the 64bit data, the correct lock should be hold.

Fixes: 87b6d218f3adb ("tunnel: implement 64 bits statistics")

Cc: Stephen Hemminger 
Cc: Eric Dumazet 
Signed-off-by: Li RongQing 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

6lowpan: release device on error path

2017-03-03T10:31:12+00:00

commit 78032f9b3eae3a43da9468d8ce30caa6be84f89d upstream.

We recently added a new error path and it needs a dev_put().

Fixes: 7adac1ec8198 ('6lowpan: Only make 6lowpan links to IEEE802154 devices')
Signed-off-by: Dan Carpenter 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

af_packet: remove a stray tab in packet_set_ring()

2017-03-01T19:27:49+00:00

commit d7cf0c34af067555737193b6c1aa7abaa677f29c upstream.

At first glance it looks like there is a missing curly brace but
actually the code works the same either way.  I have adjusted the
indenting but left the code the same.

Signed-off-by: Dan Carpenter 
Acked-by: Daniel Borkmann 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby