<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/fs/proc, branch v3.12.71</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>sysctl: Drop reference added by grab_header in proc_sys_readdir</title>
<updated>2017-01-26T16:40:44+00:00</updated>
<author>
<name>Zhou Chengming</name>
<email>zhouchengming1@huawei.com</email>
</author>
<published>2017-01-06T01:32:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=baa7295e1d686a443c0c23156b0bc9058d783aa4'/>
<id>baa7295e1d686a443c0c23156b0bc9058d783aa4</id>
<content type='text'>
commit 93362fa47fe98b62e4a34ab408c4a418432e7939 upstream.

Fixes CVE-2016-9191, proc_sys_readdir doesn't drop reference
added by grab_header when return from !dir_emit_dots path.
It can cause any path called unregister_sysctl_table will
wait forever.

The calltrace of CVE-2016-9191:

[ 5535.960522] Call Trace:
[ 5535.963265]  [&lt;ffffffff817cdaaf&gt;] schedule+0x3f/0xa0
[ 5535.968817]  [&lt;ffffffff817d33fb&gt;] schedule_timeout+0x3db/0x6f0
[ 5535.975346]  [&lt;ffffffff817cf055&gt;] ? wait_for_completion+0x45/0x130
[ 5535.982256]  [&lt;ffffffff817cf0d3&gt;] wait_for_completion+0xc3/0x130
[ 5535.988972]  [&lt;ffffffff810d1fd0&gt;] ? wake_up_q+0x80/0x80
[ 5535.994804]  [&lt;ffffffff8130de64&gt;] drop_sysctl_table+0xc4/0xe0
[ 5536.001227]  [&lt;ffffffff8130de17&gt;] drop_sysctl_table+0x77/0xe0
[ 5536.007648]  [&lt;ffffffff8130decd&gt;] unregister_sysctl_table+0x4d/0xa0
[ 5536.014654]  [&lt;ffffffff8130deff&gt;] unregister_sysctl_table+0x7f/0xa0
[ 5536.021657]  [&lt;ffffffff810f57f5&gt;] unregister_sched_domain_sysctl+0x15/0x40
[ 5536.029344]  [&lt;ffffffff810d7704&gt;] partition_sched_domains+0x44/0x450
[ 5536.036447]  [&lt;ffffffff817d0761&gt;] ? __mutex_unlock_slowpath+0x111/0x1f0
[ 5536.043844]  [&lt;ffffffff81167684&gt;] rebuild_sched_domains_locked+0x64/0xb0
[ 5536.051336]  [&lt;ffffffff8116789d&gt;] update_flag+0x11d/0x210
[ 5536.057373]  [&lt;ffffffff817cf61f&gt;] ? mutex_lock_nested+0x2df/0x450
[ 5536.064186]  [&lt;ffffffff81167acb&gt;] ? cpuset_css_offline+0x1b/0x60
[ 5536.070899]  [&lt;ffffffff810fce3d&gt;] ? trace_hardirqs_on+0xd/0x10
[ 5536.077420]  [&lt;ffffffff817cf61f&gt;] ? mutex_lock_nested+0x2df/0x450
[ 5536.084234]  [&lt;ffffffff8115a9f5&gt;] ? css_killed_work_fn+0x25/0x220
[ 5536.091049]  [&lt;ffffffff81167ae5&gt;] cpuset_css_offline+0x35/0x60
[ 5536.097571]  [&lt;ffffffff8115aa2c&gt;] css_killed_work_fn+0x5c/0x220
[ 5536.104207]  [&lt;ffffffff810bc83f&gt;] process_one_work+0x1df/0x710
[ 5536.110736]  [&lt;ffffffff810bc7c0&gt;] ? process_one_work+0x160/0x710
[ 5536.117461]  [&lt;ffffffff810bce9b&gt;] worker_thread+0x12b/0x4a0
[ 5536.123697]  [&lt;ffffffff810bcd70&gt;] ? process_one_work+0x710/0x710
[ 5536.130426]  [&lt;ffffffff810c3f7e&gt;] kthread+0xfe/0x120
[ 5536.135991]  [&lt;ffffffff817d4baf&gt;] ret_from_fork+0x1f/0x40
[ 5536.142041]  [&lt;ffffffff810c3e80&gt;] ? kthread_create_on_node+0x230/0x230

One cgroup maintainer mentioned that "cgroup is trying to offline
a cpuset css, which takes place under cgroup_mutex.  The offlining
ends up trying to drain active usages of a sysctl table which apprently
is not happening."
The real reason is that proc_sys_readdir doesn't drop reference added
by grab_header when return from !dir_emit_dots path. So this cpuset
offline path will wait here forever.

See here for details: http://www.openwall.com/lists/oss-security/2016/11/04/13

Fixes: f0c3b5093add ("[readdir] convert procfs")
Reported-by: CAI Qian &lt;caiqian@redhat.com&gt;
Tested-by: Yang Shukui &lt;yangshukui@huawei.com&gt;
Signed-off-by: Zhou Chengming &lt;zhouchengming1@huawei.com&gt;
Acked-by: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;
Signed-off-by: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

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

Fixes CVE-2016-9191, proc_sys_readdir doesn't drop reference
added by grab_header when return from !dir_emit_dots path.
It can cause any path called unregister_sysctl_table will
wait forever.

The calltrace of CVE-2016-9191:

[ 5535.960522] Call Trace:
[ 5535.963265]  [&lt;ffffffff817cdaaf&gt;] schedule+0x3f/0xa0
[ 5535.968817]  [&lt;ffffffff817d33fb&gt;] schedule_timeout+0x3db/0x6f0
[ 5535.975346]  [&lt;ffffffff817cf055&gt;] ? wait_for_completion+0x45/0x130
[ 5535.982256]  [&lt;ffffffff817cf0d3&gt;] wait_for_completion+0xc3/0x130
[ 5535.988972]  [&lt;ffffffff810d1fd0&gt;] ? wake_up_q+0x80/0x80
[ 5535.994804]  [&lt;ffffffff8130de64&gt;] drop_sysctl_table+0xc4/0xe0
[ 5536.001227]  [&lt;ffffffff8130de17&gt;] drop_sysctl_table+0x77/0xe0
[ 5536.007648]  [&lt;ffffffff8130decd&gt;] unregister_sysctl_table+0x4d/0xa0
[ 5536.014654]  [&lt;ffffffff8130deff&gt;] unregister_sysctl_table+0x7f/0xa0
[ 5536.021657]  [&lt;ffffffff810f57f5&gt;] unregister_sched_domain_sysctl+0x15/0x40
[ 5536.029344]  [&lt;ffffffff810d7704&gt;] partition_sched_domains+0x44/0x450
[ 5536.036447]  [&lt;ffffffff817d0761&gt;] ? __mutex_unlock_slowpath+0x111/0x1f0
[ 5536.043844]  [&lt;ffffffff81167684&gt;] rebuild_sched_domains_locked+0x64/0xb0
[ 5536.051336]  [&lt;ffffffff8116789d&gt;] update_flag+0x11d/0x210
[ 5536.057373]  [&lt;ffffffff817cf61f&gt;] ? mutex_lock_nested+0x2df/0x450
[ 5536.064186]  [&lt;ffffffff81167acb&gt;] ? cpuset_css_offline+0x1b/0x60
[ 5536.070899]  [&lt;ffffffff810fce3d&gt;] ? trace_hardirqs_on+0xd/0x10
[ 5536.077420]  [&lt;ffffffff817cf61f&gt;] ? mutex_lock_nested+0x2df/0x450
[ 5536.084234]  [&lt;ffffffff8115a9f5&gt;] ? css_killed_work_fn+0x25/0x220
[ 5536.091049]  [&lt;ffffffff81167ae5&gt;] cpuset_css_offline+0x35/0x60
[ 5536.097571]  [&lt;ffffffff8115aa2c&gt;] css_killed_work_fn+0x5c/0x220
[ 5536.104207]  [&lt;ffffffff810bc83f&gt;] process_one_work+0x1df/0x710
[ 5536.110736]  [&lt;ffffffff810bc7c0&gt;] ? process_one_work+0x160/0x710
[ 5536.117461]  [&lt;ffffffff810bce9b&gt;] worker_thread+0x12b/0x4a0
[ 5536.123697]  [&lt;ffffffff810bcd70&gt;] ? process_one_work+0x710/0x710
[ 5536.130426]  [&lt;ffffffff810c3f7e&gt;] kthread+0xfe/0x120
[ 5536.135991]  [&lt;ffffffff817d4baf&gt;] ret_from_fork+0x1f/0x40
[ 5536.142041]  [&lt;ffffffff810c3e80&gt;] ? kthread_create_on_node+0x230/0x230

One cgroup maintainer mentioned that "cgroup is trying to offline
a cpuset css, which takes place under cgroup_mutex.  The offlining
ends up trying to drain active usages of a sysctl table which apprently
is not happening."
The real reason is that proc_sys_readdir doesn't drop reference added
by grab_header when return from !dir_emit_dots path. So this cpuset
offline path will wait here forever.

See here for details: http://www.openwall.com/lists/oss-security/2016/11/04/13

Fixes: f0c3b5093add ("[readdir] convert procfs")
Reported-by: CAI Qian &lt;caiqian@redhat.com&gt;
Tested-by: Yang Shukui &lt;yangshukui@huawei.com&gt;
Signed-off-by: Zhou Chengming &lt;zhouchengming1@huawei.com&gt;
Acked-by: Al Viro &lt;viro@ZenIV.linux.org.uk&gt;
Signed-off-by: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>proc: prevent accessing /proc/&lt;PID&gt;/environ until it's ready</title>
<updated>2016-05-11T09:37:33+00:00</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@googlemail.com</email>
</author>
<published>2016-05-05T23:22:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cdfaba237820a99bad60d947530725151a611ca0'/>
<id>cdfaba237820a99bad60d947530725151a611ca0</id>
<content type='text'>
commit 8148a73c9901a8794a50f950083c00ccf97d43b3 upstream.

If /proc/&lt;PID&gt;/environ gets read before the envp[] array is fully set up
in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to
read more bytes than are actually written, as env_start will already be
set but env_end will still be zero, making the range calculation
underflow, allowing to read beyond the end of what has been written.

Fix this as it is done for /proc/&lt;PID&gt;/cmdline by testing env_end for
zero.  It is, apparently, intentionally set last in create_*_tables().

This bug was found by the PaX size_overflow plugin that detected the
arithmetic underflow of 'this_len = env_end - (env_start + src)' when
env_end is still zero.

The expected consequence is that userland trying to access
/proc/&lt;PID&gt;/environ of a not yet fully set up process may get
inconsistent data as we're in the middle of copying in the environment
variables.

Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&amp;t=4363
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461
Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Emese Revfy &lt;re.emese@gmail.com&gt;
Cc: Pax Team &lt;pageexec@freemail.hu&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Mateusz Guzik &lt;mguzik@redhat.com&gt;
Cc: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Cc: Cyrill Gorcunov &lt;gorcunov@openvz.org&gt;
Cc: Jarod Wilson &lt;jarod@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

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

If /proc/&lt;PID&gt;/environ gets read before the envp[] array is fully set up
in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to
read more bytes than are actually written, as env_start will already be
set but env_end will still be zero, making the range calculation
underflow, allowing to read beyond the end of what has been written.

Fix this as it is done for /proc/&lt;PID&gt;/cmdline by testing env_end for
zero.  It is, apparently, intentionally set last in create_*_tables().

This bug was found by the PaX size_overflow plugin that detected the
arithmetic underflow of 'this_len = env_end - (env_start + src)' when
env_end is still zero.

The expected consequence is that userland trying to access
/proc/&lt;PID&gt;/environ of a not yet fully set up process may get
inconsistent data as we're in the middle of copying in the environment
variables.

Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&amp;t=4363
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461
Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Emese Revfy &lt;re.emese@gmail.com&gt;
Cc: Pax Team &lt;pageexec@freemail.hu&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Mateusz Guzik &lt;mguzik@redhat.com&gt;
Cc: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Cc: Cyrill Gorcunov &lt;gorcunov@openvz.org&gt;
Cc: Jarod Wilson &lt;jarod@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>proc: Fix ptrace-based permission checks for accessing task maps</title>
<updated>2016-03-02T09:29:36+00:00</updated>
<author>
<name>Corey Wright</name>
<email>undefined@pobox.com</email>
</author>
<published>2016-02-28T08:42:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fa69c2b418d7aaae8d14810caecc9bfe3f44b4e5'/>
<id>fa69c2b418d7aaae8d14810caecc9bfe3f44b4e5</id>
<content type='text'>
Modify mm_access() calls in fs/proc/task_mmu.c and fs/proc/task_nommu.c to
have the mode include PTRACE_MODE_FSCREDS so accessing /proc/pid/maps and
/proc/pid/pagemap is not denied to all users.

In backporting upstream commit caaee623 to pre-3.18 kernel versions it was
overlooked that mm_access() is used in fs/proc/task_*mmu.c as those calls
were removed in 3.18 (by upstream commit 29a40ace) and did not exist at the
time of the original commit.

Fixes: caaee6234d ("ptrace: use fsuid, fsgid, effective creds for fs access checks")
Signed-off-by: Corey Wright &lt;undefined@pobox.com&gt;
Acked-by: Jann Horn &lt;jann@thejh.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Modify mm_access() calls in fs/proc/task_mmu.c and fs/proc/task_nommu.c to
have the mode include PTRACE_MODE_FSCREDS so accessing /proc/pid/maps and
/proc/pid/pagemap is not denied to all users.

In backporting upstream commit caaee623 to pre-3.18 kernel versions it was
overlooked that mm_access() is used in fs/proc/task_*mmu.c as those calls
were removed in 3.18 (by upstream commit 29a40ace) and did not exist at the
time of the original commit.

Fixes: caaee6234d ("ptrace: use fsuid, fsgid, effective creds for fs access checks")
Signed-off-by: Corey Wright &lt;undefined@pobox.com&gt;
Acked-by: Jann Horn &lt;jann@thejh.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ptrace: use fsuid, fsgid, effective creds for fs access checks</title>
<updated>2016-02-24T09:23:22+00:00</updated>
<author>
<name>Jann Horn</name>
<email>jann@thejh.net</email>
</author>
<published>2016-01-20T23:00:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=66d3ad932a161c39dd672dd84afb94d27ea3eedb'/>
<id>66d3ad932a161c39dd672dd84afb94d27ea3eedb</id>
<content type='text'>
commit caaee6234d05a58c5b4d05e7bf766131b810a657 upstream.

By checking the effective credentials instead of the real UID / permitted
capabilities, ensure that the calling process actually intended to use its
credentials.

To ensure that all ptrace checks use the correct caller credentials (e.g.
in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS
flag), use two new flags and require one of them to be set.

The problem was that when a privileged task had temporarily dropped its
privileges, e.g.  by calling setreuid(0, user_uid), with the intent to
perform following syscalls with the credentials of a user, it still passed
ptrace access checks that the user would not be able to pass.

While an attacker should not be able to convince the privileged task to
perform a ptrace() syscall, this is a problem because the ptrace access
check is reused for things in procfs.

In particular, the following somewhat interesting procfs entries only rely
on ptrace access checks:

 /proc/$pid/stat - uses the check for determining whether pointers
     should be visible, useful for bypassing ASLR
 /proc/$pid/maps - also useful for bypassing ASLR
 /proc/$pid/cwd - useful for gaining access to restricted
     directories that contain files with lax permissions, e.g. in
     this scenario:
     lrwxrwxrwx root root /proc/13020/cwd -&gt; /root/foobar
     drwx------ root root /root
     drwxr-xr-x root root /root/foobar
     -rw-r--r-- root root /root/foobar/secret

Therefore, on a system where a root-owned mode 6755 binary changes its
effective credentials as described and then dumps a user-specified file,
this could be used by an attacker to reveal the memory layout of root's
processes or reveal the contents of files he is not allowed to access
(through /proc/$pid/cwd).

[akpm@linux-foundation.org: fix warning]
Signed-off-by: Jann Horn &lt;jann@thejh.net&gt;
Acked-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: James Morris &lt;james.l.morris@oracle.com&gt;
Cc: "Serge E. Hallyn" &lt;serge.hallyn@ubuntu.com&gt;
Cc: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

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

By checking the effective credentials instead of the real UID / permitted
capabilities, ensure that the calling process actually intended to use its
credentials.

To ensure that all ptrace checks use the correct caller credentials (e.g.
in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS
flag), use two new flags and require one of them to be set.

The problem was that when a privileged task had temporarily dropped its
privileges, e.g.  by calling setreuid(0, user_uid), with the intent to
perform following syscalls with the credentials of a user, it still passed
ptrace access checks that the user would not be able to pass.

While an attacker should not be able to convince the privileged task to
perform a ptrace() syscall, this is a problem because the ptrace access
check is reused for things in procfs.

In particular, the following somewhat interesting procfs entries only rely
on ptrace access checks:

 /proc/$pid/stat - uses the check for determining whether pointers
     should be visible, useful for bypassing ASLR
 /proc/$pid/maps - also useful for bypassing ASLR
 /proc/$pid/cwd - useful for gaining access to restricted
     directories that contain files with lax permissions, e.g. in
     this scenario:
     lrwxrwxrwx root root /proc/13020/cwd -&gt; /root/foobar
     drwx------ root root /root
     drwxr-xr-x root root /root/foobar
     -rw-r--r-- root root /root/foobar/secret

Therefore, on a system where a root-owned mode 6755 binary changes its
effective credentials as described and then dumps a user-specified file,
this could be used by an attacker to reveal the memory layout of root's
processes or reveal the contents of files he is not allowed to access
(through /proc/$pid/cwd).

[akpm@linux-foundation.org: fix warning]
Signed-off-by: Jann Horn &lt;jann@thejh.net&gt;
Acked-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: James Morris &lt;james.l.morris@oracle.com&gt;
Cc: "Serge E. Hallyn" &lt;serge.hallyn@ubuntu.com&gt;
Cc: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>proc: actually make proc_fd_permission() thread-friendly</title>
<updated>2016-02-15T16:07:47+00:00</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2015-11-07T00:30:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=71755056d169833625addb418e59e2b2d8d3bcdf'/>
<id>71755056d169833625addb418e59e2b2d8d3bcdf</id>
<content type='text'>
commit 54708d2858e79a2bdda10bf8a20c80eb96c20613 upstream.

The commit 96d0df79f264 ("proc: make proc_fd_permission() thread-friendly")
fixed the access to /proc/self/fd from sub-threads, but introduced another
problem: a sub-thread can't access /proc/&lt;tid&gt;/fd/ or /proc/thread-self/fd
if generic_permission() fails.

Change proc_fd_permission() to check same_thread_group(pid_task(), current).

Fixes: 96d0df79f264 ("proc: make proc_fd_permission() thread-friendly")
Reported-by: "Jin, Yihua" &lt;yihua.jin@intel.com&gt;
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

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

The commit 96d0df79f264 ("proc: make proc_fd_permission() thread-friendly")
fixed the access to /proc/self/fd from sub-threads, but introduced another
problem: a sub-thread can't access /proc/&lt;tid&gt;/fd/ or /proc/thread-self/fd
if generic_permission() fails.

Change proc_fd_permission() to check same_thread_group(pid_task(), current).

Fixes: 96d0df79f264 ("proc: make proc_fd_permission() thread-friendly")
Reported-by: "Jin, Yihua" &lt;yihua.jin@intel.com&gt;
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>/proc/stat: convert to single_open_size()</title>
<updated>2015-05-15T07:10:56+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2014-07-02T22:22:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a58d83a1a10afa8b19a026859bcb6c47832975a8'/>
<id>a58d83a1a10afa8b19a026859bcb6c47832975a8</id>
<content type='text'>
commit f74373a5cc7a0155d232c4e999648c7a95435bb2 upstream.

These two patches are supposed to "fix" failed order-4 memory
allocations which have been observed when reading /proc/stat.  The
problem has been observed on s390 as well as on x86.

To address the problem change the seq_file memory allocations to
fallback to use vmalloc, so that allocations also work if memory is
fragmented.

This approach seems to be simpler and less intrusive than changing
/proc/stat to use an interator.  Also it "fixes" other users as well,
which use seq_file's single_open() interface.

This patch (of 2):

Use seq_file's single_open_size() to preallocate a buffer that is large
enough to hold the whole output, instead of open coding it.  Also
calculate the requested size using the number of online cpus instead of
possible cpus, since the size of the output only depends on the number
of online cpus.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Acked-by: David Rientjes &lt;rientjes@google.com&gt;
Cc: Ian Kent &lt;raven@themaw.net&gt;
Cc: Hendrik Brueckner &lt;brueckner@linux.vnet.ibm.com&gt;
Cc: Thorsten Diehl &lt;thorsten.diehl@de.ibm.com&gt;
Cc: Andrea Righi &lt;andrea@betterlinux.com&gt;
Cc: Christoph Hellwig &lt;hch@infradead.org&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Stefan Bader &lt;stefan.bader@canonical.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f74373a5cc7a0155d232c4e999648c7a95435bb2 upstream.

These two patches are supposed to "fix" failed order-4 memory
allocations which have been observed when reading /proc/stat.  The
problem has been observed on s390 as well as on x86.

To address the problem change the seq_file memory allocations to
fallback to use vmalloc, so that allocations also work if memory is
fragmented.

This approach seems to be simpler and less intrusive than changing
/proc/stat to use an interator.  Also it "fixes" other users as well,
which use seq_file's single_open() interface.

This patch (of 2):

Use seq_file's single_open_size() to preallocate a buffer that is large
enough to hold the whole output, instead of open coding it.  Also
calculate the requested size using the number of online cpus instead of
possible cpus, since the size of the output only depends on the number
of online cpus.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Acked-by: David Rientjes &lt;rientjes@google.com&gt;
Cc: Ian Kent &lt;raven@themaw.net&gt;
Cc: Hendrik Brueckner &lt;brueckner@linux.vnet.ibm.com&gt;
Cc: Thorsten Diehl &lt;thorsten.diehl@de.ibm.com&gt;
Cc: Andrea Righi &lt;andrea@betterlinux.com&gt;
Cc: Christoph Hellwig &lt;hch@infradead.org&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Stefan Bader &lt;stefan.bader@canonical.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>proc/pagemap: walk page tables under pte lock</title>
<updated>2015-04-27T18:38:16+00:00</updated>
<author>
<name>Konstantin Khlebnikov</name>
<email>khlebnikov@yandex-team.ru</email>
</author>
<published>2015-02-11T23:27:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8ead83eacb662ddb22a8e8e91b804a49ea182716'/>
<id>8ead83eacb662ddb22a8e8e91b804a49ea182716</id>
<content type='text'>
commit 05fbf357d94152171bc50f8a369390f1f16efd89 upstream.

Lockless access to pte in pagemap_pte_range() might race with page
migration and trigger BUG_ON(!PageLocked()) in migration_entry_to_page():

CPU A (pagemap)                           CPU B (migration)
                                          lock_page()
                                          try_to_unmap(page, TTU_MIGRATION...)
                                               make_migration_entry()
                                               set_pte_at()
&lt;read *pte&gt;
pte_to_pagemap_entry()
                                          remove_migration_ptes()
                                          unlock_page()
    if(is_migration_entry())
        migration_entry_to_page()
            BUG_ON(!PageLocked(page))

Also lockless read might be non-atomic if pte is larger than wordsize.
Other pte walkers (smaps, numa_maps, clear_refs) already lock ptes.

Fixes: 052fb0d635df ("proc: report file/anon bit in /proc/pid/pagemap")
Signed-off-by: Konstantin Khlebnikov &lt;khlebnikov@yandex-team.ru&gt;
Reported-by: Andrey Ryabinin &lt;a.ryabinin@samsung.com&gt;
Reviewed-by: Cyrill Gorcunov &lt;gorcunov@openvz.org&gt;
Acked-by: Naoya Horiguchi &lt;n-horiguchi@ah.jp.nec.com&gt;
Acked-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;	[3.5+]
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 05fbf357d94152171bc50f8a369390f1f16efd89 upstream.

Lockless access to pte in pagemap_pte_range() might race with page
migration and trigger BUG_ON(!PageLocked()) in migration_entry_to_page():

CPU A (pagemap)                           CPU B (migration)
                                          lock_page()
                                          try_to_unmap(page, TTU_MIGRATION...)
                                               make_migration_entry()
                                               set_pte_at()
&lt;read *pte&gt;
pte_to_pagemap_entry()
                                          remove_migration_ptes()
                                          unlock_page()
    if(is_migration_entry())
        migration_entry_to_page()
            BUG_ON(!PageLocked(page))

Also lockless read might be non-atomic if pte is larger than wordsize.
Other pte walkers (smaps, numa_maps, clear_refs) already lock ptes.

Fixes: 052fb0d635df ("proc: report file/anon bit in /proc/pid/pagemap")
Signed-off-by: Konstantin Khlebnikov &lt;khlebnikov@yandex-team.ru&gt;
Reported-by: Andrey Ryabinin &lt;a.ryabinin@samsung.com&gt;
Reviewed-by: Cyrill Gorcunov &lt;gorcunov@openvz.org&gt;
Acked-by: Naoya Horiguchi &lt;n-horiguchi@ah.jp.nec.com&gt;
Acked-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;	[3.5+]
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mm: softdirty: unmapped addresses between VMAs are clean</title>
<updated>2015-04-27T18:25:29+00:00</updated>
<author>
<name>Peter Feiner</name>
<email>pfeiner@google.com</email>
</author>
<published>2014-10-09T22:28:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fdfce812d2c6bd0c1eb6ccd3196fe34b5e293c6b'/>
<id>fdfce812d2c6bd0c1eb6ccd3196fe34b5e293c6b</id>
<content type='text'>
commit 81d0fa623c5b8dbd5279d9713094b0f9b0a00fb4 upstream.

If a /proc/pid/pagemap read spans a [VMA, an unmapped region, then a
VM_SOFTDIRTY VMA], the virtual pages in the unmapped region are reported
as softdirty.  Here's a program to demonstrate the bug:

int main() {
	const uint64_t PAGEMAP_SOFTDIRTY = 1ul &lt;&lt; 55;
	uint64_t pme[3];
	int fd = open("/proc/self/pagemap", O_RDONLY);;
	char *m = mmap(NULL, 3 * getpagesize(), PROT_READ,
	               MAP_ANONYMOUS | MAP_SHARED, -1, 0);
	munmap(m + getpagesize(), getpagesize());
	pread(fd, pme, 24, (unsigned long) m / getpagesize() * 8);
	assert(pme[0] &amp; PAGEMAP_SOFTDIRTY);    /* passes */
	assert(!(pme[1] &amp; PAGEMAP_SOFTDIRTY)); /* fails */
	assert(pme[2] &amp; PAGEMAP_SOFTDIRTY);    /* passes */
	return 0;
}

(Note that all pages in new VMAs are softdirty until cleared).

Tested:
	Used the program given above. I'm going to include this code in
	a selftest in the future.

[n-horiguchi@ah.jp.nec.com: prevent pagemap_pte_range() from overrunning]
Signed-off-by: Peter Feiner &lt;pfeiner@google.com&gt;
Cc: "Kirill A. Shutemov" &lt;kirill@shutemov.name&gt;
Cc: Cyrill Gorcunov &lt;gorcunov@openvz.org&gt;
Cc: Pavel Emelyanov &lt;xemul@parallels.com&gt;
Cc: Jamie Liu &lt;jamieliu@google.com&gt;
Cc: Hugh Dickins &lt;hughd@google.com&gt;
Cc: Naoya Horiguchi &lt;n-horiguchi@ah.jp.nec.com&gt;
Signed-off-by: Naoya Horiguchi &lt;n-horiguchi@ah.jp.nec.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

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

If a /proc/pid/pagemap read spans a [VMA, an unmapped region, then a
VM_SOFTDIRTY VMA], the virtual pages in the unmapped region are reported
as softdirty.  Here's a program to demonstrate the bug:

int main() {
	const uint64_t PAGEMAP_SOFTDIRTY = 1ul &lt;&lt; 55;
	uint64_t pme[3];
	int fd = open("/proc/self/pagemap", O_RDONLY);;
	char *m = mmap(NULL, 3 * getpagesize(), PROT_READ,
	               MAP_ANONYMOUS | MAP_SHARED, -1, 0);
	munmap(m + getpagesize(), getpagesize());
	pread(fd, pme, 24, (unsigned long) m / getpagesize() * 8);
	assert(pme[0] &amp; PAGEMAP_SOFTDIRTY);    /* passes */
	assert(!(pme[1] &amp; PAGEMAP_SOFTDIRTY)); /* fails */
	assert(pme[2] &amp; PAGEMAP_SOFTDIRTY);    /* passes */
	return 0;
}

(Note that all pages in new VMAs are softdirty until cleared).

Tested:
	Used the program given above. I'm going to include this code in
	a selftest in the future.

[n-horiguchi@ah.jp.nec.com: prevent pagemap_pte_range() from overrunning]
Signed-off-by: Peter Feiner &lt;pfeiner@google.com&gt;
Cc: "Kirill A. Shutemov" &lt;kirill@shutemov.name&gt;
Cc: Cyrill Gorcunov &lt;gorcunov@openvz.org&gt;
Cc: Pavel Emelyanov &lt;xemul@parallels.com&gt;
Cc: Jamie Liu &lt;jamieliu@google.com&gt;
Cc: Hugh Dickins &lt;hughd@google.com&gt;
Cc: Naoya Horiguchi &lt;n-horiguchi@ah.jp.nec.com&gt;
Signed-off-by: Naoya Horiguchi &lt;n-horiguchi@ah.jp.nec.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>pagemap: do not leak physical addresses to non-privileged userspace</title>
<updated>2015-04-09T11:14:15+00:00</updated>
<author>
<name>Kirill A. Shutemov</name>
<email>kirill.shutemov@linux.intel.com</email>
</author>
<published>2015-03-09T21:11:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=91e9d77039485b57ddf632638acc0a968a39b856'/>
<id>91e9d77039485b57ddf632638acc0a968a39b856</id>
<content type='text'>
commit ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce upstream.

As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.

This disallows anybody without CAP_SYS_ADMIN to read the pagemap.

[1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

[ Eventually we might want to do anything more finegrained, but for now
  this is the simple model.   - Linus ]

Signed-off-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Acked-by: Konstantin Khlebnikov &lt;khlebnikov@openvz.org&gt;
Acked-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Cc: Pavel Emelyanov &lt;xemul@parallels.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Mark Seaborn &lt;mseaborn@chromium.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce upstream.

As pointed by recent post[1] on exploiting DRAM physical imperfection,
/proc/PID/pagemap exposes sensitive information which can be used to do
attacks.

This disallows anybody without CAP_SYS_ADMIN to read the pagemap.

[1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

[ Eventually we might want to do anything more finegrained, but for now
  this is the simple model.   - Linus ]

Signed-off-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Acked-by: Konstantin Khlebnikov &lt;khlebnikov@openvz.org&gt;
Acked-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Cc: Pavel Emelyanov &lt;xemul@parallels.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Mark Seaborn &lt;mseaborn@chromium.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>procfs: fix race between symlink removals and traversals</title>
<updated>2015-03-12T16:31:20+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2015-02-22T03:16:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=147e702ad9582b4dae6241952ac19cf174b59695'/>
<id>147e702ad9582b4dae6241952ac19cf174b59695</id>
<content type='text'>
commit 7e0e953bb0cf649f93277ac8fb67ecbb7f7b04a9 upstream.

use_pde()/unuse_pde() in -&gt;follow_link()/-&gt;put_link() resp.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7e0e953bb0cf649f93277ac8fb67ecbb7f7b04a9 upstream.

use_pde()/unuse_pde() in -&gt;follow_link()/-&gt;put_link() resp.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
</feed>
