linux-stable.git/include, branch v3.2.87

list: introduce list_first_entry_or_null

2017-03-16T02:18:59+00:00

commit 6d7581e62f8be462440d7b22c6361f7c9fa4902b upstream.

non-rcu variant of list_first_or_null_rcu

Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

can: Fix kernel panic at security_sock_rcv_skb

2017-03-16T02:18:56+00:00

[ Upstream commit f1712c73714088a7252d276a57126d56c7d37e64 ]

Zhang Yanmin reported crashes [1] and provided a patch adding a
synchronize_rcu() call in can_rx_unregister()

The main problem seems that the sockets themselves are not RCU
protected.

If CAN uses RCU for delivery, then sockets should be freed only after
one RCU grace period.

Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's
ease stable backports with the following fix instead.

[1]
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0

Call Trace:
 
 [] security_sock_rcv_skb+0x4c/0x60
 [] sk_filter+0x41/0x210
 [] sock_queue_rcv_skb+0x53/0x3a0
 [] raw_rcv+0x2a3/0x3c0
 [] can_rcv_filter+0x12b/0x370
 [] can_receive+0xd9/0x120
 [] can_rcv+0xab/0x100
 [] __netif_receive_skb_core+0xd8c/0x11f0
 [] __netif_receive_skb+0x24/0xb0
 [] process_backlog+0x127/0x280
 [] net_rx_action+0x33b/0x4f0
 [] __do_softirq+0x184/0x440
 [] do_softirq_own_stack+0x1c/0x30
 
 [] do_softirq.part.18+0x3b/0x40
 [] do_softirq+0x1d/0x20
 [] netif_rx_ni+0xe5/0x110
 [] slcan_receive_buf+0x507/0x520
 [] flush_to_ldisc+0x21c/0x230
 [] process_one_work+0x24f/0x670
 [] worker_thread+0x9d/0x6f0
 [] ? rescuer_thread+0x480/0x480
 [] kthread+0x12c/0x150
 [] ret_from_fork+0x3f/0x70

Reported-by: Zhang Yanmin 
Signed-off-by: Eric Dumazet 
Acked-by: Oliver Hartkopp 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: avoid sk_forward_alloc overflows

2017-03-16T02:18:53+00:00

[ Upstream commit 20c64d5cd5a2bdcdc8982a06cb05e5e1bd851a3d ]

A malicious TCP receiver, sending SACK, can force the sender to split
skbs in write queue and increase its memory usage.

Then, when socket is closed and its write queue purged, we might
overflow sk_forward_alloc (It becomes negative)

sk_mem_reclaim() does nothing in this case, and more than 2GB
are leaked from TCP perspective (tcp_memory_allocated is not changed)

Then warnings trigger from inet_sock_destruct() and
sk_stream_kill_queues() seeing a not zero sk_forward_alloc

All TCP stack can be stuck because TCP is under memory pressure.

A simple fix is to preemptively reclaim from sk_mem_uncharge().

This makes sure a socket wont have more than 2 MB forward allocated,
after burst and idle period.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: fix sk_mem_reclaim_partial()

2017-03-16T02:18:52+00:00

commit 1a24e04e4b50939daa3041682b38b82c896ca438 upstream.

sk_mem_reclaim_partial() goal is to ensure each socket has
one SK_MEM_QUANTUM forward allocation. This is needed both for
performance and better handling of memory pressure situations in
follow up patches.

SK_MEM_QUANTUM is currently a page, but might be reduced to 4096 bytes
as some arches have 64KB pages.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2:
 - Keep using atomic_long_sub() directly, not sk_memory_allocated_sub()
 - Adjust context]
Signed-off-by: Ben Hutchings

net/sock: Add sock_efree() function

2017-03-16T02:18:49+00:00

Extracted from commit 62bccb8cdb69 ("net-timestamp: Make the clone operation
stand-alone from phy timestamping").

Signed-off-by: Ben Hutchings

netlabel: out of bound access in cipso_v4_validate()

2017-03-16T02:18:47+00:00

commit d71b7896886345c53ef1d84bda2bc758554f5d61 upstream.

syzkaller found another out of bound access in ip_options_compile(),
or more exactly in cipso_v4_validate()

Fixes: 20e2a8648596 ("cipso: handle CIPSO options correctly when NetLabel is disabled")
Fixes: 446fda4f2682 ("[NetLabel]: CIPSOv4 engine")
Signed-off-by: Eric Dumazet 
Reported-by: Dmitry Vyukov  
Cc: Paul Moore 
Acked-by: Paul Moore 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

gro: Disable frag0 optimization on IPv6 ext headers

2017-03-16T02:18:42+00:00

commit 57ea52a865144aedbcd619ee0081155e658b6f7d upstream.

The GRO fast path caches the frag0 address.  This address becomes
invalid if frag0 is modified by pskb_may_pull or its variants.
So whenever that happens we must disable the frag0 optimization.

This is usually done through the combination of gro_header_hard
and gro_header_slow, however, the IPv6 extension header path did
the pulling directly and would continue to use the GRO fast path
incorrectly.

This patch fixes it by disabling the fast path when we enter the
IPv6 extension header path.

Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual address")
Reported-by: Slava Shwartsman 
Signed-off-by: Herbert Xu 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

hotplug: Make register and unregister notifier API symmetric

2017-03-16T02:18:29+00:00

commit 777c6e0daebb3fcefbbd6f620410a946b07ef6d0 upstream.

Yu Zhao has noticed that __unregister_cpu_notifier only unregisters its
notifiers when HOTPLUG_CPU=y while the registration might succeed even
when HOTPLUG_CPU=n if MODULE is enabled. This means that e.g. zswap
might keep a stale notifier on the list on the manual clean up during
the pool tear down and thus corrupt the list. Resulting in the following

[  144.964346] BUG: unable to handle kernel paging request at ffff880658a2be78
[  144.971337] IP: [] raw_notifier_chain_register+0x1b/0x40

[  145.122628] Call Trace:
[  145.125086]  [] __register_cpu_notifier+0x18/0x20
[  145.131350]  [] zswap_pool_create+0x273/0x400
[  145.137268]  [] __zswap_param_set+0x1fc/0x300
[  145.143188]  [] ? trace_hardirqs_on+0xd/0x10
[  145.149018]  [] ? kernel_param_lock+0x28/0x30
[  145.154940]  [] ? __might_fault+0x4f/0xa0
[  145.160511]  [] zswap_compressor_param_set+0x17/0x20
[  145.167035]  [] param_attr_store+0x5c/0xb0
[  145.172694]  [] module_attr_store+0x1d/0x30
[  145.178443]  [] sysfs_kf_write+0x4f/0x70
[  145.183925]  [] kernfs_fop_write+0x149/0x180
[  145.189761]  [] __vfs_write+0x18/0x40
[  145.194982]  [] vfs_write+0xb2/0x1a0
[  145.200122]  [] SyS_write+0x52/0xa0
[  145.205177]  [] entry_SYSCALL_64_fastpath+0x12/0x17

This can be even triggered manually by changing
/sys/module/zswap/parameters/compressor multiple times.

Fix this issue by making unregister APIs symmetric to the register so
there are no surprises.

Fixes: 47e627bc8c9a ("[PATCH] hotplug: Allow modules to use the cpu hotplug notifiers even if !CONFIG_HOTPLUG_CPU")
Reported-and-tested-by: Yu Zhao 
Signed-off-by: Michal Hocko 
Cc: linux-mm@kvack.org
Cc: Andrew Morton 
Cc: Dan Streetman 
Link: http://lkml.kernel.org/r/20161207135438.4310-1-mhocko@kernel.org
Signed-off-by: Thomas Gleixner 
[bwh: Backported to 3.2:
 - The lockless (__-prefixed) variants don't exist
 - Keep definition of cpu_notify_nofail() conditional on CONFIG_HOTPLUG_CPU]
Signed-off-by: Ben Hutchings

tcp: take care of truncations done by sk_filter()

2017-02-23T03:51:05+00:00

commit ac6e780070e30e4c35bd395acfe9191e6268bdd3 upstream.

With syzkaller help, Marco Grassi found a bug in TCP stack,
crashing in tcp_collapse()

Root cause is that sk_filter() can truncate the incoming skb,
but TCP stack was not really expecting this to happen.
It probably was expecting a simple DROP or ACCEPT behavior.

We first need to make sure no part of TCP header could be removed.
Then we need to adjust TCP_SKB_CB(skb)->end_seq

Many thanks to syzkaller team and Marco for giving us a reproducer.

Signed-off-by: Eric Dumazet 
Reported-by: Marco Grassi 
Reported-by: Vladis Dronov 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

dccp: limit sk_filter trim to payload

2017-02-23T03:51:05+00:00

commit 4f0c40d94461cfd23893a17335b2ab78ecb333c8 upstream.

Dccp verifies packet integrity, including length, at initial rcv in
dccp_invalid_packet, later pulls headers in dccp_enqueue_skb.

A call to sk_filter in-between can cause __skb_pull to wrap skb->len.
skb_copy_datagram_msg interprets this as a negative value, so
(correctly) fails with EFAULT. The negative length is reported in
ioctl SIOCINQ or possibly in a DCCP_WARN in dccp_close.

Introduce an sk_receive_skb variant that caps how small a filter
program can trim packets, and call this in dccp with the header
length. Excessively trimmed packets are now processed normally and
queued for reception as 0B payloads.

Fixes: 7c657876b63c ("[DCCP]: Initial implementation")
Signed-off-by: Willem de Bruijn 
Acked-by: Daniel Borkmann 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings