Hello,
On Sat, 23 May 2015, Eric Dumazet wrote:
Not sure if that can help but both RCU_INIT_POINTER
calls in veth_dellink can be before the unregister_netdevice_queue
ones. May be it will help for the case when veth_dellink is
called with head=NULL. As result, veth_xmit will
On Sat, 2015-05-23 at 21:48 +0300, Julian Anastasov wrote:
Hello,
On Sat, 23 May 2015, Eric W. Biederman wrote:
Perhaps it is possible to transmit into a veth pair even when the
carrier is down? Which could be a bug in the veth driver.
Not sure if that can help but both
Hello,
On Fri, 22 May 2015, Eric W. Biederman wrote:
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()
Julian Anastasov j...@ssi.bg writes:
Hello,
On Fri, 22 May 2015, Eric W. Biederman wrote:
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()
Il 23.05.2015 16:40 ebied...@xmission.com ha scritto:
The reproducer was apparently:
ip netns add ns0
ip netns add ns1
ip link add test0 type veth peer name test1
ip link set test0 netns ns0
ip link set test1 netns ns1
ip netns exec ns0 sysctl net.ipv4.ip_forward=1
ip netns exec ns1 sysctl
Hello,
On Sat, 23 May 2015, Eric W. Biederman wrote:
Perhaps it is possible to transmit into a veth pair even when the
carrier is down? Which could be a bug in the veth driver.
Not sure if that can help but both RCU_INIT_POINTER
calls in veth_dellink can be before the
On Fri, 2015-05-22 at 04:58 -0500, Eric W. Biederman wrote:
ip_error does not check if in_dev is NULL before dereferencing it.
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
Il 22.05.2015 14:08 Eric Dumazet ha scritto:
On Fri, 2015-05-22 at 04:58 -0500, Eric W. Biederman wrote:
ip_error does not check if in_dev is NULL before dereferencing it.
Therefore handle this weird case by just dropping the packet if
!in_dev. It will result in dropping the packet sooner,
Il 22.05.2015 20:24 David Miller ha scritto:
Looks good, applied and queued up for -stable, thanks!
That's great!
I think this should also be backported up to Linux mainline 3.10, since
the original commit that introduced the bug first appeared in 3.6.
--
To unsubscribe from this list: send
From: Vittorio G (VittGam) linuxb...@vittgam.net
Date: Fri, 22 May 2015 20:48:38 +0200
Il 22.05.2015 20:24 David Miller ha scritto:
Looks good, applied and queued up for -stable, thanks!
That's great!
I think this should also be backported up to Linux mainline 3.10,
since
the original
From: ebied...@xmission.com (Eric W. Biederman)
Date: Fri, 22 May 2015 04:58:12 -0500
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()
Il 22.05.2015 21:05 David Miller ha scritto:
From: Vittorio G (VittGam) linuxb...@vittgam.net
Date: Fri, 22 May 2015 20:48:38 +0200
I think this should also be backported up to Linux mainline 3.10,
since
the original commit that introduced the bug first appeared in 3.6.
Ummm, that's what
12 matches
Mail list logo
