linux-stable.git/drivers/net, branch v4.8.8

macsec: Fix header length if SCI is added if explicitly disabled

2016-11-15T06:48:53+00:00

[ Upstream commit e0f841f5cbf2a195c63f3441f3d8ef1cd2bdeeed ]

Even if sending SCIs is explicitly disabled, the code that creates the
Security Tag might still decide to add it (e.g. if multiple RX SCs are
defined on the MACsec interface).
But because the header length so far only depended on the configuration
option the SCI overwrote the original frame's contents (EtherType and
e.g. the beginning of the IP header) and if encrypted did not visibly
end up in the packet, while the SC flag in the TCI field of the Security
Tag was still set, resulting in invalid MACsec frames.

Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: Tobias Brunner 
Acked-by: Sabrina Dubroca 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netvsc: fix incorrect receive checksum offloading

2016-11-15T06:48:53+00:00

[ Upstream commit e52fed7177f74382f742c27de2cc5314790aebb6 ]

The Hyper-V netvsc driver was looking at the incorrect status bits
in the checksum info. It was setting the receive checksum unnecessary
flag based on the IP header checksum being correct. The checksum
flag is skb is about TCP and UDP checksum status. Because of this
bug, any packet received with bad TCP checksum would be passed
up the stack and to the application causing data corruption.
The problem is reproducible via netcat and netem.

This had a side effect of not doing receive checksum offload
on IPv6. The driver was also also always doing checksum offload
independent of the checksum setting done via ethtool.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: fec: Call swap_buffer() prior to IP header alignment

2016-11-15T06:48:53+00:00

[ Upstream commit 235bde1ed3f0fff0f68f367ec8807b89ea151258 ]

Commit 3ac72b7b63d5 ("net: fec: align IP header in hardware") breaks
networking on mx28.

There is an erratum on mx28 (ENGR121613 - ENET big endian mode
not compatible with ARM little endian) that requires an additional
byte-swap operation to workaround this problem.

So call swap_buffer() prior to performing the IP header alignment
to restore network functionality on mx28.

Fixes: 3ac72b7b63d5 ("net: fec: align IP header in hardware")
Reported-and-tested-by: Henri Roosen 
Signed-off-by: Fabio Estevam 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: add recursion limit to GRO

2016-11-15T06:48:52+00:00

[ Upstream commit fcd91dd449867c6bfe56a81cabba76b829fd05cd ]

Currently, GRO can do unlimited recursion through the gro_receive
handlers.  This was fixed for tunneling protocols by limiting tunnel GRO
to one level with encap_mark, but both VLAN and TEB still have this
problem.  Thus, the kernel is vulnerable to a stack overflow, if we
receive a packet composed entirely of VLAN headers.

This patch adds a recursion counter to the GRO layer to prevent stack
overflow.  When a gro_receive function hits the recursion limit, GRO is
aborted for this skb and it is processed normally.  This recursion
counter is put in the GRO CB, but could be turned into a percpu counter
if we run out of space in the CB.

Thanks to Vladimír Beneš  for the initial bug report.

Fixes: CVE-2016-7039
Fixes: 9b174d88c257 ("net: Add Transparent Ethernet Bridging GRO support.")
Fixes: 66e5133f19e9 ("vlan: Add GRO support for non hardware accelerated vlan")
Signed-off-by: Sabrina Dubroca 
Reviewed-by: Jiri Benc 
Acked-by: Hannes Frederic Sowa 
Acked-by: Tom Herbert 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/mlx4_en: fixup xdp tx irq to match rx

2016-11-15T06:48:52+00:00

[ Upstream commit 958b3d396d7f80755e2c2e6a8f873a669f38de10 ]

In cases where the number of tx rings is not a multiple of the number of
rx rings, the tx completion event will be handled on a different core
from the transmit and population of the ring. Races on the ring will
lead to a double-free of the page, and possibly other corruption.

The rings are initialized by default with a valid multiple of rings,
based on the number of cpus, therefore an invalid configuration requires
ethtool to change the ring layout. For instance 'ethtool -L eth0 rx 9 tx
8' will cause packets received on rx0, and XDP_TX'd to tx48, to be
completed on cpu3 (48 % 9 == 3).

Resolve this discrepancy by shifting the irq for the xdp tx queues to
start again from 0, modulo rx_ring_num.

Fixes: 9ecc2d86171a ("net/mlx4_en: add xdp forwarding and data write support")
Reported-by: Jesper Dangaard Brouer 
Signed-off-by: Brenden Blanco 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: phy: Trigger state machine on state change and not polling.

2016-11-15T06:48:51+00:00

[ Upstream commit 3c293f4e08b58ad5b78f78d89ca1fd41f87f8729 ]

The phy_start() is used to indicate the PHY is now ready to do its
work. The state is changed, normally to PHY_UP which means that both
the MAC and the PHY are ready.

If the phy driver is using polling, when the next poll happens, the
state machine notices the PHY is now in PHY_UP, and kicks off
auto-negotiation, if needed.

If however, the PHY is using interrupts, there is no polling. The phy
is stuck in PHY_UP until the next interrupt comes along. And there is
no reason for the PHY to interrupt.

Have phy_start() schedule the state machine to run, which both speeds
up the polling use case, and makes the interrupt use case actually
work.

This problems exists whenever there is a state change which will not
cause an interrupt. Trigger the state machine in these cases,
e.g. phy_error().

Signed-off-by: Andrew Lunn 
Cc: Kyle Roeschley 
Tested-by: Kyle Roeschley 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: fec: set mac address unconditionally

2016-11-15T06:48:50+00:00

[ Upstream commit b82d44d78480faff7456e9e0999acb9d38666057 ]

If the mac address origin is not dt, you can only safely assign a mac
address after "link up" of the device. If the link is off the clocks are
disabled and because of issues assigning registers when clocks are off the
new mac address cannot be written in .ndo_set_mac_address() on some soc's.
This fix sets the mac address unconditionally in fec_restart(...) and
ensures consistency between fec registers and the network layer.

Signed-off-by: Gavin Schenk 
Acked-by: Fugang Duan 
Acked-by: Uwe Kleine-König 
Fixes: 9638d19e4816 ("net: fec: add netif status check before set mac address")
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ath10k: cache calibration data when the core is stopped

2016-11-10T15:38:53+00:00

commit f67b107d4ceddcf7aa65b706aaaf50d68edb52a6 upstream.

Commit 0b8e3c4ca29f ("ath10k: move cal data len to hw_params") broke retrieving
the calibration data from cal_data debugfs file. The length of file was always
zero. The reason is:

    static ssize_t ath10k_debug_cal_data_read(struct file *file,
                                          char __user *user_buf,
                                          size_t count, loff_t *ppos)
    {
        struct ath10k *ar = file->private_data;
        void *buf = file->private_data;

This is obviously bogus, private_data cannot contain both struct ath10k and the
buffer. Fix it by caching calibration data to ar->debug.cal_data. This also
allows it to be accessed when the device is not active (interface is down).

The cal_data buffer is fixed size because during the first firmware probe we
don't yet know what will be the lenght of the calibration data. It was simplest
just to use a fixed length. There's a WARN_ON() in
ath10k_debug_cal_data_fetch() if the buffer is too small.

Tested with qca988x and firmware 10.2.4.70.56.

Reported-by: Nikolay Martynov 
Fixes: 0b8e3c4ca29f ("ath10k: move cal data len to hw_params")
Signed-off-by: Marty Faltesek 
[kvalo@qca.qualcomm.com: improve commit log and minor other changes]
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

Revert "ath9k_hw: implement temperature compensation support for AR9003+"

2016-11-10T15:38:53+00:00

commit 304e5ac118cc351eb047b6c433a89e13ea7259cf upstream.

This reverts commit 171f6402e4aa ("ath9k_hw: implement temperature compensation
support for AR9003+"). Some users report that this commit causes a regression
in performance under some conditions.

Fixes: 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+")
Signed-off-by: Felix Fietkau 
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

rtl8xxxu: Fix rtl8723bu driver reload issue

2016-11-10T15:38:53+00:00

commit ab05e5ec81c76f3a852919c22984c885edd2414a upstream.

The generic disable_rf() function clears bits 22 and 23 in
REG_RX_WAIT_CCA, however we did not re-enable them again in
rtl8723b_enable_rf()

This resolves the problem for me with 8723bu devices not working again
after reloading the driver.

Signed-off-by: Jes Sorensen 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman