commit d7f41d3b297086cd8a263eb3c8b5dd97b7e70a32 Author: Jiri Slaby Date: Fri Jan 27 11:52:30 2017 +0100 Linux 3.12.70 commit b0369e53c851f8cd87afd059d360a4f646840c8c Author: Gu Zheng Date: Mon Jan 9 09:34:48 2017 +0800 tmpfs: clear S_ISGID when setting posix ACLs commit 497de07d89c1410d76a15bec2bb41f24a2a89f31 upstream. This change was missed the tmpfs modification in In CVE-2016-7097 commit 073931017b49 ("posix_acl: Clear SGID bit when setting file permissions") It can test by xfstest generic/375, which failed to clear setgid bit in the following test case on tmpfs: touch $testfile chown 100:100 $testfile chmod 2755 $testfile _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile Signed-off-by: Gu Zheng Signed-off-by: Al Viro Signed-off-by: Jan Kara Signed-off-by: Jiri Slaby commit ded56d6d88168cb8cb46a50456929fb5f8aae600 Author: Tariq Saeed Date: Fri Sep 4 15:44:31 2015 -0700 ocfs2: fix BUG_ON() in ocfs2_ci_checkpointed() commit 3d46a44a0c01b15d385ccaae24b56f619613c256 upstream. PID: 614 TASK: ffff882a739da580 CPU: 3 COMMAND: "ocfs2dc" #0 [ffff882ecc3759b0] machine_kexec at ffffffff8103b35d #1 [ffff882ecc375a20] crash_kexec at ffffffff810b95b5 #2 [ffff882ecc375af0] oops_end at ffffffff815091d8 #3 [ffff882ecc375b20] die at ffffffff8101868b #4 [ffff882ecc375b50] do_trap at ffffffff81508bb0 #5 [ffff882ecc375ba0] do_invalid_op at ffffffff810165e5 #6 [ffff882ecc375c40] invalid_op at ffffffff815116fb [exception RIP: ocfs2_ci_checkpointed+208] RIP: ffffffffa0a7e940 RSP: ffff882ecc375cf0 RFLAGS: 00010002 RAX: 0000000000000001 RBX: 000000000000654b RCX: ffff8812dc83f1f8 RDX: 00000000000017d9 RSI: ffff8812dc83f1f8 RDI: ffffffffa0b2c318 RBP: ffff882ecc375d20 R8: ffff882ef6ecfa60 R9: ffff88301f272200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffffffffff R13: ffff8812dc83f4f0 R14: 0000000000000000 R15: ffff8812dc83f1f8 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff882ecc375d28] ocfs2_check_meta_downconvert at ffffffffa0a7edbd [ocfs2] #8 [ffff882ecc375d38] ocfs2_unblock_lock at ffffffffa0a84af8 [ocfs2] #9 [ffff882ecc375dc8] ocfs2_process_blocked_lock at ffffffffa0a85285 [ocfs2] assert is tripped because the tran is not checkpointed and the lock level is PR. Some time ago, chmod command had been executed. As result, the following call chain left the inode cluster lock in PR state, latter on causing the assert. system_call_fastpath -> my_chmod -> sys_chmod -> sys_fchmodat -> notify_change -> ocfs2_setattr -> posix_acl_chmod -> ocfs2_iop_set_acl -> ocfs2_set_acl -> ocfs2_acl_set_mode Here is how. 1119 int ocfs2_setattr(struct dentry *dentry, struct iattr *attr) 1120 { 1247 ocfs2_inode_unlock(inode, 1); <<< WRONG thing to do. .. 1258 if (!status && attr->ia_valid & ATTR_MODE) { 1259 status = posix_acl_chmod(inode, inode->i_mode); 519 posix_acl_chmod(struct inode *inode, umode_t mode) 520 { .. 539 ret = inode->i_op->set_acl(inode, acl, ACL_TYPE_ACCESS); 287 int ocfs2_iop_set_acl(struct inode *inode, struct posix_acl *acl, ... 288 { 289 return ocfs2_set_acl(NULL, inode, NULL, type, acl, NULL, NULL); 224 int ocfs2_set_acl(handle_t *handle, 225 struct inode *inode, ... 231 { .. 252 ret = ocfs2_acl_set_mode(inode, di_bh, 253 handle, mode); 168 static int ocfs2_acl_set_mode(struct inode *inode, struct buffer_head ... 170 { 183 if (handle == NULL) { >>> BUG: inode lock not held in ex at this point <<< 184 handle = ocfs2_start_trans(OCFS2_SB(inode->i_sb), 185 OCFS2_INODE_UPDATE_CREDITS); ocfs2_setattr.#1247 we unlock and at #1259 call posix_acl_chmod. When we reach ocfs2_acl_set_mode.#181 and do trans, the inode cluster lock is not held in EX mode (it should be). How this could have happended? We are the lock master, were holding lock EX and have released it in ocfs2_setattr.#1247. Note that there are no holders of this lock at this point. Another node needs the lock in PR, and we downconvert from EX to PR. So the inode lock is PR when do the trans in ocfs2_acl_set_mode.#184. The trans stays in core (not flushed to disc). Now another node want the lock in EX, downconvert thread gets kicked (the one that tripped assert abovt), finds an unflushed trans but the lock is not EX (it is PR). If the lock was at EX, it would have flushed the trans ocfs2_ci_checkpointed -> ocfs2_start_checkpoint before downconverting (to NULL) for the request. ocfs2_setattr must not drop inode lock ex in this code path. If it does, takes it again before the trans, say in ocfs2_set_acl, another cluster node can get in between, execute another setattr, overwriting the one in progress on this node, resulting in a mode acl size combo that is a mix of the two. Orabug: 20189959 Signed-off-by: Tariq Saeed Reviewed-by: Mark Fasheh Cc: Joel Becker Cc: Joseph Qi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 05dc5c8fcbd236d4100777fe8534b290c87d644b Author: Mintz, Yuval Date: Sun Dec 4 15:30:17 2016 +0200 bnx2x: Correct ringparam estimate when DOWN commit 65870fa77fd7f83d7be4ed924d47ed9e3831f434 upstream. Until interface is up [and assuming ringparams weren't explicitly configured] when queried for the size of its rings bnx2x would claim they're the maximal size by default. That is incorrect as by default the maximal number of buffers would be equally divided between the various rx rings. This prevents the user from actually setting the number of elements on each rx ring to be of maximal size prior to transitioning the interface into up state. To fix this, make a rough estimation about the number of buffers. It wouldn't always be accurate, but it would be much better than current estimation and would allow users to increase number of buffers during early initialization of the interface. Reported-by: Seymour, Shane Signed-off-by: Yuval Mintz Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit b6580bd986df184845960c3abe490ed378ee1216 Author: Gabriel Krisman Bertazi Date: Mon Nov 28 19:34:42 2016 -0200 serial: 8250_pci: Detach low-level driver during PCI error recovery commit f209fa03fc9d131b3108c2e4936181eabab87416 upstream. During a PCI error recovery, like the ones provoked by EEH in the ppc64 platform, all IO to the device must be blocked while the recovery is completed. Current 8250_pci implementation only suspends the port instead of detaching it, which doesn't prevent incoming accesses like TIOCMGET and TIOCMSET calls from reaching the device. Those end up racing with the EEH recovery, crashing it. Similar races were also observed when opening the device and when shutting it down during recovery. This patch implements a more robust IO blockage for the 8250_pci recovery by unregistering the port at the beginning of the procedure and re-adding it afterwards. Since the port is detached from the uart layer, we can be sure that no request will make through to the device during recovery. This is similar to the solution used by the JSM serial driver. I thank Peter Hurley for valuable input on this one over one year ago. Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit a2b17a74c58b0a6ac4c7bd1c1c64f00eaadadfce Author: Wanpeng Li Date: Sun Sep 18 19:34:51 2016 +0800 x86/apic: Order irq_enter/exit() calls correctly vs. ack_APIC_irq() commit b0f48706a176b71a6e54f399d7404bbeeaa7cfab upstream. =============================== [ INFO: suspicious RCU usage. ] 4.8.0-rc6+ #5 Not tainted ------------------------------- ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 0 RCU used illegally from extended quiescent state! no locks held by swapper/2/0. stack backtrace: CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.8.0-rc6+ #5 Hardware name: Dell Inc. OptiPlex 7020/0F5C5X, BIOS A03 01/08/2015 0000000000000000 ffff8d1bd6003f10 ffffffff94446949 ffff8d1bd4a68000 0000000000000001 ffff8d1bd6003f40 ffffffff940e9247 ffff8d1bbdfcf3d0 000000000000080b 0000000000000000 0000000000000000 ffff8d1bd6003f70 Call Trace: [] dump_stack+0x99/0xd0 [] lockdep_rcu_suspicious+0xe7/0x120 [] do_trace_write_msr+0x135/0x140 [] native_write_msr+0x20/0x30 [] native_apic_msr_eoi_write+0x1d/0x30 [] smp_trace_call_function_interrupt+0x1e/0x270 [] trace_call_function_interrupt+0x96/0xa0 [] ? cpuidle_enter_state+0xe4/0x360 [] ? cpuidle_enter_state+0xcf/0x360 [] cpuidle_enter+0x17/0x20 [] cpu_startup_entry+0x338/0x4d0 [] start_secondary+0x154/0x180 This can be reproduced readily by running ftrace test case of kselftest. Move the irq_enter() call before ack_APIC_irq(), because irq_enter() tells the RCU susbstems to end the extended quiescent state, so that the following trace call in ack_APIC_irq() works correctly. The same applies to exiting_ack_irq() which calls ack_APIC_irq() after irq_exit(). [ tglx: Massaged changelog ] Signed-off-by: Wanpeng Li Cc: Peter Zijlstra Cc: Wanpeng Li Link: http://lkml.kernel.org/r/1474198491-3738-1-git-send-email-wanpeng.li@hotmail.com Signed-off-by: Thomas Gleixner Acked-by: Joerg Roedel Signed-off-by: Jiri Slaby commit 75e8aab4ba77c566a538bd85b0324ae71cc5a5ed Author: Al Viro Date: Thu Sep 11 18:55:50 2014 -0400 move the call of __d_drop(anon) into __d_materialise_unique(dentry, anon) commit 6f18493e541c690169c3b1479d47d95f624161cf upstream. and lock the right list there Signed-off-by: Al Viro Acked-by: NeilBrown Signed-off-by: Jiri Slaby commit 77eed17655f6176a74b70005a337127838057235 Author: Robert Doebbelin Date: Mon Mar 7 09:50:56 2016 +0100 fuse: do not use iocb after it may have been freed commit 7cabc61e01a0a8b663bd2b4c982aa53048218734 upstream. There's a race in fuse_direct_IO(), whereby is_sync_kiocb() is called on an iocb that could have been freed if async io has already completed. The fix in this case is simple and obvious: cache the result before starting io. It was discovered by KASan: Kernel: ================================================================== Kernel: BUG: KASan: use after free in fuse_direct_IO+0xb1a/0xcc0 at addr ffff88036c414390 Signed-off-by: Robert Doebbelin Signed-off-by: Miklos Szeredi Fixes: bcba24ccdc82 ("fuse: enable asynchronous processing direct IO") Signed-off-by: Jan Kara Signed-off-by: Jiri Slaby commit 969541196ff043df0bde0c4beae9d83185ea3d81 Author: Calvin Owens Date: Fri Oct 30 16:57:00 2015 -0700 sg: Fix double-free when drives detach during SG_IO commit f3951a3709ff50990bf3e188c27d346792103432 upstream. In sg_common_write(), we free the block request and return -ENODEV if the device is detached in the middle of the SG_IO ioctl(). Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we end up freeing rq->cmd in the already free rq object, and then free the object itself out from under the current user. This ends up corrupting random memory via the list_head on the rq object. The most common crash trace I saw is this: ------------[ cut here ]------------ kernel BUG at block/blk-core.c:1420! Call Trace: [] blk_put_request+0x5b/0x80 [] sg_finish_rem_req+0x6b/0x120 [sg] [] sg_common_write.isra.14+0x459/0x5a0 [sg] [] ? selinux_file_alloc_security+0x48/0x70 [] sg_new_write.isra.17+0x195/0x2d0 [sg] [] sg_ioctl+0x644/0xdb0 [sg] [] do_vfs_ioctl+0x90/0x520 [] ? file_has_perm+0x97/0xb0 [] SyS_ioctl+0x91/0xb0 [] tracesys+0xdd/0xe2 RIP [] __blk_put_request+0x154/0x1a0 The solution is straightforward: just set srp->rq to NULL in the failure branch so that sg_finish_rem_req() doesn't attempt to re-free it. Additionally, since sg_rq_end_io() will never be called on the object when this happens, we need to free memory backing ->cmd if it isn't embedded in the object itself. KASAN was extremely helpful in finding the root cause of this bug. Signed-off-by: Calvin Owens Acked-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Acked-by: Johannes Thumshirn Signed-off-by: Jiri Slaby commit f093600f6a9fd00fa76ad05b8276d4f56c4add78 Author: Takashi Iwai Date: Thu Nov 17 10:49:31 2016 +0100 xc2028: Fix use-after-free bug properly commit 22a1e7783e173ab3d86018eb590107d68df46c11 upstream. The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried to address the reported use-after-free by clearing the reference. However, it's clearing the wrong pointer; it sets NULL to priv->ctrl.fname, but it's anyway overwritten by the next line memcpy(&priv->ctrl, p, sizeof(priv->ctrl)). OTOH, the actual code accessing the freed string is the strcmp() call with priv->fname: if (!firmware_name[0] && p->fname && priv->fname && strcmp(p->fname, priv->fname)) free_firmware(priv); where priv->fname points to the previous file name, and this was already freed by kfree(). For fixing the bug properly, this patch does the following: - Keep the copy of firmware file name in only priv->fname, priv->ctrl.fname isn't changed; - The allocation is done only when the firmware gets loaded; - The kfree() is called in free_firmware() commonly Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free') Signed-off-by: Takashi Iwai Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit 075030bd3251283bd380b60eeecc8e4ba8778f22 Author: Omar Sandoval Date: Fri Jul 1 00:39:35 2016 -0700 block: fix use-after-free in sys_ioprio_get() commit 8ba8682107ee2ca3347354e018865d8e1967c5f4 upstream. get_task_ioprio() accesses the task->io_context without holding the task lock and thus can race with exit_io_context(), leading to a use-after-free. The reproducer below hits this within a few seconds on my 4-core QEMU VM: int main(int argc, char **argv) { pid_t pid, child; long nproc, i; /* ioprio_set(IOPRIO_WHO_PROCESS, 0, IOPRIO_PRIO_VALUE(IOPRIO_CLASS_IDLE, 0)); */ syscall(SYS_ioprio_set, 1, 0, 0x6000); nproc = sysconf(_SC_NPROCESSORS_ONLN); for (i = 0; i < nproc; i++) { pid = fork(); assert(pid != -1); if (pid == 0) { for (;;) { pid = fork(); assert(pid != -1); if (pid == 0) { _exit(0); } else { child = wait(NULL); assert(child == pid); } } } pid = fork(); assert(pid != -1); if (pid == 0) { for (;;) { /* ioprio_get(IOPRIO_WHO_PGRP, 0); */ syscall(SYS_ioprio_get, 2, 0); } } } for (;;) { /* ioprio_get(IOPRIO_WHO_PGRP, 0); */ syscall(SYS_ioprio_get, 2, 0); } return 0; } This gets us KASAN dumps like this: [ 35.526914] ================================================================== [ 35.530009] BUG: KASAN: out-of-bounds in get_task_ioprio+0x7b/0x90 at addr ffff880066f34e6c [ 35.530009] Read of size 2 by task ioprio-gpf/363 [ 35.530009] ============================================================================= [ 35.530009] BUG blkdev_ioc (Not tainted): kasan: bad access detected [ 35.530009] ----------------------------------------------------------------------------- [ 35.530009] Disabling lock debugging due to kernel taint [ 35.530009] INFO: Allocated in create_task_io_context+0x2b/0x370 age=0 cpu=0 pid=360 [ 35.530009] ___slab_alloc+0x55d/0x5a0 [ 35.530009] __slab_alloc.isra.20+0x2b/0x40 [ 35.530009] kmem_cache_alloc_node+0x84/0x200 [ 35.530009] create_task_io_context+0x2b/0x370 [ 35.530009] get_task_io_context+0x92/0xb0 [ 35.530009] copy_process.part.8+0x5029/0x5660 [ 35.530009] _do_fork+0x155/0x7e0 [ 35.530009] SyS_clone+0x19/0x20 [ 35.530009] do_syscall_64+0x195/0x3a0 [ 35.530009] return_from_SYSCALL_64+0x0/0x6a [ 35.530009] INFO: Freed in put_io_context+0xe7/0x120 age=0 cpu=0 pid=1060 [ 35.530009] __slab_free+0x27b/0x3d0 [ 35.530009] kmem_cache_free+0x1fb/0x220 [ 35.530009] put_io_context+0xe7/0x120 [ 35.530009] put_io_context_active+0x238/0x380 [ 35.530009] exit_io_context+0x66/0x80 [ 35.530009] do_exit+0x158e/0x2b90 [ 35.530009] do_group_exit+0xe5/0x2b0 [ 35.530009] SyS_exit_group+0x1d/0x20 [ 35.530009] entry_SYSCALL_64_fastpath+0x1a/0xa4 [ 35.530009] INFO: Slab 0xffffea00019bcd00 objects=20 used=4 fp=0xffff880066f34ff0 flags=0x1fffe0000004080 [ 35.530009] INFO: Object 0xffff880066f34e58 @offset=3672 fp=0x0000000000000001 [ 35.530009] ================================================================== Fix it by grabbing the task lock while we poke at the io_context. Reported-by: Dmitry Vyukov Signed-off-by: Omar Sandoval Signed-off-by: Jens Axboe Acked-by: Johannes Thumshirn Signed-off-by: Jiri Slaby commit 6f9247bccf79bf632384e70eaf04cb65481ead5a Author: Dan Carpenter Date: Wed Feb 3 13:34:00 2016 -0200 [media] xc2028: unlock on error in xc2028_set_config() commit 210bd104c6acd31c3c6b8b075b3f12d4a9f6b60d upstream. We have to unlock before returning -ENOMEM. Fixes: 8dfbcc4351a0 ('[media] xc2028: avoid use after free') Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit 74e3d04ca992bedac5080ed1a817fabf71667210 Author: Mauro Carvalho Chehab Date: Thu Jan 28 09:22:44 2016 -0200 [media] xc2028: avoid use after free commit 8dfbcc4351a0b6d2f2d77f367552f48ffefafe18 upstream. If struct xc2028_config is passed without a firmware name, the following trouble may happen: [11009.907205] xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner [11009.907491] ================================================================== [11009.907750] BUG: KASAN: use-after-free in strcmp+0x96/0xb0 at addr ffff8803bd78ab40 [11009.907992] Read of size 1 by task modprobe/28992 [11009.907994] ============================================================================= [11009.907997] BUG kmalloc-16 (Tainted: G W ): kasan: bad access detected [11009.907999] ----------------------------------------------------------------------------- [11009.908008] INFO: Allocated in xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd] age=0 cpu=3 pid=28992 [11009.908012] ___slab_alloc+0x581/0x5b0 [11009.908014] __slab_alloc+0x51/0x90 [11009.908017] __kmalloc+0x27b/0x350 [11009.908022] xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd] [11009.908026] usb_hcd_submit_urb+0x1e8/0x1c60 [11009.908029] usb_submit_urb+0xb0e/0x1200 [11009.908032] usb_serial_generic_write_start+0xb6/0x4c0 [11009.908035] usb_serial_generic_write+0x92/0xc0 [11009.908039] usb_console_write+0x38a/0x560 [11009.908045] call_console_drivers.constprop.14+0x1ee/0x2c0 [11009.908051] console_unlock+0x40d/0x900 [11009.908056] vprintk_emit+0x4b4/0x830 [11009.908061] vprintk_default+0x1f/0x30 [11009.908064] printk+0x99/0xb5 [11009.908067] kasan_report_error+0x10a/0x550 [11009.908070] __asan_report_load1_noabort+0x43/0x50 [11009.908074] INFO: Freed in xc2028_set_config+0x90/0x630 [tuner_xc2028] age=1 cpu=3 pid=28992 [11009.908077] __slab_free+0x2ec/0x460 [11009.908080] kfree+0x266/0x280 [11009.908083] xc2028_set_config+0x90/0x630 [tuner_xc2028] [11009.908086] xc2028_attach+0x310/0x8a0 [tuner_xc2028] [11009.908090] em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb] [11009.908094] em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb] [11009.908098] em28xx_dvb_init+0x81/0x8a [em28xx_dvb] [11009.908101] em28xx_register_extension+0xd9/0x190 [em28xx] [11009.908105] em28xx_dvb_register+0x10/0x1000 [em28xx_dvb] [11009.908108] do_one_initcall+0x141/0x300 [11009.908111] do_init_module+0x1d0/0x5ad [11009.908114] load_module+0x6666/0x9ba0 [11009.908117] SyS_finit_module+0x108/0x130 [11009.908120] entry_SYSCALL_64_fastpath+0x16/0x76 [11009.908123] INFO: Slab 0xffffea000ef5e280 objects=25 used=25 fp=0x (null) flags=0x2ffff8000004080 [11009.908126] INFO: Object 0xffff8803bd78ab40 @offset=2880 fp=0x0000000000000001 [11009.908130] Bytes b4 ffff8803bd78ab30: 01 00 00 00 2a 07 00 00 9d 28 00 00 01 00 00 00 ....*....(...... [11009.908133] Object ffff8803bd78ab40: 01 00 00 00 00 00 00 00 b0 1d c3 6a 00 88 ff ff ...........j.... [11009.908137] CPU: 3 PID: 28992 Comm: modprobe Tainted: G B W 4.5.0-rc1+ #43 [11009.908140] Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 [11009.908142] ffff8803bd78a000 ffff8802c273f1b8 ffffffff81932007 ffff8803c6407a80 [11009.908148] ffff8802c273f1e8 ffffffff81556759 ffff8803c6407a80 ffffea000ef5e280 [11009.908153] ffff8803bd78ab40 dffffc0000000000 ffff8802c273f210 ffffffff8155ccb4 [11009.908158] Call Trace: [11009.908162] [] dump_stack+0x4b/0x64 [11009.908165] [] print_trailer+0xf9/0x150 [11009.908168] [] object_err+0x34/0x40 [11009.908171] [] kasan_report_error+0x230/0x550 [11009.908175] [] ? trace_hardirqs_off_caller+0x21/0x290 [11009.908179] [] ? kasan_unpoison_shadow+0x36/0x50 [11009.908182] [] __asan_report_load1_noabort+0x43/0x50 [11009.908185] [] ? __asan_register_globals+0x50/0xa0 [11009.908189] [] ? strcmp+0x96/0xb0 [11009.908192] [] strcmp+0x96/0xb0 [11009.908196] [] xc2028_set_config+0x15c/0x630 [tuner_xc2028] [11009.908200] [] xc2028_attach+0x310/0x8a0 [tuner_xc2028] [11009.908203] [] ? memset+0x28/0x30 [11009.908206] [] ? xc2028_set_config+0x630/0x630 [tuner_xc2028] [11009.908211] [] em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb] [11009.908215] [] ? em28xx_dvb_init.part.3+0x37c/0x5cf4 [em28xx_dvb] [11009.908219] [] ? hauppauge_hvr930c_init+0x487/0x487 [em28xx_dvb] [11009.908222] [] ? lgdt330x_attach+0x1cc/0x370 [lgdt330x] [11009.908226] [] ? i2c_read_demod_bytes.isra.2+0x210/0x210 [lgdt330x] [11009.908230] [] ? ref_module.part.15+0x10/0x10 [11009.908233] [] ? module_assert_mutex_or_preempt+0x80/0x80 [11009.908238] [] em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb] [11009.908242] [] ? em28xx_attach_xc3028.constprop.7+0x30d/0x30d [em28xx_dvb] [11009.908245] [] ? string+0x14d/0x1f0 [11009.908249] [] ? symbol_string+0xff/0x1a0 [11009.908253] [] ? uuid_string+0x6f0/0x6f0 [11009.908257] [] ? __kernel_text_address+0x7e/0xa0 [11009.908260] [] ? print_context_stack+0x7f/0xf0 [11009.908264] [] ? __module_address+0xb6/0x360 [11009.908268] [] ? is_ftrace_trampoline+0x99/0xe0 [11009.908271] [] ? __kernel_text_address+0x7e/0xa0 [11009.908275] [] ? debug_check_no_locks_freed+0x290/0x290 [11009.908278] [] ? dump_trace+0x11b/0x300 [11009.908282] [] ? em28xx_register_extension+0x23/0x190 [em28xx] [11009.908285] [] ? trace_hardirqs_off_caller+0x21/0x290 [11009.908289] [] ? trace_hardirqs_on_caller+0x16/0x590 [11009.908292] [] ? trace_hardirqs_on+0xd/0x10 [11009.908296] [] ? em28xx_register_extension+0x23/0x190 [em28xx] [11009.908299] [] ? mutex_trylock+0x400/0x400 [11009.908302] [] ? do_one_initcall+0x131/0x300 [11009.908306] [] ? call_rcu_sched+0x17/0x20 [11009.908309] [] ? put_object+0x48/0x70 [11009.908314] [] em28xx_dvb_init+0x81/0x8a [em28xx_dvb] [11009.908317] [] em28xx_register_extension+0xd9/0x190 [em28xx] [11009.908320] [] ? 0xffffffffa0150000 [11009.908324] [] em28xx_dvb_register+0x10/0x1000 [em28xx_dvb] [11009.908327] [] do_one_initcall+0x141/0x300 [11009.908330] [] ? try_to_run_init_process+0x40/0x40 [11009.908333] [] ? trace_hardirqs_on_caller+0x16/0x590 [11009.908337] [] ? kasan_unpoison_shadow+0x36/0x50 [11009.908340] [] ? kasan_unpoison_shadow+0x36/0x50 [11009.908343] [] ? kasan_unpoison_shadow+0x36/0x50 [11009.908346] [] ? __asan_register_globals+0x87/0xa0 [11009.908350] [] do_init_module+0x1d0/0x5ad [11009.908353] [] load_module+0x6666/0x9ba0 [11009.908356] [] ? symbol_put_addr+0x50/0x50 [11009.908361] [] ? em28xx_dvb_init.part.3+0x5989/0x5cf4 [em28xx_dvb] [11009.908366] [] ? module_frob_arch_sections+0x20/0x20 [11009.908369] [] ? open_exec+0x50/0x50 [11009.908374] [] ? ns_capable+0x5b/0xd0 [11009.908377] [] SyS_finit_module+0x108/0x130 [11009.908379] [] ? SyS_init_module+0x1f0/0x1f0 [11009.908383] [] ? lockdep_sys_exit_thunk+0x12/0x14 [11009.908394] [] entry_SYSCALL_64_fastpath+0x16/0x76 [11009.908396] Memory state around the buggy address: [11009.908398] ffff8803bd78aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc [11009.908401] ffff8803bd78aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [11009.908403] >ffff8803bd78ab00: fc fc fc fc fc fc fc fc 00 00 fc fc fc fc fc fc [11009.908405] ^ [11009.908407] ffff8803bd78ab80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [11009.908409] ffff8803bd78ac00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [11009.908411] ================================================================== In order to avoid it, let's set the cached value of the firmware name to NULL after freeing it. While here, return an error if the memory allocation fails. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit 32dacf499429803e502361a3a778cbbd691d368b Author: Benjamin Poirier Date: Mon Nov 7 17:57:56 2016 +0800 bna: Add synchronization for tx ring. commit d667f78514c656a6a8bf0b3d6134a7fe5cd4d317 upstream. We received two reports of BUG_ON in bnad_txcmpl_process() where hw_consumer_index appeared to be ahead of producer_index. Out of order write/read of these variables could explain these reports. bnad_start_xmit(), as a producer of tx descriptors, has a few memory barriers sprinkled around writes to producer_index and the device's doorbell but they're not paired with anything in bnad_txcmpl_process(), a consumer. Since we are synchronizing with a device, we must use mandatory barriers, not smp_*. Also, I didn't see the purpose of the last smp_mb() in bnad_start_xmit(). Signed-off-by: Benjamin Poirier Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e4f13c5f27d6bfb2fea565d346273b0c74023ae6 Author: Vlad Tsyrklevich Date: Wed Oct 12 18:51:24 2016 +0200 vfio/pci: Fix integer overflows, bitmask check commit 05692d7005a364add85c6e25a6c4447ce08f913a upstream. The VFIO_DEVICE_SET_IRQS ioctl did not sufficiently sanitize user-supplied integers, potentially allowing memory corruption. This patch adds appropriate integer overflow checks, checks the range bounds for VFIO_IRQ_SET_DATA_NONE, and also verifies that only single element in the VFIO_IRQ_SET_DATA_TYPE_MASK bitmask is set. VFIO_IRQ_SET_ACTION_TYPE_MASK is already correctly checked later in vfio_pci_set_irqs_ioctl(). Furthermore, a kzalloc is changed to a kcalloc because the use of a kzalloc with an integer multiplication allowed an integer overflow condition to be reached without this patch. kcalloc checks for overflow and should prevent a similar occurrence. Signed-off-by: Vlad Tsyrklevich Signed-off-by: Alex Williamson Signed-off-by: Jiri Slaby commit c0b039ec2b2b861ac301f17c801669b4db4777e8 Author: Heinrich Schuchardt Date: Fri Jun 10 23:34:26 2016 +0200 apparmor: do not expose kernel stack commit f4ee2def2d70692ccff0d55353df4ee594fd0017 upstream. Do not copy uninitalized fields th.td_hilen, th.td_data. Signed-off-by: Heinrich Schuchardt Signed-off-by: John Johansen Signed-off-by: Jiri Slaby commit a5d852b9fb1394c3d8038163fcf8ee058fa697c3 Author: John Johansen Date: Wed Jun 22 18:01:08 2016 -0700 apparmor: fix module parameters can be changed after policy is locked commit 58acf9d911c8831156634a44d0b022d683e1e50c upstream. the policy_lock parameter is a one way switch that prevents policy from being further modified. Unfortunately some of the module parameters can effectively modify policy by turning off enforcement. split policy_admin_capable into a view check and a full admin check, and update the admin check to test the policy_lock parameter. Signed-off-by: John Johansen Signed-off-by: Jiri Slaby commit d035c957c895e43b78939f092c052ac6921b360d Author: John Johansen Date: Wed Jun 15 10:00:55 2016 +0300 apparmor: fix oops in profile_unpack() when policy_db is not present commit 5f20fdfed16bc599a325a145bf0123a8e1c9beea upstream. BugLink: http://bugs.launchpad.net/bugs/1592547 If unpack_dfa() returns NULL due to the dfa not being present, profile_unpack() is not checking if the dfa is not present (NULL). Signed-off-by: John Johansen Signed-off-by: Jiri Slaby commit 66bffcb518fcb98d0c6e34fc9b6d11373e696b0d Author: John Johansen Date: Wed Jun 15 09:57:55 2016 +0300 apparmor: don't check for vmalloc_addr if kvzalloc() failed commit 3197f5adf539a3ee6331f433a51483f8c842f890 upstream. Signed-off-by: John Johansen Signed-off-by: Jiri Slaby commit 1e612988489ab3ec2d2949161ebe498d29bf9940 Author: John Johansen Date: Thu Jun 2 02:37:02 2016 -0700 apparmor: add missing id bounds check on dfa verification commit 15756178c6a65b261a080e21af4766f59cafc112 upstream. Signed-off-by: John Johansen Signed-off-by: Jiri Slaby commit 7a203ea257e9e3b701344a4bc42fceddff32f915 Author: John Johansen Date: Wed Dec 16 18:09:10 2015 -0800 apparmor: fix refcount race when finding a child profile commit de7c4cc947f9f56f61520ee7edaf380434a98c8d upstream. When finding a child profile via an rcu critical section, the profile may be put and scheduled for deletion after the child is found but before its refcount is incremented. Protect against this by repeating the lookup if the profiles refcount is 0 and is one its way to deletion. Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit c49d78b41c7c1cf1b5fed3be2fa0c0eefd884c82 Author: John Johansen Date: Thu Mar 17 12:02:54 2016 -0700 apparmor: check that xindex is in trans_table bounds commit 23ca7b640b4a55f8747301b6bd984dd05545f6a7 upstream. Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit 15021f311c6d79534c5e6630f72e743306185632 Author: John Johansen Date: Wed Apr 20 14:18:18 2016 -0700 apparmor: ensure the target profile name is always audited commit f7da2de01127b58d93cebeab165136d0998e7b1a upstream. The target profile name was not being correctly audited in a few cases because the target variable was not being set and gotos passed the code to set it at apply: Since it is always based on new_profile just drop the target var and conditionally report based on new_profile. Signed-off-by: John Johansen Acked-by: Seth Arnold Acked-by: Jeff Mahoney Signed-off-by: Jiri Slaby commit 26805d78e246921666a21e37ceb721c7f0df9022 Author: John Johansen Date: Sat Apr 16 14:19:38 2016 -0700 apparmor: fix audit full profile hname on successful load commit 7ee6da25dcce27b6023a8673fdf8be98dcf7cacf upstream. Currently logging of a successful profile load only logs the basename of the profile. This can result in confusion when a child profile has the same name as the another profile in the set. Logging the hname will ensure there is no confusion. Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit 0762dc3adc6aa4a0056159afd54735ba088005be Author: John Johansen Date: Sat Apr 16 14:16:50 2016 -0700 apparmor: fix log failures for all profiles in a set commit bf15cf0c641be8e57d45f110a9d91464f5bb461a upstream. currently only the profile that is causing the failure is logged. This makes it more confusing than necessary about which profiles loaded and which didn't. So make sure to log success and failure messages for all profiles in the set being loaded. Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit 723ace24a961a97711f2461affd52a4d91fd977b Author: John Johansen Date: Sat Apr 16 13:59:02 2016 -0700 apparmor: fix put() parent ref after updating the active ref commit f351841f8d41072e741e45299070d421a5833a4a upstream. Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit d310760cc000323f0eab566f2f112819b06efc4e Author: John Johansen Date: Fri Jul 25 04:02:10 2014 -0700 apparmor: internal paths should be treated as disconnected commit bd35db8b8ca6e27fc17a9057ef78e1ddfc0de351 upstream. Internal mounts are not mounted anywhere and as such should be treated as disconnected paths. Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit 393776e08a7d128a7eda2043b313299566344ea0 Author: John Johansen Date: Fri Jul 25 04:02:08 2014 -0700 apparmor: fix disconnected bind mnts reconnection commit f2e561d190da7ff5ee265fa460e2d7f753dddfda upstream. Bind mounts can fail to be properly reconnected when PATH_CONNECT is specified. Ensure that when PATH_CONNECT is specified the path has a root. BugLink: http://bugs.launchpad.net/bugs/1319984 Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit 40c541cf20d052b3dff9f68687f68ffa5ca9fdeb Author: John Johansen Date: Fri Jul 25 04:01:56 2014 -0700 apparmor: fix update the mtime of the profile file on replacement commit d671e890205a663429da74e1972e652bea4d73ab upstream. Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit 2ee5e7afe18baa68bc8042f2ec84265d54ecbdbb Author: John Johansen Date: Fri Jul 25 04:02:03 2014 -0700 apparmor: exec should not be returning ENOENT when it denies commit 9049a7922124d843a2cd26a02b1d00a17596ec0c upstream. The current behavior is confusing as it causes exec failures to report the executable is missing instead of identifying that apparmor caused the failure. Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit 087e1f324ea2685122c6c9267ffd9cf8b474ac23 Author: John Johansen Date: Sun Jun 8 11:20:54 2014 -0700 apparmor: fix uninitialized lsm_audit member commit b6b1b81b3afba922505b57f4c812bba022f7c4a9 upstream. BugLink: http://bugs.launchpad.net/bugs/1268727 The task field in the lsm_audit struct needs to be initialized if a change_hat fails, otherwise the following oops will occur BUG: unable to handle kernel paging request at 0000002fbead7d08 IP: [] _raw_spin_lock+0xe/0x50 PGD 1e3f35067 PUD 0 Oops: 0002 [#1] SMP Modules linked in: pppox crc_ccitt p8023 p8022 psnap llc ax25 btrfs raid6_pq xor xfs libcrc32c dm_multipath scsi_dh kvm_amd dcdbas kvm microcode amd64_edac_mod joydev edac_core psmouse edac_mce_amd serio_raw k10temp sp5100_tco i2c_piix4 ipmi_si ipmi_msghandler acpi_power_meter mac_hid lp parport hid_generic usbhid hid pata_acpi mpt2sas ahci raid_class pata_atiixp bnx2 libahci scsi_transport_sas [last unloaded: tipc] CPU: 2 PID: 699 Comm: changehat_twice Tainted: GF O 3.13.0-7-generic #25-Ubuntu Hardware name: Dell Inc. PowerEdge R415/08WNM9, BIOS 1.8.6 12/06/2011 task: ffff8802135c6000 ti: ffff880212986000 task.ti: ffff880212986000 RIP: 0010:[] [] _raw_spin_lock+0xe/0x50 RSP: 0018:ffff880212987b68 EFLAGS: 00010006 RAX: 0000000000020000 RBX: 0000002fbead7500 RCX: 0000000000000000 RDX: 0000000000000292 RSI: ffff880212987ba8 RDI: 0000002fbead7d08 RBP: ffff880212987b68 R08: 0000000000000246 R09: ffff880216e572a0 R10: ffffffff815fd677 R11: ffffea0008469580 R12: ffffffff8130966f R13: ffff880212987ba8 R14: 0000002fbead7d08 R15: ffff8800d8c6b830 FS: 00002b5e6c84e7c0(0000) GS:ffff880216e40000(0000) knlGS:0000000055731700 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000002fbead7d08 CR3: 000000021270f000 CR4: 00000000000006e0 Stack: ffff880212987b98 ffffffff81075f17 ffffffff8130966f 0000000000000009 0000000000000000 0000000000000000 ffff880212987bd0 ffffffff81075f7c 0000000000000292 ffff880212987c08 ffff8800d8c6b800 0000000000000026 Call Trace: [] __lock_task_sighand+0x47/0x80 [] ? apparmor_cred_prepare+0x2f/0x50 [] do_send_sig_info+0x2c/0x80 [] send_sig_info+0x1e/0x30 [] aa_audit+0x13d/0x190 [] aa_audit_file+0xbc/0x130 [] ? apparmor_cred_prepare+0x2f/0x50 [] aa_change_hat+0x202/0x530 [] aa_setprocattr_changehat+0x116/0x1d0 [] apparmor_setprocattr+0x25d/0x300 [] security_setprocattr+0x16/0x20 [] proc_pid_attr_write+0x107/0x130 [] vfs_write+0xb4/0x1f0 [] SyS_write+0x49/0xa0 [] tracesys+0xe1/0xe6 Signed-off-by: John Johansen Acked-by: Seth Arnold Acked-by: Jeff Mahoney Signed-off-by: Jiri Slaby commit 401f89b958557ec620e3b120536c46d9586a2ae3 Author: John Johansen Date: Mon Apr 11 16:57:19 2016 -0700 apparmor: fix replacement bug that adds new child to old parent commit ec34fa24a934f4c8fd68f39b84abf34c42e5b06a upstream. When set atomic replacement is used and the parent is updated before the child, and the child did not exist in the old parent so there is no direct replacement then the new child is incorrectly added to the old parent. This results in the new parent not having the child(ren) that it should and the old parent when being destroyed asserting the following error. AppArmor: policy_destroy: internal error, policy '' still contains profiles Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit 6265dbd49067df7b38b0ed20deaee10d9dae0e1f Author: John Johansen Date: Mon Apr 11 16:55:10 2016 -0700 apparmor: fix refcount bug in profile replacement commit dcda617a0c5160c73e0aa02813c871339ea08004 upstream. Signed-off-by: John Johansen Acked-by: Seth Arnold Signed-off-by: Jiri Slaby commit f75bde091d91a839aabdd83cac9ad73e09f42429 Author: Sachin Prabhu Date: Thu Jan 26 14:28:49 2017 +0100 Fix regression which breaks DFS mounting commit d171356ff11ab1825e456dfb979755e01b3c54a1 upstream. Patch a6b5058 results in -EREMOTE returned by is_path_accessible() in cifs_mount() to be ignored which breaks DFS mounting. Signed-off-by: Sachin Prabhu Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Jiri Slaby commit a6802847d7d7f5020eed1b41121ad77b5e539a4f Author: Sachin Prabhu Date: Thu Jan 26 14:28:02 2017 +0100 Move check for prefix path to within cifs_get_root() commit 348c1bfa84dfc47da1f1234b7f2bf09fa798edea upstream. Signed-off-by: Sachin Prabhu Tested-by: Aurelien Aptel Signed-off-by: Steve French Acked-by: Aurelien Aptel Signed-off-by: Jiri Slaby commit a0ebbc68329db047bc1b9b9e263ad3e8cf16be4b Author: Sachin Prabhu Date: Thu Jan 26 14:27:27 2017 +0100 Compare prepaths when comparing superblocks commit c1d8b24d18192764fe82067ec6aa8d4c3bf094e0 upstream. The patch Fs/cifs: make share unaccessible at root level mountable makes use of prepaths when any component of the underlying path is inaccessible. When mounting 2 separate shares having different prepaths but are other wise similar in other respects, we end up sharing superblocks when we shouldn't be doing so. Signed-off-by: Sachin Prabhu Tested-by: Aurelien Aptel Signed-off-by: Steve French Acked-by: Aurelien Aptel Signed-off-by: Jiri Slaby commit d912360dac45b66faadee99ead9c1d2630409bc7 Author: Sachin Prabhu Date: Fri Jul 29 22:38:19 2016 +0100 Fix memory leaks in cifs_do_mount() commit 4214ebf4654798309364d0c678b799e402f38288 upstream. Fix memory leaks introduced by the patch Fs/cifs: make share unaccessible at root level mountable Also move allocation of cifs_sb->prepath to cifs_setup_cifs_sb(). Signed-off-by: Sachin Prabhu Tested-by: Aurelien Aptel Signed-off-by: Steve French Acked-by: Aurelien Aptel Signed-off-by: Jiri Slaby commit 4cc7ad85426a9a0607d20dc72812ba9599ede6d8 Author: Aurelien Aptel Date: Thu Jan 26 14:25:49 2017 +0100 fs/cifs: make share unaccessible at root level mountable commit a6b5058fafdf508904bbf16c29b24042cef3c496 upstream. if, when mounting //HOST/share/sub/dir/foo we can query /sub/dir/foo but not any of the path components above: - store the /sub/dir/foo prefix in the cifs super_block info - in the superblock, set root dentry to the subpath dentry (instead of the share root) - set a flag in the superblock to remember it - use prefixpath when building path from a dentry fixes bso#8950 Signed-off-by: Aurelien Aptel Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Jiri Slaby commit 669b0c45e0349c66c2621cb8b9e5d8669efe4662 Author: Benjamin Poirier Date: Mon Oct 3 10:47:50 2016 +0800 vmxnet3: Wake queue from reset work commit 277964e19e1416ca31301e113edb2580c81a8b66 upstream. vmxnet3_reset_work() expects tx queues to be stopped (via vmxnet3_quiesce_dev -> netif_tx_disable). However, this races with the netif_wake_queue() call in netif_tx_timeout() such that the driver's start_xmit routine may be called unexpectedly, triggering one of the BUG_ON in vmxnet3_map_pkt with a stack trace like this: RIP: 0010:[] vmxnet3_map_pkt+0x3ac/0x4c0 [vmxnet3] [] vmxnet3_tq_xmit+0x210/0x4e0 [vmxnet3] [] dev_hard_start_xmit+0x2e4/0x4c0 [] sch_direct_xmit+0x17e/0x1e0 [] __qdisc_run+0xd7/0x130 [] net_tx_action+0x10a/0x200 [] __do_softirq+0x11f/0x260 [] call_softirq+0x1c/0x30 [] do_softirq+0x65/0xa0 [] local_bh_enable_ip+0x99/0xa0 [] destroy_conntrack+0x96/0x110 [nf_conntrack] [] nf_conntrack_destroy+0x12/0x20 [] skb_release_head_state+0xb5/0xf0 [] skb_release_all+0x9/0x20 [] __kfree_skb+0x9/0x90 [] vmxnet3_quiesce_dev+0x209/0x340 [vmxnet3] [] vmxnet3_reset_work+0x6a/0xa0 [vmxnet3] [] process_one_work+0x16c/0x350 [] worker_thread+0x17a/0x410 [] kthread+0x96/0xa0 [] kernel_thread_helper+0x4/0x10 Signed-off-by: Benjamin Poirier Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit dfdab4c438c9621ef04bd883f81b6877678bb572 Author: Trond Myklebust Date: Thu Oct 23 19:33:14 2014 +0300 NFSv4: Ensure nfs_atomic_open set the dentry verifier on ENOENT commit 809fd143de8805970eec02c27c0bc2622a6ecbda upstream. If the OPEN rpc call to the server fails with an ENOENT call, nfs_atomic_open will create a negative dentry for that file, however it currently fails to call nfs_set_verifier(), thus causing the dentry to be immediately revalidated on the next call to nfs_lookup_revalidate() instead of following the usual lookup caching rules. Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit a88a2be387d1d8a5843826e12009c79e32fb46c8 Author: Jan Kara Date: Tue Oct 25 08:44:26 2016 -0500 posix_acl: Clear SGID bit when setting file permissions commit 073931017b49d9458aa351605b43a7e34598caef upstream. When file permissions are modified via chmod(2) and the user is not in the owning group or capable of CAP_FSETID, the setgid bit is cleared in inode_change_ok(). Setting a POSIX ACL via setxattr(2) sets the file permissions as well as the new ACL, but doesn't clear the setgid bit in a similar way; this allows to bypass the check in chmod(2). Fix that. Reviewed-by: Christoph Hellwig Reviewed-by: Jeff Layton Signed-off-by: Jan Kara Signed-off-by: Andreas Gruenbacher Signed-off-by: Jiri Slaby commit 1c4d4c690779ca67b2b8f654a5183fae69eca8d2 Author: Nicolas Iooss Date: Sat Sep 10 13:59:49 2016 -0300 ite-cir: initialize use_demodulator before using it commit 7ec03e60ef81c19b5d3a46dd070ee966774b860f upstream. Function ite_set_carrier_params() uses variable use_demodulator after having initialized it to false in some if branches, but this variable is never set to true otherwise. This bug has been found using clang -Wsometimes-uninitialized warning flag. Fixes: 620a32bba4a2 ("[media] rc: New rc-based ite-cir driver for several ITE CIRs") Signed-off-by: Nicolas Iooss Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby commit cfa2ba996d42f1afb68bbd9b84d00f7e4861c67c Author: Arnd Bergmann Date: Wed Nov 16 16:20:37 2016 +0100 ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation commit f0e8faa7a5e894b0fc99d24be1b18685a92ea466 upstream. This function clearly never worked and always returns true, as pointed out by gcc-7: arch/arm/mach-ux500/pm.c: In function 'prcmu_is_cpu_in_wfi': arch/arm/mach-ux500/pm.c:137:212: error: ?: using integer constants in boolean context, the expression will always evaluate to 'true' [-Werror=int-in-bool-context] With the added braces, the condition actually makes sense. Fixes: 34fe6f107eab ("mfd : Check if the other db8500 core is in WFI") Signed-off-by: Arnd Bergmann Acked-by: Daniel Lezcano Signed-off-by: Linus Walleij Signed-off-by: Jiri Slaby commit f38a504fcb6101f30829d3a74238137263fb2ca5 Author: Dave Martin Date: Wed Jan 18 16:25:24 2017 +0000 arm64/ptrace: Reject attempts to set incomplete hardware breakpoint fields commit ad9e202aa1ce571b1d7fed969d06f66067f8a086 upstream. We cannot preserve partial fields for hardware breakpoints, because the values written by userspace to the hardware breakpoint registers can't subsequently be recovered intact from the hardware. So, just reject attempts to write incomplete fields with -EINVAL. Fixes: 478fcb2cdb23 ("arm64: Debugging support") Signed-off-by: Dave Martin Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Jiri Slaby commit 4949014bd0112d071f794dcc64da2cd2fe5f0670 Author: Dave Martin Date: Wed Jan 18 16:25:23 2017 +0000 arm64/ptrace: Avoid uninitialised struct padding in fpr_set() commit aeb1f39d814b2e21e5e5706a48834bfd553d0059 upstream. This patch adds an explicit __reserved[] field to user_fpsimd_state to replace what was previously unnamed padding. This ensures that data in this region are propagated across assignment rather than being left possibly uninitialised at the destination. Fixes: 60ffc30d5652 ("arm64: Exception handling") Signed-off-by: Dave Martin Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Jiri Slaby commit e4b2d082683717337f2ef8243db9303f450cae3c Author: Dave Martin Date: Wed Jan 18 16:25:20 2017 +0000 arm64/ptrace: Preserve previous registers for short regset write commit 9a17b876b573441bfb3387ad55d98bf7184daf9d upstream. Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the registers, the thread's old registers are preserved. Fixes: 478fcb2cdb23 ("arm64: Debugging support") Signed-off-by: Dave Martin Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Jiri Slaby commit 983a8a1c922c603f6b5a8a4433a3cd17cd2fd83c Author: Fabien Parent Date: Tue Jan 17 13:57:42 2017 +0100 ARM: dts: da850-evm: fix read access to SPI flash commit 43849785e1079f6606a31cb7fda92d1200849728 upstream. Read access to the SPI flash are broken on da850-evm, i.e. the data read is not what is actually programmed on the flash. According to the datasheet for the M25P64 part present on the da850-evm, if the SPI frequency is higher than 20MHz then the READ command is not usable anymore and only the FAST_READ command can be used to read data. This commit specifies in the DTS that we should use FAST_READ command instead of the READ command. Tested-by: Kevin Hilman Signed-off-by: Fabien Parent [nsekhar@ti.com: subject line adjustment] Signed-off-by: Sekhar Nori Signed-off-by: Jiri Slaby Signed-off-by: Olof Johansson commit b9ac597cf8a001ac4c81f583404a0dc67eb272c7 Author: Mark Rutland Date: Fri Jan 6 13:12:47 2017 +0100 ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs commit ddc37832a1349f474c4532de381498020ed71d31 upstream. On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an undefined instruction trap within write_wb_reg. This is because Scorpion CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if the core is not powered down. When DBGPRSR.SPD is set, breakpoint and watchpoint registers are treated as undefined. It's possible to trigger similar crashes later on from userspace, by requesting the kernel to install a breakpoint or watchpoint, as we can go idle at any point between the reset of the debug registers and their later use. This has always been the case. Given that this has always been broken, no-one has complained until now, and there is no clear workaround, disable hardware breakpoints and watchpoints on Scorpion to avoid these issues. Signed-off-by: Mark Rutland Reported-by: Linus Walleij Reviewed-by: Stephen Boyd Acked-by: Will Deacon Cc: Russell King Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 0d340098985b2c0f72f12c12106b83fd1079a60f Author: Joonyoung Shim Date: Tue Jan 17 13:54:36 2017 +0900 clocksource/exynos_mct: Clear interrupt when cpu is shut down commit bc7c36eedb0c7004aa06c2afc3c5385adada8fa3 upstream. When a CPU goes offline a potentially pending timer interrupt is not cleared. When the CPU comes online again then the pending interrupt is delivered before the per cpu clockevent device is initialized. As a consequence the tick interrupt handler dereferences a NULL pointer. [ 51.251378] Unable to handle kernel NULL pointer dereference at virtual address 00000040 [ 51.289348] task: ee942d00 task.stack: ee960000 [ 51.293861] PC is at tick_periodic+0x38/0xb0 [ 51.298102] LR is at tick_handle_periodic+0x1c/0x90 Clear the pending interrupt in the cpu dying path. Fixes: 56a94f13919c ("clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier") Reported-by: Seung-Woo Kim Signed-off-by: Joonyoung Shim Cc: linux-samsung-soc@vger.kernel.org Cc: cw00.choi@samsung.com Cc: daniel.lezcano@linaro.org Cc: javier@osg.samsung.com Cc: kgene@kernel.org Cc: krzk@kernel.org Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1484628876-22065-1-git-send-email-jy0922.shim@samsung.com Signed-off-by: Thomas Gleixner Signed-off-by: Jiri Slaby commit 21162d6c411fad063291abba4905d86d67444746 Author: Alexey Klimov Date: Sun Jun 21 23:41:39 2015 +0300 clockevents/drivers/exynos_mct: Remove unneeded container_of() commit 479a932982944786269296a31682e5642f87b89a upstream. Patch removes unneeded container_of() macro in exynos4_local_timer_setup(). Instead let's pass mevt pointer to setup and stop functions from exynos4_mct_cpu_notify() and let them get evt pointer. Tested on odroid-xu3. Signed-off-by: Alexey Klimov Acked-by: Stephen Boyd Signed-off-by: Daniel Lezcano Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jiri Slaby commit 4b878ede8ac4265b643e3732d841d97a9dcc0d75 Author: Richard Weinberger Date: Tue Jan 10 11:49:40 2017 +0100 ubifs: Fix journal replay wrt. xattr nodes commit 1cb51a15b576ee325d527726afff40947218fd5e upstream. When replaying the journal it can happen that a journal entry points to a garbage collected node. This is the case when a power-cut occurred between a garbage collect run and a commit. In such a case nodes have to be read using the failable read functions to detect whether the found node matches what we expect. One corner case was forgotten, when the journal contains an entry to remove an inode all xattrs have to be removed too. UBIFS models xattr like directory entries, so the TNC code iterates over all xattrs of the inode and removes them too. This code re-uses the functions for walking directories and calls ubifs_tnc_next_ent(). ubifs_tnc_next_ent() expects to be used only after the journal and aborts when a node does not match the expected result. This behavior can render an UBIFS volume unmountable after a power-cut when xattrs are used. Fix this issue by using failable read functions in ubifs_tnc_next_ent() too when replaying the journal. Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system") Reported-by: Rock Lee Reviewed-by: David Gstir Signed-off-by: Richard Weinberger Signed-off-by: Jiri Slaby commit e4edff0727b3b73dbed4724803f37b0810559d97 Author: Quinn Tran Date: Fri Dec 23 18:06:10 2016 -0800 qla2xxx: Fix crash due to null pointer access commit fc1ffd6cb38a1c1af625b9833c41928039e733f5 upstream. During code inspection, while investigating following stack trace seen on one of the test setup, we found out there was possibility of memory leak becuase driver was not unwinding the stack properly. This issue has not been reproduced in a test environment or on a customer setup. Here's stack trace that was seen. [1469877.797315] Call Trace: [1469877.799940] [] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx] [1469877.806980] [] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx] [1469877.814013] [] ? __pm_runtime_resume+0x51/0xa0 [1469877.820265] [] ? _raw_spin_lock_irqsave+0x25/0x90 [1469877.826776] [] ? _raw_spin_unlock_irqrestore+0x6d/0x80 [1469877.833720] [] ? preempt_count_sub+0xb1/0x100 [1469877.839885] [] ? _raw_spin_unlock_irqrestore+0x4c/0x80 [1469877.846830] [] local_pci_probe+0x4c/0xb0 [1469877.852562] [] ? preempt_count_sub+0xb1/0x100 [1469877.858727] [] pci_call_probe+0x89/0xb0 Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Reviewed-by: Christoph Hellwig [ bvanassche: Fixed spelling in patch description ] Signed-off-by: Bart Van Assche Signed-off-by: Jiri Slaby commit e0f8759e9a8854f16698d51eb68808cda1e592a5 Author: Hauke Mehrtens Date: Mon Dec 5 22:14:36 2016 +0100 mtd: nand: xway: disable module support commit 73529c872a189c747bdb528ce9b85b67b0e28dec upstream. The xway_nand driver accesses the ltq_ebu_membase symbol which is not exported. This also should not get exported and we should handle the EBU interface in a better way later. This quick fix just deactivated support for building as module. Fixes: 99f2b107924c ("mtd: lantiq: Add NAND support on Lantiq XWAY SoC.") Signed-off-by: Hauke Mehrtens Signed-off-by: Boris Brezillon Signed-off-by: Jiri Slaby commit b3b4bf27401b086475bbcd330e49dfe6db3c7428 Author: Stefan Wahren Date: Thu Jan 5 19:24:04 2017 +0000 mmc: mxs-mmc: Fix additional cycles after transmission stop commit 01167c7b9cbf099c69fe411a228e4e9c7104e123 upstream. According to the code the intention is to append 8 SCK cycles instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this will never happened because it's an AC command not an ADTC command. So fix this by moving the statement into the right function. Signed-off-by: Stefan Wahren Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28) Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit 4eaca542eba07e97108fb8dc13c7f6ea3988f273 Author: J. Bruce Fields Date: Mon Jan 9 17:15:18 2017 -0500 svcrpc: don't leak contexts on PROC_DESTROY commit 78794d1890708cf94e3961261e52dcec2cc34722 upstream. Context expiry times are in units of seconds since boot, not unix time. The use of get_seconds() here therefore sets the expiry time decades in the future. This prevents timely freeing of contexts destroyed by client RPC_GSS_PROC_DESTROY requests. We'd still free them eventually (when the module is unloaded or the container shut down), but a lot of contexts could pile up before then. Fixes: c5b29f885afe "sunrpc: use seconds since boot in expiry cache" Reported-by: Andy Adamson Signed-off-by: J. Bruce Fields Signed-off-by: Jiri Slaby commit 40cc82ffb5a93629dd85ed29b8653e470acdd320 Author: Bjorn Helgaas Date: Wed Dec 28 14:55:16 2016 -0600 x86/PCI: Ignore _CRS on Supermicro X8DTH-i/6/iF/6F commit 89e9f7bcd8744ea25fcf0ac671b8d72c10d7d790 upstream. Martin reported that the Supermicro X8DTH-i/6/iF/6F advertises incorrect host bridge windows via _CRS: pci_root PNP0A08:00: host bridge window [io 0xf000-0xffff] pci_root PNP0A08:01: host bridge window [io 0xf000-0xffff] Both bridges advertise the 0xf000-0xffff window, which cannot be correct. Work around this by ignoring _CRS on this system. The downside is that we may not assign resources correctly to hot-added PCI devices (if they are possible on this system). Link: https://bugzilla.kernel.org/show_bug.cgi?id=42606 Reported-by: Martin Burnicki Signed-off-by: Bjorn Helgaas Signed-off-by: Jiri Slaby commit ad6d6b82e6e37a37ffd48107f891fd70b823d68b Author: Vladimir Zapolskiy Date: Thu Nov 17 03:30:51 2016 +0200 ARM: dts: imx31: fix AVIC base address commit af92305e567b7f4c9cf48b9e46c1f48ec9ffb1fb upstream. On i.MX31 AVIC interrupt controller base address is at 0x68000000. The problem was shadowed by the AVIC driver, which takes the correct base address from a SoC specific header file. Fixes: d2a37b3d91f4 ("ARM i.MX31: Add devicetree support") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Jiri Slaby commit 8e449442c0300cb92df149d01515a11cc5ff08d6 Author: Vladimir Zapolskiy Date: Mon Sep 26 03:03:41 2016 +0300 ARM: dts: imx31: move CCM device node to AIPS2 bus devices commit 1f87aee6a2e55eda466a43ba6248a8b75eede153 upstream. i.MX31 Clock Control Module controller is found on AIPS2 bus, move it there from SPBA bus to avoid a conflict of device IO space mismatch. Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup") Signed-off-by: Vladimir Zapolskiy Acked-by: Uwe Kleine-König Signed-off-by: Shawn Guo Signed-off-by: Jiri Slaby commit ddb9955c54dc9ea29a8e68ccdbb5f4705220e946 Author: Vladimir Zapolskiy Date: Mon Sep 26 03:03:40 2016 +0300 ARM: dts: imx31: fix clock control module interrupts description commit 2e575cbc930901718cc18e084566ecbb9a4b5ebb upstream. The type of AVIC interrupt controller found on i.MX31 is one-cell, namely 31 for CCM DVFS and 53 for CCM, however for clock control module its interrupts are specified as 3-cells, fix it. Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup") Acked-by: Rob Herring Signed-off-by: Vladimir Zapolskiy Signed-off-by: Shawn Guo Signed-off-by: Jiri Slaby commit c7e64090ce1d71abb221933068eba676ceeb8cbd Author: Arnaldo Carvalho de Melo Date: Tue Oct 25 17:20:47 2016 -0300 perf scripting: Avoid leaking the scripting_context variable commit cf346d5bd4b9d61656df2f72565c9b354ef3ca0d upstream. Both register_perl_scripting() and register_python_scripting() allocate this variable, fix it by checking if it already was. Cc: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Tom Zanussi Cc: Wang Nan Fixes: 7e4b21b84c43 ("perf/scripts: Add Python scripting engine") Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Jiri Slaby commit b1a317d4dc67b758131638649565be133d8de0c5 Author: Saeed Mahameed Date: Thu Nov 10 11:30:59 2016 +0200 IB/mlx4: Fix port query for 56Gb Ethernet links commit 6fa26208206c406fa529cd73f7ae6bf4181e270b upstream. Report the correct speed in the port attributes when using a 56Gbps ethernet link. Without this change the field is incorrectly set to 10. Fixes: a9c766bb75ee ('IB/mlx4: Fix info returned when querying IBoE ports') Fixes: 2e96691c31ec ('IB: Use central enum for speed instead of hard-coded values') Signed-off-by: Saeed Mahameed Signed-off-by: Yishai Hadas Signed-off-by: Daniel Jurgens Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit d1e2a609ac560496e87cef720b6e08b55cd097aa Author: Maor Gottlieb Date: Thu Nov 10 11:30:53 2016 +0200 IB/mlx4: Set traffic class in AH commit af4295c117b82a521b05d0daf39ce879d26e6cb1 upstream. Set traffic class within sl_tclass_flowlabel when create iboe AH. Without this the TOS value will be empty when running VLAN tagged traffic, because the TOS value is taken from the traffic class in the address handle attributes. Fixes: 9106c4106974 ('IB/mlx4: Fix SL to 802.1Q priority-bits mapping for IBoE') Signed-off-by: Maor Gottlieb Signed-off-by: Daniel Jurgens Reviewed-by: Mark Bloch Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit d97df932a195d603c6beb827eb358eaf8728987d Author: Mark Rutland Date: Mon Jan 23 18:23:08 2017 +0000 arm64: avoid returning from bad_mode commit 7d9e8f71b989230bc613d121ca38507d34ada849 upstream. Generally, taking an unexpected exception should be a fatal event, and bad_mode is intended to cater for this. However, it should be possible to contain unexpected synchronous exceptions from EL0 without bringing the kernel down, by sending a SIGILL to the task. We tried to apply this approach in commit 9955ac47f4ba1c95 ("arm64: don't kill the kernel on a bad esr from el0"), by sending a signal for any bad_mode call resulting from an EL0 exception. However, this also applies to other unexpected exceptions, such as SError and FIQ. The entry paths for these exceptions branch to bad_mode without configuring the link register, and have no kernel_exit. Thus, if we take one of these exceptions from EL0, bad_mode will eventually return to the original user link register value. This patch fixes this by introducing a new bad_el0_sync handler to cater for the recoverable case, and restoring bad_mode to its original state, whereby it calls panic() and never returns. The recoverable case branches to bad_el0_sync with a bl, and returns to userspace via the usual ret_to_user mechanism. Signed-off-by: Mark Rutland Fixes: 9955ac47f4ba1c95 ("arm64: don't kill the kernel on a bad esr from el0") Reported-by: Mark Salter Cc: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Jiri Slaby commit 42bd73cd447350f2f32d95f57bceb06ad90b3158 Author: Niklas Söderlund Date: Sat Nov 12 17:04:24 2016 +0100 pinctrl: sh-pfc: Do not unconditionally support PIN_CONFIG_BIAS_DISABLE commit 5d7400c4acbf7fe633a976a89ee845f7333de3e4 upstream. Always stating PIN_CONFIG_BIAS_DISABLE is supported gives untrue output when examining /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins if the operation get_bias() is implemented but the pin is not handled by the get_bias() implementation. In that case the output will state that "input bias disabled" indicating that this pin has bias control support. Make support for PIN_CONFIG_BIAS_DISABLE depend on that the pin either supports SH_PFC_PIN_CFG_PULL_UP or SH_PFC_PIN_CFG_PULL_DOWN. This also solves the issue where SoC specific implementations print error messages if their particular implementation of {set,get}_bias() is called with a pin it does not know about. Signed-off-by: Niklas Söderlund Acked-by: Laurent Pinchart Signed-off-by: Geert Uytterhoeven Signed-off-by: Jiri Slaby commit cffd4016550a3612b0534974e4bfebc303d48815 Author: Johan Hovold Date: Tue Nov 1 16:26:00 2016 +0100 powerpc/ibmebus: Fix device reference leaks in sysfs interface commit fe0f3168169f7c34c29b0cf0c489f126a7f29643 upstream. Make sure to drop any reference taken by bus_find_device() in the sysfs callbacks that are used to create and destroy devices based on device-tree entries. Fixes: 6bccf755ff53 ("[POWERPC] ibmebus: dynamic addition/removal of adapters, some code cleanup") Signed-off-by: Johan Hovold Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby commit 813179d9b188d8ca37b5613bee9fee7fec7f5761 Author: Johan Hovold Date: Tue Nov 1 16:26:01 2016 +0100 powerpc/ibmebus: Fix further device reference leaks commit 815a7141c4d1b11610dccb7fcbb38633759824f2 upstream. Make sure to drop any reference taken by bus_find_device() when creating devices during init and driver registration. Fixes: 55347cc9962f ("[POWERPC] ibmebus: Add device creation and bus probing based on of_device") Signed-off-by: Johan Hovold Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby commit 0ae4deb7c85d0991b5dad3d4dac2a0cbd8aba830 Author: NeilBrown Date: Mon Dec 19 11:19:31 2016 +1100 NFSv4.1: nfs4_fl_prepare_ds must be careful about reporting success. commit cfd278c280f997cf2fe4662e0acab0fe465f637b upstream. Various places assume that if nfs4_fl_prepare_ds() turns a non-NULL 'ds', then ds->ds_clp will also be non-NULL. This is not necessasrily true in the case when the process received a fatal signal while nfs4_pnfs_ds_connect is waiting in nfs4_wait_ds_connect(). In that case ->ds_clp may not be set, and the devid may not recently have been marked unavailable. So add a test for ds_clp == NULL and return NULL in that case. Fixes: c23266d532b4 ("NFS4.1 Fix data server connection race") Signed-off-by: NeilBrown Acked-by: Olga Kornievskaia Acked-by: Adamson, Andy Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit c65fddff2fb7c68760ca5806389bda3b9dcbebe0 Author: Lukasz Odzioba Date: Wed Dec 28 14:55:40 2016 +0100 x86/cpu: Fix bootup crashes by sanitizing the argument of the 'clearcpuid=' command-line option commit dd853fd216d1485ed3045ff772079cc8689a9a4a upstream. A negative number can be specified in the cmdline which will be used as setup_clear_cpu_cap() argument. With that we can clear/set some bit in memory predceeding boot_cpu_data/cpu_caps_cleared which may cause kernel to misbehave. This patch adds lower bound check to setup_disablecpuid(). Boris Petkov reproduced a crash: [ 1.234575] BUG: unable to handle kernel paging request at ffffffff858bd540 [ 1.236535] IP: memcpy_erms+0x6/0x10 Signed-off-by: Lukasz Odzioba Acked-by: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: andi.kleen@intel.com Cc: bp@alien8.de Cc: dave.hansen@linux.intel.com Cc: luto@kernel.org Cc: slaoub@gmail.com Fixes: ac72e7888a61 ("x86: add generic clearcpuid=... option") Link: http://lkml.kernel.org/r/1482933340-11857-1-git-send-email-lukasz.odzioba@intel.com Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit d352d031c8a1fbc38bc4eb640802e4353becb345 Author: Johan Hovold Date: Fri Jan 6 19:15:12 2017 +0100 USB: serial: ch341: fix modem-control and B0 handling commit 030ee7ae52a46a2be52ccc8242c4a330aba8d38e upstream. The modem-control signals are managed by the tty-layer during open and should not be asserted prematurely when set_termios is called from driver open. Also make sure that the signals are asserted only when changing speed from B0. Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 842996d1baa2a5fc9f961396e78e47e57a69f533 Author: Johan Hovold Date: Fri Jan 6 19:15:14 2017 +0100 USB: serial: ch341: fix resume after reset commit ce5e292828117d1b71cbd3edf9e9137cf31acd30 upstream. Fix reset-resume handling which failed to resubmit the read and interrupt URBs, thereby leaving a port that was open before suspend in a broken state until closed and reopened. Fixes: 1ded7ea47b88 ("USB: ch341 serial: fix port number changed after resume") Fixes: 2bfd1c96a9fb ("USB: serial: ch341: remove reset_resume callback") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit dcf586e94d7c5aaffbcd7004cbb267fdfac9904c Author: Alex Deucher Date: Thu Jan 5 12:39:01 2017 -0500 drm/radeon: drop verde dpm quirks commit 8a08403bcb39f5d0e733bcf59a8a74f16b538f6e upstream. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98897 https://bugs.launchpad.net/bugs/1651981 Acked-by: Edward O'Callaghan Signed-off-by: Alex Deucher Cc: Adrian Fiergolski Signed-off-by: Jiri Slaby commit baa7295e1d686a443c0c23156b0bc9058d783aa4 Author: Zhou Chengming Date: Fri Jan 6 09:32:32 2017 +0800 sysctl: Drop reference added by grab_header in proc_sys_readdir commit 93362fa47fe98b62e4a34ab408c4a418432e7939 upstream. Fixes CVE-2016-9191, proc_sys_readdir doesn't drop reference added by grab_header when return from !dir_emit_dots path. It can cause any path called unregister_sysctl_table will wait forever. The calltrace of CVE-2016-9191: [ 5535.960522] Call Trace: [ 5535.963265] [] schedule+0x3f/0xa0 [ 5535.968817] [] schedule_timeout+0x3db/0x6f0 [ 5535.975346] [] ? wait_for_completion+0x45/0x130 [ 5535.982256] [] wait_for_completion+0xc3/0x130 [ 5535.988972] [] ? wake_up_q+0x80/0x80 [ 5535.994804] [] drop_sysctl_table+0xc4/0xe0 [ 5536.001227] [] drop_sysctl_table+0x77/0xe0 [ 5536.007648] [] unregister_sysctl_table+0x4d/0xa0 [ 5536.014654] [] unregister_sysctl_table+0x7f/0xa0 [ 5536.021657] [] unregister_sched_domain_sysctl+0x15/0x40 [ 5536.029344] [] partition_sched_domains+0x44/0x450 [ 5536.036447] [] ? __mutex_unlock_slowpath+0x111/0x1f0 [ 5536.043844] [] rebuild_sched_domains_locked+0x64/0xb0 [ 5536.051336] [] update_flag+0x11d/0x210 [ 5536.057373] [] ? mutex_lock_nested+0x2df/0x450 [ 5536.064186] [] ? cpuset_css_offline+0x1b/0x60 [ 5536.070899] [] ? trace_hardirqs_on+0xd/0x10 [ 5536.077420] [] ? mutex_lock_nested+0x2df/0x450 [ 5536.084234] [] ? css_killed_work_fn+0x25/0x220 [ 5536.091049] [] cpuset_css_offline+0x35/0x60 [ 5536.097571] [] css_killed_work_fn+0x5c/0x220 [ 5536.104207] [] process_one_work+0x1df/0x710 [ 5536.110736] [] ? process_one_work+0x160/0x710 [ 5536.117461] [] worker_thread+0x12b/0x4a0 [ 5536.123697] [] ? process_one_work+0x710/0x710 [ 5536.130426] [] kthread+0xfe/0x120 [ 5536.135991] [] ret_from_fork+0x1f/0x40 [ 5536.142041] [] ? kthread_create_on_node+0x230/0x230 One cgroup maintainer mentioned that "cgroup is trying to offline a cpuset css, which takes place under cgroup_mutex. The offlining ends up trying to drain active usages of a sysctl table which apprently is not happening." The real reason is that proc_sys_readdir doesn't drop reference added by grab_header when return from !dir_emit_dots path. So this cpuset offline path will wait here forever. See here for details: http://www.openwall.com/lists/oss-security/2016/11/04/13 Fixes: f0c3b5093add ("[readdir] convert procfs") Reported-by: CAI Qian Tested-by: Yang Shukui Signed-off-by: Zhou Chengming Acked-by: Al Viro Signed-off-by: Eric W. Biederman Signed-off-by: Jiri Slaby commit 7ba4dcddd51c419828a2477e9dc2dff9d32550fe Author: Akinobu Mita Date: Fri Jan 6 02:14:16 2017 +0900 sysrq: attach sysrq handler correctly for 32-bit kernel commit 802c03881f29844af0252b6e22be5d2f65f93fd0 upstream. The sysrq input handler should be attached to the input device which has a left alt key. On 32-bit kernels, some input devices which has a left alt key cannot attach sysrq handler. Because the keybit bitmap in struct input_device_id for sysrq is not correctly initialized. KEY_LEFTALT is 56 which is greater than BITS_PER_LONG on 32-bit kernels. I found this problem when using a matrix keypad device which defines a KEY_LEFTALT (56) but doesn't have a KEY_O (24 == 56%32). Cc: Jiri Slaby Signed-off-by: Akinobu Mita Acked-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 955f82ec9a0a251ed1ebe16ce0efd564337ce439 Author: Augusto Mecking Caringi Date: Tue Jan 10 10:45:00 2017 +0000 vme: Fix wrong pointer utilization in ca91cx42_slave_get commit c8a6a09c1c617402cc9254b2bc8da359a0347d75 upstream. In ca91cx42_slave_get function, the value pointed by vme_base pointer is set through: *vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]); So it must be dereferenced to be used in calculation of pci_base: *pci_base = (dma_addr_t)*vme_base + pci_offset; This bug was caught thanks to the following gcc warning: drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’: drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] *pci_base = (dma_addr_t)vme_base + pci_offset; Signed-off-by: Augusto Mecking Caringi Acked-By: Martyn Welch Signed-off-by: Jiri Slaby commit be9ab8202e194fbc6b066b7e2dbabccd9d74a362 Author: Mathias Nyman Date: Wed Jan 11 17:10:34 2017 +0200 xhci: fix deadlock at host remove by running watchdog correctly commit d6169d04097fd9ddf811e63eae4e5cd71e6666e2 upstream. If a URB is killed while the host is removed we can end up in a situation where the hub thread takes the roothub device lock, and waits for the URB to be given back by xhci-hcd, blocking the host remove code. xhci-hcd tries to stop the endpoint and give back the urb, but can't as the host is removed from PCI bus at the same time, preventing the normal way of giving back urb. Instead we need to rely on the stop command timeout function to give back the urb. This xhci_stop_endpoint_command_watchdog() timeout function used a XHCI_STATE_DYING flag to indicate if the timeout function is already running, but later this flag has been taking into use in other places to mark that xhci is dying. Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still checking that reading from pci state does not return 0xffffffff or that host is not halted before trying to stop the endpoint. This whole area of stopping endpoints, giving back URBs, and the wathdog timeout need rework, this fix focuses on solving a specific deadlock issue that we can then send to stable before any major rework. Signed-off-by: Mathias Nyman Signed-off-by: Jiri Slaby commit 142088b084b05f9cfe68ee3e433e738016e3c0e5 Author: Vlad Tsyrklevich Date: Mon Jan 9 22:53:36 2017 +0700 i2c: fix kernel memory disclosure in dev interface commit 30f939feaeee23e21391cfc7b484f012eb189c3c upstream. i2c_smbus_xfer() does not always fill an entire block, allowing kernel stack memory disclosure through the temp variable. Clear it before it's read to. Signed-off-by: Vlad Tsyrklevich Signed-off-by: Wolfram Sang Signed-off-by: Jiri Slaby commit f52a119f6cfaa3b2ac0812459326e768c6076846 Author: Johan Hovold Date: Fri Jan 6 19:15:11 2017 +0100 USB: serial: ch341: fix open and resume after B0 commit a20047f36e2f6a1eea4f1fd261aaa55882369868 upstream. The private baud_rate variable is used to configure the port at open and reset-resume and must never be set to (and left at) zero or reset-resume and all further open attempts will fail. Fixes: aa91def41a7b ("USB: ch341: set tty baud speed according to tty struct") Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 53cffccdc39a62a2cd434bb77b7457218286ebd6 Author: Johan Hovold Date: Fri Jan 6 19:15:18 2017 +0100 USB: serial: ch341: fix control-message error handling commit 2d5a9c72d0c4ac73cf97f4b7814ed6c44b1e49ae upstream. A short control transfer would currently fail to be detected, something which could lead to stale buffer data being used as valid input. Check for short transfers, and make sure to log any transfer errors. Note that this also avoids leaking heap data to user space (TIOCMGET) and the remote device (break control). Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit e430ae1fab3c35e53da957e7f3a5076349fbc914 Author: Johan Hovold Date: Fri Jan 6 19:15:13 2017 +0100 USB: serial: ch341: fix open error handling commit f2950b78547ffb8475297ada6b92bc2d774d5461 upstream. Make sure to stop the interrupt URB before returning on errors during open. Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 08d5a8b6026ec70aba1c14259015836d70d94607 Author: Johan Hovold Date: Fri Jan 6 19:15:10 2017 +0100 USB: serial: ch341: fix initial modem-control state commit 4e2da44691cffbfffb1535f478d19bc2dca3e62b upstream. DTR and RTS will be asserted by the tty-layer when the port is opened and deasserted on close (if HUPCL is set). Make sure the initial state is not-asserted before the port is first opened as well. Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 9ed06d4fa06cce8f37637771000f0eded3a6d572 Author: Johan Hovold Date: Tue Jan 10 12:05:37 2017 +0100 USB: serial: kl5kusb105: fix line-state error handling commit 146cc8a17a3b4996f6805ee5c080e7101277c410 upstream. The current implementation failed to detect short transfers when attempting to read the line state, and also, to make things worse, logged the content of the uninitialised heap transfer buffer. Fixes: abf492e7b3ae ("USB: kl5kusb105: fix DMA buffers on stack") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 544a81ed7dc176f400e2272595ac02f2791385a8 Author: Steve Rutherford Date: Wed Jan 11 18:28:29 2017 -0800 KVM: x86: Introduce segmented_write_std commit 129a72a0d3c8e139a04512325384fe5ac119e74d upstream. Introduces segemented_write_std. Switches from emulated reads/writes to standard read/writes in fxsave, fxrstor, sgdt, and sidt. This fixes CVE-2017-2584, a longstanding kernel memory leak. Since commit 283c95d0e389 ("KVM: x86: emulate FXSAVE and FXRSTOR", 2016-11-09), which is luckily not yet in any final release, this would also be an exploitable kernel memory *write*! Reported-by: Dmitry Vyukov Fixes: 96051572c819194c37a8367624b285be10297eca Fixes: 283c95d0e3891b64087706b344a4b545d04a6e62 Suggested-by: Paolo Bonzini Signed-off-by: Steve Rutherford Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit b408606454167a38230a04c2fa66a93b49575ff3 Author: David Matlack Date: Fri Dec 16 14:30:36 2016 -0800 KVM: x86: flush pending lapic jump label updates on module unload commit cef84c302fe051744b983a92764d3fcca933415d upstream. KVM's lapic emulation uses static_key_deferred (apic_{hw,sw}_disabled). These are implemented with delayed_work structs which can still be pending when the KVM module is unloaded. We've seen this cause kernel panics when the kvm_intel module is quickly reloaded. Use the new static_key_deferred_flush() API to flush pending updates on module unload. Signed-off-by: David Matlack Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit a53623a647f19f179111002de01df3d67bf0d499 Author: David Matlack Date: Fri Dec 16 14:30:35 2016 -0800 jump_labels: API for flushing deferred jump label updates commit b6416e61012429e0277bd15a229222fd17afc1c1 upstream. Modules that use static_key_deferred need a way to synchronize with any delayed work that is still pending when the module is unloaded. Introduce static_key_deferred_flush() which flushes any pending jump label updates. [js] no STATIC_KEY_CHECK_USE in 3.12 -> remove it Signed-off-by: David Matlack Acked-by: Peter Zijlstra (Intel) Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit f043f20c055e3485fb82e0955a9f94f50cdffe15 Author: Paolo Bonzini Date: Thu Jan 12 15:02:32 2017 +0100 KVM: x86: fix emulation of "MOV SS, null selector" commit 33ab91103b3415e12457e3104f0e4517ce12d0f3 upstream. This is CVE-2017-2583. On Intel this causes a failed vmentry because SS's type is neither 3 nor 7 (even though the manual says this check is only done for usable SS, and the dmesg splat says that SS is unusable!). On AMD it's worse: svm.c is confused and sets CPL to 0 in the vmcb. The fix fabricates a data segment descriptor when SS is set to a null selector, so that CPL and SS.DPL are set correctly in the VMCS/vmcb. Furthermore, only allow setting SS to a NULL selector if SS.RPL < 3; this in turn ensures CPL < 3 because RPL must be equal to CPL. Thanks to Andy Lutomirski and Willy Tarreau for help in analyzing the bug and deciphering the manuals. [js] backport to 3.12 Reported-by: Xiaohan Zhang Fixes: 79d5b4c3cd809c770d4bf9812635647016c56011 Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 980a34c3b182eb6bbb9c6dfd6762deee4381d2af Author: Mike Kravetz Date: Tue Jan 10 16:58:27 2017 -0800 mm/hugetlb.c: fix reservation race when freeing surplus pages commit e5bbc8a6c992901058bc09e2ce01d16c111ff047 upstream. return_unused_surplus_pages() decrements the global reservation count, and frees any unused surplus pages that were backing the reservation. Commit 7848a4bf51b3 ("mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()") added a call to cond_resched_lock in the loop freeing the pages. As a result, the hugetlb_lock could be dropped, and someone else could use the pages that will be freed in subsequent iterations of the loop. This could result in inconsistent global hugetlb page state, application api failures (such as mmap) failures or application crashes. When dropping the lock in return_unused_surplus_pages, make sure that the global reservation count (resv_huge_pages) remains sufficiently large to prevent someone else from claiming pages about to be freed. Analyzed by Paul Cassella. Fixes: 7848a4bf51b3 ("mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()") Link: http://lkml.kernel.org/r/1483991767-6879-1-git-send-email-mike.kravetz@oracle.com Signed-off-by: Mike Kravetz Reported-by: Paul Cassella Suggested-by: Michal Hocko Cc: Masayoshi Mizuma Cc: Naoya Horiguchi Cc: Aneesh Kumar Cc: Hillf Danton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 762f213c7c123ace3488d0752dabc2930f92e3a2 Author: Eric Ren Date: Tue Jan 10 16:57:33 2017 -0800 ocfs2: fix crash caused by stale lvb with fsdlm plugin commit e7ee2c089e94067d68475990bdeed211c8852917 upstream. The crash happens rather often when we reset some cluster nodes while nodes contend fiercely to do truncate and append. The crash backtrace is below: dlm: C21CBDA5E0774F4BA5A9D4F317717495: dlm_recover_grant 1 locks on 971 resources dlm: C21CBDA5E0774F4BA5A9D4F317717495: dlm_recover 9 generation 5 done: 4 ms ocfs2: Begin replay journal (node 318952601, slot 2) on device (253,18) ocfs2: End replay journal (node 318952601, slot 2) on device (253,18) ocfs2: Beginning quota recovery on device (253,18) for slot 2 ocfs2: Finishing quota recovery on device (253,18) for slot 2 (truncate,30154,1):ocfs2_truncate_file:470 ERROR: bug expression: le64_to_cpu(fe->i_size) != i_size_read(inode) (truncate,30154,1):ocfs2_truncate_file:470 ERROR: Inode 290321, inode i_size = 732 != di i_size = 937, i_flags = 0x1 ------------[ cut here ]------------ kernel BUG at /usr/src/linux/fs/ocfs2/file.c:470! invalid opcode: 0000 [#1] SMP Modules linked in: ocfs2_stack_user(OEN) ocfs2(OEN) ocfs2_nodemanager ocfs2_stackglue(OEN) quota_tree dlm(OEN) configfs fuse sd_mod iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi af_packet iscsi_ibft iscsi_boot_sysfs softdog xfs libcrc32c ppdev parport_pc pcspkr parport joydev virtio_balloon virtio_net i2c_piix4 acpi_cpufreq button processor ext4 crc16 jbd2 mbcache ata_generic cirrus virtio_blk ata_piix drm_kms_helper ahci syscopyarea libahci sysfillrect sysimgblt fb_sys_fops ttm floppy libata drm virtio_pci virtio_ring uhci_hcd virtio ehci_hcd usbcore serio_raw usb_common sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4 Supported: No, Unsupported modules are loaded CPU: 1 PID: 30154 Comm: truncate Tainted: G OE N 4.4.21-69-default #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014 task: ffff88004ff6d240 ti: ffff880074e68000 task.ti: ffff880074e68000 RIP: 0010:[] [] ocfs2_truncate_file+0x640/0x6c0 [ocfs2] RSP: 0018:ffff880074e6bd50 EFLAGS: 00010282 RAX: 0000000000000074 RBX: 000000000000029e RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ffff880074e6bda8 R08: 000000003675dc7a R09: ffffffff82013414 R10: 0000000000034c50 R11: 0000000000000000 R12: ffff88003aab3448 R13: 00000000000002dc R14: 0000000000046e11 R15: 0000000000000020 FS: 00007f839f965700(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f839f97e000 CR3: 0000000036723000 CR4: 00000000000006e0 Call Trace: ocfs2_setattr+0x698/0xa90 [ocfs2] notify_change+0x1ae/0x380 do_truncate+0x5e/0x90 do_sys_ftruncate.constprop.11+0x108/0x160 entry_SYSCALL_64_fastpath+0x12/0x6d Code: 24 28 ba d6 01 00 00 48 c7 c6 30 43 62 a0 8b 41 2c 89 44 24 08 48 8b 41 20 48 c7 c1 78 a3 62 a0 48 89 04 24 31 c0 e8 a0 97 f9 ff <0f> 0b 3d 00 fe ff ff 0f 84 ab fd ff ff 83 f8 fc 0f 84 a2 fd ff RIP [] ocfs2_truncate_file+0x640/0x6c0 [ocfs2] It's because ocfs2_inode_lock() get us stale LVB in which the i_size is not equal to the disk i_size. We mistakenly trust the LVB because the underlaying fsdlm dlm_lock() doesn't set lkb_sbflags with DLM_SBF_VALNOTVALID properly for us. But, why? The current code tries to downconvert lock without DLM_LKF_VALBLK flag to tell o2cb don't update RSB's LVB if it's a PR->NULL conversion, even if the lock resource type needs LVB. This is not the right way for fsdlm. The fsdlm plugin behaves different on DLM_LKF_VALBLK, it depends on DLM_LKF_VALBLK to decide if we care about the LVB in the LKB. If DLM_LKF_VALBLK is not set, fsdlm will skip recovering RSB's LVB from this lkb and set the right DLM_SBF_VALNOTVALID appropriately when node failure happens. The following diagram briefly illustrates how this crash happens: RSB1 is inode metadata lock resource with LOCK_TYPE_USES_LVB; The 1st round: Node1 Node2 RSB1: PR RSB1(master): NULL->EX ocfs2_downconvert_lock(PR->NULL, set_lvb==0) ocfs2_dlm_lock(no DLM_LKF_VALBLK) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - dlm_lock(no DLM_LKF_VALBLK) convert_lock(overwrite lkb->lkb_exflags with no DLM_LKF_VALBLK) RSB1: NULL RSB1: EX reset Node2 dlm_recover_rsbs() recover_lvb() /* The LVB is not trustable if the node with EX fails and * no lock >= PR is left. We should set RSB_VALNOTVALID for RSB1. */ if(!(kb_exflags & DLM_LKF_VALBLK)) /* This means we miss the chance to return; * to invalid the LVB here. */ The 2nd round: Node 1 Node2 RSB1(become master from recovery) ocfs2_setattr() ocfs2_inode_lock(NULL->EX) /* dlm_lock() return the stale lvb without setting DLM_SBF_VALNOTVALID */ ocfs2_meta_lvb_is_trustable() return 1 /* so we don't refresh inode from disk */ ocfs2_truncate_file() mlog_bug_on_msg(disk isize != i_size_read(inode)) /* crash! */ The fix is quite straightforward. We keep to set DLM_LKF_VALBLK flag for dlm_lock() if the lock resource type needs LVB and the fsdlm plugin is uesed. Link: http://lkml.kernel.org/r/1481275846-6604-1-git-send-email-zren@suse.com Signed-off-by: Eric Ren Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 069f2e25d7eb65f32d12d185136002d97ca65f10 Author: Rolf Eike Beer Date: Wed Dec 14 11:59:57 2016 +0100 selftests: do not require bash to run netsocktests testcase commit 3659f98b5375d195f1870c3e508fe51e52206839 upstream. Nothing in this minimal script seems to require bash. We often run these tests on embedded devices where the only shell available is the busybox ash. Use sh instead. Signed-off-by: Rolf Eike Beer Signed-off-by: Shuah Khan Signed-off-by: Jiri Slaby commit 8e9a83dfe50bcc5a38027458258d8c6966be18f9 Author: Marcos Paulo de Souza Date: Sun Dec 18 15:26:12 2016 -0800 Input: i8042 - add Pegatron touchpad to noloop table commit 41c567a5d7d1a986763e58c3394782813c3bcb03 upstream. Avoid AUX loopback in Pegatron C15B touchpad, so input subsystem is able to recognize a Synaptics touchpad in the AUX port. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=93791 (Touchpad is not detected on DNS 0801480 notebook (PEGATRON C15B)) Suggested-by: Dmitry Torokhov Signed-off-by: Marcos Paulo de Souza Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Slaby commit 242f31769f3095bdbf8c061b2364838a44eee4e3 Author: Pavel Rojtberg Date: Tue Dec 27 11:44:51 2016 -0800 Input: xpad - use correct product id for x360w controllers commit b6fc513da50c5dbc457a8ad6b58b046a6a68fd9d upstream. currently the controllers get the same product id as the wireless receiver. However the controllers actually have their own product id. The patch makes the driver expose the same product id as the windows driver. This improves compatibility when running applications with WINE. see https://github.com/paroj/xpad/issues/54 Signed-off-by: Pavel Rojtberg Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Slaby commit aae53753611006763896b8241cdca639350f0103 Author: Oliver O'Halloran Date: Tue Jul 26 15:22:17 2016 -0700 mm/init: fix zone boundary creation commit 90cae1fe1c3540f791d5b8e025985fa5e699b2bb upstream. As a part of memory initialisation the architecture passes an array to free_area_init_nodes() which specifies the max PFN of each memory zone. This array is not necessarily monotonic (due to unused zones) so this array is parsed to build monotonic lists of the min and max PFN for each zone. ZONE_MOVABLE is special cased here as its limits are managed by the mm subsystem rather than the architecture. Unfortunately, this special casing is broken when ZONE_MOVABLE is the not the last zone in the zone list. The core of the issue is: if (i == ZONE_MOVABLE) continue; arch_zone_lowest_possible_pfn[i] = arch_zone_highest_possible_pfn[i-1]; As ZONE_MOVABLE is skipped the lowest_possible_pfn of the next zone will be set to zero. This patch fixes this bug by adding explicitly tracking where the next zone should start rather than relying on the contents arch_zone_highest_possible_pfn[]. Thie is low priority. To get bitten by this you need to enable a zone that appears after ZONE_MOVABLE in the zone_type enum. As far as I can tell this means running a kernel with ZONE_DEVICE or ZONE_CMA enabled, so I can't see this affecting too many people. I only noticed this because I've been fiddling with ZONE_DEVICE on powerpc and 4.6 broke my test kernel. This bug, in conjunction with the changes in Taku Izumi's kernelcore=mirror patch (d91749c1dda71) and powerpc being the odd architecture which initialises max_zone_pfn[] to ~0ul instead of 0 caused all of system memory to be placed into ZONE_DEVICE at boot, followed a panic since device memory cannot be used for kernel allocations. I've already submitted a patch to fix the powerpc specific bits, but I figured this should be fixed too. Link: http://lkml.kernel.org/r/1462435033-15601-1-git-send-email-oohall@gmail.com Signed-off-by: Oliver O'Halloran Cc: Anton Blanchard Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Arnd Bergmann Signed-off-by: Jiri Slaby commit 5a968cb0fa92a4edabf94478dabed2aeccda1d47 Author: Larry Finger Date: Thu Dec 22 21:06:53 2016 -0600 powerpc: Fix build warning on 32-bit PPC commit 8ae679c4bc2ea2d16d92620da8e3e9332fa4039f upstream. I am getting the following warning when I build kernel 4.9-git on my PowerBook G4 with a 32-bit PPC processor: AS arch/powerpc/kernel/misc_32.o arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not defined [-Wundef] This problem is evident after commit 989cea5c14be ("kbuild: prevent lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an error that has been in the code since 2005 when this source file was created. That was with commit 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S"). The offending line does not make a lot of sense. This error does not seem to cause any errors in the executable, thus I am not recommending that it be applied to any stable versions. Thanks to Nicholas Piggin for suggesting this solution. Fixes: 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S") Signed-off-by: Larry Finger Cc: Nicholas Piggin Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 5bc00ccfce098d09c1aa097806660d9709fbe956 Author: Greg Kroah-Hartman Date: Fri Jan 6 15:33:36 2017 +0100 HID: hid-cypress: validate length of report commit 1ebb71143758f45dc0fa76e2f48429e13b16d110 upstream. Make sure we have enough of a report structure to validate before looking at it. Reported-by: Benoit Camredon Tested-by: Benoit Camredon Signed-off-by: Jiri Slaby Signed-off-by: Jiri Kosina commit eaefead383021b1de5802449530640c9064a8222 Author: Herbert Xu Date: Tue Jan 10 12:24:15 2017 -0800 gro: Disable frag0 optimization on IPv6 ext headers [ Upstream commit 57ea52a865144aedbcd619ee0081155e658b6f7d ] The GRO fast path caches the frag0 address. This address becomes invalid if frag0 is modified by pskb_may_pull or its variants. So whenever that happens we must disable the frag0 optimization. This is usually done through the combination of gro_header_hard and gro_header_slow, however, the IPv6 extension header path did the pulling directly and would continue to use the GRO fast path incorrectly. This patch fixes it by disabling the fast path when we enter the IPv6 extension header path. Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual address") Reported-by: Slava Shwartsman Signed-off-by: Herbert Xu Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit bb7927f5df7bd4f1814880fb6c794dab8bad24e6 Author: Eric Dumazet Date: Tue Jan 10 19:52:43 2017 -0800 gro: use min_t() in skb_gro_reset_offset() [ Upstream commit 7cfd5fd5a9813f1430290d20c0fead9b4582a307 ] On 32bit arches, (skb->end - skb->data) is not 'unsigned int', so we shall use min_t() instead of min() to avoid a compiler error. Fixes: 1272ce87fa01 ("gro: Enter slow-path if there is no tailroom") Reported-by: kernel test robot Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 40e60967a4521c3706da84e5cef49eef4c977d45 Author: Herbert Xu Date: Tue Jan 10 12:24:01 2017 -0800 gro: Enter slow-path if there is no tailroom [ Upstream commit 1272ce87fa017ca4cf32920764d879656b7a005a ] The GRO path has a fast-path where we avoid calling pskb_may_pull and pskb_expand by directly accessing frag0. However, this should only be done if we have enough tailroom in the skb as otherwise we'll have to expand it later anyway. This patch adds the check by capping frag0_len with the skb tailroom. Fixes: cb18978cbf45 ("gro: Open-code final pskb_may_pull") Reported-by: Slava Shwartsman Signed-off-by: Herbert Xu Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit f075c74862ae82c487b5070bbb0e33feec95e13b Author: Michal Tesar Date: Mon Jan 2 14:38:36 2017 +0100 igmp: Make igmp group member RFC 3376 compliant [ Upstream commit 7ababb782690e03b78657e27bd051e20163af2d6 ] 5.2. Action on Reception of a Query When a system receives a Query, it does not respond immediately. Instead, it delays its response by a random amount of time, bounded by the Max Resp Time value derived from the Max Resp Code in the received Query message. A system may receive a variety of Queries on different interfaces and of different kinds (e.g., General Queries, Group-Specific Queries, and Group-and-Source-Specific Queries), each of which may require its own delayed response. Before scheduling a response to a Query, the system must first consider previously scheduled pending responses and in many cases schedule a combined response. Therefore, the system must be able to maintain the following state: o A timer per interface for scheduling responses to General Queries. o A per-group and interface timer for scheduling responses to Group- Specific and Group-and-Source-Specific Queries. o A per-group and interface list of sources to be reported in the response to a Group-and-Source-Specific Query. When a new Query with the Router-Alert option arrives on an interface, provided the system has state to report, a delay for a response is randomly selected in the range (0, [Max Resp Time]) where Max Resp Time is derived from Max Resp Code in the received Query message. The following rules are then used to determine if a Report needs to be scheduled and the type of Report to schedule. The rules are considered in order and only the first matching rule is applied. 1. If there is a pending response to a previous General Query scheduled sooner than the selected delay, no additional response needs to be scheduled. 2. If the received Query is a General Query, the interface timer is used to schedule a response to the General Query after the selected delay. Any previously pending response to a General Query is canceled. --8<-- Currently the timer is rearmed with new random expiration time for every incoming query regardless of possibly already pending report. Which is not aligned with the above RFE. It also might happen that higher rate of incoming queries can postpone the report after the expiration time of the first query causing group membership loss. Now the per interface general query timer is rearmed only when there is no pending report already scheduled on that interface or the newly selected expiration time is before the already pending scheduled report. Signed-off-by: Michal Tesar Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit abdddd2c24fe648ad0a999cef67b18c18eee26dc Author: Reiter Wolfgang Date: Tue Jan 3 01:39:10 2017 +0100 drop_monitor: consider inserted data in genlmsg_end [ Upstream commit 3b48ab2248e61408910e792fe84d6ec466084c1a ] Final nlmsg_len field update must reflect inserted net_dm_drop_point data. This patch depends on previous patch: "drop_monitor: add missing call to genlmsg_end" Signed-off-by: Reiter Wolfgang Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 5dd1048c9a1eec398f56286921bdefccbada41ff Author: Reiter Wolfgang Date: Sat Dec 31 21:11:57 2016 +0100 drop_monitor: add missing call to genlmsg_end [ Upstream commit 4200462d88f47f3759bdf4705f87e207b0f5b2e4 ] Update nlmsg_len field with genlmsg_end to enable userspace processing using nlmsg_next helper. Also adds error handling. Signed-off-by: Reiter Wolfgang Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 28f4d6c7c527764a04a4121ecbac1ed352bbf62e Author: Florian Fainelli Date: Tue Dec 27 18:23:06 2016 -0800 net: stmmac: Fix race between stmmac_drv_probe and stmmac_open [ Upstream commit 5701659004d68085182d2fd4199c79172165fa65 ] There is currently a small window during which the network device registered by stmmac can be made visible, yet all resources, including and clock and MDIO bus have not had a chance to be set up, this can lead to the following error to occur: [ 473.919358] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized): stmmac_dvr_probe: warning: cannot get CSR clock [ 473.919382] stmmaceth 0000:01:00.0: no reset control found [ 473.919412] stmmac - user ID: 0x10, Synopsys ID: 0x42 [ 473.919429] stmmaceth 0000:01:00.0: DMA HW capability register supported [ 473.919436] stmmaceth 0000:01:00.0: RX Checksum Offload Engine supported [ 473.919443] stmmaceth 0000:01:00.0: TX Checksum insertion supported [ 473.919451] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized): Enable RX Mitigation via HW Watchdog Timer [ 473.921395] libphy: PHY stmmac-1:00 not found [ 473.921417] stmmaceth 0000:01:00.0 eth0: Could not attach to PHY [ 473.921427] stmmaceth 0000:01:00.0 eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 473.959710] libphy: stmmac: probed [ 473.959724] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 0 IRQ POLL (stmmac-1:00) active [ 473.959728] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 1 IRQ POLL (stmmac-1:01) [ 473.959731] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 2 IRQ POLL (stmmac-1:02) [ 473.959734] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 3 IRQ POLL (stmmac-1:03) Fix this by making sure that register_netdev() is the last thing being done, which guarantees that the clock and the MDIO bus are available. Fixes: 4bfcbd7abce2 ("stmmac: Move the mdio_register/_unregister in probe/remove") Reported-by: Kweh, Hock Leong Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit cf5a64b53b07fd6913ed20914e36947a824ce044 Author: Daniel Borkmann Date: Wed Dec 21 18:04:11 2016 +0100 net, sched: fix soft lockup in tc_classify [ Upstream commit 628185cfddf1dfb701c4efe2cfd72cf5b09f5702 ] Shahar reported a soft lockup in tc_classify(), where we run into an endless loop when walking the classifier chain due to tp->next == tp which is a state we should never run into. The issue only seems to trigger under load in the tc control path. What happens is that in tc_ctl_tfilter(), thread A allocates a new tp, initializes it, sets tp_created to 1, and calls into tp->ops->change() with it. In that classifier callback we had to unlock/lock the rtnl mutex and returned with -EAGAIN. One reason why we need to drop there is, for example, that we need to request an action module to be loaded. This happens via tcf_exts_validate() -> tcf_action_init/_1() meaning after we loaded and found the requested action, we need to redo the whole request so we don't race against others. While we had to unlock rtnl in that time, thread B's request was processed next on that CPU. Thread B added a new tp instance successfully to the classifier chain. When thread A returned grabbing the rtnl mutex again, propagating -EAGAIN and destroying its tp instance which never got linked, we goto replay and redo A's request. This time when walking the classifier chain in tc_ctl_tfilter() for checking for existing tp instances we had a priority match and found the tp instance that was created and linked by thread B. Now calling again into tp->ops->change() with that tp was successful and returned without error. tp_created was never cleared in the second round, thus kernel thinks that we need to link it into the classifier chain (once again). tp and *back point to the same object due to the match we had earlier on. Thus for thread B's already public tp, we reset tp->next to tp itself and link it into the chain, which eventually causes the mentioned endless loop in tc_classify() once a packet hits the data path. Fix is to clear tp_created at the beginning of each request, also when we replay it. On the paths that can cause -EAGAIN we already destroy the original tp instance we had and on replay we really need to start from scratch. It seems that this issue was first introduced in commit 12186be7d2e1 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup"). Fixes: 12186be7d2e1 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup") Reported-by: Shahar Klein Signed-off-by: Daniel Borkmann Cc: Cong Wang Acked-by: Eric Dumazet Tested-by: Shahar Klein Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 391ccf0985dcc0dc786ca0f6828eb68f0455d086 Author: Dave Jones Date: Thu Dec 22 11:16:22 2016 -0500 ipv6: handle -EFAULT from skb_copy_bits [ Upstream commit a98f91758995cb59611e61318dddd8a6956b52c3 ] By setting certain socket options on ipv6 raw sockets, we can confuse the length calculation in rawv6_push_pending_frames triggering a BUG_ON. RIP: 0010:[] [] rawv6_sendmsg+0xc30/0xc40 RSP: 0018:ffff881f6c4a7c18 EFLAGS: 00010282 RAX: 00000000fffffff2 RBX: ffff881f6c681680 RCX: 0000000000000002 RDX: ffff881f6c4a7cf8 RSI: 0000000000000030 RDI: ffff881fed0f6a00 RBP: ffff881f6c4a7da8 R08: 0000000000000000 R09: 0000000000000009 R10: ffff881fed0f6a00 R11: 0000000000000009 R12: 0000000000000030 R13: ffff881fed0f6a00 R14: ffff881fee39ba00 R15: ffff881fefa93a80 Call Trace: [] ? unmap_page_range+0x693/0x830 [] inet_sendmsg+0x67/0xa0 [] sock_sendmsg+0x38/0x50 [] SYSC_sendto+0xef/0x170 [] SyS_sendto+0xe/0x10 [] do_syscall_64+0x50/0xa0 [] entry_SYSCALL64_slow_path+0x25/0x25 Handle by jumping to the failure path if skb_copy_bits gets an EFAULT. Reproducer: #include #include #include #include #include #include #include #define LEN 504 int main(int argc, char* argv[]) { int fd; int zero = 0; char buf[LEN]; memset(buf, 0, LEN); fd = socket(AF_INET6, SOCK_RAW, 7); setsockopt(fd, SOL_IPV6, IPV6_CHECKSUM, &zero, 4); setsockopt(fd, SOL_IPV6, IPV6_DSTOPTS, &buf, LEN); sendto(fd, buf, 1, 0, (struct sockaddr *) buf, 110); } Signed-off-by: Dave Jones Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit fce49ca92fcb32f06c450f02b197d5cb209743dc Author: Dan Carpenter Date: Wed Dec 7 14:22:03 2016 +0300 ser_gigaset: return -ENOMEM on error instead of success [ Upstream commit 93a97c50cbf1c007caf12db5cc23e0d5b9c8473c ] If we can't allocate the resources in gigaset_initdriver() then we should return -ENOMEM instead of zero. Fixes: 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit fa5e29d5d65fd6eb4616125410f144e7dae26707 Author: stephen hemminger Date: Tue Dec 6 13:43:54 2016 -0800 netvsc: reduce maximum GSO size [ Upstream commit a50af86dd49ee1851d1ccf06dd0019c05b95e297 ] Hyper-V (and Azure) support using NVGRE which requires some extra space for encapsulation headers. Because of this the largest allowed TSO packet is reduced. For older releases, hard code a fixed reduced value. For next release, there is a better solution which uses result of host offload negotiation. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 6e89266fa6eedba557c0a602acb4f60ff5a1543c Author: Felipe Balbi Date: Wed Sep 28 12:33:31 2016 +0300 usb: gadget: composite: always set ep->mult to a sensible value commit eaa496ffaaf19591fe471a36cef366146eeb9153 upstream. ep->mult is supposed to be set to Isochronous and Interrupt Endapoint's multiplier value. This value is computed from different places depending on the link speed. If we're dealing with HighSpeed, then it's part of bits [12:11] of wMaxPacketSize. This case wasn't taken into consideration before. While at that, also make sure the ep->mult defaults to one so drivers can use it unconditionally and assume they'll never multiply ep->maxpacket to zero. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit ed470f117391d367456a95975a850f490c727998 Author: Thomas Gleixner Date: Thu Dec 15 12:10:37 2016 +0100 tick/broadcast: Prevent NULL pointer dereference commit c1a9eeb938b5433947e5ea22f89baff3182e7075 upstream. When a disfunctional timer, e.g. dummy timer, is installed, the tick core tries to setup the broadcast timer. If no broadcast device is installed, the kernel crashes with a NULL pointer dereference in tick_broadcast_setup_oneshot() because the function has no sanity check. Reported-by: Mason Signed-off-by: Thomas Gleixner Cc: Mark Rutland Cc: Anna-Maria Gleixner Cc: Richard Cochran Cc: Sebastian Andrzej Siewior Cc: Daniel Lezcano Cc: Peter Zijlstra , Cc: Sebastian Frias Cc: Thibaud Cornic Cc: Robin Murphy Link: http://lkml.kernel.org/r/1147ef90-7877-e4d2-bb2b-5c4fa8d3144b@free.fr Signed-off-by: Jiri Slaby commit dd132142858d108814a36fc044431c4ae34ea3f8 Author: Paul Burton Date: Fri Sep 2 15:22:48 2016 +0100 net: ti: cpmac: Fix compiler warning due to type confusion commit 2f5281ba2a8feaf6f0aee93356f350855bb530fc upstream. cpmac_start_xmit() used the max() macro on skb->len (an unsigned int) and ETH_ZLEN (a signed int literal). This led to the following compiler warning: In file included from include/linux/list.h:8:0, from include/linux/module.h:9, from drivers/net/ethernet/ti/cpmac.c:19: drivers/net/ethernet/ti/cpmac.c: In function 'cpmac_start_xmit': include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast (void) (&_max1 == &_max2); \ ^ drivers/net/ethernet/ti/cpmac.c:560:8: note: in expansion of macro 'max' len = max(skb->len, ETH_ZLEN); ^ On top of this, it assigned the result of the max() macro to a signed integer whilst all further uses of it result in it being cast to varying widths of unsigned integer. Fix this up by using max_t to ensure the comparison is performed as unsigned integers, and for consistency change the type of the len variable to unsigned int. Signed-off-by: Paul Burton Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 66bbced294769d2f987c405c041b4031326fadfc Author: Arnd Bergmann Date: Tue Mar 22 14:27:11 2016 -0700 cred/userns: define current_user_ns() as a function commit 0335695dfa4df01edff5bb102b9a82a0668ee51e upstream. The current_user_ns() macro currently returns &init_user_ns when user namespaces are disabled, and that causes several warnings when building with gcc-6.0 in code that compares the result of the macro to &init_user_ns itself: fs/xfs/xfs_ioctl.c: In function 'xfs_ioctl_setattr_check_projid': fs/xfs/xfs_ioctl.c:1249:22: error: self-comparison always evaluates to true [-Werror=tautological-compare] if (current_user_ns() == &init_user_ns) This is a legitimate warning in principle, but here it isn't really helpful, so I'm reprasing the definition in a way that shuts up the warning. Apparently gcc only warns when comparing identical literals, but it can figure out that the result of an inline function can be identical to a constant expression in order to optimize a condition yet not warn about the fact that the condition is known at compile time. This is exactly what we want here, and it looks reasonable because we generally prefer inline functions over macros anyway. Signed-off-by: Arnd Bergmann Acked-by: Serge Hallyn Cc: David Howells Cc: Yaowei Bai Cc: James Morris Cc: "Paul E. McKenney" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 0d8f571b19bf316eea098bb85ddcc22a36c9801b Author: Johan Hovold Date: Tue Nov 1 16:26:03 2016 +0100 powerpc/pci/rpadlpar: Fix device reference leaks commit 99e5cde5eae78bef95bfe7c16ccda87fb070149b upstream. Make sure to drop any device reference taken by vio_find_node() when adding and removing virtual I/O slots. Fixes: 5eeb8c63a38f ("[PATCH] PCI Hotplug: rpaphp: Move VIO registration") Signed-off-by: Johan Hovold Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby commit 4007c25644d8ed6b29fea950a8791c43823dd842 Author: Shaohua Li Date: Thu Dec 8 15:48:18 2016 -0800 md: MD_RECOVERY_NEEDED is set for mddev->recovery commit 82a301cb0ea2df8a5c88213094a01660067c7fb4 upstream. Fixes: 90f5f7ad4f38("md: Wait for md_check_recovery before attempting device removal.") Reviewed-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Jiri Slaby commit 805ce4f6e030d0d9fa1cf39912e9c977e57a7677 Author: Dan Carpenter Date: Mon Nov 14 14:31:34 2016 +0300 mmc: mmc_test: Uninitialized return value commit 16652a936e96f5dae53c3fbd38a570497baadaa8 upstream. We never set "ret" to RESULT_OK. Fixes: 9f9c4180f88d ("mmc: mmc_test: add test for non-blocking transfers") Signed-off-by: Dan Carpenter Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit 7d91bd7b2ebde09846fa6dc2af292212b0f91d72 Author: Dan Carpenter Date: Tue Dec 13 15:27:04 2016 +0300 target/iscsi: Fix double free in lio_target_tiqn_addtpg() commit a91918cd3ea11f91c68e08e1e8ce1b560447a80e upstream. This iscsit_tpg_add_portal_group() function is only called from lio_target_tiqn_addtpg(). Both functions free the "tpg" pointer on error so it's a double free bug. The memory is allocated in the caller so it should be freed in the caller and not here. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Signed-off-by: Dan Carpenter Reviewed-by: David Disseldorp [ bvanassche: Added "Fix" at start of patch title ] Signed-off-by: Bart Van Assche Signed-off-by: Jiri Slaby commit 383591b85c75182128609049f11d72c22b6a0918 Author: Arnd Bergmann Date: Wed Nov 16 16:08:34 2016 +0100 scsi: mvsas: fix command_active typo commit af15769ffab13d777e55fdef09d0762bf0c249c4 upstream. gcc-7 notices that the condition in mvs_94xx_command_active looks suspicious: drivers/scsi/mvsas/mv_94xx.c: In function 'mvs_94xx_command_active': drivers/scsi/mvsas/mv_94xx.c:671:15: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context] This was introduced when the mv_printk() statement got added, and leads to the condition being ignored. This is probably harmless. Changing '&&' to '&' makes the code look reasonable, as we check the command bit before setting and printing it. Fixes: a4632aae8b66 ("[SCSI] mvsas: Add new macros and functions") Signed-off-by: Arnd Bergmann Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby commit 70eaa9c0da68624ad4fe6b46162156205b886927 Author: Huang Rui Date: Mon Dec 12 07:28:26 2016 -0500 iommu/amd: Fix the left value check of cmd buffer commit 432abf68a79332282329286d190e21fe3ac02a31 upstream. The generic command buffer entry is 128 bits (16 bytes), so the offset of tail and head pointer should be 16 bytes aligned and increased with 0x10 per command. When cmd buf is full, head = (tail + 0x10) % CMD_BUFFER_SIZE. So when left space of cmd buf should be able to store only two command, we should be issued one COMPLETE_WAIT additionally to wait all older commands completed. Then the left space should be increased after IOMMU fetching from cmd buf. So left check value should be left <= 0x20 (two commands). Signed-off-by: Huang Rui Fixes: ac0ea6e92b222 ('x86/amd-iommu: Improve handling of full command buffer') Signed-off-by: Joerg Roedel Signed-off-by: Jiri Slaby commit 4038387da6a7dcbc1af910a6e2566ae3b2037330 Author: Pan Bian Date: Thu Dec 1 14:25:44 2016 +0800 clk: clk-wm831x: fix a logic error commit 20979202ee6e4c68dab7bcf408787225a656d18e upstream. Fix bug https://bugzilla.kernel.org/show_bug.cgi?id=188561. Function wm831x_clkout_is_prepared() returns "true" when it fails to read CLOCK_CONTROL_1. "true" means the device is already prepared. So return "true" on the read failure seems improper. Signed-off-by: Pan Bian Acked-by: Charles Keepax Fixes: f05259a6ffa4 ("clk: wm831x: Add initial WM831x clock driver") Signed-off-by: Stephen Boyd Signed-off-by: Jiri Slaby commit df3fbf21ff22b3d7c9717e3f3a35f165413227fe Author: Guenter Roeck Date: Sun Dec 11 13:27:42 2016 -0800 hwmon: (g762) Fix overflows and crash seen when writing limit attributes commit 4fccd4a1e8944033bcd7693ea4e8fb478cd2059a upstream. Fix overflows seen when writing into fan speed limit attributes. Also fix crash due to division by zero, seen when certain very large values (such as 2147483648, or 0x80000000) are written into fan speed limit attributes. Fixes: 594fbe713bf60 ("Add support for GMT G762/G763 PWM fan controllers") Cc: Arnaud Ebalard Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit 255113ec53e3e3bb41719242ddc20c5f78e670c7 Author: Guenter Roeck Date: Sun Nov 20 10:37:39 2016 -0800 hwmon: (ds620) Fix overflows seen when writing temperature limits commit e36ce99ee0815d7919a7b589bfb66f3de50b6bc7 upstream. Module test reports: temp1_max: Suspected overflow: [160000 vs. 0] temp1_min: Suspected overflow: [160000 vs. 0] This is seen because the values passed when writing temperature limits are unbound. Reviewed-by: Jean Delvare Fixes: 6099469805c2 ("hwmon: Support for Dallas Semiconductor DS620") Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby commit d8abb38ea10e94a87ad3a2c1d498d3fc487dbd53 Author: Guenter Roeck Date: Sun Oct 30 09:09:18 2016 -0700 cris: Only build flash rescue image if CONFIG_ETRAX_AXISFLASHMAP is selected commit 328cf6927bb72cadefddebbc9a23c793108147a2 upstream. If CONFIG_ETRAX_AXISFLASHMAP is not configured, the flash rescue image object file is empty. With recent versions of binutils, this results in the following build error. cris-linux-objcopy: error: the input file 'arch/cris/boot/rescue/rescue.o' has no sections This is seen, for example, when trying to build cris:allnoconfig with recently generated toolchains. Since it does not make sense to build a flash rescue image if there is no flash, only build it if CONFIG_ETRAX_AXISFLASHMAP is enabled. Reported-by: kbuild test robot Fixes: 66ab3a74c5ce ("CRIS: Merge machine dependent boot/compressed ..") Signed-off-by: Guenter Roeck Signed-off-by: Jesper Nilsson Signed-off-by: Jiri Slaby commit 44f88151edb80b4fe818e7023424f596238a7f96 Author: Felipe Balbi Date: Tue Dec 20 14:14:40 2016 +0200 usb: dwc3: gadget: always unmap EP0 requests commit d62145929992f331fdde924d5963ab49588ccc7d upstream. commit 0416e494ce7d ("usb: dwc3: ep0: correct cache sync issue in case of ep0_bounced") introduced a bug where we would leak DMA resources which would cause us to starve the system of them resulting in failing DMA transfers. Fix the bug by making sure that we always unmap EP0 requests since those are *always* mapped. Fixes: 0416e494ce7d ("usb: dwc3: ep0: correct cache sync issue in case of ep0_bounced") Tested-by: Tomasz Medrek Reported-by: Janusz Dziedzic Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 9e8f9aa9d8cddc50ac6d05cfea53e241886172e7 Author: Eva Rachel Retuya Date: Sun Oct 9 00:05:39 2016 +0800 staging: iio: ad7606: fix improper setting of oversampling pins commit b321a38d2407c7e425c54bc09be909a34e49f740 upstream. The oversampling ratio is controlled using the oversampling pins, OS [2:0] with OS2 being the MSB control bit, and OS0 the LSB control bit. The gpio connected to the OS2 pin is not being set correctly, only OS0 and OS1 pins are being set. Fix the typo to allow proper control of the oversampling pins. Signed-off-by: Eva Rachel Retuya Fixes: b9618c0 ("staging: IIO: ADC: New driver for AD7606/AD7606-6/AD7606-4") Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Jiri Slaby commit 8cb5b0901bd54ef57755851242a0354d3b2f85b7 Author: Johan Hovold Date: Tue Jan 3 16:39:46 2017 +0100 USB: serial: io_ti: bind to interface after fw download commit e35d6d7c4e6532a89732cf4bace0e910ee684c88 upstream. Bind to the interface, but do not register any ports, after having downloaded the firmware. The device will still disconnect and re-enumerate, but this way we avoid an error messages from being logged as part of the process: io_ti: probe of 1-1.3:1.0 failed with error -5 Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 732304a3e01b5dafc748f2932833ed882ee4ca6b Author: Johan Hovold Date: Tue Nov 1 11:40:25 2016 +0100 USB: phy: am335x-control: fix device and of_node leaks commit 015105b12183556771e111e93f5266851e7c5582 upstream. Make sure to drop the references taken by of_parse_phandle() and bus_find_device() before returning from am335x_get_phy_control(). Note that there is no guarantee that the devres-managed struct phy_control will be valid for the lifetime of the sibling phy device regardless of this change. Fixes: 3bb869c8b3f1 ("usb: phy: Add AM335x PHY driver") Acked-by: Bin Liu Signed-off-by: Johan Hovold Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 3741322cec239a5307620db3cd3a42dcb917ffea Author: Pan Bian Date: Tue Nov 29 16:55:02 2016 +0100 USB: serial: kl5kusb105: abort on open exception path commit 3c3dd1e058cb01e835dcade4b54a6f13ffaeaf7c upstream. Function klsi_105_open() calls usb_control_msg() (to "enable read") and checks its return value. When the return value is unexpected, it only assigns the error code to the return variable retval, but does not terminate the exception path. This patch fixes the bug by inserting "goto err_generic_close;" when the call to usb_control_msg() fails. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Pan Bian [johan: rebase on prerequisite fix and amend commit message] Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 7b0713fb9aa966f2c70679338ec08582c4e4d1cd Author: Takashi Iwai Date: Tue Nov 29 22:28:40 2016 +0100 ALSA: usb-audio: Fix bogus error return in snd_usb_create_stream() commit 4763601a56f155ddf94ef35fc2c41504a2de15f5 upstream. The function returns -EINVAL even if it builds the stream properly. The bogus error code sneaked in during the code refactoring, but it wasn't noticed until now since the returned error code itself is ignored in anyway. Kill it here, but there is no behavior change by this patch, obviously. Fixes: e5779998bf8b ('ALSA: usb-audio: refactor code') Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit aece02071e5848b3837283e565fceb43bc3f5c70 Author: Geert Uytterhoeven Date: Wed Dec 14 15:37:30 2016 +0100 usb: hub: Move hub_port_disable() to fix warning if PM is disabled commit 3bc02bce908c7250781376052248f5cd60a4e3d4 upstream. If CONFIG_PM=n: drivers/usb/core/hub.c:107: warning: ‘hub_usb3_port_prepare_disable’ declared inline after being called drivers/usb/core/hub.c:107: warning: previous declaration of ‘hub_usb3_port_prepare_disable’ was here To fix this, move hub_port_disable() after hub_usb3_port_prepare_disable(), and adjust forward declarations. Fixes: 37be66767e3cae4f ("usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices") Signed-off-by: Geert Uytterhoeven Signed-off-by: Jiri Slaby commit 58fbd600181aba64bce35af84fecf6e012c33dd2 Author: Tony Lindgren Date: Tue Jan 3 18:13:48 2017 -0600 usb: musb: Fix trying to free already-free IRQ 4 commit 8c300fe282fa254ea730c92cb0983e2642dc1fff upstream. When unloading omap2430, we can get the following splat: WARNING: CPU: 1 PID: 295 at kernel/irq/manage.c:1478 __free_irq+0xa8/0x2c8 Trying to free already-free IRQ 4 ... [] (free_irq) from [] (musbhs_dma_controller_destroy+0x28/0xb0 [musb_hdrc]) [] (musbhs_dma_controller_destroy [musb_hdrc]) from [] (musb_remove+0xf0/0x12c [musb_hdrc]) [] (musb_remove [musb_hdrc]) from [] (platform_drv_remove+0x24/0x3c) ... This is because the irq number in use is 260 nowadays, and the dma controller is using u8 instead of int. Fixes: 6995eb68aab7 ("USB: musb: enable low level DMA operation for Blackfin") Signed-off-by: Tony Lindgren [b-liu@ti.com: added Fixes tag] Signed-off-by: Bin Liu Signed-off-by: Jiri Slaby commit b1cdbc48f7b1840a4e8c33603927d83809b7dce7 Author: Heikki Krogerus Date: Fri Apr 1 17:13:12 2016 +0300 usb: dwc3: pci: add Intel Gemini Lake PCI ID commit 8f8983a5683623b62b339d159573f95a1fce44f3 upstream. Intel Gemini Lake SoC has the same DWC3 than Broxton. Add the new ID to the supported Devices. Signed-off-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 5c84eec536274007ad9acdc91725b0696393b147 Author: Dan Carpenter Date: Thu Nov 10 22:33:17 2016 +0300 usb: xhci-mem: use passed in GFP flags instead of GFP_KERNEL commit c95a9f83711bf53faeb4ed9bbb63a3f065613dfb upstream. We normally use the passed in gfp flags for allocations, it's just these two which were missed. Fixes: 22d45f01a836 ("usb/xhci: replace pci_*_consistent() with dma_*_coherent()") Cc: Mathias Nyman Signed-off-by: Dan Carpenter Acked-by: Sebastian Andrzej Siewior Signed-off-by: Jiri Slaby commit 24f7fb99a15c2f4a565a1db2ebce6acdd7808005 Author: Johan Hovold Date: Tue Jan 3 16:39:53 2017 +0100 USB: serial: mos7720: fix parallel probe commit fde1faf872ed86d88e245191bc15a8e57368cd1c upstream. A static usb-serial-driver structure that is used to initialise the interrupt URB was modified during probe depending on the currently probed device type, something which could break a parallel probe of a device of a different type. Fix this up by overriding the default completion callback for MCS7715 devices in attach() instead. We may want to use two usb-serial driver instances for the two types later. Fixes: fb088e335d78 ("USB: serial: add support for serial port on the moschip 7715") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 81dd8d4c020fc8e69671f59579461863d2f4ace5 Author: Johan Hovold Date: Tue Jan 3 16:39:52 2017 +0100 USB: serial: mos7720: fix parport use-after-free on probe errors commit 75dd211e773afcbc264677b0749d1cf7d937ab2d upstream. Do not submit the interrupt URB until after the parport has been successfully registered to avoid another use-after-free in the completion handler when accessing the freed parport private data in case of a racing completion. Fixes: b69578df7e98 ("USB: usbserial: mos7720: add support for parallel port on moschip 7715") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit a728574a31e780b0f83a16ed967aaefbe60456c7 Author: Johan Hovold Date: Tue Jan 3 16:39:51 2017 +0100 USB: serial: mos7720: fix use-after-free on probe errors commit 91a1ff4d53c5184d383d0baeeaeab6f9736f2ff3 upstream. The interrupt URB was submitted on probe but never stopped on probe errors. This can lead to use-after-free issues in the completion handler when accessing the freed usb-serial struct: Unable to handle kernel paging request at virtual address 6b6b6be7 ... [] (mos7715_interrupt_callback [mos7720]) from [] (__usb_hcd_giveback_urb+0x80/0x140) [] (__usb_hcd_giveback_urb) from [] (usb_hcd_giveback_urb+0x50/0x138) [] (usb_hcd_giveback_urb) from [] (musb_giveback+0xc8/0x1cc) Fixes: b69578df7e98 ("USB: usbserial: mos7720: add support for parallel port on moschip 7715") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 8a84d012e2dbe341807ad758f8b9427760ab4180 Author: Johan Hovold Date: Tue Jan 3 16:39:50 2017 +0100 USB: serial: mos7720: fix NULL-deref at open commit b05aebc25fdc5aeeac3ee29f0dc9f58dd07c13cc upstream. Fix NULL-pointer dereference at port open if a device lacks the expected bulk in and out endpoints. Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... [] (mos7720_open [mos7720]) from [] (serial_port_activate+0x68/0x98 [usbserial]) [] (serial_port_activate [usbserial]) from [] (tty_port_open+0x9c/0xe8) [] (tty_port_open) from [] (serial_open+0x48/0x6c [usbserial]) [] (serial_open [usbserial]) from [] (tty_open+0xcc/0x5cc) Fixes: 0f64478cbc7a ("USB: add USB serial mos7720 driver") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 6c16cb61aaa01471f755816c51e550925305b04f Author: Johan Hovold Date: Tue Jan 3 16:39:55 2017 +0100 USB: serial: mos7840: fix NULL-deref at open commit 5c75633ef751dd4cd8f443dc35152c1ae563162e upstream. Fix NULL-pointer dereference in open() should the device lack the expected endpoints: Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... PC is at mos7840_open+0x88/0x8dc [mos7840] Note that we continue to treat the interrupt-in endpoint as optional for now. Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 85050661276d517aabe9bf0f8666e6b8584b33c6 Author: Johan Hovold Date: Tue Jan 3 16:39:49 2017 +0100 USB: serial: kobil_sct: fix NULL-deref in write commit 21ce57840243c7b70fbc1ebd3dceeb70bb6e9e09 upstream. Fix NULL-pointer dereference in write() should the device lack the expected interrupt-out endpoint: Unable to handle kernel NULL pointer dereference at virtual address 00000054 ... PC is at kobil_write+0x144/0x2a0 [kobil_sct] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit a42508f04fdd5d64684fd5d4a7780369756ed4eb Author: Johan Hovold Date: Tue Jan 3 16:39:40 2017 +0100 USB: serial: cyberjack: fix NULL-deref at open commit 3dca01114dcecb1cf324534cd8d75fd1306a516b upstream. Fix NULL-pointer dereference when clearing halt at open should the device lack a bulk-out endpoint. Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... PC is at cyberjack_open+0x40/0x9c [cyberjack] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit f3297a317305c36893e520d65f327997576d430b Author: Johan Hovold Date: Tue Jan 3 16:39:59 2017 +0100 USB: serial: oti6858: fix NULL-deref at open commit 5afeef2366db14587b65558bbfd5a067542e07fb upstream. Fix NULL-pointer dereference in open() should the device lack the expected endpoints: Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... PC is at oti6858_open+0x30/0x1d0 [oti6858] Note that a missing interrupt-in endpoint would have caused open() to fail. Fixes: 49cdee0ed0fc ("USB: oti6858 usb-serial driver (in Nokia CA-42 cable)") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit ff681c3d694354fbfb9f2d8c424682267c1a40c6 Author: Johan Hovold Date: Tue Jan 3 16:39:42 2017 +0100 USB: serial: io_edgeport: fix NULL-deref at open commit 0dd408425eb21ddf26a692b3c8044c9e7d1a7948 upstream. Fix NULL-pointer dereference when initialising URBs at open should a non-EPIC device lack a bulk-in or interrupt-in endpoint. Unable to handle kernel NULL pointer dereference at virtual address 00000028 ... PC is at edge_open+0x24c/0x3e8 [io_edgeport] Note that the EPIC-device probe path has the required sanity checks so this makes those checks partially redundant. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 6541d1a3a2d9d8ff75fa841a5883a5c421e224ce Author: Johan Hovold Date: Tue Jan 3 16:40:03 2017 +0100 USB: serial: ti_usb_3410_5052: fix NULL-deref at open commit ef079936d3cd09e63612834fe2698eeada0d8e3f upstream. Fix NULL-pointer dereference in open() should a malicious device lack the expected endpoints: Unable to handle kernel NULL pointer dereference at virtual address 00000030 .. [] (ti_open [ti_usb_3410_5052]) from [] (serial_port_activate+0x68/0x98 [usbserial]) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit a5c558687f66ed779c8c439b340da32eb5e33774 Author: Johan Hovold Date: Tue Jan 3 16:39:41 2017 +0100 USB: serial: garmin_gps: fix memory leak on failed URB submit commit c4ac4496e835b78a45dfbf74f6173932217e4116 upstream. Make sure to free the URB transfer buffer in case submission fails (e.g. due to a disconnect). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit d4f28bda4e480c7cfbfe77271a8176555e0f9d53 Author: Johan Hovold Date: Tue Jan 3 16:39:47 2017 +0100 USB: serial: iuu_phoenix: fix NULL-deref at open commit 90507d54f712d81b74815ef3a4bbb555cd9fab2f upstream. Fix NULL-pointer dereference at open should the device lack a bulk-in or bulk-out endpoint: Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... PC is at iuu_open+0x78/0x59c [iuu_phoenix] Fixes: 07c3b1a10016 ("USB: remove broken usb-serial num_endpoints check") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 4c2c01fb219e9345c88ade261fee90330119eadb Author: Johan Hovold Date: Tue Jan 3 16:39:44 2017 +0100 USB: serial: io_ti: fix another NULL-deref at open commit 4f9785cc99feeb3673993b471f646b4dbaec2cc1 upstream. In case a device is left in "boot-mode" we must not register any port devices in order to avoid a NULL-pointer dereference on open due to missing endpoints. This could be used by a malicious device to trigger an OOPS: Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... [] (edge_open [io_ti]) from [] (serial_port_activate+0x68/0x98 [usbserial]) [] (serial_port_activate [usbserial]) from [] (tty_port_open+0x9c/0xe8) [] (tty_port_open) from [] (serial_open+0x48/0x6c [usbserial]) [] (serial_open [usbserial]) from [] (tty_open+0xcc/0x5cc) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 711e7e4aba99c001be1d1478aae277777ea01caf Author: Johan Hovold Date: Tue Jan 3 16:39:43 2017 +0100 USB: serial: io_ti: fix NULL-deref at open commit a323fefc6f5079844dc62ffeb54f491d0242ca35 upstream. Fix NULL-pointer dereference when clearing halt at open should a malicious device lack the expected endpoints when in download mode. Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... [] (edge_open [io_ti]) from [] (serial_port_activate+0x68/0x98 [usbserial]) [] (serial_port_activate [usbserial]) from [] (tty_port_open+0x9c/0xe8) [] (tty_port_open) from [] (serial_open+0x48/0x6c [usbserial]) [] (serial_open [usbserial]) from [] (tty_open+0xcc/0x5cc) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 3581f3d212adbfa4d2a0b108c3c8686f7fc71be4 Author: Johan Hovold Date: Tue Jan 3 16:40:02 2017 +0100 USB: serial: spcp8x5: fix NULL-deref at open commit cc0909248258f679c4bb4cd315565d40abaf6bc6 upstream. Fix NULL-pointer dereference in open() should the device lack the expected endpoints: Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... PC is at spcp8x5_open+0x30/0xd0 [spcp8x5] Fixes: 619a6f1d1423 ("USB: add usb-serial spcp8x5 driver") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit eb0eb124a640c56a7c307c87a5e7150196ae236e Author: Johan Hovold Date: Tue Jan 3 16:39:48 2017 +0100 USB: serial: keyspan_pda: verify endpoints at probe commit 5d9b0f859babe96175cd33d7162a9463a875ffde upstream. Check for the expected endpoints in attach() and fail loudly if not present. Note that failing to do this appears to be benign since da280e348866 ("USB: keyspan_pda: clean up write-urb busy handling") which prevents a NULL-pointer dereference in write() by never marking a non-existent write-urb as free. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit dfdc808d8a49f16409ee2f559c1794876866da20 Author: Johan Hovold Date: Tue Jan 3 16:40:00 2017 +0100 USB: serial: pl2303: fix NULL-deref at open commit 76ab439ed1b68778e9059c79ecc5d14de76c89a8 upstream. Fix NULL-pointer dereference in open() should a type-0 or type-1 device lack the expected endpoints: Unable to handle kernel NULL pointer dereference at virtual address 00000030 ... PC is at pl2303_open+0x38/0xec [pl2303] Note that a missing interrupt-in endpoint would have caused open() to fail. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit e7c61440519c0b8efe4a2f78799a90b49198a625 Author: Johan Hovold Date: Tue Jan 3 16:40:01 2017 +0100 USB: serial: quatech2: fix sleep-while-atomic in close commit f09d1886a41e9063b43da493ef0e845ac8afd2fa upstream. The write URB was being killed using the synchronous interface while holding a spin lock in close(). Simply drop the lock and busy-flag update, something which would have been taken care of by the completion handler if the URB was in flight. Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 702c8acb31489bacd5d330970c37e71d66b86484 Author: Johan Hovold Date: Tue Jan 3 16:39:58 2017 +0100 USB: serial: omninet: fix NULL-derefs at open and disconnect commit a5bc01949e3b19d8a23b5eabc6fc71bb50dc820e upstream. Fix NULL-pointer dereferences at open() and disconnect() should the device lack the expected bulk-out endpoints: Unable to handle kernel NULL pointer dereference at virtual address 000000b4 ... [c0170ff0>] (__lock_acquire) from [] (lock_acquire+0x108/0x264) [] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x58/0x6c) [] (_raw_spin_lock_irqsave) from [] (tty_port_tty_set+0x28/0xa4) [] (tty_port_tty_set) from [] (omninet_open+0x30/0x40 [omninet]) [] (omninet_open [omninet]) from [] (serial_port_activate+0x68/0x98 [usbserial]) Unable to handle kernel NULL pointer dereference at virtual address 00000234 ... [] (omninet_disconnect [omninet]) from [] (usb_serial_disconnect+0xe4/0x100 [usbserial]) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit db2ea0f72ff39e50469e8ff14754bc553e8f9d93 Author: Mathias Nyman Date: Tue Jan 3 18:28:43 2017 +0200 xhci: free xhci virtual devices with leaf nodes first commit ee8665e28e8d90ce69d4abe5a469c14a8707ae0e upstream. the tt_info provided by a HS hub might be in use to by a child device Make sure we free the devices in the correct order. This is needed in special cases such as when xhci controller is reset when resuming from hibernate, and all virt_devices are freed. Also free the virt_devices starting from max slot_id as children more commonly have higher slot_id than parent. Reported-by: Guenter Roeck Tested-by: Guenter Roeck Signed-off-by: Mathias Nyman Signed-off-by: Jiri Slaby commit 7d0394bf3528bc80ed9523403d5fc3a3de5dff85 Author: Wan Ahmad Zainie Date: Tue Jan 3 18:28:52 2017 +0200 usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Apollo Lake commit 6c97cfc1a097b1e0786c836e92b7a72b4d031e25 upstream. Intel Apollo Lake also requires XHCI_PME_STUCK_QUIRK. Adding its PCI ID to quirk. Signed-off-by: Wan Ahmad Zainie Signed-off-by: Mathias Nyman Signed-off-by: Jiri Slaby commit 9df8806f3366e9e44712c1a45fd7ffa09f28ce30 Author: Mathias Nyman Date: Thu Oct 20 18:09:19 2016 +0300 xhci: workaround for hosts missing CAS bit commit 346e99736c3ce328fd42d678343b70243aca5f36 upstream. If a device is unplugged and replugged during Sx system suspend some Intel xHC hosts will overwrite the CAS (Cold attach status) flag and no device connection is noticed in resume. A device in this state can be identified in resume if its link state is in polling or compliance mode, and the current connect status is 0. A device in this state needs to be warm reset. Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8 Observed on Cherryview and Apollolake as they go into compliance mode if LFPS times out during polling, and re-plugged devices are not discovered at resume. Signed-off-by: Mathias Nyman Signed-off-by: Jiri Slaby commit d1324a5fceb1883cfdd5edc0cc5ad4c713eef0e1 Author: Krzysztof Opasiak Date: Tue Dec 20 19:52:16 2016 +0100 usb: gadget: composite: Test get_alt() presence instead of set_alt() commit 7e4da3fcf7c9fe042f2f7cb7bf23861a899b4a8f upstream. By convention (according to doc) if function does not provide get_alt() callback composite framework should assume that it has only altsetting 0 and should respond with error if host tries to set other one. After commit dd4dff8b035f ("USB: composite: Fix bug: should test set_alt function pointer before use it") we started checking set_alt() callback instead of get_alt(). This check is useless as we check if set_alt() is set inside usb_add_function() and fail if it's NULL. Let's fix this check and move comment about why we check the get method instead of set a little bit closer to prevent future false fixes. Fixes: dd4dff8b035f ("USB: composite: Fix bug: should test set_alt function pointer before use it") Signed-off-by: Krzysztof Opasiak Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 02578fc2d6f4c647ca8e53bbefb6342a8fb01d7e Author: Alan Stern Date: Wed Dec 14 14:55:56 2016 -0500 USB: dummy-hcd: fix bug in stop_activity (handle ep0) commit bcdbeb844773333d2d1c08004f3b3e25921040e5 upstream. The stop_activity() routine in dummy-hcd is supposed to unlink all active requests for every endpoint, among other things. But it doesn't handle ep0. As a result, fuzz testing can generate a WARNING like the following: WARNING: CPU: 0 PID: 4410 at drivers/usb/gadget/udc/dummy_hcd.c:672 dummy_free_request+0x153/0x170 Modules linked in: CPU: 0 PID: 4410 Comm: syz-executor Not tainted 4.9.0-rc7+ #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffff88006a64ed10 ffffffff81f96b8a ffffffff41b58ab3 1ffff1000d4c9d35 ffffed000d4c9d2d ffff880065f8ac00 0000000041b58ab3 ffffffff8598b510 ffffffff81f968f8 0000000041b58ab3 ffffffff859410e0 ffffffff813f0590 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x292/0x398 lib/dump_stack.c:51 [] __warn+0x19f/0x1e0 kernel/panic.c:550 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585 [] dummy_free_request+0x153/0x170 drivers/usb/gadget/udc/dummy_hcd.c:672 [] usb_ep_free_request+0xc0/0x420 drivers/usb/gadget/udc/core.c:195 [] gadgetfs_unbind+0x131/0x190 drivers/usb/gadget/legacy/inode.c:1612 [] usb_gadget_remove_driver+0x10f/0x2b0 drivers/usb/gadget/udc/core.c:1228 [] usb_gadget_unregister_driver+0x154/0x240 drivers/usb/gadget/udc/core.c:1357 This patch fixes the problem by iterating over all the endpoints in the driver's ep array instead of iterating over the gadget's ep_list, which explicitly leaves out ep0. Signed-off-by: Alan Stern Reported-by: Andrey Konovalov Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 8597a9245181656ae2ef341906e5f40af323fbca Author: Alan Stern Date: Mon Dec 19 12:03:41 2016 -0500 USB: fix problems with duplicate endpoint addresses commit 0a8fd1346254974c3a852338508e4a4cddbb35f1 upstream. When checking a new device's descriptors, the USB core does not check for duplicate endpoint addresses. This can cause a problem when the sysfs files for those endpoints are created; trying to create multiple files with the same name will provoke a WARNING: WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0 sysfs: cannot create duplicate filename '/devices/platform/dummy_hcd.0/usb2/2-1/2-1:64.0/ep_05' Kernel panic - not syncing: panic_on_warn set ... CPU: 2 PID: 865 Comm: kworker/2:1 Not tainted 4.9.0-rc7+ #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event ffff88006bee64c8 ffffffff81f96b8a ffffffff00000001 1ffff1000d7dcc2c ffffed000d7dcc24 0000000000000001 0000000041b58ab3 ffffffff8598b510 ffffffff81f968f8 ffffffff850fee20 ffffffff85cff020 dffffc0000000000 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x292/0x398 lib/dump_stack.c:51 [] panic+0x1cb/0x3a9 kernel/panic.c:179 [] __warn+0x1c4/0x1e0 kernel/panic.c:542 [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565 [] sysfs_warn_dup+0x8a/0xa0 fs/sysfs/dir.c:30 [] sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:59 [< inline >] create_dir lib/kobject.c:71 [] kobject_add_internal+0x227/0xa60 lib/kobject.c:229 [< inline >] kobject_add_varg lib/kobject.c:366 [] kobject_add+0x139/0x220 lib/kobject.c:411 [] device_add+0x353/0x1660 drivers/base/core.c:1088 [] device_register+0x1d/0x20 drivers/base/core.c:1206 [] usb_create_ep_devs+0x163/0x260 drivers/usb/core/endpoint.c:195 [] create_intf_ep_devs+0x13b/0x200 drivers/usb/core/message.c:1030 [] usb_set_configuration+0x1083/0x18d0 drivers/usb/core/message.c:1937 [] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:172 [] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:263 This patch prevents the problem by checking for duplicate endpoint addresses during enumeration and skipping any duplicates. Signed-off-by: Alan Stern Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Jiri Slaby commit 8e60e3f7a747b310e019312a761c145f10c6bb7d Author: Alan Stern Date: Fri Dec 9 15:24:24 2016 -0500 USB: gadgetfs: fix checks of wTotalLength in config descriptors commit 1c069b057dcf64fada952eaa868d35f02bb0cfc2 upstream. Andrey Konovalov's fuzz testing of gadgetfs showed that we should improve the driver's checks for valid configuration descriptors passed in by the user. In particular, the driver needs to verify that the wTotalLength value in the descriptor is not too short (smaller than USB_DT_CONFIG_SIZE). And the check for whether wTotalLength is too large has to be changed, because the driver assumes there is always enough room remaining in the buffer to hold a device descriptor (at least USB_DT_DEVICE_SIZE bytes). This patch adds the additional check and fixes the existing check. It may do a little more than strictly necessary, but one extra check won't hurt. Signed-off-by: Alan Stern CC: Andrey Konovalov Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit c67399bee66b13c6a9411679b102aa068fd8036d Author: Alan Stern Date: Fri Dec 9 15:18:43 2016 -0500 USB: gadgetfs: fix use-after-free bug commit add333a81a16abbd4f106266a2553677a165725f upstream. Andrey Konovalov reports that fuzz testing with syzkaller causes a KASAN use-after-free bug report in gadgetfs: BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr ffff88003dfe5bf2 Read of size 2 by task syz-executor0/22994 CPU: 3 PID: 22994 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffff88006df06a18 ffffffff81f96aba ffffffffe0528500 1ffff1000dbe0cd6 ffffed000dbe0cce ffff88006df068f0 0000000041b58ab3 ffffffff8598b4c8 ffffffff81f96828 1ffff1000dbe0ccd ffff88006df06708 ffff88006df06748 Call Trace: [ 201.343209] [< inline >] __dump_stack lib/dump_stack.c:15 [ 201.343209] [] dump_stack+0x292/0x398 lib/dump_stack.c:51 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159 [< inline >] print_address_description mm/kasan/report.c:197 [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286 [< inline >] kasan_report mm/kasan/report.c:306 [] __asan_report_load_n_noabort+0x3a/0x40 mm/kasan/report.c:337 [< inline >] config_buf drivers/usb/gadget/legacy/inode.c:1298 [] gadgetfs_setup+0x208a/0x20e0 drivers/usb/gadget/legacy/inode.c:1368 [] dummy_timer+0x11f0/0x36d0 drivers/usb/gadget/udc/dummy_hcd.c:1858 [] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308 [< inline >] expire_timers kernel/time/timer.c:1348 [] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641 [] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654 [] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284 The cause of the bug is subtle. The dev_config() routine gets called twice by the fuzzer. The first time, the user data contains both a full-speed configuration descriptor and a high-speed config descriptor, causing dev->hs_config to be set. But it also contains an invalid device descriptor, so the buffer containing the descriptors is deallocated and dev_config() returns an error. The second time dev_config() is called, the user data contains only a full-speed config descriptor. But dev->hs_config still has the stale pointer remaining from the first call, causing the routine to think that there is a valid high-speed config. Later on, when the driver dereferences the stale pointer to copy that descriptor, we get a use-after-free access. The fix is simple: Clear dev->hs_config if the passed-in data does not contain a high-speed config descriptor. Signed-off-by: Alan Stern Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 68613ff444e2652aa77f2f27c9476a831c4ddb89 Author: Alan Stern Date: Fri Dec 9 15:17:46 2016 -0500 USB: gadgetfs: fix unbounded memory allocation bug commit faab50984fe6636e616c7cc3d30308ba391d36fd upstream. Andrey Konovalov reports that fuzz testing with syzkaller causes a KASAN warning in gadgetfs: BUG: KASAN: slab-out-of-bounds in dev_config+0x86f/0x1190 at addr ffff88003c47e160 Write of size 65537 by task syz-executor0/6356 CPU: 3 PID: 6356 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffff88003c107ad8 ffffffff81f96aba ffffffff3dc11ef0 1ffff10007820eee ffffed0007820ee6 ffff88003dc11f00 0000000041b58ab3 ffffffff8598b4c8 ffffffff81f96828 ffffffff813fb4a0 ffff88003b6eadc0 ffff88003c107738 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x292/0x398 lib/dump_stack.c:51 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159 [< inline >] print_address_description mm/kasan/report.c:197 [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286 [] kasan_report+0x35/0x40 mm/kasan/report.c:306 [< inline >] check_memory_region_inline mm/kasan/kasan.c:308 [] check_memory_region+0x139/0x190 mm/kasan/kasan.c:315 [] kasan_check_write+0x14/0x20 mm/kasan/kasan.c:326 [< inline >] copy_from_user arch/x86/include/asm/uaccess.h:689 [< inline >] ep0_write drivers/usb/gadget/legacy/inode.c:1135 [] dev_config+0x86f/0x1190 drivers/usb/gadget/legacy/inode.c:1759 [] __vfs_write+0x5d5/0x760 fs/read_write.c:510 [] vfs_write+0x170/0x4e0 fs/read_write.c:560 [< inline >] SYSC_write fs/read_write.c:607 [] SyS_write+0xfb/0x230 fs/read_write.c:599 [] entry_SYSCALL_64_fastpath+0x1f/0xc2 Indeed, there is a comment saying that the value of len is restricted to a 16-bit integer, but the code doesn't actually do this. This patch fixes the warning. It replaces the comment with a computation that forces the amount of data copied from the user in ep0_write() to be no larger than the wLength size for the control transfer, which is a 16-bit quantity. Signed-off-by: Alan Stern Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit edac17655c94b1c734b719e8e077951293c60277 Author: Greg Kroah-Hartman Date: Tue Dec 6 08:36:29 2016 +0100 usb: gadgetfs: restrict upper bound on device configuration size commit 0994b0a257557e18ee8f0b7c5f0f73fe2b54eec1 upstream. Andrey Konovalov reported that we were not properly checking the upper limit before of a device configuration size before calling memdup_user(), which could cause some problems. So set the upper limit to PAGE_SIZE * 4, which should be good enough for all devices. Reported-by: Andrey Konovalov Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit a437aef8a780a90a1b7402dbf1db6d7f6503c840 Author: Bartosz Golaszewski Date: Wed Dec 7 16:22:16 2016 +0100 ARM: davinci: da850: don't add emac clock to lookup table twice commit ef37427ac5677331145ab27a17e6f5f1b43f0c11 upstream. Similarly to the aemif clock - this screws up the linked list of clock children. Create a separate clock for mdio inheriting the rate from emac_clk. Signed-off-by: Bartosz Golaszewski [nsekhar@ti.com: add a comment over mdio_clk to explaing its existence + commit headline updates] Signed-off-by: Sekhar Nori Signed-off-by: Jiri Slaby commit f3b65e8b56e38dd8adf8b90cd74876dd5a73737e Author: Takashi Iwai Date: Wed Jan 4 21:38:16 2017 +0100 ALSA: hda - Apply asus-mode8 fixup to ASUS X71SL commit c7efff9284dfde95a11aaa811c9d8ec8167f0f6e upstream. Although the old quirk table showed ASUS X71SL with ALC663 codec being compatible with asus-mode3 fixup, the bugzilla reporter explained that asus-model8 fits better for the dual headphone controls. So be it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=191781 Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit c8f002b3795493554ebf4c34ae68d8ca0e89d783 Author: Takashi Iwai Date: Tue Dec 6 16:20:36 2016 +0100 ALSA: hda - Fix up GPIO for ASUS ROG Ranger commit 85bcf96caba8b4a7c0805555638629ba3c67ea0c upstream. ASUS ROG Ranger VIII with ALC1150 codec requires the extra GPIO pin to up for the front panel. Just use the existing fixup for setting up the GPIO pins. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189411 Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit b98a176351a1b810790e3ba28171459eed8bc09f Author: Heikki Krogerus Date: Fri Apr 1 17:13:11 2016 +0300 usb: dwc3: pci: add Intel Kabylake PCI ID commit 4491ed5042f0419b22a4b08331adb54af31e2caa upstream. Intel Kabylake PCH has the same DWC3 than Intel Sunrisepoint. Add the new ID to the supported devices. Signed-off-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 80f5acd71675ae967f52ef123b5745d6060844ba Author: Heikki Krogerus Date: Fri Apr 1 17:13:10 2016 +0300 usb: dwc3: pci: add ID for one more Intel Broxton platform commit 1ffb4d5cc78a3a99109ff0808ce6915de07a0588 upstream. BXT-M is a Intel Broxton SoC based platform with unique PCI ID. Signed-off-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 1ef06fc8832355068ae38b8b69e2d3313f8015f1 Author: Heikki Krogerus Date: Wed Oct 21 14:37:04 2015 +0300 usb: dwc3: pci: add support for Intel Broxton SOC commit b4c580a43d520b7812c0fd064fbab929ce2f1da0 upstream. PCI IDs for Broxton based platforms. Signed-off-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 91c428dfde78265eb71f73dabe4791ceb77c6d98 Author: Heikki Krogerus Date: Thu Dec 18 16:39:14 2014 +0200 usb: dwc3: pci: add support for Intel Sunrise Point PCH commit 84a2b61b6eb94036093531cdabc448dddfbae45a upstream. Add PCI IDs for Intel Sunrise Point PCH. Signed-off-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit a5ebeb0906b3ac4bce51a4ea7a0a80550016f824 Author: Alan Cox Date: Wed Sep 24 10:40:25 2014 +0300 usb: dwc3: pci: Add PCI ID for Intel Braswell commit 7d643664ea559b36188cae264047ce3c9bfec3a2 upstream. The device controller is the same but it has different PCI ID. Add this new ID to the driver's list of supported IDs. Signed-off-by: Alan Cox Signed-off-by: Mika Westerberg Signed-off-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 47dd81993b5f990ff1a82da585334c1a5f35aaa4 Author: Rafal Redzimski Date: Fri Apr 8 16:25:05 2016 +0300 usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host commit 0d46faca6f887a849efb07c1655b5a9f7c288b45 upstream. Broxton B0 also requires XHCI_PME_STUCK_QUIRK. Adding PCI device ID for Broxton B and adding to quirk. Signed-off-by: Rafal Redzimski Signed-off-by: Robert Dobrowolski Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 2a6efbf11e58b0d2771edf8e4e0c60ffc04d4155 Author: Lu Baolu Date: Tue Jan 26 17:50:08 2016 +0200 usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms commit ccc04afb72cddbdf7c0e1c17e92886405a71b754 upstream. Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well. Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 14983bc422bf2035845f097efd0411885c92a283 Author: Steven Rostedt Date: Mon May 16 23:00:35 2016 -0400 ftrace/x86: Set ftrace_stub to weak to prevent gcc from using short jumps to it commit 8329e818f14926a6040df86b2668568bde342ebf upstream. Matt Fleming reported seeing crashes when enabling and disabling function profiling which uses function graph tracer. Later Namhyung Kim hit a similar issue and he found that the issue was due to the jmp to ftrace_stub in ftrace_graph_call was only two bytes, and when it was changed to jump to the tracing code, it overwrote the ftrace_stub that was after it. Masami Hiramatsu bisected this down to a binutils change: 8dcea93252a9ea7dff57e85220a719e2a5e8ab41 is the first bad commit commit 8dcea93252a9ea7dff57e85220a719e2a5e8ab41 Author: H.J. Lu Date: Fri May 15 03:17:31 2015 -0700 Add -mshared option to x86 ELF assembler This patch adds -mshared option to x86 ELF assembler. By default, assembler will optimize out non-PLT relocations against defined non-weak global branch targets with default visibility. The -mshared option tells the assembler to generate code which may go into a shared library where all non-weak global branch targets with default visibility can be preempted. The resulting code is slightly bigger. This option only affects the handling of branch instructions. Declaring ftrace_stub as a weak call prevents gas from using two byte jumps to it, which would be converted to a jump to the function graph code. Link: http://lkml.kernel.org/r/20160516230035.1dbae571@gandalf.local.home Reported-by: Matt Fleming Reported-by: Namhyung Kim Tested-by: Matt Fleming Reviewed-by: Masami Hiramatsu Signed-off-by: Steven Rostedt Signed-off-by: Jiri Slaby commit 7eb9e6472cbdd8e2df774ae91531c8959e21dbbc Author: Al Viro Date: Fri Dec 16 13:42:06 2016 -0500 sg_write()/bsg_write() is not fit to be called under KERNEL_DS commit 128394eff343fc6d2f32172f03e24829539c5835 upstream. Both damn things interpret userland pointers embedded into the payload; worse, they are actually traversing those. Leaving aside the bad API design, this is very much _not_ safe to call with KERNEL_DS. Bail out early if that happens. Signed-off-by: Al Viro Signed-off-by: Jiri Slaby commit da2f9e2e1ab1bc654870c5accd09209aa531d2cd Author: Ben Hutchings Date: Thu Nov 24 22:10:23 2016 +0000 kconfig/nconf: Fix hang when editing symbol with a long prompt commit 79e51b5c2deea542b3bb8c66e0d502230b017dde upstream. Currently it is impossible to edit the value of a config symbol with a prompt longer than (terminal width - 2) characters. dialog_inputbox() calculates a negative x-offset for the input window and newwin() fails as this is invalid. It also doesn't check for this failure, so it busy-loops calling wgetch(NULL) which immediately returns -1. The additions in the offset calculations also don't match the intended size of the window. Limit the window size and calculate the offset similarly to show_scroll_win(). Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)") Signed-off-by: Ben Hutchings Signed-off-by: Jiri Slaby commit af9d2aba36c0e5deb79303cd30ec2a096bbe2eb2 Author: Segher Boessenkool Date: Thu Oct 6 13:42:19 2016 +0000 powerpc: Convert cmp to cmpd in idle enter sequence commit 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 upstream. PowerPC's "cmp" instruction has four operands. Normally people write "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently people forget, and write "cmp" with just three operands. With older binutils this is silently accepted as if this was "cmpw", while often "cmpd" is wanted. With newer binutils GAS will complain about this for 64-bit code. For 32-bit code it still silently assumes "cmpw" is what is meant. In this instance the code comes directly from ISA v2.07, including the cmp, but cmpd is correct. Backport to stable so that new toolchains can build old kernels. Fixes: 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode") Reviewed-by: Vaidyanathan Srinivasan Signed-off-by: Segher Boessenkool Signed-off-by: Michael Ellerman Signed-off-by: Joel Stanley Signed-off-by: Jiri Slaby commit 818e30354928edc4d19a22bef2a62a6e1ef13d72 Author: Geoff Levand Date: Tue Nov 29 10:47:32 2016 -0800 powerpc/ps3: Fix system hang with GCC 5 builds commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream. GCC 5 generates different code for this bootwrapper null check that causes the PS3 to hang very early in its bootup. This check is of limited value, so just get rid of it. Signed-off-by: Geoff Levand Signed-off-by: Michael Ellerman Signed-off-by: Jiri Slaby commit 274125f9db7a9bad1ffdbad5e84f4f1a5566ca42 Author: Al Viro Date: Mon Sep 5 21:42:32 2016 -0400 nfs_write_end(): fix handling of short copies commit c0cf3ef5e0f47e385920450b245d22bead93e7ad upstream. What matters when deciding if we should make a page uptodate is not how much we _wanted_ to copy, but how much we actually have copied. As it is, on architectures that do not zero tail on short copy we can leave uninitialized data in page marked uptodate. Signed-off-by: Al Viro Signed-off-by: Jiri Slaby commit b8e9e113b99b59b6e25a89d07f5aa3ce53882dbd Author: Ilya Dryomov Date: Fri Dec 2 16:35:09 2016 +0100 libceph: verify authorize reply on connect commit 5c056fdc5b474329037f2aa18401bd73033e0ce0 upstream. After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b), the client gets back a ceph_x_authorize_reply, which it is supposed to verify to ensure the authenticity and protect against replay attacks. The code for doing this is there (ceph_x_verify_authorizer_reply(), ceph_auth_verify_authorizer_reply() + plumbing), but it is never invoked by the the messenger. AFAICT this goes back to 2009, when ceph authentication protocols support was added to the kernel client in 4e7a5dcd1bba ("ceph: negotiate authentication protocol; implement AUTH_NONE protocol"). The second param of ceph_connection_operations::verify_authorizer_reply is unused all the way down. Pass 0 to facilitate backporting, and kill it in the next commit. Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Jiri Slaby commit d211a4a213606096dc389e238aecbfec6723528a Author: Alan Stern Date: Fri Oct 21 16:45:38 2016 -0400 PCI: Check for PME in targeted sleep state commit 6496ebd7edf446fccf8266a1a70ffcb64252593e upstream. One some systems, the firmware does not allow certain PCI devices to be put in deep D-states. This can cause problems for wakeup signalling, if the device does not support PME# in the deepest allowed suspend state. For example, Pierre reports that on his system, ACPI does not permit his xHCI host controller to go into D3 during runtime suspend -- but D3 is the only state in which the controller can generate PME# signals. As a result, the controller goes into runtime suspend but never wakes up, so it doesn't work properly. USB devices plugged into the controller are never detected. If the device relies on PME# for wakeup signals but is not capable of generating PME# in the target state, the PCI core should accurately report that it cannot do wakeup from runtime suspend. This patch modifies the pci_dev_run_wake() routine to add this check. Reported-by: Pierre de Villemereuil Tested-by: Pierre de Villemereuil Signed-off-by: Alan Stern Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki CC: Lukas Wunner Signed-off-by: Jiri Slaby commit aacf6f08b4bd26f9eea51b3dec9cbfe2b4618e68 Author: Bart Van Assche Date: Mon Nov 21 10:22:17 2016 -0800 IB/multicast: Check ib_find_pkey() return value commit d3a2418ee36a59bc02e9d454723f3175dcf4bfd9 upstream. This patch avoids that Coverity complains about not checking the ib_find_pkey() return value. Fixes: commit 547af76521b3 ("IB/multicast: Report errors on multicast groups if P_key changes") Signed-off-by: Bart Van Assche Cc: Sean Hefty Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 9d765155118475ccc87664026cb29636c4b18c04 Author: Bart Van Assche Date: Mon Nov 21 10:21:17 2016 -0800 IB/mad: Fix an array index check commit 2fe2f378dd45847d2643638c07a7658822087836 upstream. The array ib_mad_mgmt_class_table.method_table has MAX_MGMT_CLASS (80) elements. Hence compare the array index with that value instead of with IB_MGMT_MAX_METHODS (128). This patch avoids that Coverity reports the following: Overrunning array class->method_table of 80 8-byte elements at element index 127 (byte offset 1016) using index convert_mgmt_class(mad_hdr->mgmt_class) (which evaluates to 127). Fixes: commit b7ab0b19a85f ("IB/mad: Verify mgmt class in received MADs") Signed-off-by: Bart Van Assche Cc: Sean Hefty Reviewed-by: Hal Rosenstock Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 7a2a5f7c2e9b4653385c2f0094e96ce3abc7b43a Author: Steven Rostedt (Red Hat) Date: Thu Dec 8 12:48:26 2016 -0500 ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it commit 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 upstream. With new binutils, gcc may get smart with its optimization and change a jmp from a 5 byte jump to a 2 byte one even though it was jumping to a global function. But that global function existed within a 2 byte radius, and gcc was able to optimize it. Unfortunately, that jump was also being modified when function graph tracing begins. Since ftrace expected that jump to be 5 bytes, but it was only two, it overwrote code after the jump, causing a crash. This was fixed for x86_64 with commit 8329e818f149, with the same subject as this commit, but nothing was done for x86_32. Fixes: d61f82d06672 ("ftrace: use dynamic patching for updating mcount calls") Reported-by: Colin Ian King Tested-by: Colin Ian King Signed-off-by: Steven Rostedt Signed-off-by: Jiri Slaby commit aaa9f982f5dc0a64bcc6d83cc78e690c757bcad8 Author: Jim Mattson Date: Mon Dec 12 11:01:37 2016 -0800 kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF) commit ef85b67385436ddc1998f45f1d6a210f935b3388 upstream. When L2 exits to L0 due to "exception or NMI", software exceptions (#BP and #OF) for which L1 has requested an intercept should be handled by L1 rather than L0. Previously, only hardware exceptions were forwarded to L1. Signed-off-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 1bf684a815f6df01d9a96a531c94dd72a84e4a89 Author: Konstantin Khlebnikov Date: Sun Nov 27 19:32:32 2016 +0300 md/raid5: limit request size according to implementation limits commit e8d7c33232e5fdfa761c3416539bc5b4acd12db5 upstream. Current implementation employ 16bit counter of active stripes in lower bits of bio->bi_phys_segments. If request is big enough to overflow this counter bio will be completed and freed too early. Fortunately this not happens in default configuration because several other limits prevent that: stripe_cache_size * nr_disks effectively limits count of active stripes. And small max_sectors_kb at lower disks prevent that during normal read/write operations. Overflow easily happens in discard if it's enabled by module parameter "devices_handle_discard_safely" and stripe_cache_size is set big enough. This patch limits requests size with 256Mb - 8Kb to prevent overflows. Signed-off-by: Konstantin Khlebnikov Cc: Shaohua Li Cc: Neil Brown Signed-off-by: Shaohua Li Signed-off-by: Jiri Slaby commit 22f604f0eac8189f92489a061796e94004e7aa1f Author: Gerald Schaefer Date: Mon Nov 21 12:13:58 2016 +0100 s390/vmlogrdr: fix IUCV buffer allocation commit 5457e03de918f7a3e294eb9d26a608ab8a579976 upstream. The buffer for iucv_message_receive() needs to be below 2 GB. In __iucv_message_receive(), the buffer address is casted to an u32, which would result in either memory corruption or an addressing exception when using addresses >= 2 GB. Fix this by using GFP_DMA for the buffer allocation. Signed-off-by: Gerald Schaefer Signed-off-by: Martin Schwidefsky Signed-off-by: Jiri Slaby commit 753437010e1a2883ebdcb08a5bcb979b0fbb25e0 Author: Wei Fang Date: Tue Dec 13 09:25:21 2016 +0800 scsi: avoid a permanent stop of the scsi device's request queue commit d2a145252c52792bc59e4767b486b26c430af4bb upstream. A race between scanning and fc_remote_port_delete() may result in a permanent stop if the device gets blocked before scsi_sysfs_add_sdev() and unblocked after. The reason is that blocking a device sets both the SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED. However, scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the device to be ignored by scsi_target_unblock() and thus never have its QUEUE_FLAG_STOPPED cleared leading to a device which is apparently running but has a stopped queue. We actually have two places where SDEV_RUNNING is set: once in scsi_add_lun() which respects the blocked flag and once in scsi_sysfs_add_sdev() which doesn't. Since the second set is entirely spurious, simply remove it to fix the problem. Reported-by: Zengxi Chen Signed-off-by: Wei Fang Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby commit 197663e65f08e1b6a18982984a0ae1559a76df7d Author: Steffen Maier Date: Fri Dec 9 17:16:33 2016 +0100 scsi: zfcp: fix rport unblock race with LUN recovery commit 6f2ce1c6af37191640ee3ff6e8fc39ea10352f4c upstream. It is unavoidable that zfcp_scsi_queuecommand() has to finish requests with DID_IMM_RETRY (like fc_remote_port_chkready()) during the time window when zfcp detected an unavailable rport but fc_remote_port_delete(), which is asynchronous via zfcp_scsi_schedule_rport_block(), has not yet blocked the rport. However, for the case when the rport becomes available again, we should prevent unblocking the rport too early. In contrast to other FCP LLDDs, zfcp has to open each LUN with the FCP channel hardware before it can send I/O to a LUN. So if a port already has LUNs attached and we unblock the rport just after port recovery, recoveries of LUNs behind this port can still be pending which in turn force zfcp_scsi_queuecommand() to unnecessarily finish requests with DID_IMM_RETRY. This also opens a time window with unblocked rport (until the followup LUN reopen recovery has finished). If a scsi_cmnd timeout occurs during this time window fc_timed_out() cannot work as desired and such command would indeed time out and trigger scsi_eh. This prevents a clean and timely path failover. This should not happen if the path issue can be recovered on FC transport layer such as path issues involving RSCNs. Fix this by only calling zfcp_scsi_schedule_rport_register(), to asynchronously trigger fc_remote_port_add(), after all LUN recoveries as children of the rport have finished and no new recoveries of equal or higher order were triggered meanwhile. Finished intentionally includes any recovery result no matter if successful or failed (still unblock rport so other successful LUNs work). For simplicity, we check after each finished LUN recovery if there is another LUN recovery pending on the same port and then do nothing. We handle the special case of a successful recovery of a port without LUN children the same way without changing this case's semantics. For debugging we introduce 2 new trace records written if the rport unblock attempt was aborted due to still unfinished or freshly triggered recovery. The records are only written above the default trace level. Benjamin noticed the important special case of new recovery that can be triggered between having given up the erp_lock and before calling zfcp_erp_action_cleanup() within zfcp_erp_strategy(). We must avoid the following sequence: ERP thread rport_work other context ------------------------- -------------- -------------------------------- port is unblocked, rport still blocked, due to pending/running ERP action, so ((port->status & ...UNBLOCK) != 0) and (port->rport == NULL) unlock ERP zfcp_erp_action_cleanup() case ZFCP_ERP_ACTION_REOPEN_LUN: zfcp_erp_try_rport_unblock() ((status & ...UNBLOCK) != 0) [OLD!] zfcp_erp_port_reopen() lock ERP zfcp_erp_port_block() port->status clear ...UNBLOCK unlock ERP zfcp_scsi_schedule_rport_block() port->rport_task = RPORT_DEL queue_work(rport_work) zfcp_scsi_rport_work() (port->rport_task != RPORT_ADD) port->rport_task = RPORT_NONE zfcp_scsi_rport_block() if (!port->rport) return zfcp_scsi_schedule_rport_register() port->rport_task = RPORT_ADD queue_work(rport_work) zfcp_scsi_rport_work() (port->rport_task == RPORT_ADD) port->rport_task = RPORT_NONE zfcp_scsi_rport_register() (port->rport == NULL) rport = fc_remote_port_add() port->rport = rport; Now the rport was erroneously unblocked while the zfcp_port is blocked. This is another situation we want to avoid due to scsi_eh potential. This state would at least remain until the new recovery from the other context finished successfully, or potentially forever if it failed. In order to close this race, we take the erp_lock inside zfcp_erp_try_rport_unblock() when checking the status of zfcp_port or LUN. With that, the possible corresponding rport state sequences would be: (unblock[ERP thread],block[other context]) if the ERP thread gets erp_lock first and still sees ((port->status & ...UNBLOCK) != 0), (block[other context],NOP[ERP thread]) if the ERP thread gets erp_lock after the other context has already cleard ...UNBLOCK from port->status. Since checking fields of struct erp_action is unsafe because they could have been overwritten (re-used for new recovery) meanwhile, we only check status of zfcp_port and LUN since these are only changed under erp_lock elsewhere. Regarding the check of the proper status flags (port or port_forced are similar to the shown adapter recovery): [zfcp_erp_adapter_shutdown()] zfcp_erp_adapter_reopen() zfcp_erp_adapter_block() * clear UNBLOCK ---------------------------------------+ zfcp_scsi_schedule_rports_block() | write_lock_irqsave(&adapter->erp_lock, flags);-------+ | zfcp_erp_action_enqueue() | | zfcp_erp_setup_act() | | * set ERP_INUSE -----------------------------------|--|--+ write_unlock_irqrestore(&adapter->erp_lock, flags);--+ | | .context-switch. | | zfcp_erp_thread() | | zfcp_erp_strategy() | | write_lock_irqsave(&adapter->erp_lock, flags);------+ | | ... | | | zfcp_erp_strategy_check_target() | | | zfcp_erp_strategy_check_adapter() | | | zfcp_erp_adapter_unblock() | | | * set UNBLOCK -----------------------------------|--+ | zfcp_erp_action_dequeue() | | * clear ERP_INUSE ---------------------------------|-----+ ... | write_unlock_irqrestore(&adapter->erp_lock, flags);-+ Hence, we should check for both UNBLOCK and ERP_INUSE because they are interleaved. Also we need to explicitly check ERP_FAILED for the link down case which currently does not clear the UNBLOCK flag in zfcp_fsf_link_down_info_eval(). Signed-off-by: Steffen Maier Fixes: 8830271c4819 ("[SCSI] zfcp: Dont fail SCSI commands when transitioning to blocked fc_rport") Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors") Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI") Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable") Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again") Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby commit 82a5b214798ea63c0fc4f0e7f2f574690a862ad2 Author: Steffen Maier Date: Fri Dec 9 17:16:32 2016 +0100 scsi: zfcp: do not trace pure benign residual HBA responses at default level commit 56d23ed7adf3974f10e91b643bd230e9c65b5f79 upstream. Since quite a while, Linux issues enough SCSI commands per scsi_device which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE, and SAM_STAT_GOOD. This floods the HBA trace area and we cannot see other and important HBA trace records long enough. Therefore, do not trace HBA response errors for pure benign residual under counts at the default trace level. This excludes benign residual under count combined with other validity bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL. For all those other cases, we still do want to see both the HBA record and the corresponding SCSI record by default. Signed-off-by: Steffen Maier Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby commit bd8d14a5fddb03897702d01f59da67b422c93863 Author: Benjamin Block Date: Fri Dec 9 17:16:31 2016 +0100 scsi: zfcp: fix use-after-"free" in FC ingress path after TMF commit dac37e15b7d511e026a9313c8c46794c144103cd upstream. When SCSI EH invokes zFCP's callbacks for eh_device_reset_handler() and eh_target_reset_handler(), it expects us to relent the ownership over the given scsi_cmnd and all other scsi_cmnds within the same scope - LUN or target - when returning with SUCCESS from the callback ('release' them). SCSI EH can then reuse those commands. We did not follow this rule to release commands upon SUCCESS; and if later a reply arrived for one of those supposed to be released commands, we would still make use of the scsi_cmnd in our ingress tasklet. This will at least result in undefined behavior or a kernel panic because of a wrong kernel pointer dereference. To fix this, we NULLify all pointers to scsi_cmnds (struct zfcp_fsf_req *)->data in the matching scope if a TMF was successful. This is done under the locks (struct zfcp_adapter *)->abort_lock and (struct zfcp_reqlist *)->lock to prevent the requests from being removed from the request-hashtable, and the ingress tasklet from making use of the scsi_cmnd-pointer in zfcp_fsf_fcp_cmnd_handler(). For cases where a reply arrives during SCSI EH, but before we get a chance to NULLify the pointer - but before we return from the callback -, we assume that the code is protected from races via the CAS operation in blk_complete_request() that is called in scsi_done(). The following stacktrace shows an example for a crash resulting from the previous behavior: Unable to handle kernel pointer dereference at virtual kernel address fffffee17a672000 Oops: 0038 [#1] SMP CPU: 2 PID: 0 Comm: swapper/2 Not tainted task: 00000003f7ff5be0 ti: 00000003f3d38000 task.ti: 00000003f3d38000 Krnl PSW : 0404d00180000000 00000000001156b0 (smp_vcpu_scheduled+0x18/0x40) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3 Krnl GPRS: 000000200000007e 0000000000000000 fffffee17a671fd8 0000000300000015 ffffffff80000000 00000000005dfde8 07000003f7f80e00 000000004fa4e800 000000036ce8d8f8 000000036ce8d9c0 00000003ece8fe00 ffffffff969c9e93 00000003fffffffd 000000036ce8da10 00000000003bf134 00000003f3b07918 Krnl Code: 00000000001156a2: a7190000 lghi %r1,0 00000000001156a6: a7380015 lhi %r3,21 #00000000001156aa: e32050000008 ag %r2,0(%r5) >00000000001156b0: 482022b0 lh %r2,688(%r2) 00000000001156b4: ae123000 sigp %r1,%r2,0(%r3) 00000000001156b8: b2220020 ipm %r2 00000000001156bc: 8820001c srl %r2,28 00000000001156c0: c02700000001 xilf %r2,1 Call Trace: ([<0000000000000000>] 0x0) [<000003ff807bdb8e>] zfcp_fsf_fcp_cmnd_handler+0x3de/0x490 [zfcp] [<000003ff807be30a>] zfcp_fsf_req_complete+0x252/0x800 [zfcp] [<000003ff807c0a48>] zfcp_fsf_reqid_check+0xe8/0x190 [zfcp] [<000003ff807c194e>] zfcp_qdio_int_resp+0x66/0x188 [zfcp] [<000003ff80440c64>] qdio_kick_handler+0xdc/0x310 [qdio] [<000003ff804463d0>] __tiqdio_inbound_processing+0xf8/0xcd8 [qdio] [<0000000000141fd4>] tasklet_action+0x9c/0x170 [<0000000000141550>] __do_softirq+0xe8/0x258 [<000000000010ce0a>] do_softirq+0xba/0xc0 [<000000000014187c>] irq_exit+0xc4/0xe8 [<000000000046b526>] do_IRQ+0x146/0x1d8 [<00000000005d6a3c>] io_return+0x0/0x8 [<00000000005d6422>] vtime_stop_cpu+0x4a/0xa0 ([<0000000000000000>] 0x0) [<0000000000103d8a>] arch_cpu_idle+0xa2/0xb0 [<0000000000197f94>] cpu_startup_entry+0x13c/0x1f8 [<0000000000114782>] smp_start_secondary+0xda/0xe8 [<00000000005d6efe>] restart_int_handler+0x56/0x6c [<0000000000000000>] 0x0 Last Breaking-Event-Address: [<00000000003bf12e>] arch_spin_lock_wait+0x56/0xb0 Suggested-by: Steffen Maier Signed-off-by: Benjamin Block Fixes: ea127f9754 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git) Signed-off-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby commit 2a0a8ae2e0acb6e7bcacf111d12d1c5d4cfc026c Author: Rabin Vincent Date: Thu Dec 1 09:18:28 2016 +0100 block: protect iterate_bdevs() against concurrent close commit af309226db916e2c6e08d3eba3fa5c34225200c4 upstream. If a block device is closed while iterate_bdevs() is handling it, the following NULL pointer dereference occurs because bdev->b_disk is NULL in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in turn called by the mapping_cap_writeback_dirty() call in __filemap_fdatawrite_range()): BUG: unable to handle kernel NULL pointer dereference at 0000000000000508 IP: [] blk_get_backing_dev_info+0x10/0x20 PGD 9e62067 PUD 9ee8067 PMD 0 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000 RIP: 0010:[] [] blk_get_backing_dev_info+0x10/0x20 RSP: 0018:ffff880009f5fe68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940 RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0 RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860 R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38 FS: 00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0 Stack: ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff 0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001 ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f Call Trace: [] __filemap_fdatawrite_range+0x85/0x90 [] filemap_fdatawrite+0x1f/0x30 [] fdatawrite_one_bdev+0x16/0x20 [] iterate_bdevs+0xf2/0x130 [] sys_sync+0x63/0x90 [] entry_SYSCALL_64_fastpath+0x12/0x76 Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d RIP [] blk_get_backing_dev_info+0x10/0x20 RSP CR2: 0000000000000508 ---[ end trace 2487336ceb3de62d ]--- The crash is easily reproducible by running the following command, if an msleep(100) is inserted before the call to func() in iterate_devs(): while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done Fix it by holding the bd_mutex across the func() call and only calling func() if the bdev is opened. Fixes: 5c0d6b60a0ba ("vfs: Create function for iterating over block devices") Reported-and-tested-by: Wei Fang Signed-off-by: Rabin Vincent Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Jiri Slaby commit 0401ed69831cc15ef99489b2c976797f2592ce32 Author: Russell Currey Date: Thu Dec 15 16:12:41 2016 +1100 drivers/gpu/drm/ast: Fix infinite loop if read fails commit 298360af3dab45659810fdc51aba0c9f4097e4f6 upstream. ast_get_dram_info() configures a window in order to access BMC memory. A BMC register can be configured to disallow this, and if so, causes an infinite loop in the ast driver which renders the system unusable. Fix this by erroring out if an error is detected. On powerpc systems with EEH, this leads to the device being fenced and the system continuing to operate. Signed-off-by: Russell Currey Reviewed-by: Joel Stanley Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161215051241.20815-1-ruscur@russell.cc Signed-off-by: Jiri Slaby commit cc61286cb5cb00956b6dfd2650efebb6b3ef7eb1 Author: Patrik Jakobsson Date: Tue Nov 1 15:43:15 2016 +0100 drm/gma500: Add compat ioctl commit 0a97c81a9717431e6c57ea845b59c3c345edce67 upstream. Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels. It turns out that N2600 and N2800 comes with 64-bit enabled. We previously assumed there where no such systems out there. Signed-off-by: Patrik Jakobsson Signed-off-by: Sean Paul Link: http://patchwork.freedesktop.org/patch/msgid/20161101144315.2955-1-patrik.r.jakobsson@gmail.com Signed-off-by: Jiri Slaby commit 83adc27e54af4724a1c6740abe6038d7288ae042 Author: Alex Deucher Date: Fri Dec 2 00:21:48 2016 -0500 drm/radeon: add additional pci revision to dpm workaround commit 8729675c00a8d13cb2094d617d70a4a4da7d83c5 upstream. New variant. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 9aaa0c7ce40861796fe76b806a65f5a8e0c602d0 Author: Krzysztof Kozlowski Date: Tue Nov 22 19:22:44 2016 +0200 thermal: hwmon: Properly report critical temperature in sysfs commit f37fabb8643eaf8e3b613333a72f683770c85eca upstream. In the critical sysfs entry the thermal hwmon was returning wrong temperature to the user-space. It was reporting the temperature of the first trip point instead of the temperature of critical trip point. For example: /sys/class/hwmon/hwmon0/temp1_crit:50000 /sys/class/thermal/thermal_zone0/trip_point_0_temp:50000 /sys/class/thermal/thermal_zone0/trip_point_0_type:active /sys/class/thermal/thermal_zone0/trip_point_3_temp:120000 /sys/class/thermal/thermal_zone0/trip_point_3_type:critical Since commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver have been registering a sysfs entry if get_crit_temp() callback was provided. However when accessed, it was calling get_trip_temp() instead of the get_crit_temp(). Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Zhang Rui Signed-off-by: Jiri Slaby commit a906df2c4b9df9f3aa4abc1955a007abd1a7697c Author: Larry Finger Date: Sat Nov 5 14:08:57 2016 -0500 ssb: Fix error routine when fallback SPROM fails commit 8052d7245b6089992343c80b38b14dbbd8354651 upstream. When there is a CRC error in the SPROM read from the device, the code attempts to handle a fallback SPROM. When this also fails, the driver returns zero rather than an error code. Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Jiri Slaby commit b514c427f1ab7d666439c120efa08a8ff0d1bb8b Author: Eric Sandeen Date: Mon Dec 5 12:31:06 2016 +1100 xfs: set AGI buffer type in xlog_recover_clear_agi_bucket commit 6b10b23ca94451fae153a5cc8d62fd721bec2019 upstream. xlog_recover_clear_agi_bucket didn't set the type to XFS_BLFT_AGI_BUF, so we got a warning during log replay (or an ASSERT on a debug build). XFS (md0): Unknown buffer type 0! XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1 Fix this, as was done in f19b872b for 2 other locations with the same problem. Signed-off-by: Eric Sandeen Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Jiri Slaby commit b7e205581feb5e3ba3a02582379027c777d986e6 Author: Julien Grall Date: Wed Dec 7 12:24:40 2016 +0000 arm/xen: Use alloc_percpu rather than __alloc_percpu commit 24d5373dda7c00a438d26016bce140299fae675e upstream. The function xen_guest_init is using __alloc_percpu with an alignment which are not power of two. However, the percpu allocator never supported alignments which are not power of two and has always behaved incorectly in thise case. Commit 3ca45a4 "percpu: ensure requested alignment is power of two" introduced a check which trigger a warning [1] when booting linux-next on Xen. But in reality this bug was always present. This can be fixed by replacing the call to __alloc_percpu with alloc_percpu. The latter will use an alignment which are a power of two. [1] [ 0.023921] illegal size (48) or align (48) for percpu allocation [ 0.024167] ------------[ cut here ]------------ [ 0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0 [ 0.024584] Modules linked in: [ 0.024708] [ 0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7-next-20161128 #473 [ 0.025012] Hardware name: Foundation-v8A (DT) [ 0.025162] task: ffff80003d870000 task.stack: ffff80003d844000 [ 0.025351] PC is at pcpu_alloc+0x88/0x6c0 [ 0.025490] LR is at pcpu_alloc+0x88/0x6c0 [ 0.025624] pc : [] lr : [] pstate: 60000045 [ 0.025830] sp : ffff80003d847cd0 [ 0.025946] x29: ffff80003d847cd0 x28: 0000000000000000 [ 0.026147] x27: 0000000000000000 x26: 0000000000000000 [ 0.026348] x25: 0000000000000000 x24: 0000000000000000 [ 0.026549] x23: 0000000000000000 x22: 00000000024000c0 [ 0.026752] x21: ffff000008e97000 x20: 0000000000000000 [ 0.026953] x19: 0000000000000030 x18: 0000000000000010 [ 0.027155] x17: 0000000000000a3f x16: 00000000deadbeef [ 0.027357] x15: 0000000000000006 x14: ffff000088f79c3f [ 0.027573] x13: ffff000008f79c4d x12: 0000000000000041 [ 0.027782] x11: 0000000000000006 x10: 0000000000000042 [ 0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c [ 0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84 [ 0.028419] x5 : 0000000000000005 x4 : 0000000000000000 [ 0.028628] x3 : 0000000000000000 x2 : 000000000000017f [ 0.028840] x1 : ffff80003d870000 x0 : 0000000000000035 [ 0.029056] [ 0.029152] ---[ end trace 0000000000000000 ]--- [ 0.029297] Call trace: [ 0.029403] Exception stack(0xffff80003d847b00 to 0xffff80003d847c30) [ 0.029621] 7b00: 0000000000000030 0001000000000000 ffff80003d847cd0 ffff00000818e678 [ 0.029901] 7b20: 0000000000000002 0000000000000004 ffff000008f7c060 0000000000000035 [ 0.030153] 7b40: ffff000008f79000 ffff000008c4cd88 ffff80003d847bf0 ffff000008101778 [ 0.030402] 7b60: 0000000000000030 0000000000000000 ffff000008e97000 00000000024000c0 [ 0.030647] 7b80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.030895] 7ba0: 0000000000000035 ffff80003d870000 000000000000017f 0000000000000000 [ 0.031144] 7bc0: 0000000000000000 0000000000000005 ffff000008f79c84 6120757063726570 [ 0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40 0000000000000042 0000000000000006 [ 0.031643] 7c00: 0000000000000041 ffff000008f79c4d ffff000088f79c3f 0000000000000006 [ 0.031877] 7c20: 00000000deadbeef 0000000000000a3f [ 0.032051] [] pcpu_alloc+0x88/0x6c0 [ 0.032229] [] __alloc_percpu+0x18/0x20 [ 0.032409] [] xen_guest_init+0x174/0x2f4 [ 0.032591] [] do_one_initcall+0x38/0x130 [ 0.032783] [] kernel_init_freeable+0xe0/0x248 [ 0.032995] [] kernel_init+0x10/0x100 [ 0.033172] [] ret_from_fork+0x10/0x50 Reported-by: Wei Chen Link: https://lkml.org/lkml/2016/11/28/669 Signed-off-by: Julien Grall Signed-off-by: Stefano Stabellini Reviewed-by: Stefano Stabellini Signed-off-by: Jiri Slaby commit 7c5f94349ac6b14a42469bc0909e63a0e77cdb21 Author: Boris Ostrovsky Date: Mon Nov 21 09:56:06 2016 -0500 xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing commit 30faaafdfa0c754c91bac60f216c9f34a2bfdf7e upstream. Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to NUMA balancing") set VM_IO flag to prevent grant maps from being subjected to NUMA balancing. It was discovered recently that this flag causes get_user_pages() to always fail with -EFAULT. check_vma_flags __get_user_pages __get_user_pages_locked __get_user_pages_unlocked get_user_pages_fast iov_iter_get_pages dio_refill_pages do_direct_IO do_blockdev_direct_IO do_blockdev_direct_IO ext4_direct_IO_read generic_file_read_iter aio_run_iocb (which can happen if guest's vdisk has direct-io-safe option). To avoid this let's use VM_MIXEDMAP flag instead --- it prevents NUMA balancing just as VM_IO does and has no effect on check_vma_flags(). Reported-by: Olaf Hering Suggested-by: Hugh Dickins Signed-off-by: Boris Ostrovsky Acked-by: Hugh Dickins Tested-by: Olaf Hering Signed-off-by: Juergen Gross Signed-off-by: Jiri Slaby commit dd4617bd371f4b916553f7b0c6c37f3ed0562b9f Author: Pavel Shilovsky Date: Tue Nov 29 16:14:43 2016 -0800 CIFS: Fix a possible memory corruption in push locks commit e3d240e9d505fc67f8f8735836df97a794bbd946 upstream. If maxBuf is not 0 but less than a size of SMB2 lock structure we can end up with a memory corruption. Signed-off-by: Pavel Shilovsky Signed-off-by: Jiri Slaby commit c291abb7c7145fde99cf2b284c7b49cadfceedbe Author: Pavel Shilovsky Date: Tue Nov 29 11:30:58 2016 -0800 CIFS: Fix missing nls unload in smb2_reconnect() commit 4772c79599564bd08ee6682715a7d3516f67433f upstream. Acked-by: Sachin Prabhu Signed-off-by: Pavel Shilovsky Signed-off-by: Jiri Slaby commit 123b228a09b90b50b0a9d6eb8294cf0c42efc029 Author: Pavel Shilovsky Date: Fri Nov 4 11:50:31 2016 -0700 CIFS: Fix a possible memory corruption during reconnect commit 53e0e11efe9289535b060a51d4cf37c25e0d0f2b upstream. We can not unlock/lock cifs_tcp_ses_lock while walking through ses and tcon lists because it can corrupt list iterator pointers and a tcon structure can be released if we don't hold an extra reference. Fix it by moving a reconnect process to a separate delayed work and acquiring a reference to every tcon that needs to be reconnected. Also do not send an echo request on newly established connections. Signed-off-by: Pavel Shilovsky Signed-off-by: Jiri Slaby commit 102ddf72e8b7b07af776b8b9245afb2f9ae4c578 Author: Benjamin Marzinski Date: Wed Nov 30 17:56:14 2016 -0600 dm space map metadata: fix 'struct sm_metadata' leak on failed create commit 314c25c56c1ee5026cf99c570bdfe01847927acb upstream. In dm_sm_metadata_create() we temporarily change the dm_space_map operations from 'ops' (whose .destroy function deallocates the sm_metadata) to 'bootstrap_ops' (whose .destroy function doesn't). If dm_sm_metadata_create() fails in sm_ll_new_metadata() or sm_ll_extend(), it exits back to dm_tm_create_internal(), which calls dm_sm_destroy() with the intention of freeing the sm_metadata, but it doesn't (because the dm_space_map operations is still set to 'bootstrap_ops'). Fix this by setting the dm_space_map operations back to 'ops' if dm_sm_metadata_create() fails when it is set to 'bootstrap_ops'. [js] no nr_blocks test in 3.12 yet Signed-off-by: Benjamin Marzinski Acked-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Jiri Slaby commit 1a1314868960d4ad56226508f383aeaf7c83262c Author: Ondrej Kozina Date: Wed Nov 2 15:02:08 2016 +0100 dm crypt: mark key as invalid until properly loaded commit 265e9098bac02bc5e36cda21fdbad34cb5b2f48d upstream. In crypt_set_key(), if a failure occurs while replacing the old key (e.g. tfm->setkey() fails) the key must not have DM_CRYPT_KEY_VALID flag set. Otherwise, the crypto layer would have an invalid key that still has DM_CRYPT_KEY_VALID flag set. Signed-off-by: Ondrej Kozina Reviewed-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Jiri Slaby commit aae555fb5ad0ad7532e2eafde7928288e856d680 Author: Aleksa Sarai Date: Wed Dec 21 16:26:24 2016 +1100 fs: exec: apply CLOEXEC before changing dumpable task flags commit 613cc2b6f272c1a8ad33aefa21cad77af23139f7 upstream. If you have a process that has set itself to be non-dumpable, and it then undergoes exec(2), any CLOEXEC file descriptors it has open are "exposed" during a race window between the dumpable flags of the process being reset for exec(2) and CLOEXEC being applied to the file descriptors. This can be exploited by a process by attempting to access /proc//fd/... during this window, without requiring CAP_SYS_PTRACE. The race in question is after set_dumpable has been (for get_link, though the trace is basically the same for readlink): [vfs] -> proc_pid_link_inode_operations.get_link -> proc_pid_get_link -> proc_fd_access_allowed -> ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS); Which will return 0, during the race window and CLOEXEC file descriptors will still be open during this window because do_close_on_exec has not been called yet. As a result, the ordering of these calls should be reversed to avoid this race window. This is of particular concern to container runtimes, where joining a PID namespace with file descriptors referring to the host filesystem can result in security issues (since PRCTL_SET_DUMPABLE doesn't protect against access of CLOEXEC file descriptors -- file descriptors which may reference filesystem objects the container shouldn't have access to). Cc: dev@opencontainers.org Reported-by: Michael Crosby Signed-off-by: Aleksa Sarai Signed-off-by: Al Viro Signed-off-by: Jiri Slaby commit 9ba6fb6a61aeac873544e8805d584c42f78319b1 Author: Shaohua Li Date: Mon Dec 12 16:41:50 2016 -0800 mm/vmscan.c: set correct defer count for shrinker commit 5f33a0803bbd781de916f5c7448cbbbbc763d911 upstream. Our system uses significantly more slab memory with memcg enabled with the latest kernel. With 3.10 kernel, slab uses 2G memory, while with 4.6 kernel, 6G memory is used. The shrinker has problem. Let's see we have two memcg for one shrinker. In do_shrink_slab: 1. Check cg1. nr_deferred = 0, assume total_scan = 700. batch size is 1024, then no memory is freed. nr_deferred = 700 2. Check cg2. nr_deferred = 700. Assume freeable = 20, then total_scan = 10 or 40. Let's assume it's 10. No memory is freed. nr_deferred = 10. The deferred share of cg1 is lost in this case. kswapd will free no memory even run above steps again and again. The fix makes sure one memcg's deferred share isn't lost. Link: http://lkml.kernel.org/r/2414be961b5d25892060315fbb56bb19d81d0c07.1476227351.git.shli@fb.com Signed-off-by: Shaohua Li Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 5b0d12d3f0fb677c0cfaaf0b6a934866ec2e3f9a Author: Nicolai Stange Date: Sun Nov 20 19:57:23 2016 +0100 f2fs: set ->owner for debugfs status file's file_operations commit 05e6ea2685c964db1e675a24a4f4e2adc22d2388 upstream. The struct file_operations instance serving the f2fs/status debugfs file lacks an initialization of its ->owner. This means that although that file might have been opened, the f2fs module can still get removed. Any further operation on that opened file, releasing included, will cause accesses to unmapped memory. Indeed, Mike Marshall reported the following: BUG: unable to handle kernel paging request at ffffffffa0307430 IP: [] full_proxy_release+0x24/0x90 <...> Call Trace: [] __fput+0xdf/0x1d0 [] ____fput+0xe/0x10 [] task_work_run+0x8e/0xc0 [] do_exit+0x2ae/0xae0 [] ? __audit_syscall_entry+0xae/0x100 [] ? syscall_trace_enter+0x1ca/0x310 [] do_group_exit+0x44/0xc0 [] SyS_exit_group+0x14/0x20 [] do_syscall_64+0x61/0x150 [] entry_SYSCALL64_slow_path+0x25/0x25 <...> ---[ end trace f22ae883fa3ea6b8 ]--- Fixing recursive fault but reboot is needed! Fix this by initializing the f2fs/status file_operations' ->owner with THIS_MODULE. This will allow debugfs to grab a reference to the f2fs module upon any open on that file, thus preventing it from getting removed. Fixes: 902829aa0b72 ("f2fs: move proc files to debugfs") Reported-by: Mike Marshall Reported-by: Martin Brandenburg Signed-off-by: Nicolai Stange Signed-off-by: Jaegeuk Kim Signed-off-by: Jiri Slaby commit e832a16af900bdace442b34be24829dc6f6bf0d5 Author: Dan Carpenter Date: Sat Dec 10 09:56:01 2016 -0500 ext4: return -ENOMEM instead of success commit 578620f451f836389424833f1454eeeb2ffc9e9f upstream. We should set the error code if kzalloc() fails. Fixes: 67cf5b09a46f ("ext4: add the basic function for inline data support") Signed-off-by: Dan Carpenter Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby commit 30256224d9d4620f720be63b1e1b231a6e390ed2 Author: Darrick J. Wong Date: Sat Dec 10 09:55:01 2016 -0500 ext4: reject inodes with negative size commit 7e6e1ef48fc02f3ac5d0edecbb0c6087cd758d58 upstream. Don't load an inode with a negative size; this causes integer overflow problems in the VFS. [ Added EXT4_ERROR_INODE() to mark file system as corrupted. -TYT] js: use EIO for 3.12 instead of EFSCORRUPTED. Fixes: a48380f769df (ext4: rename i_dir_acl to i_size_high) Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby commit 2b47f7351dd6e24e54acbd6883fccc6c5650374e Author: Theodore Ts'o Date: Fri Nov 18 13:37:47 2016 -0500 ext4: add sanity checking to count_overhead() commit c48ae41bafe31e9a66d8be2ced4e42a6b57fa814 upstream. The commit "ext4: sanity check the block and cluster size at mount time" should prevent any problems, but in case the superblock is modified while the file system is mounted, add an extra safety check to make sure we won't overrun the allocated buffer. Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby commit 399cf9694d2df236121351e3263e52c556ba2383 Author: Theodore Ts'o Date: Fri Nov 18 13:24:26 2016 -0500 ext4: fix in-superblock mount options processing commit 5aee0f8a3f42c94c5012f1673420aee96315925a upstream. Fix a large number of problems with how we handle mount options in the superblock. For one, if the string in the superblock is long enough that it is not null terminated, we could run off the end of the string and try to interpret superblocks fields as characters. It's unlikely this will cause a security problem, but it could result in an invalid parse. Also, parse_options is destructive to the string, so in some cases if there is a comma-separated string, it would be modified in the superblock. (Fortunately it only happens on file systems with a 1k block size.) Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby commit de4f994b3607b3f007fae21e77d07a0c970d40f0 Author: Theodore Ts'o Date: Fri Nov 18 13:28:30 2016 -0500 ext4: use more strict checks for inodes_per_block on mount commit cd6bb35bf7f6d7d922509bf50265383a0ceabe96 upstream. Centralize the checks for inodes_per_block and be more strict to make sure the inodes_per_block_group can't end up being zero. Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Signed-off-by: Jiri Slaby commit c4c0dbd27c8f3c775b65a8bf75dd2e0aee6d1160 Author: Chandan Rajendra Date: Mon Nov 14 21:26:26 2016 -0500 ext4: fix stack memory corruption with 64k block size commit 30a9d7afe70ed6bd9191d3000e2ef1a34fb58493 upstream. The number of 'counters' elements needed in 'struct sg' is super_block->s_blocksize_bits + 2. Presently we have 16 'counters' elements in the array. This is insufficient for block sizes >= 32k. In such cases the memcpy operation performed in ext4_mb_seq_groups_show() would cause stack memory corruption. Fixes: c9de560ded61f Signed-off-by: Chandan Rajendra Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Signed-off-by: Jiri Slaby commit a844e8a76a67dd1dcdfdc23f38675055a59a682a Author: Chandan Rajendra Date: Mon Nov 14 21:04:37 2016 -0500 ext4: fix mballoc breakage with 64k block size commit 69e43e8cc971a79dd1ee5d4343d8e63f82725123 upstream. 'border' variable is set to a value of 2 times the block size of the underlying filesystem. With 64k block size, the resulting value won't fit into a 16-bit variable. Hence this commit changes the data type of 'border' to 'unsigned int'. Fixes: c9de560ded61f Signed-off-by: Chandan Rajendra Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Signed-off-by: Jiri Slaby commit a8e872c9174b100f52ac53bc8da8862f4e638a45 Author: Alex Porosanu Date: Wed Nov 9 10:46:11 2016 +0200 crypto: caam - fix AEAD givenc descriptors commit d128af17876d79b87edf048303f98b35f6a53dbc upstream. The AEAD givenc descriptor relies on moving the IV through the output FIFO and then back to the CTX2 for authentication. The SEQ FIFO STORE could be scheduled before the data can be read from OFIFO, especially since the SEQ FIFO LOAD needs to wait for the SEQ FIFO LOAD SKIP to finish first. The SKIP takes more time when the input is SG than when it's a contiguous buffer. If the SEQ FIFO LOAD is not scheduled before the STORE, the DECO will hang waiting for data to be available in the OFIFO so it can be transferred to C2. In order to overcome this, first force transfer of IV to C2 by starting the "cryptlen" transfer first and then starting to store data from OFIFO to the output buffer. Fixes: 1acebad3d8db8 ("crypto: caam - faster aead implementation") Signed-off-by: Alex Porosanu Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Jiri Slaby commit 94b87438f802c2083ad10a67f5d9a0cb8bf52dc3 Author: NeilBrown Date: Mon Dec 12 08:21:51 2016 -0700 block_dev: don't test bdev->bd_contains when it is not stable commit bcc7f5b4bee8e327689a4d994022765855c807ff upstream. bdev->bd_contains is not stable before calling __blkdev_get(). When __blkdev_get() is called on a parition with ->bd_openers == 0 it sets bdev->bd_contains = bdev; which is not correct for a partition. After a call to __blkdev_get() succeeds, ->bd_openers will be > 0 and then ->bd_contains is stable. When FMODE_EXCL is used, blkdev_get() calls bd_start_claiming() -> bd_prepare_to_claim() -> bd_may_claim() This call happens before __blkdev_get() is called, so ->bd_contains is not stable. So bd_may_claim() cannot safely use ->bd_contains. It currently tries to use it, and this can lead to a BUG_ON(). This happens when a whole device is already open with a bd_holder (in use by dm in my particular example) and two threads race to open a partition of that device for the first time, one opening with O_EXCL and one without. The thread that doesn't use O_EXCL gets through blkdev_get() to __blkdev_get(), gains the ->bd_mutex, and sets bdev->bd_contains = bdev; Immediately thereafter the other thread, using FMODE_EXCL, calls bd_start_claiming() from blkdev_get(). This should fail because the whole device has a holder, but because bdev->bd_contains == bdev bd_may_claim() incorrectly reports success. This thread continues and blocks on bd_mutex. The first thread then sets bdev->bd_contains correctly and drops the mutex. The thread using FMODE_EXCL then continues and when it calls bd_may_claim() again in: BUG_ON(!bd_may_claim(bdev, whole, holder)); The BUG_ON fires. Fix this by removing the dependency on ->bd_contains in bd_may_claim(). As bd_may_claim() has direct access to the whole device, it can simply test if the target bdev is the whole device. Fixes: 6b4517a7913a ("block: implement bd_claiming and claiming block") Signed-off-by: NeilBrown Signed-off-by: Jens Axboe Signed-off-by: Jiri Slaby commit 3d83da25eef1ddea7e497960474493622d13c1c4 Author: Liu Bo Date: Wed Aug 3 12:33:01 2016 -0700 Btrfs: fix memory leak in reading btree blocks commit 2571e739677f1e4c0c63f5ed49adcc0857923625 upstream. So we can read a btree block via readahead or intentional read, and we can end up with a memory leak when something happens as follows, 1) readahead starts to read block A but does not wait for read completion, 2) btree_readpage_end_io_hook finds that block A is corrupted, and it needs to clear all block A's pages' uptodate bit. 3) meanwhile an intentional read kicks in and checks block A's pages' uptodate to decide which page needs to be read. 4) when some pages have the uptodate bit during 3)'s check so 3) doesn't count them for eb->io_pages, but they are later cleared by 2) so we has to readpage on the page, we get the wrong eb->io_pages which results in a memory leak of this block. This fixes the problem by firstly getting all pages's locking and then checking pages' uptodate bit. t1(readahead) t2(readahead endio) t3(the following read) read_extent_buffer_pages end_bio_extent_readpage for pg in eb: for page 0,1,2 in eb: if pg is uptodate: btree_readpage_end_io_hook(pg) num_reads++ if uptodate: eb->io_pages = num_reads SetPageUptodate(pg) _______________ for pg in eb: for page 3 in eb: read_extent_buffer_pages if pg is NOT uptodate: btree_readpage_end_io_hook(pg) for pg in eb: __extent_read_full_page(pg) sanity check reports something wrong if pg is uptodate: clear_extent_buffer_uptodate(eb) num_reads++ for pg in eb: eb->io_pages = num_reads ClearPageUptodate(page) _______________ for pg in eb: if pg is NOT uptodate: __extent_read_full_page(pg) So t3's eb->io_pages is not consistent with the number of pages it's reading, and during endio(), atomic_dec_and_test(&eb->io_pages) will get a negative number so that we're not able to free the eb. Signed-off-by: Liu Bo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Jiri Slaby commit 2628573b54abd15deff74485ef586ed3b305f453 Author: Takashi Iwai Date: Tue Dec 6 11:55:17 2016 +0100 ALSA: hda - Gate the mic jack on HP Z1 Gen3 AiO commit f73cd43ac3b41c0f09a126387f302bbc0d9c726d upstream. HP Z1 Gen3 AiO with Conexant codec doesn't give an unsolicited event to the headset mic pin upon the jack plugging, it reports only to the headphone pin. It results in the missing mic switching. Let's fix up by simply gating the jack event. Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 72588bd4bae84380f6ae9a4c828d84d8c22f19ec Author: Jussi Laako Date: Mon Nov 28 11:27:45 2016 +0200 ALSA: hiface: Fix M2Tech hiFace driver sampling rate change commit 995c6a7fd9b9212abdf01160f6ce3193176be503 upstream. Sampling rate changes after first set one are not reflected to the hardware, while driver and ALSA think the rate has been changed. Fix the problem by properly stopping the interface at the beginning of prepare call, allowing new rate to be set to the hardware. This keeps the hardware in sync with the driver. Signed-off-by: Jussi Laako Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 5bf1a774bcfb67660f2e9780a742d7cd4c2c2934 Author: Con Kolivas Date: Fri Dec 9 15:15:57 2016 +1100 ALSA: usb-audio: Add QuickCam Communicate Deluxe/S7500 to volume_control_quirks commit 82ffb6fc637150b279f49e174166d2aa3853eaf4 upstream. The Logitech QuickCam Communicate Deluxe/S7500 microphone fails with the following warning. [ 6.778995] usb 2-1.2.2.2: Warning! Unlikely big volume range (=3072), cval->res is probably wrong. [ 6.778996] usb 2-1.2.2.2: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1 Adding it to the list of devices in volume_control_quirks makes it work properly, fixing related typo. Signed-off-by: Con Kolivas Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 1d22fa3192dd0fc10f6f193e85993e42b451f663 Author: Alan Stern Date: Fri Oct 21 16:49:07 2016 -0400 USB: UHCI: report non-PME wakeup signalling for Intel hardware commit ccdb6be9ec6580ef69f68949ebe26e0fb58a6fb0 upstream. The UHCI controllers in Intel chipsets rely on a platform-specific non-PME mechanism for wakeup signalling. They can generate wakeup signals even though they don't support PME. We need to let the USB core know this so that it will enable runtime suspend for UHCI controllers. Signed-off-by: Alan Stern Signed-off-by: Bjorn Helgaas Acked-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit bc87609a9b18ddfd4f6aa1060a61b704042d4076 Author: Felipe Balbi Date: Wed Sep 28 10:38:11 2016 +0300 usb: gadget: composite: correctly initialize ep->maxpacket commit e8f29bb719b47a234f33b0af62974d7a9521a52c upstream. usb_endpoint_maxp() returns wMaxPacketSize in its raw form. Without taking into consideration that it also contains other bits reserved for isochronous endpoints. This patch fixes one occasion where this is a problem by making sure that we initialize ep->maxpacket only with lower 10 bits of the value returned by usb_endpoint_maxp(). Note that seperate patches will be necessary to audit all call sites of usb_endpoint_maxp() and make sure that usb_endpoint_maxp() only returns lower 10 bits of wMaxPacketSize. Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 6cc18ebe2066e89f47b112bfc58ec67f1bc48142 Author: Mathias Nyman Date: Thu Nov 17 11:14:14 2016 +0200 usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices commit 37be66767e3cae4fd16e064d8bb7f9f72bf5c045 upstream. USB-3 does not have any link state that will avoid negotiating a connection with a plugged-in cable but will signal the host when the cable is unplugged. For USB-3 we used to first set the link to Disabled, then to RxDdetect to be able to detect cable connects or disconnects. But in RxDetect the connected device is detected again and eventually enabled. Instead set the link into U3 and disable remote wakeups for the device. This is what Windows does, and what Alan Stern suggested. Cc: Alan Stern Acked-by: Alan Stern Signed-off-by: Mathias Nyman Signed-off-by: Jiri Slaby commit cdd9e42bfe86d7f945ad302ecac8e6e2c4e9b2ad Author: Nathaniel Quillin Date: Mon Dec 5 06:53:00 2016 -0800 USB: cdc-acm: add device id for GW Instek AFG-125 commit 301216044e4c27d5a7323c1fa766266fad00db5e upstream. Add device-id entry for GW Instek AFG-125, which has a byte swapped bInterfaceSubClass (0x20). Signed-off-by: Nathaniel Quillin Acked-by: Oliver Neukum Signed-off-by: Jiri Slaby commit 7d15019fcd263a6ed5f7471d23274ba0d8366ef2 Author: Johan Hovold Date: Tue Nov 29 16:55:01 2016 +0100 USB: serial: kl5kusb105: fix open error path commit 6774d5f53271d5f60464f824748995b71da401ab upstream. Kill urbs and disable read before returning from open on failure to retrieve the line state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 99362880e75438511a6db73fda1d10c108d58ee9 Author: Giuseppe Lippolis Date: Tue Dec 6 21:24:19 2016 +0100 USB: serial: option: add dlink dwm-158 commit d8a12b7117b42fd708f1e908498350232bdbd5ff upstream. Adding registration for 3G modem DWM-158 in usb-serial-option Signed-off-by: Giuseppe Lippolis Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 09f7a171b368f5da11fc9883b64f46802f1e3311 Author: Daniele Palmas Date: Thu Dec 1 16:38:39 2016 +0100 USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041 commit 5b09eff0c379002527ad72ea5ea38f25da8a8650 upstream. This patch adds support for PIDs 0x1040, 0x1041 of Telit LE922A. Since the interface positions are the same than the ones used for other Telit compositions, previous defined blacklists are used. Signed-off-by: Daniele Palmas Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 5b5c8f9fed14d289a4b0cc91f465f2c7592b2f1b Author: Robbie Ko Date: Fri Oct 7 17:30:47 2016 +0800 Btrfs: fix tree search logic when replaying directory entry deletes commit 2a7bf53f577e49c43de4ffa7776056de26db65d9 upstream. If a log tree has a layout like the following: leaf N: ... item 240 key (282 DIR_LOG_ITEM 0) itemoff 8189 itemsize 8 dir log end 1275809046 leaf N + 1: item 0 key (282 DIR_LOG_ITEM 3936149215) itemoff 16275 itemsize 8 dir log end 18446744073709551615 ... When we pass the value 1275809046 + 1 as the parameter start_ret to the function tree-log.c:find_dir_range() (done by replay_dir_deletes()), we end up with path->slots[0] having the value 239 (points to the last item of leaf N, item 240). Because the dir log item in that position has an offset value smaller than *start_ret (1275809046 + 1) we need to move on to the next leaf, however the logic for that is wrong since it compares the current slot to the number of items in the leaf, which is smaller and therefore we don't lookup for the next leaf but instead we set the slot to point to an item that does not exist, at slot 240, and we later operate on that slot which has unexpected content or in the worst case can result in an invalid memory access (accessing beyond the last page of leaf N's extent buffer). So fix the logic that checks when we need to lookup at the next leaf by first incrementing the slot and only after to check if that slot is beyond the last item of the current leaf. Signed-off-by: Robbie Ko Reviewed-by: Filipe Manana Fixes: e02119d5a7b4 (Btrfs: Add a write ahead tree log to optimize synchronous operations) Signed-off-by: Filipe Manana [Modified changelog for clarity and correctness] Signed-off-by: Jiri Slaby commit 081fafddc3ff1e86e36024b0177c08e340b19a12 Author: Jeff Mahoney Date: Fri Dec 2 22:21:55 2016 -0500 Revert "Btrfs: don't delay inode ref updates during log, replay" This reverts commit 644d10716875b24388680925d6c7502420987bfe, upstream commit 6f8960541b1eb6054a642da48daae2320fddba93. The original patch for mainline, 6f8960541b1 (Btrfs: don't delay inode ref updates during log replay) lists 1d52c78afbb (Btrfs: try not to ENOSPC on log replay) as the only pre-3.18 dependency, but it also depends on 67de11769bd (Btrfs: introduce the delayed inode ref deletion for the single link inode), which was introduced in 3.14 and isn't in 3.12.y. The -stable commit added the check to btrfs_delayed_update_inode, which may look similar to btrfs_delayed_delete_inode_ref, but it's only superficial. The tops of both functions handle typical delayed node boilerplate. The upshot is that the patch is harmless since the caller already checks to see if we're doing log recovery, so we're not breaking anything. It should be reverted because it makes it appear as if this issue was fixed for users who did backport 67de11769bd, when it is not. Signed-off-by: Jeff Mahoney Signed-off-by: Jiri Slaby commit ae252fd89dfa9e6b15a1299ab690ec2c99da8e1e Author: Michal Hocko Date: Wed Dec 7 14:54:38 2016 +0100 hotplug: Make register and unregister notifier API symmetric commit 777c6e0daebb3fcefbbd6f620410a946b07ef6d0 upstream. Yu Zhao has noticed that __unregister_cpu_notifier only unregisters its notifiers when HOTPLUG_CPU=y while the registration might succeed even when HOTPLUG_CPU=n if MODULE is enabled. This means that e.g. zswap might keep a stale notifier on the list on the manual clean up during the pool tear down and thus corrupt the list. Resulting in the following [ 144.964346] BUG: unable to handle kernel paging request at ffff880658a2be78 [ 144.971337] IP: [] raw_notifier_chain_register+0x1b/0x40 [ 145.122628] Call Trace: [ 145.125086] [] __register_cpu_notifier+0x18/0x20 [ 145.131350] [] zswap_pool_create+0x273/0x400 [ 145.137268] [] __zswap_param_set+0x1fc/0x300 [ 145.143188] [] ? trace_hardirqs_on+0xd/0x10 [ 145.149018] [] ? kernel_param_lock+0x28/0x30 [ 145.154940] [] ? __might_fault+0x4f/0xa0 [ 145.160511] [] zswap_compressor_param_set+0x17/0x20 [ 145.167035] [] param_attr_store+0x5c/0xb0 [ 145.172694] [] module_attr_store+0x1d/0x30 [ 145.178443] [] sysfs_kf_write+0x4f/0x70 [ 145.183925] [] kernfs_fop_write+0x149/0x180 [ 145.189761] [] __vfs_write+0x18/0x40 [ 145.194982] [] vfs_write+0xb2/0x1a0 [ 145.200122] [] SyS_write+0x52/0xa0 [ 145.205177] [] entry_SYSCALL_64_fastpath+0x12/0x17 This can be even triggered manually by changing /sys/module/zswap/parameters/compressor multiple times. Fix this issue by making unregister APIs symmetric to the register so there are no surprises. [js] backport to 3.12 Fixes: 47e627bc8c9a ("[PATCH] hotplug: Allow modules to use the cpu hotplug notifiers even if !CONFIG_HOTPLUG_CPU") Reported-and-tested-by: Yu Zhao Signed-off-by: Michal Hocko Cc: linux-mm@kvack.org Cc: Andrew Morton Cc: Dan Streetman Link: http://lkml.kernel.org/r/20161207135438.4310-1-mhocko@kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Jiri Slaby commit 13e993f84eebae3672f94509cb858a7eae139aa0 Author: Boris Brezillon Date: Fri Oct 28 17:12:28 2016 +0200 m68k: Fix ndelay() macro commit 7e251bb21ae08ca2e4fb28cc0981fac2685a8efa upstream. The current ndelay() macro definition has an extra semi-colon at the end of the line thus leading to a compilation error when ndelay is used in a conditional block without curly braces like this one: if (cond) ndelay(t); else ... which, after the preprocessor pass gives: if (cond) m68k_ndelay(t);; else ... thus leading to the following gcc error: error: 'else' without a previous 'if' Remove this extra semi-colon. Signed-off-by: Boris Brezillon Fixes: c8ee038bd1488 ("m68k: Implement ndelay() based on the existing udelay() logic") Signed-off-by: Geert Uytterhoeven Signed-off-by: Jiri Slaby commit f1f12289932cd1b134f34699f8eea00af77ab582 Author: 추지호 Date: Thu Dec 8 12:01:13 2016 +0000 can: peak: fix bad memory access and free sequence commit b67d0dd7d0dc9e456825447bbeb935d8ef43ea7c upstream. Fix for bad memory access while disconnecting. netdev is freed before private data free, and dev is accessed after freeing netdev. This makes a slub problem, and it raise kernel oops with slub debugger config. Signed-off-by: Jiho Chu Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit 9f412aa5bf276de789651cb3a64ea73877168fe9 Author: Marc Kleine-Budde Date: Mon Dec 5 11:44:23 2016 +0100 can: raw: raw_setsockopt: limit number of can_filter that can be set commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream. This patch adds a check to limit the number of can_filters that can be set via setsockopt on CAN_RAW sockets. Otherwise allocations > MAX_ORDER are not prevented resulting in a warning. Reference: https://lkml.org/lkml/2016/12/2/230 Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit d9dba3a93f5427e643a81e6ba2da81898ac84792 Author: Peter Zijlstra (Intel) Date: Tue Nov 29 20:33:28 2016 +0000 perf/x86: Fix full width counter, counter overflow commit 7f612a7f0bc13a2361a152862435b7941156b6af upstream. Lukasz reported that perf stat counters overflow handling is broken on KNL/SLM. Both these parts have full_width_write set, and that does indeed have a problem. In order to deal with counter wrap, we must sample the counter at at least half the counter period (see also the sampling theorem) such that we can unambiguously reconstruct the count. However commit: 069e0c3c4058 ("perf/x86/intel: Support full width counting") sets the sampling interval to the full period, not half. Fixing that exposes another issue, in that we must not sign extend the delta value when we shift it right; the counter cannot have decremented after all. With both these issues fixed, counter overflow functions correctly again. Reported-by: Lukasz Odzioba Tested-by: Liang, Kan Tested-by: Odzioba, Lukasz Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: 069e0c3c4058 ("perf/x86/intel: Support full width counting") Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 15543c65c619ea88c8b3fdf97f2371ea13d4048f Author: Thomas Gleixner Date: Wed Nov 30 21:04:42 2016 +0000 locking/rtmutex: Use READ_ONCE() in rt_mutex_owner() commit 1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d upstream. While debugging the rtmutex unlock vs. dequeue race Will suggested to use READ_ONCE() in rt_mutex_owner() as it might race against the cmpxchg_release() in unlock_rt_mutex_safe(). Will: "It's a minor thing which will most likely not matter in practice" Careful search did not unearth an actual problem in todays code, but it's better to be safe than surprised. Suggested-by: Will Deacon Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: David Daney Cc: Linus Torvalds Cc: Mark Rutland Cc: Peter Zijlstra Cc: Sebastian Siewior Cc: Steven Rostedt Link: http://lkml.kernel.org/r/20161130210030.431379999@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit a0346c3237a7f29b957190875ab6d65689fa191a Author: Thomas Gleixner Date: Wed Nov 30 21:04:41 2016 +0000 locking/rtmutex: Prevent dequeue vs. unlock race commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream. David reported a futex/rtmutex state corruption. It's caused by the following problem: CPU0 CPU1 CPU2 l->owner=T1 rt_mutex_lock(l) lock(l->wait_lock) l->owner = T1 | HAS_WAITERS; enqueue(T2) boost() unlock(l->wait_lock) schedule() rt_mutex_lock(l) lock(l->wait_lock) l->owner = T1 | HAS_WAITERS; enqueue(T3) boost() unlock(l->wait_lock) schedule() signal(->T2) signal(->T3) lock(l->wait_lock) dequeue(T2) deboost() unlock(l->wait_lock) lock(l->wait_lock) dequeue(T3) ===> wait list is now empty deboost() unlock(l->wait_lock) lock(l->wait_lock) fixup_rt_mutex_waiters() if (wait_list_empty(l)) { owner = l->owner & ~HAS_WAITERS; l->owner = owner ==> l->owner = T1 } lock(l->wait_lock) rt_mutex_unlock(l) fixup_rt_mutex_waiters() if (wait_list_empty(l)) { owner = l->owner & ~HAS_WAITERS; cmpxchg(l->owner, T1, NULL) ===> Success (l->owner = NULL) l->owner = owner ==> l->owner = T1 } That means the problem is caused by fixup_rt_mutex_waiters() which does the RMW to clear the waiters bit unconditionally when there are no waiters in the rtmutexes rbtree. This can be fatal: A concurrent unlock can release the rtmutex in the fastpath because the waiters bit is not set. If the cmpxchg() gets in the middle of the RMW operation then the previous owner, which just unlocked the rtmutex is set as the owner again when the write takes place after the successfull cmpxchg(). The solution is rather trivial: verify that the owner member of the rtmutex has the waiters bit set before clearing it. This does not require a cmpxchg() or other atomic operations because the waiters bit can only be set and cleared with the rtmutex wait_lock held. It's also safe against the fast path unlock attempt. The unlock attempt via cmpxchg() will either see the bit set and take the slowpath or see the bit cleared and release it atomically in the fastpath. It's remarkable that the test program provided by David triggers on ARM64 and MIPS64 really quick, but it refuses to reproduce on x86-64, while the problem exists there as well. That refusal might explain that this got not discovered earlier despite the bug existing from day one of the rtmutex implementation more than 10 years ago. Thanks to David for meticulously instrumenting the code and providing the information which allowed to decode this subtle problem. Reported-by: David Daney Tested-by: David Daney Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt Acked-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Mark Rutland Cc: Peter Zijlstra Cc: Sebastian Siewior Cc: Will Deacon Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") Link: http://lkml.kernel.org/r/20161130210030.351136722@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 10de8b686e90eb57066cf4d04d7ddbc54b4f1833 Author: Jan Kara Date: Sun Apr 24 00:56:03 2016 -0400 ext4: fix data exposure after a crash commit 06bd3c36a733ac27962fea7d6f47168841376824 upstream. Huang has reported that in his powerfail testing he is seeing stale block contents in some of recently allocated blocks although he mounts ext4 in data=ordered mode. After some investigation I have found out that indeed when delayed allocation is used, we don't add inode to transaction's list of inodes needing flushing before commit. Originally we were doing that but commit f3b59291a69d removed the logic with a flawed argument that it is not needed. The problem is that although for delayed allocated blocks we write their contents immediately after allocating them, there is no guarantee that the IO scheduler or device doesn't reorder things and thus transaction allocating blocks and attaching them to inode can reach stable storage before actual block contents. Actually whenever we attach freshly allocated blocks to inode using a written extent, we should add inode to transaction's ordered inode list to make sure we properly wait for block contents to be written before committing the transaction. So that is what we do in this patch. This also handles other cases where stale data exposure was possible - like filling hole via mmap in data=ordered,nodelalloc mode. The only exception to the above rule are extending direct IO writes where blkdev_direct_IO() waits for IO to complete before increasing i_size and thus stale data exposure is not possible. For now we don't complicate the code with optimizing this special case since the overhead is pretty low. In case this is observed to be a performance problem we can always handle it using a special flag to ext4_map_blocks(). Fixes: f3b59291a69d0b734be1fc8be489fef2dd846d3d Reported-by: "HUANG Weller (CM/ESW12-CN)" Tested-by: "HUANG Weller (CM/ESW12-CN)" Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby commit a93a63333dbdb182b87e8cc99df8b4474f867acb Author: Ming Lei Date: Sun Jul 10 19:27:36 2016 +0800 driver core: fix race between creating/querying glue dir and its cleanup commit cebf8fd16900fdfd58c0028617944f808f97fe50 upstream. The global mutex of 'gdp_mutex' is used to serialize creating/querying glue dir and its cleanup. Turns out it isn't a perfect way because part(kobj_kset_leave()) of the actual cleanup action() is done inside the release handler of the glue dir kobject. That means gdp_mutex has to be held before releasing the last reference count of the glue dir kobject. This patch moves glue dir's cleanup after kobject_del() in device_del() for avoiding the race. Cc: Yijing Wang Reported-by: Chandra Sekhar Lingutla Signed-off-by: Ming Lei Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 5b46dc789ca2be4046e4e40a131858d386cac741 Author: Markus Elfring Date: Thu Feb 5 11:48:26 2015 +0100 driver core: Delete an unnecessary check before the function call "put_device" commit 5f0163a5ee9cc7c59751768bdfd94a73186debba upstream. The put_device() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby