<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/linux, branch v3.2.87</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>list: introduce list_first_entry_or_null</title>
<updated>2017-03-16T02:18:59+00:00</updated>
<author>
<name>Jiri Pirko</name>
<email>jiri@resnulli.us</email>
</author>
<published>2013-05-29T05:02:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4157e287632c9f88ea9bee74d7296a20aa1654cc'/>
<id>4157e287632c9f88ea9bee74d7296a20aa1654cc</id>
<content type='text'>
commit 6d7581e62f8be462440d7b22c6361f7c9fa4902b upstream.

non-rcu variant of list_first_or_null_rcu

Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6d7581e62f8be462440d7b22c6361f7c9fa4902b upstream.

non-rcu variant of list_first_or_null_rcu

Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: Fix kernel panic at security_sock_rcv_skb</title>
<updated>2017-03-16T02:18:56+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2017-01-27T16:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=47c192ef34576d3f88451f40b960713f94c3b22f'/>
<id>47c192ef34576d3f88451f40b960713f94c3b22f</id>
<content type='text'>
[ 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: [&lt;ffffffff81495e25&gt;] selinux_socket_sock_rcv_skb+0x65/0x2a0

Call Trace:
 &lt;IRQ&gt;
 [&lt;ffffffff81485d8c&gt;] security_sock_rcv_skb+0x4c/0x60
 [&lt;ffffffff81d55771&gt;] sk_filter+0x41/0x210
 [&lt;ffffffff81d12913&gt;] sock_queue_rcv_skb+0x53/0x3a0
 [&lt;ffffffff81f0a2b3&gt;] raw_rcv+0x2a3/0x3c0
 [&lt;ffffffff81f06eab&gt;] can_rcv_filter+0x12b/0x370
 [&lt;ffffffff81f07af9&gt;] can_receive+0xd9/0x120
 [&lt;ffffffff81f07beb&gt;] can_rcv+0xab/0x100
 [&lt;ffffffff81d362ac&gt;] __netif_receive_skb_core+0xd8c/0x11f0
 [&lt;ffffffff81d36734&gt;] __netif_receive_skb+0x24/0xb0
 [&lt;ffffffff81d37f67&gt;] process_backlog+0x127/0x280
 [&lt;ffffffff81d36f7b&gt;] net_rx_action+0x33b/0x4f0
 [&lt;ffffffff810c88d4&gt;] __do_softirq+0x184/0x440
 [&lt;ffffffff81f9e86c&gt;] do_softirq_own_stack+0x1c/0x30
 &lt;EOI&gt;
 [&lt;ffffffff810c76fb&gt;] do_softirq.part.18+0x3b/0x40
 [&lt;ffffffff810c8bed&gt;] do_softirq+0x1d/0x20
 [&lt;ffffffff81d30085&gt;] netif_rx_ni+0xe5/0x110
 [&lt;ffffffff8199cc87&gt;] slcan_receive_buf+0x507/0x520
 [&lt;ffffffff8167ef7c&gt;] flush_to_ldisc+0x21c/0x230
 [&lt;ffffffff810e3baf&gt;] process_one_work+0x24f/0x670
 [&lt;ffffffff810e44ed&gt;] worker_thread+0x9d/0x6f0
 [&lt;ffffffff810e4450&gt;] ? rescuer_thread+0x480/0x480
 [&lt;ffffffff810ebafc&gt;] kthread+0x12c/0x150
 [&lt;ffffffff81f9ccef&gt;] ret_from_fork+0x3f/0x70

Reported-by: Zhang Yanmin &lt;yanmin.zhang@intel.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ 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: [&lt;ffffffff81495e25&gt;] selinux_socket_sock_rcv_skb+0x65/0x2a0

Call Trace:
 &lt;IRQ&gt;
 [&lt;ffffffff81485d8c&gt;] security_sock_rcv_skb+0x4c/0x60
 [&lt;ffffffff81d55771&gt;] sk_filter+0x41/0x210
 [&lt;ffffffff81d12913&gt;] sock_queue_rcv_skb+0x53/0x3a0
 [&lt;ffffffff81f0a2b3&gt;] raw_rcv+0x2a3/0x3c0
 [&lt;ffffffff81f06eab&gt;] can_rcv_filter+0x12b/0x370
 [&lt;ffffffff81f07af9&gt;] can_receive+0xd9/0x120
 [&lt;ffffffff81f07beb&gt;] can_rcv+0xab/0x100
 [&lt;ffffffff81d362ac&gt;] __netif_receive_skb_core+0xd8c/0x11f0
 [&lt;ffffffff81d36734&gt;] __netif_receive_skb+0x24/0xb0
 [&lt;ffffffff81d37f67&gt;] process_backlog+0x127/0x280
 [&lt;ffffffff81d36f7b&gt;] net_rx_action+0x33b/0x4f0
 [&lt;ffffffff810c88d4&gt;] __do_softirq+0x184/0x440
 [&lt;ffffffff81f9e86c&gt;] do_softirq_own_stack+0x1c/0x30
 &lt;EOI&gt;
 [&lt;ffffffff810c76fb&gt;] do_softirq.part.18+0x3b/0x40
 [&lt;ffffffff810c8bed&gt;] do_softirq+0x1d/0x20
 [&lt;ffffffff81d30085&gt;] netif_rx_ni+0xe5/0x110
 [&lt;ffffffff8199cc87&gt;] slcan_receive_buf+0x507/0x520
 [&lt;ffffffff8167ef7c&gt;] flush_to_ldisc+0x21c/0x230
 [&lt;ffffffff810e3baf&gt;] process_one_work+0x24f/0x670
 [&lt;ffffffff810e44ed&gt;] worker_thread+0x9d/0x6f0
 [&lt;ffffffff810e4450&gt;] ? rescuer_thread+0x480/0x480
 [&lt;ffffffff810ebafc&gt;] kthread+0x12c/0x150
 [&lt;ffffffff81f9ccef&gt;] ret_from_fork+0x3f/0x70

Reported-by: Zhang Yanmin &lt;yanmin.zhang@intel.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>gro: Disable frag0 optimization on IPv6 ext headers</title>
<updated>2017-03-16T02:18:42+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2017-01-10T20:24:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3890b98611757fe3e4808e0f52e4d822d6e75e6d'/>
<id>3890b98611757fe3e4808e0f52e4d822d6e75e6d</id>
<content type='text'>
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 &lt;slavash@mellanox.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;slavash@mellanox.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hotplug: Make register and unregister notifier API symmetric</title>
<updated>2017-03-16T02:18:29+00:00</updated>
<author>
<name>Michal Hocko</name>
<email>mhocko@suse.com</email>
</author>
<published>2016-12-07T13:54:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2bdea84253130dc22c3e3d7a7e9013d02d21d108'/>
<id>2bdea84253130dc22c3e3d7a7e9013d02d21d108</id>
<content type='text'>
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: [&lt;ffffffffa290b00b&gt;] raw_notifier_chain_register+0x1b/0x40
&lt;snipped&gt;
[  145.122628] Call Trace:
[  145.125086]  [&lt;ffffffffa28e5cf8&gt;] __register_cpu_notifier+0x18/0x20
[  145.131350]  [&lt;ffffffffa2a5dd73&gt;] zswap_pool_create+0x273/0x400
[  145.137268]  [&lt;ffffffffa2a5e0fc&gt;] __zswap_param_set+0x1fc/0x300
[  145.143188]  [&lt;ffffffffa2944c1d&gt;] ? trace_hardirqs_on+0xd/0x10
[  145.149018]  [&lt;ffffffffa2908798&gt;] ? kernel_param_lock+0x28/0x30
[  145.154940]  [&lt;ffffffffa2a3e8cf&gt;] ? __might_fault+0x4f/0xa0
[  145.160511]  [&lt;ffffffffa2a5e237&gt;] zswap_compressor_param_set+0x17/0x20
[  145.167035]  [&lt;ffffffffa2908d3c&gt;] param_attr_store+0x5c/0xb0
[  145.172694]  [&lt;ffffffffa290848d&gt;] module_attr_store+0x1d/0x30
[  145.178443]  [&lt;ffffffffa2b2b41f&gt;] sysfs_kf_write+0x4f/0x70
[  145.183925]  [&lt;ffffffffa2b2a5b9&gt;] kernfs_fop_write+0x149/0x180
[  145.189761]  [&lt;ffffffffa2a99248&gt;] __vfs_write+0x18/0x40
[  145.194982]  [&lt;ffffffffa2a9a412&gt;] vfs_write+0xb2/0x1a0
[  145.200122]  [&lt;ffffffffa2a9a732&gt;] SyS_write+0x52/0xa0
[  145.205177]  [&lt;ffffffffa2ff4d97&gt;] 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 &lt;yuzhao@google.com&gt;
Signed-off-by: Michal Hocko &lt;mhocko@suse.com&gt;
Cc: linux-mm@kvack.org
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Dan Streetman &lt;ddstreet@ieee.org&gt;
Link: http://lkml.kernel.org/r/20161207135438.4310-1-mhocko@kernel.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
[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 &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: [&lt;ffffffffa290b00b&gt;] raw_notifier_chain_register+0x1b/0x40
&lt;snipped&gt;
[  145.122628] Call Trace:
[  145.125086]  [&lt;ffffffffa28e5cf8&gt;] __register_cpu_notifier+0x18/0x20
[  145.131350]  [&lt;ffffffffa2a5dd73&gt;] zswap_pool_create+0x273/0x400
[  145.137268]  [&lt;ffffffffa2a5e0fc&gt;] __zswap_param_set+0x1fc/0x300
[  145.143188]  [&lt;ffffffffa2944c1d&gt;] ? trace_hardirqs_on+0xd/0x10
[  145.149018]  [&lt;ffffffffa2908798&gt;] ? kernel_param_lock+0x28/0x30
[  145.154940]  [&lt;ffffffffa2a3e8cf&gt;] ? __might_fault+0x4f/0xa0
[  145.160511]  [&lt;ffffffffa2a5e237&gt;] zswap_compressor_param_set+0x17/0x20
[  145.167035]  [&lt;ffffffffa2908d3c&gt;] param_attr_store+0x5c/0xb0
[  145.172694]  [&lt;ffffffffa290848d&gt;] module_attr_store+0x1d/0x30
[  145.178443]  [&lt;ffffffffa2b2b41f&gt;] sysfs_kf_write+0x4f/0x70
[  145.183925]  [&lt;ffffffffa2b2a5b9&gt;] kernfs_fop_write+0x149/0x180
[  145.189761]  [&lt;ffffffffa2a99248&gt;] __vfs_write+0x18/0x40
[  145.194982]  [&lt;ffffffffa2a9a412&gt;] vfs_write+0xb2/0x1a0
[  145.200122]  [&lt;ffffffffa2a9a732&gt;] SyS_write+0x52/0xa0
[  145.205177]  [&lt;ffffffffa2ff4d97&gt;] 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 &lt;yuzhao@google.com&gt;
Signed-off-by: Michal Hocko &lt;mhocko@suse.com&gt;
Cc: linux-mm@kvack.org
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Dan Streetman &lt;ddstreet@ieee.org&gt;
Link: http://lkml.kernel.org/r/20161207135438.4310-1-mhocko@kernel.org
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
[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 &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rose: limit sk_filter trim to payload</title>
<updated>2017-02-23T03:51:05+00:00</updated>
<author>
<name>Willem de Bruijn</name>
<email>willemb@google.com</email>
</author>
<published>2016-07-12T22:18:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d0e04e049a62ad9e7371bbd6897f17e56900c48f'/>
<id>d0e04e049a62ad9e7371bbd6897f17e56900c48f</id>
<content type='text'>
commit f4979fcea7fd36d8e2f556abef86f80e0d5af1ba upstream.

Sockets can have a filter program attached that drops or trims
incoming packets based on the filter program return value.

Rose requires data packets to have at least ROSE_MIN_LEN bytes. It
verifies this on arrival in rose_route_frame and unconditionally pulls
the bytes in rose_recvmsg. The filter can trim packets to below this
value in-between, causing pull to fail, leaving the partial header at
the time of skb_copy_datagram_msg.

Place a lower bound on the size to which sk_filter may trim packets
by introducing sk_filter_trim_cap and call this for rose packets.

Signed-off-by: Willem de Bruijn &lt;willemb@google.com&gt;
Acked-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f4979fcea7fd36d8e2f556abef86f80e0d5af1ba upstream.

Sockets can have a filter program attached that drops or trims
incoming packets based on the filter program return value.

Rose requires data packets to have at least ROSE_MIN_LEN bytes. It
verifies this on arrival in rose_route_frame and unconditionally pulls
the bytes in rose_recvmsg. The filter can trim packets to below this
value in-between, causing pull to fail, leaving the partial header at
the time of skb_copy_datagram_msg.

Place a lower bound on the size to which sk_filter may trim packets
by introducing sk_filter_trim_cap and call this for rose packets.

Signed-off-by: Willem de Bruijn &lt;willemb@google.com&gt;
Acked-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>lockdep: Silence warning if CONFIG_LOCKDEP isn't set</title>
<updated>2017-02-23T03:51:04+00:00</updated>
<author>
<name>Paul Bolle</name>
<email>pebolle@tiscali.nl</email>
</author>
<published>2013-01-24T20:53:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=45b5aba2c6a8fa9a62a35a3801b15e23b98f19d5'/>
<id>45b5aba2c6a8fa9a62a35a3801b15e23b98f19d5</id>
<content type='text'>
commit 5cd3f5affad2109fd1458aab3f6216f2181e26ea upstream.

Since commit c9a4962881929df7f1ef6e63e1b9da304faca4dd ("nfsd:
make client_lock per net") compiling nfs4state.o without
CONFIG_LOCKDEP set, triggers this GCC warning:

    fs/nfsd/nfs4state.c: In function ‘free_client’:
    fs/nfsd/nfs4state.c:1051:19: warning: unused variable ‘nn’ [-Wunused-variable]

The cause of that warning is that lockdep_assert_held() compiles
away if CONFIG_LOCKDEP is not set. Silence this warning by using
the argument to lockdep_assert_held() as a nop if CONFIG_LOCKDEP
is not set.

Signed-off-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stanislav Kinsbursky &lt;skinsbursky@parallels.com&gt;
Cc: J. Bruce Fields &lt;bfields@redhat.com&gt;
Link: http://lkml.kernel.org/r/1359060797.1325.33.camel@x61.thuisdomein
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5cd3f5affad2109fd1458aab3f6216f2181e26ea upstream.

Since commit c9a4962881929df7f1ef6e63e1b9da304faca4dd ("nfsd:
make client_lock per net") compiling nfs4state.o without
CONFIG_LOCKDEP set, triggers this GCC warning:

    fs/nfsd/nfs4state.c: In function ‘free_client’:
    fs/nfsd/nfs4state.c:1051:19: warning: unused variable ‘nn’ [-Wunused-variable]

The cause of that warning is that lockdep_assert_held() compiles
away if CONFIG_LOCKDEP is not set. Silence this warning by using
the argument to lockdep_assert_held() as a nop if CONFIG_LOCKDEP
is not set.

Signed-off-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stanislav Kinsbursky &lt;skinsbursky@parallels.com&gt;
Cc: J. Bruce Fields &lt;bfields@redhat.com&gt;
Link: http://lkml.kernel.org/r/1359060797.1325.33.camel@x61.thuisdomein
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: raw: raw_setsockopt: limit number of can_filter that can be set</title>
<updated>2017-02-23T03:51:02+00:00</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2016-12-05T10:44:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7f5edacaa2c4b198b948fa0d14661a63d66428d6'/>
<id>7f5edacaa2c4b198b948fa0d14661a63d66428d6</id>
<content type='text'>
commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream.

This patch adds a check to limit the number of can_filters that can be
set via setsockopt on CAN_RAW sockets. Otherwise allocations &gt; MAX_ORDER
are not prevented resulting in a warning.

Reference: https://lkml.org/lkml/2016/12/2/230

Reported-by: Andrey Konovalov &lt;andreyknvl@google.com&gt;
Tested-by: Andrey Konovalov &lt;andreyknvl@google.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream.

This patch adds a check to limit the number of can_filters that can be
set via setsockopt on CAN_RAW sockets. Otherwise allocations &gt; MAX_ORDER
are not prevented resulting in a warning.

Reference: https://lkml.org/lkml/2016/12/2/230

Reported-by: Andrey Konovalov &lt;andreyknvl@google.com&gt;
Tested-by: Andrey Konovalov &lt;andreyknvl@google.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>posix_acl: Clear SGID bit when setting file permissions</title>
<updated>2016-11-20T01:01:44+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2016-09-19T15:39:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a06d3be52bce98746341cfb290203603fd028290'/>
<id>a06d3be52bce98746341cfb290203603fd028290</id>
<content type='text'>
commit 073931017b49d9458aa351605b43a7e34598caef upstream.

When file permissions are modified via chmod(2) and the user is not in
the owning group or capable of CAP_FSETID, the setgid bit is cleared in
inode_change_ok().  Setting a POSIX ACL via setxattr(2) sets the file
permissions as well as the new ACL, but doesn't clear the setgid bit in
a similar way; this allows to bypass the check in chmod(2).  Fix that.

References: CVE-2016-7097
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
[bwh: Backported to 3.2:
 - Drop changes to ceph, f2fs, hfsplus, orangefs
 - Use capable() instead of capable_wrt_inode_uidgid()
 - Update ext3 and generic_acl.c as well
 - In gfs2, jfs, and xfs, take care to avoid leaking the allocated ACL if
   posix_acl_update_mode() determines it's not needed
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 073931017b49d9458aa351605b43a7e34598caef upstream.

When file permissions are modified via chmod(2) and the user is not in
the owning group or capable of CAP_FSETID, the setgid bit is cleared in
inode_change_ok().  Setting a POSIX ACL via setxattr(2) sets the file
permissions as well as the new ACL, but doesn't clear the setgid bit in
a similar way; this allows to bypass the check in chmod(2).  Fix that.

References: CVE-2016-7097
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
[bwh: Backported to 3.2:
 - Drop changes to ceph, f2fs, hfsplus, orangefs
 - Use capable() instead of capable_wrt_inode_uidgid()
 - Update ext3 and generic_acl.c as well
 - In gfs2, jfs, and xfs, take care to avoid leaking the allocated ACL if
   posix_acl_update_mode() determines it's not needed
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: Give dentry to inode_change_ok() instead of inode</title>
<updated>2016-11-20T01:01:43+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2016-05-26T14:55:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=44b25c3e25af81daebf188ba1bc94b123ea40138'/>
<id>44b25c3e25af81daebf188ba1bc94b123ea40138</id>
<content type='text'>
commit 31051c85b5e2aaaf6315f74c72a732673632a905 upstream.

inode_change_ok() will be resposible for clearing capabilities and IMA
extended attributes and as such will need dentry. Give it as an argument
to inode_change_ok() instead of an inode. Also rename inode_change_ok()
to setattr_prepare() to better relect that it does also some
modifications in addition to checks.

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
[bwh: Backported to 3.2:
 - Drop changes to f2fs, lustre, orangefs, overlayfs
 - Adjust filenames, context
 - In nfsd, pass dentry to nfsd_sanitize_attrs()
 - In xfs, pass dentry to xfs_change_file_space(), xfs_set_mode(),
   xfs_setattr_nonsize(), and xfs_setattr_size()
 - Update ext3 as well
 - Mark pohmelfs as BROKEN; it's long dead upstream]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 31051c85b5e2aaaf6315f74c72a732673632a905 upstream.

inode_change_ok() will be resposible for clearing capabilities and IMA
extended attributes and as such will need dentry. Give it as an argument
to inode_change_ok() instead of an inode. Also rename inode_change_ok()
to setattr_prepare() to better relect that it does also some
modifications in addition to checks.

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
[bwh: Backported to 3.2:
 - Drop changes to f2fs, lustre, orangefs, overlayfs
 - Adjust filenames, context
 - In nfsd, pass dentry to nfsd_sanitize_attrs()
 - In xfs, pass dentry to xfs_change_file_space(), xfs_set_mode(),
   xfs_setattr_nonsize(), and xfs_setattr_size()
 - Update ext3 as well
 - Mark pohmelfs as BROKEN; it's long dead upstream]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipmr, ip6mr: fix scheduling while atomic and a deadlock with ipmr_get_route</title>
<updated>2016-11-20T01:01:42+00:00</updated>
<author>
<name>Nikolay Aleksandrov</name>
<email>nikolay@cumulusnetworks.com</email>
</author>
<published>2016-09-25T21:08:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ec097a17bfa108bd7480bc71f0732d856d9a9b10'/>
<id>ec097a17bfa108bd7480bc71f0732d856d9a9b10</id>
<content type='text'>
commit 2cf750704bb6d7ed8c7d732e071dd1bc890ea5e8 upstream.

Since the commit below the ipmr/ip6mr rtnl_unicast() code uses the portid
instead of the previous dst_pid which was copied from in_skb's portid.
Since the skb is new the portid is 0 at that point so the packets are sent
to the kernel and we get scheduling while atomic or a deadlock (depending
on where it happens) by trying to acquire rtnl two times.
Also since this is RTM_GETROUTE, it can be triggered by a normal user.

Here's the sleeping while atomic trace:
[ 7858.212557] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
[ 7858.212748] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
[ 7858.212881] 2 locks held by swapper/0/0:
[ 7858.213013]  #0:  (((&amp;mrt-&gt;ipmr_expire_timer))){+.-...}, at: [&lt;ffffffff810fbbf5&gt;] call_timer_fn+0x5/0x350
[ 7858.213422]  #1:  (mfc_unres_lock){+.....}, at: [&lt;ffffffff8161e005&gt;] ipmr_expire_process+0x25/0x130
[ 7858.213807] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc7+ #179
[ 7858.213934] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 7858.214108]  0000000000000000 ffff88005b403c50 ffffffff813a7804 0000000000000000
[ 7858.214412]  ffffffff81a1338e ffff88005b403c78 ffffffff810a4a72 ffffffff81a1338e
[ 7858.214716]  000000000000026c 0000000000000000 ffff88005b403ca8 ffffffff810a4b9f
[ 7858.215251] Call Trace:
[ 7858.215412]  &lt;IRQ&gt;  [&lt;ffffffff813a7804&gt;] dump_stack+0x85/0xc1
[ 7858.215662]  [&lt;ffffffff810a4a72&gt;] ___might_sleep+0x192/0x250
[ 7858.215868]  [&lt;ffffffff810a4b9f&gt;] __might_sleep+0x6f/0x100
[ 7858.216072]  [&lt;ffffffff8165bea3&gt;] mutex_lock_nested+0x33/0x4d0
[ 7858.216279]  [&lt;ffffffff815a7a5f&gt;] ? netlink_lookup+0x25f/0x460
[ 7858.216487]  [&lt;ffffffff8157474b&gt;] rtnetlink_rcv+0x1b/0x40
[ 7858.216687]  [&lt;ffffffff815a9a0c&gt;] netlink_unicast+0x19c/0x260
[ 7858.216900]  [&lt;ffffffff81573c70&gt;] rtnl_unicast+0x20/0x30
[ 7858.217128]  [&lt;ffffffff8161cd39&gt;] ipmr_destroy_unres+0xa9/0xf0
[ 7858.217351]  [&lt;ffffffff8161e06f&gt;] ipmr_expire_process+0x8f/0x130
[ 7858.217581]  [&lt;ffffffff8161dfe0&gt;] ? ipmr_net_init+0x180/0x180
[ 7858.217785]  [&lt;ffffffff8161dfe0&gt;] ? ipmr_net_init+0x180/0x180
[ 7858.217990]  [&lt;ffffffff810fbc95&gt;] call_timer_fn+0xa5/0x350
[ 7858.218192]  [&lt;ffffffff810fbbf5&gt;] ? call_timer_fn+0x5/0x350
[ 7858.218415]  [&lt;ffffffff8161dfe0&gt;] ? ipmr_net_init+0x180/0x180
[ 7858.218656]  [&lt;ffffffff810fde10&gt;] run_timer_softirq+0x260/0x640
[ 7858.218865]  [&lt;ffffffff8166379b&gt;] ? __do_softirq+0xbb/0x54f
[ 7858.219068]  [&lt;ffffffff816637c8&gt;] __do_softirq+0xe8/0x54f
[ 7858.219269]  [&lt;ffffffff8107a948&gt;] irq_exit+0xb8/0xc0
[ 7858.219463]  [&lt;ffffffff81663452&gt;] smp_apic_timer_interrupt+0x42/0x50
[ 7858.219678]  [&lt;ffffffff816625bc&gt;] apic_timer_interrupt+0x8c/0xa0
[ 7858.219897]  &lt;EOI&gt;  [&lt;ffffffff81055f16&gt;] ? native_safe_halt+0x6/0x10
[ 7858.220165]  [&lt;ffffffff810d64dd&gt;] ? trace_hardirqs_on+0xd/0x10
[ 7858.220373]  [&lt;ffffffff810298e3&gt;] default_idle+0x23/0x190
[ 7858.220574]  [&lt;ffffffff8102a20f&gt;] arch_cpu_idle+0xf/0x20
[ 7858.220790]  [&lt;ffffffff810c9f8c&gt;] default_idle_call+0x4c/0x60
[ 7858.221016]  [&lt;ffffffff810ca33b&gt;] cpu_startup_entry+0x39b/0x4d0
[ 7858.221257]  [&lt;ffffffff8164f995&gt;] rest_init+0x135/0x140
[ 7858.221469]  [&lt;ffffffff81f83014&gt;] start_kernel+0x50e/0x51b
[ 7858.221670]  [&lt;ffffffff81f82120&gt;] ? early_idt_handler_array+0x120/0x120
[ 7858.221894]  [&lt;ffffffff81f8243f&gt;] x86_64_start_reservations+0x2a/0x2c
[ 7858.222113]  [&lt;ffffffff81f8257c&gt;] x86_64_start_kernel+0x13b/0x14a

Fixes: 2942e9005056 ("[RTNETLINK]: Use rtnl_unicast() for rtnetlink unicasts")
Signed-off-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2:
 - Use 'pid' instead of 'portid' where necessary
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2cf750704bb6d7ed8c7d732e071dd1bc890ea5e8 upstream.

Since the commit below the ipmr/ip6mr rtnl_unicast() code uses the portid
instead of the previous dst_pid which was copied from in_skb's portid.
Since the skb is new the portid is 0 at that point so the packets are sent
to the kernel and we get scheduling while atomic or a deadlock (depending
on where it happens) by trying to acquire rtnl two times.
Also since this is RTM_GETROUTE, it can be triggered by a normal user.

Here's the sleeping while atomic trace:
[ 7858.212557] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
[ 7858.212748] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
[ 7858.212881] 2 locks held by swapper/0/0:
[ 7858.213013]  #0:  (((&amp;mrt-&gt;ipmr_expire_timer))){+.-...}, at: [&lt;ffffffff810fbbf5&gt;] call_timer_fn+0x5/0x350
[ 7858.213422]  #1:  (mfc_unres_lock){+.....}, at: [&lt;ffffffff8161e005&gt;] ipmr_expire_process+0x25/0x130
[ 7858.213807] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc7+ #179
[ 7858.213934] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 7858.214108]  0000000000000000 ffff88005b403c50 ffffffff813a7804 0000000000000000
[ 7858.214412]  ffffffff81a1338e ffff88005b403c78 ffffffff810a4a72 ffffffff81a1338e
[ 7858.214716]  000000000000026c 0000000000000000 ffff88005b403ca8 ffffffff810a4b9f
[ 7858.215251] Call Trace:
[ 7858.215412]  &lt;IRQ&gt;  [&lt;ffffffff813a7804&gt;] dump_stack+0x85/0xc1
[ 7858.215662]  [&lt;ffffffff810a4a72&gt;] ___might_sleep+0x192/0x250
[ 7858.215868]  [&lt;ffffffff810a4b9f&gt;] __might_sleep+0x6f/0x100
[ 7858.216072]  [&lt;ffffffff8165bea3&gt;] mutex_lock_nested+0x33/0x4d0
[ 7858.216279]  [&lt;ffffffff815a7a5f&gt;] ? netlink_lookup+0x25f/0x460
[ 7858.216487]  [&lt;ffffffff8157474b&gt;] rtnetlink_rcv+0x1b/0x40
[ 7858.216687]  [&lt;ffffffff815a9a0c&gt;] netlink_unicast+0x19c/0x260
[ 7858.216900]  [&lt;ffffffff81573c70&gt;] rtnl_unicast+0x20/0x30
[ 7858.217128]  [&lt;ffffffff8161cd39&gt;] ipmr_destroy_unres+0xa9/0xf0
[ 7858.217351]  [&lt;ffffffff8161e06f&gt;] ipmr_expire_process+0x8f/0x130
[ 7858.217581]  [&lt;ffffffff8161dfe0&gt;] ? ipmr_net_init+0x180/0x180
[ 7858.217785]  [&lt;ffffffff8161dfe0&gt;] ? ipmr_net_init+0x180/0x180
[ 7858.217990]  [&lt;ffffffff810fbc95&gt;] call_timer_fn+0xa5/0x350
[ 7858.218192]  [&lt;ffffffff810fbbf5&gt;] ? call_timer_fn+0x5/0x350
[ 7858.218415]  [&lt;ffffffff8161dfe0&gt;] ? ipmr_net_init+0x180/0x180
[ 7858.218656]  [&lt;ffffffff810fde10&gt;] run_timer_softirq+0x260/0x640
[ 7858.218865]  [&lt;ffffffff8166379b&gt;] ? __do_softirq+0xbb/0x54f
[ 7858.219068]  [&lt;ffffffff816637c8&gt;] __do_softirq+0xe8/0x54f
[ 7858.219269]  [&lt;ffffffff8107a948&gt;] irq_exit+0xb8/0xc0
[ 7858.219463]  [&lt;ffffffff81663452&gt;] smp_apic_timer_interrupt+0x42/0x50
[ 7858.219678]  [&lt;ffffffff816625bc&gt;] apic_timer_interrupt+0x8c/0xa0
[ 7858.219897]  &lt;EOI&gt;  [&lt;ffffffff81055f16&gt;] ? native_safe_halt+0x6/0x10
[ 7858.220165]  [&lt;ffffffff810d64dd&gt;] ? trace_hardirqs_on+0xd/0x10
[ 7858.220373]  [&lt;ffffffff810298e3&gt;] default_idle+0x23/0x190
[ 7858.220574]  [&lt;ffffffff8102a20f&gt;] arch_cpu_idle+0xf/0x20
[ 7858.220790]  [&lt;ffffffff810c9f8c&gt;] default_idle_call+0x4c/0x60
[ 7858.221016]  [&lt;ffffffff810ca33b&gt;] cpu_startup_entry+0x39b/0x4d0
[ 7858.221257]  [&lt;ffffffff8164f995&gt;] rest_init+0x135/0x140
[ 7858.221469]  [&lt;ffffffff81f83014&gt;] start_kernel+0x50e/0x51b
[ 7858.221670]  [&lt;ffffffff81f82120&gt;] ? early_idt_handler_array+0x120/0x120
[ 7858.221894]  [&lt;ffffffff81f8243f&gt;] x86_64_start_reservations+0x2a/0x2c
[ 7858.222113]  [&lt;ffffffff81f8257c&gt;] x86_64_start_kernel+0x13b/0x14a

Fixes: 2942e9005056 ("[RTNETLINK]: Use rtnl_unicast() for rtnetlink unicasts")
Signed-off-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2:
 - Use 'pid' instead of 'portid' where necessary
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
