linux-stable.git/fs, branch v3.16.40

sysctl: Drop reference added by grab_header in proc_sys_readdir

2017-02-23T03:54:47+00:00

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]  [] schedule+0x3f/0xa0
[ 5535.968817]  [] schedule_timeout+0x3db/0x6f0
[ 5535.975346]  [] ? wait_for_completion+0x45/0x130
[ 5535.982256]  [] wait_for_completion+0xc3/0x130
[ 5535.988972]  [] ? wake_up_q+0x80/0x80
[ 5535.994804]  [] drop_sysctl_table+0xc4/0xe0
[ 5536.001227]  [] drop_sysctl_table+0x77/0xe0
[ 5536.007648]  [] unregister_sysctl_table+0x4d/0xa0
[ 5536.014654]  [] unregister_sysctl_table+0x7f/0xa0
[ 5536.021657]  [] unregister_sched_domain_sysctl+0x15/0x40
[ 5536.029344]  [] partition_sched_domains+0x44/0x450
[ 5536.036447]  [] ? __mutex_unlock_slowpath+0x111/0x1f0
[ 5536.043844]  [] rebuild_sched_domains_locked+0x64/0xb0
[ 5536.051336]  [] update_flag+0x11d/0x210
[ 5536.057373]  [] ? mutex_lock_nested+0x2df/0x450
[ 5536.064186]  [] ? cpuset_css_offline+0x1b/0x60
[ 5536.070899]  [] ? trace_hardirqs_on+0xd/0x10
[ 5536.077420]  [] ? mutex_lock_nested+0x2df/0x450
[ 5536.084234]  [] ? css_killed_work_fn+0x25/0x220
[ 5536.091049]  [] cpuset_css_offline+0x35/0x60
[ 5536.097571]  [] css_killed_work_fn+0x5c/0x220
[ 5536.104207]  [] process_one_work+0x1df/0x710
[ 5536.110736]  [] ? process_one_work+0x160/0x710
[ 5536.117461]  [] worker_thread+0x12b/0x4a0
[ 5536.123697]  [] ? process_one_work+0x710/0x710
[ 5536.130426]  [] kthread+0xfe/0x120
[ 5536.135991]  [] ret_from_fork+0x1f/0x40
[ 5536.142041]  [] ? 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 
Tested-by: Yang Shukui 
Signed-off-by: Zhou Chengming 
Acked-by: Al Viro 
Signed-off-by: Eric W. Biederman 
Signed-off-by: Ben Hutchings

fuse: fix clearing suid, sgid for chown()

2017-02-23T03:54:43+00:00

commit c01638f5d919728f565bf8b5e0a6a159642df0d9 upstream.

Basically, the pjdfstests set the ownership of a file to 06555, and then
chowns it (as root) to a new uid/gid. Prior to commit a09f99eddef4 ("fuse:
fix killing s[ug]id in setattr"), fuse would send down a setattr with both
the uid/gid change and a new mode.  Now, it just sends down the uid/gid
change.

Technically this is NOTABUG, since POSIX doesn't _require_ that we clear
these bits for a privileged process, but Linux (wisely) has done that and I
think we don't want to change that behavior here.

This is caused by the use of should_remove_suid(), which will always return
0 when the process has CAP_FSETID.

In fact we really don't need to be calling should_remove_suid() at all,
since we've already been indicated that we should remove the suid, we just
don't want to use a (very) stale mode for that.

This patch should fix the above as well as simplify the logic.

Reported-by: Jeff Layton 
Signed-off-by: Miklos Szeredi 
Fixes: a09f99eddef4 ("fuse: fix killing s[ug]id in setattr")
Reviewed-by: Jeff Layton 
[bwh: Backported to 3.16: adjust context, indentation]
Signed-off-by: Ben Hutchings

ext4: sanity check the block and cluster size at mount time

2017-02-23T03:54:38+00:00

commit 8cdf3372fe8368f56315e66bea9f35053c418093 upstream.

If the block size or cluster size is insane, reject the mount.  This
is important for security reasons (although we shouldn't be just
depending on this check).

Ref: http://www.securityfocus.com/archive/1/539661
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506
Reported-by: Borislav Petkov 
Reported-by: Nikolay Borisov 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Ben Hutchings

fuse: fix fuse_write_end() if zero bytes were copied

2017-02-23T03:54:33+00:00

commit 59c3b76cc61d1d676f965c192cc7969aa5cb2744 upstream.

If pos is at the beginning of a page and copied is zero then page is not
zeroed but is marked uptodate.

Fix by skipping everything except unlock/put of page if zero bytes were
copied.

Reported-by: Al Viro 
Fixes: 6b12c1b37e55 ("fuse: Implement write_begin/write_end callbacks")
Signed-off-by: Miklos Szeredi 
Signed-off-by: Ben Hutchings

coredump: fix unfreezable coredumping task

2017-02-23T03:54:32+00:00

commit 70d78fe7c8b640b5acfad56ad341985b3810998a upstream.

It could be not possible to freeze coredumping task when it waits for
'core_state->startup' completion, because threads are frozen in
get_signal() before they got a chance to complete 'core_state->startup'.

Inability to freeze a task during suspend will cause suspend to fail.
Also CRIU uses cgroup freezer during dump operation.  So with an
unfreezable task the CRIU dump will fail because it waits for a
transition from 'FREEZING' to 'FROZEN' state which will never happen.

Use freezer_do_not_count() to tell freezer to ignore coredumping task
while it waits for core_state->startup completion.

Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin 
Acked-by: Pavel Machek 
Acked-by: Oleg Nesterov 
Cc: Alexander Viro 
Cc: Tejun Heo 
Cc: "Rafael J. Wysocki" 
Cc: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

ubifs: Fix regression in ubifs_readdir()

2017-02-23T03:54:24+00:00

commit a00052a296e54205cf238c75bd98d17d5d02a6db upstream.

Commit c83ed4c9dbb35 ("ubifs: Abort readdir upon error") broke
overlayfs support because the fix exposed an internal error
code to VFS.

Reported-by: Peter Rosin 
Tested-by: Peter Rosin 
Reported-by: Ralph Sennhauser 
Tested-by: Ralph Sennhauser 
Fixes: c83ed4c9dbb35 ("ubifs: Abort readdir upon error")
Signed-off-by: Richard Weinberger 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

btrfs: fix races on root_log_ctx lists

2017-02-23T03:54:23+00:00

commit 570dd45042a7c8a7aba1ee029c5dd0f5ccf41b9b upstream.

btrfs_remove_all_log_ctxs takes a shortcut where it avoids walking the
list because it knows all of the waiters are patiently waiting for the
commit to finish.

But, there's a small race where btrfs_sync_log can remove itself from
the list if it finds a log commit is already done.  Also, it uses
list_del_init() to remove itself from the list, but there's no way to
know if btrfs_remove_all_log_ctxs has already run, so we don't know for
sure if it is safe to call list_del_init().

This gets rid of all the shortcuts for btrfs_remove_all_log_ctxs(), and
just calls it with the proper locking.

This is part two of the corruption fixed by cbd60aa7cd1.  I should have
done this in the first place, but convinced myself the optimizations were
safe.  A 12 hour run of dbench 2048 will eventually trigger a list debug
WARN_ON for the list_del_init() in btrfs_sync_log().

Fixes: d1433debe7f4346cf9fc0dafc71c3137d2a97bc4
Reported-by: Dave Jones 
Signed-off-by: Chris Mason 
Signed-off-by: Ben Hutchings

ubifs: Abort readdir upon error

2017-02-23T03:54:18+00:00

commit c83ed4c9dbb358b9e7707486e167e940d48bfeed upstream.

If UBIFS is facing an error while walking a directory, it reports this
error and ubifs_readdir() returns the error code. But the VFS readdir
logic does not make the getdents system call fail in all cases. When the
readdir cursor indicates that more entries are present, the system call
will just return and the libc wrapper will try again since it also
knows that more entries are present.
This causes the libc wrapper to busy loop for ever when a directory is
corrupted on UBIFS.
A common approach do deal with corrupted directory entries is
skipping them by setting the cursor to the next entry. On UBIFS this
approach is not possible since we cannot compute the next directory
entry cursor position without reading the current entry. So all we can
do is setting the cursor to the "no more entries" position and make
getdents exit.

Signed-off-by: Richard Weinberger 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

ubifs: Fix xattr_names length in exit paths

2017-02-23T03:54:17+00:00

commit 843741c5778398ea67055067f4cc65ae6c80ca0e upstream.

When the operation fails we also have to undo the changes
we made to ->xattr_names. Otherwise listxattr() will report
wrong lengths.

Signed-off-by: Richard Weinberger 
Signed-off-by: Ben Hutchings

isofs: Do not return EACCES for unknown filesystems

2017-02-23T03:54:17+00:00

commit a2ed0b391dd9c3ef1d64c7c3e370f4a5ffcd324a upstream.

When isofs_mount() is called to mount a device read-write, it returns
EACCES even before it checks that the device actually contains an isofs
filesystem. This may confuse mount(8) which then tries to mount all
subsequent filesystem types in read-only mode.

Fix the problem by returning EACCES only once we verify that the device
indeed contains an iso9660 filesystem.

Fixes: 17b7f7cf58926844e1dd40f5eb5348d481deca6a
Reported-by: Kent Overstreet 
Reported-by: Karel Zak 
Signed-off-by: Jan Kara 
Signed-off-by: Ben Hutchings