linux-toradex.git/fs, branch v4.1.14

fs/proc, core/debug: Don't expose absolute kernel addresses via wchan

2015-12-09T19:03:20+00:00

commit b2f73922d119686323f14fbbe46587f863852328 upstream.

So the /proc/PID/stat 'wchan' field (the 30th field, which contains
the absolute kernel address of the kernel function a task is blocked in)
leaks absolute kernel addresses to unprivileged user-space:

        seq_put_decimal_ull(m, ' ', wchan);

The absolute address might also leak via /proc/PID/wchan as well, if
KALLSYMS is turned off or if the symbol lookup fails for some reason:

static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
                          struct pid *pid, struct task_struct *task)
{
        unsigned long wchan;
        char symname[KSYM_NAME_LEN];

        wchan = get_wchan(task);

        if (lookup_symbol_name(wchan, symname) < 0) {
                if (!ptrace_may_access(task, PTRACE_MODE_READ))
                        return 0;
                seq_printf(m, "%lu", wchan);
        } else {
                seq_printf(m, "%s", symname);
        }

        return 0;
}

This isn't ideal, because for example it trivially leaks the KASLR offset
to any local attacker:

  fomalhaut:~> printf "%016lx\n" $(cat /proc/$$/stat | cut -d' ' -f35)
  ffffffff8123b380

Most real-life uses of wchan are symbolic:

  ps -eo pid:10,tid:10,wchan:30,comm

and procps uses /proc/PID/wchan, not the absolute address in /proc/PID/stat:

  triton:~/tip> strace -f ps -eo pid:10,tid:10,wchan:30,comm 2>&1 | grep wchan | tail -1
  open("/proc/30833/wchan", O_RDONLY)     = 6

There's one compatibility quirk here: procps relies on whether the
absolute value is non-zero - and we can provide that functionality
by outputing "0" or "1" depending on whether the task is blocked
(whether there's a wchan address).

These days there appears to be very little legitimate reason
user-space would be interested in  the absolute address. The
absolute address is mostly historic: from the days when we
didn't have kallsyms and user-space procps had to do the
decoding itself via the System.map.

So this patch sets all numeric output to "0" or "1" and keeps only
symbolic output, in /proc/PID/wchan.

( The absolute sleep address can generally still be profiled via
  perf, by tasks with sufficient privileges. )

Reviewed-by: Thomas Gleixner 
Acked-by: Kees Cook 
Acked-by: Linus Torvalds 
Cc: Al Viro 
Cc: Alexander Potapenko 
Cc: Andrey Konovalov 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: Dmitry Vyukov 
Cc: Kostya Serebryany 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Peter Zijlstra 
Cc: Sasha Levin 
Cc: kasan-dev 
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/20150930135917.GA3285@gmail.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

btrfs: fix possible leak in btrfs_ioctl_balance()

2015-11-09T22:33:39+00:00

commit 0f89abf56abbd0e1c6e3cef9813e6d9f05383c1e upstream.

Commit 8eb934591f8b ("btrfs: check unsupported filters in balance
arguments") adds a jump to exit label out_bargs in case the argument
check fails. At this point in addition to the bargs memory, the
memory for struct btrfs_balance_control has already been allocated.
Ownership of bctl is passed to btrfs_balance() in the good case,
thus the memory is not freed due to the introduced jump. Make sure
that the memory gets freed in any case as necessary. Detected by
Coverity CID 1328378.

Signed-off-by: Christian Engelmayer 
Reviewed-by: David Sterba 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

ovl: fix dentry reference leak

2015-11-09T22:33:38+00:00

commit ab79efab0a0ba01a74df782eb7fa44b044dae8b5 upstream.

In ovl_copy_up_locked(), newdentry is leaked if the function exits through
out_cleanup as this just to out after calling ovl_cleanup() - which doesn't
actually release the ref on newdentry.

The out_cleanup segment should instead exit through out2 as certainly
newdentry leaks - and possibly upper does also, though this isn't caught
given the catch of newdentry.

Without this fix, something like the following is seen:

	BUG: Dentry ffff880023e9eb20{i=f861,n=#ffff880023e82d90} still in use (1) [unmount of tmpfs tmpfs]
	BUG: Dentry ffff880023ece640{i=0,n=bigfile}  still in use (1) [unmount of tmpfs tmpfs]

when unmounting the upper layer after an error occurred in copyup.

An error can be induced by creating a big file in a lower layer with
something like:

	dd if=/dev/zero of=/lower/a/bigfile bs=65536 count=1 seek=$((0xf000))

to create a large file (4.1G).  Overlay an upper layer that is too small
(on tmpfs might do) and then induce a copy up by opening it writably.

Reported-by: Ulrich Obergfell 
Signed-off-by: David Howells 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

ovl: use O_LARGEFILE in ovl_copy_up()

2015-11-09T22:33:38+00:00

commit 0480334fa60488d12ae101a02d7d9e1a3d03d7dd upstream.

Open the lower file with O_LARGEFILE in ovl_copy_up().

Pass O_LARGEFILE unconditionally in ovl_copy_up_data() as it's purely for
catching 32-bit userspace dealing with a file large enough that it'll be
mishandled if the application isn't aware that there might be an integer
overflow.  Inside the kernel, there shouldn't be any problems.

Reported-by: Ulrich Obergfell 
Signed-off-by: David Howells 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

ovl: free lower_mnt array in ovl_put_super

2015-11-09T22:33:38+00:00

commit 5ffdbe8bf1e485026e1c7e4714d2841553cf0b40 upstream.

This fixes memory leak after umount.

Kmemleak report:

unreferenced object 0xffff8800ba791010 (size 8):
  comm "mount", pid 2394, jiffies 4294996294 (age 53.920s)
  hex dump (first 8 bytes):
    20 1c 13 02 00 88 ff ff                           .......
  backtrace:
    [] create_object+0x124/0x2c0
    [] kmemleak_alloc+0x7b/0xc0
    [] __kmalloc+0x106/0x340
    [] ovl_fill_super+0x55c/0x9b0 [overlay]
    [] mount_nodev+0x54/0xa0
    [] ovl_mount+0x18/0x20 [overlay]
    [] mount_fs+0x43/0x170
    [] vfs_kern_mount+0x74/0x170
    [] do_mount+0x22d/0xdf0
    [] SyS_mount+0x7b/0xc0
    [] entry_SYSCALL_64_fastpath+0x12/0x76
    [] 0xffffffffffffffff

Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: Miklos Szeredi 
Fixes: dd662667e6d3 ("ovl: add mutli-layer infrastructure")
Signed-off-by: Greg Kroah-Hartman

ovl: free stack of paths in ovl_fill_super

2015-11-09T22:33:37+00:00

commit 0f95502ad84874b3c05fc7cdd9d4d9d5cddf7859 upstream.

This fixes small memory leak after mount.

Kmemleak report:

unreferenced object 0xffff88003683fe00 (size 16):
  comm "mount", pid 2029, jiffies 4294909563 (age 33.380s)
  hex dump (first 16 bytes):
    20 27 1f bb 00 88 ff ff 40 4b 0f 36 02 88 ff ff   '......@K.6....
  backtrace:
    [] create_object+0x124/0x2c0
    [] kmemleak_alloc+0x7b/0xc0
    [] __kmalloc+0x106/0x340
    [] ovl_fill_super+0x389/0x9a0 [overlay]
    [] mount_nodev+0x54/0xa0
    [] ovl_mount+0x18/0x20 [overlay]
    [] mount_fs+0x43/0x170
    [] vfs_kern_mount+0x74/0x170
    [] do_mount+0x22d/0xdf0
    [] SyS_mount+0x7b/0xc0
    [] entry_SYSCALL_64_fastpath+0x12/0x76
    [] 0xffffffffffffffff

Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: Miklos Szeredi 
Fixes: a78d9f0d5d5c ("ovl: support multiple lower layers")
Signed-off-by: Greg Kroah-Hartman

nfs4: have do_vfs_lock take an inode pointer

2015-10-27T00:52:00+00:00

commit 83bfff23e9ed19f37c4ef0bba84e75bd88e5cf21 upstream.

Now that we have file locking helpers that can deal with an inode
instead of a filp, we can change the NFSv4 locking code to use that
instead.

This should fix the case where we have a filp that is closed while flock
or OFD locks are set on it, and the task is signaled so that it doesn't
wait for the LOCKU reply to come in before the filp is freed. At that
point we can end up with a use-after-free with the current code, which
relies on dereferencing the fl_file in the lock request.

Signed-off-by: Jeff Layton 
Reviewed-by: "J. Bruce Fields" 
Tested-by: "J. Bruce Fields" 
Cc: William Dauchy 
Signed-off-by: Greg Kroah-Hartman

locks: inline posix_lock_file_wait and flock_lock_file_wait

2015-10-27T00:52:00+00:00

commit ee296d7c5709440f8abd36b5b65c6b3e388538d9 upstream.

They just call file_inode and then the corresponding *_inode_file_wait
function. Just make them static inlines instead.

Signed-off-by: Jeff Layton 
Cc: William Dauchy 
Signed-off-by: Greg Kroah-Hartman

locks: new helpers - flock_lock_inode_wait and posix_lock_inode_wait

2015-10-27T00:52:00+00:00

commit 29d01b22eaa18d8b46091d3c98c6001c49f78e4a upstream.

Allow callers to pass in an inode instead of a filp.

Signed-off-by: Jeff Layton 
Reviewed-by: "J. Bruce Fields" 
Tested-by: "J. Bruce Fields" 
Cc: William Dauchy 
Signed-off-by: Greg Kroah-Hartman

locks: have flock_lock_file take an inode pointer instead of a filp

2015-10-27T00:51:59+00:00

commit bcd7f78d078ff6197715c1ed070c92aca57ec12c upstream.

...and rename it to better describe how it works.

In order to fix a use-after-free in NFS, we need to be able to remove
locks from an inode after the filp associated with them may have already
been freed. flock_lock_file already only dereferences the filp to get to
the inode, so just change it so the callers do that.

All of the callers already pass in a lock request that has the fl_file
set properly, so we don't need to pass it in individually. With that
change it now only dereferences the filp to get to the inode, so just
push that out to the callers.

Signed-off-by: Jeff Layton 
Reviewed-by: "J. Bruce Fields" 
Tested-by: "J. Bruce Fields" 
Cc: William Dauchy 
Signed-off-by: Greg Kroah-Hartman