linux-toradex.git/fs, branch v3.4.108

don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()

2015-06-19T03:40:34+00:00

commit 7bd88377d482e1eae3c5329b12e33cfd664fa6a9 upstream.

return the value instead, and have path_init() do the assignment.  Broken by
"vfs: Fix absolute RCU path walk failures due to uninitialized seq number",
which was Cc-stable with 2.6.38+ as destination.  This one should go where
it went.

To avoid dummy value returned in case when root is already set (it would do
no harm, actually, since the only caller that doesn't ignore the return value
is guaranteed to have nd->root *not* set, but it's more obvious that way),
lift the check into callers.  And do the same to set_root(), to keep them
in sync.

Signed-off-by: Al Viro 
Cc: Ian Jackson 
[lizf: the previous backport of this upstream commit is buggy. fix it]
Signed-off-by: Zefan Li

autofs4: check dev ioctl size before allocating

2015-06-19T03:40:33+00:00

commit e53d77eb8bb616e903e34cc7a918401bee3b5149 upstream.

There wasn't any check of the size passed from userspace before trying
to allocate the memory required.

This meant that userspace might request more space than allowed,
triggering an OOM.

Signed-off-by: Sasha Levin 
Signed-off-by: Ian Kent 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

fs: take i_mutex during prepare_binprm for set[ug]id executables

2015-06-19T03:40:33+00:00

commit 8b01fc86b9f425899f8a3a8fc1c47d73c2c20543 upstream.

This prevents a race between chown() and execve(), where chowning a
setuid-user binary to root would momentarily make the binary setuid
root.

This patch was mostly written by Linus Torvalds.

Signed-off-by: Jann Horn 
Signed-off-by: Linus Torvalds 
[lizf: Backported to 3.4:
 - adjust context
 - remove task_no_new_priv and user namespace stuff
 - open-code file_inode()
 - s/READ_ONCE/ACCESS_ONCE]
Signed-off-by: Zefan Li

splice: Apply generic position and size checks to each write

2015-06-19T03:40:32+00:00

3.2.67-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Ben Hutchings 

We need to check the position and size of file writes against various
limits, using generic_write_check().  This was not being done for
the splice write path.  It was fixed upstream by commit 8d0207652cbe
("->splice_write() via ->write_iter()") but we can't apply that.

CVE-2014-7822

Signed-off-by: Ben Hutchings 
Signed-off-by: Zefan Li

ocfs2: _really_ sync the right range

2015-06-19T03:40:31+00:00

commit 64b4e2526d1cf6e6a4db6213d6e2b6e6ab59479a upstream.

"ocfs2 syncs the wrong range" had been broken; prior to it the
code was doing the wrong thing in case of O_APPEND, all right,
but _after_ it we were syncing the wrong range in 100% cases.
*ppos, aka iocb->ki_pos is incremented prior to that point,
so we are always doing sync on the area _after_ the one we'd
written to.

Spotted by Joseph Qi  back in January;
unfortunately, I'd missed his mail back then ;-/

Signed-off-by: Al Viro 
Signed-off-by: Zefan Li

cifs: fix use-after-free bug in find_writable_file

2015-06-19T03:40:30+00:00

commit e1e9bda22d7ddf88515e8fe401887e313922823e upstream.

Under intermittent network outages, find_writable_file() is susceptible
to the following race condition, which results in a user-after-free in
the cifs_writepages code-path:

Thread 1                                        Thread 2
========                                        ========

inv_file = NULL
refind = 0
spin_lock(&cifs_file_list_lock)

// invalidHandle found on openFileList

inv_file = open_file
// inv_file->count currently 1

cifsFileInfo_get(inv_file)
// inv_file->count = 2

spin_unlock(&cifs_file_list_lock);

cifs_reopen_file()                            cifs_close()
// fails (rc != 0)                            ->cifsFileInfo_put()
                                       spin_lock(&cifs_file_list_lock)
                                       // inv_file->count = 1
                                       spin_unlock(&cifs_file_list_lock)

spin_lock(&cifs_file_list_lock);
list_move_tail(&inv_file->flist,
      &cifs_inode->openFileList);
spin_unlock(&cifs_file_list_lock);

cifsFileInfo_put(inv_file);
->spin_lock(&cifs_file_list_lock)

  // inv_file->count = 0
  list_del(&cifs_file->flist);
  // cleanup!!
  kfree(cifs_file);

  spin_unlock(&cifs_file_list_lock);

spin_lock(&cifs_file_list_lock);
++refind;
// refind = 1
goto refind_writable;

At this point we loop back through with an invalid inv_file pointer
and a refind value of 1. On second pass, inv_file is not overwritten on
openFileList traversal, and is subsequently dereferenced.

Signed-off-by: David Disseldorp 
Reviewed-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Zefan Li

hfsplus: fix B-tree corruption after insertion at position 0

2015-06-19T03:40:29+00:00

commit 98cf21c61a7f5419d82f847c4d77bf6e96a76f5f upstream.

Fix B-tree corruption when a new record is inserted at position 0 in the
node in hfs_brec_insert().  In this case a hfs_brec_update_parent() is
called to update the parent index node (if exists) and it is passed
hfs_find_data with a search_key containing a newly inserted key instead
of the key to be updated.  This results in an inconsistent index node.
The bug reproduces on my machine after an extents overflow record for
the catalog file (CNID=4) is inserted into the extents overflow B-tree.
Because of a low (reserved) value of CNID=4, it has to become the first
record in the first leaf node.

The resulting first leaf node is correct:

  ----------------------------------------------------
  | key0.CNID=4 | key1.CNID=123 | key2.CNID=456, ... |
  ----------------------------------------------------

But the parent index key0 still contains the previous key CNID=123:

  -----------------------
  | key0.CNID=123 | ... |
  -----------------------

A change in hfs_brec_insert() makes hfs_brec_update_parent() work
correctly by preventing it from getting fd->record=-1 value from
__hfs_brec_find().

Along the way, I removed duplicate code with unification of the if
condition.  The resulting code is equivalent to the original code
because node is never 0.

Also hfs_brec_update_parent() will now return an error after getting a
negative fd->record value.  However, the return value of
hfs_brec_update_parent() is not checked anywhere in the file and I'm
leaving it unchanged by this patch.  brec.c lacks error checking after
some other calls too, but this issue is of less importance than the one
being fixed by this patch.

Signed-off-by: Sergei Antonov 
Cc: Joe Perches 
Reviewed-by: Vyacheslav Dubeyko 
Acked-by: Hin-Tak Leung 
Cc: Anton Altaparmakov 
Cc: Al Viro 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

fuse: set stolen page uptodate

2015-06-19T03:40:24+00:00

commit aa991b3b267e24f578bac7b09cc57579b660304b upstream.

Regular pipe buffers' ->steal method (generic_pipe_buf_steal()) doesn't set
PG_uptodate.

Don't warn on this condition, just set the uptodate flag.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Zefan Li

fuse: notify: don't move pages

2015-06-19T03:40:24+00:00

commit 0d2783626a53d4c922f82d51fa675cb5d13f0d36 upstream.

fuse_try_move_page() is not prepared for replacing pages that have already
been read.

Reported-by: Al Viro 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Zefan Li

eCryptfs: don't pass fs-specific ioctl commands through

2015-06-19T03:40:20+00:00

commit 6d65261a09adaa374c05de807f73a144d783669e upstream.

eCryptfs can't be aware of what to expect when after passing an
arbitrary ioctl command through to the lower filesystem. The ioctl
command may trigger an action in the lower filesystem that is
incompatible with eCryptfs.

One specific example is when one attempts to use the Btrfs clone
ioctl command when the source file is in the Btrfs filesystem that
eCryptfs is mounted on top of and the destination fd is from a new file
created in the eCryptfs mount. The ioctl syscall incorrectly returns
success because the command is passed down to Btrfs which thinks that it
was able to do the clone operation. However, the result is an empty
eCryptfs file.

This patch allows the trim, {g,s}etflags, and {g,s}etversion ioctl
commands through and then copies up the inode metadata from the lower
inode to the eCryptfs inode to catch any changes made to the lower
inode's metadata. Those five ioctl commands are mostly common across all
filesystems but the whitelist may need to be further pruned in the
future.

https://bugzilla.kernel.org/show_bug.cgi?id=93691
https://launchpad.net/bugs/1305335

Signed-off-by: Tyler Hicks 
Cc: Rocko 
Cc: Colin Ian King 
[lizf: Backported to 3.4:
 - adjust context
 - there's no file_inode(), so open-code it]
Signed-off-by: Zefan Li