linux-toradex.git/net, branch v3.14.28

mac80211: free management frame keys when removing station

2015-01-08T18:00:49+00:00

commit 28a9bc68124c319b2b3dc861e80828a8865fd1ba upstream.

When writing the code to allow per-station GTKs, I neglected to
take into account the management frame keys (index 4 and 5) when
freeing the station and only added code to free the first four
data frame keys.

Fix this by iterating the array of keys over the right length.

Fixes: e31b82136d1a ("cfg80211/mac80211: allow per-station GTKs")
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix multicast LED blinking and counter

2015-01-08T18:00:49+00:00

commit d025933e29872cb1fe19fc54d80e4dfa4ee5779c upstream.

As multicast-frames can't be fragmented, "dot11MulticastReceivedFrameCount"
stopped being incremented after the use-after-free fix. Furthermore, the
RX-LED will be triggered by every multicast frame (which wouldn't happen
before) which wouldn't allow the LED to rest at all.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=89431 which also had the
patch.

Fixes: b8fff407a180 ("mac80211: fix use-after-free in defragmentation")
Signed-off-by: Andreas Müller 
[rewrite commit message]
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: Fix regression that triggers a kernel BUG with CCMP

2014-12-16T17:34:28+00:00

commit 4f031fa9f188b2b0641ac20087d9e16bcfb4e49d upstream.

Commit 7ec7c4a9a686c608315739ab6a2b0527a240883c (mac80211: port CCMP to
cryptoapi's CCM driver) introduced a regression when decrypting empty
packets (data_len == 0). This will lead to backtraces like:

(scatterwalk_start) from [] (scatterwalk_map_and_copy+0x2c/0xa8)
(scatterwalk_map_and_copy) from [] (crypto_ccm_decrypt+0x7c/0x25c)
(crypto_ccm_decrypt) from [] (ieee80211_aes_ccm_decrypt+0x160/0x170)
(ieee80211_aes_ccm_decrypt) from [] (ieee80211_crypto_ccmp_decrypt+0x1ac/0x238)
(ieee80211_crypto_ccmp_decrypt) from [] (ieee80211_rx_handlers+0x870/0x1d24)
(ieee80211_rx_handlers) from [] (ieee80211_prepare_and_rx_handle+0x8a0/0x91c)
(ieee80211_prepare_and_rx_handle) from [] (ieee80211_rx+0x568/0x730)
(ieee80211_rx) from [] (__carl9170_rx+0x94c/0xa20)
(__carl9170_rx) from [] (carl9170_rx_stream+0x1fc/0x320)
(carl9170_rx_stream) from [] (carl9170_usb_tasklet+0x80/0xc8)
(carl9170_usb_tasklet) from [] (tasklet_hi_action+0x88/0xcc)
(tasklet_hi_action) from [] (__do_softirq+0xcc/0x200)
(__do_softirq) from [] (irq_exit+0x80/0xe0)
(irq_exit) from [] (handle_IRQ+0x64/0x80)
(handle_IRQ) from [] (__irq_svc+0x40/0x4c)
(__irq_svc) from [] (arch_cpu_idle+0x2c/0x34)

Such packets can appear for example when using the carl9170 wireless driver
because hardware sometimes generates garbage when the internal FIFO overruns.

This patch adds an additional length check.

Fixes: 7ec7c4a9a686 ("mac80211: port CCMP to cryptoapi's CCM driver")
Acked-by: Ard Biesheuvel 
Signed-off-by: Ronald Wahl 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

net: sctp: use MAX_HEADER for headroom reserve in output path

2014-12-16T17:34:27+00:00

[ Upstream commit 9772b54c55266ce80c639a80aa68eeb908f8ecf5 ]

To accomodate for enough headroom for tunnels, use MAX_HEADER instead
of LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs
of trinity an skb_under_panic() via SCTP output path (see reference).
I couldn't reproduce it from here, but not using MAX_HEADER as elsewhere
in other protocols might be one possible cause for this.

In any case, it looks like accounting on chunks themself seems to look
good as the skb already passed the SCTP output path and did not hit
any skb_over_panic(). Given tunneling was enabled in his .config, the
headroom would have been expanded by MAX_HEADER in this case.

Reported-by: Robert Święcki 
Reference: https://lkml.org/lkml/2014/12/1/507
Fixes: 594ccc14dfe4d ("[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().")
Signed-off-by: Daniel Borkmann 
Acked-by: Vlad Yasevich 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

gre: Set inner mac header in gro complete

2014-12-16T17:34:27+00:00

[ Upstream commit 6fb2a756739aa507c1fd5b8126f0bfc2f070dc46 ]

Set the inner mac header to point to the GRE payload when
doing GRO. This is needed if we proceed to send the packet
through GRE GSO which now uses the inner mac header instead
of inner network header to determine the length of encapsulation
headers.

Fixes: 14051f0452a2 ("gre: Use inner mac length when computing tunnel length")
Reported-by: Wolfgang Walter 
Signed-off-by: Tom Herbert 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

rtnetlink: release net refcnt on error in do_setlink()

2014-12-16T17:34:27+00:00

[ Upstream commit e0ebde0e131b529fd721b24f62872def5ec3718c ]

rtnl_link_get_net() holds a reference on the 'struct net', we need to release
it in case of error.

CC: Eric W. Biederman 
Fixes: b51642f6d77b ("net: Enable a userns root rtnl calls that are safe for unprivilged users")
Signed-off-by: Nicolas Dichtel 
Reviewed-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: gre: fix wrong skb->protocol in WCCP

2014-12-16T17:34:27+00:00

[ Upstream commit be6572fdb1bfbe23b2624d477de50af50b02f5d6 ]

When using GRE redirection in WCCP, it sets the wrong skb->protocol,
that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic.

Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Cc: Dmitry Kozlov 
Signed-off-by: Yuri Chislov 
Tested-by: Yuri Chislov 
Signed-off-by: Daniel Borkmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ip_tunnel: the lack of vti_link_ops' dellink() cause kernel panic

2014-12-16T17:34:27+00:00

[ Upstream commit 20ea60ca9952bd19d4b0d74719daba305aef5178 ]

Now the vti_link_ops do not point the .dellink, for fb tunnel device
(ip_vti0), the net_device will be removed as the default .dellink is
unregister_netdevice_queue,but the tunnel still in the tunnel list,
then if we add a new vti tunnel, in ip_tunnel_find():

        hlist_for_each_entry_rcu(t, head, hash_node) {
                if (local == t->parms.iph.saddr &&
                    remote == t->parms.iph.daddr &&
                    link == t->parms.link &&
==>                 type == t->dev->type &&
                    ip_tunnel_key_match(&t->parms, flags, key))
                        break;
        }

the panic will happen, cause dev of ip_tunnel *t is null:
[ 3835.072977] IP: [] ip_tunnel_find+0x9d/0xc0 [ip_tunnel]
[ 3835.073008] PGD b2c21067 PUD b7277067 PMD 0
[ 3835.073008] Oops: 0000 [#1] SMP
.....
[ 3835.073008] Stack:
[ 3835.073008]  ffff8800b72d77f0 ffffffffa0411924 ffff8800bb956000 ffff8800b72d78e0
[ 3835.073008]  ffff8800b72d78a0 0000000000000000 ffffffffa040d100 ffff8800b72d7858
[ 3835.073008]  ffffffffa040b2e3 0000000000000000 0000000000000000 0000000000000000
[ 3835.073008] Call Trace:
[ 3835.073008]  [] ip_tunnel_newlink+0x64/0x160 [ip_tunnel]
[ 3835.073008]  [] vti_newlink+0x43/0x70 [ip_vti]
[ 3835.073008]  [] rtnl_newlink+0x4fa/0x5f0
[ 3835.073008]  [] ? nla_strlcpy+0x5b/0x70
[ 3835.073008]  [] ? rtnl_link_ops_get+0x40/0x60
[ 3835.073008]  [] ? rtnl_newlink+0x13f/0x5f0
[ 3835.073008]  [] rtnetlink_rcv_msg+0xa4/0x270
[ 3835.073008]  [] ? sock_has_perm+0x75/0x90
[ 3835.073008]  [] ? rtnetlink_rcv+0x30/0x30
[ 3835.073008]  [] netlink_rcv_skb+0xa9/0xc0
[ 3835.073008]  [] rtnetlink_rcv+0x28/0x30
....

modprobe ip_vti
ip link del ip_vti0 type vti
ip link add ip_vti0 type vti
rmmod ip_vti

do that one or more times, kernel will panic.

fix it by assigning ip_tunnel_dellink to vti_link_ops' dellink, in
which we skip the unregister of fb tunnel device. do the same on ip6_vti.

Signed-off-by: Xin Long 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

batman: fix a bogus warning from batadv_is_on_batman_iface()

2014-12-06T23:55:39+00:00

commit b6ed5498601df40489606dbc14a9c7011c16630b upstream.

batman tries to search dev->iflink to check if it's a batman interface,
but ->iflink could be 0, which is not a valid ifindex. It should just
avoid iflink == 0 case.

Reported-by: Jet Chen 
Tested-by: Jet Chen 
Cc: David S. Miller 
Cc: Steffen Klassert 
Cc: Antonio Quartulli 
Cc: Marek Lindner 
Signed-off-by: Cong Wang 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/ping: handle protocol mismatching scenario

2014-12-06T23:55:39+00:00

commit 91a0b603469069cdcce4d572b7525ffc9fd352a6 upstream.

ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
sock will be returned.
the fix is to "continue" the searching, if no matching, return NULL.

Cc: "David S. Miller" 
Cc: Alexey Kuznetsov 
Cc: James Morris 
Cc: Hideaki YOSHIFUJI 
Cc: Patrick McHardy 
Cc: netdev@vger.kernel.org
Signed-off-by: Jane Zhou 
Signed-off-by: Yiwei Zhao 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman