linux-stable.git/include, branch v4.1.18

radix-tree: fix oops after radix_tree_iter_retry

2016-02-15T20:45:37+00:00

[ Upstream commit 732042821cfa106b3c20b9780e4c60fee9d68900 ]

Helper radix_tree_iter_retry() resets next_index to the current index.
In following radix_tree_next_slot current chunk size becomes zero.  This
isn't checked and it tries to dereference null pointer in slot.

Tagged iterator is fine because retry happens only at slot 0 where tag
bitmask in iter->tags is filled with single bit.

Fixes: 46437f9a554f ("radix-tree: fix race in gang lookup")
Signed-off-by: Konstantin Khlebnikov 
Cc: Matthew Wilcox 
Cc: Hugh Dickins 
Cc: Ohad Ben-Cohen 
Cc: Jeremiah Mahler 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm: replace vma_lock_anon_vma with anon_vma_lock_read/write

2016-02-15T20:45:36+00:00

[ Upstream commit 12352d3cae2cebe18805a91fab34b534d7444231 ]

Sequence vma_lock_anon_vma() - vma_unlock_anon_vma() isn't safe if
anon_vma appeared between lock and unlock.  We have to check anon_vma
first or call anon_vma_prepare() to be sure that it's here.  There are
only few users of these legacy helpers.  Let's get rid of them.

This patch fixes anon_vma lock imbalance in validate_mm().  Write lock
isn't required here, read lock is enough.

And reorders expand_downwards/expand_upwards: security_mmap_addr() and
wrapping-around check don't have to be under anon vma lock.

Link: https://lkml.kernel.org/r/CACT4Y+Y908EjM2z=706dv4rV6dWtxTLK9nFg9_7DhRMLppBo2g@mail.gmail.com
Signed-off-by: Konstantin Khlebnikov 
Reported-by: Dmitry Vyukov 
Acked-by: Kirill A. Shutemov 
Cc: Andrea Arcangeli 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

drm/dp/mst: Remove port after removing connector.

2016-02-15T20:45:35+00:00

[ Upstream commit 4772ff03df8094fd99d28de5fcf5df3a3e9c68bb ]

The port is removed synchronously, but the connector delayed.
This causes a use after free which can cause a kernel BUG with
slug_debug=FPZU. This is fixed by freeing the port after the
connector.

This fixes a regression introduced with
6b8eeca65b18ae77e175cc2b6571731f0ee413bf
"drm/dp/mst: close deadlock in connector destruction."

Cc: stable@vger.kernel.org
Cc: Dave Airlie 
Signed-off-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil

2016-02-15T20:45:35+00:00

[ Upstream commit 64566b5e767f9bc3161055ca1b443a51afb52aad ]

drm_fixp_from_fraction allows us to create a fixed point directly
from a fraction, rather than creating fixed point values and dividing
later. This avoids overflow of our 64 bit value for large numbers.

drm_fixp2int_ceil allows us to return the ceiling of our fixed point
value.

[airlied: squash Jordan's fix]
32-bit-build-fix: Jordan Lazare 
Signed-off-by: Harry Wentland 
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher 
Signed-off-by: Dave Airlie 

Signed-off-by: Sasha Levin

radix-tree: fix race in gang lookup

2016-02-15T20:45:32+00:00

[ Upstream commit 46437f9a554fbe3e110580ca08ab703b59f2f95a ]

If the indirect_ptr bit is set on a slot, that indicates we need to redo
the lookup.  Introduce a new function radix_tree_iter_retry() which
forces the loop to retry the lookup by setting 'slot' to NULL and
turning the iterator back to point at the problematic entry.

This is a pretty rare problem to hit at the moment; the lookup has to
race with a grow of the radix tree from a height of 0.  The consequences
of hitting this race are that gang lookup could return a pointer to a
radix_tree_node instead of a pointer to whatever the user had inserted
in the tree.

Fixes: cebbd29e1c2f ("radix-tree: rewrite gang lookup using iterator")
Signed-off-by: Matthew Wilcox 
Cc: Hugh Dickins 
Cc: Ohad Ben-Cohen 
Cc: Konstantin Khlebnikov 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

ALSA: rawmidi: Make snd_rawmidi_transmit() race-free

2016-02-15T20:45:31+00:00

[ Upstream commit 06ab30034ed9c200a570ab13c017bde248ddb2a6 ]

A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by
syzkaller fuzzer:
  WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136
 [] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163
 [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223
 [] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273
 [] __vfs_write+0x113/0x480 fs/read_write.c:528
 [] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [<     inline     >] SYSC_write fs/read_write.c:624
 [] SyS_write+0x111/0x220 fs/read_write.c:616
 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

Also a similar warning is found but in another path:
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133
 [] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163
 [] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185
 [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252
 [] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302
 [] __vfs_write+0x113/0x480 fs/read_write.c:528
 [] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [<     inline     >] SYSC_write fs/read_write.c:624
 [] SyS_write+0x111/0x220 fs/read_write.c:616
 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

In the former case, the reason is that virmidi has an open code
calling snd_rawmidi_transmit_ack() with the value calculated outside
the spinlock.   We may use snd_rawmidi_transmit() in a loop just for
consuming the input data, but even there, there is a race between
snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack().

Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and
snd_rawmidi_tranmit_ack() separately without protection, so they are
racy as well.

The patch tries to address these issues by the following ways:
- Introduce the unlocked versions of snd_rawmidi_transmit_peek() and
  snd_rawmidi_transmit_ack() to be called inside the explicit lock.
- Rewrite snd_rawmidi_transmit() to be race-free (the former case).
- Make the split calls (the latter case) protected in the rawmidi spin
  lock.

BugLink: http://lkml.kernel.org/r/CACT4Y+YPq1+cYLkadwjWa5XjzF1_Vki1eHnVn-Lm0hzhSpu5PA@mail.gmail.com
BugLink: http://lkml.kernel.org/r/CACT4Y+acG4iyphdOZx47Nyq_VHGbpJQK-6xNpiqUjaZYqsXOGw@mail.gmail.com
Reported-by: Dmitry Vyukov 
Tested-by: Dmitry Vyukov 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

drm: add helper to check for wc memory support

2016-02-15T20:45:31+00:00

[ Upstream commit 4b0e4e4af6c6dc8354dcb72182d52c1bc55f12fc ]

Reviewed-by: Christian König 
Reviewed-by: Michel Dänzer 
Signed-off-by: Dave Airlie 
Signed-off-by: Oded Gabbay 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

libceph: fix ceph_msg_revoke()

2016-02-15T20:45:18+00:00

[ Upstream commit 67645d7619738e51c668ca69f097cb90b5470422 ]

There are a number of problems with revoking a "was sending" message:

(1) We never make any attempt to revoke data - only kvecs contibute to
con->out_skip.  However, once the header (envelope) is written to the
socket, our peer learns data_len and sets itself to expect at least
data_len bytes to follow front or front+middle.  If ceph_msg_revoke()
is called while the messenger is sending message's data portion,
anything we send after that call is counted by the OSD towards the now
revoked message's data portion.  The effects vary, the most common one
is the eventual hang - higher layers get stuck waiting for the reply to
the message that was sent out after ceph_msg_revoke() returned and
treated by the OSD as a bunch of data bytes.  This is what Matt ran
into.

(2) Flat out zeroing con->out_kvec_bytes worth of bytes to handle kvecs
is wrong.  If ceph_msg_revoke() is called before the tag is sent out or
while the messenger is sending the header, we will get a connection
reset, either due to a bad tag (0 is not a valid tag) or a bad header
CRC, which kind of defeats the purpose of revoke.  Currently the kernel
client refuses to work with header CRCs disabled, but that will likely
change in the future, making this even worse.

(3) con->out_skip is not reset on connection reset, leading to one or
more spurious connection resets if we happen to get a real one between
con->out_skip is set in ceph_msg_revoke() and before it's cleared in
write_partial_skip().

Fixing (1) and (3) is trivial.  The idea behind fixing (2) is to never
zero the tag or the header, i.e. send out tag+header regardless of when
ceph_msg_revoke() is called.  That way the header is always correct, no
unnecessary resets are induced and revoke stands ready for disabled
CRCs.  Since ceph_msg_revoke() rips out con->out_msg, introduce a new
"message out temp" and copy the header into it before sending.

Cc: stable@vger.kernel.org # 4.0+
Reported-by: Matt Conner 
Signed-off-by: Ilya Dryomov 
Tested-by: Matt Conner 
Reviewed-by: Sage Weil 
Signed-off-by: Sasha Levin

crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path

2016-02-03T21:23:19+00:00

[ Upstream commit 6a935170a980024dd29199e9dbb5c4da4767a1b9 ]

This patch allows af_alg_release_parent to be called even for
nokey sockets.

Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: hash - Add crypto_ahash_has_setkey

2016-02-03T21:23:18+00:00

[ Upstream commit a5596d6332787fd383b3b5427b41f94254430827 ]

This patch adds a way for ahash users to determine whether a key
is required by a crypto_ahash transform.

Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin