Skip to content

L
linux
Switch branch/tag
  1. 11 Jun, 2015 12 commits
  3. 04 Jun, 2015 2 commits
  5. 03 Jun, 2015 21 commits
  7. 02 Jun, 2015 5 commits
    • Russell King's avatar
      ARM: fix missing syscall trace exit · 112a1545
      Russell King authored 
      commit 1b979372 upstream.

Josh Stone reports:

  I've discovered a case where both arm and arm64 will miss a ptrace
  syscall-exit that they should report.  If the syscall is entered
  without TIF_SYSCALL_TRACE set, then it goes on the fast path.  It's
  then possible to have TIF_SYSCALL_TRACE added in the middle of the
  syscall, but ret_fast_syscall doesn't check this flag again.

Fix this by always checking for a syscall trace in the fast exit path.
Reported-by: default avatarJosh Stone <jistone@redhat.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      112a1545
    • Thadeu Lima de Souza Cascardo's avatar
      bridge: fix parsing of MLDv2 reports · fee12ac9
      Thadeu Lima de Souza Cascardo authored 
      commit 47cc84ce upstream.

When more than a multicast address is present in a MLDv2 report, all but
the first address is ignored, because the code breaks out of the loop if
there has not been an error adding that address.

This has caused failures when two guests connected through the bridge
tried to communicate using IPv6. Neighbor discoveries would not be
transmitted to the other guest when both used a link-local address and a
static address.

This only happens when there is a MLDv2 querier in the network.

The fix will only break out of the loop when there is a failure adding a
multicast address.

The mdb before the patch:

dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
dev ovirtmgmt port bond0.86 grp ff02::2 temp

After the patch:

dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
dev ovirtmgmt port bond0.86 grp ff02::fb temp
dev ovirtmgmt port bond0.86 grp ff02::2 temp
dev ovirtmgmt port bond0.86 grp ff02::d temp
dev ovirtmgmt port vnet0 grp ff02::1:ff00:76 temp
dev ovirtmgmt port bond0.86 grp ff02::16 temp
dev ovirtmgmt port vnet1 grp ff02::1:ff00:77 temp
dev ovirtmgmt port bond0.86 grp ff02::1:ff00:def temp
dev ovirtmgmt port bond0.86 grp ff02::1:ffa1:40bf temp

Fixes: 08b202b6 ("bridge br_multicast: IPv6 MLD support.")
Reported-by: default avatarRik Theys <Rik.Theys@esat.kuleuven.be>
Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@redhat.com>
Tested-by: default avatarRik Theys <Rik.Theys@esat.kuleuven.be>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fee12ac9
    • Bjørn Mork's avatar
      cdc_ncm: Fix tx_bytes statistics · 7baba68a
      Bjørn Mork authored 
      commit 44f6731d upstream.

The tx_curr_frame_payload field is u32. When we try to calculate a
small negative delta based on it, we end up with a positive integer
close to 2^32 instead.  So the tx_bytes pointer increases by about
2^32 for every transmitted frame.

Fix by calculating the delta as a signed long.

Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Reported-by: default avatarFlorian Bruhin <me@the-compiler.org>
Fixes: 7a1e890e ("usbnet: Fix tx_bytes statistic running backward in cdc_ncm")
Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7baba68a
    • Eric W. Biederman's avatar
      ipv4: Avoid crashing in ip_error · 9ccba705
      Eric W. Biederman authored 
      commit 381c759d upstream.

ip_error does not check if in_dev is NULL before dereferencing it.

IThe following sequence of calls is possible:
CPU A                          CPU B
ip_rcv_finish
    ip_route_input_noref()
        ip_route_input_slow()
                               inetdev_destroy()
    dst_input()

With the result that a network device can be destroyed while processing
an input packet.

A crash was triggered with only unicast packets in flight, and
forwarding enabled on the only network device.   The error condition
was created by the removal of the network device.

As such it is likely the that error code was -EHOSTUNREACH, and the
action taken by ip_error (if in_dev had been accessible) would have
been to not increment any counters and to have tried and likely failed
to send an icmp error as the network device is going away.

Therefore handle this weird case by just dropping the packet if
!in_dev.  It will result in dropping the packet sooner, and will not
result in an actual change of behavior.

Fixes: 251da413 ("ipv4: Cache ip_error() routes even when not forwarding.")
Reported-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
Tested-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: default avatarEric Dumazet <edumazet@google.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9ccba705
    • Michal Kubeček's avatar
      ipv6: fix ECMP route replacement · 46a576a9
      Michal Kubeček authored 
      commit 27596472 upstream.

When replacing an IPv6 multipath route with "ip route replace", i.e.
NLM_F_CREATE | NLM_F_REPLACE, fib6_add_rt2node() replaces only first
matching route without fixing its siblings, resulting in corrupted
siblings linked list; removing one of the siblings can then end in an
infinite loop.

IPv6 ECMP implementation is a bit different from IPv4 so that route
replacement cannot work in exactly the same way. This should be a
reasonable approximation:

1. If the new route is ECMP-able and there is a matching ECMP-able one
already, replace it and all its siblings (if any).

2. If the new route is ECMP-able and no matching ECMP-able route exists,
replace first matching non-ECMP-able (if any) or just add the new one.

3. If the new route is not ECMP-able, replace first matching
non-ECMP-able route (if any) or add the new route.

We also need to remove the NLM_F_REPLACE flag after replacing old
route(s) by first nexthop of an ECMP route so that each subsequent
nexthop does not replace previous one.

Fixes: 51ebd318 ("ipv6: add support of equal cost multipath (ECMP)")
Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      46a576a9
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7