user/sven/linux.git, branch v3.18.27

Linux 3.18.27

2016-02-15T20:47:06Z

Signed-off-by: Sasha Levin

xfrm: dst_entries_init() per-net dst_ops

2016-02-15T20:42:46Z

[ Upstream commit a8a572a6b5f2a79280d6e302cb3c1cb1fbaeb3e8 ] Remove the dst_entries_init/destroy calls for xfrm4 and xfrm6 dst_ops templates; their dst_entries counters will never be used. Move the xfrm dst_ops initialization from the common xfrm/xfrm_policy.c to xfrm4/xfrm4_policy.c and xfrm6/xfrm6_policy.c, and call dst_entries_init and dst_entries_destroy for each net namespace. The ipv4 and ipv6 xfrms each create dst_ops template, and perform dst_entries_init on the templates. The template values are copied to each net namespace's xfrm.xfrm*_dst_ops. The problem there is the dst_ops pcpuc_entries field is a percpu counter and cannot be used correctly by simply copying it to another object. The result of this is a very subtle bug; changes to the dst entries counter from one net namespace may sometimes get applied to a different net namespace dst entries counter. This is because of how the percpu counter works; it has a main count field as well as a pointer to the percpu variables. Each net namespace maintains its own main count variable, but all point to one set of percpu variables. When any net namespace happens to change one of the percpu variables to outside its small batch range, its count is moved to the net namespace's main count variable. So with multiple net namespaces operating concurrently, the dst_ops entries counter can stray from the actual value that it should be; if counts are consistently moved from one net namespace to another (which my testing showed is likely), then one net namespace winds up with a negative dst_ops count while another winds up with a continually increasing count, eventually reaching its gc_thresh limit, which causes all new traffic on the net namespace to fail with -ENOBUFS. Signed-off-by: Dan Streetman Signed-off-by: Dan Streetman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin

xen-netfront: update num_queues to real created

2016-02-15T20:42:45Z

[ Upstream commit ca88ea1247dfee094e2467a3578eaec9bdf0833a ] Sometimes xennet_create_queues() may failed to created all requested queues, we need to update num_queues to real created to avoid NULL pointer dereference. Signed-off-by: Joe Jin Cc: Boris Ostrovsky Cc: Konrad Rzeszutek Wilk Cc: Wei Liu Cc: Ian Campbell Cc: David S. Miller Reviewed-by: Boris Ostrovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

xen-netfront: respect user provided max_queues

2016-02-15T20:42:45Z

[ Upstream commit 32a844056fd43dda647e1c3c6b9983bdfa04d17d ] Originally that parameter was always reset to num_online_cpus during module initialisation, which renders it useless. The fix is to only set max_queues to num_online_cpus when user has not provided a value. Signed-off-by: Wei Liu Cc: David Vrabel Reviewed-by: David Vrabel Tested-by: David Vrabel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

xen-netback: respect user provided max_queues

2016-02-15T20:42:45Z

[ Upstream commit 4c82ac3c37363e8c4ded6a5fe1ec5fa756b34df3 ] Originally that parameter was always reset to num_online_cpus during module initialisation, which renders it useless. The fix is to only set max_queues to num_online_cpus when user has not provided a value. Reported-by: Johnny Strom Signed-off-by: Wei Liu Reviewed-by: David Vrabel Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

team: Replace rcu_read_lock with a mutex in team_vlan_rx_kill_vid

2016-02-15T20:42:45Z

[ Upstream commit 60a6531bfe49555581ccd65f66a350cc5693fcde ] We can't be within an RCU read-side critical section when deleting VLANs, as underlying drivers might sleep during the hardware operation. Therefore, replace the RCU critical section with a mutex. This is consistent with team_vlan_rx_add_vid. Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Acked-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

ppp, slip: Validate VJ compression slot parameters completely

2016-02-15T20:42:45Z

[ Upstream commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae ] Currently slhc_init() treats out-of-range values of rslots and tslots as equivalent to 0, except that if tslots is too large it will dereference a null pointer (CVE-2015-7799). Add a range-check at the top of the function and make it return an ERR_PTR() on error instead of NULL. Change the callers accordingly. Compile-tested only. Reported-by: 郭永刚 References: http://article.gmane.org/gmane.comp.security.oss.general/17908 Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

isdn_ppp: Add checks for allocation failure in isdn_ppp_open()

2016-02-15T20:42:45Z

[ Upstream commit 0baa57d8dc32db78369d8b5176ef56c5e2e18ab3 ] Compile-tested only. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

ipv6: update skb->csum when CE mark is propagated

2016-02-15T20:42:44Z

[ Upstream commit 34ae6a1aa0540f0f781dd265366036355fdc8930 ] When a tunnel decapsulates the outer header, it has to comply with RFC 6080 and eventually propagate CE mark into inner header. It turns out IP6_ECN_set_ce() does not correctly update skb->csum for CHECKSUM_COMPLETE packets, triggering infamous "hw csum failure" messages and stack traces. Signed-off-by: Eric Dumazet Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: bpf: reject invalid shifts

2016-02-15T20:42:44Z

[ Upstream commit 229394e8e62a4191d592842cf67e80c62a492937 ] On ARM64, a BUG() is triggered in the eBPF JIT if a filter with a constant shift that can't be encoded in the immediate field of the UBFM/SBFM instructions is passed to the JIT. Since these shifts amounts, which are negative or >= regsize, are invalid, reject them in the eBPF verifier and the classic BPF filter checker, for all architectures. Signed-off-by: Rabin Vincent Acked-by: Alexei Starovoitov Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin