linux-stable.git/drivers/net, branch v3.18.86

net: 3com: typhoon: typhoon_init_one: fix incorrect return values

2017-11-30T08:35:54+00:00

[ Upstream commit 107fded7bf616ad6f46823d98b8ed6405d7adf2d ]

In a few cases the err-variable is not set to a negative error code if a
function call in typhoon_init_one() fails and thus 0 is returned
instead.
It may be better to set err to the appropriate negative error
code before returning.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841

Reported-by: Pan Bian 
Signed-off-by: Thomas Preisner 
Signed-off-by: Milan Stephan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

net: 3com: typhoon: typhoon_init_one: make return values more specific

2017-11-30T08:35:54+00:00

[ Upstream commit 6b6bbb5922a4b1d4b58125a572da91010295fba3 ]

In some cases the return value of a failing function is not being used
and the function typhoon_init_one() returns another negative error code
instead.

Signed-off-by: Thomas Preisner 
Signed-off-by: Milan Stephan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

e1000e: Separate signaling for link check/link up

2017-11-30T08:35:54+00:00

commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream.

Lennart reported the following race condition:

\ e1000_watchdog_task
    \ e1000e_has_link
        \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
            /* link is up */
            mac->get_link_status = false;

                            /* interrupt */
                            \ e1000_msix_other
                                hw->mac.get_link_status = true;

        link_active = !hw->mac.get_link_status
        /* link_active is false, wrongly */

This problem arises because the single flag get_link_status is used to
signal two different states: link status needs checking and link status is
down.

Avoid the problem by using the return value of .check_for_link to signal
the link status to e1000e_has_link().

Reported-by: Lennart Sorensen 
Signed-off-by: Benjamin Poirier 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

e1000e: Fix return value test

2017-11-30T08:35:54+00:00

commit d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 upstream.

All the helpers return -E1000_ERR_PHY.

Signed-off-by: Benjamin Poirier 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

e1000e: Fix error path in link detection

2017-11-30T08:35:54+00:00

commit c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb upstream.

In case of error from e1e_rphy(), the loop will exit early and "success"
will be set to true erroneously.

Signed-off-by: Benjamin Poirier 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

USB: fix buffer overflows with parsing CDC headers

2017-11-30T08:35:54+00:00

Parsing CDC headers a buffer overflow cannot just be prevented
by checking that the remainder of the buffer is longer than minimum
length. The size of the fields to be parsed must be figured in, too.

In newer kernels this issue has been fixed at a central location with

commit 2e1c42391ff2556387b3cb6308b24f6f65619feb
Author: Greg Kroah-Hartman 
Date:   Thu Sep 21 16:58:48 2017 +0200

    USB: core: harden cdc_parse_cdc_header

on anything older the parsing had not been centralised, so a separate
fix for each driver is necessary.

Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman

ixgbe: Fix skb list corruption on Power systems

2017-11-30T08:35:53+00:00

commit 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 upstream.

This patch fixes an issue seen on Power systems with ixgbe which results
in skb list corruption and an eventual kernel oops. The following is what
was observed:

CPU 1                                   CPU2
============================            ============================
1: ixgbe_xmit_frame_ring                ixgbe_clean_tx_irq
2:  first->skb = skb                     eop_desc = tx_buffer->next_to_watch
3:  ixgbe_tx_map                         read_barrier_depends()
4:   wmb                                 check adapter written status bit
5:   first->next_to_watch = tx_desc      napi_consume_skb(tx_buffer->skb ..);
6:   writel(i, tx_ring->tail);

The read_barrier_depends is insufficient to ensure that tx_buffer->skb does not
get loaded prior to tx_buffer->next_to_watch, which then results in loading
a stale skb pointer. This patch replaces the read_barrier_depends with
smp_rmb to ensure loads are ordered with respect to the load of
tx_buffer->next_to_watch.

Signed-off-by: Brian King 
Acked-by: Jesse Brandeburg 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

fm10k: Use smp_rmb rather than read_barrier_depends

2017-11-30T08:35:53+00:00

commit 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 upstream.

The original issue being fixed in this patch was seen with the ixgbe
driver, but the same issue exists with fm10k as well, as the code is
very similar. read_barrier_depends is not sufficient to ensure
loads following it are not speculatively loaded out of order
by the CPU, which can result in stale data being loaded, causing
potential system crashes.

Signed-off-by: Brian King 
Acked-by: Jesse Brandeburg 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

i40evf: Use smp_rmb rather than read_barrier_depends

2017-11-30T08:35:53+00:00

commit f72271e2a0ae4277d53c4053f5eed8bb346ba38a upstream.

The original issue being fixed in this patch was seen with the ixgbe
driver, but the same issue exists with i40evf as well, as the code is
very similar. read_barrier_depends is not sufficient to ensure
loads following it are not speculatively loaded out of order
by the CPU, which can result in stale data being loaded, causing
potential system crashes.

Signed-off-by: Brian King 
Acked-by: Jesse Brandeburg 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

ixgbevf: Use smp_rmb rather than read_barrier_depends

2017-11-30T08:35:52+00:00

commit ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b upstream.

The original issue being fixed in this patch was seen with the ixgbe
driver, but the same issue exists with ixgbevf as well, as the code is
very similar. read_barrier_depends is not sufficient to ensure
loads following it are not speculatively loaded out of order
by the CPU, which can result in stale data being loaded, causing
potential system crashes.

Signed-off-by: Brian King 
Acked-by: Jesse Brandeburg 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman