linux-stable.git/drivers/net, branch linux-3.13.y

net: vxlan: fix crash when interface is created with no group

2014-04-14T13:47:22+00:00

[ Upstream commit 5933a7bbb5de66482ea8aa874a7ebaf8e67603c4 ]

If the vxlan interface is created without explicit group definition,
there are corner cases which may cause kernel panic.

For instance, in the following scenario:

node A:
$ ip link add dev vxlan42  address 2c:c2:60:00:10:20 type vxlan id 42
$ ip addr add dev vxlan42 10.0.0.1/24
$ ip link set up dev vxlan42
$ arp -i vxlan42 -s 10.0.0.2 2c:c2:60:00:01:02
$ bridge fdb add dev vxlan42 to 2c:c2:60:00:01:02 dst 
$ ping 10.0.0.2

node B:
$ ip link add dev vxlan42 address 2c:c2:60:00:01:02 type vxlan id 42
$ ip addr add dev vxlan42 10.0.0.2/24
$ ip link set up dev vxlan42
$ arp -i vxlan42 -s 10.0.0.1 2c:c2:60:00:10:20

node B crashes:

 vxlan42: 2c:c2:60:00:10:20 migrated from 4011:eca4:c0a8:6466:c0a8:6415:8e09:2118 to (invalid address)
 vxlan42: 2c:c2:60:00:10:20 migrated from 4011:eca4:c0a8:6466:c0a8:6415:8e09:2118 to (invalid address)
 BUG: unable to handle kernel NULL pointer dereference at 0000000000000046
 IP: [] ip6_route_output+0x58/0x82
 PGD 7bd89067 PUD 7bd4e067 PMD 0
 Oops: 0000 [#1] SMP
 Modules linked in:
 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.0-rc8-hvx-xen-00019-g97a5221-dirty #154
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 task: ffff88007c774f50 ti: ffff88007c79c000 task.ti: ffff88007c79c000
 RIP: 0010:[]  [] ip6_route_output+0x58/0x82
 RSP: 0018:ffff88007fd03668  EFLAGS: 00010282
 RAX: 0000000000000000 RBX: ffffffff8186a000 RCX: 0000000000000040
 RDX: 0000000000000000 RSI: ffff88007b0e4a80 RDI: ffff88007fd03754
 RBP: ffff88007fd03688 R08: ffff88007b0e4a80 R09: 0000000000000000
 R10: 0200000a0100000a R11: 0001002200000000 R12: ffff88007fd03740
 R13: ffff88007b0e4a80 R14: ffff88007b0e4a80 R15: ffff88007bba0c50
 FS:  0000000000000000(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000046 CR3: 000000007bb60000 CR4: 00000000000006e0
 Stack:
  0000000000000000 ffff88007fd037a0 ffffffff8186a000 ffff88007fd03740
  ffff88007fd036c8 ffffffff814320bb 0000000000006e49 ffff88007b8b7360
  ffff88007bdbf200 ffff88007bcbc000 ffff88007b8b7000 ffff88007b8b7360
 Call Trace:
  
  [] ip6_dst_lookup_tail+0x2d/0xa4
  [] ip6_dst_lookup+0x10/0x12
  [] vxlan_xmit_one+0x32a/0x68c
  [] ? _raw_spin_unlock_irqrestore+0x12/0x14
  [] ? lock_timer_base.isra.23+0x26/0x4b
  [] vxlan_xmit+0x66a/0x6a8
  [] ? ipt_do_table+0x35f/0x37e
  [] ? selinux_ip_postroute+0x41/0x26e
  [] dev_hard_start_xmit+0x2ce/0x3ce
  [] __dev_queue_xmit+0x2d0/0x392
  [] ? eth_header+0x28/0xb5
  [] dev_queue_xmit+0xb/0xd
  [] neigh_resolve_output+0x134/0x152
  [] ip_finish_output2+0x236/0x299
  [] ip_finish_output+0x98/0x9d
  [] ip_output+0x62/0x67
  [] dst_output+0xf/0x11
  [] ip_local_out+0x1b/0x1f
  [] ip_send_skb+0x11/0x37
  [] ip_push_pending_frames+0x2f/0x33
  [] icmp_push_reply+0x106/0x115
  [] icmp_reply+0x142/0x164
  [] icmp_echo.part.16+0x46/0x48
  [] ? nf_iterate+0x43/0x80
  [] ? xfrm4_policy_check.constprop.11+0x52/0x52
  [] icmp_echo+0x25/0x27
  [] icmp_rcv+0x1d2/0x20a
  [] ? xfrm4_policy_check.constprop.11+0x52/0x52
  [] ip_local_deliver_finish+0xd6/0x14f
  [] ? xfrm4_policy_check.constprop.11+0x52/0x52
  [] NF_HOOK.constprop.10+0x4c/0x53
  [] ip_local_deliver+0x4a/0x4f
  [] ip_rcv_finish+0x253/0x26a
  [] ? inet_add_protocol+0x3e/0x3e
  [] NF_HOOK.constprop.10+0x4c/0x53
  [] ip_rcv+0x2a6/0x2ec
  [] __netif_receive_skb_core+0x43e/0x478
  [] ? virtqueue_poll+0x16/0x27
  [] __netif_receive_skb+0x55/0x5a
  [] process_backlog+0x76/0x12f
  [] net_rx_action+0xa2/0x1ab
  [] __do_softirq+0xca/0x1d1
  [] irq_exit+0x3e/0x85
  [] do_IRQ+0xa9/0xc4
  [] common_interrupt+0x6d/0x6d
  
  [] ? native_safe_halt+0x6/0x8
  [] default_idle+0x9/0xd
  [] arch_cpu_idle+0x13/0x1c
  [] cpu_startup_entry+0xbc/0x137
  [] start_secondary+0x1a0/0x1a5
 Code: 24 14 e8 f1 e5 01 00 31 d2 a8 32 0f 95 c2 49 8b 44 24 2c 49 0b 44 24 24 74 05 83 ca 04 eb 1c 4d 85 ed 74 17 49 8b 85 a8 02 00 00 <66> 8b 40 46 66 c1 e8 07 83 e0 07 c1 e0 03 09 c2 4c 89 e6 48 89
 RIP  [] ip6_route_output+0x58/0x82
  RSP 
 CR2: 0000000000000046
 ---[ end trace 4612329caab37efd ]---

When vxlan interface is created without explicit group definition, the
default_dst protocol family is initialiazed to AF_UNSPEC and the driver
assumes IPv4 configuration. On the other side, the default_dst protocol
family is used to differentiate between IPv4 and IPv6 cases and, since,
AF_UNSPEC != AF_INET, the processing takes the IPv6 path.

Making the IPv4 assumption explicit by settting default_dst protocol
family to AF_INET4 and preventing mixing of IPv4 and IPv6 addresses in
snooped fdb entries fixes the corner case crashes.

Signed-off-by: Mike Rapoport 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Call efx_set_channels() before efx->type->dimension_resources()

2014-04-14T13:47:21+00:00

[ Upstream commit 52ad762b85ed7947ec9eff6b036eb985352f6874 ]

When using the "separate_tx_channels=1" module parameter, the TX queues are
initially numbered starting from the first TX-only channel number (after all the
RX-only channels).  efx_set_channels() renumbers the queues so that they are
indexed from zero.

On EF10, the TX queues need to be relabelled in this way before calling the
dimension_resources NIC type operation, otherwise the TX queue PIO buffers can be
linked to the wrong VIs when using "separate_tx_channels=1".

Added comments to explain UC/WC mappings for PIO buffers

Signed-off-by: Shradha Shah 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xen-netback: disable rogue vif in kthread context

2014-04-14T13:47:21+00:00

[ Upstream commit e9d8b2c2968499c1f96563e6522c56958d5a1d0d ]

When netback discovers frontend is sending malformed packet it will
disables the interface which serves that frontend.

However disabling a network interface involving taking a mutex which
cannot be done in softirq context, so we need to defer this process to
kthread context.

This patch does the following:
1. introduce a flag to indicate the interface is disabled.
2. check that flag in TX path, don't do any work if it's true.
3. check that flag in RX path, turn off that interface if it's true.

The reason to disable it in RX path is because RX uses kthread. After
this change the behavior of netback is still consistent -- it won't do
any TX work for a rogue frontend, and the interface will be eventually
turned off.

Also change a "continue" to "break" after xenvif_fatal_tx_err, as it
doesn't make sense to continue processing packets if frontend is rogue.

This is a fix for XSA-90.

Reported-by: Török Edwin 
Signed-off-by: Wei Liu 
Cc: Ian Campbell 
Reviewed-by: David Vrabel 
Acked-by: Ian Campbell 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xen-netback: remove pointless clause from if statement

2014-04-14T13:47:21+00:00

[ Upstream commit 0576eddf24df716d8570ef8ca11452a9f98eaab2 ]

This patch removes a test in start_new_rx_buffer() that checks whether
a copy operation is less than MAX_BUFFER_OFFSET in length, since
MAX_BUFFER_OFFSET is defined to be PAGE_SIZE and the only caller of
start_new_rx_buffer() already limits copy operations to PAGE_SIZE or less.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Sander Eikelenboom 
Reported-By: Sander Eikelenboom 
Tested-By: Sander Eikelenboom 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

usbnet: include wait queue head in device structure

2014-04-14T13:47:21+00:00

[ Upstream commit 14a0d635d18d0fb552dcc979d6d25106e6541f2e ]

This fixes a race which happens by freeing an object on the stack.
Quoting Julius:
> The issue is
> that it calls usbnet_terminate_urbs() before that, which temporarily
> installs a waitqueue in dev->wait in order to be able to wait on the
> tasklet to run and finish up some queues. The waiting itself looks
> okay, but the access to 'dev->wait' is totally unprotected and can
> race arbitrarily. I think in this case usbnet_bh() managed to succeed
> it's dev->wait check just before usbnet_terminate_urbs() sets it back
> to NULL. The latter then finishes and the waitqueue_t structure on its
> stack gets overwritten by other functions halfway through the
> wake_up() call in usbnet_bh().

The fix is to just not allocate the data structure on the stack.
As dev->wait is abused as a flag it also takes a runtime PM change
to fix this bug.

Signed-off-by: Oliver Neukum 
Reported-by: Grant Grundler 
Tested-by: Grant Grundler 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

virtio-net: correct error handling of virtqueue_kick()

2014-04-14T13:47:21+00:00

[ Upstream commit 681daee2443291419c57cccb0671f5f94a839005 ]

Current error handling of virtqueue_kick() was wrong in two places:
- The skb were freed immediately when virtqueue_kick() fail during
  xmit. This may lead double free since the skb was not detached from
  the virtqueue.
- try_fill_recv() returns false when virtqueue_kick() fail. This will
  lead unnecessary rescheduling of refill work.

Actually, it's safe to just ignore the kick failure in those two
places. So this patch fixes this by partially revert commit
67975901183799af8e93ec60e322f9e2a1940b9b.

Fixes 67975901183799af8e93ec60e322f9e2a1940b9b
(virtio_net: verify if virtqueue_kick() succeeded).

Cc: Heinz Graalfs 
Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tg3: Do not include vlan acceleration features in vlan_features

2014-04-14T13:47:21+00:00

[ Upstream commit 51dfe7b944998eaeb2b34d314f3a6b16a5fd621b ]

Including hardware acceleration features in vlan_features breaks
stacked vlans (Q-in-Q) by marking the bottom vlan interface as
capable of acceleration.  This causes one of the tags to be lost
and the packets are sent with a sing vlan header.

CC: Nithin Nayak Sujir 
CC: Michael Chan 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: micrel : ks8851-ml: add vdd-supply support

2014-04-14T13:47:20+00:00

[ Upstream commit ebf4ad955d3e26d4d2a33709624fc7b5b9d3b969 ]

Few platforms use external regulator to keep the ethernet MAC supplied.
So, request and enable the regulator for driver functionality.

Fixes: 66fda75f47dc (regulator: core: Replace direct ops->disable usage)
Reported-by: Russell King 
Suggested-by: Markus Pargmann 
Signed-off-by: Nishanth Menon 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vxlan: fix nonfunctional neigh_reduce()

2014-04-14T13:47:20+00:00

[ Upstream commit 4b29dba9c085a4fb79058fb1c45a2f6257ca3dfa ]

The VXLAN neigh_reduce() code is completely non-functional since
check-in. Specific errors:

1) The original code drops all packets with a multicast destination address,
	even though neighbor solicitations are sent to the solicited-node
	address, a multicast address. The code after this check was never run.
2) The neighbor table lookup used the IPv6 header destination, which is the
	solicited node address, rather than the target address from the
	neighbor solicitation. So neighbor lookups would always fail if it
	got this far. Also for L3MISSes.
3) The code calls ndisc_send_na(), which does a send on the tunnel device.
	The context for neigh_reduce() is the transmit path, vxlan_xmit(),
	where the host or a bridge-attached neighbor is trying to transmit
	a neighbor solicitation. To respond to it, the tunnel endpoint needs
	to do a *receive* of the appropriate neighbor advertisement. Doing a
	send, would only try to send the advertisement, encapsulated, to the
	remote destinations in the fdb -- hosts that definitely did not do the
	corresponding solicitation.
4) The code uses the tunnel endpoint IPv6 forwarding flag to determine the
	isrouter flag in the advertisement. This has nothing to do with whether
	or not the target is a router, and generally won't be set since the
	tunnel endpoint is bridging, not routing, traffic.

	The patch below creates a proxy neighbor advertisement to respond to
neighbor solicitions as intended, providing proper IPv6 support for neighbor
reduction.

Signed-off-by: David L Stevens 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vxlan: fix potential NULL dereference in arp_reduce()

2014-04-14T13:47:20+00:00

[ Upstream commit 7346135dcd3f9b57f30a5512094848c678d7143e ]

This patch fixes a NULL pointer dereference in the event of an
skb allocation failure in arp_reduce().

Signed-Off-By: David L Stevens 
Acked-by: Cong Wang 

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