<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include, branch v4.9.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>IB/cma: Fix a race condition in iboe_addr_get_sgid()</title>
<updated>2017-01-09T07:32:23+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2016-12-19T17:00:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9aff8b170fe01cb01cdcce2590dd135925570f1b'/>
<id>9aff8b170fe01cb01cdcce2590dd135925570f1b</id>
<content type='text'>
commit fba332b079029c2f4f7e84c1c1cd8e3867310c90 upstream.

Code that dereferences the struct net_device ip_ptr member must be
protected with an in_dev_get() / in_dev_put() pair. Hence insert
calls to these functions.

Fixes: commit 7b85627b9f02 ("IB/cma: IBoE (RoCE) IP-based GID addressing")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Reviewed-by: Moni Shoua &lt;monis@mellanox.com&gt;
Cc: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Cc: Roland Dreier &lt;roland@purestorage.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit fba332b079029c2f4f7e84c1c1cd8e3867310c90 upstream.

Code that dereferences the struct net_device ip_ptr member must be
protected with an in_dev_get() / in_dev_put() pair. Hence insert
calls to these functions.

Fixes: commit 7b85627b9f02 ("IB/cma: IBoE (RoCE) IP-based GID addressing")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Reviewed-by: Moni Shoua &lt;monis@mellanox.com&gt;
Cc: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Cc: Roland Dreier &lt;roland@purestorage.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts</title>
<updated>2017-01-09T07:32:17+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2016-12-08T16:22:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1976c7689a58405e076d7443e4f9f4805d86d935'/>
<id>1976c7689a58405e076d7443e4f9f4805d86d935</id>
<content type='text'>
commit e6f462df9acd2a3295e5d34eb29e2823220cf129 upstream.

When mac80211 abandons an association attempt, it may free
all the data structures, but inform cfg80211 and userspace
about it only by sending the deauth frame it received, in
which case cfg80211 has no link to the BSS struct that was
used and will not cfg80211_unhold_bss() it.

Fix this by providing a way to inform cfg80211 of this with
the BSS entry passed, so that it can clean up properly, and
use this ability in the appropriate places in mac80211.

This isn't ideal: some code is more or less duplicated and
tracing is missing. However, it's a fairly small change and
it's thus easier to backport - cleanups can come later.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e6f462df9acd2a3295e5d34eb29e2823220cf129 upstream.

When mac80211 abandons an association attempt, it may free
all the data structures, but inform cfg80211 and userspace
about it only by sending the deauth frame it received, in
which case cfg80211 has no link to the BSS struct that was
used and will not cfg80211_unhold_bss() it.

Fix this by providing a way to inform cfg80211 of this with
the BSS entry passed, so that it can clean up properly, and
use this ability in the appropriate places in mac80211.

This isn't ideal: some code is more or less duplicated and
tracing is missing. However, it's a fairly small change and
it's thus easier to backport - cleanups can come later.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/kbuild: enable modversions for symbols exported from asm</title>
<updated>2017-01-06T09:40:17+00:00</updated>
<author>
<name>Adam Borowski</name>
<email>kilobyte@angband.pl</email>
</author>
<published>2016-12-11T01:09:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=705df55bd0cf3530cc7e2b517f77d14585d3d24f'/>
<id>705df55bd0cf3530cc7e2b517f77d14585d3d24f</id>
<content type='text'>
commit 334bb773876403eae3457d81be0b8ea70f8e4ccc upstream.

Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds
modversion support for symbols exported from asm files. Architectures
must include C-style declarations for those symbols in asm/asm-prototypes.h
in order for them to be versioned.

Add these declarations for x86, and an architecture-independent file that
can be used for common symbols.

With f27c2f6 reverting 8ab2ae6 ("default exported asm symbols to zero") we
produce a scary warning on x86, this commit fixes that.

Signed-off-by: Adam Borowski &lt;kilobyte@angband.pl&gt;
Tested-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Acked-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Tested-by: Peter Wu &lt;peter@lekensteyn.nl&gt;
Tested-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 334bb773876403eae3457d81be0b8ea70f8e4ccc upstream.

Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds
modversion support for symbols exported from asm files. Architectures
must include C-style declarations for those symbols in asm/asm-prototypes.h
in order for them to be versioned.

Add these declarations for x86, and an architecture-independent file that
can be used for common symbols.

With f27c2f6 reverting 8ab2ae6 ("default exported asm symbols to zero") we
produce a scary warning on x86, this commit fixes that.

Signed-off-by: Adam Borowski &lt;kilobyte@angband.pl&gt;
Tested-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Acked-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Tested-by: Peter Wu &lt;peter@lekensteyn.nl&gt;
Tested-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PM / OPP: Pass opp_table to dev_pm_opp_put_regulator()</title>
<updated>2017-01-06T09:40:15+00:00</updated>
<author>
<name>Stephen Boyd</name>
<email>sboyd@codeaurora.org</email>
</author>
<published>2016-11-30T10:51:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c7a8a0ac8fee26d3c20402da306a17bcbbbb367b'/>
<id>c7a8a0ac8fee26d3c20402da306a17bcbbbb367b</id>
<content type='text'>
commit 91291d9ad92faa65a56a9a19d658d8049b78d3d4 upstream.

Joonyoung Shim reported an interesting problem on his ARM octa-core
Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
was failing for a struct device for which dev_pm_opp_set_regulator() is
called earlier.

This happened because an earlier call to
dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
removed all the entries from opp_table-&gt;dev_list apart from the last CPU
device in the cpumask of CPUs sharing the OPP.

But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
routines get CPU device for the first CPU in the cpumask. And so the OPP
core failed to find the OPP table for the struct device.

This patch attempts to fix this problem by returning a pointer to the
opp_table from dev_pm_opp_set_regulator() and using that as the
parameter to dev_pm_opp_put_regulator(). This ensures that the
dev_pm_opp_put_regulator() doesn't fail to find the opp table.

Note that similar design problem also exists with other
dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
so we don't need to update them for now.

Reported-by: Joonyoung Shim &lt;jy0922.shim@samsung.com&gt;
Signed-off-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
[ Viresh: Wrote commit log and tested on exynos 5250 ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 91291d9ad92faa65a56a9a19d658d8049b78d3d4 upstream.

Joonyoung Shim reported an interesting problem on his ARM octa-core
Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
was failing for a struct device for which dev_pm_opp_set_regulator() is
called earlier.

This happened because an earlier call to
dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
removed all the entries from opp_table-&gt;dev_list apart from the last CPU
device in the cpumask of CPUs sharing the OPP.

But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
routines get CPU device for the first CPU in the cpumask. And so the OPP
core failed to find the OPP table for the struct device.

This patch attempts to fix this problem by returning a pointer to the
opp_table from dev_pm_opp_set_regulator() and using that as the
parameter to dev_pm_opp_put_regulator(). This ensures that the
dev_pm_opp_put_regulator() doesn't fail to find the opp table.

Note that similar design problem also exists with other
dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
so we don't need to update them for now.

Reported-by: Joonyoung Shim &lt;jy0922.shim@samsung.com&gt;
Signed-off-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
[ Viresh: Wrote commit log and tested on exynos 5250 ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ptrace: Don't allow accessing an undumpable mm</title>
<updated>2017-01-06T09:40:13+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2016-11-22T18:06:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e71b4e061c9677cef1f1f38fd7236e198fab1287'/>
<id>e71b4e061c9677cef1f1f38fd7236e198fab1287</id>
<content type='text'>
commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3 upstream.

It is the reasonable expectation that if an executable file is not
readable there will be no way for a user without special privileges to
read the file.  This is enforced in ptrace_attach but if ptrace
is already attached before exec there is no enforcement for read-only
executables.

As the only way to read such an mm is through access_process_vm
spin a variant called ptrace_access_vm that will fail if the
target process is not being ptraced by the current process, or
the current process did not have sufficient privileges when ptracing
began to read the target processes mm.

In the ptrace implementations replace access_process_vm by
ptrace_access_vm.  There remain several ptrace sites that still use
access_process_vm as they are reading the target executables
instructions (for kernel consumption) or register stacks.  As such it
does not appear necessary to add a permission check to those calls.

This bug has always existed in Linux.

Fixes: v1.0
Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3 upstream.

It is the reasonable expectation that if an executable file is not
readable there will be no way for a user without special privileges to
read the file.  This is enforced in ptrace_attach but if ptrace
is already attached before exec there is no enforcement for read-only
executables.

As the only way to read such an mm is through access_process_vm
spin a variant called ptrace_access_vm that will fail if the
target process is not being ptraced by the current process, or
the current process did not have sufficient privileges when ptracing
began to read the target processes mm.

In the ptrace implementations replace access_process_vm by
ptrace_access_vm.  There remain several ptrace sites that still use
access_process_vm as they are reading the target executables
instructions (for kernel consumption) or register stacks.  As such it
does not appear necessary to add a permission check to those calls.

This bug has always existed in Linux.

Fixes: v1.0
Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ptrace: Capture the ptracer's creds not PT_PTRACE_CAP</title>
<updated>2017-01-06T09:40:13+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2016-11-15T00:48:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e747b4ae3b6bca205d82e86366e140cdcbfb7731'/>
<id>e747b4ae3b6bca205d82e86366e140cdcbfb7731</id>
<content type='text'>
commit 64b875f7ac8a5d60a4e191479299e931ee949b67 upstream.

When the flag PT_PTRACE_CAP was added the PTRACE_TRACEME path was
overlooked.  This can result in incorrect behavior when an application
like strace traces an exec of a setuid executable.

Further PT_PTRACE_CAP does not have enough information for making good
security decisions as it does not report which user namespace the
capability is in.  This has already allowed one mistake through
insufficient granulariy.

I found this issue when I was testing another corner case of exec and
discovered that I could not get strace to set PT_PTRACE_CAP even when
running strace as root with a full set of caps.

This change fixes the above issue with strace allowing stracing as
root a setuid executable without disabling setuid.  More fundamentaly
this change allows what is allowable at all times, by using the correct
information in it's decision.

Fixes: 4214e42f96d4 ("v2.4.9.11 -&gt; v2.4.9.12")
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 64b875f7ac8a5d60a4e191479299e931ee949b67 upstream.

When the flag PT_PTRACE_CAP was added the PTRACE_TRACEME path was
overlooked.  This can result in incorrect behavior when an application
like strace traces an exec of a setuid executable.

Further PT_PTRACE_CAP does not have enough information for making good
security decisions as it does not report which user namespace the
capability is in.  This has already allowed one mistake through
insufficient granulariy.

I found this issue when I was testing another corner case of exec and
discovered that I could not get strace to set PT_PTRACE_CAP even when
running strace as root with a full set of caps.

This change fixes the above issue with strace allowing stracing as
root a setuid executable without disabling setuid.  More fundamentaly
this change allows what is allowable at all times, by using the correct
information in it's decision.

Fixes: 4214e42f96d4 ("v2.4.9.11 -&gt; v2.4.9.12")
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mm: Add a user_ns owner to mm_struct and fix ptrace permission checks</title>
<updated>2017-01-06T09:40:13+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2016-10-14T02:23:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=694a95fa6dae4991f16cda333d897ea063021fed'/>
<id>694a95fa6dae4991f16cda333d897ea063021fed</id>
<content type='text'>
commit bfedb589252c01fa505ac9f6f2a3d5d68d707ef4 upstream.

During exec dumpable is cleared if the file that is being executed is
not readable by the user executing the file.  A bug in
ptrace_may_access allows reading the file if the executable happens to
enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).

This problem is fixed with only necessary userspace breakage by adding
a user namespace owner to mm_struct, captured at the time of exec, so
it is clear in which user namespace CAP_SYS_PTRACE must be present in
to be able to safely give read permission to the executable.

The function ptrace_may_access is modified to verify that the ptracer
has CAP_SYS_ADMIN in task-&gt;mm-&gt;user_ns instead of task-&gt;cred-&gt;user_ns.
This ensures that if the task changes it's cred into a subordinate
user namespace it does not become ptraceable.

The function ptrace_attach is modified to only set PT_PTRACE_CAP when
CAP_SYS_PTRACE is held over task-&gt;mm-&gt;user_ns.  The intent of
PT_PTRACE_CAP is to be a flag to note that whatever permission changes
the task might go through the tracer has sufficient permissions for
it not to be an issue.  task-&gt;cred-&gt;user_ns is always the same
as or descendent of mm-&gt;user_ns.  Which guarantees that having
CAP_SYS_PTRACE over mm-&gt;user_ns is the worst case for the tasks
credentials.

To prevent regressions mm-&gt;dumpable and mm-&gt;user_ns are not considered
when a task has no mm.  As simply failing ptrace_may_attach causes
regressions in privileged applications attempting to read things
such as /proc/&lt;pid&gt;/stat

Acked-by: Kees Cook &lt;keescook@chromium.org&gt;
Tested-by: Cyrill Gorcunov &lt;gorcunov@openvz.org&gt;
Fixes: 8409cca70561 ("userns: allow ptrace from non-init user namespaces")
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bfedb589252c01fa505ac9f6f2a3d5d68d707ef4 upstream.

During exec dumpable is cleared if the file that is being executed is
not readable by the user executing the file.  A bug in
ptrace_may_access allows reading the file if the executable happens to
enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).

This problem is fixed with only necessary userspace breakage by adding
a user namespace owner to mm_struct, captured at the time of exec, so
it is clear in which user namespace CAP_SYS_PTRACE must be present in
to be able to safely give read permission to the executable.

The function ptrace_may_access is modified to verify that the ptracer
has CAP_SYS_ADMIN in task-&gt;mm-&gt;user_ns instead of task-&gt;cred-&gt;user_ns.
This ensures that if the task changes it's cred into a subordinate
user namespace it does not become ptraceable.

The function ptrace_attach is modified to only set PT_PTRACE_CAP when
CAP_SYS_PTRACE is held over task-&gt;mm-&gt;user_ns.  The intent of
PT_PTRACE_CAP is to be a flag to note that whatever permission changes
the task might go through the tracer has sufficient permissions for
it not to be an issue.  task-&gt;cred-&gt;user_ns is always the same
as or descendent of mm-&gt;user_ns.  Which guarantees that having
CAP_SYS_PTRACE over mm-&gt;user_ns is the worst case for the tasks
credentials.

To prevent regressions mm-&gt;dumpable and mm-&gt;user_ns are not considered
when a task has no mm.  As simply failing ptrace_may_attach causes
regressions in privileged applications attempting to read things
such as /proc/&lt;pid&gt;/stat

Acked-by: Kees Cook &lt;keescook@chromium.org&gt;
Tested-by: Cyrill Gorcunov &lt;gorcunov@openvz.org&gt;
Fixes: 8409cca70561 ("userns: allow ptrace from non-init user namespaces")
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>exec: Ensure mm-&gt;user_ns contains the execed files</title>
<updated>2017-01-06T09:40:12+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2016-11-17T04:06:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=21245b8635e8636e9e01df06f33cf08f369322b7'/>
<id>21245b8635e8636e9e01df06f33cf08f369322b7</id>
<content type='text'>
commit f84df2a6f268de584a201e8911384a2d244876e3 upstream.

When the user namespace support was merged the need to prevent
ptrace from revealing the contents of an unreadable executable
was overlooked.

Correct this oversight by ensuring that the executed file
or files are in mm-&gt;user_ns, by adjusting mm-&gt;user_ns.

Use the new function privileged_wrt_inode_uidgid to see if
the executable is a member of the user namespace, and as such
if having CAP_SYS_PTRACE in the user namespace should allow
tracing the executable.  If not update mm-&gt;user_ns to
the parent user namespace until an appropriate parent is found.

Reported-by: Jann Horn &lt;jann@thejh.net&gt;
Fixes: 9e4a36ece652 ("userns: Fail exec for suid and sgid binaries with ids outside our user namespace.")
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f84df2a6f268de584a201e8911384a2d244876e3 upstream.

When the user namespace support was merged the need to prevent
ptrace from revealing the contents of an unreadable executable
was overlooked.

Correct this oversight by ensuring that the executed file
or files are in mm-&gt;user_ns, by adjusting mm-&gt;user_ns.

Use the new function privileged_wrt_inode_uidgid to see if
the executable is a member of the user namespace, and as such
if having CAP_SYS_PTRACE in the user namespace should allow
tracing the executable.  If not update mm-&gt;user_ns to
the parent user namespace until an appropriate parent is found.

Reported-by: Jann Horn &lt;jann@thejh.net&gt;
Fixes: 9e4a36ece652 ("userns: Fail exec for suid and sgid binaries with ids outside our user namespace.")
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>hotplug: Make register and unregister notifier API symmetric</title>
<updated>2017-01-06T09:40:10+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=56eaecc8ecf398c7af3fa252eff6164102b0ace1'/>
<id>56eaecc8ecf398c7af3fa252eff6164102b0ace1</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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2016-12-10T17:23:19+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-12-10T17:23:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cd6628953e4216b65e7d91ab70ff8e5b65c9fde9'/>
<id>cd6628953e4216b65e7d91ab70ff8e5b65c9fde9</id>
<content type='text'>
Pull networking fixes from David Miller:

 1) Limit the number of can filters to avoid &gt; MAX_ORDER allocations.
    Fix from Marc Kleine-Budde.

 2) Limit GSO max size in netvsc driver to avoid problems with NVGRE
    configurations. From Stephen Hemminger.

 3) Return proper error when memory allocation fails in
    ser_gigaset_init(), from Dan Carpenter.

 4) Missing linkage undo in error paths of ipvlan_link_new(), from Gao
    Feng.

 5) Missing necessayr SET_NETDEV_DEV in lantiq and cpmac drivers, from
    Florian Fainelli.

 6) Handle probe deferral properly in smsc911x driver.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  net: mlx5: Fix Kconfig help text
  net: smsc911x: back out silently on probe deferrals
  ibmveth: set correct gso_size and gso_type
  net: ethernet: cpmac: Call SET_NETDEV_DEV()
  net: ethernet: lantiq_etop: Call SET_NETDEV_DEV()
  vhost-vsock: fix orphan connection reset
  cxgb4/cxgb4vf: Assign netdev-&gt;dev_port with port ID
  driver: ipvlan: Unlink the upper dev when ipvlan_link_new failed
  ser_gigaset: return -ENOMEM on error instead of success
  NET: usb: cdc_mbim: add quirk for supporting Telit LE922A
  can: peak: fix bad memory access and free sequence
  phy: Don't increment MDIO bus refcount unless it's a different owner
  netvsc: reduce maximum GSO size
  drivers: net: cpsw-phy-sel: Clear RGMII_IDMODE on "rgmii" links
  can: raw: raw_setsockopt: limit number of can_filter that can be set
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull networking fixes from David Miller:

 1) Limit the number of can filters to avoid &gt; MAX_ORDER allocations.
    Fix from Marc Kleine-Budde.

 2) Limit GSO max size in netvsc driver to avoid problems with NVGRE
    configurations. From Stephen Hemminger.

 3) Return proper error when memory allocation fails in
    ser_gigaset_init(), from Dan Carpenter.

 4) Missing linkage undo in error paths of ipvlan_link_new(), from Gao
    Feng.

 5) Missing necessayr SET_NETDEV_DEV in lantiq and cpmac drivers, from
    Florian Fainelli.

 6) Handle probe deferral properly in smsc911x driver.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  net: mlx5: Fix Kconfig help text
  net: smsc911x: back out silently on probe deferrals
  ibmveth: set correct gso_size and gso_type
  net: ethernet: cpmac: Call SET_NETDEV_DEV()
  net: ethernet: lantiq_etop: Call SET_NETDEV_DEV()
  vhost-vsock: fix orphan connection reset
  cxgb4/cxgb4vf: Assign netdev-&gt;dev_port with port ID
  driver: ipvlan: Unlink the upper dev when ipvlan_link_new failed
  ser_gigaset: return -ENOMEM on error instead of success
  NET: usb: cdc_mbim: add quirk for supporting Telit LE922A
  can: peak: fix bad memory access and free sequence
  phy: Don't increment MDIO bus refcount unless it's a different owner
  netvsc: reduce maximum GSO size
  drivers: net: cpsw-phy-sel: Clear RGMII_IDMODE on "rgmii" links
  can: raw: raw_setsockopt: limit number of can_filter that can be set
</pre>
</div>
</content>
</entry>
</feed>
