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

exec: Ensure mm->user_ns contains the execed files

2018-01-01T20:52:11+00:00

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->user_ns, by adjusting mm->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->user_ns to
the parent user namespace until an appropriate parent is found.

Reported-by: Jann Horn 
Fixes: 9e4a36ece652 ("userns: Fail exec for suid and sgid binaries with ids outside our user namespace.")
Signed-off-by: "Eric W. Biederman" 
[bwh: Backported to 3.16:
 - Add #include 
 - Adjust context]
Signed-off-by: Ben Hutchings

ptrace: Capture the ptracer's creds not PT_PTRACE_CAP

2018-01-01T20:52:10+00:00

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 -> v2.4.9.12")
Signed-off-by: "Eric W. Biederman" 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

ocfs2: fstrim: Fix start offset of first cluster group during fstrim

2018-01-01T20:52:04+00:00

commit 105ddc93f06ebe3e553f58563d11ed63dbcd59f0 upstream.

The first cluster group descriptor is not stored at the start of the
group but at an offset from the start.  We need to take this into
account while doing fstrim on the first cluster group.  Otherwise we
will wrongly start fstrim a few blocks after the desired start block and
the range can cross over into the next cluster group and zero out the
group descriptor there.  This can cause filesytem corruption that cannot
be fixed by fsck.

Link: http://lkml.kernel.org/r/1507835579-7308-1-git-send-email-ashish.samant@oracle.com
Signed-off-by: Ashish Samant 
Reviewed-by: Junxiao Bi 
Reviewed-by: Joseph Qi 
Cc: Mark Fasheh 
Cc: Joel Becker 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

SMB3: Validate negotiate request must always be signed

2018-01-01T20:52:00+00:00

commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream.

According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned

See kernel bugzilla bug 197311

Acked-by: Ronnie Sahlberg 
Signed-off-by: Steve French 
[bwh: Backported to 3.16: s/sync_hdr\.Flags/Flags/]
Signed-off-by: Ben Hutchings

SMB: fix validate negotiate info uninitialised memory use

2018-01-01T20:51:59+00:00

commit a2d9daad1d2dfbd307ab158044d1c323d7babbde upstream.

An undersize validate negotiate info server response causes the client
to use uninitialised memory for struct validate_negotiate_info_rsp
comparisons of Dialect, SecurityMode and/or Capabilities members.

Link: https://bugzilla.samba.org/show_bug.cgi?id=13092
Fixes: 7db0a6efdc3e ("SMB3: Work around mount failure when using SMB3 dialect to Macs")
Signed-off-by: David Disseldorp 
Reviewed-by: Pavel Shilovsky 
Signed-off-by: Steve French 
Signed-off-by: Ben Hutchings

SMB: fix leak of validate negotiate info response buffer

2018-01-01T20:51:59+00:00

commit fe83bebc05228e838ed5cbbc62712ab50dd40e18 upstream.

Fixes: ff1c038addc4 ("Check SMB3 dialects against downgrade attacks")
Signed-off-by: David Disseldorp 
Signed-off-by: Steve French 
Signed-off-by: Ben Hutchings

fuse: fix READDIRPLUS skipping an entry

2018-01-01T20:51:59+00:00

commit c6cdd51404b7ac12dd95173ddfc548c59ecf037f upstream.

Marios Titas running a Haskell program noticed a problem with fuse's
readdirplus: when it is interrupted by a signal, it skips one directory
entry.

The reason is that fuse erronously updates ctx->pos after a failed
dir_emit().

The issue originates from the patch adding readdirplus support.

Reported-by: Jakob Unterwurzacher 
Tested-by: Marios Titas 
Signed-off-by: Miklos Szeredi 
Fixes: 0b05b18381ee ("fuse: implement NFS-like readdirplus support")
Signed-off-by: Ben Hutchings

fs/mpage.c: fix mpage_writepage() for pages with buffers

2018-01-01T20:51:53+00:00

commit f892760aa66a2d657deaf59538fb69433036767c upstream.

When using FAT on a block device which supports rw_page, we can hit
BUG_ON(!PageLocked(page)) in try_to_free_buffers().  This is because we
call clean_buffers() after unlocking the page we've written.  Introduce
a new clean_page_buffers() which cleans all buffers associated with a
page and call it from within bdev_write_page().

[akpm@linux-foundation.org: s/PAGE_SIZE/~0U/ per Linus and Matthew]
Link: http://lkml.kernel.org/r/20171006211541.GA7409@bombadil.infradead.org
Signed-off-by: Matthew Wilcox 
Reported-by: Toshi Kani 
Reported-by: OGAWA Hirofumi 
Tested-by: Toshi Kani 
Acked-by: Johannes Thumshirn 
Cc: Ross Zwisler 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

ecryptfs: fix dereference of NULL user_key_payload

2018-01-01T20:51:53+00:00

commit f66665c09ab489a11ca490d6a82df57cfc1bea3e upstream.

In eCryptfs, we failed to verify that the authentication token keys are
not revoked before dereferencing their payloads, which is problematic
because the payload of a revoked key is NULL.  request_key() *does* skip
revoked keys, but there is still a window where the key can be revoked
before we acquire the key semaphore.

Fix it by updating ecryptfs_get_key_payload_data() to return
-EKEYREVOKED if the key payload is NULL.  For completeness we check this
for "encrypted" keys as well as "user" keys, although encrypted keys
cannot be revoked currently.

Alternatively we could use key_validate(), but since we'll also need to
fix ecryptfs_get_key_payload_data() to validate the payload length, it
seems appropriate to just check the payload pointer.

Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig")
Reviewed-by: James Morris 
Cc: Michael Halcrow 
Signed-off-by: Eric Biggers 
Signed-off-by: David Howells 
[bwh: Backported to 3.16: user key payload is key->payload.data, not
 key->payload.data[0]]
Signed-off-by: Ben Hutchings

FS-Cache: fix dereference of NULL user_key_payload

2018-01-01T20:51:52+00:00

commit d124b2c53c7bee6569d2a2d0b18b4a1afde00134 upstream.

When the file /proc/fs/fscache/objects (available with
CONFIG_FSCACHE_OBJECT_LIST=y) is opened, we request a user key with
description "fscache:objlist", then access its payload.  However, a
revoked key has a NULL payload, and we failed to check for this.
request_key() *does* skip revoked keys, but there is still a window
where the key can be revoked before we access its payload.

Fix it by checking for a NULL payload, treating it like a key which was
already revoked at the time it was requested.

Fixes: 4fbf4291aa15 ("FS-Cache: Allow the current state of all objects to be dumped")
Reviewed-by: James Morris 
Signed-off-by: Eric Biggers 
Signed-off-by: David Howells 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings