linux.git, branch v3.16.46

Linux 3.16.46

2017-07-18T17:40:42+00:00

ALSA: timer: Fix missing queue indices reset at SNDRV_TIMER_IOCTL_SELECT

2017-07-18T17:40:41+00:00

commit ba3021b2c79b2fa9114f92790a99deb27a65b728 upstream.

snd_timer_user_tselect() reallocates the queue buffer dynamically, but
it forgot to reset its indices.  Since the read may happen
concurrently with ioctl and snd_timer_user_tselect() allocates the
buffer via kmalloc(), this may lead to the leak of uninitialized
kernel-space data, as spotted via KMSAN:

  BUG: KMSAN: use of unitialized memory in snd_timer_user_read+0x6c4/0xa10
  CPU: 0 PID: 1037 Comm: probe Not tainted 4.11.0-rc5+ #2739
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
   __dump_stack lib/dump_stack.c:16
   dump_stack+0x143/0x1b0 lib/dump_stack.c:52
   kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
   kmsan_check_memory+0xc2/0x140 mm/kmsan/kmsan.c:1086
   copy_to_user ./arch/x86/include/asm/uaccess.h:725
   snd_timer_user_read+0x6c4/0xa10 sound/core/timer.c:2004
   do_loop_readv_writev fs/read_write.c:716
   __do_readv_writev+0x94c/0x1380 fs/read_write.c:864
   do_readv_writev fs/read_write.c:894
   vfs_readv fs/read_write.c:908
   do_readv+0x52a/0x5d0 fs/read_write.c:934
   SYSC_readv+0xb6/0xd0 fs/read_write.c:1021
   SyS_readv+0x87/0xb0 fs/read_write.c:1018

This patch adds the missing reset of queue indices.  Together with the
previous fix for the ioctl/read race, we cover the whole problem.

Reported-by: Alexander Potapenko 
Tested-by: Alexander Potapenko 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: timer: Fix race between read and ioctl

2017-07-18T17:40:40+00:00

commit d11662f4f798b50d8c8743f433842c3e40fe3378 upstream.

The read from ALSA timer device, the function snd_timer_user_tread(),
may access to an uninitialized struct snd_timer_user fields when the
read is concurrently performed while the ioctl like
snd_timer_user_tselect() is invoked.  We have already fixed the races
among ioctls via a mutex, but we seem to have forgotten the race
between read vs ioctl.

This patch simply applies (more exactly extends the already applied
range of) tu->ioctl_lock in snd_timer_user_tread() for closing the
race window.

Reported-by: Alexander Potapenko 
Tested-by: Alexander Potapenko 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

fs/exec.c: account for argv/envp pointers

2017-07-18T17:40:40+00:00

commit 98da7d08850fb8bdeb395d6368ed15753304aa0c upstream.

When limiting the argv/envp strings during exec to 1/4 of the stack limit,
the storage of the pointers to the strings was not included.  This means
that an exec with huge numbers of tiny strings could eat 1/4 of the stack
limit in strings and then additional space would be later used by the
pointers to the strings.

For example, on 32-bit with a 8MB stack rlimit, an exec with 1677721
single-byte strings would consume less than 2MB of stack, the max (8MB /
4) amount allowed, but the pointers to the strings would consume the
remaining additional stack space (1677721 * 4 == 6710884).

The result (1677721 + 6710884 == 8388605) would exhaust stack space
entirely.  Controlling this stack exhaustion could result in
pathological behavior in setuid binaries (CVE-2017-1000365).

[akpm@linux-foundation.org: additional commenting from Kees]
Fixes: b6a2fea39318 ("mm: variable length argument support")
Link: http://lkml.kernel.org/r/20170622001720.GA32173@beast
Signed-off-by: Kees Cook 
Acked-by: Rik van Riel 
Acked-by: Michal Hocko 
Cc: Alexander Viro 
Cc: Qualys Security Advisory 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16: use ACCESS_ONCE() instead of READ_ONCE()]
Signed-off-by: Ben Hutchings

char: lp: fix possible integer overflow in lp_setup()

2017-07-18T17:40:40+00:00

commit 3e21f4af170bebf47c187c1ff8bf155583c9f3b1 upstream.

The lp_setup() code doesn't apply any bounds checking when passing
"lp=none", and only in this case, resulting in an overflow of the
parport_nr[] array. All versions in Git history are affected.

Reported-By: Roee Hay 
Cc: Ben Hutchings 
Signed-off-by: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

xen-blkback: don't leak stack data via response ring

2017-07-18T17:40:40+00:00

commit 089bc0143f489bd3a4578bdff5f4ca68fb26f341 upstream.

Rather than constructing a local structure instance on the stack, fill
the fields directly on the shared ring, just like other backends do.
Build on the fact that all response structure flavors are actually
identical (the old code did make this assumption too).

This is XSA-216.


Signed-off-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: Konrad Rzeszutek Wilk 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

drm/vmwgfx: Make sure backup_handle is always valid

2017-07-18T17:40:40+00:00

commit 07678eca2cf9c9a18584e546c2b2a0d0c9a3150c upstream.

When vmw_gb_surface_define_ioctl() is called with an existing buffer,
we end up returning an uninitialized variable in the backup_handle.

The fix is to first initialize backup_handle to 0 just to be sure, and
second, when a user-provided buffer is found, we will use the
req->buffer_handle as the backup_handle.

Reported-by: Murray McAllister 
Signed-off-by: Sinclair Yeh 
Reviewed-by: Deepak Rawat 
[bwh: Backported to 3.16: There's no size check after vmw_user_dmabuf_lookup(),
 so only check ret == 0.]
Signed-off-by: Ben Hutchings

mm: Tighten x86 /dev/mem with zeroing reads

2017-07-18T17:40:39+00:00

commit a4866aa812518ed1a37d8ea0c881dc946409de94 upstream.

Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:

usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)

This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.

Reported-by: Tommi Rantala 
Tested-by: Tommi Rantala 
Signed-off-by: Kees Cook 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

ceph: fix recursion between ceph_set_acl() and __ceph_setattr()

2017-07-18T17:40:39+00:00

commit 8179a101eb5f4ef0ac9a915fcea9a9d3109efa90 upstream.

ceph_set_acl() calls __ceph_setattr() if the setacl operation needs
to modify inode's i_mode. __ceph_setattr() updates inode's i_mode,
then calls posix_acl_chmod().

The problem is that __ceph_setattr() calls posix_acl_chmod() before
sending the setattr request. The get_acl() call in posix_acl_chmod()
can trigger a getxattr request. The reply of the getxattr request
can restore inode's i_mode to its old value. The set_acl() call in
posix_acl_chmod() sees old value of inode's i_mode, so it calls
__ceph_setattr() again.

Link: http://tracker.ceph.com/issues/19688
Reported-by: Jerry Lee 
Signed-off-by: "Yan, Zheng" 
Reviewed-by: Jeff Layton 
Tested-by: Luis Henriques 
Signed-off-by: Ilya Dryomov 
[bwh: Backported to 3.16: All the changes are made in ceph_setattr() as
 there is no __ceph_setattr() function.]
Signed-off-by: Ben Hutchings

ipv6: move stub initialization after ipv6 setup completion

2017-07-18T17:40:39+00:00

commit b7d6df57516f8e6a1c847b822ec2a62555455f88 upstream.

The ipv6 stub pointer is currently initialized before the ipv6
routing subsystem: a 3rd party can access and use such stub
before the routing data is ready.
Moreover, such pointer is not cleared in case of initialization
error, possibly leading to dangling pointers usage.

This change addresses the above moving the stub initialization
at the end of ipv6 init code.

Fixes: 5f81bd2e5d80 ("ipv6: export a stub for IPv6 symbols used by vxlan")
Signed-off-by: Paolo Abeni 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings