commit 56d847e3ef9433d7ac92376e4ba49d3cf3cb70d2 Author: Sasha Levin Date: Sat May 27 19:04:04 2017 -0400 Linux 4.1.40 Signed-off-by: Sasha Levin commit 5c564705d3f0436ddc70d833b975b870ba560528 Author: Eric Dumazet Date: Wed Dec 30 08:51:12 2015 -0500 udp: properly support MSG_PEEK with truncated buffers [ Upstream commit 197c949e7798fbf28cfadc69d9ca0c2abbf93191 ] Backport of this upstream commit into stable kernels : 89c22d8c3b27 ("net: Fix skb csum races when peeking") exposed a bug in udp stack vs MSG_PEEK support, when user provides a buffer smaller than skb payload. In this case, skb_copy_and_csum_datagram_iovec(skb, sizeof(struct udphdr), msg->msg_iov); returns -EFAULT. This bug does not happen in upstream kernels since Al Viro did a great job to replace this into : skb_copy_and_csum_datagram_msg(skb, sizeof(struct udphdr), msg); This variant is safe vs short buffers. For the time being, instead reverting Herbert Xu patch and add back skb->ip_summed invalid changes, simply store the result of udp_lib_checksum_complete() so that we avoid computing the checksum a second time, and avoid the problematic skb_copy_and_csum_datagram_iovec() call. This patch can be applied on recent kernels as it avoids a double checksumming, then backported to stable kernels as a bug fix. Signed-off-by: Eric Dumazet Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f97e5ec81364b6edc8d26dfcd0ae43b54d3d43de Author: J. Bruce Fields Date: Fri May 5 16:17:57 2017 -0400 nfsd: encoders mustn't use unitialized values in error cases [ Upstream commit f961e3f2acae94b727380c0b74e2d3954d0edf79 ] In error cases, lgp->lg_layout_type may be out of bounds; so we shouldn't be using it until after the check of nfserr. This was seen to crash nfsd threads when the server receives a LAYOUTGET request with a large layout type. GETDEVICEINFO has the same problem. Reported-by: Ari Kauppi Reviewed-by: Christoph Hellwig Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit a7b4cdeb22f51cbf3b623ea404b0d215ca4eb3ea Author: Mark Rutland Date: Wed May 3 16:09:35 2017 +0100 arm64: uaccess: ensure extension of access_ok() addr [ Upstream commit a06040d7a791a9177581dcf7293941bd92400856 ] Our access_ok() simply hands its arguments over to __range_ok(), which implicitly assummes that the addr parameter is 64 bits wide. This isn't necessarily true for compat code, which might pass down a 32-bit address parameter. In these cases, we don't have a guarantee that the address has been zero extended to 64 bits, and the upper bits of the register may contain unknown values, potentially resulting in a suprious failure. Avoid this by explicitly casting the addr parameter to an unsigned long (as is done on other architectures), ensuring that the parameter is widened appropriately. Fixes: 0aea86a2176c ("arm64: User access library functions") Cc: # 3.7.x- Acked-by: Will Deacon Signed-off-by: Mark Rutland Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit ed3ffd7c7fb9770777b069cbda5c5642f44445e3 Author: Kristina Martsenko Date: Wed May 3 16:37:48 2017 +0100 arm64: documentation: document tagged pointer stack constraints [ Upstream commit f0e421b1bf7af97f026e1bb8bfe4c5a7a8c08f42 ] Some kernel features don't currently work if a task puts a non-zero address tag in its stack pointer, frame pointer, or frame record entries (FP, LR). For example, with a tagged stack pointer, the kernel can't deliver signals to the process, and the task is killed instead. As another example, with a tagged frame pointer or frame records, perf fails to generate call graphs or resolve symbols. For now, just document these limitations, instead of finding and fixing everything that doesn't work, as it's not known if anyone needs to use tags in these places anyway. In addition, as requested by Dave Martin, generalize the limitations into a general kernel address tag policy, and refactor tagged-pointers.txt to include it. Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0") Cc: # 3.12.x- Reviewed-by: Dave Martin Acked-by: Will Deacon Signed-off-by: Kristina Martsenko Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit f8a4b26e261d246023b997d7d724b389a72e9d2d Author: Bart Van Assche Date: Thu May 4 15:50:47 2017 -0700 target/fileio: Fix zero-length READ and WRITE handling [ Upstream commit 59ac9c078141b8fd0186c0b18660a1b2c24e724e ] This patch fixes zero-length READ and WRITE handling in target/FILEIO, which was broken a long time back by: Since: commit d81cb44726f050d7cf1be4afd9cb45d153b52066 Author: Paolo Bonzini Date: Mon Sep 17 16:36:11 2012 -0700 target: go through normal processing for all zero-length commands which moved zero-length READ and WRITE completion out of target-core, to doing submission into backend driver code. To address this, go ahead and invoke target_complete_cmd() for any non negative return value in fd_do_rw(). Signed-off-by: Bart Van Assche Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Cc: Andy Grover Cc: David Disseldorp Cc: # v3.7+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 9d68722df885edcae1eb4d3d144393de9a085336 Author: Björn Jacke Date: Fri May 5 04:36:16 2017 +0200 CIFS: add misssing SFM mapping for doublequote [ Upstream commit 85435d7a15294f9f7ef23469e6aaf7c5dfcc54f0 ] SFM is mapping doublequote to 0xF020 Without this patch creating files with doublequote fails to Windows/Mac Signed-off-by: Bjoern Jacke Signed-off-by: Steve French CC: stable Signed-off-by: Sasha Levin commit 14f24a466cd1218e91b6f1556fd546d0ab0dff06 Author: Nicholas Bellinger Date: Tue Apr 25 10:55:12 2017 -0700 iscsi-target: Set session_fall_back_to_erl0 when forcing reinstatement [ Upstream commit 197b806ae5db60c6f609d74da04ddb62ea5e1b00 ] While testing modification of per se_node_acl queue_depth forcing session reinstatement via lio_target_nacl_cmdsn_depth_store() -> core_tpg_set_initiator_node_queue_depth(), a hung task bug triggered when changing cmdsn_depth invoked session reinstatement while an iscsi login was already waiting for session reinstatement to complete. This can happen when an outstanding se_cmd descriptor is taking a long time to complete, and session reinstatement from iscsi login or cmdsn_depth change occurs concurrently. To address this bug, explicitly set session_fall_back_to_erl0 = 1 when forcing session reinstatement, so session reinstatement is not attempted if an active session is already being shutdown. This patch has been tested with two scenarios. The first when iscsi login is blocked waiting for iscsi session reinstatement to complete followed by queue_depth change via configfs, and second when queue_depth change via configfs us blocked followed by a iscsi login driven session reinstatement. Note this patch depends on commit d36ad77f702 to handle multiple sessions per se_node_acl when changing cmdsn_depth, and for pre v4.5 kernels will need to be included for stable as well. Reported-by: Gary Guo Tested-by: Gary Guo Cc: Gary Guo Cc: # v4.1+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 3aa99b61c0995761281afb192e36cab9be549b62 Author: Nicholas Bellinger Date: Tue Apr 11 16:24:16 2017 -0700 target: Fix compare_and_write_callback handling for non GOOD status [ Upstream commit a71a5dc7f833943998e97ca8fa6a4c708a0ed1a9 ] Following the bugfix for handling non SAM_STAT_GOOD COMPARE_AND_WRITE status during COMMIT phase in commit 9b2792c3da1, the same bug exists for the READ phase as well. This would manifest first as a lost SCSI response, and eventual hung task during fabric driver logout or re-login, as existing shutdown logic waited for the COMPARE_AND_WRITE se_cmd->cmd_kref to reach zero. To address this bug, compare_and_write_callback() has been changed to set post_ret = 1 and return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE as necessary to signal failure status. Reported-by: Bill Borsari Cc: Bill Borsari Tested-by: Gary Guo Cc: Gary Guo Cc: # v4.1+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 0c5623052d48eae8e1308bb882adcc1115b4cee7 Author: Rob Herring Date: Thu May 4 12:34:30 2017 -0500 of: fix sparse warning in of_pci_range_parser_one [ Upstream commit eb3100365791b06242b8bb5c3c2854ba41dabfbc ] sparse gives the following warning for 'pci_space': ../drivers/of/address.c:266:26: warning: incorrect type in assignment (different base types) ../drivers/of/address.c:266:26: expected unsigned int [unsigned] [usertype] pci_space ../drivers/of/address.c:266:26: got restricted __be32 const [usertype] It appears that pci_space is only ever accessed on powerpc, so the endian swap is often not needed. Cc: stable@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 3e9e9c708f1054b7780afa01ecb0d410dcc934f0 Author: Luis Henriques Date: Fri Apr 28 11:14:04 2017 +0100 ceph: fix memory leak in __ceph_setxattr() [ Upstream commit eeca958dce0a9231d1969f86196653eb50fcc9b3 ] The ceph_inode_xattr needs to be released when removing an xattr. Easily reproducible running the 'generic/020' test from xfstests or simply by doing: attr -s attr0 -V 0 /mnt/test && attr -r attr0 /mnt/test While there, also fix the error path. Here's the kmemleak splat: unreferenced object 0xffff88001f86fbc0 (size 64): comm "attr", pid 244, jiffies 4294904246 (age 98.464s) hex dump (first 32 bytes): 40 fa 86 1f 00 88 ff ff 80 32 38 1f 00 88 ff ff @........28..... 00 01 00 00 00 00 ad de 00 02 00 00 00 00 ad de ................ backtrace: [] kmemleak_alloc+0x49/0xa0 [] kmem_cache_alloc+0x9b/0xf0 [] __ceph_setxattr+0x17e/0x820 [] ceph_set_xattr_handler+0x37/0x40 [] __vfs_removexattr+0x4b/0x60 [] vfs_removexattr+0x77/0xd0 [] removexattr+0x41/0x60 [] path_removexattr+0x75/0xa0 [] SyS_lremovexattr+0xb/0x10 [] entry_SYSCALL_64_fastpath+0x13/0x94 [] 0xffffffffffffffff Cc: stable@vger.kernel.org Signed-off-by: Luis Henriques Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 009a83913e29972963d625f83983985a53ab5177 Author: Steve French Date: Wed May 3 21:12:20 2017 -0500 SMB3: Work around mount failure when using SMB3 dialect to Macs [ Upstream commit 7db0a6efdc3e990cdfd4b24820d010e9eb7890ad ] Macs send the maximum buffer size in response on ioctl to validate negotiate security information, which causes us to fail the mount as the response buffer is larger than the expected response. Changed ioctl response processing to allow for padding of validate negotiate ioctl response and limit the maximum response size to maximum buffer size. Signed-off-by: Steve French CC: Stable Signed-off-by: Sasha Levin commit ffd28faab493a239b4ba7af5d810ece1fa613b63 Author: Björn Jacke Date: Wed May 3 23:47:44 2017 +0200 CIFS: fix mapping of SFM_SPACE and SFM_PERIOD [ Upstream commit b704e70b7cf48f9b67c07d585168e102dfa30bb4 ] - trailing space maps to 0xF028 - trailing period maps to 0xF029 This fix corrects the mapping of file names which have a trailing character that would otherwise be illegal (period or space) but is allowed by POSIX. Signed-off-by: Bjoern Jacke CC: Stable Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ae5175c8dba4ce0c8cd7da54cccf98295ab149f9 Author: Andrey Ryabinin Date: Wed May 3 14:56:02 2017 -0700 fs/block_dev: always invalidate cleancache in invalidate_bdev() [ Upstream commit a5f6a6a9c72eac38a7fadd1a038532bc8516337c ] invalidate_bdev() calls cleancache_invalidate_inode() iff ->nrpages != 0 which doen't make any sense. Make sure that invalidate_bdev() always calls cleancache_invalidate_inode() regardless of mapping->nrpages value. Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache") Link: http://lkml.kernel.org/r/20170424164135.22350-3-aryabinin@virtuozzo.com Signed-off-by: Andrey Ryabinin Reviewed-by: Jan Kara Acked-by: Konrad Rzeszutek Wilk Cc: Alexander Viro Cc: Ross Zwisler Cc: Jens Axboe Cc: Johannes Weiner Cc: Alexey Kuznetsov Cc: Christoph Hellwig Cc: Nikolay Borisov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e895a1054e2542b7762fad5a4095d65f4d293471 Author: Richard Weinberger Date: Sat Apr 1 00:41:57 2017 +0200 um: Fix PTRACE_POKEUSER on x86_64 [ Upstream commit 9abc74a22d85ab29cef9896a2582a530da7e79bf ] This is broken since ever but sadly nobody noticed. Recent versions of GDB set DR_CONTROL unconditionally and UML dies due to a heap corruption. It turns out that the PTRACE_POKEUSER was copy&pasted from i386 and assumes that addresses are 4 bytes long. Fix that by using 8 as address size in the calculation. Cc: Reported-by: jie cao Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 327d78550aea59481ef99d500b42927c3735ae5b Author: James Hogan Date: Tue May 2 19:41:06 2017 +0100 metag/uaccess: Check access_ok in strncpy_from_user [ Upstream commit 3a158a62da0673db918b53ac1440845a5b64fd90 ] The metag implementation of strncpy_from_user() doesn't validate the src pointer, which could allow reading of arbitrary kernel memory. Add a short access_ok() check to prevent that. Its still possible for it to read across the user/kernel boundary, but it will invariably reach a NUL character after only 9 bytes, leaking only a static kernel address being loaded into D0Re0 at the beginning of __start, which is acceptable for the immediate fix. Reported-by: Al Viro Signed-off-by: James Hogan Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 31390049dfd2b65da315f0e4f5d98f115ce09352 Author: Steve French Date: Tue May 2 13:35:20 2017 -0500 Set unicode flag on cifs echo request to avoid Mac error [ Upstream commit 26c9cb668c7fbf9830516b75d8bee70b699ed449 ] Mac requires the unicode flag to be set for cifs, even for the smb echo request (which doesn't have strings). Without this Mac rejects the periodic echo requests (when mounting with cifs) that we use to check if server is down Signed-off-by: Steve French CC: Stable Signed-off-by: Sasha Levin commit 3ea80afb2dceac32a72647ceaf2d613a4962ffb5 Author: James Hogan Date: Fri Apr 28 10:50:26 2017 +0100 metag/uaccess: Fix access_ok() [ Upstream commit 8a8b56638bcac4e64cccc88bf95a0f9f4b19a2fb ] The __user_bad() macro used by access_ok() has a few corner cases noticed by Al Viro where it doesn't behave correctly: - The kernel range check has off by 1 errors which permit access to the first and last byte of the kernel mapped range. - The kernel range check ends at LINCORE_BASE rather than META_MEMORY_LIMIT, which is ineffective when the kernel is in global space (an extremely uncommon configuration). There are a couple of other shortcomings here too: - Access to the whole of the other address space is permitted (i.e. the global half of the address space when the kernel is in local space). This isn't ideal as it could theoretically still contain privileged mappings set up by the bootloader. - The size argument is unused, permitting user copies which start on valid pages at the end of the user address range and cross the boundary into the kernel address space (e.g. addr = 0x3ffffff0, size > 0x10). It isn't very convenient to add size checks when disallowing certain regions, and it seems far safer to be sure and explicit about what userland is able to access, so invert the logic to allow certain regions instead, and fix the off by 1 errors and missing size checks. This also allows the get_fs() == KERNEL_DS check to be more easily optimised into the user address range case. We now have 3 such allowed regions: - The user address range (incorporating the get_fs() == KERNEL_DS check). - NULL (some kernel code expects this to work, and we'll always catch the fault anyway). - The core code memory region. Fixes: 373cd784d0fc ("metag: Memory handling") Reported-by: Al Viro Signed-off-by: James Hogan Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 17535d260b75982d8759dcafcc29152789468285 Author: Bart Van Assche Date: Thu Mar 30 10:12:39 2017 -0700 target: Fix VERIFY and WRITE VERIFY command parsing [ Upstream commit 0e2eb7d12eaa8e391bf5615d4271bb87a649caaa ] Use the value of the BYTCHK field to determine the size of the Data-Out buffer. For VERIFY, honor the VRPROTECT, DPO and FUA fields. This patch avoids that LIO complains about a mismatch between the expected transfer length and the SCSI CDB length if the value of the BYTCHK field is 0. Signed-off-by: Bart Van Assche Cc: Max Lohrmann Cc: Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit edd3ad16ead412a1b52e8bc9544b8908e62ee2e7 Author: Mikulas Patocka Date: Sun Apr 30 17:34:53 2017 -0400 dm bufio: check new buffer allocation watermark every 30 seconds [ Upstream commit 390020ad2af9ca04844c4f3b1f299ad8746d84c8 ] dm-bufio checks a watermark when it allocates a new buffer in __bufio_new(). However, it doesn't check the watermark when the user changes /sys/module/dm_bufio/parameters/max_cache_size_bytes. This may result in a problem - if the watermark is high enough so that all possible buffers are allocated and if the user lowers the value of "max_cache_size_bytes", the watermark will never be checked against the new value because no new buffer would be allocated. To fix this, change __evict_old_buffers() so that it checks the watermark. __evict_old_buffers() is called every 30 seconds, so if the user reduces "max_cache_size_bytes", dm-bufio will react to this change within 30 seconds and decrease memory consumption. Depends-on: 1b0fb5a5b2 ("dm bufio: avoid a possible ABBA deadlock") Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit bbe86592f9c33a5a34bed9b02d7ec1a6e5a287ec Author: Mikulas Patocka Date: Sun Apr 30 17:33:26 2017 -0400 dm bufio: avoid a possible ABBA deadlock [ Upstream commit 1b0fb5a5b2dc0dddcfa575060441a7176ba7ac37 ] __get_memory_limit() tests if dm_bufio_cache_size changed and calls __cache_size_refresh() if it did. It takes dm_bufio_clients_lock while it already holds the client lock. However, lock ordering is violated because in cleanup_old_buffers() dm_bufio_clients_lock is taken before the client lock. This results in a possible deadlock and lockdep engine warning. Fix this deadlock by changing mutex_lock() to mutex_trylock(). If the lock can't be taken, it will be re-checked next time when a new buffer is allocated. Also add "unlikely" to the if condition, so that the optimizer assumes that the condition is false. Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 9575253a91e6fb3cb88ba95e7802c6b0aa215c7e Author: Szymon Janc Date: Mon Apr 24 18:25:04 2017 -0700 Bluetooth: Fix user channel for 32bit userspace on 64bit kernel [ Upstream commit ab89f0bdd63a3721f7cd3f064f39fc4ac7ca14d4 ] Running 32bit userspace on 64bit kernel results in MSG_CMSG_COMPAT being defined as 0x80000000. This results in sendmsg failure if used from 32bit userspace running on 64bit kernel. Fix this by accounting for MSG_CMSG_COMPAT in flags check in hci_sock_sendmsg. Signed-off-by: Szymon Janc Signed-off-by: Marko Kiiskila Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ca38d087f1b0f8d2478fbe3da455f03bf3f69ee4 Author: Eric Biggers Date: Sun Apr 30 00:10:50 2017 -0400 ext4: evict inline data when writing to memory map [ Upstream commit 7b4cc9787fe35b3ee2dfb1c35e22eafc32e00c33 ] Currently the case of writing via mmap to a file with inline data is not handled. This is maybe a rare case since it requires a writable memory map of a very small file, but it is trivial to trigger with on inline_data filesystem, and it causes the 'BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA));' in ext4_writepages() to be hit: mkfs.ext4 -O inline_data /dev/vdb mount /dev/vdb /mnt xfs_io -f /mnt/file \ -c 'pwrite 0 1' \ -c 'mmap -w 0 1m' \ -c 'mwrite 0 1' \ -c 'fsync' kernel BUG at fs/ext4/inode.c:2723! invalid opcode: 0000 [#1] SMP CPU: 1 PID: 2532 Comm: xfs_io Not tainted 4.11.0-rc1-xfstests-00301-g071d9acf3d1f #633 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014 task: ffff88003d3a8040 task.stack: ffffc90000300000 RIP: 0010:ext4_writepages+0xc89/0xf8a RSP: 0018:ffffc90000303ca0 EFLAGS: 00010283 RAX: 0000028410000000 RBX: ffff8800383fa3b0 RCX: ffffffff812afcdc RDX: 00000a9d00000246 RSI: ffffffff81e660e0 RDI: 0000000000000246 RBP: ffffc90000303dc0 R08: 0000000000000002 R09: 869618e8f99b4fa5 R10: 00000000852287a2 R11: 00000000a03b49f4 R12: ffff88003808e698 R13: 0000000000000000 R14: 7fffffffffffffff R15: 7fffffffffffffff FS: 00007fd3e53094c0(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd3e4c51000 CR3: 000000003d554000 CR4: 00000000003406e0 Call Trace: ? _raw_spin_unlock+0x27/0x2a ? kvm_clock_read+0x1e/0x20 do_writepages+0x23/0x2c ? do_writepages+0x23/0x2c __filemap_fdatawrite_range+0x80/0x87 filemap_write_and_wait_range+0x67/0x8c ext4_sync_file+0x20e/0x472 vfs_fsync_range+0x8e/0x9f ? syscall_trace_enter+0x25b/0x2d0 vfs_fsync+0x1c/0x1e do_fsync+0x31/0x4a SyS_fsync+0x10/0x14 do_syscall_64+0x69/0x131 entry_SYSCALL64_slow_path+0x25/0x25 We could try to be smart and keep the inline data in this case, or at least support delayed allocation when allocating the block, but these solutions would be more complicated and don't seem worthwhile given how rare this case seems to be. So just fix the bug by calling ext4_convert_inline_data() when we're asked to make a page writable, so that any inline data gets evicted, with the block allocated immediately. Reported-by: Nick Alcock Cc: stable@vger.kernel.org Reviewed-by: Andreas Dilger Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 3a9700b0709e1db2179f915d3be3a77aba29240c Author: Takashi Iwai Date: Fri Apr 28 15:00:15 2017 +0200 proc: Fix unbalanced hard link numbers [ Upstream commit d66bb1607e2d8d384e53f3d93db5c18483c8c4f7 ] proc_create_mount_point() forgot to increase the parent's nlink, and it resulted in unbalanced hard link numbers, e.g. /proc/fs shows one less than expected. Fixes: eb6d38d5427b ("proc: Allow creating permanently empty directories...") Cc: stable@vger.kernel.org Reported-by: Tristan Ye Signed-off-by: Takashi Iwai Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 2279c8b917f7840f1e623cadeb07c12fefc45c77 Author: Adrian Salido Date: Thu Apr 27 10:32:55 2017 -0700 dm ioctl: prevent stack leak in dm ioctl call [ Upstream commit 4617f564c06117c7d1b611be49521a4430042287 ] When calling a dm ioctl that doesn't process any data (IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct dm_ioctl are left initialized. Current code is incorrectly extending the size of data copied back to user, causing the contents of kernel stack to be leaked to user. Fix by only copying contents before data and allow the functions processing the ioctl to override. Cc: stable@vger.kernel.org Signed-off-by: Adrian Salido Reviewed-by: Alasdair G Kergon Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 5afff19d82af4e4ed66ce0320cd2f17053b78b25 Author: J. Bruce Fields Date: Fri Apr 21 15:26:30 2017 -0400 nfsd: stricter decoding of write-like NFSv2/v3 ops [ Upstream commit 13bf9fbff0e5e099e2b6f003a0ab8ae145436309 ] The NFSv2/v3 code does not systematically check whether we decode past the end of the buffer. This generally appears to be harmless, but there are a few places where we do arithmetic on the pointers involved and don't account for the possibility that a length could be negative. Add checks to catch these. Reported-by: Tuomas Haanpää Reported-by: Ari Kauppi Reviewed-by: NeilBrown Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 24c3569dd195a26d816b67bb50ebdbc501001038 Author: J. Bruce Fields Date: Tue Apr 25 16:21:34 2017 -0400 nfsd4: minor NFSv2/v3 write decoding cleanup [ Upstream commit db44bac41bbfc0c0d9dd943092d8bded3c9db19b ] Use a couple shortcuts that will simplify a following bugfix. Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit c9bb9f02b0484703ca5d0da15a11f891954e1c31 Author: J. Bruce Fields Date: Fri Apr 21 16:10:18 2017 -0400 nfsd: check for oversized NFSv2/v3 arguments [ Upstream commit e6838a29ecb484c97e4efef9429643b9851fba6e ] A client can append random data to the end of an NFSv2 or NFSv3 RPC call without our complaining; we'll just stop parsing at the end of the expected data and ignore the rest. Encoded arguments and replies are stored together in an array of pages, and if a call is too large it could leave inadequate space for the reply. This is normally OK because NFS RPC's typically have either short arguments and long replies (like READ) or long arguments and short replies (like WRITE). But a client that sends an incorrectly long reply can violate those assumptions. This was observed to cause crashes. Also, several operations increment rq_next_page in the decode routine before checking the argument size, which can leave rq_next_page pointing well past the end of the page array, causing trouble later in svc_free_pages. So, following a suggestion from Neil Brown, add a central check to enforce our expectation that no NFSv2/v3 call has both a large call and a large reply. As followup we may also want to rewrite the encoding routines to check more carefully that they aren't running off the end of the page array. We may also consider rejecting calls that have any extra garbage appended. That would be safer, and within our rights by spec, but given the age of our server and the NFS protocol, and the fact that we've never enforced this before, we may need to balance that against the possibility of breaking some oddball client. Reported-by: Tuomas Haanpää Reported-by: Ari Kauppi Cc: stable@vger.kernel.org Reviewed-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 6a5e61496c48575b0e0f00fd90d2b4583f84d9dd Author: Alexey Brodkin Date: Thu Apr 13 15:33:34 2017 +0300 usb: Make sure usb/phy/of gets built-in [ Upstream commit 3d6159640da9c9175d1ca42f151fc1a14caded59 ] DWC3 driver uses of_usb_get_phy_mode() which is implemented in drivers/usb/phy/of.c and in bare minimal configuration it might not be pulled in kernel binary. In case of ARC or ARM this could be easily reproduced with "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m. On building all ends-up with: ---------------------->8------------------ Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Building modules, stage 2. MODPOST 5 modules ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 ---------------------->8------------------ Signed-off-by: Alexey Brodkin Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Geert Uytterhoeven Cc: Nicolas Pitre Cc: Thomas Gleixner Cc: Felipe Balbi Cc: Felix Fietkau Cc: Jeremy Kerr Cc: linux-snps-arc@lists.infradead.org Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 372323131cd027b0c24af1847fe8b34e69f5dedb Author: Takashi Iwai Date: Mon Apr 24 14:09:55 2017 +0200 ASoC: intel: Fix PM and non-atomic crash in bytcr drivers [ Upstream commit 6e4cac23c5a648d50b107d1b53e9c4e1120c7943 ] The FE setups of Intel SST bytcr_rt5640 and bytcr_rt5651 drivers carry the ignore_suspend flag, and this prevents the suspend/resume working properly while the stream is running, since SST core code has the check of the running streams and returns -EBUSY. Drop these superfluous flags for fixing the behavior. Also, the bytcr_rt5640 driver lacks of nonatomic flag in some FE definitions, which leads to the kernel Oops at suspend/resume like: BUG: scheduling while atomic: systemd-sleep/3144/0x00000003 Call Trace: dump_stack+0x5c/0x7a __schedule_bug+0x55/0x70 __schedule+0x63c/0x8c0 schedule+0x3d/0x90 schedule_timeout+0x16b/0x320 ? del_timer_sync+0x50/0x50 ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core] ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core] ? remove_wait_queue+0x60/0x60 ? sst_prepare_and_post_msg+0x275/0x960 [snd_intel_sst_core] ? sst_pause_stream+0x9b/0x110 [snd_intel_sst_core] .... This patch addresses these appropriately, too. Signed-off-by: Takashi Iwai Acked-by: Vinod Koul Signed-off-by: Mark Brown Cc: # v4.1+ Signed-off-by: Sasha Levin commit b583cc9354777c5cbd7cdcac1399a75545699cfd Author: Dmitry Torokhov Date: Thu Apr 13 15:36:31 2017 -0700 Input: i8042 - add Clevo P650RS to the i8042 reset list [ Upstream commit 7c5bb4ac2b76d2a09256aec8a7d584bf3e2b0466 ] Clevo P650RS and other similar devices require i8042 to be reset in order to detect Synaptics touchpad. Reported-by: Paweł Bylica Tested-by: Ed Bordin Cc: stable@vger.kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=190301 Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 56e1917012527d4d84c2a97834aa03d9b7c8c3f4 Author: Somasundaram Krishnasamy Date: Fri Apr 7 12:14:55 2017 -0700 dm era: save spacemap metadata root after the pre-commit [ Upstream commit 117aceb030307dcd431fdcff87ce988d3016c34a ] When committing era metadata to disk, it doesn't always save the latest spacemap metadata root in superblock. Due to this, metadata is getting corrupted sometimes when reopening the device. The correct order of update should be, pre-commit (shadows spacemap root), save the spacemap root (newly shadowed block) to in-core superblock and then the final commit. Cc: stable@vger.kernel.org Signed-off-by: Somasundaram Krishnasamy Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 6a887571cad2bbc08bb6a1a6fcd8d1f0576c6cd2 Author: Vinothkumar Raja Date: Thu Apr 6 22:09:38 2017 -0400 dm btree: fix for dm_btree_find_lowest_key() [ Upstream commit 7d1fedb6e96a960aa91e4ff70714c3fb09195a5a ] dm_btree_find_lowest_key() is giving incorrect results. find_key() traverses the btree correctly for finding the highest key, but there is an error in the way it traverses the btree for retrieving the lowest key. dm_btree_find_lowest_key() fetches the first key of the rightmost block of the btree instead of fetching the first key from the leftmost block. Fix this by conditionally passing the correct parameter to value64() based on the @find_highest flag. Cc: stable@vger.kernel.org Signed-off-by: Erez Zadok Signed-off-by: Vinothkumar Raja Signed-off-by: Nidhi Panpalia Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 2ad7696baa06de950c27cc8dc2654001b6e921de Author: Tyrel Datwyler Date: Mon Apr 17 20:21:40 2017 -0400 powerpc/pseries: Fix of_node_put() underflow during DLPAR remove [ Upstream commit 68baf692c435339e6295cb470ea5545cbc28160e ] Historically struct device_node references were tracked using a kref embedded as a struct field. Commit 75b57ecf9d1d ("of: Make device nodes kobjects so they show up in sysfs") (Mar 2014) refactored device_nodes to be kobjects such that the device tree could by more simply exposed to userspace using sysfs. Commit 0829f6d1f69e ("of: device_node kobject lifecycle fixes") (Mar 2014) followed up these changes to better control the kobject lifecycle and in particular the referecne counting via of_node_get(), of_node_put(), and of_node_init(). A result of this second commit was that it introduced an of_node_put() call when a dynamic node is detached, in of_node_remove(), that removes the initial kobj reference created by of_node_init(). Traditionally as the original dynamic device node user the pseries code had assumed responsibilty for releasing this final reference in its platform specific DLPAR detach code. This patch fixes a refcount underflow introduced by commit 0829f6d1f6, and recently exposed by the upstreaming of the recount API. Messages like the following are no longer seen in the kernel log with this patch following DLPAR remove operations of cpus and pci devices. rpadlpar_io: slot PHB 72 removed refcount_t: underflow; use-after-free. ------------[ cut here ]------------ WARNING: CPU: 5 PID: 3335 at lib/refcount.c:128 refcount_sub_and_test+0xf4/0x110 Fixes: 0829f6d1f69e ("of: device_node kobject lifecycle fixes") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Tyrel Datwyler [mpe: Make change log commit references more verbose] Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit e756dc9e7bfbd3c0c6374d5397d2d0e757240a3d Author: Jack Morgenstein Date: Tue Mar 21 12:57:05 2017 +0200 IB/mlx4: Fix ib device initialization error flow [ Upstream commit 99e68909d5aba1861897fe7afc3306c3c81b6de0 ] In mlx4_ib_add, procedure mlx4_ib_alloc_eqs is called to allocate EQs. However, in the mlx4_ib_add error flow, procedure mlx4_ib_free_eqs is not called to free the allocated EQs. Fixes: e605b743f33d ("IB/mlx4: Increase the number of vectors (EQs) available for ULPs") Cc: # v3.4+ Signed-off-by: Jack Morgenstein Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 50f63ac752b8c443d63670493925713cf8ebe508 Author: Ashish Kalra Date: Wed Apr 19 20:50:15 2017 +0530 x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup [ Upstream commit d594aa0277e541bb997aef0bc0a55172d8138340 ] The minimum size for a new stack (512 bytes) setup for arch/x86/boot components when the bootloader does not setup/provide a stack for the early boot components is not "enough". The setup code executing as part of early kernel startup code, uses the stack beyond 512 bytes and accidentally overwrites and corrupts part of the BSS section. This is exposed mostly in the early video setup code, where it was corrupting BSS variables like force_x, force_y, which in-turn affected kernel parameters such as screen_info (screen_info.orig_video_cols) and later caused an exception/panic in console_init(). Most recent boot loaders setup the stack for early boot components, so this stack overwriting into BSS section issue has not been exposed. Signed-off-by: Ashish Kalra Cc: Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20170419152015.10011-1-ashishkalra@Ashishs-MacBook-Pro.local Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 51cad4572c0222f8232ba85c9ecfb5f54b2486c1 Author: Steven Rostedt (VMware) Date: Wed Apr 19 14:29:46 2017 -0400 ring-buffer: Have ring_buffer_iter_empty() return true when empty [ Upstream commit 78f7a45dac2a2d2002f98a3a95f7979867868d73 ] I noticed that reading the snapshot file when it is empty no longer gives a status. It suppose to show the status of the snapshot buffer as well as how to allocate and use it. For example: ># cat snapshot # tracer: nop # # # * Snapshot is allocated * # # Snapshot commands: # echo 0 > snapshot : Clears and frees snapshot buffer # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated. # Takes a snapshot of the main buffer. # echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free) # (Doesn't have to be '2' works with any number that # is not a '0' or '1') But instead it just showed an empty buffer: ># cat snapshot # tracer: nop # # entries-in-buffer/entries-written: 0/0 #P:4 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | What happened was that it was using the ring_buffer_iter_empty() function to see if it was empty, and if it was, it showed the status. But that function was returning false when it was empty. The reason was that the iter header page was on the reader page, and the reader page was empty, but so was the buffer itself. The check only tested to see if the iter was on the commit page, but the commit page was no longer pointing to the reader page, but as all pages were empty, the buffer is also. Cc: stable@vger.kernel.org Fixes: 651e22f2701b ("ring-buffer: Always reset iterator to reader page") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 2933c0ba9193d9e7754c89db6ec817657c38f3aa Author: Arnd Bergmann Date: Wed Apr 19 19:47:04 2017 +0200 ACPI / power: Avoid maybe-uninitialized warning [ Upstream commit fe8c470ab87d90e4b5115902dd94eced7e3305c3 ] gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state() is enterered at least once, so it assumes that cur_state might not get initialized: drivers/acpi/power.c: In function 'acpi_power_get_inferred_state': drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized] This sets the variable to zero at the start of the loop, to ensure that there is well-defined behavior even for an empty list. This gets rid of the warning. The warning first showed up when the -Os flag got removed in a bug fix patch in linux-4.11-rc5. I would suggest merging this addon patch on top of that bug fix to avoid introducing a new warning in the stable kernels. Fixes: 61b79e16c68d (ACPI: Fix incompatibility with mcount-based function graph tracing) Cc: All applicable Signed-off-by: Arnd Bergmann Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f7f44f58872253e8f5d8a9a86bf3f5aea265af29 Author: Steven Rostedt (VMware) Date: Wed Apr 19 12:07:08 2017 -0400 tracing: Allocate the snapshot buffer before enabling probe [ Upstream commit df62db5be2e5f070ecd1a5ece5945b590ee112e0 ] Currently the snapshot trigger enables the probe and then allocates the snapshot. If the probe triggers before the allocation, it could cause the snapshot to fail and turn tracing off. It's best to allocate the snapshot buffer first, and then enable the trigger. If something goes wrong in the enabling of the trigger, the snapshot buffer is still allocated, but it can also be freed by the user by writting zero into the snapshot buffer file. Also add a check of the return status of alloc_snapshot(). Cc: stable@vger.kernel.org Fixes: 77fd5c15e3 ("tracing: Add snapshot trigger to function probes") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 73270592d94b8e740d0ac044fc48c7749df593a0 Author: Peter Chen Date: Wed Apr 19 16:55:52 2017 +0300 usb: host: xhci: print correct command ring address [ Upstream commit 6fc091fb0459ade939a795bfdcaf645385b951d4 ] Print correct command ring address using 'val_64'. Cc: stable Signed-off-by: Peter Chen Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5ba52c08d1d1ca91386f644afadb546554b2192e Author: Alyssa Milburn Date: Sat Apr 1 14:34:32 2017 -0300 [media] ttusb2: limit messages to buffer size [ Upstream commit a12b8ab8c5ff7ccd7b107a564743507c850a441d ] Otherwise ttusb2_i2c_xfer can read or write beyond the end of static and heap buffers. Signed-off-by: Alyssa Milburn Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e1dfe98dda6a97d7df4bde0ec41bf2eecb62ff70 Author: Marek Vasut Date: Tue Apr 18 20:07:56 2017 +0200 USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit [ Upstream commit 31c5d1922b90ddc1da6a6ddecef7cd31f17aa32b ] This development kit has an FT4232 on it with a custom USB VID/PID. The FT4232 provides four UARTs, but only two are used. The UART 0 is used by the FlashPro5 programmer and UART 2 is connected to the SmartFusion2 CortexM3 SoC UART port. Note that the USB VID is registered to Actel according to Linux USB VID database, but that was acquired by Microsemi. Signed-off-by: Marek Vasut Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 00461b9f48179e4621c8c79672af11b341b55848 Author: Lukas Wunner Date: Tue Apr 18 20:44:30 2017 +0200 PCI: Freeze PME scan before suspending devices [ Upstream commit ea00353f36b64375518662a8ad15e39218a1f324 ] Laurent Pinchart reported that the Renesas R-Car H2 Lager board (r8a7790) crashes during suspend tests. Geert Uytterhoeven managed to reproduce the issue on an M2-W Koelsch board (r8a7791): It occurs when the PME scan runs, once per second. During PME scan, the PCI host bridge (rcar-pci) registers are accessed while its module clock has already been disabled, leading to the crash. One reproducer is to configure s2ram to use "s2idle" instead of "deep" suspend: # echo 0 > /sys/module/printk/parameters/console_suspend # echo s2idle > /sys/power/mem_sleep # echo mem > /sys/power/state Another reproducer is to write either "platform" or "processors" to /sys/power/pm_test. It does not (or is less likely) to happen during full system suspend ("core" or "none") because system suspend also disables timers, and thus the workqueue handling PME scans no longer runs. Geert believes the issue may still happen in the small window between disabling module clocks and disabling timers: # echo 0 > /sys/module/printk/parameters/console_suspend # echo platform > /sys/power/pm_test # Or "processors" # echo mem > /sys/power/state (Make sure CONFIG_PCI_RCAR_GEN2 and CONFIG_USB_OHCI_HCD_PCI are enabled.) Rafael Wysocki agrees that PME scans should be suspended before the host bridge registers become inaccessible. To that end, queue the task on a workqueue that gets frozen before devices suspend. Rafael notes however that as a result, some wakeup events may be missed if they are delivered via PME from a device without working IRQ (which hence must be polled) and occur after the workqueue has been frozen. If that turns out to be an issue in practice, it may be possible to solve it by calling pci_pme_list_scan() once directly from one of the host bridge's pm_ops callbacks. Stacktrace for posterity: PM: Syncing filesystems ... [ 38.566237] done. PM: Preparing system for sleep (mem) Freezing user space processes ... [ 38.579813] (elapsed 0.001 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. PM: Suspending system (mem) PM: suspend of devices complete after 152.456 msecs PM: late suspend of devices complete after 2.809 msecs PM: noirq suspend of devices complete after 29.863 msecs suspend debug: Waiting for 5 second(s). Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 pgd = c0003000 [00000000] *pgd=80000040004003, *pmd=00000000 Internal error: : 1211 [#1] SMP ARM Modules linked in: CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted 4.9.0-rc1-koelsch-00011-g68db9bc814362e7f #3383 Hardware name: Generic R8A7791 (Flattened Device Tree) Workqueue: events pci_pme_list_scan task: eb56e140 task.stack: eb58e000 PC is at pci_generic_config_read+0x64/0x6c LR is at rcar_pci_cfg_base+0x64/0x84 pc : [] lr : [] psr: 600d0093 sp : eb58fe98 ip : c041d750 fp : 00000008 r10: c0e2283c r9 : 00000000 r8 : 600d0013 r7 : 00000008 r6 : eb58fed6 r5 : 00000002 r4 : eb58feb4 r3 : 00000000 r2 : 00000044 r1 : 00000008 r0 : 00000000 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 30c5387d Table: 6a9f6c80 DAC: 55555555 Process kworker/1:1 (pid: 20, stack limit = 0xeb58e210) Stack: (0xeb58fe98 to 0xeb590000) fe80: 00000002 00000044 fea0: eb6f5800 c041d9b0 eb58feb4 00000008 00000044 00000000 eb78a000 eb78a000 fec0: 00000044 00000000 eb9aff00 c0424bf0 eb78a000 00000000 eb78a000 c0e22830 fee0: ea8a6fc0 c0424c5c eaae79c0 c0424ce0 eb55f380 c0e22838 eb9a9800 c0235fbc ff00: eb55f380 c0e22838 eb55f380 eb9a9800 eb9a9800 eb58e000 eb9a9824 c0e02100 ff20: eb55f398 c02366c4 eb56e140 eb5631c0 00000000 eb55f380 c023641c 00000000 ff40: 00000000 00000000 00000000 c023a928 cd105598 00000000 40506a34 eb55f380 ff60: 00000000 00000000 dead4ead ffffffff ffffffff eb58ff74 eb58ff74 00000000 ff80: 00000000 dead4ead ffffffff ffffffff eb58ff90 eb58ff90 eb58ffac eb5631c0 ffa0: c023a844 00000000 00000000 c0206d68 00000000 00000000 00000000 00000000 ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 3a81336c 10ccd1dd [] (pci_generic_config_read) from [] (pci_bus_read_config_word+0x58/0x80) [] (pci_bus_read_config_word) from [] (pci_check_pme_status+0x34/0x78) [] (pci_check_pme_status) from [] (pci_pme_wakeup+0x28/0x54) [] (pci_pme_wakeup) from [] (pci_pme_list_scan+0x58/0xb4) [] (pci_pme_list_scan) from [] (process_one_work+0x1bc/0x308) [] (process_one_work) from [] (worker_thread+0x2a8/0x3e0) [] (worker_thread) from [] (kthread+0xe4/0xfc) [] (kthread) from [] (ret_from_fork+0x14/0x2c) Code: ea000000 e5903000 f57ff04f e3a00000 (e5843000) ---[ end trace 667d43ba3aa9e589 ]--- Fixes: df17e62e5bff ("PCI: Add support for polling PME state on suspended legacy PCI devices") Reported-and-tested-by: Laurent Pinchart Reported-and-tested-by: Geert Uytterhoeven Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Laurent Pinchart Acked-by: Rafael J. Wysocki Cc: stable@vger.kernel.org # 2.6.37+ Cc: Mika Westerberg Cc: Niklas Söderlund Cc: Simon Horman Cc: Yinghai Lu Cc: Matthew Garrett Signed-off-by: Sasha Levin commit 57b8e3a6524b856604576668bc012de63eeab5ad Author: Richard Cochran Date: Mon Apr 17 10:23:36 2017 +0200 regulator: tps65023: Fix inverted core enable logic. [ Upstream commit c90722b54a4f5e21ac59301ed9a6dbaa439bdb16 ] Commit 43530b69d758328d3ffe6ab98fd640463e8e3667 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly") intended to replace working inline helper functions with standard regmap calls. However, it also inverted the set/clear logic of the "CORE ADJ Allowed" bit. That patch was clearly never tested, since without that bit cleared, the core VDCDC1 voltage output does not react to I2C configuration changes. This patch fixes the issue by clearing the bit as in the original, correct implementation. Note for stable back porting that, due to subsequent driver churn, this patch will not apply on every kernel version. Fixes: 43530b69d758 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly") Signed-off-by: Richard Cochran Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1ff629068e6e0fe2270272e3976eefef00fa5cc7 Author: Alyssa Milburn Date: Sat Apr 1 14:34:08 2017 -0300 [media] zr364xx: enforce minimum size when reading header [ Upstream commit ee0fe833d96793853335844b6d99fb76bd12cbeb ] This code copies actual_length-128 bytes from the header, which will underflow if the received buffer is too small. Signed-off-by: Alyssa Milburn Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a0f82864854a4511cd19f06436f0cf140fae2427 Author: Eric Biggers Date: Tue Apr 18 15:31:09 2017 +0100 KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings [ Upstream commit c9f838d104fed6f2f61d68164712e3204bf5271b ] This fixes CVE-2017-7472. Running the following program as an unprivileged user exhausts kernel memory by leaking thread keyrings: #include int main() { for (;;) keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING); } Fix it by only creating a new thread keyring if there wasn't one before. To make things more consistent, make install_thread_keyring_to_cred() and install_process_keyring_to_cred() both return 0 if the corresponding keyring is already present. Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials") Cc: stable@vger.kernel.org # 2.6.29+ Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 86d961e2588830120cab2eb4d2f1d5325d165571 Author: David Howells Date: Tue Apr 18 15:31:08 2017 +0100 KEYS: Change the name of the dead type to ".dead" to prevent user access [ Upstream commit c1644fe041ebaf6519f6809146a77c3ead9193af ] This fixes CVE-2017-6951. Userspace should not be able to do things with the "dead" key type as it doesn't have some of the helper functions set upon it that the kernel needs. Attempting to use it may cause the kernel to crash. Fix this by changing the name of the type to ".dead" so that it's rejected up front on userspace syscalls by key_get_type_from_user(). Though this doesn't seem to affect recent kernels, it does affect older ones, certainly those prior to: commit c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81 Author: David Howells Date: Tue Sep 16 17:36:06 2014 +0100 KEYS: Remove key_type::match in favour of overriding default by match_preparse which went in before 3.18-rc1. Signed-off-by: David Howells cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 4ef48e49b1c550a511acb78d7b9e0b52bb43aba6 Author: David Howells Date: Tue Apr 18 15:31:07 2017 +0100 KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings [ Upstream commit ee8f844e3c5a73b999edf733df1c529d6503ec2f ] This fixes CVE-2016-9604. Keyrings whose name begin with a '.' are special internal keyrings and so userspace isn't allowed to create keyrings by this name to prevent shadowing. However, the patch that added the guard didn't fix KEYCTL_JOIN_SESSION_KEYRING. Not only can that create dot-named keyrings, it can also subscribe to them as a session keyring if they grant SEARCH permission to the user. This, for example, allows a root process to set .builtin_trusted_keys as its session keyring, at which point it has full access because now the possessor permissions are added. This permits root to add extra public keys, thereby bypassing module verification. This also affects kexec and IMA. This can be tested by (as root): keyctl session .builtin_trusted_keys keyctl add user a a @s keyctl list @s which on my test box gives me: 2 keys in keyring: 180010936: ---lswrv 0 0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05 801382539: --alswrv 0 0 user: a Fix this by rejecting names beginning with a '.' in the keyctl. Signed-off-by: David Howells Acked-by: Mimi Zohar cc: linux-ima-devel@lists.sourceforge.net cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 369cd39335063bd5e7272124b593851bfa29958e Author: Ravi Bangoria Date: Tue Apr 11 10:38:13 2017 +0530 powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction [ Upstream commit 9e1ba4f27f018742a1aa95d11e35106feba08ec1 ] If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel OOPS: Bad kernel stack pointer cd93c840 at c000000000009868 Oops: Bad kernel stack pointer, sig: 6 [#1] ... GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840 ... NIP [c000000000009868] resume_kernel+0x2c/0x58 LR [c000000000006208] program_check_common+0x108/0x180 On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does not emulate actual store in emulate_step() because it may corrupt the exception frame. So the kernel does the actual store operation in exception return code i.e. resume_kernel(). resume_kernel() loads the saved stack pointer from memory using lwz, which only loads the low 32-bits of the address, causing the kernel crash. Fix this by loading the 64-bit value instead. Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of emulate_step()") Cc: stable@vger.kernel.org # v3.18+ Signed-off-by: Ravi Bangoria Reviewed-by: Naveen N. Rao Reviewed-by: Ananth N Mavinakayanahalli [mpe: Change log massage, add stable tag] Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 199ea04d7d01488595a747a79e6c5542a2a1f52f Author: Sachin Prabhu Date: Sun Apr 16 20:37:24 2017 +0100 cifs: Do not send echoes before Negotiate is complete [ Upstream commit 62a6cfddcc0a5313e7da3e8311ba16226fe0ac10 ] commit 4fcd1813e640 ("Fix reconnect to not defer smb3 session reconnect long after socket reconnect") added support for Negotiate requests to be initiated by echo calls. To avoid delays in calling echo after a reconnect, I added the patch introduced by the commit b8c600120fc8 ("Call echo service immediately after socket reconnect"). This has however caused a regression with cifs shares which do not have support for echo calls to trigger Negotiate requests. On connections which need to call Negotiation, the echo calls trigger an error which triggers a reconnect which in turn triggers another echo call. This results in a loop which is only broken when an operation is performed on the cifs share. For an idle share, it can DOS a server. The patch uses the smb_operation can_echo() for cifs so that it is called only if connection has been already been setup. kernel bz: 194531 Signed-off-by: Sachin Prabhu Tested-by: Jonathan Liu Acked-by: Pavel Shilovsky CC: Stable Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b291f2ed870ad97ecf945f90d6de68ca5827c883 Author: Al Viro Date: Fri Apr 14 17:22:18 2017 -0400 p9_client_readdir() fix [ Upstream commit 71d6ad08379304128e4bdfaf0b4185d54375423e ] Don't assume that server is sane and won't return more data than asked for. Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 98ae917fd128adac4f4563999013b79844c88c11 Author: Ludovic Desroches Date: Mon Apr 10 10:25:17 2017 +0200 ARM: dts: at91: sama5d3_xplained: not all ADC channels are available [ Upstream commit d3df1ec06353e51fc44563d2e7e18d42811af290 ] Remove ADC channels that are not available by default on the sama5d3_xplained board (resistor not populated) in order to not create confusion. Signed-off-by: Ludovic Desroches Cc: # 3.16+ Acked-by: Nicolas Ferre Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 429957317eac0e60cb703dc66c7e752d919e5d1e Author: Ludovic Desroches Date: Mon Apr 10 10:25:16 2017 +0200 ARM: dts: at91: sama5d3_xplained: fix ADC vref [ Upstream commit 9cdd31e5913c1f86dce7e201b086155b3f24896b ] The voltage reference for the ADC is not 3V but 3.3V since it is connected to VDDANA. Signed-off-by: Ludovic Desroches Cc: # 3.16+ Acked-by: Nicolas Ferre Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit c7f3669caa0b37d1e96a3a1c4fe926be4c6f8b60 Author: Minchan Kim Date: Thu Apr 13 14:56:37 2017 -0700 zram: do not use copy_page with non-page aligned address [ Upstream commit d72e9a7a93e4f8e9e52491921d99e0c8aa89eb4e ] The copy_page is optimized memcpy for page-alinged address. If it is used with non-page aligned address, it can corrupt memory which means system corruption. With zram, it can happen with 1. 64K architecture 2. partial IO 3. slub debug Partial IO need to allocate a page and zram allocates it via kmalloc. With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned address. And finally, copy_page(mem, cmem) corrupts memory. So, this patch changes it to memcpy. Actuaully, we don't need to change zram_bvec_write part because zsmalloc returns page-aligned address in case of PAGE_SIZE class but it's not good to rely on the internal of zsmalloc. Note: When this patch is merged to stable, clear_page should be fixed, too. Unfortunately, recent zram removes it by "same page merge" feature so it's hard to backport this patch to -stable tree. I will handle it when I receive the mail from stable tree maintainer to merge this patch to backport. Fixes: 42e99bd ("zram: optimize memory operations with clear_page()/copy_page()") Link: http://lkml.kernel.org/r/1492042622-12074-2-git-send-email-minchan@kernel.org Signed-off-by: Minchan Kim Cc: Sergey Senozhatsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ac87ea2ff7d7b88aa0bde25c425c51085976fbf3 Author: Minchan Kim Date: Thu Apr 13 14:56:35 2017 -0700 zram: fix operator precedence to get offset [ Upstream commit 4ca82dabc9fbf7bc5322aa54d802cb3cb7b125c5 ] In zram_rw_page, the logic to get offset is wrong by operator precedence (i.e., "<<" is higher than "&"). With wrong offset, zram can corrupt the user's data. This patch fixes it. Fixes: 8c7f01025 ("zram: implement rw_page operation of zram") Link: http://lkml.kernel.org/r/1492042622-12074-1-git-send-email-minchan@kernel.org Signed-off-by: Minchan Kim Cc: Sergey Senozhatsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7bee1c58a629e584252cb40de6e636cc92e4bc79 Author: Takashi Iwai Date: Sun Apr 9 10:41:27 2017 +0200 ALSA: seq: Don't break snd_use_lock_sync() loop by timeout [ Upstream commit 4e7655fd4f47c23e5249ea260dc802f909a64611 ] The snd_use_lock_sync() (thus its implementation snd_use_lock_sync_helper()) has the 5 seconds timeout to break out of the sync loop. It was introduced from the beginning, just to be "safer", in terms of avoiding the stupid bugs. However, as Ben Hutchings suggested, this timeout rather introduces a potential leak or use-after-free that was apparently fixed by the commit 2d7d54002e39 ("ALSA: seq: Fix race during FIFO resize"): for example, snd_seq_fifo_event_in() -> snd_seq_event_dup() -> copy_from_user() could block for a long time, and snd_use_lock_sync() goes timeout and still leaves the cell at releasing the pool. For fixing such a problem, we remove the break by the timeout while still keeping the warning. Suggested-by: Ben Hutchings Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 93dfafeefbb6c7345dbc93052e76743d914b9d2e Author: James Hogan Date: Thu Mar 30 16:06:02 2017 +0100 MIPS: KGDB: Use kernel context for sleeping threads [ Upstream commit 162b270c664dca2e0944308e92f9fcc887151a72 ] KGDB is a kernel debug stub and it can't be used to debug userland as it can only safely access kernel memory. On MIPS however KGDB has always got the register state of sleeping processes from the userland register context at the beginning of the kernel stack. This is meaningless for kernel threads (which never enter userland), and for user threads it prevents the user seeing what it is doing while in the kernel: (gdb) info threads Id Target Id Frame ... 3 Thread 2 (kthreadd) 0x0000000000000000 in ?? () 2 Thread 1 (init) 0x000000007705c4b4 in ?? () 1 Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201 Get the register state instead from the (partial) kernel register context stored in the task's thread_struct for resume() to restore. All threads now correctly appear to be in context_switch(): (gdb) info threads Id Target Id Frame ... 3 Thread 2 (kthreadd) context_switch (rq=, cookie=..., next=, prev=0x0) at kernel/sched/core.c:2903 2 Thread 1 (init) context_switch (rq=, cookie=..., next=, prev=0x0) at kernel/sched/core.c:2903 1 Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201 Call clobbered registers which aren't saved and exception registers (BadVAddr & Cause) which can't be easily determined without stack unwinding are reported as 0. The PC is taken from the return address, such that the state presented matches that found immediately after returning from resume(). Fixes: 8854700115ec ("[MIPS] kgdb: add arch support for the kernel's kgdb core") Signed-off-by: James Hogan Cc: Jason Wessel Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/15829/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 22afb4fc42e427c93327f80aacadfe82f42a77d9 Author: David Woodhouse Date: Wed Apr 12 13:25:50 2017 +0100 PCI: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms [ Upstream commit 6bccc7f426abd640f08d8c75fb22f99483f201b4 ] In the PCI_MMAP_PROCFS case when the address being passed by the user is a 'user visible' resource address based on the bus window, and not the actual contents of the resource, that's what we need to be checking it against. Signed-off-by: David Woodhouse Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1ecc90c7e6b4359d4ea64bf237878bc96b380474 Author: James Cowgill Date: Tue Apr 11 13:51:07 2017 +0100 MIPS: Avoid BUG warning in arch_check_elf [ Upstream commit c46f59e90226fa5bfcc83650edebe84ae47d454b ] arch_check_elf contains a usage of current_cpu_data that will call smp_processor_id() with preemption enabled and therefore triggers a "BUG: using smp_processor_id() in preemptible" warning when an fpxx executable is loaded. As a follow-up to commit b244614a60ab ("MIPS: Avoid a BUG warning during prctl(PR_SET_FP_MODE, ...)"), apply the same fix to arch_check_elf by using raw_current_cpu_data instead. The rationale quoted from the previous commit: "It is assumed throughout the kernel that if any CPU has an FPU, then all CPUs would have an FPU as well, so it is safe to perform the check with preemption enabled - change the code to use raw_ variant of the check to avoid the warning." Fixes: 46490b572544 ("MIPS: kernel: elf: Improve the overall ABI and FPU mode checks") Signed-off-by: James Cowgill CC: # 4.0+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15951/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 396f0fe4cc1b4d34d453f97aafc693ad10067d55 Author: Christian Borntraeger Date: Sun Apr 9 22:09:38 2017 +0200 s390/mm: fix CMMA vs KSM vs others [ Upstream commit a8f60d1fadf7b8b54449fcc9d6b15248917478ba ] On heavy paging with KSM I see guest data corruption. Turns out that KSM will add pages to its tree, where the mapping return true for pte_unused (or might become as such later). KSM will unmap such pages and reinstantiate with different attributes (e.g. write protected or special, e.g. in replace_page or write_protect_page)). This uncovered a bug in our pagetable handling: We must remove the unused flag as soon as an entry becomes present again. Cc: stable@vger.kernel.org Signed-of-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit fab0b034bd9108c715e8a32a25b5a1678d02d729 Author: Johan Hovold Date: Mon Apr 10 11:21:39 2017 +0200 serial: omap: suspend device on probe errors [ Upstream commit 77e6fe7fd2b7cba0bf2f2dc8cde51d7b9a35bf74 ] Make sure to actually suspend the device before returning after a failed (or deferred) probe. Note that autosuspend must be disabled before runtime pm is disabled in order to balance the usage count due to a negative autosuspend delay as well as to make the final put suspend the device synchronously. Fixes: 388bc2622680 ("omap-serial: Fix the error handling in the omap_serial probe") Cc: Shubhrajyoti D Signed-off-by: Johan Hovold Acked-by: Tony Lindgren Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0ea0b8f3adbec78cc9836abbed7f3eae9440bb4e Author: Johan Hovold Date: Mon Apr 10 11:21:38 2017 +0200 serial: omap: fix runtime-pm handling on unbind [ Upstream commit 099bd73dc17ed77aa8c98323e043613b6e8f54fc ] An unbalanced and misplaced synchronous put was used to suspend the device on driver unbind, something which with a likewise misplaced pm_runtime_disable leads to external aborts when an open port is being removed. Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa024010 ... [] (serial_omap_set_mctrl) from [] (uart_update_mctrl+0x50/0x60) [] (uart_update_mctrl) from [] (uart_shutdown+0xbc/0x138) [] (uart_shutdown) from [] (uart_hangup+0x94/0x190) [] (uart_hangup) from [] (__tty_hangup+0x404/0x41c) [] (__tty_hangup) from [] (tty_vhangup+0x1c/0x20) [] (tty_vhangup) from [] (uart_remove_one_port+0xec/0x260) [] (uart_remove_one_port) from [] (serial_omap_remove+0x40/0x60) [] (serial_omap_remove) from [] (platform_drv_remove+0x34/0x4c) Fix this up by resuming the device before deregistering the port and by suspending and disabling runtime pm only after the port has been removed. Also make sure to disable autosuspend before disabling runtime pm so that the usage count is balanced and device actually suspended before returning. Note that due to a negative autosuspend delay being set in probe, the unbalanced put would actually suspend the device on first driver unbind, while rebinding and again unbinding would result in a negative power.usage_count. Fixes: 7e9c8e7dbf3b ("serial: omap: make sure to suspend device before remove") Cc: Felipe Balbi Cc: Santosh Shilimkar Signed-off-by: Johan Hovold Acked-by: Tony Lindgren Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 113cc52cf9fe30c9e6a8f85e09ae54ce67708594 Author: Germano Percossi Date: Fri Apr 7 12:29:38 2017 +0100 CIFS: store results of cifs_reopen_file to avoid infinite wait [ Upstream commit 1fa839b4986d648b907d117275869a0e46c324b9 ] This fixes Continuous Availability when errors during file reopen are encountered. cifs_user_readv and cifs_user_writev would wait for ever if results of cifs_reopen_file are not stored and for later inspection. In fact, results are checked and, in case of errors, a chain of function calls leading to reads and writes to be scheduled in a separate thread is skipped. These threads will wake up the corresponding waiters once reads and writes are done. However, given the return value is not stored, when rc is checked for errors a previous one (always zero) is inspected instead. This leads to pending reads/writes added to the list, making cifs_user_readv and cifs_user_writev wait for ever. Signed-off-by: Germano Percossi Reviewed-by: Pavel Shilovsky CC: Stable Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 5c6d0e841556c6f0a3cfe5dac3195c92df8a5e72 Author: Germano Percossi Date: Fri Apr 7 12:29:37 2017 +0100 CIFS: remove bad_network_name flag [ Upstream commit a0918f1ce6a43ac980b42b300ec443c154970979 ] STATUS_BAD_NETWORK_NAME can be received during node failover, causing the flag to be set and making the reconnect thread always unsuccessful, thereafter. Once the only place where it is set is removed, the remaining bits are rendered moot. Removing it does not prevent "mount" from failing when a non existent share is passed. What happens when the share really ceases to exist while the share is mounted is undefined now as much as it was before. Signed-off-by: Germano Percossi Reviewed-by: Pavel Shilovsky CC: Stable Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 417dc40ebaf20ef121d8a01b956324b139f30c89 Author: Cameron Gutman Date: Mon Apr 10 20:44:25 2017 -0700 Input: xpad - add support for Razer Wildcat gamepad [ Upstream commit 5376366886251e2f8f248704adb620a4bc4c0937 ] Cc: stable@vger.kernel.org Signed-off-by: Cameron Gutman Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 3a5df486f2e133f1d575d84fbd68d7c8272e5c99 Author: Thomas Gleixner Date: Mon Apr 10 17:14:28 2017 +0200 x86/vdso: Plug race between mapping and ELF header setup [ Upstream commit 6fdc6dd90272ce7e75d744f71535cfbd8d77da81 ] The vsyscall32 sysctl can racy against a concurrent fork when it switches from disabled to enabled: arch_setup_additional_pages() if (vdso32_enabled) --> No mapping sysctl.vsysscall32() --> vdso32_enabled = true create_elf_tables() ARCH_DLINFO_IA32 if (vdso32_enabled) { --> Add VDSO entry with NULL pointer Make ARCH_DLINFO_IA32 check whether the VDSO mapping has been set up for the newly forked process or not. Signed-off-by: Thomas Gleixner Acked-by: Andy Lutomirski Cc: Peter Zijlstra Cc: Mathias Krause Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20170410151723.602367196@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 7ec71e0bb16dd4a00bb0ded83a126ca2890433d8 Author: Dennis Yang Date: Wed Mar 29 15:46:13 2017 +0800 md: update slab_cache before releasing new stripes when stripes resizing [ Upstream commit 583da48e388f472e8818d9bb60ef6a1d40ee9f9d ] When growing raid5 device on machine with small memory, there is chance that mdadm will be killed and the following bug report can be observed. The same bug could also be reproduced in linux-4.10.6. [57600.075774] BUG: unable to handle kernel NULL pointer dereference at (null) [57600.083796] IP: [] _raw_spin_lock+0x7/0x20 [57600.110378] PGD 421cf067 PUD 4442d067 PMD 0 [57600.114678] Oops: 0002 [#1] SMP [57600.180799] CPU: 1 PID: 25990 Comm: mdadm Tainted: P O 4.2.8 #1 [57600.187849] Hardware name: To be filled by O.E.M. To be filled by O.E.M./MAHOBAY, BIOS QV05AR66 03/06/2013 [57600.197490] task: ffff880044e47240 ti: ffff880043070000 task.ti: ffff880043070000 [57600.204963] RIP: 0010:[] [] _raw_spin_lock+0x7/0x20 [57600.213057] RSP: 0018:ffff880043073810 EFLAGS: 00010046 [57600.218359] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffff88011e296dd0 [57600.225486] RDX: 0000000000000001 RSI: ffffe8ffffcb46c0 RDI: 0000000000000000 [57600.232613] RBP: ffff880043073878 R08: ffff88011e5f8170 R09: 0000000000000282 [57600.239739] R10: 0000000000000005 R11: 28f5c28f5c28f5c3 R12: ffff880043073838 [57600.246872] R13: ffffe8ffffcb46c0 R14: 0000000000000000 R15: ffff8800b9706a00 [57600.253999] FS: 00007f576106c700(0000) GS:ffff88011e280000(0000) knlGS:0000000000000000 [57600.262078] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [57600.267817] CR2: 0000000000000000 CR3: 00000000428fe000 CR4: 00000000001406e0 [57600.274942] Stack: [57600.276949] ffffffff8114ee35 ffff880043073868 0000000000000282 000000000000eb3f [57600.284383] ffffffff81119043 ffff880043073838 ffff880043073838 ffff88003e197b98 [57600.291820] ffffe8ffffcb46c0 ffff88003e197360 0000000000000286 ffff880043073968 [57600.299254] Call Trace: [57600.301698] [] ? cache_flusharray+0x35/0xe0 [57600.307523] [] ? __page_cache_release+0x23/0x110 [57600.313779] [] kmem_cache_free+0x63/0xc0 [57600.319344] [] drop_one_stripe+0x62/0x90 [57600.324915] [] raid5_cache_scan+0x8b/0xb0 [57600.330563] [] shrink_slab.part.36+0x19a/0x250 [57600.336650] [] shrink_zone+0x23c/0x250 [57600.342039] [] do_try_to_free_pages+0x153/0x420 [57600.348210] [] try_to_free_pages+0x91/0xa0 [57600.353959] [] __alloc_pages_nodemask+0x4d1/0x8b0 [57600.360303] [] check_reshape+0x62b/0x770 [57600.365866] [] raid5_check_reshape+0x55/0xa0 [57600.371778] [] update_raid_disks+0xc7/0x110 [57600.377604] [] md_ioctl+0xd83/0x1b10 [57600.382827] [] blkdev_ioctl+0x170/0x690 [57600.388307] [] block_ioctl+0x38/0x40 [57600.393525] [] do_vfs_ioctl+0x2b5/0x480 [57600.399010] [] ? vfs_write+0x14b/0x1f0 [57600.404400] [] SyS_ioctl+0x3c/0x70 [57600.409447] [] entry_SYSCALL_64_fastpath+0x12/0x6a [57600.415875] Code: 00 00 00 00 55 48 89 e5 8b 07 85 c0 74 04 31 c0 5d c3 ba 01 00 00 00 f0 0f b1 17 85 c0 75 ef b0 01 5d c3 90 31 c0 ba 01 00 00 00 0f b1 17 85 c0 75 01 c3 55 89 c6 48 89 e5 e8 85 d1 63 ff 5d [57600.435460] RIP [] _raw_spin_lock+0x7/0x20 [57600.441208] RSP [57600.444690] CR2: 0000000000000000 [57600.448000] ---[ end trace cbc6b5cc4bf9831d ]--- The problem is that resize_stripes() releases new stripe_heads before assigning new slab cache to conf->slab_cache. If the shrinker function raid5_cache_scan() gets called after resize_stripes() starting releasing new stripes but right before new slab cache being assigned, it is possible that these new stripe_heads will be freed with the old slab_cache which was already been destoryed and that triggers this bug. Signed-off-by: Dennis Yang Fixes: edbe83ab4c27 ("md/raid5: allow the stripe_cache to grow and shrink.") Cc: stable@vger.kernel.org (4.1+) Reviewed-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin commit 2da764d4c67b4810741bc3aa5a64bf87c2427e9b Author: Jason A. Donenfeld Date: Fri Apr 7 02:33:30 2017 +0200 padata: free correct variable [ Upstream commit 07a77929ba672d93642a56dc2255dd21e6e2290b ] The author meant to free the variable that was just allocated, instead of the one that failed to be allocated, but made a simple typo. This patch rectifies that. Signed-off-by: Jason A. Donenfeld Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ce0e21e44f9766aeef6a8c18a750ef9d94c1ca8c Author: Herbert Xu Date: Mon Apr 10 17:27:57 2017 +0800 crypto: ahash - Fix EINPROGRESS notification callback [ Upstream commit ef0579b64e93188710d48667cb5e014926af9f1b ] The ahash API modifies the request's callback function in order to clean up after itself in some corner cases (unaligned final and missing finup). When the request is complete ahash will restore the original callback and everything is fine. However, when the request gets an EBUSY on a full queue, an EINPROGRESS callback is made while the request is still ongoing. In this case the ahash API will incorrectly call its own callback. This patch fixes the problem by creating a temporary request object on the stack which is used to relay EINPROGRESS back to the original completion function. This patch also adds code to preserve the original flags value. Fixes: ab6bf4e5e5e4 ("crypto: hash - Fix the pointer voodoo in...") Cc: Reported-by: Sabrina Dubroca Tested-by: Sabrina Dubroca Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4ee5f3baad194e4850c80f31af72406a5faa5639 Author: Johan Hovold Date: Mon Mar 13 09:53:58 2017 -0300 [media] cx231xx-audio: fix NULL-deref at probe [ Upstream commit 65f921647f4c89a2068478c89691f39b309b58f7 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver") Cc: stable # 2.6.30 Cc: Sri Deevi Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8b6c66045c336a22fe5593046099e4ca3f2501ad Author: Johan Hovold Date: Mon Mar 13 09:53:57 2017 -0300 [media] cx231xx-audio: fix init error path [ Upstream commit fff1abc4d54e469140a699612b4db8d6397bfcba ] Make sure to release the snd_card also on a late allocation error. Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver") Cc: stable # 2.6.30 Cc: Sri Deevi Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5a4e9221b31bc62710b8eb3d46326f3be7eaaf5f Author: Johan Hovold Date: Mon Mar 13 09:53:56 2017 -0300 [media] cx231xx-cards: fix NULL-deref at probe [ Upstream commit 0cd273bb5e4d1828efaaa8dfd11b7928131ed149 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver") Cc: stable # 2.6.30 Cc: Sri Deevi Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a44bcf6b4c54f8aff0680204629f613f263aef6a Author: Johan Hovold Date: Mon Mar 13 09:53:55 2017 -0300 [media] usbvision: fix NULL-deref at probe [ Upstream commit eacb975b48272f54532b62f515a3cf7eefa35123 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: 2a9f8b5d25be ("V4L/DVB (5206): Usbvision: set alternate interface modification") Cc: stable # 2.6.21 Cc: Thierry MERLE Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c7bcf82e59eae7de75deab19a931e8e9ce182353 Author: Johan Hovold Date: Mon Mar 13 09:53:54 2017 -0300 [media] dib0700: fix NULL-deref at probe [ Upstream commit d5823511c0f8719a39e72ede1bce65411ac653b7 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: c4018fa2e4c0 ("[media] dib0700: fix RC support on Hauppauge Nova-TD") Cc: stable # 3.16 Cc: Mauro Carvalho Chehab Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 27a0c2317453b184705e6cbd2a97339587b015aa Author: Marek Szyprowski Date: Mon Apr 3 08:20:59 2017 +0200 serial: samsung: Use right device for DMA-mapping calls [ Upstream commit 768d64f491a530062ddad50e016fb27125f8bd7c ] Driver should provide its own struct device for all DMA-mapping calls instead of extracting device pointer from DMA engine channel. Although this is harmless from the driver operation perspective on ARM architecture, it is always good to use the DMA mapping API in a proper way. This patch fixes following DMA API debug warning: WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1241 check_sync+0x520/0x9f4 samsung-uart 12c20000.serial: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000006df0f580] [size=64 bytes] Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00137-g07ca963 #51 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [] (show_stack) from [] (dump_stack+0x84/0xa0) [] (dump_stack) from [] (__warn+0x14c/0x180) [] (__warn) from [] (warn_slowpath_fmt+0x48/0x50) [] (warn_slowpath_fmt) from [] (check_sync+0x520/0x9f4) [] (check_sync) from [] (debug_dma_sync_single_for_device+0x88/0xc8) [] (debug_dma_sync_single_for_device) from [] (s3c24xx_serial_start_tx_dma+0x100/0x2f8) [] (s3c24xx_serial_start_tx_dma) from [] (s3c24xx_serial_tx_chars+0x198/0x33c) Reported-by: Seung-Woo Kim Fixes: 62c37eedb74c8 ("serial: samsung: add dma reqest/release functions") CC: stable@vger.kernel.org # v4.0+ Signed-off-by: Marek Szyprowski Reviewed-by: Bartlomiej Zolnierkiewicz Reviewed-by: Krzysztof Kozlowski Reviewed-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5eb0c97fc8354d87dcc94999738327ddc64ae233 Author: NeilBrown Date: Mon Apr 3 11:30:34 2017 +1000 sysfs: be careful of error returns from ops->show() [ Upstream commit c8a139d001a1aab1ea8734db14b22dac9dd143b6 ] ops->show() can return a negative error code. Commit 65da3484d9be ("sysfs: correctly handle short reads on PREALLOC attrs.") (in v4.4) caused this to be stored in an unsigned 'size_t' variable, so errors would look like large numbers. As a result, if an error is returned, sysfs_kf_read() will return the value of 'count', typically 4096. Commit 17d0774f8068 ("sysfs: correctly handle read offset on PREALLOC attrs") (in v4.8) extended this error to use the unsigned large 'len' as a size for memmove(). Consequently, if ->show returns an error, then the first read() on the sysfs file will return 4096 and could return uninitialized memory to user-space. If the application performs a subsequent read, this will trigger a memmove() with extremely large count, and is likely to crash the machine is bizarre ways. This bug can currently only be triggered by reading from an md sysfs attribute declared with __ATTR_PREALLOC() during the brief period between when mddev_put() deletes an mddev from the ->all_mddevs list, and when mddev_delayed_delete() - which is scheduled on a workqueue - completes. Before this, an error won't be returned by the ->show() After this, the ->show() won't be called. I can reproduce it reliably only by putting delay like usleep_range(500000,700000); early in mddev_delayed_delete(). Then after creating an md device md0 run echo clear > /sys/block/md0/md/array_state; cat /sys/block/md0/md/array_state The bug can be triggered without the usleep. Fixes: 65da3484d9be ("sysfs: correctly handle short reads on PREALLOC attrs.") Fixes: 17d0774f8068 ("sysfs: correctly handle read offset on PREALLOC attrs") Cc: stable@vger.kernel.org Signed-off-by: NeilBrown Acked-by: Tejun Heo Reported-and-tested-by: Miroslav Benes Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dad2a28d46e7568849778dbc838545c0daf70df5 Author: Shuxiao Zhang Date: Thu Apr 6 22:30:29 2017 +0800 staging: android: ashmem: lseek failed due to no FMODE_LSEEK. [ Upstream commit 97fbfef6bd597888485b653175fb846c6998b60c ] vfs_llseek will check whether the file mode has FMODE_LSEEK, no return failure. But ashmem can be lseek, so add FMODE_LSEEK to ashmem file. Comment From Greg Hackmann: ashmem_llseek() passes the llseek() call through to the backing shmem file. 91360b02ab48 ("ashmem: use vfs_llseek()") changed this from directly calling the file's llseek() op into a VFS layer call. This also adds a check for the FMODE_LSEEK bit, so without that bit ashmem_llseek() now always fails with -ESPIPE. Fixes: 91360b02ab48 ("ashmem: use vfs_llseek()") Signed-off-by: Shuxiao Zhang Tested-by: Greg Hackmann Cc: stable # 3.18+ Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4ac302f8832f476ed75b10ff2628d87a78e0e575 Author: Gustavo A. R. Silva Date: Mon Apr 3 22:48:40 2017 -0500 usb: misc: add missing continue in switch [ Upstream commit 2c930e3d0aed1505e86e0928d323df5027817740 ] Add missing continue in switch. Addresses-Coverity-ID: 1248733 Signed-off-by: Gustavo A. R. Silva Acked-by: Alan Stern Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 34a2eb59fc130a2730765049be26af88399421a7 Author: bsegall@google.com Date: Fri Apr 7 16:04:51 2017 -0700 ptrace: fix PTRACE_LISTEN race corrupting task->state [ Upstream commit 5402e97af667e35e54177af8f6575518bf251d51 ] In PT_SEIZED + LISTEN mode STOP/CONT signals cause a wakeup against __TASK_TRACED. If this races with the ptrace_unfreeze_traced at the end of a PTRACE_LISTEN, this can wake the task /after/ the check against __TASK_TRACED, but before the reset of state to TASK_TRACED. This causes it to instead clobber TASK_WAKING, allowing a subsequent wakeup against TRACED while the task is still on the rq wake_list, corrupting it. Oleg said: "The kernel can crash or this can lead to other hard-to-debug problems. In short, "task->state = TASK_TRACED" in ptrace_unfreeze_traced() assumes that nobody else can wake it up, but PTRACE_LISTEN breaks the contract. Obviusly it is very wrong to manipulate task->state if this task is already running, or WAKING, or it sleeps again" [akpm@linux-foundation.org: coding-style fixes] Fixes: 9899d11f ("ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL") Link: http://lkml.kernel.org/r/xm26y3vfhmkp.fsf_-_@bsegall-linux.mtv.corp.google.com Signed-off-by: Ben Segall Acked-by: Oleg Nesterov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8624aeaec37d4e3e0e6c2a987619461402f83a56 Author: Martin K. Petersen Date: Tue Apr 4 10:42:30 2017 -0400 scsi: sd: Fix capacity calculation with 32-bit sector_t [ Upstream commit 7c856152cb92f8eee2df29ef325a1b1f43161aff ] We previously made sure that the reported disk capacity was less than 0xffffffff blocks when the kernel was not compiled with large sector_t support (CONFIG_LBDAF). However, this check assumed that the capacity was reported in units of 512 bytes. Add a sanity check function to ensure that we only enable disks if the entire reported capacity can be expressed in terms of sector_t. Cc: Reported-by: Steve Magnani Cc: Bart Van Assche Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9535300dd7e25ea1a47e16f30a71c6d4bf385bfa Author: Martin K. Petersen Date: Fri Mar 17 08:47:14 2017 -0400 scsi: sr: Sanity check returned mode data [ Upstream commit a00a7862513089f17209b732f230922f1942e0b9 ] Kefeng Wang discovered that old versions of the QEMU CD driver would return mangled mode data causing us to walk off the end of the buffer in an attempt to parse it. Sanity check the returned mode sense data. Cc: Reported-by: Kefeng Wang Tested-by: Kefeng Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 21ebc869930ae5d0c086d27dbe05be9fd7cf5e85 Author: Joeseph Chang Date: Mon Mar 27 20:22:09 2017 -0600 ipmi: Fix kernel panic at ipmi_ssif_thread() [ Upstream commit 6de65fcfdb51835789b245203d1bfc8d14cb1e06 ] msg_written_handler() may set ssif_info->multi_data to NULL when using ipmitool to write fru. Before setting ssif_info->multi_data to NULL, add new local pointer "data_to_send" and store correct i2c data pointer to it to fix NULL pointer kernel panic and incorrect ssif_info->multi_pos. Signed-off-by: Joeseph Chang Signed-off-by: Corey Minyard Cc: stable@vger.kernel.org # 3.19- Signed-off-by: Sasha Levin commit 82bfc1d9bc5d17034c0b78a51a3071623fd89293 Author: Juergen Gross Date: Fri Apr 7 17:28:23 2017 +0200 xen, fbfront: fix connecting to backend [ Upstream commit 9121b15b5628b38b4695282dc18c553440e0f79b ] Connecting to the backend isn't working reliably in xen-fbfront: in case XenbusStateInitWait of the backend has been missed the backend transition to XenbusStateConnected will trigger the connected state only without doing the actions required when the backend has connected. Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit 8dd5c1281e982d2b260ef5334339049c2d195c7f Author: Jan-Marek Glogowski Date: Mon Feb 20 12:25:58 2017 +0100 Reset TreeId to zero on SMB2 TREE_CONNECT [ Upstream commit 806a28efe9b78ffae5e2757e1ee924b8e50c08ab ] Currently the cifs module breaks the CIFS specs on reconnect as described in http://msdn.microsoft.com/en-us/library/cc246529.aspx: "TreeId (4 bytes): Uniquely identifies the tree connect for the command. This MUST be 0 for the SMB2 TREE_CONNECT Request." Signed-off-by: Jan-Marek Glogowski Reviewed-by: Aurelien Aptel Tested-by: Aurelien Aptel Signed-off-by: Steve French CC: Stable Signed-off-by: Sasha Levin commit 3707e32c8fccc709efbf5a806cb27cf02ed0e28f Author: Marek Szyprowski Date: Wed Mar 22 04:53:57 2017 -0300 [media] s5p-mfc: Fix unbalanced call to clock management [ Upstream commit a5cb00eb4223458250b55daf03ac7ea5f424d601 ] Clock should be turned off after calling s5p_mfc_init_hw() from the watchdog worker, like it is already done in the s5p_mfc_open() which also calls this function. Fixes: af93574678108 ("[media] MFC: Add MFC 5.1 V4L2 driver") Signed-off-by: Marek Szyprowski Cc: stable@vger.kernel.org # v3.7+ Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 01ea8f2396af499ca868b626da8cc3e5d383988c Author: Johan Hovold Date: Mon Mar 13 09:53:59 2017 -0300 [media] gspca: konica: add missing endpoint sanity check [ Upstream commit aa58fedb8c7b6cf2f05941d238495f9e2f29655c ] Make sure to check the number of endpoints to avoid accessing memory beyond the endpoint array should a device lack the expected endpoints. Note that, as far as I can tell, the gspca framework has already made sure there is at least one endpoint in the current alternate setting so there should be no risk for a NULL-pointer dereference here. Fixes: b517af722860 ("V4L/DVB: gspca_konica: New gspca subdriver for konica chipset using cams") Cc: stable # 2.6.37 Cc: Hans de Goede Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 206374212c2831f9913013477bfabd8d66aade8b Author: Shamir Rabinovitch Date: Wed Mar 29 06:21:59 2017 -0400 IB/IPoIB: ibX: failed to create mcg debug file [ Upstream commit 771a52584096c45e4565e8aabb596eece9d73d61 ] When udev renames the netdev devices, ipoib debugfs entries does not get renamed. As a result, if subsequent probe of ipoib device reuse the name then creating a debugfs entry for the new device would fail. Also, moved ipoib_create_debug_files and ipoib_delete_debug_files as part of ipoib event handling in order to avoid any race condition between these. Fixes: 1732b0ef3b3a ([IPoIB] add path record information in debugfs) Cc: stable@vger.kernel.org # 2.6.15+ Signed-off-by: Vijay Kumar Signed-off-by: Shamir Rabinovitch Reviewed-by: Mark Bloch Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit f585e26312b5afb2c9781322298016baa26f6c2d Author: James Hogan Date: Tue Apr 4 08:51:34 2017 +0100 metag/usercopy: Add missing fixups [ Upstream commit b884a190afcecdbef34ca508ea5ee88bb7c77861 ] The rapf copy loops in the Meta usercopy code is missing some extable entries for HTP cores with unaligned access checking enabled, where faults occur on the instruction immediately after the faulting access. Add the fixup labels and extable entries for these cases so that corner case user copy failures don't cause kernel crashes. Fixes: 373cd784d0fc ("metag: Memory handling") Signed-off-by: James Hogan Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c31ac9be1dc218e4a5a4c683046fb5df13a39926 Author: James Hogan Date: Mon Apr 3 17:41:40 2017 +0100 metag/usercopy: Fix src fixup in from user rapf loops [ Upstream commit 2c0b1df88b987a12d95ea1d6beaf01894f3cc725 ] The fixup code to rewind the source pointer in __asm_copy_from_user_{32,64}bit_rapf_loop() always rewound the source by a single unit (4 or 8 bytes), however this is insufficient if the fault didn't occur on the first load in the loop, as the source pointer will have been incremented but nothing will have been stored until all 4 register [pairs] are loaded. Read the LSM_STEP field of TXSTATUS (which is already loaded into a register), a bit like the copy_to_user versions, to determine how many iterations of MGET[DL] have taken place, all of which need rewinding. Fixes: 373cd784d0fc ("metag: Memory handling") Signed-off-by: James Hogan Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 09e3cca03b298c809aff6610664a7987ee152deb Author: James Hogan Date: Tue Apr 4 11:43:26 2017 +0100 metag/usercopy: Set flags before ADDZ [ Upstream commit fd40eee1290ad7add7aa665e3ce6b0f9fe9734b4 ] The fixup code for the copy_to_user rapf loops reads TXStatus.LSM_STEP to decide how far to rewind the source pointer. There is a special case for the last execution of an MGETL/MGETD, since it leaves LSM_STEP=0 even though the number of MGETLs/MGETDs attempted was 4. This uses ADDZ which is conditional upon the Z condition flag, but the AND instruction which masked the TXStatus.LSM_STEP field didn't set the condition flags based on the result. Fix that now by using ANDS which does set the flags, and also marking the condition codes as clobbered by the inline assembly. Fixes: 373cd784d0fc ("metag: Memory handling") Signed-off-by: James Hogan Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7c3a804c24cc38ce029aad593e54c137166c0d18 Author: James Hogan Date: Fri Mar 31 11:14:02 2017 +0100 metag/usercopy: Zero rest of buffer from copy_from_user [ Upstream commit 563ddc1076109f2b3f88e6d355eab7b6fd4662cb ] Currently we try to zero the destination for a failed read from userland in fixup code in the usercopy.c macros. The rest of the destination buffer is then zeroed from __copy_user_zeroing(), which is used for both copy_from_user() and __copy_from_user(). Unfortunately we fail to zero in the fixup code as D1Ar1 is set to 0 before the fixup code entry labels, and __copy_from_user() shouldn't even be zeroing the rest of the buffer. Move the zeroing out into copy_from_user() and rename __copy_user_zeroing() to raw_copy_from_user() since it no longer does any zeroing. This also conveniently matches the name needed for RAW_COPY_USER support in a later patch. Fixes: 373cd784d0fc ("metag: Memory handling") Reported-by: Al Viro Signed-off-by: James Hogan Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit f58b27f0ce36a00a70be28bf734271a43c9a3ceb Author: James Hogan Date: Fri Mar 31 13:35:01 2017 +0100 metag/usercopy: Add early abort to copy_to_user [ Upstream commit fb8ea062a8f2e85256e13f55696c5c5f0dfdcc8b ] When copying to userland on Meta, if any faults are encountered immediately abort the copy instead of continuing on and repeatedly faulting, and worse potentially copying further bytes successfully to subsequent valid pages. Fixes: 373cd784d0fc ("metag: Memory handling") Reported-by: Al Viro Signed-off-by: James Hogan Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit fde1ed807fc632dbc029171648ddf7e906a62d7b Author: James Hogan Date: Fri Mar 31 11:23:18 2017 +0100 metag/usercopy: Fix alignment error checking [ Upstream commit 2257211942bbbf6c798ab70b487d7e62f7835a1a ] Fix the error checking of the alignment adjustment code in raw_copy_from_user(), which mistakenly considers it safe to skip the error check when aligning the source buffer on a 2 or 4 byte boundary. If the destination buffer was unaligned it may have started to copy using byte or word accesses, which could well be at the start of a new (valid) source page. This would result in it appearing to have copied 1 or 2 bytes at the end of the first (invalid) page rather than none at all. Fixes: 373cd784d0fc ("metag: Memory handling") Signed-off-by: James Hogan Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 59465f2b425d913d6cff86c429a8623b4eb6067d Author: James Hogan Date: Fri Mar 31 10:37:44 2017 +0100 metag/usercopy: Drop unused macros [ Upstream commit ef62a2d81f73d9cddef14bc3d9097a57010d551c ] Metag's lib/usercopy.c has a bunch of copy_from_user macros for larger copies between 5 and 16 bytes which are completely unused. Before fixing zeroing lets drop these macros so there is less to fix. Signed-off-by: James Hogan Cc: Al Viro Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 8da28861bfab88657c0d461591b73953b82b9655 Author: Wei Yongjun Date: Fri Jun 17 17:33:59 2016 +0000 ring-buffer: Fix return value check in test_ringbuffer() [ Upstream commit 62277de758b155dc04b78f195a1cb5208c37b2df ] In case of error, the function kthread_run() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Link: http://lkml.kernel.org/r/1466184839-14927-1-git-send-email-weiyj_lk@163.com Cc: stable@vger.kernel.org Fixes: 6c43e554a ("ring-buffer: Add ring buffer startup selftest") Signed-off-by: Wei Yongjun Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 4cc0a6f1461156e40ee8a8c3af956bfbc87693df Author: Horia Geantă Date: Wed Apr 5 11:41:03 2017 +0300 crypto: caam - fix RNG deinstantiation error checking [ Upstream commit 40c98cb57cdbc377456116ad4582c89e329721b0 ] RNG instantiation was previously fixed by commit 62743a4145bb9 ("crypto: caam - fix RNG init descriptor ret. code checking") while deinstantiation was not addressed. Since the descriptors used are similar, in the sense that they both end with a JUMP HALT command, checking for errors should be similar too, i.e. status code 7000_0000h should be considered successful. Cc: # 3.13+ Fixes: 1005bccd7a4a6 ("crypto: caam - enable instantiation of all RNG4 state handles") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c94b3a0d7a274dceddc932ebc880999ccbbdd481 Author: Frederic Barrat Date: Wed Mar 29 19:19:42 2017 +0200 powerpc/mm: Add missing global TLB invalidate if cxl is active [ Upstream commit 88b1bf7268f56887ca88eb09c6fb0f4fc970121a ] Commit 4c6d9acce1f4 ("powerpc/mm: Add hooks for cxl") converted local TLB invalidates to global if the cxl driver is active. This is necessary because the CAPP snoops invalidations to forward them to the PSL on the cxl adapter. However one path was forgotten. native_flush_hash_range() still does local TLB invalidates, as found out the hard way recently. This patch fixes it by following the same logic as previously: if the cxl driver is active, the local TLB invalidates are 'upgraded' to global. Fixes: 4c6d9acce1f4 ("powerpc/mm: Add hooks for cxl") Cc: stable@vger.kernel.org # v3.18+ Signed-off-by: Frederic Barrat Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit ca4f5edccb94cf80add41056929c65ec9f6011b3 Author: Johan Hovold Date: Mon Mar 13 13:44:20 2017 +0100 ath9k_htc: fix NULL-deref at probe [ Upstream commit ebeb36670ecac36c179b5fb5d5c88ff03ba191ec ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices") Cc: stable # 2.6.39+ Signed-off-by: Johan Hovold Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 783494a2cf45eb05a1ec611eab1c99dd58fa39cd Author: Paul Mackerras Date: Tue Apr 4 14:56:05 2017 +1000 powerpc: Don't try to fix up misaligned load-with-reservation instructions [ Upstream commit 48fe9e9488743eec9b7c1addd3c93f12f2123d54 ] In the past, there was only one load-with-reservation instruction, lwarx, and if a program attempted a lwarx on a misaligned address, it would take an alignment interrupt and the kernel handler would emulate it as though it was lwzx, which was not really correct, but benign since it is loading the right amount of data, and the lwarx should be paired with a stwcx. to the same address, which would also cause an alignment interrupt which would result in a SIGBUS being delivered to the process. We now have 5 different sizes of load-with-reservation instruction. Of those, lharx and ldarx cause an immediate SIGBUS by luck since their entries in aligninfo[] overlap instructions which were not fixed up, but lqarx overlaps with lhz and will be emulated as such. lbarx can never generate an alignment interrupt since it only operates on 1 byte. To straighten this out and fix the lqarx case, this adds code to detect the l[hwdq]arx instructions and return without fixing them up, resulting in a SIGBUS being delivered to the process. Cc: stable@vger.kernel.org Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit ea42f85ce0a63c1b026a67623e2135fab53171bb Author: Suzuki K Poulose Date: Mon Apr 3 15:12:43 2017 +0100 kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd [ Upstream commit 8b3405e345b5a098101b0c31b264c812bba045d9 ] In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling unmap_stage2_range() on the entire memory range for the guest. This could cause problems with other callers (e.g, munmap on a memslot) trying to unmap a range. And since we have to unmap the entire Guest memory range holding a spinlock, make sure we yield the lock if necessary, after we unmap each PUD range. Fixes: commit d5d8184d35c9 ("KVM: ARM: Memory virtualization setup") Cc: stable@vger.kernel.org # v3.10+ Cc: Paolo Bonzini Cc: Marc Zyngier Cc: Christoffer Dall Cc: Mark Rutland Signed-off-by: Suzuki K Poulose [ Avoid vCPU starvation and lockup detector warnings ] Signed-off-by: Marc Zyngier Signed-off-by: Suzuki K Poulose Signed-off-by: Christoffer Dall Signed-off-by: Sasha Levin commit 407526d5f5cc76590d670e1379af6f91f4008eef Author: Nayna Jain Date: Fri Mar 10 13:45:54 2017 -0500 tpm: add sleep only for retry in i2c_nuvoton_write_status() [ Upstream commit 0afb7118ae021e80ecf70f5a3336e0935505518a ] Currently, there is an unnecessary 1 msec delay added in i2c_nuvoton_write_status() for the successful case. This function is called multiple times during send() and recv(), which implies adding multiple extra delays for every TPM operation. This patch calls usleep_range() only if retry is to be done. Signed-off-by: Nayna Jain Cc: stable@vger.kernel.org (linux-4.8) Reviewed-by: Mimi Zohar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 779a96681b4ba5e87d2750fb10fc543165510515 Author: Jerry Snitselaar Date: Fri Mar 10 17:46:04 2017 -0700 tpm_crb: check for bad response size [ Upstream commit 8569defde8057258835c51ce01a33de82e14b148 ] Make sure size of response buffer is at least 6 bytes, or we will underflow and pass large size_t to memcpy_fromio(). This was encountered while testing earlier version of locality patchset. Cc: stable@vger.kernel.org Fixes: 30fc8d138e912 ("tpm: TPM 2.0 CRB Interface") Signed-off-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 331f718a97463b3c3957d62729704a3116c4297f Author: Nayna Jain Date: Fri Mar 10 13:45:53 2017 -0500 tpm: msleep() delays - replace with usleep_range() in i2c nuvoton driver [ Upstream commit a233a0289cf9a96ef9b42c730a7621ccbf9a6f98 ] Commit 500462a9de65 "timers: Switch to a non-cascading wheel" replaced the 'classic' timer wheel, which aimed for near 'exact' expiry of the timers. Their analysis was that the vast majority of timeout timers are used as safeguards, not as real timers, and are cancelled or rearmed before expiration. The only exception noted to this were networking timers with a small expiry time. Not included in the analysis was the TPM polling timer, which resulted in a longer normal delay and, every so often, a very long delay. The non-cascading wheel delay is based on CONFIG_HZ. For a description of the different rings and their delays, refer to the comments in kernel/time/timer.c. Below are the delays given for rings 0 - 2, which explains the longer "normal" delays and the very, long delays as seen on systems with CONFIG_HZ 250. * HZ 1000 steps * Level Offset Granularity Range * 0 0 1 ms 0 ms - 63 ms * 1 64 8 ms 64 ms - 511 ms * 2 128 64 ms 512 ms - 4095 ms (512ms - ~4s) * HZ 250 * Level Offset Granularity Range * 0 0 4 ms 0 ms - 255 ms * 1 64 32 ms 256 ms - 2047 ms (256ms - ~2s) * 2 128 256 ms 2048 ms - 16383 ms (~2s - ~16s) Below is a comparison of extending the TPM with 1000 measurements, using msleep() vs. usleep_delay() when configured for 1000 hz vs. 250 hz, before and after commit 500462a9de65. linux-4.7 | msleep() usleep_range() 1000 hz: 0m44.628s | 1m34.497s 29.243s 250 hz: 1m28.510s | 4m49.269s 32.386s linux-4.7 | min-max (msleep) min-max (usleep_range) 1000 hz: 0:017 - 2:760s | 0:015 - 3:967s 0:014 - 0:418s 250 hz: 0:028 - 1:954s | 0:040 - 4:096s 0:016 - 0:816s This patch replaces the msleep() with usleep_range() calls in the i2c nuvoton driver with a consistent max range value. Signed-of-by: Mimi Zohar Cc: stable@vger.kernel.org (linux-4.8) Signed-off-by: Nayna Jain Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit e43c2447f8edc5967c66e020094ecf278aeb7328 Author: Nicholas Bellinger Date: Sun Apr 2 13:36:44 2017 -0700 iscsi-target: Drop work-around for legacy GlobalSAN initiator [ Upstream commit 1c99de981f30b3e7868b8d20ce5479fa1c0fea46 ] Once upon a time back in 2009, a work-around was added to support the GlobalSAN iSCSI initiator v3.3 for MacOSX, which during login did not propose nor respond to MaxBurstLength, FirstBurstLength, DefaultTime2Wait and DefaultTime2Retain keys. The work-around in iscsi_check_proposer_for_optional_reply() allowed the missing keys to be proposed, but did not require waiting for a response before moving to full feature phase operation. This allowed GlobalSAN v3.3 to work out-of-the box, and for many years we didn't run into login interopt issues with any other initiators.. Until recently, when Martin tried a QLogic 57840S iSCSI Offload HBA on Windows 2016 which completed login, but subsequently failed with: Got unknown iSCSI OpCode: 0x43 The issue was QLogic MSFT side did not propose DefaultTime2Wait + DefaultTime2Retain, so LIO proposes them itself, and immediately transitions to full feature phase because of the GlobalSAN hack. However, the QLogic MSFT side still attempts to respond to DefaultTime2Retain + DefaultTime2Wait, even though LIO has set ISCSI_FLAG_LOGIN_NEXT_STAGE3 + ISCSI_FLAG_LOGIN_TRANSIT in last login response. So while the QLogic MSFT side should have been proposing these two keys to start, it was doing the correct thing per RFC-3720 attempting to respond to proposed keys before transitioning to full feature phase. All that said, recent versions of GlobalSAN iSCSI (v5.3.0.541) does correctly propose the four keys during login, making the original work-around moot. So in order to allow QLogic MSFT to run unmodified as-is, go ahead and drop this long standing work-around. Reported-by: Martin Svec Cc: Martin Svec Cc: Himanshu Madhani Cc: Arun Easi Cc: stable@vger.kernel.org # 3.1+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit d2762e9848bb6699ab9a8d735b5d25d9092ab208 Author: Tobias Herzog Date: Thu Mar 30 22:15:10 2017 +0200 cdc-acm: fix possible invalid access when processing notification [ Upstream commit 1bb9914e1730417d530de9ed37e59efdc647146b ] Notifications may only be 8 bytes long. Accessing the 9th and 10th byte of unimplemented/unknown notifications may be insecure. Also check the length of known notifications before accessing anything behind the 8th byte. Signed-off-by: Tobias Herzog Acked-by: Oliver Neukum Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4d8a7de65c82f166d9a5c3b31face645558f6f75 Author: Naoya Horiguchi Date: Fri Mar 31 15:11:55 2017 -0700 mm, hugetlb: use pte_present() instead of pmd_present() in follow_huge_pmd() [ Upstream commit c9d398fa237882ea07167e23bcfc5e6847066518 ] I found the race condition which triggers the following bug when move_pages() and soft offline are called on a single hugetlb page concurrently. Soft offlining page 0x119400 at 0x700000000000 BUG: unable to handle kernel paging request at ffffea0011943820 IP: follow_huge_pmd+0x143/0x190 PGD 7ffd2067 PUD 7ffd1067 PMD 0 [61163.582052] Oops: 0000 [#1] SMP Modules linked in: binfmt_misc ppdev virtio_balloon parport_pc pcspkr i2c_piix4 parport i2c_core acpi_cpufreq ip_tables xfs libcrc32c ata_generic pata_acpi virtio_blk 8139too crc32c_intel ata_piix serio_raw libata virtio_pci 8139cp virtio_ring virtio mii floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: cap_check] CPU: 0 PID: 22573 Comm: iterate_numa_mo Tainted: P OE 4.11.0-rc2-mm1+ #2 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:follow_huge_pmd+0x143/0x190 RSP: 0018:ffffc90004bdbcd0 EFLAGS: 00010202 RAX: 0000000465003e80 RBX: ffffea0004e34d30 RCX: 00003ffffffff000 RDX: 0000000011943800 RSI: 0000000000080001 RDI: 0000000465003e80 RBP: ffffc90004bdbd18 R08: 0000000000000000 R09: ffff880138d34000 R10: ffffea0004650000 R11: 0000000000c363b0 R12: ffffea0011943800 R13: ffff8801b8d34000 R14: ffffea0000000000 R15: 000077ff80000000 FS: 00007fc977710740(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffea0011943820 CR3: 000000007a746000 CR4: 00000000001406f0 Call Trace: follow_page_mask+0x270/0x550 SYSC_move_pages+0x4ea/0x8f0 SyS_move_pages+0xe/0x10 do_syscall_64+0x67/0x180 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7fc976e03949 RSP: 002b:00007ffe72221d88 EFLAGS: 00000246 ORIG_RAX: 0000000000000117 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc976e03949 RDX: 0000000000c22390 RSI: 0000000000001400 RDI: 0000000000005827 RBP: 00007ffe72221e00 R08: 0000000000c2c3a0 R09: 0000000000000004 R10: 0000000000c363b0 R11: 0000000000000246 R12: 0000000000400650 R13: 00007ffe72221ee0 R14: 0000000000000000 R15: 0000000000000000 Code: 81 e4 ff ff 1f 00 48 21 c2 49 c1 ec 0c 48 c1 ea 0c 4c 01 e2 49 bc 00 00 00 00 00 ea ff ff 48 c1 e2 06 49 01 d4 f6 45 bc 04 74 90 <49> 8b 7c 24 20 40 f6 c7 01 75 2b 4c 89 e7 8b 47 1c 85 c0 7e 2a RIP: follow_huge_pmd+0x143/0x190 RSP: ffffc90004bdbcd0 CR2: ffffea0011943820 ---[ end trace e4f81353a2d23232 ]--- Kernel panic - not syncing: Fatal exception Kernel Offset: disabled This bug is triggered when pmd_present() returns true for non-present hugetlb, so fixing the present check in follow_huge_pmd() prevents it. Using pmd_present() to determine present/non-present for hugetlb is not correct, because pmd_present() checks multiple bits (not only _PAGE_PRESENT) for historical reason and it can misjudge hugetlb state. Fixes: e66f17ff7177 ("mm/hugetlb: take page table lock in follow_huge_pmd()") Link: http://lkml.kernel.org/r/1490149898-20231-1-git-send-email-n-horiguchi@ah.jp.nec.com Signed-off-by: Naoya Horiguchi Acked-by: Hillf Danton Cc: Hugh Dickins Cc: Michal Hocko Cc: "Kirill A. Shutemov" Cc: Mike Kravetz Cc: Christian Borntraeger Cc: Gerald Schaefer Cc: [4.0+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5c9eddc3db73523f607727111cd3948686f35da9 Author: Hui Wang Date: Fri Mar 31 10:31:40 2017 +0800 ALSA: hda - fix a problem for lineout on a Dell AIO machine [ Upstream commit 2f726aec19a9d2c63bec9a8a53a3910ffdcd09f8 ] On this Dell AIO machine, the lineout jack does not work. We found the pin 0x1a is assigned to lineout on this machine, and in the past, we applied ALC298_FIXUP_DELL1_MIC_NO_PRESENCE to fix the heaset-set mic problem for this machine, this fixup will redefine the pin 0x1a to headphone-mic, as a result the lineout doesn't work anymore. After consulting with Dell, they told us this machine doesn't support microphone via headset jack, so we add a new fixup which only defines the pin 0x18 as the headset-mic. [rearranged the fixup insertion position by tiwai in order to make the merge with other branches easier -- tiwai] Fixes: 59ec4b57bcae ("ALSA: hda - Fix headset mic detection problem for two dell machines") Cc: Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d91a91d8f6ba1c98e0822e40b7e4a266d9567813 Author: Li Qiang Date: Mon Mar 27 20:10:53 2017 -0700 drm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl() [ Upstream commit e7e11f99564222d82f0ce84bd521e57d78a6b678 ] In vmw_surface_define_ioctl(), the 'num_sizes' is the sum of the 'req->mip_levels' array. This array can be assigned any value from the user space. As both the 'num_sizes' and the array is uint32_t, it is easy to make 'num_sizes' overflow. The later 'mip_levels' is used as the loop count. This can lead an oob write. Add the check of 'req->mip_levels' to avoid this. Cc: Signed-off-by: Li Qiang Reviewed-by: Thomas Hellstrom Signed-off-by: Sasha Levin commit 6431059d9e0f2ebdd6645247e0134d2cb5d67b21 Author: Thomas Hellstrom Date: Mon Mar 27 13:06:05 2017 +0200 drm/vmwgfx: Remove getparam error message [ Upstream commit 53e16798b0864464c5444a204e1bb93ae246c429 ] The mesa winsys sometimes uses unimplemented parameter requests to check for features. Remove the error message to avoid bloating the kernel log. Cc: Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul Reviewed-by: Sinclair Yeh Signed-off-by: Sasha Levin commit b31c507e2c3b0394c35d8e80c781d65264b5fe87 Author: Murray McAllister Date: Mon Mar 27 11:15:12 2017 +0200 drm/vmwgfx: avoid calling vzalloc with a 0 size in vmw_get_cap_3d_ioctl() [ Upstream commit 63774069d9527a1aeaa4aa20e929ef5e8e9ecc38 ] In vmw_get_cap_3d_ioctl(), a user can supply 0 for a size that is used in vzalloc(). This eventually calls dump_stack() (in warn_alloc()), which can leak useful addresses to dmesg. Add check to avoid a size of 0. Cc: Signed-off-by: Murray McAllister Reviewed-by: Sinclair Yeh Signed-off-by: Sasha Levin commit 13b52a46a6778fe23e64a20499230738ed3d445b Author: Murray McAllister Date: Mon Mar 27 11:12:53 2017 +0200 drm/vmwgfx: NULL pointer dereference in vmw_surface_define_ioctl() [ Upstream commit 36274ab8c596f1240c606bb514da329add2a1bcd ] Before memory allocations vmw_surface_define_ioctl() checks the upper-bounds of a user-supplied size, but does not check if the supplied size is 0. Add check to avoid NULL pointer dereferences. Cc: Signed-off-by: Murray McAllister Reviewed-by: Sinclair Yeh Signed-off-by: Sasha Levin commit 55f1d24ac1ab964943a1f644ce278bcce082d9a7 Author: Thomas Hellstrom Date: Mon Mar 27 11:09:08 2017 +0200 drm/vmwgfx: Type-check lookups of fence objects [ Upstream commit f7652afa8eadb416b23eb57dec6f158529942041 ] A malicious caller could otherwise hand over handles to other objects causing all sorts of interesting problems. Testing done: Ran a Fedora 25 desktop using both Xorg and gnome-shell/Wayland. Cc: Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh Signed-off-by: Sasha Levin commit 18bcea4e8d2e3f625ff671202c1f09c5feb15519 Author: Nicholas Bellinger Date: Thu Mar 23 17:19:24 2017 -0700 iscsi-target: Fix TMR reference leak during session shutdown [ Upstream commit efb2ea770bb3b0f40007530bc8b0c22f36e1c5eb ] This patch fixes a iscsi-target specific TMR reference leak during session shutdown, that could occur when a TMR was quiesced before the hand-off back to iscsi-target code via transport_cmd_check_stop_to_fabric(). The reference leak happens because iscsit_free_cmd() was incorrectly skipping the final target_put_sess_cmd() for TMRs when transport_generic_free_cmd() returned zero because the se_cmd->cmd_kref did not reach zero, due to the missing se_cmd assignment in original code. The result was iscsi_cmd and it's associated se_cmd memory would be freed once se_sess->sess_cmd_map where released, but the associated se_tmr_req was leaked and remained part of se_device->dev_tmr_list. This bug would manfiest itself as kernel paging request OOPsen in core_tmr_lun_reset(), when a left-over se_tmr_req attempted to dereference it's se_cmd pointer that had already been released during normal session shutdown. To address this bug, go ahead and treat ISCSI_OP_SCSI_CMD and ISCSI_OP_SCSI_TMFUNC the same when there is an extra se_cmd->cmd_kref to drop in iscsit_free_cmd(), and use op_scsi to signal __iscsit_free_cmd() when the former needs to clear any further iscsi related I/O state. Reported-by: Rob Millner Cc: Rob Millner Reported-by: Chu Yuan Lin Cc: Chu Yuan Lin Tested-by: Chu Yuan Lin Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit bfa5d70414f2a2a0095b36b90b81387a819d4557 Author: Sebastian Siewior Date: Wed Feb 22 17:15:21 2017 +0100 ubi/upd: Always flush after prepared for an update [ Upstream commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 ] In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I managed to trigger and fix a similar bug. Now here is another version of which I assumed it wouldn't matter back then but it turns out UBI has a check for it and will error out like this: |ubi0 warning: validate_vid_hdr: inconsistent used_ebs |ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592 All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a powercut in the middle of the operation. ubi_start_update() sets the update-marker and puts all EBs on the erase list. After that userland can proceed to write new data while the old EB aren't erased completely. A powercut at this point is usually not that much of a tragedy. UBI won't give read access to the static volume because it has the update marker. It will most likely set the corrupted flag because it misses some EBs. So we are all good. Unless the size of the image that has been written differs from the old image in the magnitude of at least one EB. In that case UBI will find two different values for `used_ebs' and refuse to attach the image with the error message mentioned above. So in order not to get in the situation, the patch will ensure that we wait until everything is removed before it tries to write any data. The alternative would be to detect such a case and remove all EBs at the attached time after we processed the volume-table and see the update-marker set. The patch looks bigger and I doubt it is worth it since usually the write() will wait from time to time for a new EB since usually there not that many spare EB that can be used. Cc: stable@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit c127ce428b732d5e2ded9d22e068f4f2b2d8b0bb Author: Heiko Carstens Date: Mon Mar 27 09:48:04 2017 +0200 s390/uaccess: get_user() should zero on failure (again) [ Upstream commit d09c5373e8e4eaaa09233552cbf75dc4c4f21203 ] Commit fd2d2b191fe7 ("s390: get_user() should zero on failure") intended to fix s390's get_user() implementation which did not zero the target operand if the read from user space faulted. Unfortunately the patch has no effect: the corresponding inline assembly specifies that the operand is only written to ("=") and the previous value is discarded. Therefore the compiler is free to and actually does omit the zero initialization. To fix this simply change the contraint modifier to "+", so the compiler cannot omit the initialization anymore. Fixes: c9ca78415ac1 ("s390/uaccess: provide inline variants of get_user/put_user") Fixes: fd2d2b191fe7 ("s390: get_user() should zero on failure") Cc: stable@vger.kernel.org Cc: Al Viro Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 0d2f98e74d4fa3fb73cf4325063aba1eb9bd77a4 Author: Ajay Kaher Date: Tue Mar 28 08:09:32 2017 -0400 USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously [ Upstream commit 2f86a96be0ccb1302b7eee7855dbee5ce4dc5dfb ] There is race condition when two USB class drivers try to call init_usb_class at the same time and leads to crash. code path: probe->usb_register_dev->init_usb_class To solve this, mutex locking has been added in init_usb_class() and destroy_usb_class(). As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class() because usb_class can never be NULL there. Signed-off-by: Ajay Kaher Acked-by: Alan Stern Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6842ff6056ea46660eb40e19f345c21cc51a21e3 Author: Josh Poimboeuf Date: Thu Mar 16 08:56:28 2017 -0500 ACPI: Fix incompatibility with mcount-based function graph tracing [ Upstream commit 61b79e16c68d703dde58c25d3935d67210b7d71b ] Paul Menzel reported a warning: WARNING: CPU: 0 PID: 774 at /build/linux-ROBWaj/linux-4.9.13/kernel/trace/trace_functions_graph.c:233 ftrace_return_to_handler+0x1aa/0x1e0 Bad frame pointer: expected f6919d98, received f6919db0 from func acpi_pm_device_sleep_wake return to c43b6f9d The warning means that function graph tracing is broken for the acpi_pm_device_sleep_wake() function. That's because the ACPI Makefile unconditionally sets the '-Os' gcc flag to optimize for size. That's an issue because mcount-based function graph tracing is incompatible with '-Os' on x86, thanks to the following gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109 I have another patch pending which will ensure that mcount-based function graph tracing is never used with CONFIG_CC_OPTIMIZE_FOR_SIZE on x86. But this patch is needed in addition to that one because the ACPI Makefile overrides that config option for no apparent reason. It has had this flag since the beginning of git history, and there's no related comment, so I don't know why it's there. As far as I can tell, there's no reason for it to be there. The appropriate behavior is for it to honor CONFIG_CC_OPTIMIZE_FOR_{SIZE,PERFORMANCE} like the rest of the kernel. Reported-by: Paul Menzel Signed-off-by: Josh Poimboeuf Acked-by: Steven Rostedt (VMware) Signed-off-by: Rafael J. Wysocki Cc: All applicable Signed-off-by: Sasha Levin commit e5dcf4e37e91190211f41115b946e6eda85486c4 Author: Joerg Roedel Date: Wed Mar 22 18:33:25 2017 +0100 ACPI: Do not create a platform_device for IOAPIC/IOxAPIC [ Upstream commit 08f63d97749185fab942a3a47ed80f5bd89b8b7d ] No platform-device is required for IO(x)APICs, so don't even create them. [ rjw: This fixes a problem with leaking platform device objects after IOAPIC/IOxAPIC hot-removal events.] Signed-off-by: Joerg Roedel Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e2b3e7de14ba087b6981487bdc0d1dd05e042980 Author: Ladi Prosek Date: Thu Mar 23 08:04:18 2017 +0100 virtio_balloon: init 1st buffer in stats vq [ Upstream commit fc8653228c8588a120f6b5dad6983b7b61ff669e ] When init_vqs runs, virtio_balloon.stats is either uninitialized or contains stale values. The host updates its state with garbage data because it has no way of knowing that this is just a marker buffer used for signaling. This patch updates the stats before pushing the initial buffer. Alternative fixes: * Push an empty buffer in init_vqs. Not easily done with the current virtio implementation and violates the spec "Driver MUST supply the same subset of statistics in all buffers submitted to the statsq". * Push a buffer with invalid tags in init_vqs. Violates the same spec clause, plus "invalid tag" is not really defined. Note: the spec says: When using the legacy interface, the device SHOULD ignore all values in the first buffer in the statsq supplied by the driver after device initialization. Note: Historically, drivers supplied an uninitialized buffer in the first buffer. Unfortunately QEMU does not seem to implement the recommendation even for the legacy interface. Cc: stable@vger.kernel.org Signed-off-by: Ladi Prosek Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit a205b2e5a2a099c459f5f0a11210888a778b227d Author: Benjamin Herrenschmidt Date: Mon Mar 20 17:49:03 2017 +1100 powerpc: Disable HFSCR[TM] if TM is not supported [ Upstream commit 7ed23e1bae8bf7e37fd555066550a00b95a3a98b ] On Power8 & Power9 the early CPU inititialisation in __init_HFSCR() turns on HFSCR[TM] (Hypervisor Facility Status and Control Register [Transactional Memory]), but that doesn't take into account that TM might be disabled by CPU features, or disabled by the kernel being built with CONFIG_PPC_TRANSACTIONAL_MEM=n. So later in boot, when we have setup the CPU features, clear HSCR[TM] if the TM CPU feature has been disabled. We use CPU_FTR_TM_COMP to account for the CONFIG_PPC_TRANSACTIONAL_MEM=n case. Without this a KVM guest might try use TM, even if told not to, and cause an oops in the host kernel. Typically the oops is seen in __kvmppc_vcore_entry() and may or may not be fatal to the host, but is always bad news. In practice all shipping CPU revisions do support TM, and all host kernels we are aware of build with TM support enabled, so no one should actually be able to hit this in the wild. Fixes: 2a3563b023e5 ("powerpc: Setup in HFSCR for POWER8") Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Benjamin Herrenschmidt Tested-by: Sam Bobroff [mpe: Rewrite change log with input from Sam, add Fixes/stable] Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit f8889a244545af2787a4078110702fab42161703 Author: Michel Dänzer Date: Fri Mar 24 19:01:09 2017 +0900 drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags [ Upstream commit ce4b4f228e51219b0b79588caf73225b08b5b779 ] We were accidentally only overriding the first VRAM placement. For BOs with the RADEON_GEM_NO_CPU_ACCESS flag set, radeon_ttm_placement_from_domain creates a second VRAM placment with fpfn == 0. If VRAM is almost full, the first VRAM placement with fpfn > 0 may not work, but the second one with fpfn == 0 always will (the BO's current location trivially satisfies it). Because "moving" the BO to its current location puts it back on the LRU list, this results in an infinite loop. Fixes: 2a85aedd117c ("drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first") Reported-by: Zachary Michaels Reported-and-Tested-by: Julien Isorce Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 848f9459271027910531876e457132b131223e4f Author: Alan Stern Date: Fri Mar 24 13:38:28 2017 -0400 USB: fix linked-list corruption in rh_call_control() [ Upstream commit 1633682053a7ee8058e10c76722b9b28e97fb73f ] Using KASAN, Dmitry found a bug in the rh_call_control() routine: If buffer allocation fails, the routine returns immediately without unlinking its URB from the control endpoint, eventually leading to linked-list corruption. This patch fixes the problem by jumping to the end of the routine (where the URB is unlinked) when an allocation failure occurs. Signed-off-by: Alan Stern Reported-and-tested-by: Dmitry Vyukov CC: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3492352e1f34673708fa7409b4b1d97545aa2f1c Author: Takashi Iwai Date: Fri Mar 24 17:07:57 2017 +0100 ALSA: seq: Fix race during FIFO resize [ Upstream commit 2d7d54002e396c180db0c800c1046f0a3c471597 ] When a new event is queued while processing to resize the FIFO in snd_seq_fifo_clear(), it may lead to a use-after-free, as the old pool that is being queued gets removed. For avoiding this race, we need to close the pool to be deleted and sync its usage before actually deleting it. The issue was spotted by syzkaller. Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 55e9d9474816f3bac900e6fb67b5f80b1f0785aa Author: Johan Hovold Date: Tue Mar 7 15:14:13 2017 -0300 [media] mceusb: fix NULL-deref at probe [ Upstream commit 03eb2a557ed552e920a0942b774aaf931596eec1 ] Make sure to check for the required out endpoint to avoid dereferencing a NULL-pointer in mce_request_packet should a malicious device lack such an endpoint. Note that this path is hit during probe. Fixes: 66e89522aff7 ("V4L/DVB: IR: add mceusb IR receiver driver") Cc: stable # 2.6.36 Signed-off-by: Johan Hovold Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 91848cdb7ae7872bd102f87b888e0d1ed3e72dd8 Author: Ankur Arora Date: Tue Mar 21 15:43:38 2017 -0700 xen/acpi: upload PM state from init-domain to Xen [ Upstream commit 1914f0cd203c941bba72f9452c8290324f1ef3dc ] This was broken in commit cd979883b9ed ("xen/acpi-processor: fix enabling interrupts on syscore_resume"). do_suspend (from xen/manage.c) and thus xen_resume_notifier never get called on the initial-domain at resume (it is if running as guest.) The rationale for the breaking change was that upload_pm_data() potentially does blocking work in syscore_resume(). This patch addresses the original issue by scheduling upload_pm_data() to execute in workqueue context. Cc: Stanislaw Gruszka Cc: stable@vger.kernel.org Based-on-patch-by: Konrad Wilk Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Stanislaw Gruszka Signed-off-by: Ankur Arora Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 970a7a72b32d6d7105efb8385443cb337a63dec8 Author: Bjorn Andersson Date: Tue Mar 14 08:23:26 2017 -0700 pinctrl: qcom: Don't clear status bit on irq_unmask [ Upstream commit a6566710adaa4a7dd5e0d99820ff9c9c30ee5951 ] Clearing the status bit on irq_unmask will discard any pending interrupt that did arrive after the irq_ack, i.e. while the IRQ handler function was executing. Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver") Cc: stable@vger.kernel.org Cc: Stephen Boyd Reported-by: Timur Tabi Signed-off-by: Bjorn Andersson Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fbb9dd5123ded1a6e9a65edef81b927bf5c15b91 Author: Adrian Hunter Date: Mon Mar 20 19:50:29 2017 +0200 mmc: sdhci: Do not disable interrupts while waiting for clock [ Upstream commit e2ebfb2142acefecc2496e71360f50d25726040b ] Disabling interrupts for even a millisecond can cause problems for some devices. That can happen when sdhci changes clock frequency because it waits for the clock to become stable under a spin lock. The spin lock is not necessary here. Anything that is racing with changes to the I/O state is already broken. The mmc core already provides synchronization via "claiming" the host. Although the spin lock probably should be removed from the code paths that lead to this point, such a patch would touch too much code to be suitable for stable trees. Consequently, for this patch, just drop the spin lock while waiting. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Tested-by: Ludovic Desroches Signed-off-by: Sasha Levin commit a2f7beb42427f98a715f12743f5a15a7ca4d28c7 Author: Guenter Roeck Date: Mon Mar 20 14:30:50 2017 -0700 usb: hub: Do not attempt to autosuspend disconnected devices [ Upstream commit f5cccf49428447dfbc9edb7a04bb8fc316269781 ] While running a bind/unbind stress test with the dwc3 usb driver on rk3399, the following crash was observed. Unable to handle kernel NULL pointer dereference at virtual address 00000218 pgd = ffffffc00165f000 [00000218] *pgd=000000000174f003, *pud=000000000174f003, *pmd=0000000001750003, *pte=00e8000001751713 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507 Hardware name: Google Kevin (DT) Workqueue: pm pm_runtime_work task: ffffffc0ac540000 ti: ffffffc0af4d4000 task.ti: ffffffc0af4d4000 PC is at autosuspend_check+0x74/0x174 LR is at autosuspend_check+0x70/0x174 ... Call trace: [] autosuspend_check+0x74/0x174 [] usb_runtime_idle+0x20/0x40 [] __rpm_callback+0x48/0x7c [] rpm_idle+0x1e8/0x498 [] pm_runtime_work+0x88/0xcc [] process_one_work+0x390/0x6b8 [] worker_thread+0x480/0x610 [] kthread+0x164/0x178 [] ret_from_fork+0x10/0x40 Source: (gdb) l *0xffffffc00080dcc0 0xffffffc00080dcc0 is in autosuspend_check (drivers/usb/core/driver.c:1778). 1773 /* We don't need to check interfaces that are 1774 * disabled for runtime PM. Either they are unbound 1775 * or else their drivers don't support autosuspend 1776 * and so they are permanently active. 1777 */ 1778 if (intf->dev.power.disable_depth) 1779 continue; 1780 if (atomic_read(&intf->dev.power.usage_count) > 0) 1781 return -EBUSY; 1782 w |= intf->needs_remote_wakeup; Code analysis shows that intf is set to NULL in usb_disable_device() prior to setting actconfig to NULL. At the same time, usb_runtime_idle() does not lock the usb device, and neither does any of the functions in the traceback. This means that there is no protection against a race condition where usb_disable_device() is removing dev->actconfig->interface[] pointers while those are being accessed from autosuspend_check(). To solve the problem, synchronize and validate device state between autosuspend_check() and usb_disconnect(). Acked-by: Alan Stern Signed-off-by: Guenter Roeck Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 041fad219db7a88566571c2854072ef79d8798c8 Author: Roger Quadros Date: Wed Mar 8 16:05:43 2017 +0200 usb: gadget: f_uvc: Fix SuperSpeed companion descriptor's wBytesPerInterval [ Upstream commit 09424c50b7dff40cb30011c09114404a4656e023 ] The streaming_maxburst module parameter is 0 offset (0..15) so we must add 1 while using it for wBytesPerInterval calculation for the SuperSpeed companion descriptor. Without this host uvcvideo driver will always see the wrong wBytesPerInterval for SuperSpeed uvc gadget and may not find a suitable video interface endpoint. e.g. for streaming_maxburst = 0 case it will always fail as wBytePerInterval was evaluating to 0. Cc: stable@vger.kernel.org Reviewed-by: Laurent Pinchart Signed-off-by: Roger Quadros Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit d4cbbe1460c46bc8329be82e65f956e9b71a81c0 Author: Marcelo Henrique Cerri Date: Mon Mar 13 12:14:58 2017 -0300 s390/decompressor: fix initrd corruption caused by bss clear [ Upstream commit d82c0d12c92705ef468683c9b7a8298dd61ed191 ] Reorder the operations in decompress_kernel() to ensure initrd is moved to a safe location before the bss section is zeroed. During decompression bss can overlap with the initrd and this can corrupt the initrd contents depending on the size of the compressed kernel (which affects where the initrd is placed by the bootloader) and the size of the bss section of the decompressor. Also use the correct initrd size when checking for overlaps with parmblock. Fixes: 06c0dd72aea3 ([S390] fix boot failures with compressed kernels) Cc: stable@vger.kernel.org Reviewed-by: Joy Latten Reviewed-by: Vineetha HariPai Signed-off-by: Marcelo Henrique Cerri Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit f1c9472e3dce9161c316671913c58c1de86fafd9 Author: Takashi Iwai Date: Tue Mar 21 13:56:04 2017 +0100 ALSA: seq: Fix racy cell insertions during snd_seq_pool_done() [ Upstream commit c520ff3d03f0b5db7146d9beed6373ad5d2a5e0e ] When snd_seq_pool_done() is called, it marks the closing flag to refuse the further cell insertions. But snd_seq_pool_done() itself doesn't clear the cells but just waits until all cells are cleared by the caller side. That is, it's racy, and this leads to the endless stall as syzkaller spotted. This patch addresses the racy by splitting the setup of pool->closing flag out of snd_seq_pool_done(), and calling it properly before snd_seq_pool_done(). BugLink: http://lkml.kernel.org/r/CACT4Y+aqqy8bZA1fFieifNxR2fAfFQQABcBHj801+u5ePV0URw@mail.gmail.com Reported-and-tested-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d57b1afab5a8b2268f9e378df6c9f6550c8dc238 Author: John Garry Date: Thu Mar 16 23:07:28 2017 +0800 scsi: libsas: fix ata xfer length [ Upstream commit 9702c67c6066f583b629cf037d2056245bb7a8e6 ] The total ata xfer length may not be calculated properly, in that we do not use the proper method to get an sg element dma length. According to the code comment, sg_dma_len() should be used after dma_map_sg() is called. This issue was found by turning on the SMMUv3 in front of the hisi_sas controller in hip07. Multiple sg elements were being combined into a single element, but the original first element length was being use as the total xfer length. Cc: Fixes: ff2aeb1eb64c8a4770a6 ("libata: convert to chained sg") Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 972d4b4f2c7b918a6d476942d1a3e13eb57a0ab3 Author: Marc Zyngier Date: Thu Mar 16 18:20:50 2017 +0000 arm/arm64: KVM: Take mmap_sem in kvm_arch_prepare_memory_region [ Upstream commit 72f310481a08db821b614e7b5d00febcc9064b36 ] We don't hold the mmap_sem while searching for VMAs (via find_vma), in kvm_arch_prepare_memory_region, which can end up in expected failures. Fixes: commit 8eef91239e57 ("arm/arm64: KVM: map MMIO regions at creation time") Cc: Ard Biesheuvel Cc: Eric Auger Cc: stable@vger.kernel.org # v3.18+ Reviewed-by: Christoffer Dall [ Handle dirty page logging failure case ] Signed-off-by: Suzuki K Poulose Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 474d78d49b8bfb365b3795f1bcc8fe61c386f730 Author: Marc Zyngier Date: Thu Mar 16 18:20:49 2017 +0000 arm/arm64: KVM: Take mmap_sem in stage2_unmap_vm [ Upstream commit 90f6e150e44a0dc3883110eeb3ab35d1be42b6bb ] We don't hold the mmap_sem while searching for the VMAs when we try to unmap each memslot for a VM. Fix this properly to avoid unexpected results. Fixes: commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm") Cc: stable@vger.kernel.org # v3.19+ Reviewed-by: Christoffer Dall Signed-off-by: Suzuki K Poulose Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit d59cf3fa94db0755a3bab267182ad5d43883c829 Author: Bjørn Mork Date: Fri Mar 17 17:21:28 2017 +0100 USB: serial: qcserial: add Dell DW5811e [ Upstream commit 436ecf5519d892397af133a79ccd38a17c25fa51 ] This is a Dell branded Sierra Wireless EM7455. Cc: Signed-off-by: Bjørn Mork Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 6338e370099ac59ca7207999e8946af71d210918 Author: Andy Lutomirski Date: Thu Mar 16 12:59:39 2017 -0700 x86/perf: Fix CR4.PCE propagation to use active_mm instead of mm [ Upstream commit 5dc855d44c2ad960a86f593c60461f1ae1566b6d ] If one thread mmaps a perf event while another thread in the same mm is in some context where active_mm != mm (which can happen in the scheduler, for example), refresh_pce() would write the wrong value to CR4.PCE. This broke some PAPI tests. Reported-and-tested-by: Vince Weaver Signed-off-by: Andy Lutomirski Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: stable@vger.kernel.org Fixes: 7911d3f7af14 ("perf/x86: Only allow rdpmc if a perf_event is mapped") Link: http://lkml.kernel.org/r/0c5b38a76ea50e405f9abe07a13dfaef87c173a1.1489694270.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 1b9537d72610ff5b8ba5b053fc5891ce5649387b Author: Wang YanQing Date: Wed Feb 22 19:37:08 2017 +0800 tty: pty: Fix ldisc flush after userspace become aware of the data already [ Upstream commit 77dae6134440420bac334581a3ccee94cee1c054 ] While using emacs, cat or others' commands in konsole with recent kernels, I have met many times that CTRL-C freeze konsole. After konsole freeze I can't type anything, then I have to open a new one, it is very annoying. See bug report: https://bugs.kde.org/show_bug.cgi?id=175283 The platform in that bug report is Solaris, but now the pty in linux has the same problem or the same behavior as Solaris :) It has high possibility to trigger the problem follow steps below: Note: In my test, BigFile is a text file whose size is bigger than 1G 1:open konsole 1:cat BigFile 2:CTRL-C After some digging, I find out the reason is that commit 1d1d14da12e7 ("pty: Fix buffer flush deadlock") changes the behavior of pty_flush_buffer. Thread A Thread B -------- -------- 1:n_tty_poll return POLLIN 2:CTRL-C trigger pty_flush_buffer tty_buffer_flush n_tty_flush_buffer 3:attempt to check count of chars: ioctl(fd, TIOCINQ, &available) available is equal to 0 4:read(fd, buffer, avaiable) return 0 5:konsole close fd Yes, I know we could use the same patch included in the BUG report as a workaround for linux platform too. But I think the data in ldisc is belong to application of another side, we shouldn't clear it when we want to flush write buffer of this side in pty_flush_buffer. So I think it is better to disable ldisc flush in pty_flush_buffer, because its new hehavior bring no benefit except that it mess up the behavior between POLLIN, and TIOCINQ or FIONREAD. Also I find no flush_buffer function in others' tty driver has the same behavior as current pty_flush_buffer. Fixes: 1d1d14da12e7 ("pty: Fix buffer flush deadlock") CC: stable@vger.kernel.org # v4.0+ Signed-off-by: Wang YanQing Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 44705deddafeec80bc8d79fb9485558b48322d34 Author: Guenter Roeck Date: Wed Mar 8 10:19:36 2017 -0800 usb: hub: Fix crash after failure to read BOS descriptor [ Upstream commit 7b2db29fbb4e766fcd02207eb2e2087170bd6ebc ] If usb_get_bos_descriptor() returns an error, usb->bos will be NULL. Nevertheless, it is dereferenced unconditionally in hub_set_initial_usb2_lpm_policy() if usb2_hw_lpm_capable is set. This results in a crash. usb 5-1: unable to get BOS descriptor ... Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = ffffffc00165f000 [00000008] *pgd=000000000174f003, *pud=000000000174f003, *pmd=0000000001750003, *pte=00e8000001751713 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac [ ... ] CPU: 5 PID: 3353 Comm: kworker/5:3 Tainted: G B 4.4.52 #480 Hardware name: Google Kevin (DT) Workqueue: events driver_set_config_work task: ffffffc0c3690000 ti: ffffffc0ae9a8000 task.ti: ffffffc0ae9a8000 PC is at hub_port_init+0xc3c/0xd10 LR is at hub_port_init+0xc3c/0xd10 ... Call trace: [] hub_port_init+0xc3c/0xd10 [] usb_reset_and_verify_device+0x15c/0x82c [] usb_reset_device+0xe4/0x298 [] rtl8152_probe+0x84/0x9b0 [r8152] [] usb_probe_interface+0x244/0x2f8 [] driver_probe_device+0x180/0x3b4 [] __device_attach_driver+0xb4/0xe0 [] bus_for_each_drv+0xb4/0xe4 [] __device_attach+0xd0/0x158 [] device_initial_probe+0x24/0x30 [] bus_probe_device+0x50/0xe4 [] device_add+0x414/0x738 [] usb_set_configuration+0x89c/0x914 [] driver_set_config_work+0xc0/0xf0 [] process_one_work+0x390/0x6b8 [] worker_thread+0x480/0x610 [] kthread+0x164/0x178 [] ret_from_fork+0x10/0x40 Since we don't know anything about LPM capabilities without BOS descriptor, don't attempt to enable LPM if it is not available. Fixes: 890dae886721 ("xhci: Enable LPM support only for hardwired ...") Cc: stable Cc: Mathias Nyman Signed-off-by: Guenter Roeck Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 09b3048b2880b162d9d654ae9e54dde4f7f0350a Author: Oliver Neukum Date: Tue Mar 14 12:09:56 2017 +0100 ACM gadget: fix endianness in notifications [ Upstream commit cdd7928df0d2efaa3270d711963773a08a4cc8ab ] The gadget code exports the bitfield for serial status changes over the wire in its internal endianness. The fix is to convert to little endian before sending it over the wire. Signed-off-by: Oliver Neukum Tested-by: 家瑋 CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 861b5c18bb146f3845dc52f64e7bc997d6cf8db3 Author: peter chang Date: Wed Feb 15 14:11:54 2017 -0800 scsi: sg: check length passed to SG_NEXT_CMD_LEN [ Upstream commit bf33f87dd04c371ea33feb821b60d63d754e3124 ] The user can control the size of the next command passed along, but the value passed to the ioctl isn't checked against the usable max command size. Cc: Signed-off-by: Peter Chang Acked-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7268eabd5b5f39c64ec98f9526e776e34c7aca6b Author: Johan Hovold Date: Thu Mar 16 11:43:09 2017 -0700 Input: sur40 - validate number of endpoints before using them [ Upstream commit 92461f5d723037530c1f36cce93640770037812c ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory that lie beyond the end of the endpoint array should a malicious device lack the expected endpoints. Fixes: bdb5c57f209c ("Input: add sur40 driver for Samsung SUR40... ") Signed-off-by: Johan Hovold Cc: stable@vger.kernel.org # 3.13 Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 84a91ce021050bd60f41fed78f8ffa83712c4db1 Author: Johan Hovold Date: Thu Mar 16 11:41:55 2017 -0700 Input: kbtab - validate number of endpoints before using them [ Upstream commit cb1b494663e037253337623bf1ef2df727883cb7 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Signed-off-by: Johan Hovold Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit f1ba9cf0277683f9067f50244f676117702faf3e Author: Johan Hovold Date: Thu Mar 16 11:39:29 2017 -0700 Input: hanwang - validate number of endpoints before using them [ Upstream commit ba340d7b83703768ce566f53f857543359aa1b98 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: bba5394ad3bd ("Input: add support for Hanwang tablets") Signed-off-by: Johan Hovold Cc: stable@vger.kernel.org # 2.6.37 Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 36d425fcc1649915479341bc91fbe3650b316f37 Author: Johan Hovold Date: Thu Mar 16 11:37:01 2017 -0700 Input: yealink - validate number of endpoints before using them [ Upstream commit 5cc4a1a9f5c179795c8a1f2b0f4361829d6a070e ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: aca951a22a1d ("[PATCH] input-driver-yealink-P1K-usb-phone") Signed-off-by: Johan Hovold Cc: stable@vger.kernel.org # 2.6.14 Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 79cae616c9409429c0522e5b314e4368befa67d3 Author: Johan Hovold Date: Thu Mar 16 11:36:13 2017 -0700 Input: ims-pcu - validate number of endpoints before using them [ Upstream commit 1916d319271664241b7aa0cd2b05e32bdb310ce9 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack control-interface endpoints. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Signed-off-by: Johan Hovold Cc: stable@vger.kernel.org # 3.10 Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 6585effe7d220f2fef5c07a3c499584cc05ee275 Author: Johan Hovold Date: Thu Mar 16 11:35:12 2017 -0700 Input: cm109 - validate number of endpoints before using them [ Upstream commit ac2ee9ba953afe88f7a673e1c0c839227b1d7891 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: c04148f915e5 ("Input: add driver for USB VoIP phones with CM109...") Signed-off-by: Johan Hovold Cc: stable@vger.kernel.org # 2.6.28 Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 76d981017361e0937f2f2c83fe7b02b590e74bdd Author: Johan Hovold Date: Thu Mar 16 11:34:02 2017 -0700 Input: iforce - validate number of endpoints before using them [ Upstream commit 59cf8bed44a79ec42303151dd014fdb6434254bb ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory that lie beyond the end of the endpoint array should a malicious device lack the expected endpoints. Signed-off-by: Johan Hovold Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit edf3bd9562a949ea5799e79e49ca75cb52b10892 Author: Johan Hovold Date: Mon Mar 13 13:40:22 2017 +0100 mmc: ushc: fix NULL-deref at probe [ Upstream commit 181302dc7239add8ab1449c23ecab193f52ee6ab ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: 53f3a9e26ed5 ("mmc: USB SD Host Controller (USHC) driver") Cc: stable # 2.6.37 Cc: David Vrabel Signed-off-by: Johan Hovold Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 93d21fdc17e533bf04f4e1756a1910176dec70aa Author: Alex Deucher Date: Wed Mar 15 21:11:46 2017 -0400 drm/radeon: reinstate oland workaround for sclk [ Upstream commit 66822d815ae61ecb2d9dba9031517e8a8476969d ] Higher sclks seem to be unstable on some boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 71a1c9d004edeb08b52a7426655ade75538687f1 Author: Peter Zijlstra Date: Thu Mar 16 13:47:49 2017 +0100 perf/core: Fix event inheritance on fork() [ Upstream commit e7cc4865f0f31698ef2f7aac01a50e78968985b7 ] While hunting for clues to a use-after-free, Oleg spotted that perf_event_init_context() can loose an error value with the result that fork() can succeed even though we did not fully inherit the perf event context. Spotted-by: Oleg Nesterov Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Dmitry Vyukov Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Linus Torvalds Cc: Mathieu Desnoyers Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: oleg@redhat.com Cc: stable@vger.kernel.org Fixes: 889ff0150661 ("perf/core: Split context's event group list into pinned and non-pinned lists") Link: http://lkml.kernel.org/r/20170316125823.190342547@infradead.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 4da3251aac57e5f033860ed0bca711ea74851543 Author: Rafael J. Wysocki Date: Wed Mar 15 00:12:16 2017 +0100 cpufreq: Fix and clean up show_cpuinfo_cur_freq() [ Upstream commit 9b4f603e7a9f4282aec451063ffbbb8bb410dcd9 ] There is a missing newline in show_cpuinfo_cur_freq(), so add it, but while at it clean that function up somewhat too. Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar Cc: All applicable Signed-off-by: Sasha Levin commit 85fa60732c8003abad49f158538fd01f1963a2b0 Author: Alex Deucher Date: Tue Mar 14 14:42:03 2017 -0400 drm/radeon/si: add dpm quirk for Oland [ Upstream commit 0f424de1fd9bc4ab24bd1fe5430ab5618e803e31 ] OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems with higher sclks. Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 772653bea4031509112db9341473b20ee65eeb38 Author: Eric Biggers Date: Wed Mar 15 14:52:02 2017 -0400 ext4: mark inode dirty after converting inline directory [ Upstream commit b9cf625d6ecde0d372e23ae022feead72b4228a6 ] If ext4_convert_inline_data() was called on a directory with inline data, the filesystem was left in an inconsistent state (as considered by e2fsck) because the file size was not increased to cover the new block. This happened because the inode was not marked dirty after i_disksize was updated. Fix this by marking the inode dirty at the end of ext4_finish_convert_inline_dir(). This bug was probably not noticed before because most users mark the inode dirty afterwards for other reasons. But if userspace executed FS_IOC_SET_ENCRYPTION_POLICY with invalid parameters, as exercised by 'kvm-xfstests -c adv generic/396', then the inode was never marked dirty after updating i_disksize. Cc: stable@vger.kernel.org # 3.10+ Fixes: 3c47d54170b6a678875566b1b8d6dcf57904e49b Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e8959ed1fd07315de25a2fe59df5c777a14e2df3 Author: Peter Zijlstra Date: Sat Mar 4 10:27:19 2017 +0100 futex: Add missing error handling to FUTEX_REQUEUE_PI [ Upstream commit 9bbb25afeb182502ca4f2c4f3f88af0681b34cae ] Thomas spotted that fixup_pi_state_owner() can return errors and we fail to unlock the rt_mutex in that case. Reported-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Darren Hart Cc: juri.lelli@arm.com Cc: bigeasy@linutronix.de Cc: xlpang@redhat.com Cc: rostedt@goodmis.org Cc: mathieu.desnoyers@efficios.com Cc: jdesfossez@efficios.com Cc: dvhart@infradead.org Cc: bristot@redhat.com Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20170304093558.867401760@infradead.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 33fcd6ecaf0fc42ac1bc94270049b36b911c347b Author: Peter Zijlstra Date: Sat Mar 4 10:27:18 2017 +0100 futex: Fix potential use-after-free in FUTEX_REQUEUE_PI [ Upstream commit c236c8e95a3d395b0494e7108f0d41cf36ec107c ] While working on the futex code, I stumbled over this potential use-after-free scenario. Dmitry triggered it later with syzkaller. pi_mutex is a pointer into pi_state, which we drop the reference on in unqueue_me_pi(). So any access to that pointer after that is bad. Since other sites already do rt_mutex_unlock() with hb->lock held, see for example futex_lock_pi(), simply move the unlock before unqueue_me_pi(). Reported-by: Dmitry Vyukov Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Darren Hart Cc: juri.lelli@arm.com Cc: bigeasy@linutronix.de Cc: xlpang@redhat.com Cc: rostedt@goodmis.org Cc: mathieu.desnoyers@efficios.com Cc: jdesfossez@efficios.com Cc: dvhart@infradead.org Cc: bristot@redhat.com Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20170304093558.801744246@infradead.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 56d75a164c879c121601c0c3d47aa701ea0d80a2 Author: Nicolas Ferre Date: Tue Mar 14 09:38:04 2017 +0100 ARM: at91: pm: cpu_idle: switch DDR to power-down mode [ Upstream commit 60b89f1928af80b546b5c3fd8714a62f6f4b8844 ] On some DDR controllers, compatible with the sama5d3 one, the sequence to enter/exit/re-enter the self-refresh mode adds more constrains than what is currently written in the at91_idle driver. An actual access to the DDR chip is needed between exit and re-enter of this mode which is somehow difficult to implement. This sequence can completely hang the SoC. It is particularly experienced on parts which embed a L2 cache if the code run between IDLE calls fits in it... Moreover, as the intention is to enter and exit pretty rapidly from IDLE, the power-down mode is a good candidate. So now we use power-down instead of self-refresh. As we can simplify the code for sama5d3 compatible DDR controllers, we instantiate a new sama5d3_ddr_standby() function. Signed-off-by: Nicolas Ferre Cc: # v4.1+ Fixes: 017b5522d5e3 ("ARM: at91: Add new binding for sama5d3-ddramc") Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit ce6df3d36d07ded44170c335f7a7b2a7584495f2 Author: Bin Liu Date: Fri Mar 10 14:43:35 2017 -0600 usb: musb: cppi41: don't check early-TX-interrupt for Isoch transfer [ Upstream commit 0090114d336a9604aa2d90bc83f20f7cd121b76c ] The CPPI 4.1 driver polls register to workaround the premature TX interrupt issue, but it causes audio playback underrun when triggered in Isoch transfers. Isoch doesn't do back-to-back transfers, the TX should be done by the time the next transfer is scheduled. So skip this polling workaround for Isoch transfer. Fixes: a655f481d83d6 ("usb: musb: musb_cppi41: handle pre-mature TX complete interrupt") Cc: #4.1+ Reported-by: Alexandre Bailon Acked-by: Sebastian Andrzej Siewior Tested-by: Alexandre Bailon Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ed4b286d254bfd7dd777adb115c3a316eb7008ca Author: Samuel Thibault Date: Mon Mar 13 20:50:08 2017 +0100 usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk [ Upstream commit 3243367b209faed5c320a4e5f9a565ee2a2ba958 ] Some USB 2.0 devices erroneously report millisecond values in bInterval. The generic config code manages to catch most of them, but in some cases it's not completely enough. The case at stake here is a USB 2.0 braille device, which wants to announce 10ms and thus sets bInterval to 10, but with the USB 2.0 computation that yields to 64ms. It happens that one can type fast enough to reach this interval and get the device buffers overflown, leading to problematic latencies. The generic config code does not catch this case because the 64ms is considered a sane enough value. This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk to mark devices which actually report milliseconds in bInterval, and marks Vario Ultra devices as needing it. Signed-off-by: Samuel Thibault Acked-by: Alan Stern Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 599dc7743f7443a795268cba01f8987ced09116e Author: Johan Hovold Date: Mon Mar 13 13:47:53 2017 +0100 uwb: i1480-dfu: fix NULL-deref at probe [ Upstream commit 4ce362711d78a4999011add3115b8f4b0bc25e8c ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Note that the dereference happens in the cmd and wait_init_done callbacks which are called during probe. Fixes: 1ba47da52712 ("uwb: add the i1480 DFU driver") Cc: stable # 2.6.28 Cc: Inaky Perez-Gonzalez Cc: David Vrabel Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 50c372bd694dafc0f51db83617f21c2bd6f6970c Author: Johan Hovold Date: Mon Mar 13 13:47:52 2017 +0100 uwb: hwa-rc: fix NULL-deref at probe [ Upstream commit daf229b15907fbfdb6ee183aac8ca428cb57e361 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Note that the dereference happens in the start callback which is called during probe. Fixes: de520b8bd552 ("uwb: add HWA radio controller driver") Cc: stable # 2.6.28 Cc: Inaky Perez-Gonzalez Cc: David Vrabel Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7896de4f8b00c2c5079bf9315a058b3978cba392 Author: Johan Hovold Date: Mon Mar 13 13:47:51 2017 +0100 USB: wusbcore: fix NULL-deref at probe [ Upstream commit 03ace948a4eb89d1cf51c06afdfc41ebca5fdb27 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. This specifically fixes the NULL-pointer dereference when probing HWA HC devices. Fixes: df3654236e31 ("wusb: add the Wire Adapter (WA) core") Cc: stable # 2.6.28 Cc: Inaky Perez-Gonzalez Cc: David Vrabel Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0b37180176413589d032dc9b757978d982adc5a4 Author: Johan Hovold Date: Mon Mar 13 13:47:50 2017 +0100 USB: uss720: fix NULL-deref at probe [ Upstream commit f259ca3eed6e4b79ac3d5c5c9fb259fb46e86217 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Note that the endpoint access that causes the NULL-deref is currently only used for debugging purposes during probe so the oops only happens when dynamic debugging is enabled. This means the driver could be rewritten to continue to accept device with only two endpoints, should such devices exist. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aee563c5ffb52ce66a5984bbecec09ea9820fcfb Author: Johan Hovold Date: Mon Mar 13 13:47:49 2017 +0100 USB: lvtest: fix NULL-deref at probe [ Upstream commit 1dc56c52d2484be09c7398a5207d6b11a4256be9 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should the probed device lack endpoints. Note that this driver does not bind to any devices by default. Fixes: ce21bfe603b3 ("USB: Add LVS Test device driver") Cc: stable # 3.17 Cc: Pratyush Anand Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a2574cf7887d370596d7bc5dd93f96aae53d0a97 Author: Johan Hovold Date: Mon Mar 13 13:47:48 2017 +0100 USB: idmouse: fix NULL-deref at probe [ Upstream commit b0addd3fa6bcd119be9428996d5d4522479ab240 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 13cd0c011e73924b68f3c4c71c44f20b987a70ce Author: Johan Hovold Date: Mon Mar 13 13:39:01 2017 +0100 isdn/gigaset: fix NULL-deref at probe [ Upstream commit 68c32f9c2a36d410aa242e661506e5b2c2764179 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: cf7776dc05b8 ("[PATCH] isdn4linux: Siemens Gigaset drivers - direct USB connection") Cc: stable # 2.6.17 Cc: Hansjoerg Lipp Signed-off-by: Johan Hovold Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 027a48c195e158fb375ae01287401e562d2ab5b5 Author: OGAWA Hirofumi Date: Thu Mar 9 16:17:37 2017 -0800 fat: fix using uninitialized fields of fat_inode/fsinfo_inode [ Upstream commit c0d0e351285161a515396b7b1ee53ec9ffd97e3c ] Recently fallocate patch was merged and it uses MSDOS_I(inode)->mmu_private at fat_evict_inode(). However, fat_inode/fsinfo_inode that was introduced in past didn't initialize MSDOS_I(inode) properly. With those combinations, it became the cause of accessing random entry in FAT area. Link: http://lkml.kernel.org/r/87pohrj4i8.fsf@mail.parknet.co.jp Signed-off-by: OGAWA Hirofumi Reported-by: Moreno Bartalucci Tested-by: Moreno Bartalucci Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c4743e805d439f0ba691d3583272a24436299574 Author: Shaohua Li Date: Tue Feb 28 13:00:20 2017 -0800 md/raid1/10: fix potential deadlock [ Upstream commit 61eb2b43b99ebdc9bc6bc83d9792257b243e7cb3 ] Neil Brown pointed out a potential deadlock in raid 10 code with bio_split/chain. The raid1 code could have the same issue, but recent barrier rework makes it less likely to happen. The deadlock happens in below sequence: 1. generic_make_request(bio), this will set current->bio_list 2. raid10_make_request will split bio to bio1 and bio2 3. __make_request(bio1), wait_barrer, add underlayer disk bio to current->bio_list 4. __make_request(bio2), wait_barrer If raise_barrier happens between 3 & 4, since wait_barrier runs at 3, raise_barrier waits for IO completion from 3. And since raise_barrier sets barrier, 4 waits for raise_barrier. But IO from 3 can't be dispatched because raid10_make_request() doesn't finished yet. The solution is to adjust the IO ordering. Quotes from Neil: " It is much safer to: if (need to split) { split = bio_split(bio, ...) bio_chain(...) make_request_fn(split); generic_make_request(bio); } else make_request_fn(mddev, bio); This way we first process the initial section of the bio (in 'split') which will queue some requests to the underlying devices. These requests will be queued in generic_make_request. Then we queue the remainder of the bio, which will be added to the end of the generic_make_request queue. Then we return. generic_make_request() will pop the lower-level device requests off the queue and handle them first. Then it will process the remainder of the original bio once the first section has been fully processed. " Note, this only happens in read path. In write path, the bio is flushed to underlaying disks either by blk flush (from schedule) or offladed to raid1/10d. It's queued in current->bio_list. Cc: Coly Li Cc: stable@vger.kernel.org (v3.14+, only the raid10 part) Suggested-by: NeilBrown Reviewed-by: Jack Wang Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin commit 6eea126f9d6d903e56b8fa629e01e1e27dad9f0c Author: Guenter Roeck Date: Thu Mar 9 15:39:37 2017 +0200 usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers [ Upstream commit dcc7620cad5ad1326a78f4031a7bf4f0e5b42984 ] Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI xhci controllers which can result in excessive timeouts, to the point where the system reports a deadlock. The same problem is seen with hot pluggable xhci controllers using the xhci-plat driver, such as the driver used for Type-C ports on rk3399. Similar to hot-pluggable PCI controllers, the driver for this chip removes the xhci controller from the system when the Type-C cable is disconnected. The solution for PCI devices works just as well for non-PCI devices and avoids the problem. Signed-off-by: Guenter Roeck Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 92b280212adf5457134645088bf38ee70d917ba5 Author: Johan Hovold Date: Tue Mar 7 16:11:04 2017 +0100 USB: iowarrior: fix NULL-deref in write [ Upstream commit de46e56653de7b3b54baa625bd582635008b8d05 ] Make sure to verify that we have the required interrupt-out endpoint for IOWarrior56 devices to avoid dereferencing a NULL-pointer in write should a malicious device lack such an endpoint. Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Cc: stable # 2.6.21 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c4b51661231242b5b24431a31299c433934cad2e Author: Johan Hovold Date: Tue Mar 7 16:11:03 2017 +0100 USB: iowarrior: fix NULL-deref at probe [ Upstream commit b7321e81fc369abe353cf094d4f0dc2fe11ab95f ] Make sure to check for the required interrupt-in endpoint to avoid dereferencing a NULL-pointer should a malicious device lack such an endpoint. Note that a fairly recent change purported to fix this issue, but added an insufficient test on the number of endpoints only, a test which can now be removed. Fixes: 4ec0ef3a8212 ("USB: iowarrior: fix oops with malicious USB descriptors") Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Cc: stable # 2.6.21 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4db7a852b417d849c4a856450f988a2f6926f83d Author: Dmitry Tunin Date: Wed Mar 8 13:52:07 2017 +0200 ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device [ Upstream commit 16ff1fb0e32f76a5d285a6f23b82d21aa52813c6 ] T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=1eda ProdID=2315 Rev=01.08 S: Manufacturer=ATHEROS S: Product=USB2.0 WLAN S: SerialNumber=12345 C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Signed-off-by: Dmitry Tunin Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 394e5f4a60c17cb14e7b12ac214e7c555414e145 Author: Johan Hovold Date: Mon Mar 6 17:36:41 2017 +0100 USB: serial: safe_serial: fix information leak in completion handler [ Upstream commit 8c76d7cd520ebffc1ea9ea0850d87a224a50c7f2 ] Add missing sanity check to the bulk-in completion handler to avoid an integer underflow that could be triggered by a malicious device. This avoids leaking up to 56 bytes from after the URB transfer buffer to user space. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit e0f57e1a406c091646d7f474572975aab4c6d1de Author: Johan Hovold Date: Mon Mar 6 17:36:40 2017 +0100 USB: serial: io_ti: fix information leak in completion handler [ Upstream commit 654b404f2a222f918af9b0cd18ad469d0c941a8e ] Add missing sanity check to the bulk-in completion handler to avoid an integer underflow that can be triggered by a malicious device. This avoids leaking 128 kB of memory content from after the URB transfer buffer to user space. Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable # 2.6.30 Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 5dfb04937689e5f797506ee73f028f919cc9278d Author: Johan Hovold Date: Mon Mar 6 17:36:38 2017 +0100 USB: serial: omninet: fix reference leaks at open [ Upstream commit 30572418b445d85fcfe6c8fe84c947d2606767d8 ] This driver needlessly took another reference to the tty on open, a reference which was then never released on close. This lead to not just a leak of the tty, but also a driver reference leak that prevented the driver from being unloaded after a port had once been opened. Fixes: 4a90f09b20f4 ("tty: usb-serial krefs") Cc: stable # 2.6.28 Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 6aed13b2c40eaaf46c57a093da1cd1adace1b235 Author: Johan Hovold Date: Mon Mar 6 17:36:37 2017 +0100 USB: serial: io_ti: fix NULL-deref in interrupt callback [ Upstream commit 0b1d250afb8eb9d65afb568bac9b9f9253a82b49 ] Fix a NULL-pointer dereference in the interrupt callback should a malicious device send data containing a bad port number by adding the missing sanity check. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 92fbcbfe994f1b00d7ff66254e0c324b6799c556 Author: John Crispin Date: Sat Feb 25 11:54:23 2017 +0100 MIPS: ralink: Fix typos in rt3883 pinctrl [ Upstream commit 7c5a3d813050ee235817b0220dd8c42359a9efd8 ] There are two copy & paste errors in the definition of the 5GHz LNA and second ethernet pinmux. Fixes: f576fb6a0700 ("MIPS: ralink: cleanup the soc specific pinmux data") Signed-off-by: John Crispin Signed-off-by: Daniel Golle Cc: linux-mips@linux-mips.org Cc: # 3.19.x- Patchwork: https://patchwork.linux-mips.org/patch/15328/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 7ba49ba6dd09a769679534ad07ab626c7939635b Author: Paul Burton Date: Thu Feb 23 14:50:24 2017 +0000 MIPS: End spinlocks with .insn [ Upstream commit 4b5347a24a0f2d3272032c120664b484478455de ] When building for microMIPS we need to ensure that the assembler always knows that there is code at the target of a branch or jump. Recent toolchains will fail to link a microMIPS kernel when this isn't the case due to what it thinks is a branch to non-microMIPS code. mips-mti-linux-gnu-ld kernel/built-in.o: .spinlock.text+0x2fc: Unsupported branch between ISA modes. mips-mti-linux-gnu-ld final link failed: Bad value This is due to inline assembly labels in spinlock.h not being followed by an instruction mnemonic, either due to a .subsection pseudo-op or the end of the inline asm block. Fix this with a .insn direction after such labels. Signed-off-by: Paul Burton Signed-off-by: James Hogan Reviewed-by: Maciej W. Rozycki Cc: Ralf Baechle Cc: Peter Zijlstra Cc: Ingo Molnar Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Patchwork: https://patchwork.linux-mips.org/patch/15325/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit d7f84ae03ff39bc01024c9fdbf44003a6a30e36e Author: James Hogan Date: Thu Feb 16 12:39:01 2017 +0000 MIPS: Force o32 fp64 support on 32bit MIPS64r6 kernels [ Upstream commit 2e6c7747730296a6d4fd700894286db1132598c4 ] When a 32-bit kernel is configured to support MIPS64r6 (CPU_MIPS64_R6), MIPS_O32_FP64_SUPPORT won't be selected as it should be because MIPS32_O32 is disabled (o32 is already the default ABI available on 32-bit kernels). This results in userland FP breakage as CP0_Status.FR is read-only 1 since r6 (when an FPU is present) so __enable_fpu() will fail to clear FR. This causes the FPU emulator to get used which will incorrectly emulate 32-bit FPU registers. Force o32 fp64 support in this case by also selecting MIPS_O32_FP64_SUPPORT from CPU_MIPS64_R6 if 32BIT. Fixes: 4e9d324d4288 ("MIPS: Require O32 FP64 support for MIPS64 with O32 compat") Signed-off-by: James Hogan Reviewed-by: Paul Burton Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: # 4.0.x- Patchwork: https://patchwork.linux-mips.org/patch/15310/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 248e94265dd01fca20289ab9c69415e97908f1ae Author: Max Lohrmann Date: Tue Mar 7 22:09:56 2017 -0800 target: Fix VERIFY_16 handling in sbc_parse_cdb [ Upstream commit 13603685c1f12c67a7a2427f00b63f39a2b6f7c9 ] As reported by Max, the Windows 2008 R2 chkdsk utility expects VERIFY_16 to be supported, and does not handle the returned CHECK_CONDITION properly, resulting in an infinite loop. The kernel will log huge amounts of this error: kernel: TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x8f, sending CHECK_CONDITION. Signed-off-by: Max Lohrmann Cc: Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 452c3c92732548b2b4eafd316d35b1711660858f Author: Nicholas Bellinger Date: Thu Nov 3 23:06:53 2016 -0700 target/pscsi: Fix TYPE_TAPE + TYPE_MEDIMUM_CHANGER export [ Upstream commit a04e54f2c35823ca32d56afcd5cea5b783e2f51a ] The following fixes a divide by zero OOPs with TYPE_TAPE due to pscsi_tape_read_blocksize() failing causing a zero sd->sector_size being propigated up via dev_attrib.hw_block_size. It also fixes another long-standing bug where TYPE_TAPE and TYPE_MEDIMUM_CHANGER where using pscsi_create_type_other(), which does not call scsi_device_get() to take the device reference. Instead, rename pscsi_create_type_rom() to pscsi_create_type_nondisk() and use it for all cases. Finally, also drop a dump_stack() in pscsi_get_blocks() for non TYPE_DISK, which in modern target-core can get invoked via target_sense_desc_format() during CHECK_CONDITION. Reported-by: Malcolm Haak Cc: Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 076df4623c1026c6886d6b3a6282f4e192e19951 Author: Anton Blanchard Date: Mon Feb 13 08:49:20 2017 +1100 scsi: lpfc: Add shutdown method for kexec [ Upstream commit 85e8a23936ab3442de0c42da97d53b29f004ece1 ] We see lpfc devices regularly fail during kexec. Fix this by adding a shutdown method which mirrors the remove method. Cc: Signed-off-by: Anton Blanchard Reviewed-by: Mauricio Faria de Oliveira Tested-by: Mauricio Faria de Oliveira Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e04d8b65f4124848640fa67511f2a63692dd8ad8 Author: Michael Ellerman Date: Tue Mar 7 16:14:49 2017 +1100 powerpc/boot: Fix zImage TOC alignment [ Upstream commit 97ee351b50a49717543533cfb85b4bf9d88c9680 ] Recent toolchains force the TOC to be 256 byte aligned. We need to enforce this alignment in the zImage linker script, otherwise pointers to our TOC variables (__toc_start) could be incorrect. If the actual start of the TOC and __toc_start don't have the same value we crash early in the zImage wrapper. Cc: stable@vger.kernel.org Suggested-by: Alan Modra Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 5c8f767c657b501ce6093784ca4f0c10b05287ab Author: Krzysztof Kozlowski Date: Sat Feb 25 18:36:44 2017 +0200 serial: samsung: Continue to work if DMA request fails [ Upstream commit f98c7bce570bdbe344b74ff5daa7dfeef3f22929 ] If DMA is not available (even when configured in DeviceTree), the driver will fail the startup procedure thus making serial console not available. For example this causes boot failure on QEMU ARMv7 (Exynos4210, SMDKC210): [    1.302575] OF: amba_device_add() failed (-19) for /amba/pdma@12680000 ... [   11.435732] samsung-uart 13800000.serial: DMA request failed [   72.963893] samsung-uart 13800000.serial: DMA request failed [   73.143361] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 DMA is not necessary for serial to work, so continue with UART startup after emitting a warning. Fixes: 62c37eedb74c ("serial: samsung: add dma reqest/release functions") Cc: Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 46df5258a5210325e9039555f9ca1238de0d0dab Author: Kai-Heng Feng Date: Tue Mar 7 09:31:29 2017 -0800 Input: i8042 - add noloop quirk for Dell Embedded Box PC 3000 [ Upstream commit 45838660e34d90db8d4f7cbc8fd66e8aff79f4fe ] The aux port does not get detected without noloop quirk, so external PS/2 mouse cannot work as result. The PS/2 mouse can work with this quirk. BugLink: https://bugs.launchpad.net/bugs/1591053 Signed-off-by: Kai-Heng Feng Reviewed-by: Marcos Paulo de Souza Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 9d3698c9b85c7f65148b97133c7918841a4fc25f Author: Daniel Glöckner Date: Fri Feb 24 15:05:14 2017 +0100 ima: accept previously set IMA_NEW_FILE [ Upstream commit 1ac202e978e18f045006d75bd549612620c6ec3a ] Modifying the attributes of a file makes ima_inode_post_setattr reset the IMA cache flags. So if the file, which has just been created, is opened a second time before the first file descriptor is closed, verification fails since the security.ima xattr has not been written yet. We therefore have to look at the IMA_NEW_FILE even if the file already existed. With this patch there should no longer be an error when cat tries to open testfile: $ rm -f testfile $ ( echo test >&3 ; touch testfile ; cat testfile ) 3>testfile A file being new is no reason to accept that it is missing a digital signature demanded by the policy. Signed-off-by: Daniel Glöckner Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 86525f9f44749350e61f31fdcf9c6ea8408652a7 Author: Tahsin Erdogan Date: Sat Feb 25 13:00:19 2017 -0800 percpu: acquire pcpu_lock when updating pcpu_nr_empty_pop_pages [ Upstream commit 320661b08dd6f1746d5c7ab4eb435ec64b97cd45 ] Update to pcpu_nr_empty_pop_pages in pcpu_alloc() is currently done without holding pcpu_lock. This can lead to bad updates to the variable. Add missing lock calls. Fixes: b539b87fed37 ("percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated") Signed-off-by: Tahsin Erdogan Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org # v3.18+ Signed-off-by: Sasha Levin commit 42ece5f5009813df9cb12f5cbc26277af496d149 Author: Peter Chen Date: Tue Feb 28 14:25:45 2017 +0800 usb: gadget: dummy_hcd: clear usb_gadget region before registration [ Upstream commit 5bbc852676ae08e818241cf66a3ffe4be44225c4 ] When the user does device unbind and rebind test, the kernel will show below dump due to usb_gadget memory region is dirty after unbind. Clear usb_gadget region for every new probe. root@imx6qdlsolo:/sys/bus/platform/drivers/dummy_udc# echo dummy_udc.0 > bind [ 102.523312] kobject (eddd78b0): tried to init an initialized object, something is seriously wrong. [ 102.532447] CPU: 0 PID: 734 Comm: sh Not tainted 4.10.0-rc7-00872-g1b2b8e9 #1298 [ 102.539866] Hardware name: Freescale i.MX6 SoloX (Device Tree) [ 102.545717] Backtrace: [ 102.548225] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 102.555822] r7:ede34000 r6:60010013 r5:00000000 r4:c0f29418 [ 102.561512] [] (show_stack) from [] (dump_stack+0xb4/0xe8) [ 102.568764] [] (dump_stack) from [] (kobject_init+0x80/0x9c) [ 102.576187] r10:0000001f r9:eddd7000 r8:eeaf8c10 r7:eddd78a8 r6:c177891c r5:c0f3b060 [ 102.584036] r4:eddd78b0 r3:00000000 [ 102.587641] [] (kobject_init) from [] (device_initialize+0x28/0xf8) [ 102.595665] r5:eebc4800 r4:eddd78a8 [ 102.599268] [] (device_initialize) from [] (device_register+0x14/0x20) [ 102.607556] r7:eddd78a8 r6:00000000 r5:eebc4800 r4:eddd78a8 [ 102.613256] [] (device_register) from [] (usb_add_gadget_udc_release+0x8c/0x1ec) [ 102.622410] r5:eebc4800 r4:eddd7860 [ 102.626015] [] (usb_add_gadget_udc_release) from [] (usb_add_gadget_udc+0x14/0x18) [ 102.635351] r10:0000001f r9:eddd7000 r8:eddd788c r7:bf003770 r6:eddd77f8 r5:eddd7818 [ 102.643198] r4:eddd785c r3:eddd7b24 [ 102.646834] [] (usb_add_gadget_udc) from [] (dummy_udc_probe+0x170/0x1c4 [dummy_hcd]) [ 102.656458] [] (dummy_udc_probe [dummy_hcd]) from [] (platform_drv_probe+0x54/0xb8) [ 102.665881] r10:00000008 r9:c1778960 r8:bf004128 r7:fffffdfb r6:bf004128 r5:eeaf8c10 [ 102.673727] r4:eeaf8c10 [ 102.676293] [] (platform_drv_probe) from [] (driver_probe_device+0x264/0x474) [ 102.685186] r7:00000000 r6:00000000 r5:c1778960 r4:eeaf8c10 [ 102.690876] [] (driver_probe_device) from [] (bind_store+0xb8/0x14c) [ 102.698994] r10:eeb3bb4c r9:ede34000 r8:0000000c r7:eeaf8c44 r6:bf004128 r5:c0f3b668 [ 102.706840] r4:eeaf8c10 [ 102.709402] [] (bind_store) from [] (drv_attr_store+0x28/0x34) [ 102.716998] r9:ede34000 r8:00000000 r7:ee3863c0 r6:ee3863c0 r5:c0538c80 r4:c053970c [ 102.724776] [] (drv_attr_store) from [] (sysfs_kf_write+0x50/0x54) [ 102.732711] r5:c0538c80 r4:0000000c [ 102.736313] [] (sysfs_kf_write) from [] (kernfs_fop_write+0x100/0x214) [ 102.744599] r7:ee3863c0 r6:eeb3bb40 r5:00000000 r4:00000000 [ 102.750287] [] (kernfs_fop_write) from [] (__vfs_write+0x34/0x120) [ 102.758231] r10:00000000 r9:ede34000 r8:c0108bc4 r7:0000000c r6:ede35f80 r5:c029bd84 [ 102.766077] r4:ee223780 [ 102.768638] [] (__vfs_write) from [] (vfs_write+0xa8/0x170) [ 102.775974] r9:ede34000 r8:c0108bc4 r7:ede35f80 r6:01861cb0 r5:ee223780 r4:0000000c [ 102.783743] [] (vfs_write) from [] (SyS_write+0x4c/0xa8) [ 102.790818] r9:ede34000 r8:c0108bc4 r7:0000000c r6:01861cb0 r5:ee223780 r4:ee223780 [ 102.798595] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c) [ 102.806188] r7:00000004 r6:b6e83d58 r5:01861cb0 r4:0000000c Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers") Cc: stable Acked-by: Alan Stern Signed-off-by: Peter Chen Tested-by: Xiaolong Ye Reported-by: Fengguang Wu Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 7ccd5568eab897df049865324ff8f1694a452011 Author: Johan Hovold Date: Fri Feb 24 19:11:28 2017 +0100 USB: serial: digi_acceleport: fix OOB-event processing [ Upstream commit 2e46565cf622dd0534a9d8bffe152a577b48d7aa ] A recent change claimed to fix an off-by-one error in the OOB-port completion handler, but instead introduced such an error. This could specifically led to modem-status changes going unnoticed, effectively breaking TIOCMGET. Note that the offending commit fixes a loop-condition underflow and is marked for stable, but should not be backported without this fix. Reported-by: Ben Hutchings Fixes: 2d380889215f ("USB: serial: digi_acceleport: fix OOB data sanity check") Cc: stable # v2.6.30: 2d380889215f Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 6842c845729264a5d7bcd1fe7c1a1b10dcd770a9 Author: Ian Abbott Date: Fri Feb 17 11:09:09 2017 +0000 staging: comedi: jr3_pci: cope with jiffies wraparound [ Upstream commit 8ec04a491825e08068e92bed0bba7821893b6433 ] The timer expiry routine `jr3_pci_poll_dev()` checks for expiry by checking whether the absolute value of `jiffies` (stored in local variable `now`) is greater than the expected expiry time in jiffy units. This will fail when `jiffies` wraps around. Also, it seems to make sense to handle the expiry one jiffy earlier than the current test. Use `time_after_eq()` to check for expiry. Cc: # 3.15+ Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 29e34e47fadf0aeea2861e27b6d518e3bba43d51 Author: Ian Abbott Date: Fri Feb 17 11:09:08 2017 +0000 staging: comedi: jr3_pci: fix possible null pointer dereference [ Upstream commit 45292be0b3db0b7f8286683b376e2d9f949d11f9 ] For some reason, the driver does not consider allocation of the subdevice private data to be a fatal error when attaching the COMEDI device. It tests the subdevice private data pointer for validity at certain points, but omits some crucial tests. In particular, `jr3_pci_auto_attach()` calls `jr3_pci_alloc_spriv()` to allocate and initialize the subdevice private data, but the same function subsequently dereferences the pointer to access the `next_time_min` and `next_time_max` members without checking it first. The other missing test is in the timer expiry routine `jr3_pci_poll_dev()`, but it will crash before it gets that far. Fix the bug by returning `-ENOMEM` from `jr3_pci_auto_attach()` as soon as one of the calls to `jr3_pci_alloc_spriv()` returns `NULL`. The COMEDI core will subsequently call `jr3_pci_detach()` to clean up. Cc: # 3.15+ Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c48408dff998127cf7d7917e98e3bdc1b9548b9b Author: Felipe Balbi Date: Tue Jan 31 14:54:45 2017 +0200 usb: gadget: function: f_fs: pass companion descriptor along [ Upstream commit 2bfa0719ac2a9b2f3c91345873d3cdebd0296ba9 ] If we're dealing with SuperSpeed endpoints, we need to make sure to pass along the companion descriptor and initialize fields needed by the Gadget API. Eventually, f_fs.c should be converted to use config_ep_by_speed() like all other functions, though. Cc: Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 757895c336d6cb6126d1bc97c46db53afa0f0bff Author: Felipe Balbi Date: Tue Jan 31 13:24:54 2017 +0200 usb: dwc3: gadget: make Set Endpoint Configuration macros safe [ Upstream commit 7369090a9fb57c3fc705ce355d2e4523a5a24716 ] Some gadget drivers are bad, bad boys. We notice that ADB was passing bad Burst Size which caused top bits of param0 to be overwritten which confused DWC3 when running this command. In order to avoid future issues, we're going to make sure values passed by macros are always safe for the controller. Note that ADB still needs a fix to *not* pass bad values. Cc: # v3.2+ Reported-by: Mohamed Abbas Sugested-by: Adam Andruszak Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 2e9d3a921000a40e3cd9a689e8dd39a08c0e2e83 Author: Rik van Riel Date: Wed Sep 28 22:55:54 2016 -0400 tracing: Add #undef to fix compile error [ Upstream commit bf7165cfa23695c51998231c4efa080fe1d3548d ] There are several trace include files that define TRACE_INCLUDE_FILE. Include several of them in the same .c file (as I currently have in some code I am working on), and the compile will blow up with a "warning: "TRACE_INCLUDE_FILE" redefined #define TRACE_INCLUDE_FILE syscalls" Every other include file in include/trace/events/ avoids that issue by having a #undef TRACE_INCLUDE_FILE before the #define; syscalls.h should have one, too. Link: http://lkml.kernel.org/r/20160928225554.13bd7ac6@annuminas.surriel.com Cc: stable@vger.kernel.org Fixes: b8007ef74222 ("tracing: Separate raw syscall from syscall tracer") Signed-off-by: Rik van Riel Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit bd38086c6b2a451848f4383e76291e8a3232982a Author: Marc Kleine-Budde Date: Thu Mar 2 12:03:40 2017 +0100 can: usb_8dev: Fix memory leak of priv->cmd_msg_buffer [ Upstream commit 7c42631376306fb3f34d51fda546b50a9b6dd6ec ] The priv->cmd_msg_buffer is allocated in the probe function, but never kfree()ed. This patch converts the kzalloc() to resource-managed kzalloc. Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 99d3d49197e1f2663c91c7e28d4dec86105c0e60 Author: Ravi Bangoria Date: Tue Feb 14 14:46:42 2017 +0530 powerpc: Emulation support for load/store instructions on LE [ Upstream commit e148bd17f48bd17fca2f4f089ec879fa6e47e34c ] emulate_step() uses a number of underlying kernel functions that were initially not enabled for LE. This has been rectified since. So, fix emulate_step() for LE for the corresponding instructions. Cc: stable@vger.kernel.org # v3.18+ Reported-by: Anton Blanchard Signed-off-by: Ravi Bangoria Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 381785176cc15523a865c607496a1cb61b48055f Author: Janosch Frank Date: Thu Mar 2 15:23:42 2017 +0100 KVM: s390: Fix guest migration for huge guests resulting in panic [ Upstream commit 2e4d88009f57057df7672fa69a32b5224af54d37 ] While we can technically not run huge page guests right now, we can setup a guest with huge pages. Trying to migrate it will trigger a VM_BUG_ON and, if the kernel is not configured to panic on a BUG, it will happily try to work on non-existing page table entries. With this patch, we always return "dirty" if we encounter a large page when migrating. This at least fixes the immediate problem until we have proper handling for both kind of pages. Fixes: 15f36eb ("KVM: s390: Add proper dirty bitmap support to S390 kvm.") Cc: # 3.16+ Signed-off-by: Janosch Frank Acked-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 7caf29dc038c8537d94cfc4be4f8b9345a1a1741 Author: Max Filippov Date: Tue Jan 3 09:37:34 2017 -0800 xtensa: move parse_tag_fdt out of #ifdef CONFIG_BLK_DEV_INITRD [ Upstream commit 4ab18701c66552944188dbcd0ce0012729baab84 ] FDT tag parsing is not related to whether BLK_DEV_INITRD is configured or not, move it out of the corresponding #ifdef/#endif block. This fixes passing external FDT to the kernel configured w/o BLK_DEV_INITRD support. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit 14abcbaa3f0d5698f8f88a4f1d55b2ce115bf970 Author: Chris Leech Date: Mon Feb 27 16:58:36 2017 -0800 scsi: libiscsi: add lock around task lists to fix list corruption regression [ Upstream commit 6f8830f5bbab16e54f261de187f3df4644a5b977 ] There's a rather long standing regression from the commit "libiscsi: Reduce locking contention in fast path" Depending on iSCSI target behavior, it's possible to hit the case in iscsi_complete_task where the task is still on a pending list (!list_empty(&task->running)). When that happens the task is removed from the list while holding the session back_lock, but other task list modification occur under the frwd_lock. That leads to linked list corruption and eventually a panicked system. Rather than back out the session lock split entirely, in order to try and keep some of the performance gains this patch adds another lock to maintain the task lists integrity. Major enterprise supported kernels have been backing out the lock split for while now, thanks to the efforts at IBM where a lab setup has the most reliable reproducer I've seen on this issue. This patch has been tested there successfully. Signed-off-by: Chris Leech Fixes: 659743b02c41 ("[SCSI] libiscsi: Reduce locking contention in fast path") Reported-by: Prashantha Subbarao Reviewed-by: Guilherme G. Piccoli Cc: # v3.15+ Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 28d5d8b2db228c1d1a9a47050c8d64895d862f94 Author: Takashi Iwai Date: Tue Feb 28 22:15:51 2017 +0100 ALSA: seq: Fix link corruption by event error handling [ Upstream commit f3ac9f737603da80c2da3e84b89e74429836bb6d ] The sequencer FIFO management has a bug that may lead to a corruption (shortage) of the cell linked list. When a sequencer client faces an error at the event delivery, it tries to put back the dequeued cell. When the first queue was put back, this forgot the tail pointer tracking, and the link will be screwed up. Although there is no memory corruption, the sequencer client may stall forever at exit while flushing the pending FIFO cells in snd_seq_pool_done(), as spotted by syzkaller. This patch addresses the missing tail pointer tracking at snd_seq_fifo_cell_putback(). Also the patch makes sure to clear the cell->enxt pointer at snd_seq_fifo_event_in() for avoiding a similar mess-up of the FIFO linked list. Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b78e49c3057a60cb4a6deb23cc8c470188c0603d Author: Takashi Iwai Date: Tue Feb 28 17:27:57 2017 +0100 ALSA: hda - Add subwoofer support for Dell Inspiron 17 7000 Gaming [ Upstream commit 493de342748cc6f52938096f5480cf291da58a0b ] Dell Inspiron 17 7000 Gaming laptop needs a similar quirk like Inspiron 7599 to support its subwoofer speaker. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194191 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d19f6529f1c1b49ad3ede7e5f899d949a2e66a68 Author: Takashi Iwai Date: Tue Feb 28 14:49:07 2017 +0100 ALSA: timer: Reject user params with too small ticks [ Upstream commit 71321eb3f2d0df4e6c327e0b936eec4458a12054 ] When a user sets a too small ticks with a fine-grained timer like hrtimer, the kernel tries to fire up the timer irq too frequently. This may lead to the condensed locks, eventually the kernel spinlock lockup with warnings. For avoiding such a situation, we define a lower limit of the resolution, namely 1ms. When the user passes a too small tick value that results in less than that, the kernel returns -EINVAL now. Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3d35f44225829db0c25301815be9197ae424538b Author: Y.C. Chen Date: Wed Feb 22 15:14:19 2017 +1100 drm/ast: Call open_key before enable_mmio in POST code [ Upstream commit 9bb92f51558f2ef5f56c257bdcea0588f31d857e ] open_key enables access the registers used by enable_mmio Signed-off-by: Y.C. Chen Signed-off-by: Benjamin Herrenschmidt Acked-by: Joel Stanley Tested-by: Y.C. Chen Cc: Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit 2188c2b367c6eba77622b478c5fe12bbcc3c88bd Author: Y.C. Chen Date: Wed Feb 22 15:10:50 2017 +1100 drm/ast: Fix test for VGA enabled [ Upstream commit 905f21a49d388de3e99438235f3301cabf0c0ef4 ] The test to see if VGA was already enabled is doing an unnecessary second test from a register that may or may not have been initialized to a valid value. Remove it. Signed-off-by: Y.C. Chen Signed-off-by: Benjamin Herrenschmidt Cc: Acked-by: Joel Stanley Tested-by: Y.C. Chen Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit e8b120e25fbc9f19ebff0cfaa0da7049fd25f29c Author: Y.C. Chen Date: Thu Feb 23 15:52:33 2017 +0800 drm/ast: Fix AST2400 POST failure without BMC FW or VBIOS [ Upstream commit 3856081eede297b617560b85e948cfb00bb395ec ] The current POST code for the AST2300/2400 family doesn't work properly if the chip hasn't been initialized previously by either the BMC own FW or the VBIOS. This fixes it. Signed-off-by: Y.C. Chen Signed-off-by: Benjamin Herrenschmidt Tested-by: Y.C. Chen Acked-by: Joel Stanley Cc: Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit c9cf983337a046e93f33c66c2707a704ec6440ac Author: Davidlohr Bueso Date: Mon Feb 27 14:28:24 2017 -0800 ipc/shm: Fix shmat mmap nil-page protection [ Upstream commit 95e91b831f87ac8e1f8ed50c14d709089b4e01b8 ] The issue is described here, with a nice testcase: https://bugzilla.kernel.org/show_bug.cgi?id=192931 The problem is that shmat() calls do_mmap_pgoff() with MAP_FIXED, and the address rounded down to 0. For the regular mmap case, the protection mentioned above is that the kernel gets to generate the address -- arch_get_unmapped_area() will always check for MAP_FIXED and return that address. So by the time we do security_mmap_addr(0) things get funky for shmat(). The testcase itself shows that while a regular user crashes, root will not have a problem attaching a nil-page. There are two possible fixes to this. The first, and which this patch does, is to simply allow root to crash as well -- this is also regular mmap behavior, ie when hacking up the testcase and adding mmap(... |MAP_FIXED). While this approach is the safer option, the second alternative is to ignore SHM_RND if the rounded address is 0, thus only having MAP_SHARED flags. This makes the behavior of shmat() identical to the mmap() case. The downside of this is obviously user visible, but does make sense in that it maintains semantics after the round-down wrt 0 address and mmap. Passes shm related ltp tests. Link: http://lkml.kernel.org/r/1486050195-18629-1-git-send-email-dave@stgolabs.net Signed-off-by: Davidlohr Bueso Reported-by: Gareth Evans Cc: Manfred Spraul Cc: Michael Kerrisk Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1827f7e6062b7d620844d1c215b1aa34975dc2b1 Author: Matt Chen Date: Sun Jan 22 02:16:58 2017 +0800 mac80211: flush delayed work when entering suspend [ Upstream commit a9e9200d8661c1a0be8c39f93deb383dc940de35 ] The issue was found when entering suspend and resume. It triggers a warning in: mac80211/key.c: ieee80211_enable_keys() ... WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt || sdata->crypto_tx_tailroom_pending_dec); ... It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully in a delayed_work during suspend. Add a flush_delayed_work to fix it. Cc: stable@vger.kernel.org Signed-off-by: Matt Chen Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0dad072cfc1df7b68677c7fb58455b68a35c41b5 Author: Hui Wang Date: Mon Feb 27 10:11:47 2017 +0800 ALSA: hda - Fix micmute hotkey problem for a lenovo AIO machine [ Upstream commit 29693efcea0f38cf40d0055d2401490a4f9bf8be ] On this machine, the micmute button is connected to Line2 of the codec and the micmute led is connected to GPIO2 of the codec. After applying this quirk, both hotkey and led work well. Cc: Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e5ee49ad28a053f7adf3e293379a577c4a326ba4 Author: Minchan Kim Date: Fri Feb 24 14:59:59 2017 -0800 mm: do not access page->mapping directly on page_endio [ Upstream commit dd8416c47715cf324c9a16f13273f9fda87acfed ] With rw_page, page_endio is used for completing IO on a page and it propagates write error to the address space if the IO fails. The problem is it accesses page->mapping directly which might be okay for file-backed pages but it shouldn't for anonymous page. Otherwise, it can corrupt one of field from anon_vma under us and system goes panic randomly. swap_writepage bdev_writepage ops->rw_page I encountered the BUG during developing new zram feature and it was really hard to figure it out because it made random crash, somtime mmap_sem lockdep, sometime other places where places never related to zram/zsmalloc, and not reproducible with some configuration. When I consider how that bug is subtle and people do fast-swap test with brd, it's worth to add stable mark, I think. Fixes: dd6bd0d9c7db ("swap: use bdev_read_page() / bdev_write_page()") Signed-off-by: Minchan Kim Acked-by: Michal Hocko Cc: Matthew Wilcox Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 21a6489deda10af6ed3c18ba6b1bfc12e41bf448 Author: Vinayak Menon Date: Fri Feb 24 14:59:39 2017 -0800 mm: vmpressure: fix sending wrong events on underflow [ Upstream commit e1587a4945408faa58d0485002c110eb2454740c ] At the end of a window period, if the reclaimed pages is greater than scanned, an unsigned underflow can result in a huge pressure value and thus a critical event. Reclaimed pages is found to go higher than scanned because of the addition of reclaimed slab pages to reclaimed in shrink_node without a corresponding increment to scanned pages. Minchan Kim mentioned that this can also happen in the case of a THP page where the scanned is 1 and reclaimed could be 512. Link: http://lkml.kernel.org/r/1486641577-11685-1-git-send-email-vinmenon@codeaurora.org Signed-off-by: Vinayak Menon Acked-by: Minchan Kim Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Mel Gorman Cc: Vlastimil Babka Cc: Rik van Riel Cc: Vladimir Davydov Cc: Anton Vorontsov Cc: Shiraz Hashim Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 091e3373d97f0f31cdd68554dee13be80cac551e Author: Gavin Shan Date: Fri Feb 24 14:59:33 2017 -0800 mm/page_alloc: fix nodes for reclaim in fast path [ Upstream commit e02dc017c3032dcdce1b993af0db135462e1b4b7 ] When @node_reclaim_node isn't 0, the page allocator tries to reclaim pages if the amount of free memory in the zones are below the low watermark. On Power platform, none of NUMA nodes are scanned for page reclaim because no nodes match the condition in zone_allows_reclaim(). On Power platform, RECLAIM_DISTANCE is set to 10 which is the distance of Node-A to Node-A. So the preferred node even won't be scanned for page reclaim. __alloc_pages_nodemask() get_page_from_freelist() zone_allows_reclaim() Anton proposed the test code as below: # cat alloc.c : int main(int argc, char *argv[]) { void *p; unsigned long size; unsigned long start, end; start = time(NULL); size = strtoul(argv[1], NULL, 0); printf("To allocate %ldGB memory\n", size); size <<= 30; p = malloc(size); assert(p); memset(p, 0, size); end = time(NULL); printf("Used time: %ld seconds\n", end - start); sleep(3600); return 0; } The system I use for testing has two NUMA nodes. Both have 128GB memory. In below scnario, the page caches on node#0 should be reclaimed when it encounters pressure to accommodate request of allocation. # echo 2 > /proc/sys/vm/zone_reclaim_mode; \ sync; \ echo 3 > /proc/sys/vm/drop_caches; \ # taskset -c 0 cat file.32G > /dev/null; \ grep FilePages /sys/devices/system/node/node0/meminfo Node 0 FilePages: 33619712 kB # taskset -c 0 ./alloc 128 # grep FilePages /sys/devices/system/node/node0/meminfo Node 0 FilePages: 33619840 kB # grep MemFree /sys/devices/system/node/node0/meminfo Node 0 MemFree: 186816 kB With the patch applied, the pagecache on node-0 is reclaimed when its free memory is running out. It's the expected behaviour. # echo 2 > /proc/sys/vm/zone_reclaim_mode; \ sync; \ echo 3 > /proc/sys/vm/drop_caches # taskset -c 0 cat file.32G > /dev/null; \ grep FilePages /sys/devices/system/node/node0/meminfo Node 0 FilePages: 33605568 kB # taskset -c 0 ./alloc 128 # grep FilePages /sys/devices/system/node/node0/meminfo Node 0 FilePages: 1379520 kB # grep MemFree /sys/devices/system/node/node0/meminfo Node 0 MemFree: 317120 kB Fixes: 5f7a75acdb24 ("mm: page_alloc: do not cache reclaim distances") Link: http://lkml.kernel.org/r/1486532455-29613-1-git-send-email-gwshan@linux.vnet.ibm.com Signed-off-by: Gavin Shan Acked-by: Mel Gorman Acked-by: Michal Hocko Cc: Anton Blanchard Cc: Michael Ellerman Cc: [3.16+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7ec8bd575e7bc7035ac129c1930ed63108565a4c Author: Martin Schwidefsky Date: Fri Feb 24 07:43:51 2017 +0100 s390: TASK_SIZE for kernel threads [ Upstream commit fb94a687d96c570d46332a4a890f1dcb7310e643 ] Return a sensible value if TASK_SIZE if called from a kernel thread. This gets us around an issue with copy_mount_options that does a magic size calculation "TASK_SIZE - (unsigned long)data" while in a kernel thread and data pointing to kernel space. Cc: Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 01592a4b8ba830d470954fd896fff1f4c2bcd195 Author: Weston Andros Adamson Date: Thu Feb 23 14:54:21 2017 -0500 NFSv4: fix getacl ERANGE for some ACL buffer sizes [ Upstream commit ed92d8c137b7794c2c2aa14479298b9885967607 ] We're not taking into account that the space needed for the (variable length) attr bitmap, with the result that we'd sometimes get a spurious ERANGE when the ACL data got close to the end of a page. Just add in an extra page to make sure. Signed-off-by: Weston Andros Adamson Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit bb9e115a5e850226c8fcaa9b69d723b78280085e Author: J. Bruce Fields Date: Thu Feb 23 14:53:39 2017 -0500 NFSv4: fix getacl head length estimation [ Upstream commit 6682c14bbe505a8b912c57faf544f866777ee48d ] Bitmap and attrlen follow immediately after the op reply header. This was an oversight from commit bf118a342f. Consequences of this are just minor efficiency (extra calls to xdr_shrink_bufhead). Fixes: bf118a342f10 "NFSv4: include bitmap in nfsv4 get acl data" Reviewed-by: Kinglong Mee Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 05365e1fdea91ecb498c42ce04e7025567b0af92 Author: Raghava Aditya Renukunta Date: Thu Feb 16 12:51:21 2017 -0800 scsi: aacraid: Reorder Adapter status check [ Upstream commit c421530bf848604e97d0785a03b3fe2c62775083 ] The driver currently checks the SELF_TEST_FAILED first and then KERNEL_PANIC next. Under error conditions(boot code failure) both SELF_TEST_FAILED and KERNEL_PANIC can be set at the same time. The driver has the capability to reset the controller on an KERNEL_PANIC, but not on SELF_TEST_FAILED. Fixed by first checking KERNEL_PANIC and then the others. Cc: stable@vger.kernel.org Fixes: e8b12f0fb835223752 ([SCSI] aacraid: Add new code for PMC-Sierra's SRC base controller family) Signed-off-by: Raghava Aditya Renukunta Reviewed-by: David Carroll Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f90e6f9a26babaab61dacf11976487334e98595a Author: Steve Wise Date: Tue Feb 21 11:21:57 2017 -0800 rdma_cm: fail iwarp accepts w/o connection params [ Upstream commit f2625f7db4dd0bbd16a9c7d2950e7621f9aa57ad ] cma_accept_iw() needs to return an error if conn_params is NULL. Since this is coming from user space, we can crash. Reported-by: Shaobo He Acked-by: Sean Hefty Signed-off-by: Steve Wise Cc: stable@vger.kernel.org Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit a60c9ff335a19c91162f95fa8558f7c1318c7aa4 Author: Bart Van Assche Date: Tue Feb 14 10:56:30 2017 -0800 IB/srp: Avoid that duplicate responses trigger a kernel bug [ Upstream commit 6cb72bc1b40bb2c1750ee7a5ebade93bed49a5fb ] After srp_process_rsp() returns there is a short time during which the scsi_host_find_tag() call will return a pointer to the SCSI command that is being completed. If during that time a duplicate response is received, avoid that the following call stack appears: BUG: unable to handle kernel NULL pointer dereference at (null) IP: srp_recv_done+0x450/0x6b0 [ib_srp] Oops: 0000 [#1] SMP CPU: 10 PID: 0 Comm: swapper/10 Not tainted 4.10.0-rc7-dbg+ #1 Call Trace: __ib_process_cq+0x4b/0xd0 [ib_core] ib_poll_handler+0x1d/0x70 [ib_core] irq_poll_softirq+0xba/0x120 __do_softirq+0xba/0x4c0 irq_exit+0xbe/0xd0 smp_apic_timer_interrupt+0x38/0x50 apic_timer_interrupt+0x90/0xa0 RIP: srp_recv_done+0x450/0x6b0 [ib_srp] RSP: ffff88046f483e20 Signed-off-by: Bart Van Assche Cc: Israel Rukshin Cc: Max Gurtovoy Cc: Laurence Oberman Cc: Steve Feeley Cc: Reviewed-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 3cac36b0423b07e57d77690db9b2dd2632b0834c Author: Mirko Parthey Date: Wed Feb 15 23:31:30 2017 +0100 MIPS: BCM47XX: Fix button inversion for Asus WL-500W [ Upstream commit bdfdaf1a016ef09cb941f2edad485a713510b8d5 ] The Asus WL-500W buttons are active high, but the software treats them as active low. Fix the inverted logic. Fixes: 3be972556fa1 ("MIPS: BCM47XX: Import buttons database from OpenWrt") Signed-off-by: Mirko Parthey Acked-by: Rafał Miłecki Cc: Hauke Mehrtens Cc: linux-mips@linux-mips.org Cc: # 3.14.x- Patchwork: https://patchwork.linux-mips.org/patch/15295/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 512cbc94607b24a038b6421d4376546e5f5e8eeb Author: James Cowgill Date: Mon Jan 9 16:52:28 2017 +0000 MIPS: OCTEON: Fix copy_from_user fault handling for large buffers [ Upstream commit 884b426917e4b3c85f33b382c792a94305dfdd62 ] If copy_from_user is called with a large buffer (>= 128 bytes) and the userspace buffer refers partially to unreadable memory, then it is possible for Octeon's copy_from_user to report the wrong number of bytes have been copied. In the case where the buffer size is an exact multiple of 128 and the fault occurs in the last 64 bytes, copy_from_user will report that all the bytes were copied successfully but leave some garbage in the destination buffer. The bug is in the main __copy_user_common loop in octeon-memcpy.S where in the middle of the loop, src and dst are incremented by 128 bytes. The l_exc_copy fault handler is used after this but that assumes that "src < THREAD_BUADDR($28)". This is not the case if src has already been incremented. Fix by adding an extra fault handler which rewinds the src and dst pointers 128 bytes before falling though to l_exc_copy. Thanks to the pwritev test from the strace test suite for originally highlighting this bug! Fixes: 5b3b16880f40 ("MIPS: Add Cavium OCTEON processor support ...") Signed-off-by: James Cowgill Acked-by: David Daney Reviewed-by: James Hogan Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14978/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 9b4ed3674858e548af50192021a2438385f14b8d Author: Ralf Baechle Date: Thu Jan 26 02:16:47 2017 +0100 MIPS: Fix special case in 64 bit IP checksumming. [ Upstream commit 66fd848cadaa6be974a8c780fbeb328f0af4d3bd ] For certain arguments such as saddr = 0xc0a8fd60, daddr = 0xc0a8fda1, len = 80, proto = 17, sum = 0x7eae049d there will be a carry when folding the intermediate 64 bit checksum to 32 bit but the code doesn't add the carry back to the one's complement sum, thus an incorrect result will be generated. Reported-by: Mark Zhang Signed-off-by: Ralf Baechle Reviewed-by: James Hogan Cc: stable@vger.kernel.org Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 85050844c0b965b1df88757da86f39554c8a099c Author: Joe Thornber Date: Thu Feb 9 11:46:18 2017 -0500 dm cache: fix corruption seen when using cache > 2TB [ Upstream commit ca763d0a53b264a650342cee206512bc92ac7050 ] A rounding bug due to compiler generated temporary being 32bit was found in remap_to_cache(). A localized cast in remap_to_cache() fixes the corruption but this preferred fix (changing from uint32_t to sector_t) eliminates potential for future rounding errors elsewhere. Cc: stable@vger.kernel.org Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit c0601ca14e10d4044937f0cd3e47f174ee15f89c Author: Dmitry Tunin Date: Thu Jan 5 13:19:53 2017 +0300 Bluetooth: Add another AR3012 04ca:3018 device [ Upstream commit 441ad62d6c3f131f1dbd7dcdd9cbe3f74dbd8501 ] T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3018 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: Dmitry Tunin Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit da1324e7080d1f3cb94c9f61ba509c592f5434e4 Author: Leonard Crestez Date: Tue Feb 14 17:31:03 2017 +0200 regulator: Fix regulator_summary for deviceless consumers [ Upstream commit e42a46b6f52473661ad192f76a128a68fe301df4 ] It is allowed to call regulator_get with a NULL dev argument (_regulator_get explicitly checks for it) but this causes an error later when printing /sys/kernel/debug/regulator_summary. Fix this by explicitly handling "deviceless" consumers in the debugfs code. Signed-off-by: Leonard Crestez Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 01f9734353be30b08e6ec69efd58c8ac57020043 Author: Jaroslav Kysela Date: Wed Feb 15 17:09:42 2017 +0100 ALSA: hda - fix Lewisburg audio issue [ Upstream commit e7480b34ad1ab84a63540b2c884cb92c0764ab74 ] Like for Sunrise Point, the total stream number of Lewisburg's input and output stream exceeds 15 (GCAP is 0x9701), which will cause some streams do not work because of the overflow on SDxCTL.STRM field if using the legacy stream tag allocation method. Fixes: 5cf92c8b3dc5 ("ALSA: hda - Add Intel Lewisburg device IDs Audio") Signed-off-by: Jaroslav Kysela Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b57d6c457569c93093577795106843f625fd641e Author: Thomas Gleixner Date: Wed Feb 15 11:11:51 2017 +0100 goldfish: Sanitize the broken interrupt handler [ Upstream commit 6cf18e6927c0b224f972e3042fb85770d63cb9f8 ] This interrupt handler is broken in several ways: - It loops forever when the op code is not decodeable - It never returns IRQ_HANDLED because the only way to exit the loop returns IRQ_NONE unconditionally. The whole concept of this is broken. Creating devices in an interrupt handler is beyond any point of sanity. Make it at least behave halfways sane so accidental users do not have to deal with a hard to debug lockup. Fixes: e809c22b8fb028 ("goldfish: add the goldfish virtual bus") Reported-by: Gabriel C Signed-off-by: Thomas Gleixner Acked-by: Linus Torvalds Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c1dbd97d8a2a78caf7061ed66cc3dbb3c1cdba38 Author: Thomas Gleixner Date: Wed Feb 15 11:11:50 2017 +0100 x86/platform/goldfish: Prevent unconditional loading [ Upstream commit 47512cfd0d7a8bd6ab71d01cd89fca19eb2093eb ] The goldfish platform code registers the platform device unconditionally which causes havoc in several ways if the goldfish_pdev_bus driver is enabled: - Access to the hardcoded physical memory region, which is either not available or contains stuff which is completely unrelated. - Prevents that the interrupt of the serial port can be requested - In case of a spurious interrupt it goes into a infinite loop in the interrupt handler of the pdev_bus driver (which needs to be fixed seperately). Add a 'goldfish' command line option to make the registration opt-in when the platform is compiled in. I'm seriously grumpy about this engineering trainwreck, which has seven SOBs from Intel developers for 50 lines of code. And none of them figured out that this is broken. Impressive fail! Fixes: ddd70cf93d78 ("goldfish: platform device for x86") Reported-by: Gabriel C Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Acked-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 58cec2bdba91d68713ec2ebd8c6ca1317950eb2b Author: Christian Lamparter Date: Tue Feb 14 20:10:30 2017 +0100 ath9k: use correct OTP register offsets for the AR9340 and AR9550 [ Upstream commit c9f1e32600816d695f817477d56490bfc2ba43c6 ] This patch fixes the OTP register definitions for the AR934x and AR9550 WMAC SoC. Previously, the ath9k driver was unable to initialize the integrated WMAC on an Aerohive AP121: | ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004 | ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004 | ath: phy0: Unable to initialize hardware; initialization status: -5 | ath9k ar934x_wmac: failed to initialize device | ath9k: probe of ar934x_wmac failed with error -5 It turns out that the AR9300_OTP_STATUS and AR9300_OTP_DATA definitions contain a typo. Cc: Gabor Juhos Cc: stable@vger.kernel.org Fixes: add295a4afbdf5852d0 "ath9k: use correct OTP register offsets for AR9550" Signed-off-by: Christian Lamparter Signed-off-by: Chris Blake Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 9aabd8dbacd82a2cd62da83b4e9e1504b53706ee Author: Ravi Bangoria Date: Tue Nov 22 14:55:59 2016 +0530 powerpc/xmon: Fix data-breakpoint [ Upstream commit c21a493a2b44650707d06741601894329486f2ad ] Currently xmon data-breakpoint feature is broken. Whenever there is a watchpoint match occurs, hw_breakpoint_handler will be called by do_break via notifier chains mechanism. If watchpoint is registered by xmon, hw_breakpoint_handler won't find any associated perf_event and returns immediately with NOTIFY_STOP. Similarly, do_break also returns without notifying to xmon. Solve this by returning NOTIFY_DONE when hw_breakpoint_handler does not find any perf_event associated with matched watchpoint, rather than NOTIFY_STOP, which tells the core code to continue calling the other breakpoint handlers including the xmon one. Cc: stable@vger.kernel.org Signed-off-by: Ravi Bangoria Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit c2fd678ea234c68df8628bfe76b2540616c82fd2 Author: Trond Myklebust Date: Sat Feb 11 10:37:38 2017 -0500 nlm: Ensure callback code also checks that the files match [ Upstream commit 251af29c320d86071664f02c76f0d063a19fefdf ] It is not sufficient to just check that the lock pids match when granting a callback, we also need to ensure that we're granting the callback on the right file. Reported-by: Pankaj Singh Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit e53554da9daf2f6b3ee128acf51ceb5ec8965fe8 Author: K. Y. Srinivasan Date: Wed Feb 8 18:30:56 2017 -0700 drivers: hv: Turn off write permission on the hypercall page [ Upstream commit 372b1e91343e657a7cc5e2e2bcecd5140ac28119 ] The hypercall page only needs to be executable but currently it is setup to be writable as well. Fix the issue. Signed-off-by: K. Y. Srinivasan Cc: Acked-by: Kees Cook Reported-by: Stephen Hemminger Tested-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5fdf59513019c3b90b5e6ea2ab112d28a69378f9 Author: Johan Hovold Date: Thu Feb 9 12:11:41 2017 +0100 USB: serial: mos7840: fix another NULL-deref at open [ Upstream commit 5182c2cf2a9bfb7f066ef0bdd2bb6330b94dd74e ] Fix another NULL-pointer dereference at open should a malicious device lack an interrupt-in endpoint. Note that the driver has a broken check for an interrupt-in endpoint which means that an interrupt URB has never even been submitted. Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver") Cc: stable # v2.6.19: 5c75633ef751 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 61f3d22966782ddca6048e4180046fbf1a51fe04 Author: Trond Myklebust Date: Wed Feb 8 11:29:46 2017 -0500 NFSv4: Fix memory and state leak in _nfs4_open_and_get_state [ Upstream commit a974deee477af89411e0f80456bfb344ac433c98 ] If we exit because the file access check failed, we currently leak the struct nfs4_state. We need to attach it to the open context before returning. Fixes: 3efb9722475e ("NFSv4: Refactor _nfs4_open_and_get_state..") Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 95f495896ad85a19454704d7ff05f60215962627 Author: Dan Carpenter Date: Wed Feb 8 02:46:01 2017 +0300 drm/atomic: fix an error code in mode_fixup() [ Upstream commit f9ad86e42d0303eeb8e0d41bb208153022ebd9d2 ] Having "ret" be a bool type works for everything except ret = funcs->atomic_check(). The other functions all return zero on error but ->atomic_check() returns negative error codes. We want to propagate the error code but instead we return 1. I found this bug with static analysis and I don't know if it affects run time. Fixes: 4cd4df8080a3 ("drm/atomic: Add ->atomic_check() to encoder helpers") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170207234601.GA23981@mwanda Signed-off-by: Sasha Levin commit 04df6689f870481bf521e0efbef896a60266d3ae Author: Steven Rostedt (VMware) Date: Tue Feb 7 12:05:25 2017 -0500 ktest: Fix child exit code processing [ Upstream commit 32677207dcc5e594254b7fb4fb2352b1755b1d5b ] The child_exit errno needs to be shifted by 8 bits to compare against the return values for the bisect variables. Fixes: c5dacb88f0a64 ("ktest: Allow overriding bisect test results") Cc: stable@vger.kernel.org Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit a52f3859b78cee24fbbfea9c0216447ad01a3775 Author: Felix Fietkau Date: Thu Feb 2 10:14:52 2017 +0100 ath9k: fix race condition in enabling/disabling IRQs [ Upstream commit 3a5e969bb2f6692a256352649355d56d018d6b88 ] The code currently relies on refcounting to disable IRQs from within the IRQ handler and re-enabling them again after the tasklet has run. However, due to race conditions sometimes the IRQ handler might be called twice, or the tasklet may not run at all (if interrupted in the middle of a reset). This can cause nasty imbalances in the irq-disable refcount which will get the driver permanently stuck until the entire radio has been stopped and started again (ath_reset will not recover from this). Instead of using this fragile logic, change the code to ensure that running the irq handler during tasklet processing is safe, and leave the refcount untouched. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit db5051f860169531000cb649d4deb4fcd1e68c00 Author: Larry Finger Date: Sun Feb 5 10:24:22 2017 -0600 rtlwifi: rtl8192c-common: Fix "BUG: KASAN: [ Upstream commit 6773386f977ce5af339f9678fa2918909a946c6b ] Kernels built with CONFIG_KASAN=y report the following BUG for rtl8192cu and rtl8192c-common: ================================================================== BUG: KASAN: slab-out-of-bounds in rtl92c_dm_bt_coexist+0x858/0x1e40 [rtl8192c_common] at addr ffff8801c90edb08 Read of size 1 by task kworker/0:1/38 page:ffffea0007243800 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0x8000000000004000(head) page dumped because: kasan: bad access detected CPU: 0 PID: 38 Comm: kworker/0:1 Not tainted 4.9.7-gentoo #3 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z77-DS3H, BIOS F11a 11/13/2013 Workqueue: rtl92c_usb rtl_watchdog_wq_callback [rtlwifi] 0000000000000000 ffffffff829eea33 ffff8801d7f0fa30 ffff8801c90edb08 ffffffff824c0f09 ffff8801d4abee80 0000000000000004 0000000000000297 ffffffffc070b57c ffff8801c7aa7c48 ffff880100000004 ffffffff000003e8 Call Trace: [] ? dump_stack+0x5c/0x79 [] ? kasan_report_error+0x4b9/0x4e0 [] ? _usb_read_sync+0x15c/0x280 [rtl_usb] [] ? __asan_report_load1_noabort+0x45/0x50 [] ? rtl92c_dm_bt_coexist+0x858/0x1e40 [rtl8192c_common] [] ? rtl92c_dm_bt_coexist+0x858/0x1e40 [rtl8192c_common] [] ? rtl92c_dm_rf_saving+0x96e/0x1330 [rtl8192c_common] ... The problem is due to rtl8192ce and rtl8192cu sharing routines, and having different layouts of struct rtl_pci_priv, which is used by rtl8192ce, and struct rtl_usb_priv, which is used by rtl8192cu. The problem was resolved by placing the struct bt_coexist_info at the head of each of those private areas. Reported-and-tested-by: Dmitry Osipenko Signed-off-by: Larry Finger Cc: Stable # 4.0+ Cc: Dmitry Osipenko Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit f59f883503b774633c1ab5e333eba77fe0e4ef39 Author: Johan Hovold Date: Thu Feb 2 17:38:35 2017 +0100 USB: serial: ftdi_sio: fix line-status over-reporting [ Upstream commit a6bb1e17a39818b01b55d8e6238b4b5f06d55038 ] FTDI devices use a receive latency timer to periodically empty the receive buffer and report modem and line status (also when the buffer is empty). When a break or error condition is detected the corresponding status flags will be set on a packet with nonzero data payload and the flags are not updated until the break is over or further characters are received. In order to avoid over-reporting break and error conditions, these flags must therefore only be processed for packets with payload. This specifically fixes the case where after an overrun, the error condition is continuously reported and NULL-characters inserted until further data is received. Reported-by: Michael Walle Fixes: 72fda3ca6fc1 ("USB: serial: ftd_sio: implement sysrq handling on break") Fixes: 166ceb690750 ("USB: ftdi_sio: clean up line-status handling") Cc: stable # v2.6.35 Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 4a34581ed0219105526685cb96e00f68cf047cc7 Author: Janosch Frank Date: Thu Feb 2 16:39:31 2017 +0100 KVM: s390: Disable dirty log retrieval for UCONTROL guests [ Upstream commit e1e8a9624f7ba8ead4f056ff558ed070e86fa747 ] User controlled KVM guests do not support the dirty log, as they have no single gmap that we can check for changes. As they have no single gmap, kvm->arch.gmap is NULL and all further referencing to it for dirty checking will result in a NULL dereference. Let's return -EINVAL if a caller tries to sync dirty logs for a UCONTROL guest. Fixes: 15f36eb ("KVM: s390: Add proper dirty bitmap support to S390 kvm.") Cc: # 3.16+ Signed-off-by: Janosch Frank Reported-by: Martin Schwidefsky Reviewed-by: Cornelia Huck Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 6631e70a42ff761ec14020d57c9a20f9d36b7a6c Author: Ken Lin Date: Sat Feb 4 04:00:24 2017 +0800 USB: serial: cp210x: add new IDs for GE Bx50v3 boards [ Upstream commit 9a593656def0dc2f6c227851e8e602077267a5f1 ] Add new USB IDs for cp2104/5 devices on Bx50v3 boards due to the design change. Signed-off-by: Ken Lin Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 31ac2f17fd856c72263a70c0a93eefdb7058b5ea Author: Ian Abbott Date: Fri Feb 3 20:25:00 2017 +0000 serial: 8250_pci: Add MKS Tenta SCOM-0800 and SCOM-0801 cards [ Upstream commit 1c9c858e2ff8ae8024a3d75d2ed080063af43754 ] The MKS Instruments SCOM-0800 and SCOM-0801 cards (originally by Tenta Technologies) are 3U CompactPCI serial cards with 4 and 8 serial ports, respectively. The first 4 ports are implemented by an OX16PCI954 chip, and the second 4 ports are implemented by an OX16C954 chip on a local bus, bridged by the second PCI function of the OX16PCI954. The ports are jumper-selectable as RS-232 and RS-422/485, and the UARTs use a non-standard oscillator frequency of 20 MHz (base_baud = 1250000). Signed-off-by: Ian Abbott Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4c47ad359cc865fb6ea8c2ab0f20875bc4d538c0 Author: Theodore Ts'o Date: Sat Feb 4 23:14:19 2017 -0500 jbd2: don't leak modified metadata buffers on an aborted journal [ Upstream commit e112666b4959b25a8552d63bc564e1059be703e8 ] If the journal has been aborted, we shouldn't mark the underlying buffer head as dirty, since that will cause the metadata block to get modified. And if the journal has been aborted, we shouldn't allow this since it will almost certainly lead to a corrupted file system. Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 2b24a836706883d7fe965dd67af801b66c825b30 Author: Julian Wiedmann Date: Mon Nov 21 13:37:48 2016 +0100 s390/qdio: clear DSCI prior to scanning multiple input queues [ Upstream commit 1e4a382fdc0ba8d1a85b758c0811de3a3631085e ] For devices with multiple input queues, tiqdio_call_inq_handlers() iterates over all input queues and clears the device's DSCI during each iteration. If the DSCI is re-armed during one of the later iterations, we therefore do not scan the previous queues again. The re-arming also raises a new adapter interrupt. But its handler does not trigger a rescan for the device, as the DSCI has already been erroneously cleared. This can result in queue stalls on devices with multiple input queues. Fix it by clearing the DSCI just once, prior to scanning the queues. As the code is moved in front of the loop, we also need to access the DSCI directly (ie irq->dsci) instead of going via each queue's parent pointer to the same irq. This is not a functional change, and a follow-up patch will clean up the other users. In practice, this bug only affects CQ-enabled HiperSockets devices, ie. devices with sysfs-attribute "hsuid" set. Setting a hsuid is needed for AF_IUCV socket applications that use HiperSockets communication. Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks") Cc: # v3.2+ Reviewed-by: Ursula Braun Signed-off-by: Julian Wiedmann Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 36e4f568b8f1196dd43f3acb3c84a88e26810404 Author: Gerald Schaefer Date: Mon Jan 30 15:52:14 2017 +0100 s390/dcssblk: fix device size calculation in dcssblk_direct_access() [ Upstream commit a63f53e34db8b49675448d03ae324f6c5bc04fe6 ] Since commit dd22f551 "block: Change direct_access calling convention", the device size calculation in dcssblk_direct_access() is off-by-one. This results in bdev_direct_access() always returning -ENXIO because the returned value is not page aligned. Fix this by adding 1 to the dev_sz calculation. Fixes: dd22f551 ("block: Change direct_access calling convention") Cc: # 4.0+ Signed-off-by: Gerald Schaefer Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 5e6ef5ef6eaf690faad3a7c6c665ebf45d7b6ccf Author: Eric W. Biederman Date: Fri Jan 20 18:28:35 2017 +1300 mnt: Tuck mounts under others instead of creating shadow/side mounts. [ Upstream commit 1064f874abc0d05eeed8993815f584d847b72486 ] Ever since mount propagation was introduced in cases where a mount in propagated to parent mount mountpoint pair that is already in use the code has placed the new mount behind the old mount in the mount hash table. This implementation detail is problematic as it allows creating arbitrary length mount hash chains. Furthermore it invalidates the constraint maintained elsewhere in the mount code that a parent mount and a mountpoint pair will have exactly one mount upon them. Making it hard to deal with and to talk about this special case in the mount code. Modify mount propagation to notice when there is already a mount at the parent mount and mountpoint where a new mount is propagating to and place that preexisting mount on top of the new mount. Modify unmount propagation to notice when a mount that is being unmounted has another mount on top of it (and no other children), and to replace the unmounted mount with the mount on top of it. Move the MNT_UMUONT test from __lookup_mnt_last into __propagate_umount as that is the only call of __lookup_mnt_last where MNT_UMOUNT may be set on any mount visible in the mount hash table. These modifications allow: - __lookup_mnt_last to be removed. - attach_shadows to be renamed __attach_mnt and its shadow handling to be removed. - commit_tree to be simplified - copy_tree to be simplified The result is an easier to understand tree of mounts that does not allow creation of arbitrary length hash chains in the mount hash table. The result is also a very slight userspace visible difference in semantics. The following two cases now behave identically, where before order mattered: case 1: (explicit user action) B is a slave of A mount something on A/a , it will propagate to B/a and than mount something on B/a case 2: (tucked mount) B is a slave of A mount something on B/a and than mount something on A/a Histroically umount A/a would fail in case 1 and succeed in case 2. Now umount A/a succeeds in both configurations. This very small change in semantics appears if anything to be a bug fix to me and my survey of userspace leads me to believe that no programs will notice or care of this subtle semantic change. v2: Updated to mnt_change_mountpoint to not call dput or mntput and instead to decrement the counts directly. It is guaranteed that there will be other references when mnt_change_mountpoint is called so this is safe. v3: Moved put_mountpoint under mount_lock in attach_recursive_mnt As the locking in fs/namespace.c changed between v2 and v3. v4: Reworked the logic in propagate_mount_busy and __propagate_umount that detects when a mount completely covers another mount. v5: Removed unnecessary tests whose result is alwasy true in find_topper and attach_recursive_mnt. v6: Document the user space visible semantic difference. Cc: stable@vger.kernel.org Fixes: b90fa9ae8f51 ("[PATCH] shared mount handling: bind and rbind") Tested-by: Andrei Vagin Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit 54195f1a32ee5ce7183e0a8000e901897773a52e Author: Maxime Ripard Date: Mon Jan 23 11:41:48 2017 +0100 rtc: sun6i: Switch to the external oscillator [ Upstream commit fb61bb82cb46a932ef2fc62e1c731c8e7e6640d5 ] The RTC is clocked from either an internal, imprecise, oscillator or an external one, which is usually much more accurate. The difference perceived between the time elapsed and the time reported by the RTC is in a 10% scale, which prevents the RTC from being useful at all. Fortunately, the external oscillator is reported to be mandatory in the Allwinner datasheet, so we can just switch to it. Cc: stable@vger.kernel.org Fixes: 9765d2d94309 ("rtc: sun6i: Add sun6i RTC driver") Signed-off-by: Maxime Ripard Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit cdb2a7f22913785ddba9aa795312318368489c7a Author: Maxime Ripard Date: Mon Jan 23 11:41:47 2017 +0100 rtc: sun6i: Add some locking [ Upstream commit a9422a19ce270a22fc520f2278fb7e80c58be508 ] Some registers have a read-modify-write access pattern that are not atomic. Add some locking to prevent from concurrent accesses. Cc: stable@vger.kernel.org Acked-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit af1af02352ee45bc0ac9eacf3fc07a259876e87a Author: Johan Hovold Date: Tue Jan 31 17:17:27 2017 +0100 USB: serial: digi_acceleport: fix OOB data sanity check [ Upstream commit 2d380889215fe20b8523345649dee0579821800c ] Make sure to check for short transfers to avoid underflow in a loop condition when parsing the receive buffer. Also fix an off-by-one error in the incomplete sanity check which could lead to invalid data being parsed. Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable # v2.6.30 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit adb1da2a98a2d0a5bfd6adf0b153cbdcde3c7c10 Author: Randy Dunlap Date: Sat Jan 7 23:08:49 2017 -0200 [media] media: fix dm1105.c build error [ Upstream commit e3bb3cddd177550d63a3e4909cf1a7782f13414d ] Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and CONFIG_DVB_DM1105=y. drivers/built-in.o: In function `dm1105_probe': dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus' Signed-off-by: Randy Dunlap Reported-by: kbuild test robot Cc: Javier Martinez Canillas Cc: stable@vger.kernel.org # applies to 4.0 (maybe even 3.x) Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c845c73b83961df44d913a18f9cfc234f2a5f883 Author: Rafał Miłecki Date: Sat Jan 28 14:31:22 2017 +0100 bcma: use (get|put)_device when probing/removing device driver [ Upstream commit a971df0b9d04674e325346c17de9a895425ca5e1 ] This allows tracking device state and e.g. makes devm work as expected. Signed-off-by: Rafał Miłecki Cc: Stable Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit e1d467993c4586d472ff777bec99cb52e1e95584 Author: Nicolas Iooss Date: Tue Dec 27 16:02:36 2016 -0200 [media] am437x-vpfe: always assign bpp variable [ Upstream commit 6ebf75774f823ddbdbd10921006989d4df222f4a ] In vpfe_s_fmt(), when the sensor format and the requested format were the same, bpp was assigned to vpfe->bpp without being initialized first. Grab the bpp value that is currently used by using __vpfe_get_format() instead of its wrapper, vpfe_try_fmt(). This use of uninitialized variable has been found by compiling the kernel with clang. Fixes: 417d2e507edc ("[media] media: platform: add VPFE capture driver support for AM437X") Cc: stable@vger.kernel.org Signed-off-by: Nicolas Iooss Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c53e17083e91a26f049836b9d192f61f5ba894b9 Author: Marc Zyngier Date: Wed Jan 25 12:29:59 2017 +0000 arm/arm64: KVM: Enforce unconditional flush to PoC when mapping to stage-2 [ Upstream commit 8f36ebaf21fdae99c091c67e8b6fab33969f2667 ] When we fault in a page, we flush it to the PoC (Point of Coherency) if the faulting vcpu has its own caches off, so that it can observe the page we just brought it. But if the vcpu has its caches on, we skip that step. Bad things happen when *another* vcpu tries to access that page with its own caches disabled. At that point, there is no garantee that the data has made it to the PoC, and we access stale data. The obvious fix is to always flush to PoC when a page is faulted in, no matter what the state of the vcpu is. Cc: stable@vger.kernel.org Fixes: 2d58b733c876 ("arm64: KVM: force cache clean on page fault when caches are off") Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 75f37dab088eb84ff25a49e59371f01ea3f44aa7 Author: Jan Kara Date: Fri Jan 27 14:34:30 2017 -0500 ext4: trim allocation requests to group size [ Upstream commit cd648b8a8fd5071d232242d5ee7ee3c0815776af ] If filesystem groups are artifically small (using parameter -g to mkfs.ext4), ext4_mb_normalize_request() can result in a request that is larger than a block group. Trim the request size to not confuse allocation code. Reported-by: "Kirill A. Shutemov" Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 07b79ed1e82cb87044869d8fd78815fdb8aef2ec Author: Alex Deucher Date: Wed Jan 25 15:33:44 2017 -0500 drm/radeon: handle vfct with multiple vbios images [ Upstream commit a882f5de402ded769af74fbf276132f9c175049c ] The vfct table can contain multiple vbios images if the platform contains multiple GPUs. Noticed by netkas on phoronix forums. This patch fixes those platforms. Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1efa8e2ac68bf25c973d874ffb3eab67d05bb1cc Author: Michel Dänzer Date: Wed Jan 25 17:21:31 2017 +0900 drm/ttm: Make sure BOs being swapped out are cacheable [ Upstream commit 239ac65fa5ffab71adf66e642750f940e7241d99 ] The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer Reviewed-by: Thomas Hellstrom Reviewed-by: Christian König . Reviewed-by: Sinclair Yeh Signed-off-by: Christian König Signed-off-by: Sasha Levin commit a99df0713f431769ee1edc478150a43f571b283c Author: Magnus Lilja Date: Wed Jan 25 22:07:59 2017 +0100 usb: gadget: udc: fsl: Add missing complete function. [ Upstream commit 5528954a1a0c49c6974ef1b8d6eaceff536204d5 ] Commit 304f7e5e1d08 ("usb: gadget: Refactor request completion") removed check if req->req.complete is non-NULL, resulting in a NULL pointer derefence and a kernel panic. This patch adds an empty complete function instead of re-introducing the req->req.complete check. Fixes: 304f7e5e1d08 ("usb: gadget: Refactor request completion") Signed-off-by: Magnus Lilja Cc: # 3.18+ Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 8c06df5655c75dadcfa5dfb48af845b108fe413e Author: Johan Hovold Date: Wed Jan 25 15:35:20 2017 +0100 USB: serial: ftdi_sio: fix extreme low-latency setting [ Upstream commit c6dce2626606ef16434802989466636bc28c1419 ] Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag") the FTDI driver has been using a receive latency-timer value of 1 ms instead of the device default of 16 ms. The latency timer is used to periodically empty a non-full receive buffer, but a status header is always sent when the timer expires including when the buffer is empty. This means that a two-byte bulk message is received every millisecond also for an otherwise idle port as long as it is open. Let's restore the pre-2009 behaviour which reduces the rate of the status messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5 Hz) by not setting ASYNC_LOW_LATENCY by default. Anyone willing to pay the price for the minimum-latency behaviour should set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool such as setserial (e.g. setserial /dev/ttyUSB0 low_latency). Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but to set a minimal latency timer. Reported-by: Antoine Aubert Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag") Cc: stable@vger.kernel.org # v2.6.31: e3e574ad85a2 Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit de143f74af3e5834ad9b725f91bafeb2cddf14c7 Author: Maciej S. Szmigiero Date: Sat Jan 21 23:50:18 2017 +0100 w1: don't leak refcount on slave attach failure in w1_attach_slave_device() [ Upstream commit d2ce4ea1a0b0162e5d2d7e7942ab6f5cc2063d5a ] Near the beginning of w1_attach_slave_device() we increment a w1 master reference count. Later, when we are going to exit this function without actually attaching a slave device (due to failure of __w1_attach_slave_device()) we need to decrement this reference count back. Signed-off-by: Maciej S. Szmigiero Cc: stable@vger.kernel.org Fixes: 9fcbbac5ded489 ("w1: process w1 netlink commands in w1_process thread") Cc: Evgeniy Polyakov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 271ce5038fbc706bb3afb6d27cde5884c5bf6288 Author: Maciej S. Szmigiero Date: Wed Jan 18 21:31:11 2017 +0100 w1: ds2490: USB transfer buffers need to be DMAable [ Upstream commit 61cd1b4cd1e8f7f7642ab64529d9bd52e8374641 ] ds2490 driver was doing USB transfers from / to buffers on a stack. This is not permitted and made the driver non-working with vmapped stacks. Since all these transfers are done under the same bus_mutex lock we can simply use shared buffers in a device private structure for two most common of them. While we are at it, let's also fix a comparison between int and size_t in ds9490r_search() which made the driver spin in this function if state register get requests were failing. Signed-off-by: Maciej S. Szmigiero Cc: stable Acked-by: Evgeniy Polyakov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 57389faf841fced8919137bb5c094f4bfc71e676 Author: Alexandre Belloni Date: Thu Jan 19 01:46:58 2017 +0100 ARM: dts: at91: Enable DMA on sama5d4_xplained console [ Upstream commit ef8d02d4a2c36f7a93e74c95a9c419353b310117 ] Enable DMA on usart3 to get a more reliable console. This is especially useful for automation and kernelci were a kernel with PROVE_LOCKING enabled is quite susceptible to character loss, resulting in tests failure. Cc: stable #v4.1+ Acked-by: Nicolas Ferre Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 61b067fb433aad18c049c8785bb3210e8a9fe12f Author: Arnd Bergmann Date: Wed Jan 11 15:53:08 2017 +0100 staging: rtl: fix possible NULL pointer dereference [ Upstream commit 6e017006022abfea5d2466cad936065f45763ad1 ] gcc-7 detects that wlanhdr_to_ethhdr() in two drivers calls memcpy() with a destination argument that an earlier function call may have set to NULL: staging/rtl8188eu/core/rtw_recv.c: In function 'wlanhdr_to_ethhdr': staging/rtl8188eu/core/rtw_recv.c:1318:2: warning: argument 1 null where non-null expected [-Wnonnull] staging/rtl8712/rtl871x_recv.c: In function 'r8712_wlanhdr_to_ethhdr': staging/rtl8712/rtl871x_recv.c:649:2: warning: argument 1 null where non-null expected [-Wnonnull] I'm fixing this by adding a NULL pointer check and returning failure from the function, which is hopefully already handled properly. This seems to date back to when the drivers were originally added, so backporting the fix to stable seems appropriate. There are other related realtek drivers in the kernel, but none of them contain a function with a similar name or produce this warning. Cc: stable@vger.kernel.org Fixes: 1cc18a22b96b ("staging: r8188eu: Add files for new driver - part 5") Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 434c09afa6c97acb22a18fe4b48ecbc18d45bba4 Author: Johan Hovold Date: Fri Jan 13 13:21:08 2017 +0100 USB: serial: opticon: fix CTS retrieval at open [ Upstream commit 2eee05020a0e7ee7c04422cbacdb07859e45dce6 ] The opticon driver used a control request at open to trigger a CTS status notification to be sent over the bulk-in pipe. When the driver was converted to using the generic read implementation, an inverted test prevented this request from being sent, something which could lead to TIOCMGET reporting an incorrect CTS state. Reported-by: Dan Carpenter Fixes: 7a6ee2b02751 ("USB: opticon: switch to generic read implementation") Cc: stable Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 700b2315c25437a3f356198ae3b2881aa0536e12 Author: Johan Hovold Date: Thu Jan 12 14:56:21 2017 +0100 USB: serial: spcp8x5: fix modem-status handling [ Upstream commit 5ed8d41023751bdd3546f2fe4118304357efe8d2 ] Make sure to detect short control transfers and return zero on success when retrieving the modem status. This fixes the TIOCMGET implementation which since e1ed212d8593 ("USB: spcp8x5: add proper modem-status support") has returned TIOCM_LE on successful retrieval, and avoids leaking bits from the stack on short transfers. This also fixes the carrier-detect implementation which since the above mentioned commit unconditionally has returned true. Fixes: e1ed212d8593 ("USB: spcp8x5: add proper modem-status support") Cc: stable Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit da3a3becb7a80003580b784ce62c8559706ff2e9 Author: Johan Hovold Date: Thu Jan 12 14:56:11 2017 +0100 USB: serial: ftdi_sio: fix modem-status error handling [ Upstream commit 427c3a95e3e29e65f59d99aaf320d7506f3eed57 ] Make sure to detect short responses when fetching the modem status in order to avoid parsing uninitialised buffer data and having bits of it leak to user space. Note that we still allow for short 1-byte responses. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 270ffbd14d811bf53ef225f15ae724f610b3d366 Author: Johan Hovold Date: Thu Jan 12 14:56:09 2017 +0100 USB: serial: ark3116: fix register-accessor error handling [ Upstream commit 9fef37d7cf170522fb354d6d0ea6de09b9b16678 ] The current implementation failed to detect short transfers, something which could lead to bits of the uninitialised heap transfer buffer leaking to user space. Fixes: 149fc791a452 ("USB: ark3116: Setup some basic infrastructure for new ark3116 driver.") Fixes: f4c1e8d597d1 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.") Cc: stable Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 131d81690f187cb294c018d3fcb27c7c7d73c22c Author: Feras Daoud Date: Wed Dec 28 14:47:23 2016 +0200 IB/ipoib: Fix deadlock between rmmod and set_mode [ Upstream commit 0a0007f28304cb9fc87809c86abb80ec71317f20 ] When calling set_mode from sys/fs, the call flow locks the sys/fs lock first and then tries to lock rtnl_lock (when calling ipoib_set_mod). On the other hand, the rmmod call flow takes the rtnl_lock first (when calling unregister_netdev) and then tries to take the sys/fs lock. Deadlock a->b, b->a. The problem starts when ipoib_set_mod frees it's rtnl_lck and tries to get it after that. set_mod: [] ? check_preempt_curr+0x6d/0x90 [] __mutex_lock_slowpath+0x13e/0x180 [] ? __rtnl_unlock+0x15/0x20 [] mutex_lock+0x2b/0x50 [] rtnl_lock+0x15/0x20 [] ipoib_set_mode+0x97/0x160 [ib_ipoib] [] set_mode+0x3b/0x80 [ib_ipoib] [] dev_attr_store+0x20/0x30 [] sysfs_write_file+0xe5/0x170 [] vfs_write+0xb8/0x1a0 [] sys_write+0x51/0x90 [] system_call_fastpath+0x16/0x1b rmmod: [] ? put_dec+0x10c/0x110 [] ? number+0x2ee/0x320 [] schedule_timeout+0x215/0x2e0 [] ? vsnprintf+0x484/0x5f0 [] ? string+0x40/0x100 [] wait_for_common+0x123/0x180 [] ? default_wake_function+0x0/0x20 [] ? ifind_fast+0x5e/0xb0 [] wait_for_completion+0x1d/0x20 [] sysfs_addrm_finish+0x228/0x270 [] sysfs_remove_dir+0xa3/0xf0 [] kobject_del+0x16/0x40 [] device_del+0x184/0x1e0 [] netdev_unregister_kobject+0xab/0xc0 [] rollback_registered+0xae/0x130 [] unregister_netdevice+0x22/0x70 [] unregister_netdev+0x1e/0x30 [] ipoib_remove_one+0xe0/0x120 [ib_ipoib] [] ib_unregister_device+0x4f/0x100 [ib_core] [] mlx4_ib_remove+0x41/0x180 [mlx4_ib] [] mlx4_remove_device+0x71/0x90 [mlx4_core] Fixes: 862096a8bbf8 ("IB/ipoib: Add more rtnl_link_ops callbacks") Cc: # v3.6+ Cc: Or Gerlitz Signed-off-by: Feras Daoud Signed-off-by: Erez Shitrit Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 24104f6ae3b472f712c8a3c9f6c83d3bffc0c230 Author: Jason Gunthorpe Date: Thu Dec 22 18:07:52 2016 -0700 RDMA/core: Fix incorrect structure packing for booleans [ Upstream commit 55efcfcd7776165b294f8b5cd6e05ca00ec89b7c ] The RDMA core uses ib_pack() to convert from unpacked CPU structs to on-the-wire bitpacked structs. This process requires that 1 bit fields are declared as u8 in the unpacked struct, otherwise the packing process does not read the value properly and the packed result is wired to 0. Several places wrongly used int. Crucially this means the kernel has never, set reversible correctly in the path record request. It has always asked for irreversible paths even if the ULP requests otherwise. When the kernel is used with a SM that supports this feature, it completely breaks communication management if reversible paths are not properly requested. The only reason this ever worked is because opensm ignores the reversible bit. Cc: stable@vger.kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jason Gunthorpe Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit fc47912f44a7b92a9f8d96255396d52d95f21c03 Author: Felix Fietkau Date: Wed Jan 11 16:32:13 2017 +0200 ath5k: drop bogus warning on drv_set_key with unsupported cipher [ Upstream commit a70e1d6fd6b5e1a81fa6171600942bee34f5128f ] Simply return -EOPNOTSUPP instead. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit c2e65cde1bd74a09716dae2338a3c6ef29d23fe7 Author: Javier Martinez Canillas Date: Mon Jan 2 11:57:20 2017 -0300 tty: serial: msm: Fix module autoload [ Upstream commit abe81f3b8ed2996e1712d26d38ff6b73f582c616 ] If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/tty/serial/msm_serial.ko | grep alias $ After this patch: $ modinfo drivers/tty/serial/msm_serial.ko | grep alias alias: of:N*T*Cqcom,msm-uartdmC* alias: of:N*T*Cqcom,msm-uartdm alias: of:N*T*Cqcom,msm-uartC* alias: of:N*T*Cqcom,msm-uart Signed-off-by: Javier Martinez Canillas Acked-by: Bjorn Andersson Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ccb2e5cdaffaf1dca3469561eecf803d9db3f173 Author: Vitaly Kuznetsov Date: Wed Dec 7 01:16:26 2016 -0800 hv: init percpu_list in hv_synic_alloc() [ Upstream commit 3c7630d35009e6635e5b58d62de554fd5b6db5df ] Initializing hv_context.percpu_list in hv_synic_alloc() helps to prevent a crash in percpu_channel_enq() when not all CPUs were online during initialization and it naturally belongs there. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Cc: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fbb6950ea08a1ad07c6d5b14f6ffd47b34ec0b55 Author: Mathias Svensson Date: Fri Jan 6 13:32:39 2017 -0800 samples/seccomp: fix 64-bit comparison macros [ Upstream commit 916cafdc95843fb9af5fd5f83ca499d75473d107 ] There were some bugs in the JNE64 and JLT64 comparision macros. This fixes them, improves comments, and cleans up the file while we are at it. Reported-by: Stephen Röttger Signed-off-by: Mathias Svensson Signed-off-by: Kees Cook Cc: stable@vger.kernel.org Signed-off-by: James Morris Signed-off-by: Sasha Levin commit 33b9ac915dba00e5dae3a7c8f3d3d28c6265385d Author: Long Li Date: Wed Dec 14 18:46:02 2016 -0800 scsi: storvsc: properly handle SRB_ERROR when sense message is present [ Upstream commit bba5dc332ec2d3a685cb4dae668c793f6a3713a3 ] When sense message is present on error, we should pass along to the upper layer to decide how to deal with the error. This patch fixes connectivity issues with Fiber Channel devices. Signed-off-by: Long Li Reviewed-by: K. Y. Srinivasan Signed-off-by: K. Y. Srinivasan Cc: Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f0cd3119dcd071f8152ee3b6f838cd7d241acd6d Author: Long Li Date: Wed Dec 14 18:46:01 2016 -0800 scsi: storvsc: use tagged SRB requests if supported by the device [ Upstream commit 3cd6d3d9b1abab8dcdf0800224ce26daac24eea2 ] Properly set SRB flags when hosting device supports tagged queuing. This patch improves the performance on Fiber Channel disks. Signed-off-by: Long Li Reviewed-by: K. Y. Srinivasan Signed-off-by: K. Y. Srinivasan Cc: Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 88e4685b51d3a8d37e5fce2afd3f4a61e6e82c73 Author: Paul Burton Date: Mon Nov 7 15:07:07 2016 +0000 MIPS: Handle microMIPS jumps in the same way as MIPS32/MIPS64 jumps [ Upstream commit 096a0de427ea333f56f0ee00328cff2a2731bcf1 ] is_jump_ins() checks for plain jump ("j") instructions since commit e7438c4b893e ("MIPS: Fix sibling call handling in get_frame_info") but that commit didn't make the same change to the microMIPS code, leaving it inconsistent with the MIPS32/MIPS64 code. Handle the microMIPS encoding of the jump instruction too such that it behaves consistently. Signed-off-by: Paul Burton Fixes: e7438c4b893e ("MIPS: Fix sibling call handling in get_frame_info") Cc: Tony Wu Cc: linux-mips@linux-mips.org Cc: # v3.10+ Patchwork: https://patchwork.linux-mips.org/patch/14533/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit a6c4b18bdb3ac5fdeaed939b1fa6c7683228c1db Author: Paul Burton Date: Mon Nov 7 15:07:06 2016 +0000 MIPS: Calculate microMIPS ra properly when unwinding the stack [ Upstream commit bb9bc4689b9c635714fbcd5d335bad9934a7ebfc ] get_frame_info() calculates the offset of the return address within a stack frame simply by dividing a the bottom 16 bits of the instruction, treated as a signed integer, by the size of a long. Whilst this works for MIPS32 & MIPS64 ISAs where the sw or sd instructions are used, it's incorrect for microMIPS where encodings differ. The result is that we typically completely fail to unwind the stack on microMIPS. Fix this by adjusting is_ra_save_ins() to calculate the return address offset, and take into account the various different encodings there in the same place as we consider whether an instruction is storing the ra/$31 register. With this we are now able to unwind the stack for kernels targetting the microMIPS ISA, for example we can produce: Call Trace: [<80109e1f>] show_stack+0x63/0x7c [<8011ea17>] __warn+0x9b/0xac [<8011ea45>] warn_slowpath_fmt+0x1d/0x20 [<8013fe53>] register_console+0x43/0x314 [<8067c58d>] of_setup_earlycon+0x1dd/0x1ec [<8067f63f>] early_init_dt_scan_chosen_stdout+0xe7/0xf8 [<8066c115>] do_early_param+0x75/0xac [<801302f9>] parse_args+0x1dd/0x308 [<8066c459>] parse_early_options+0x25/0x28 [<8066c48b>] parse_early_param+0x2f/0x38 [<8066e8cf>] setup_arch+0x113/0x488 [<8066c4f3>] start_kernel+0x57/0x328 ---[ end trace 0000000000000000 ]--- Whereas previously we only produced: Call Trace: [<80109e1f>] show_stack+0x63/0x7c ---[ end trace 0000000000000000 ]--- Signed-off-by: Paul Burton Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.") Cc: Leonid Yegoshin Cc: linux-mips@linux-mips.org Cc: # v3.10+ Patchwork: https://patchwork.linux-mips.org/patch/14532/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 339da589697a4b9ac717ebce3d458f9573cb25f1 Author: Paul Burton Date: Mon Nov 7 15:07:05 2016 +0000 MIPS: Fix is_jump_ins() handling of 16b microMIPS instructions [ Upstream commit 67c75057709a6d85c681c78b9b2f9b71191f01a2 ] is_jump_ins() checks 16b instruction fields without verifying that the instruction is indeed 16b, as is done by is_ra_save_ins() & is_sp_move_ins(). Add the appropriate check. Signed-off-by: Paul Burton Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.") Cc: Leonid Yegoshin Cc: linux-mips@linux-mips.org Cc: # v3.10+ Patchwork: https://patchwork.linux-mips.org/patch/14531/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 4556bdd21af3ecc87346b7c67b1c92b67274ef38 Author: Paul Burton Date: Mon Nov 7 15:07:04 2016 +0000 MIPS: Fix get_frame_info() handling of microMIPS function size [ Upstream commit b6c7a324df37bf05ef7a2c1580683cf10d082d97 ] get_frame_info() is meant to iterate over up to the first 128 instructions within a function, but for microMIPS kernels it will not reach that many instructions unless the function is 512 bytes long since we calculate the maximum number of instructions to check by dividing the function length by the 4 byte size of a union mips_instruction. In microMIPS kernels this won't do since instructions are variable length. Fix this by instead checking whether the pointer to the current instruction has reached the end of the function, and use max_insns as a simple constant to check the number of iterations against. Signed-off-by: Paul Burton Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.") Cc: Leonid Yegoshin Cc: linux-mips@linux-mips.org Cc: # v3.10+ Patchwork: https://patchwork.linux-mips.org/patch/14530/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 7c6a61c004ad14c3e1ff7715fa23f74acdea325a Author: Paul Burton Date: Mon Nov 7 15:07:03 2016 +0000 MIPS: Prevent unaligned accesses during stack unwinding [ Upstream commit a3552dace7d1d0cabf573e88fc3025cb90c4a601 ] During stack unwinding we call a number of functions to determine what type of instruction we're looking at. The union mips_instruction pointer provided to them may be pointing at a 2 byte, but not 4 byte, aligned address & we thus cannot directly access the 4 byte wide members of the union mips_instruction. To avoid this is_ra_save_ins() copies the required half-words of the microMIPS instruction to a correctly aligned union mips_instruction on the stack, which it can then access safely. The is_jump_ins() & is_sp_move_ins() functions do not correctly perform this temporary copy, and instead attempt to directly dereference 4 byte fields which may be misaligned and lead to an address exception. Fix this by copying the instruction halfwords to a temporary union mips_instruction in get_frame_info() such that we can provide a 4 byte aligned union mips_instruction to the is_*_ins() functions and they do not need to deal with misalignment themselves. Signed-off-by: Paul Burton Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.") Cc: Leonid Yegoshin Cc: linux-mips@linux-mips.org Cc: # v3.10+ Patchwork: https://patchwork.linux-mips.org/patch/14529/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 39fffbc9b371d0dcba51b85c9f75f677d7d28806 Author: Paul Burton Date: Mon Nov 7 15:07:02 2016 +0000 MIPS: Clear ISA bit correctly in get_frame_info() [ Upstream commit ccaf7caf2c73c6db920772bf08bf1d47b2170634 ] get_frame_info() can be called in microMIPS kernels with the ISA bit already clear. For example this happens when unwind_stack_by_address() is called because we begin with a PC that has the ISA bit set & subtract the (odd) offset from the preceding symbol (which does not have the ISA bit set). Since get_frame_info() unconditionally subtracts 1 from the PC in microMIPS kernels it incorrectly misaligns the address it then attempts to access code at, leading to an address error exception. Fix this by using msk_isa16_mode() to clear the ISA bit, which allows get_frame_info() to function regardless of whether it is provided with a PC that has the ISA bit set or not. Signed-off-by: Paul Burton Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.") Cc: Leonid Yegoshin Cc: linux-mips@linux-mips.org Cc: # v3.10+ Patchwork: https://patchwork.linux-mips.org/patch/14528/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit e9ef2a32a2ec6a9b74bbf0ce4e7f920112c2083d Author: Hans de Goede Date: Fri Dec 2 15:29:04 2016 +0100 drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating [ Upstream commit 721d484563e1a51ada760089c490cbc47e909756 ] On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. Once the i915 driver has successfully loaded, the panel can be disabled / enabled without hitting this issue. The getting stuck is caused by vlv_init_display_clock_gating() clearing the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled driving the DSI LCD by the BIOS. Clearing this bit while DSI is in use is a known issue and intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it as appropriate. This commit modifies vlv_init_display_clock_gating() to leave the DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck. Changes in v2: -Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and comment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20161202142904.25613-1-hdegoede@redhat.com Signed-off-by: Ville Syrjälä Signed-off-by: Sasha Levin