user/sven/linux.git/drivers/net/ipvlan, branch v4.4.27

ipvlan: fix use after free of skb

2015-11-17T19:39:29Z

ipvlan_handle_frame is a rx_handler, and when it returns a value other than RX_HANDLER_CONSUMED (here, NET_RX_DROP aka RX_HANDLER_ANOTHER), __netif_receive_skb_core expects that the skb still exists and will process it further, but we just freed it. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller

ipvlan: fix leak in ipvlan_rcv_frame

2015-11-17T19:39:28Z

Pass a **skb to ipvlan_rcv_frame so that if skb_share_check returns a new skb, we actually use it during further processing. It's safe to ignore the new skb in the ipvlan_xmit_* functions, because they call ipvlan_rcv_frame with local == true, so that dev_forward_skb is called and always takes ownership of the skb. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller

ipvlan: read direct ifindex instead of iflink

2015-10-22T13:39:08Z

In the ipv4 outbound path of an ipvlan device in l3 mode, the ifindex is being grabbed from dev_get_iflink. This works for the physical device case, since as the documentation of that function notes: "Physical interfaces have the same 'ifindex' and 'iflink' values.". However, if the master device is a veth, and the pairs are in separate net namespaces, the route lookup will fail with -ENODEV due to outer veth pair being in a separate namespace from the ipvlan master/routing namespace. ns0 | ns1 | ns2 veth0a--|--veth0b--|--ipvl0 In ipvlan_process_v4_outbound(), a packet sent from ipvl0 in the above configuration will pass fl.flowi4_oif == veth0a to ip_route_output_flow(), but *net == ns1. Notice also that ipv6 processing is not using iflink. Since there is a discrepancy in usage, fixup both v4 and v6 case to use local dev variable. Tested this with l3 ipvlan on top of veth, as well as with single physical interface in the top namespace. Signed-off-by: Brenden Blanco Reviewed-by: Jiri Benc Acked-by: Mahesh Bandewar Signed-off-by: David S. Miller

ipv4, ipv6: Pass net into ip_local_out and ip6_local_out

2015-10-08T11:27:02Z

Signed-off-by: "Eric W. Biederman" Signed-off-by: David S. Miller

ipvlan: Cache net in ipvlan_process_v4_outbound and ipvlan_process_v6_outbound

2015-10-08T11:27:01Z

Compute net once in ipvlan_process_v4_outbound and ipvlan_process_v6_outbound and store it in a variable so that net does not need to be recomputed next time it is used. Signed-off-by: "Eric W. Biederman" Signed-off-by: David S. Miller

ipv6: Merge ip6_local_out and ip6_local_out_sk

2015-10-08T11:26:58Z

Stop hidding the sk parameter with an inline helper function and make all of the callers pass it, so that it is clear what the function is doing. Signed-off-by: "Eric W. Biederman" Signed-off-by: David S. Miller

ipv4: Merge ip_local_out and ip_local_out_sk

2015-10-08T11:26:57Z

It is confusing and silly hiding a parameter so modify all of the callers to pass in the appropriate socket or skb->sk if no socket is known. Signed-off-by: "Eric W. Biederman" Signed-off-by: David S. Miller

net: ipvlan: convert to using IFF_NO_QUEUE

2015-08-18T18:55:06Z

Signed-off-by: Phil Sutter Cc: Mahesh Bandewar Signed-off-by: David S. Miller

ipvlan: ignore addresses from ipv6 autoconfiguration

2015-07-16T04:33:40Z

Inet6addr notifier is atomic and runs in bh context without RTNL when ipv6 receives router advertisement packet and performs autoconfiguration. Proper fix still in discussion. Let's at least plug the bug. v1: http://lkml.kernel.org/r/20150514135618.14062.1969.stgit@buzz v2: http://lkml.kernel.org/r/20150703125840.24121.91556.stgit@buzz Signed-off-by: Konstantin Khlebnikov Signed-off-by: David S. Miller

ipvlan: use rcu_deference_bh() in ipvlan_queue_xmit()

2015-07-16T04:33:40Z

In tx path rcu_read_lock_bh() is held, so we need rcu_deference_bh(). This fixes the following warning: =============================== [ INFO: suspicious RCU usage. ] 4.1.0-rc1+ #1007 Not tainted ------------------------------- drivers/net/ipvlan/ipvlan.h:106 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by dhclient/1076: #0: (rcu_read_lock_bh){......}, at: [] rcu_lock_acquire+0x0/0x26 stack backtrace: CPU: 2 PID: 1076 Comm: dhclient Not tainted 4.1.0-rc1+ #1007 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000001 ffff8800d381bac8 ffffffff81a4154f 000000003c1a3c19 ffff8800d4d0a690 ffff8800d381baf8 ffffffff810b849f ffff880117d41148 ffff880117d40000 ffff880117d40068 0000000000000156 ffff8800d381bb18 Call Trace: [] dump_stack+0x4c/0x65 [] lockdep_rcu_suspicious+0x107/0x110 [] ipvlan_port_get_rcu+0x47/0x4e [] ipvlan_queue_xmit+0x35/0x450 [] ? rcu_read_unlock+0x3e/0x5f [] ? local_clock+0x19/0x22 [] ? __lock_is_held+0x39/0x52 [] ipvlan_start_xmit+0x1b/0x44 [] dev_hard_start_xmit+0x2ae/0x467 [] __dev_queue_xmit+0x50a/0x60c [] dev_queue_xmit_sk+0x13/0x15 [] dev_queue_xmit+0x10/0x12 [] packet_sendmsg+0xb6b/0xbdf [] ? mark_lock+0x2e/0x226 [] ? sched_clock_cpu+0x9e/0xb7 [] sock_sendmsg_nosec+0x12/0x1d [] sock_sendmsg+0x29/0x2e [] sock_write_iter+0x70/0x91 [] __vfs_write+0x7e/0xa7 [] vfs_write+0x92/0xe8 [] SyS_write+0x47/0x7e [] system_call_fastpath+0x12/0x6f Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Cc: Mahesh Bandewar Signed-off-by: Cong Wang Acked-by: Mahesh Bandewar Acked-by: Konstantin Khlebnikov Signed-off-by: David S. Miller