commit 6c2f633cbed5c0231802c69a8e4e55a0169df917 Author: Ben Hutchings Date: Sun Dec 16 22:09:47 2018 +0000 Linux 3.16.62 commit e86dae498d16a8acb3741acc2a09a2d692e3e7de Author: Xiao Liang Date: Tue Aug 14 23:21:28 2018 +0800 xen-netfront: fix warn message as irq device name has '/' commit 21f2706b20100bb3db378461ab9b8e2035309b5b upstream. There is a call trace generated after commit 2d408c0d4574b01b9ed45e02516888bf925e11a9( xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file found under /proc/irq/xx/. This patch only picks up device type and id as its name. With the patch, now /proc/interrupts looks like below and the warning message gone: 70: 21 0 0 0 xen-dyn -event vif0-q0-tx 71: 15 0 0 0 xen-dyn -event vif0-q0-rx 72: 14 0 0 0 xen-dyn -event vif0-q1-tx 73: 33 0 0 0 xen-dyn -event vif0-q1-rx 74: 12 0 0 0 xen-dyn -event vif0-q2-tx 75: 24 0 0 0 xen-dyn -event vif0-q2-rx 76: 19 0 0 0 xen-dyn -event vif0-q3-tx 77: 21 0 0 0 xen-dyn -event vif0-q3-rx Below is call trace information without this patch: name 'device/vif/0-q0-tx' WARNING: CPU: 2 PID: 37 at fs/proc/generic.c:174 __xlate_proc_name+0x85/0xa0 RIP: 0010:__xlate_proc_name+0x85/0xa0 RSP: 0018:ffffb85c40473c18 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000000006 RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff984c7f516930 RBP: ffffb85c40473cb8 R08: 000000000000002c R09: 0000000000000229 R10: 0000000000000000 R11: 0000000000000001 R12: ffffb85c40473c98 R13: ffffb85c40473cb8 R14: ffffb85c40473c50 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff984c7f500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f69b6899038 CR3: 000000001c20a006 CR4: 00000000001606e0 Call Trace: __proc_create+0x45/0x230 ? snprintf+0x49/0x60 proc_mkdir_data+0x35/0x90 register_handler_proc+0xef/0x110 ? proc_register+0xfc/0x110 ? proc_create_data+0x70/0xb0 __setup_irq+0x39b/0x660 ? request_threaded_irq+0xad/0x160 request_threaded_irq+0xf5/0x160 ? xennet_tx_buf_gc+0x1d0/0x1d0 [xen_netfront] bind_evtchn_to_irqhandler+0x3d/0x70 ? xenbus_alloc_evtchn+0x41/0xa0 netback_changed+0xa46/0xcda [xen_netfront] ? find_watch+0x40/0x40 xenwatch_thread+0xc5/0x160 ? finish_wait+0x80/0x80 kthread+0x112/0x130 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x35/0x40 Code: 81 5c 00 48 85 c0 75 cc 5b 49 89 2e 31 c0 5d 4d 89 3c 24 41 5c 41 5d 41 5e 41 5f c3 4c 89 ee 48 c7 c7 40 4f 0e b4 e8 65 ea d8 ff <0f> 0b b8 fe ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 0f 1f ---[ end trace 650e5561b0caab3a ]--- Signed-off-by: Xiao Liang Reviewed-by: Juergen Gross Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 4d0f2564603d1ef8cce8a083751442342e9c9474 Author: Young_X Date: Wed Oct 3 12:54:29 2018 +0000 cdrom: fix improper type cast, which can leat to information leak. commit e4f3aa2e1e67bb48dfbaaf1cad59013d5a5bc276 upstream. There is another cast from unsigned long to int which causes a bounds check to fail with specially crafted input. The value is then used as an index in the slot array in cdrom_slot_status(). This issue is similar to CVE-2018-16658 and CVE-2018-10940. Signed-off-by: Young_X Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit 789a4317666e599e487ec1983643de1b519c431e Author: Darrick J. Wong Date: Tue Apr 17 19:10:15 2018 -0700 xfs: don't fail when converting shortform attr to long form during ATTR_REPLACE commit 7b38460dc8e4eafba06c78f8e37099d3b34d473c upstream. Kanda Motohiro reported that expanding a tiny xattr into a large xattr fails on XFS because we remove the tiny xattr from a shortform fork and then try to re-add it after converting the fork to extents format having not removed the ATTR_REPLACE flag. This fails because the attr is no longer present, causing a fs shutdown. This is derived from the patch in his bug report, but we really shouldn't ignore a nonzero retval from the remove call. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199119 Reported-by: kanda.motohiro@gmail.com Reviewed-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Darrick J. Wong [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 2567a342d707b1245e837f16cb7555b360e2c580 Author: Linus Torvalds Date: Fri Oct 12 15:22:59 2018 -0700 mremap: properly flush TLB before releasing the page commit eb66ae030829605d61fbef1909ce310e29f78821 upstream. Jann Horn points out that our TLB flushing was subtly wrong for the mremap() case. What makes mremap() special is that we don't follow the usual "add page to list of pages to be freed, then flush tlb, and then free pages". No, mremap() obviously just _moves_ the page from one page table location to another. That matters, because mremap() thus doesn't directly control the lifetime of the moved page with a freelist: instead, the lifetime of the page is controlled by the page table locking, that serializes access to the entry. As a result, we need to flush the TLB not just before releasing the lock for the source location (to avoid any concurrent accesses to the entry), but also before we release the destination page table lock (to avoid the TLB being flushed after somebody else has already done something to that page). This also makes the whole "need_flush" logic unnecessary, since we now always end up flushing the TLB for every valid entry. Reported-and-tested-by: Jann Horn Acked-by: Will Deacon Tested-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman [will: backport to 4.4 stable] Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 56a7ebd4a3adc001b18a8feeb5cdf0b9fb2684fa Author: Pavel Tikhomirov Date: Fri Nov 30 14:09:00 2018 -0800 mm: cleancache: fix corruption on missed inode invalidation commit 6ff38bd40230af35e446239396e5fc8ebd6a5248 upstream. If all pages are deleted from the mapping by memory reclaim and also moved to the cleancache: __delete_from_page_cache (no shadow case) unaccount_page_cache_page cleancache_put_page page_cache_delete mapping->nrpages -= nr (nrpages becomes 0) We don't clean the cleancache for an inode after final file truncation (removal). truncate_inode_pages_final check (nrpages || nrexceptional) is false no truncate_inode_pages no cleancache_invalidate_inode(mapping) These way when reading the new file created with same inode we may get these trash leftover pages from cleancache and see wrong data instead of the contents of the new file. Fix it by always doing truncate_inode_pages which is already ready for nrpages == 0 && nrexceptional == 0 case and just invalidates inode. [akpm@linux-foundation.org: add comment, per Jan] Link: http://lkml.kernel.org/r/20181112095734.17979-1-ptikhomirov@virtuozzo.com Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache") Signed-off-by: Pavel Tikhomirov Reviewed-by: Vasily Averin Reviewed-by: Andrey Ryabinin Reviewed-by: Jan Kara Cc: Johannes Weiner Cc: Mel Gorman Cc: Matthew Wilcox Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit f795b11fdc99a3d4d7d6b9d48c5e44e17c287a27 Author: Thomas Gleixner Date: Tue Jun 26 15:21:32 2018 +0200 posix-timers: Sanitize overrun handling commit 78c9c4dfbf8c04883941445a195276bb4bb92c76 upstream. The posix timer overrun handling is broken because the forwarding functions can return a huge number of overruns which does not fit in an int. As a consequence timer_getoverrun(2) and siginfo::si_overrun can turn into random number generators. The k_clock::timer_forward() callbacks return a 64 bit value now. Make k_itimer::ti_overrun[_last] 64bit as well, so the kernel internal accounting is correct. 3Remove the temporary (int) casts. Add a helper function which clamps the overrun value returned to user space via timer_getoverrun(2) or siginfo::si_overrun limited to a positive value between 0 and INT_MAX. INT_MAX is an indicator for user space that the overrun value has been clamped. Reported-by: Team OWL337 Signed-off-by: Thomas Gleixner Acked-by: John Stultz Cc: Peter Zijlstra Cc: Michael Kerrisk Link: https://lkml.kernel.org/r/20180626132705.018623573@linutronix.de [bwh: Backported to 3.16: adjust filenames, context] Signed-off-by: Ben Hutchings commit 921c1539170bf690cad59b3dbebf7d46843d28e2 Author: Lior David Date: Tue Nov 14 15:25:39 2017 +0200 wil6210: missing length check in wmi_set_ie commit b5a8ffcae4103a9d823ea3aa3a761f65779fbe2a upstream. Add a length check in wmi_set_ie to detect unsigned integer overflow. Signed-off-by: Lior David Signed-off-by: Maya Erez Signed-off-by: Kalle Valo [bwh: Backported to 3.16: return directly rather than via "out" label] Signed-off-by: Ben Hutchings commit bfe535bf4ab73e41922c7a58d6a858a2c435ff29 Author: Eric Biggers Date: Thu Jun 8 14:48:18 2017 +0100 KEYS: encrypted: fix buffer overread in valid_master_desc() commit 794b4bc292f5d31739d89c0202c54e7dc9bc3add upstream. With the 'encrypted' key type it was possible for userspace to provide a data blob ending with a master key description shorter than expected, e.g. 'keyctl add encrypted desc "new x" @s'. When validating such a master key description, validate_master_desc() could read beyond the end of the buffer. Fix this by using strncmp() instead of memcmp(). [Also clean up the code to deduplicate some logic.] Cc: Mimi Zohar Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: James Morris Signed-off-by: Ben Hutchings commit aa8d445cbbb6d383a8e430a9f7e606dc418faeb3 Author: Catalin Marinas Date: Wed Jun 1 18:52:16 2016 +0100 cpuidle: Do not access cpuidle_devices when !CONFIG_CPU_IDLE commit 9bd616e3dbedfc103f158197c8ad93678849b1ed upstream. The cpuidle_devices per-CPU variable is only defined when CPU_IDLE is enabled. Commit c8cc7d4de7a4 ("sched/idle: Reorganize the idle loop") removed the #ifdef CONFIG_CPU_IDLE around cpuidle_idle_call() with the compiler optimising away __this_cpu_read(cpuidle_devices). However, with CONFIG_UBSAN && !CONFIG_CPU_IDLE, this optimisation no longer happens and the kernel fails to link since cpuidle_devices is not defined. This patch introduces an accessor function for the current CPU cpuidle device (returning NULL when !CONFIG_CPU_IDLE) and uses it in cpuidle_idle_call(). Signed-off-by: Catalin Marinas Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit 7e6fc0b317c4cbd504434395edd7a99bd69e440e Author: Han Xu Date: Fri Oct 23 13:18:28 2015 -0500 mtd: fsl-quadspi: fix macro collision problems with READ/WRITE commit 04850c4d8613127a9b488321c0ad83bff7519311 upstream. Change the READ/WRITE to FSL_READ/FSL_WRITE to resolve any possible namespace collisions with READ/WRITE macros (e.g., from ). Problems have been seen, for example, on mips: >> drivers/mtd/spi-nor/fsl-quadspi.c:186:5: error: 'LUT_0' undeclared (first use in this function) ((LUT_##ins) << INSTR0_SHIFT)) ^ >> drivers/mtd/spi-nor/fsl-quadspi.c:188:30: note: in expansion of macro 'LUT0' On SPARC: drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut': drivers/mtd/spi-nor/fsl-quadspi.c:369:1: error: 'LUT_0' undeclared (first use in this function) drivers/mtd/spi-nor/fsl-quadspi.c:418:1: error: pasting "LUT_" and "(" does not give a valid preprocessing token drivers/mtd/spi-nor/fsl-quadspi.c:418:2: error: implicit declaration of function 'LUT_' And surely on others. Fixes: d26a22d06708 ("mtd: fsl-quadspi: allow building for other ARCHes with COMPILE_TEST") Reported-by: Guenter Roeck Reported-by: kbuild test robot Signed-off-by: Han Xu [Brian: rewrote commit description] Signed-off-by: Brian Norris Signed-off-by: Ben Hutchings commit 52de52ca372090ac6eb8e7d1dc1c33ba49b73d09 Author: David Ahern Date: Fri Oct 19 10:00:19 2018 -0700 net/ipv6: Fix index counter for unicast addresses in in6_dump_addrs commit 4ba4c566ba8448a05e6257e0b98a21f1a0d55315 upstream. The loop wants to skip previously dumped addresses, so loops until current index >= saved index. If the message fills it wants to save the index for the next address to dump - ie., the one that did not fit in the current message. Currently, it is incrementing the index counter before comparing to the saved index, and then the saved index is off by 1 - it assumes the current address is going to fit in the message. Change the index handling to increment only after a succesful dump. Fixes: 502a2ffd7376a ("ipv6: convert idev_list to list macros") Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 964dedacdbe5c60ba4bf7c98a400dd88ed66c097 Author: Heiner Kallweit Date: Thu Oct 18 19:56:01 2018 +0200 r8169: fix NAPI handling under high load commit 6b839b6cf9eada30b086effb51e5d6076bafc761 upstream. rtl_rx() and rtl_tx() are called only if the respective bits are set in the interrupt status register. Under high load NAPI may not be able to process all data (work_done == budget) and it will schedule subsequent calls to the poll callback. rtl_ack_events() however resets the bits in the interrupt status register, therefore subsequent calls to rtl8169_poll() won't call rtl_rx() and rtl_tx() - chip interrupts are still disabled. Fix this by calling rtl_rx() and rtl_tx() independent of the bits set in the interrupt status register. Both functions will detect if there's nothing to do for them. Fixes: da78dbff2e05 ("r8169: remove work from irq handler.") Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 45d8e6c9210c56db76fd8e196e349aa09b711221 Author: Al Viro Date: Wed Oct 17 15:23:26 2018 +0100 cachefiles: fix the race between cachefiles_bury_object() and rmdir(2) commit 169b803397499be85bdd1e3d07d6f5e3d4bd669e upstream. the victim might've been rmdir'ed just before the lock_rename(); unlike the normal callers, we do not look the source up after the parents are locked - we know it beforehand and just recheck that it's still the child of what used to be its parent. Unfortunately, the check is too weak - we don't spot a dead directory since its ->d_parent is unchanged, dentry is positive, etc. So we sail all the way to ->rename(), with hosting filesystems _not_ expecting to be asked renaming an rmdir'ed subdirectory. The fix is easy, fortunately - the lock on parent is sufficient for making IS_DEADDIR() on child safe. Fixes: 9ae326a69004 (CacheFiles: A cache that backs onto a mounted filesystem) Signed-off-by: Al Viro Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e9dbac343870ad5d33c60c42de1b31c3da6dfebe Author: Gustavo A. R. Silva Date: Tue Oct 16 15:06:41 2018 +0200 ptp: fix Spectre v1 vulnerability commit efa61c8cf2950ab5c0e66cff3cabe2a2b24e81ba upstream. pin_index can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/ptp/ptp_chardev.c:253 ptp_ioctl() warn: potential spectre issue 'ops->pin_config' [r] (local cap) Fix this by sanitizing pin_index before using it to index ops->pin_config, and before passing it as an argument to function ptp_set_pinfunc(), in which it is used to index info->pin_config. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Acked-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2e253a0ca95a8ccfd172f60bf08f259181abd646 Author: Gustavo A. R. Silva Date: Tue Oct 16 12:16:45 2018 +0200 usb: gadget: storage: Fix Spectre v1 vulnerability commit 9ae24af3669111d418242caec8dd4ebd9ba26860 upstream. num can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/usb/gadget/function/f_mass_storage.c:3177 fsg_lun_make() warn: potential spectre issue 'fsg_opts->common->luns' [r] (local cap) Fix this by sanitizing num before using it to index fsg_opts->common->luns Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Acked-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 366cbbcba48da72a3ba4f5a9c9a82a64d0aff2ce Author: Gustavo A. R. Silva Date: Tue Oct 16 16:59:01 2018 +0200 RDMA/ucma: Fix Spectre v1 vulnerability commit a3671a4f973ee9d9621d60166cc3b037c397d604 upstream. hdr.cmd can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/infiniband/core/ucma.c:1686 ucma_write() warn: potential spectre issue 'ucma_cmd_table' [r] (local cap) Fix this by sanitizing hdr.cmd before using it to index ucm_cmd_table. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Doug Ledford Signed-off-by: Ben Hutchings commit bc500cd4b469ef37d167f24025f62d4ed87372b8 Author: Gustavo A. R. Silva Date: Tue Oct 16 16:32:40 2018 +0200 IB/ucm: Fix Spectre v1 vulnerability commit 0295e39595e1146522f2722715dba7f7fba42217 upstream. hdr.cmd can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/infiniband/core/ucm.c:1127 ib_ucm_write() warn: potential spectre issue 'ucm_cmd_table' [r] (local cap) Fix this by sanitizing hdr.cmd before using it to index ucm_cmd_table. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Doug Ledford [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit e8a72e62937362e35c36efefcdd513562ee81842 Author: Alan Stern Date: Mon Oct 15 16:55:04 2018 -0400 USB: fix the usbfs flag sanitization for control transfers commit 665c365a77fbfeabe52694aedf3446d5f2f1ce42 upstream. Commit 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more") checks the transfer flags for URBs submitted from userspace via usbfs. However, the check for whether the USBDEVFS_URB_SHORT_NOT_OK flag should be allowed for a control transfer was added in the wrong place, before the code has properly determined the direction of the control transfer. (Control transfers are special because for them, the direction is set by the bRequestType byte of the Setup packet rather than direction bit of the endpoint address.) This patch moves code which sets up the allow_short flag for control transfers down after is_in has been set to the correct value. Signed-off-by: Alan Stern Reported-and-tested-by: syzbot+24a30223a4b609bb802e@syzkaller.appspotmail.com Fixes: 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more") CC: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 4f78f1df7fc63b55a6e9fe9184f2d156aeac32c9 Author: Peter Zijlstra Date: Thu Oct 11 12:38:27 2018 +0200 x86/percpu: Fix this_cpu_read() commit b59167ac7bafd804c91e49ad53c6d33a7394d4c8 upstream. Eric reported that a sequence count loop using this_cpu_read() got optimized out. This is wrong, this_cpu_read() must imply READ_ONCE() because the interface is IRQ-safe, therefore an interrupt can have changed the per-cpu value. Fixes: 7c3576d261ce ("[PATCH] i386: Convert PDA into the percpu section") Reported-by: Eric Dumazet Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Acked-by: Eric Dumazet Cc: hpa@zytor.com Cc: eric.dumazet@gmail.com Cc: bp@alien8.de Link: https://lkml.kernel.org/r/20181011104019.748208519@infradead.org [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit b427832009b97a3ee412ef643a80b15372a7754d Author: Sabrina Dubroca Date: Tue Oct 9 17:48:14 2018 +0200 net: ipv4: update fnhe_pmtu when first hop's MTU changes commit af7d6cce53694a88d6a1bb60c9a239a6a5144459 upstream. Since commit 5aad1de5ea2c ("ipv4: use separate genid for next hop exceptions"), exceptions get deprecated separately from cached routes. In particular, administrative changes don't clear PMTU anymore. As Stefano described in commit e9fa1495d738 ("ipv6: Reflect MTU changes on PMTU of exceptions for MTU-less routes"), the PMTU discovered before the local MTU change can become stale: - if the local MTU is now lower than the PMTU, that PMTU is now incorrect - if the local MTU was the lowest value in the path, and is increased, we might discover a higher PMTU Similarly to what commit e9fa1495d738 did for IPv6, update PMTU in those cases. If the exception was locked, the discovered PMTU was smaller than the minimal accepted PMTU. In that case, if the new local MTU is smaller than the current PMTU, let PMTU discovery figure out if locking of the exception is still needed. To do this, we need to know the old link MTU in the NETDEV_CHANGEMTU notifier. By the time the notifier is called, dev->mtu has been changed. This patch adds the old MTU as additional information in the notifier structure, and a new call_netdevice_notifiers_u32() function. Fixes: 5aad1de5ea2c ("ipv4: use separate genid for next hop exceptions") Signed-off-by: Sabrina Dubroca Reviewed-by: Stefano Brivio Reviewed-by: David Ahern Signed-off-by: David S. Miller [bwh: Backported to 3.16: - Pass net_device argument to call_netdevice_notifiers_info() - Adjust context] Signed-off-by: Ben Hutchings commit 078a0a4eb7c9dc3e1d3ffa8503cdc7c02e86e8a0 Author: Eric Dumazet Date: Wed Oct 10 06:59:35 2018 -0700 net: make skb_partial_csum_set() more robust against overflows commit 52b5d6f5dcf0e5201392f7d417148ccb537dbf6f upstream. syzbot managed to crash in skb_checksum_help() [1] : BUG_ON(offset + sizeof(__sum16) > skb_headlen(skb)); Root cause is the following check in skb_partial_csum_set() if (unlikely(start > skb_headlen(skb)) || unlikely((int)start + off > skb_headlen(skb) - 2)) return false; If skb_headlen(skb) is 1, then (skb_headlen(skb) - 2) becomes 0xffffffff and the check fails to detect that ((int)start + off) is off the limit, since the compare is unsigned. When we fix that, then the first condition (start > skb_headlen(skb)) becomes obsolete. Then we should also check that (skb_headroom(skb) + start) wont overflow 16bit field. [1] kernel BUG at net/core/dev.c:2880! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 7330 Comm: syz-executor4 Not tainted 4.19.0-rc6+ #253 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_checksum_help+0x9e3/0xbb0 net/core/dev.c:2880 Code: 85 00 ff ff ff 48 c1 e8 03 42 80 3c 28 00 0f 84 09 fb ff ff 48 8b bd 00 ff ff ff e8 97 a8 b9 fb e9 f8 fa ff ff e8 2d 09 76 fb <0f> 0b 48 8b bd 28 ff ff ff e8 1f a8 b9 fb e9 b1 f6 ff ff 48 89 cf RSP: 0018:ffff8801d83a6f60 EFLAGS: 00010293 RAX: ffff8801b9834380 RBX: ffff8801b9f8d8c0 RCX: ffffffff8608c6d7 RDX: 0000000000000000 RSI: ffffffff8608cc63 RDI: 0000000000000006 RBP: ffff8801d83a7068 R08: ffff8801b9834380 R09: 0000000000000000 R10: ffff8801d83a76d8 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000010001 R14: 000000000000ffff R15: 00000000000000a8 FS: 00007f1a66db5700(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7d77f091b0 CR3: 00000001ba252000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_csum_hwoffload_help+0x8f/0xe0 net/core/dev.c:3269 validate_xmit_skb+0xa2a/0xf30 net/core/dev.c:3312 __dev_queue_xmit+0xc2f/0x3950 net/core/dev.c:3797 dev_queue_xmit+0x17/0x20 net/core/dev.c:3838 packet_snd net/packet/af_packet.c:2928 [inline] packet_sendmsg+0x422d/0x64c0 net/packet/af_packet.c:2953 Fixes: 5ff8dda3035d ("net: Ensure partial checksum offset is inside the skb head") Signed-off-by: Eric Dumazet Cc: Herbert Xu Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 727e211b3665c51f5a160b8bbbff6f2ad0771cb2 Author: Daniel Mack Date: Mon Oct 8 22:03:57 2018 +0200 libertas: call into generic suspend code before turning off power commit 4f666675cdff0b986195413215eb062b7da6586f upstream. When powering down a SDIO connected card during suspend, make sure to call into the generic lbs_suspend() function before pulling the plug. This will make sure the card is successfully deregistered from the system to avoid communication to the card starving out. Fixes: 7444a8092906 ("libertas: fix suspend and resume for SDIO connected cards") Signed-off-by: Daniel Mack Reviewed-by: Ulf Hansson Acked-by: Kalle Valo Signed-off-by: Ulf Hansson Signed-off-by: Ben Hutchings commit 739f44a8a3f28901fee088cf59c4054e20cecda9 Author: Guenter Roeck Date: Tue Sep 25 21:06:24 2018 -0700 of: unittest: Disable interrupt node tests for old world MAC systems commit 8894891446c9380709451b99ab45c5c53adfd2fc upstream. On systems with OF_IMAP_OLDWORLD_MAC set in of_irq_workarounds, the devicetree interrupt parsing code is different, causing unit tests of devicetree interrupt nodes to fail. Due to a bug in unittest code, which tries to dereference an uninitialized pointer, this results in a crash. OF: /testcase-data/phandle-tests/consumer-a: arguments longer than property Unable to handle kernel paging request for data at address 0x00bc616e Faulting instruction address: 0xc08e9468 Oops: Kernel access of bad area, sig: 11 [#1] BE PREEMPT PowerMac Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.72-rc1-yocto-standard+ #1 task: cf8e0000 task.stack: cf8da000 NIP: c08e9468 LR: c08ea5bc CTR: c08ea5ac REGS: cf8dbb50 TRAP: 0300 Not tainted (4.14.72-rc1-yocto-standard+) MSR: 00001032 CR: 82004044 XER: 00000000 DAR: 00bc616e DSISR: 40000000 GPR00: c08ea5bc cf8dbc00 cf8e0000 c13ca517 c13ca517 c13ca8a0 00000066 00000002 GPR08: 00000063 00bc614e c0b05865 000affff 82004048 00000000 c00047f0 00000000 GPR16: c0a80000 c0a9cc34 c13ca517 c0ad1134 05ffffff 000affff c0b05860 c0abeef8 GPR24: cecec278 cecec278 c0a8c4d0 c0a885e0 c13ca8a0 05ffffff c13ca8a0 c13ca517 NIP [c08e9468] device_node_gen_full_name+0x30/0x15c LR [c08ea5bc] device_node_string+0x190/0x3c8 Call Trace: [cf8dbc00] [c007f670] trace_hardirqs_on_caller+0x118/0x1fc (unreliable) [cf8dbc40] [c08ea5bc] device_node_string+0x190/0x3c8 [cf8dbcb0] [c08eb794] pointer+0x25c/0x4d0 [cf8dbd00] [c08ebcbc] vsnprintf+0x2b4/0x5ec [cf8dbd60] [c08ec00c] vscnprintf+0x18/0x48 [cf8dbd70] [c008e268] vprintk_store+0x4c/0x22c [cf8dbda0] [c008ecac] vprintk_emit+0x94/0x130 [cf8dbdd0] [c008ff54] printk+0x5c/0x6c [cf8dbe10] [c0b8ddd4] of_unittest+0x2220/0x26f8 [cf8dbea0] [c0004434] do_one_initcall+0x4c/0x184 [cf8dbf00] [c0b4534c] kernel_init_freeable+0x13c/0x1d8 [cf8dbf30] [c0004814] kernel_init+0x24/0x118 [cf8dbf40] [c0013398] ret_from_kernel_thread+0x5c/0x64 The problem was observed when running a qemu test for the g3beige machine with devicetree unittests enabled. Disable interrupt node tests on affected systems to avoid both false unittest failures and the crash. With this patch in place, unittest on the affected system passes with the following message. dt-test ### end of unittest - 144 passed, 0 failed Fixes: 53a42093d96ef ("of: Add device tree selftests") Signed-off-by: Guenter Roeck Reviewed-by: Frank Rowand Signed-off-by: Rob Herring [bwh: Backported to 3.16: s/unittest/selftest/] Signed-off-by: Ben Hutchings commit 96e09747f240c64fadffc91b54095c889ed0720b Author: Shenghui Wang Date: Sun Oct 7 14:45:41 2018 +0800 dm cache: destroy migration_cache if cache target registration failed commit c7cd55504a5b0fc826a2cd9540845979d24ae542 upstream. Commit 7e6358d244e47 ("dm: fix various targets to dm_register_target after module __init resources created") inadvertently introduced this bug when it moved dm_register_target() after the call to KMEM_CACHE(). Fixes: 7e6358d244e47 ("dm: fix various targets to dm_register_target after module __init resources created") Signed-off-by: Shenghui Wang Signed-off-by: Mike Snitzer Signed-off-by: Ben Hutchings commit 0f30fad9f69329b14cd934c8e79cdb92298d9191 Author: Shuah Khan (Samsung OSG) Date: Fri Oct 5 16:17:44 2018 -0600 usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control() commit 81f7567c51ad97668d1c3a48e8ecc482e64d4161 upstream. vhci_hub_control() accesses port_status array with out of bounds port value. Fix it to reference port_status[] only with a valid rhport value when invalid_rhport flag is true. The invalid_rhport flag is set early on after detecting in port value is within the bounds or not. The following is used reproduce the problem and verify the fix: C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000 Reported-by: syzbot+bccc1fe10b70fadc78d0@syzkaller.appspotmail.com Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: - s/VHCI_HC_PORTS/VHCI_NPORTS/ - Mask wIndex before using it, as done upstream in commit 1c9de5bf4286 "usbip: vhci-hcd: Add USB3 SuperSpeed support" - Drop inapplicable changes - Adjust filename] Signed-off-by: Ben Hutchings commit 0c1b02cb51c211e02be1349004962056292bf555 Author: Mikulas Patocka Date: Fri Aug 17 15:19:37 2018 -0400 mach64: detect the dot clock divider correctly on sparc commit 76ebebd2464c5c8a4453c98b6dbf9c95a599e810 upstream. On Sun Ultra 5, it happens that the dot clock is not set up properly for some videomodes. For example, if we set the videomode "r1024x768x60" in the firmware, Linux would incorrectly set a videomode with refresh rate 180Hz when booting (suprisingly, my LCD monitor can display it, although display quality is very low). The reason is this: Older mach64 cards set the divider in the register VCLK_POST_DIV. The register has four 2-bit fields (the field that is actually used is specified in the lowest two bits of the register CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards, there's another bit added - the top four bits of PLL_EXT_CNTL extend the divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12". The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets them, so it can work regardless if the card supports them. However, the sparc64 firmware may set these extended dividers during boot - and the mach64 driver detects incorrect dot clock in this case. This patch makes the driver read the additional divider bit from PLL_EXT_CNTL and calculate the initial refresh rate properly. Signed-off-by: Mikulas Patocka Acked-by: David S. Miller Reviewed-by: Ville Syrjälä Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2595fe66a4f7adb653ce8ea38f766e0ecaa34fed Author: Daniel Black Date: Fri Oct 5 15:52:19 2018 -0700 mm: madvise(MADV_DODUMP): allow hugetlbfs pages commit d41aa5252394c065d1f04d1ceea885b70d00c9c6 upstream. Reproducer, assuming 2M of hugetlbfs available: Hugetlbfs mounted, size=2M and option user=testuser # mount | grep ^hugetlbfs hugetlbfs on /dev/hugepages type hugetlbfs (rw,pagesize=2M,user=dan) # sysctl vm.nr_hugepages=1 vm.nr_hugepages = 1 # grep Huge /proc/meminfo AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 1 HugePages_Free: 1 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 2048 kB Code: #include #include #define SIZE 2*1024*1024 int main() { void *ptr; ptr = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_HUGETLB | MAP_ANONYMOUS, -1, 0); madvise(ptr, SIZE, MADV_DONTDUMP); madvise(ptr, SIZE, MADV_DODUMP); } Compile and strace: mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0) = 0x7ff7c9200000 madvise(0x7ff7c9200000, 2097152, MADV_DONTDUMP) = 0 madvise(0x7ff7c9200000, 2097152, MADV_DODUMP) = -1 EINVAL (Invalid argument) hugetlbfs pages have VM_DONTEXPAND in the VmFlags driver pages based on author testing with analysis from Florian Weimer[1]. The inclusion of VM_DONTEXPAND into the VM_SPECIAL defination was a consequence of the large useage of VM_DONTEXPAND in device drivers. A consequence of [2] is that VM_DONTEXPAND marked pages are unable to be marked DODUMP. A user could quite legitimately madvise(MADV_DONTDUMP) their hugetlbfs memory for a while and later request that madvise(MADV_DODUMP) on the same memory. We correct this omission by allowing madvice(MADV_DODUMP) on hugetlbfs pages. [1] https://stackoverflow.com/questions/52548260/madvisedodump-on-the-same-ptr-size-as-a-successful-madvisedontdump-fails-wit [2] commit 0103bd16fb90 ("mm: prepare VM_DONTDUMP for using in drivers") Link: http://lkml.kernel.org/r/20180930054629.29150-1-daniel@linux.ibm.com Link: https://lists.launchpad.net/maria-discuss/msg05245.html Fixes: 0103bd16fb90 ("mm: prepare VM_DONTDUMP for using in drivers") Reported-by: Kenneth Penza Signed-off-by: Daniel Black Reviewed-by: Mike Kravetz Cc: Konstantin Khlebnikov Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 13f2bbf6c8c9066c9dd7402363fffd332b42d280 Author: Ashish Samant Date: Fri Oct 5 15:52:15 2018 -0700 ocfs2: fix locking for res->tracking and dlm->tracking_list commit cbe355f57c8074bc4f452e5b6e35509044c6fa23 upstream. In dlm_init_lockres() we access and modify res->tracking and dlm->tracking_list without holding dlm->track_lock. This can cause list corruptions and can end up in kernel panic. Fix this by locking res->tracking and dlm->tracking_list with dlm->track_lock instead of dlm->spinlock. Link: http://lkml.kernel.org/r/1529951192-4686-1-git-send-email-ashish.samant@oracle.com Signed-off-by: Ashish Samant Reviewed-by: Changwei Ge Acked-by: Joseph Qi Acked-by: Jun Piao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 5ebfd72e4af94dc446459180a6dc8c5f18da1cde Author: Jann Horn Date: Fri Oct 5 15:52:07 2018 -0700 mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly commit 58bc4c34d249bf1bc50730a9a209139347cfacfe upstream. 5dd0b16cdaff ("mm/vmstat: Make NR_TLB_REMOTE_FLUSH_RECEIVED available even on UP") made the availability of the NR_TLB_REMOTE_FLUSH* counters inside the kernel unconditional to reduce #ifdef soup, but (either to avoid showing dummy zero counters to userspace, or because that code was missed) didn't update the vmstat_array, meaning that all following counters would be shown with incorrect values. This only affects kernel builds with CONFIG_VM_EVENT_COUNTERS=y && CONFIG_DEBUG_TLBFLUSH=y && CONFIG_SMP=n. Link: http://lkml.kernel.org/r/20181001143138.95119-2-jannh@google.com Fixes: 5dd0b16cdaff ("mm/vmstat: Make NR_TLB_REMOTE_FLUSH_RECEIVED available even on UP") Signed-off-by: Jann Horn Reviewed-by: Kees Cook Reviewed-by: Andrew Morton Acked-by: Michal Hocko Acked-by: Roman Gushchin Cc: Davidlohr Bueso Cc: Oleg Nesterov Cc: Christoph Lameter Cc: Kemi Wang Cc: Andy Lutomirski Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 6e8e3ad9d57f70fc58e2ecbafbfd1b3f37973cfc Author: Jann Horn Date: Fri Oct 5 15:51:58 2018 -0700 proc: restrict kernel stack dumps to root commit f8a00cef17206ecd1b30d3d9f99e10d9fa707aa7 upstream. Currently, you can use /proc/self/task/*/stack to cause a stack walk on a task you control while it is running on another CPU. That means that the stack can change under the stack walker. The stack walker does have guards against going completely off the rails and into random kernel memory, but it can interpret random data from your kernel stack as instruction pointers and stack pointers. This can cause exposure of kernel stack contents to userspace. Restrict the ability to inspect kernel stacks of arbitrary tasks to root in order to prevent a local attacker from exploiting racy stack unwinding to leak kernel task stack contents. See the added comment for a longer rationale. There don't seem to be any users of this userspace API that can't gracefully bail out if reading from the file fails. Therefore, I believe that this change is unlikely to break things. In the case that this patch does end up needing a revert, the next-best solution might be to fake a single-entry stack based on wchan. Link: http://lkml.kernel.org/r/20180927153316.200286-1-jannh@google.com Fixes: 2ec220e27f50 ("proc: add /proc/*/stack") Signed-off-by: Jann Horn Acked-by: Kees Cook Cc: Alexey Dobriyan Cc: Ken Chen Cc: Will Deacon Cc: Laura Abbott Cc: Andy Lutomirski Cc: Catalin Marinas Cc: Josh Poimboeuf Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H . Peter Anvin" Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit c5220d8c27078f2f36606f77843a3a177e8c6c00 Author: Linus Torvalds Date: Thu Apr 14 11:22:00 2016 -0700 Make file credentials available to the seqfile interfaces commit 34dbbcdbf63360661ff7bda6c5f52f99ac515f92 upstream. A lot of seqfile users seem to be using things like %pK that uses the credentials of the current process, but that is actually completely wrong for filesystem interfaces. The unix semantics for permission checking files is to check permissions at _open_ time, not at read or write time, and that is not just a small detail: passing off stdin/stdout/stderr to a suid application and making the actual IO happen in privileged context is a classic exploit technique. So if we want to be able to look at permissions at read time, we need to use the file open credentials, not the current ones. Normal file accesses can just use "f_cred" (or any of the helper functions that do that, like file_ns_capable()), but the seqfile interfaces do not have any such options. It turns out that seq_file _does_ save away the user_ns information of the file, though. Since user_ns is just part of the full credential information, replace that special case with saving off the cred pointer instead, and suddenly seq_file has all the permission information it needs. Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 9db8f411f90eae46da77865d2bb72ad5fb5721b0 Author: Wei Wang Date: Thu Oct 4 10:12:37 2018 -0700 ipv6: take rcu lock in rawv6_send_hdrinc() commit a688caa34beb2fd2a92f1b6d33e40cde433ba160 upstream. In rawv6_send_hdrinc(), in order to avoid an extra dst_hold(), we directly assign the dst to skb and set passed in dst to NULL to avoid double free. However, in error case, we free skb and then do stats update with the dst pointer passed in. This causes use-after-free on the dst. Fix it by taking rcu read lock right before dst could get released to make sure dst does not get freed until the stats update is done. Note: we don't have this issue in ipv4 cause dst is not used for stats update in v4. Syzkaller reported following crash: BUG: KASAN: use-after-free in rawv6_send_hdrinc net/ipv6/raw.c:692 [inline] BUG: KASAN: use-after-free in rawv6_sendmsg+0x4421/0x4630 net/ipv6/raw.c:921 Read of size 8 at addr ffff8801d95ba730 by task syz-executor0/32088 CPU: 1 PID: 32088 Comm: syz-executor0 Not tainted 4.19.0-rc2+ #93 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 rawv6_send_hdrinc net/ipv6/raw.c:692 [inline] rawv6_sendmsg+0x4421/0x4630 net/ipv6/raw.c:921 inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 __sys_sendmsg+0x11d/0x280 net/socket.c:2152 __do_sys_sendmsg net/socket.c:2161 [inline] __se_sys_sendmsg net/socket.c:2159 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457099 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f83756edc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f83756ee6d4 RCX: 0000000000457099 RDX: 0000000000000000 RSI: 0000000020003840 RDI: 0000000000000004 RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000004d4b30 R14: 00000000004c90b1 R15: 0000000000000000 Allocated by task 32088: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554 dst_alloc+0xbb/0x1d0 net/core/dst.c:105 ip6_dst_alloc+0x35/0xa0 net/ipv6/route.c:353 ip6_rt_cache_alloc+0x247/0x7b0 net/ipv6/route.c:1186 ip6_pol_route+0x8f8/0xd90 net/ipv6/route.c:1895 ip6_pol_route_output+0x54/0x70 net/ipv6/route.c:2093 fib6_rule_lookup+0x277/0x860 net/ipv6/fib6_rules.c:122 ip6_route_output_flags+0x2c5/0x350 net/ipv6/route.c:2121 ip6_route_output include/net/ip6_route.h:88 [inline] ip6_dst_lookup_tail+0xe27/0x1d60 net/ipv6/ip6_output.c:951 ip6_dst_lookup_flow+0xc8/0x270 net/ipv6/ip6_output.c:1079 rawv6_sendmsg+0x12d9/0x4630 net/ipv6/raw.c:905 inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2114 __sys_sendmsg+0x11d/0x280 net/socket.c:2152 __do_sys_sendmsg net/socket.c:2161 [inline] __se_sys_sendmsg net/socket.c:2159 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 5356: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x83/0x290 mm/slab.c:3756 dst_destroy+0x267/0x3c0 net/core/dst.c:141 dst_destroy_rcu+0x16/0x19 net/core/dst.c:154 __rcu_reclaim kernel/rcu/rcu.h:236 [inline] rcu_do_batch kernel/rcu/tree.c:2576 [inline] invoke_rcu_callbacks kernel/rcu/tree.c:2880 [inline] __rcu_process_callbacks kernel/rcu/tree.c:2847 [inline] rcu_process_callbacks+0xf23/0x2670 kernel/rcu/tree.c:2864 __do_softirq+0x30b/0xad8 kernel/softirq.c:292 Fixes: 1789a640f556 ("raw: avoid two atomics in xmit") Signed-off-by: Wei Wang Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller [bwh: Backported to 3.16: - We don't set tstamp here - Adjust context] Signed-off-by: Ben Hutchings commit e959a6ac3ecb7be134b49f4b71ecacb43f625d1a Author: Eric W. Biederman Date: Tue Sep 15 20:04:11 2015 -0500 ipv6: Compute net once in raw6_send_hdrinc commit adb28c9d3371c845c7a28bfd4fb163aca0d0dc37 upstream. Signed-off-by: "Eric W. Biederman" Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 89982d3bc8d845c44366854a6b9c863168d2e3dc Author: Vineet Gupta Date: Fri Oct 5 12:48:48 2018 -0700 ARC: clone syscall to setp r25 as thread pointer commit c58a584f05e35d1d4342923cd7aac07d9c3d3d16 upstream. Per ARC TLS ABI, r25 is designated TP (thread pointer register). However so far kernel didn't do any special treatment, like setting up usermode r25, even for CLONE_SETTLS. We instead relied on libc runtime to do this, in say clone libc wrapper [1]. This was deliberate to keep kernel ABI agnostic (userspace could potentially change TP, specially for different ARC ISA say ARCompact vs. ARCv2 with different spare registers etc) However userspace setting up r25, after clone syscall opens a race, if child is not scheduled and gets a signal instead. It starts off in userspace not in clone but in a signal handler and anything TP sepcific there such as pthread_self() fails which showed up with uClibc testsuite nptl/tst-kill6 [2] Fix this by having kernel populate r25 to TP value. So this locks in ABI, but it was not going to change anyways, and fwiw is same for both ARCompact (arc700 core) and ARCvs (HS3x cores) [1] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/arc/clone.S [2] https://github.com/wbx-github/uclibc-ng-test/blob/master/test/nptl/tst-kill6.c Fixes: ARC STAR 9001378481 Reported-by: Nikita Sobolev Signed-off-by: Vineet Gupta Signed-off-by: Ben Hutchings commit 233d3688bfcfac7774a7ff8aedea5b1e9bf13c51 Author: Maciej W. Rozycki Date: Tue Oct 2 12:50:11 2018 +0100 MIPS: memset: Fix CPU_DADDI_WORKAROUNDS `small_fixup' regression commit 148b9aba99e0bbadf361747d21456e1589015f74 upstream. Fix a commit 8a8158c85e1e ("MIPS: memset.S: EVA & fault support for small_memset") regression and remove assembly warnings: arch/mips/lib/memset.S: Assembler messages: arch/mips/lib/memset.S:243: Warning: Macro instruction expanded into multiple instructions in a branch delay slot triggering with the CPU_DADDI_WORKAROUNDS option set and this code: PTR_SUBU a2, t1, a0 jr ra PTR_ADDIU a2, 1 This is because with that option in place the DADDIU instruction, which the PTR_ADDIU CPP macro expands to, becomes a GAS macro, which in turn expands to an LI/DADDU (or actually ADDIU/DADDU) sequence: 13c: 01a4302f dsubu a2,t1,a0 140: 03e00008 jr ra 144: 24010001 li at,1 148: 00c1302d daddu a2,a2,at ... Correct this by switching off the `noreorder' assembly mode and letting GAS schedule this jump's delay slot, as there is nothing special about it that would require manual scheduling. With this change in place correct code is produced: 13c: 01a4302f dsubu a2,t1,a0 140: 24010001 li at,1 144: 03e00008 jr ra 148: 00c1302d daddu a2,a2,at ... Signed-off-by: Maciej W. Rozycki Signed-off-by: Paul Burton Fixes: 8a8158c85e1e ("MIPS: memset.S: EVA & fault support for small_memset") Patchwork: https://patchwork.linux-mips.org/patch/20833/ Cc: Ralf Baechle [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 014c6bd31bcc69c847f29d1ac5b06eb5de16dcf1 Author: Ido Schimmel Date: Mon Oct 1 12:21:59 2018 +0300 team: Forbid enslaving team device to itself commit 471b83bd8bbe4e89743683ef8ecb78f7029d8288 upstream. team's ndo_add_slave() acquires 'team->lock' and later tries to open the newly enslaved device via dev_open(). This emits a 'NETDEV_UP' event that causes the VLAN driver to add VLAN 0 on the team device. team's ndo_vlan_rx_add_vid() will also try to acquire 'team->lock' and deadlock. Fix this by checking early at the enslavement function that a team device is not being enslaved to itself. A similar check was added to the bond driver in commit 09a89c219baf ("bonding: disallow enslaving a bond to itself"). WARNING: possible recursive locking detected 4.18.0-rc7+ #176 Not tainted -------------------------------------------- syz-executor4/6391 is trying to acquire lock: (____ptrval____) (&team->lock){+.+.}, at: team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868 but task is already holding lock: (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&team->lock); lock(&team->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by syz-executor4/6391: #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline] #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4662 #1: (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947 stack backtrace: CPU: 1 PID: 6391 Comm: syz-executor4 Not tainted 4.18.0-rc7+ #176 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_deadlock_bug kernel/locking/lockdep.c:1765 [inline] check_deadlock kernel/locking/lockdep.c:1809 [inline] validate_chain kernel/locking/lockdep.c:2405 [inline] __lock_acquire.cold.64+0x1fb/0x486 kernel/locking/lockdep.c:3435 lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924 __mutex_lock_common kernel/locking/mutex.c:757 [inline] __mutex_lock+0x176/0x1820 kernel/locking/mutex.c:894 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:909 team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868 vlan_add_rx_filter_info+0x14a/0x1d0 net/8021q/vlan_core.c:210 __vlan_vid_add net/8021q/vlan_core.c:278 [inline] vlan_vid_add+0x63e/0x9d0 net/8021q/vlan_core.c:308 vlan_device_event.cold.12+0x2a/0x2f net/8021q/vlan.c:381 notifier_call_chain+0x180/0x390 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 [inline] raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735 call_netdevice_notifiers net/core/dev.c:1753 [inline] dev_open+0x173/0x1b0 net/core/dev.c:1433 team_port_add drivers/net/team/team.c:1219 [inline] team_add_slave+0xa8b/0x1c30 drivers/net/team/team.c:1948 do_set_master+0x1c9/0x220 net/core/rtnetlink.c:2248 do_setlink+0xba4/0x3e10 net/core/rtnetlink.c:2382 rtnl_setlink+0x2a9/0x400 net/core/rtnetlink.c:2636 rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4665 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2455 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4683 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343 netlink_sendmsg+0xa18/0xfd0 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:642 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:652 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2126 __sys_sendmsg+0x11d/0x290 net/socket.c:2164 __do_sys_sendmsg net/socket.c:2173 [inline] __se_sys_sendmsg net/socket.c:2171 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2171 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x456b29 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f9706bf8c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f9706bf96d4 RCX: 0000000000456b29 RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000004 RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000004d3548 R14: 00000000004c8227 R15: 0000000000000000 Fixes: 87002b03baab ("net: introduce vlan_vid_[add/del] and use them instead of direct [add/kill]_vid ndo calls") Signed-off-by: Ido Schimmel Reported-and-tested-by: syzbot+bd051aba086537515cdb@syzkaller.appspotmail.com Signed-off-by: David S. Miller [bwh: Backported to 3.16: drop the extack message] Signed-off-by: Ben Hutchings commit a5a6cebdd016e2d1cc3c60359fce846d5efe16f4 Author: Rafael J. Wysocki Date: Thu Oct 4 11:08:12 2018 +0200 PM / core: Clear the direct_complete flag on errors commit 69e445ab8b66a9f30519842ef18be555d3ee9b51 upstream. If __device_suspend() runs asynchronously (in which case the device passed to it is in dpm_suspended_list at that point) and it returns early on an error or pending wakeup, and the power.direct_complete flag has been set for the device already, the subsequent device_resume() will be confused by that and it will call pm_runtime_enable() incorrectly, as runtime PM has not been disabled for the device by __device_suspend(). To avoid that, clear power.direct_complete if __device_suspend() is not going to disable runtime PM for the device before returning. Fixes: aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily) Reported-by: Al Cooper Tested-by: Al Cooper Reviewed-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit 6dca1bd02697b0a83526b2cfe82feb4ed7545a0f Author: Eugeniy Paltsev Date: Wed Oct 3 19:45:38 2018 +0300 drm: fb-helper: Reject all pixel format changing requests commit db05c481977599236f12a85e55de9f5ab37b0a2c upstream. drm fbdev emulation doesn't support changing the pixel format at all, so reject all pixel format changing requests. Signed-off-by: Eugeniy Paltsev Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181003164538.5534-1-Eugeniy.Paltsev@synopsys.com Signed-off-by: Ben Hutchings commit ca4e2d514016ba01b416c6f6fff0f1cf46644e4e Author: Aurelien Aptel Date: Thu May 17 16:35:07 2018 +0200 smb2: fix missing files in root share directory listing commit 0595751f267994c3c7027377058e4185b3a28e75 upstream. When mounting a Windows share that is the root of a drive (eg. C$) the server does not return . and .. directory entries. This results in the smb2 code path erroneously skipping the 2 first entries. Pseudo-code of the readdir() code path: cifs_readdir(struct file, struct dir_context) initiate_cifs_search <-- if no reponse cached yet server->ops->query_dir_first dir_emit_dots dir_emit <-- adds "." and ".." if we're at pos=0 find_cifs_entry initiate_cifs_search <-- if pos < start of current response (restart search) server->ops->query_dir_next <-- if pos > end of current response (fetch next search res) for(...) <-- loops over cur response entries starting at pos cifs_filldir <-- skip . and .., emit entry cifs_fill_dirent dir_emit pos++ A) dir_emit_dots() always adds . & .. and sets the current dir pos to 2 (0 and 1 are done). Therefore we always want the index_to_find to be 2 regardless of if the response has . and .. B) smb1 code initializes index_of_last_entry with a +2 offset in cifssmb.c CIFSFindFirst(): psrch_inf->index_of_last_entry = 2 /* skip . and .. */ + psrch_inf->entries_in_buffer; Later in find_cifs_entry() we want to find the next dir entry at pos=2 as a result of (A) first_entry_in_buffer = cfile->srch_inf.index_of_last_entry - cfile->srch_inf.entries_in_buffer; This var is the dir pos that the first entry in the buffer will have therefore it must be 2 in the first call. If we don't offset index_of_last_entry by 2 (like in (B)), first_entry_in_buffer=0 but we were instructed to get pos=2 so this code in find_cifs_entry() skips the 2 first which is ok for non-root shares, as it skips . and .. from the response but is not ok for root shares where the 2 first are actual files pos_in_buf = index_to_find - first_entry_in_buffer; // pos_in_buf=2 // we skip 2 first response entries :( for (i = 0; (i < (pos_in_buf)) && (cur_ent != NULL); i++) { /* go entry by entry figuring out which is first */ cur_ent = nxt_dir_entry(cur_ent, end_of_smb, cfile->srch_inf.info_level); } C) cifs_filldir() skips . and .. so we can safely ignore them for now. Sample program: int main(int argc, char **argv) { const char *path = argc >= 2 ? argv[1] : "."; DIR *dh; struct dirent *de; printf("listing path <%s>\n", path); dh = opendir(path); if (!dh) { printf("opendir error %d\n", errno); return 1; } while (1) { de = readdir(dh); if (!de) { if (errno) { printf("readdir error %d\n", errno); return 1; } printf("end of listing\n"); break; } printf("off=%lu <%s>\n", de->d_off, de->d_name); } return 0; } Before the fix with SMB1 on root shares: <.> off=1 <..> off=2 <$Recycle.Bin> off=3 off=4 and on non-root shares: <.> off=1 <..> off=4 <-- after adding .., the offsets jumps to +2 because <2536> off=5 we skipped . and .. from response buffer (C) <411> off=6 but still incremented pos off=7 off=8 Therefore the fix for smb2 is to mimic smb1 behaviour and offset the index_of_last_entry by 2. Test results comparing smb1 and smb2 before/after the fix on root share, non-root shares and on large directories (ie. multi-response dir listing): PRE FIX ======= pre-1-root VS pre-2-root: ERR pre-2-root is missing [bootmgr, $Recycle.Bin] pre-1-nonroot VS pre-2-nonroot: OK~ same files, same order, different offsets pre-1-nonroot-large VS pre-2-nonroot-large: OK~ same files, same order, different offsets POST FIX ======== post-1-root VS post-2-root: OK same files, same order, same offsets post-1-nonroot VS post-2-nonroot: OK same files, same order, same offsets post-1-nonroot-large VS post-2-nonroot-large: OK same files, same order, same offsets REGRESSION? =========== pre-1-root VS post-1-root: OK same files, same order, same offsets pre-1-nonroot VS post-1-nonroot: OK same files, same order, same offsets BugLink: https://bugzilla.samba.org/show_bug.cgi?id=13107 Signed-off-by: Aurelien Aptel Signed-off-by: Paulo Alcantara Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Ben Hutchings commit 4086d270ae6b72aee0ad480996c849c97384dc32 Author: Eric Dumazet Date: Tue Oct 2 15:47:35 2018 -0700 rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096 commit 0e1d6eca5113858ed2caea61a5adc03c595f6096 upstream. We have an impressive number of syzkaller bugs that are linked to the fact that syzbot was able to create a networking device with millions of TX (or RX) queues. Let's limit the number of RX/TX queues to 4096, this really should cover all known cases. A separate patch will add various cond_resched() in the loops handling sysfs entries at device creation and dismantle. Tested: lpaa6:~# ip link add gre-4097 numtxqueues 4097 numrxqueues 4097 type ip6gretap RTNETLINK answers: Invalid argument lpaa6:~# time ip link add gre-4096 numtxqueues 4096 numrxqueues 4096 type ip6gretap real 0m0.180s user 0m0.000s sys 0m0.107s Fixes: 76ff5cc91935 ("rtnl: allow to specify number of rx and tx queues on device creation") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit e5f3c81900439a7a504c451decd2933faaf87c6d Author: Jiri Olsa Date: Sun Sep 23 18:13:43 2018 +0200 perf/ring_buffer: Prevent concurent ring buffer access commit cd6fb677ce7e460c25bdd66f689734102ec7d642 upstream. Some of the scheduling tracepoints allow the perf_tp_event code to write to ring buffer under different cpu than the code is running on. This results in corrupted ring buffer data demonstrated in following perf commands: # perf record -e 'sched:sched_switch,sched:sched_wakeup' perf bench sched messaging # Running 'sched/messaging' benchmark: # 20 sender and receiver processes per group # 10 groups == 400 processes run Total time: 0.383 [sec] [ perf record: Woken up 8 times to write data ] 0x42b890 [0]: failed to process type: -1765585640 [ perf record: Captured and wrote 4.825 MB perf.data (29669 samples) ] # perf report --stdio 0x42b890 [0]: failed to process type: -1765585640 The reason for the corruption are some of the scheduling tracepoints, that have __perf_task dfined and thus allow to store data to another cpu ring buffer: sched_waking sched_wakeup sched_wakeup_new sched_stat_wait sched_stat_sleep sched_stat_iowait sched_stat_blocked The perf_tp_event function first store samples for current cpu related events defined for tracepoint: hlist_for_each_entry_rcu(event, head, hlist_entry) perf_swevent_event(event, count, &data, regs); And then iterates events of the 'task' and store the sample for any task's event that passes tracepoint checks: ctx = rcu_dereference(task->perf_event_ctxp[perf_sw_context]); list_for_each_entry_rcu(event, &ctx->event_list, event_entry) { if (event->attr.type != PERF_TYPE_TRACEPOINT) continue; if (event->attr.config != entry->type) continue; perf_swevent_event(event, count, &data, regs); } Above code can race with same code running on another cpu, ending up with 2 cpus trying to store under the same ring buffer, which is specifically not allowed. This patch prevents the problem, by allowing only events with the same current cpu to receive the event. NOTE: this requires the use of (per-task-)per-cpu buffers for this feature to work; perf-record does this. Signed-off-by: Jiri Olsa [peterz: small edits to Changelog] Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Andrew Vagin Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: e6dab5ffab59 ("perf/trace: Add ability to set a target task for events") Link: http://lkml.kernel.org/r/20180923161343.GB15054@krava Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit df89373a21531c3cb9315c947d39b7d889c3648a Author: Peter Zijlstra Date: Tue Sep 25 17:58:35 2018 +0200 perf/core: Fix perf_pmu_unregister() locking commit a9f9772114c8b07ae75bcb3654bd017461248095 upstream. When we unregister a PMU, we fail to serialize the @pmu_idr properly. Fix that by doing the entire thing under pmu_lock. 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: 2e80a82a49c4 ("perf: Dynamic pmu types") Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: - Also remove "out" label in free_pmu_context() - Adjust context] Signed-off-by: Ben Hutchings commit 4ccc1fac64f29a347a02f13ca556fec46203c07a Author: Jiri Olsa Date: Thu Oct 20 13:10:11 2016 +0200 perf/core: Protect PMU device removal with a 'pmu_bus_running' check, to fix CONFIG_DEBUG_TEST_DRIVER_REMOVE=y kernel panic commit 0933840acf7b65d6d30a5b6089d882afea57aca3 upstream. CAI Qian reported a crash in the PMU uncore device removal code, enabled by the CONFIG_DEBUG_TEST_DRIVER_REMOVE=y option: https://marc.info/?l=linux-kernel&m=147688837328451 The reason for the crash is that perf_pmu_unregister() tries to remove a PMU device which is not added at this point. We add PMU devices only after pmu_bus is registered, which happens in the perf_event_sysfs_init() call and sets the 'pmu_bus_running' flag. The fix is to get the 'pmu_bus_running' flag state at the point the PMU is taken out of the PMU list and remove the device later only if it's set. Reported-by: CAI Qian Tested-by: CAI Qian Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Greg Kroah-Hartman Cc: Jiri Olsa Cc: Kan Liang Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Rob Herring Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20161020111011.GA13361@krava Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: no address filter attributes to clean up] Signed-off-by: Ben Hutchings commit 4f9007359bcd28bc83c63cb9af38d8b2c8c1670d Author: Andy Lutomirski Date: Mon Oct 1 12:52:15 2018 -0700 x86/vdso: Fix asm constraints on vDSO syscall fallbacks commit 715bd9d12f84d8f5cc8ad21d888f9bc304a8eb0b upstream. The syscall fallbacks in the vDSO have incorrect asm constraints. They are not marked as writing to their outputs -- instead, they are marked as clobbering "memory", which is useless. In particular, gcc is smart enough to know that the timespec parameter hasn't escaped, so a memory clobber doesn't clobber it. And passing a pointer as an asm *input* does not tell gcc that the pointed-to value is changed. Add in the fact that the asm instructions weren't volatile, and gcc was free to omit them entirely unless their sole output (the return value) is used. Which it is (phew!), but that stops happening with some upcoming patches. As a trivial example, the following code: void test_fallback(struct timespec *ts) { vdso_fallback_gettime(CLOCK_MONOTONIC, ts); } compiles to: 00000000000000c0 : c0: c3 retq To add insult to injury, the RCX and R11 clobbers on 64-bit builds were missing. The "memory" clobber is also unnecessary -- no ordering with respect to other memory operations is needed, but that's going to be fixed in a separate not-for-stable patch. Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu") Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/2c0231690551989d2fafa60ed0e7b5cc8b403908.1538422295.git.luto@kernel.org [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit a25d12961a5f2543c9a9185df8af5d1ab1cf1cce Author: Dan Carpenter Date: Sat Sep 22 16:46:48 2018 +0300 net: sched: act_ipt: check for underflow in __tcf_ipt_init() commit aeadd93f2b0a609f603ac33e574b97a9832d1b90 upstream. If "td->u.target_size" is larger than sizeof(struct xt_entry_target) we return -EINVAL. But we don't check whether it's smaller than sizeof(struct xt_entry_target) and that could lead to an out of bounds read. Fixes: 7ba699c604ab ("[NET_SCHED]: Convert actions from rtnetlink to new netlink API") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 42695dbe46603e2899db34bb8fc900b575c68332 Author: Mathias Nyman Date: Mon Oct 1 18:36:07 2018 +0300 xhci: Add missing CAS workaround for Intel Sunrise Point xHCI commit ffe84e01bb1b38c7eb9c6b6da127a6c136d251df upstream. The workaround for missing CAS bit is also needed for xHC on Intel sunrisepoint PCH. For more details see: Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8 Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 2fdce53c4a81397774363dfda8be635b8a4468db Author: Dave Martin Date: Thu Sep 27 16:53:21 2018 +0100 arm64: KVM: Tighten guest core register access from userspace commit d26c25a9d19b5976b319af528886f89cf455692d upstream. We currently allow userspace to access the core register file in about any possible way, including straddling multiple registers and doing unaligned accesses. This is not the expected use of the ABI, and nobody is actually using it that way. Let's tighten it by explicitly checking the size and alignment for each field of the register file. Fixes: 2f4a07c5f9fe ("arm64: KVM: guest one-reg interface") Reviewed-by: Christoffer Dall Reviewed-by: Mark Rutland Signed-off-by: Dave Martin [maz: rewrote Dave's initial patch to be more easily backported] Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Ben Hutchings commit 40b1b4e0aa2542ef68eec505ebcb07ff29527bb6 Author: Felix Fietkau Date: Sat Sep 29 16:01:58 2018 +0200 mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys commit 211710ca74adf790b46ab3867fcce8047b573cd1 upstream. key->sta is only valid after ieee80211_key_link, which is called later in this function. Because of that, the IEEE80211_KEY_FLAG_RX_MGMT is never set when management frame protection is enabled. Fixes: e548c49e6dc6b ("mac80211: add key flag for management keys") Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit 1ed20af2554ce6f3b38f24f20a1667e6e6ebd961 Author: Kees Cook Date: Fri Sep 28 15:17:50 2018 -0700 pstore/ram: Fix failure-path memory leak in ramoops_init commit bac6f6cda206ad7cbe0c73c35e494377ce9c4749 upstream. As reported by nixiaoming, with some minor clarifications: 1) memory leak in ramoops_register_dummy(): dummy_data = kzalloc(sizeof(*dummy_data), GFP_KERNEL); but no kfree() if platform_device_register_data() fails. 2) memory leak in ramoops_init(): Missing platform_device_unregister(dummy) and kfree(dummy_data) if platform_driver_register(&ramoops_driver) fails. I've clarified the purpose of ramoops_register_dummy(), and added a common cleanup routine for all three failure paths to call. Reported-by: nixiaoming Cc: Anton Vorontsov Cc: Colin Cross Cc: Tony Luck Cc: Joel Fernandes Cc: Geliang Tang Signed-off-by: Kees Cook [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 699f809e73317a968576d73e0a0d6661cdedc09e Author: Vitaly Kuznetsov Date: Mon Sep 17 04:14:55 2018 +0000 tools: hv: fcopy: set 'error' in case an unknown operation was requested commit c2d68afba86d1ff01e7300c68bc16a9234dcd8e9 upstream. 'error' variable is left uninitialized in case we see an unknown operation. As we don't immediately return and proceed to pwrite() we need to set it to something, HV_E_FAIL sounds good enough. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 23c5bafe27e5ef5da8c6b3b0d6b68d30665b91be Author: Dexuan Cui Date: Mon Sep 17 04:14:54 2018 +0000 Drivers: hv: vmbus: Use get/put_cpu() in vmbus_connect() commit 41e270f6898e7502be9fd6920ee0a108ca259d36 upstream. With CONFIG_DEBUG_PREEMPT=y, I always see this warning: BUG: using smp_processor_id() in preemptible [00000000] Fix the false warning by using get/put_cpu(). Here vmbus_connect() sends a message to the host and waits for the host's response. The host will deliver the response message and an interrupt on CPU msg->target_vcpu, and later the interrupt handler will wake up vmbus_connect(). vmbus_connect() doesn't really have to run on the same cpu as CPU msg->target_vcpu, so it's safe to call put_cpu() just here. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: - smp_processor_id() is only used once here - Adjust context] Signed-off-by: Ben Hutchings commit 6109503a9db0d950f8b95d3158efcc6cdc16aa6e Author: Shahed Shaikh Date: Wed Sep 26 12:41:10 2018 -0700 qlcnic: fix Tx descriptor corruption on 82xx devices commit c333fa0c4f220f8f7ea5acd6b0ebf3bf13fd684d upstream. In regular NIC transmission flow, driver always configures MAC using Tx queue zero descriptor as a part of MAC learning flow. But with multi Tx queue supported NIC, regular transmission can occur on any non-zero Tx queue and from that context it uses Tx queue zero descriptor to configure MAC, at the same time TX queue zero could be used by another CPU for regular transmission which could lead to Tx queue zero descriptor corruption and cause FW abort. This patch fixes this in such a way that driver always configures learned MAC address from the same Tx queue which is used for regular transmission. Fixes: 7e2cf4feba05 ("qlcnic: change driver hardware interface mechanism") Signed-off-by: Shahed Shaikh Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit abbafd5f44a5f0e510c52268fe332638909fbddf Author: Florian Fainelli Date: Fri Sep 28 16:18:56 2018 -0700 smsc95xx: Check for Wake-on-LAN modes commit c530c471ba37bdd9fe1c7185b01455c00ae606fb upstream. The driver does not check for Wake-on-LAN modes specified by an user, but will conditionally set the device as wake-up enabled or not based on that, which could be a very confusing user experience. Fixes: e0e474a83c18 ("smsc95xx: add wol magic packet support") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 961a5cea9c21776d22059a6af0adf67b4589b59d Author: Florian Fainelli Date: Fri Sep 28 16:18:55 2018 -0700 smsc75xx: Check for Wake-on-LAN modes commit 9c734b2769a73eea2e9e9767c0e0bf839ff23679 upstream. The driver does not check for Wake-on-LAN modes specified by an user, but will conditionally set the device as wake-up enabled or not based on that, which could be a very confusing user experience. Fixes: 6c636503260d ("smsc75xx: add wol magic packet support") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 157e0b1feee0c1a1406f23cb2a0920544b5c8324 Author: Florian Fainelli Date: Fri Sep 28 16:18:54 2018 -0700 r8152: Check for supported Wake-on-LAN Modes commit f2750df1548bd8a2b060eb609fc43ca82811af4c upstream. The driver does not check for Wake-on-LAN modes specified by an user, but will conditionally set the device as wake-up enabled or not based on that, which could be a very confusing user experience. Fixes: 21ff2e8976b1 ("r8152: support WOL") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit dc702431f516df088dd9ca61ebc19051423db0ab Author: Florian Fainelli Date: Fri Sep 28 16:18:53 2018 -0700 sr9800: Check for supported Wake-on-LAN modes commit c5cb93e994ffb43b7b3b1ff10b9f928f54574a36 upstream. The driver currently silently accepts unsupported Wake-on-LAN modes (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user, which is confusing. Fixes: 19a38d8e0aa3 ("USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 8f28373117e1f20dd152179737dcb1a405dc41f6 Author: Florian Fainelli Date: Fri Sep 28 16:18:51 2018 -0700 ax88179_178a: Check for supported Wake-on-LAN modes commit 5ba6b4aa9a410c5e2c6417df52b5e2118ea9b467 upstream. The driver currently silently accepts unsupported Wake-on-LAN modes (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user, which is confusing. Fixes: e2ca90c276e1 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 80d5febff08d1c4b4e452c721b41221a9be4b2ef Author: Florian Fainelli Date: Fri Sep 28 16:18:50 2018 -0700 asix: Check for supported Wake-on-LAN modes commit c4ce446e33d7a0e978256ac6fea4c80e59d9de5f upstream. The driver currently silently accepts unsupported Wake-on-LAN modes (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user, which is confusing. Fixes: 2e55cc7210fe ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet adapters") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit d585747f95153146964bc3b5d81bcf34fab0e23a Author: Leonard Crestez Date: Fri Sep 21 18:03:18 2018 +0300 crypto: mxs-dcp - Fix wait logic on chan threads commit d80771c08363ad7fbf0f56f5301e7ca65065c582 upstream. When compiling with CONFIG_DEBUG_ATOMIC_SLEEP=y the mxs-dcp driver prints warnings such as: WARNING: CPU: 0 PID: 120 at kernel/sched/core.c:7736 __might_sleep+0x98/0x9c do not call blocking ops when !TASK_RUNNING; state=1 set at [<8081978c>] dcp_chan_thread_sha+0x3c/0x2ec The problem is that blocking ops will manipulate current->state themselves so it is not allowed to call them between set_current_state(TASK_INTERRUPTIBLE) and schedule(). Fix this by converting the per-chan mutex to a spinlock (it only protects tiny list ops anyway) and rearranging the wait logic so that callbacks are called current->state as TASK_RUNNING. Those callbacks will indeed call blocking ops themselves so this is required. Signed-off-by: Leonard Crestez Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit d4f7913ccee18cde1a778a58c077e07e1d46fff1 Author: Daniel Drake Date: Thu Sep 27 15:47:33 2018 -0500 PCI: Reprogram bridge prefetch registers on resume commit 083874549fdfefa629dfa752785e20427dde1511 upstream. On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3 suspend/resume. The affected products include multiple generations of NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such as: fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04 [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown] DRM: failed to idle channel 0 [DRM] Similarly, the NVIDIA proprietary driver also fails after resume (black screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for diagnosis, and their response indicated that it's a problem with the parent PCI bridge (on the Intel SoC), not the GPU. Runtime suspend/resume works fine, only S3 suspend is affected. We found a workaround: on resume, rewrite the Intel PCI bridge 'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the cases that I checked, this register has value 0 and we just have to rewrite that value. Linux already saves and restores PCI config space during suspend/resume, but this register was being skipped because upon resume, it already has value 0 (the correct, pre-suspend value). Intel appear to have previously acknowledged this behaviour and the requirement to rewrite this register: https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 Based on that, rewrite the prefetch register values even when that appears unnecessary. We have confirmed this solution on all the affected models we have in-hands (X542UQ, UX533FD, X530UN, V272UN). Additionally, this solves an issue where r8169 MSI-X interrupts were broken after S3 suspend/resume on ASUS X441UAR. This issue was recently worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop that we had not yet patched. I suspect it will also fix the issue that was worked around in commit 7c53a722459c ("r8169: don't use MSI-X on RTL8168g"). Thomas Martitz reports that this change also solves an issue where the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3 suspend/resume. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069 Signed-off-by: Daniel Drake Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Reviewed-By: Peter Wu Signed-off-by: Ben Hutchings commit b1af289fa5dfa9080908bdecb0ca1d59b6714666 Author: Guoju Fang Date: Thu Sep 27 23:41:46 2018 +0800 bcache: add separate workqueue for journal_write to avoid deadlock commit 0f843e65d9eef4936929bb036c5f771fb261eea4 upstream. After write SSD completed, bcache schedules journal_write work to system_wq, which is a public workqueue in system, without WQ_MEM_RECLAIM flag. system_wq is also a bound wq, and there may be no idle kworker on current processor. Creating a new kworker may unfortunately need to reclaim memory first, by shrinking cache and slab used by vfs, which depends on bcache device. That's a deadlock. This patch create a new workqueue for journal_write with WQ_MEM_RECLAIM flag. It's rescuer thread will work to avoid the deadlock. Signed-off-by: Guoju Fang Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit c0f768d195d2901ba845a3b8eaa602e65a4428a4 Author: Florian Schmaus Date: Thu Jul 26 12:17:39 2018 +0800 bcache: do not assign in if condition in bcache_init() commit 16c1fdf4cfd6c0091e59b93ec2cb7e99973f8244 upstream. Fixes an error condition reported by checkpatch.pl which is caused by assigning a variable in an if condition. Signed-off-by: Florian Schmaus Signed-off-by: Coly Li Signed-off-by: Jens Axboe [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit fb5fdc3830b82f15c00e2f204160c467a0bdc352 Author: Liang Chen Date: Mon Oct 30 14:46:35 2017 -0700 bcache: explicitly destroy mutex while exiting commit 330a4db89d39a6b43f36da16824eaa7a7509d34d upstream. mutex_destroy does nothing most of time, but it's better to call it to make the code future proof and it also has some meaning for like mutex debug. As Coly pointed out in a previous review, bcache_exit() may not be able to handle all the references properly if userspace registers cache and backing devices right before bch_debug_init runs and bch_debug_init failes later. So not exposing userspace interface until everything is ready to avoid that issue. Signed-off-by: Liang Chen Reviewed-by: Michael Lyle Reviewed-by: Coly Li Reviewed-by: Eric Wheeler Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit feb6110f18a4e55a370189a1a65dae8c945b8cb1 Author: Bhaktipriya Shridhar Date: Wed Jun 8 01:57:19 2016 +0530 bcache: Remove deprecated create_workqueue commit 81baf90af2dcc8259e99e2f236024524b55313fc upstream. alloc_workqueue replaces deprecated create_workqueue(). Dedicated workqueues have been used since bcache_wq and moving_gc_wq are workqueues for writes and are being used on a memory reclaim path. WQ_MEM_RECLAIM has been set to ensure forward progress under memory pressure. Since there are only a fixed number of work items, explicit concurrency limit is unnecessary here. Signed-off-by: Bhaktipriya Shridhar Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit 0063e500cf93dbb04976b369b27d2a0b37e1d7cf Author: Jens Axboe Date: Fri Mar 6 08:37:46 2015 -0700 bcache: don't embed 'return' statements in closure macros commit 77b5a08427e87514c33730afc18cd02c9475e2c3 upstream. This is horribly confusing, it breaks the flow of the code without it being apparent in the caller. Signed-off-by: Jens Axboe Acked-by: Christoph Hellwig Signed-off-by: Ben Hutchings commit ddbdc753f5567d04571669f30ffe622b17d07fe0 Author: Tomi Valkeinen Date: Wed Sep 26 18:11:22 2018 +0200 fbdev/omapfb: fix omapfb_memory_read infoleak commit 1bafcbf59fed92af58955024452f45430d3898c5 upstream. OMAPFB_MEMORY_READ ioctl reads pixels from the LCD's memory and copies them to a userspace buffer. The code has two issues: - The user provided width and height could be large enough to overflow the calculations - The copy_to_user() can copy uninitialized memory to the userspace, which might contain sensitive kernel information. Fix these by limiting the width & height parameters, and only copying the amount of data that we actually received from the LCD. Signed-off-by: Tomi Valkeinen Reported-by: Jann Horn Cc: security@kernel.org Cc: Will Deacon Cc: Jann Horn Cc: Tony Lindgren Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Ben Hutchings commit fbf891d16e8b100b15d5d3b61805ad5cae933da3 Author: Paolo Abeni Date: Mon Sep 24 15:48:19 2018 +0200 ip_tunnel: be careful when accessing the inner header commit ccfec9e5cb2d48df5a955b7bf47f7782157d3bc2 upstream. Cong noted that we need the same checks introduced by commit 76c0ddd8c3a6 ("ip6_tunnel: be careful when accessing the inner header") even for ipv4 tunnels. Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Suggested-by: Cong Wang Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 15a47fe5246560eb15226ef4c8b6557f39a31bc2 Author: Johan Hovold Date: Mon Sep 24 15:28:10 2018 +0200 USB: serial: simple: add Motorola Tetra MTP6550 id commit f5fad711c06e652f90f581fc7c2caee327c33d31 upstream. Add device-id for the Motorola Tetra radio MTP6550. Bus 001 Device 004: ID 0cad:9012 Motorola CGISS Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0cad Motorola CGISS idProduct 0x9012 bcdDevice 24.16 iManufacturer 1 Motorola Solutions, Inc. iProduct 2 TETRA PEI interface iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 55 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 3 Generic Serial config bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Reported-by: Hans Hult Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 38023af173ecfee5840ebc3471d81d9c97e88296 Author: Michael Bringmann Date: Thu Sep 20 11:45:13 2018 -0500 powerpc/pseries: Fix unitialized timer reset on migration commit 8604895a34d92f5e186ceb931b0d1b384030ea3d upstream. After migration of a powerpc LPAR, the kernel executes code to update the system state to reflect new platform characteristics. Such changes include modifications to device tree properties provided to the system by PHYP. Property notifications received by the post_mobility_fixup() code are passed along to the kernel in general through a call to of_update_property() which in turn passes such events back to all modules through entries like the '.notifier_call' function within the NUMA module. When the NUMA module updates its state, it resets its event timer. If this occurs after a previous call to stop_topology_update() or on a system without VPHN enabled, the code runs into an unitialized timer structure and crashes. This patch adds a safety check along this path toward the problem code. An example crash log is as follows. ibmvscsi 30000081: Re-enabling adapter! ------------[ cut here ]------------ kernel BUG at kernel/time/timer.c:958! Oops: Exception in kernel mode, sig: 5 [#1] LE SMP NR_CPUS=2048 NUMA pSeries Modules linked in: nfsv3 nfs_acl nfs tcp_diag udp_diag inet_diag lockd unix_diag af_packet_diag netlink_diag grace fscache sunrpc xts vmx_crypto pseries_rng sg binfmt_misc ip_tables xfs libcrc32c sd_mod ibmvscsi ibmveth scsi_transport_srp dm_mirror dm_region_hash dm_log dm_mod CPU: 11 PID: 3067 Comm: drmgr Not tainted 4.17.0+ #179 ... NIP mod_timer+0x4c/0x400 LR reset_topology_timer+0x40/0x60 Call Trace: 0xc0000003f9407830 (unreliable) reset_topology_timer+0x40/0x60 dt_update_callback+0x100/0x120 notifier_call_chain+0x90/0x100 __blocking_notifier_call_chain+0x60/0x90 of_property_notify+0x90/0xd0 of_update_property+0x104/0x150 update_dt_property+0xdc/0x1f0 pseries_devicetree_update+0x2d0/0x510 post_mobility_fixup+0x7c/0xf0 migration_store+0xa4/0xc0 kobj_attr_store+0x30/0x60 sysfs_kf_write+0x64/0xa0 kernfs_fop_write+0x16c/0x240 __vfs_write+0x40/0x200 vfs_write+0xc8/0x240 ksys_write+0x5c/0x100 system_call+0x58/0x6c Fixes: 5d88aa85c00b ("powerpc/pseries: Update CPU maps when device tree is updated") Signed-off-by: Michael Bringmann Signed-off-by: Michael Ellerman [bwh: Backported to 3.16: Also remove direct assignment to topology_timer.expires, done upstream as part of commit df7e828c1b69 "timer: Remove init_timer_deferrable() in favor of timer_setup()"] Signed-off-by: Ben Hutchings commit 0205820a7aeb6b332a101a0bcb561d94096a601d Author: Junxiao Bi Date: Thu Sep 20 12:22:51 2018 -0700 ocfs2: fix ocfs2 read block panic commit 234b69e3e089d850a98e7b3145bd00e9b52b1111 upstream. While reading block, it is possible that io error return due to underlying storage issue, in this case, BH_NeedsValidate was left in the buffer head. Then when reading the very block next time, if it was already linked into journal, that will trigger the following panic. [203748.702517] kernel BUG at fs/ocfs2/buffer_head_io.c:342! [203748.702533] invalid opcode: 0000 [#1] SMP [203748.702561] Modules linked in: ocfs2 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc dm_switch dm_queue_length dm_multipath bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i iw_cxgb4 cxgb4 cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif i2c_core ipmi_si ipmi_msghandler acpi_pad pcspkr sb_edac edac_core lpc_ich mfd_core shpchp sg tg3 ptp pps_core ext4 jbd2 mbcache2 sr_mod cdrom sd_mod ahci libahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod [203748.703024] CPU: 7 PID: 38369 Comm: touch Not tainted 4.1.12-124.18.6.el6uek.x86_64 #2 [203748.703045] Hardware name: Dell Inc. PowerEdge R620/0PXXHP, BIOS 2.5.2 01/28/2015 [203748.703067] task: ffff880768139c00 ti: ffff88006ff48000 task.ti: ffff88006ff48000 [203748.703088] RIP: 0010:[] [] ocfs2_read_blocks+0x669/0x7f0 [ocfs2] [203748.703130] RSP: 0018:ffff88006ff4b818 EFLAGS: 00010206 [203748.703389] RAX: 0000000008620029 RBX: ffff88006ff4b910 RCX: 0000000000000000 [203748.703885] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000023079fe [203748.704382] RBP: ffff88006ff4b8d8 R08: 0000000000000000 R09: ffff8807578c25b0 [203748.704877] R10: 000000000f637376 R11: 000000003030322e R12: 0000000000000000 [203748.705373] R13: ffff88006ff4b910 R14: ffff880732fe38f0 R15: 0000000000000000 [203748.705871] FS: 00007f401992c700(0000) GS:ffff880bfebc0000(0000) knlGS:0000000000000000 [203748.706370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [203748.706627] CR2: 00007f4019252440 CR3: 00000000a621e000 CR4: 0000000000060670 [203748.707124] Stack: [203748.707371] ffff88006ff4b828 ffffffffa0609f52 ffff88006ff4b838 0000000000000001 [203748.707885] 0000000000000000 0000000000000000 ffff880bf67c3800 ffffffffa05eca00 [203748.708399] 00000000023079ff ffffffff81c58b80 0000000000000000 0000000000000000 [203748.708915] Call Trace: [203748.709175] [] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2] [203748.709680] [] ? ocfs2_empty_dir_filldir+0x80/0x80 [ocfs2] [203748.710185] [] ocfs2_read_dir_block_direct+0x3b/0x200 [ocfs2] [203748.710691] [] ocfs2_prepare_dx_dir_for_insert.isra.57+0x19f/0xf60 [ocfs2] [203748.711204] [] ? ocfs2_metadata_cache_io_unlock+0x1f/0x30 [ocfs2] [203748.711716] [] ocfs2_prepare_dir_for_insert+0x13a/0x890 [ocfs2] [203748.712227] [] ? ocfs2_check_dir_for_entry+0x8e/0x140 [ocfs2] [203748.712737] [] ocfs2_mknod+0x4b2/0x1370 [ocfs2] [203748.713003] [] ocfs2_create+0x65/0x170 [ocfs2] [203748.713263] [] vfs_create+0xdb/0x150 [203748.713518] [] do_last+0x815/0x1210 [203748.713772] [] ? path_init+0xb9/0x450 [203748.714123] [] path_openat+0x80/0x600 [203748.714378] [] ? handle_pte_fault+0xd15/0x1620 [203748.714634] [] do_filp_open+0x3a/0xb0 [203748.714888] [] ? __alloc_fd+0xa7/0x130 [203748.715143] [] do_sys_open+0x12c/0x220 [203748.715403] [] ? syscall_trace_enter_phase1+0x11b/0x180 [203748.715668] [] ? system_call_after_swapgs+0xe9/0x190 [203748.715928] [] SyS_open+0x1e/0x20 [203748.716184] [] system_call_fastpath+0x18/0xd7 [203748.716440] Code: 00 00 48 8b 7b 08 48 83 c3 10 45 89 f8 44 89 e1 44 89 f2 4c 89 ee e8 07 06 11 e1 48 8b 03 48 85 c0 75 df 8b 5d c8 e9 4d fa ff ff <0f> 0b 48 8b 7d a0 e8 dc c6 06 00 48 b8 00 00 00 00 00 00 00 10 [203748.717505] RIP [] ocfs2_read_blocks+0x669/0x7f0 [ocfs2] [203748.717775] RSP Joesph ever reported a similar panic. Link: https://oss.oracle.com/pipermail/ocfs2-devel/2013-May/008931.html Link: http://lkml.kernel.org/r/20180912063207.29484-1-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Cc: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 8900ab99529726c8133f443a6dbe2a0a81c1900b Author: Joel Fernandes (Google) Date: Thu Sep 20 12:22:39 2018 -0700 mm: shmem.c: Correctly annotate new inodes for lockdep commit b45d71fb89ab8adfe727b9d0ee188ed58582a647 upstream. Directories and inodes don't necessarily need to be in the same lockdep class. For ex, hugetlbfs splits them out too to prevent false positives in lockdep. Annotate correctly after new inode creation. If its a directory inode, it will be put into a different class. This should fix a lockdep splat reported by syzbot: > ====================================================== > WARNING: possible circular locking dependency detected > 4.18.0-rc8-next-20180810+ #36 Not tainted > ------------------------------------------------------ > syz-executor900/4483 is trying to acquire lock: > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: inode_lock > include/linux/fs.h:765 [inline] > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602 > > but task is already holding lock: > 0000000025208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630 > drivers/staging/android/ashmem.c:448 > > which lock already depends on the new lock. > > -> #2 (ashmem_mutex){+.+.}: > __mutex_lock_common kernel/locking/mutex.c:925 [inline] > __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073 > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088 > ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361 > call_mmap include/linux/fs.h:1844 [inline] > mmap_region+0xf27/0x1c50 mm/mmap.c:1762 > do_mmap+0xa10/0x1220 mm/mmap.c:1535 > do_mmap_pgoff include/linux/mm.h:2298 [inline] > vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357 > ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585 > __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline] > __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline] > __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > -> #1 (&mm->mmap_sem){++++}: > __might_fault+0x155/0x1e0 mm/memory.c:4568 > _copy_to_user+0x30/0x110 lib/usercopy.c:25 > copy_to_user include/linux/uaccess.h:155 [inline] > filldir+0x1ea/0x3a0 fs/readdir.c:196 > dir_emit_dot include/linux/fs.h:3464 [inline] > dir_emit_dots include/linux/fs.h:3475 [inline] > dcache_readdir+0x13a/0x620 fs/libfs.c:193 > iterate_dir+0x48b/0x5d0 fs/readdir.c:51 > __do_sys_getdents fs/readdir.c:231 [inline] > __se_sys_getdents fs/readdir.c:212 [inline] > __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > -> #0 (&sb->s_type->i_mutex_key#9){++++}: > lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924 > down_write+0x8f/0x130 kernel/locking/rwsem.c:70 > inode_lock include/linux/fs.h:765 [inline] > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602 > ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455 > ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:501 [inline] > do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702 > __do_sys_ioctl fs/ioctl.c:709 [inline] > __se_sys_ioctl fs/ioctl.c:707 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > other info that might help us debug this: > > Chain exists of: > &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex > > Possible unsafe locking scenario: > > CPU0 CPU1 > ---- ---- > lock(ashmem_mutex); > lock(&mm->mmap_sem); > lock(ashmem_mutex); > lock(&sb->s_type->i_mutex_key#9); > > *** DEADLOCK *** > > 1 lock held by syz-executor900/4483: > #0: 0000000025208078 (ashmem_mutex){+.+.}, at: > ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448 Link: http://lkml.kernel.org/r/20180821231835.166639-1-joel@joelfernandes.org Signed-off-by: Joel Fernandes (Google) Reported-by: syzbot Reviewed-by: NeilBrown Suggested-by: NeilBrown Cc: Matthew Wilcox Cc: Peter Zijlstra Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e92d32a4f5135040f900a06ecc6cb641bb93e2d9 Author: Richard Weinberger Date: Mon Sep 3 23:06:23 2018 +0200 ubifs: Check for name being NULL while mounting commit 37f31b6ca4311b94d985fb398a72e5399ad57925 upstream. The requested device name can be NULL or an empty string. Check for that and refuse to continue. UBIFS has to do this manually since we cannot use mount_bdev(), which checks for this condition. Fixes: 1e51764a3c2ac ("UBIFS: add new flash file system") Reported-by: syzbot+38bd0f7865e5c6379280@syzkaller.appspotmail.com Signed-off-by: Richard Weinberger Signed-off-by: Ben Hutchings commit bb904fada8b4cc55edc2f2cfdad7c513ed814b04 Author: Yu Zhao Date: Wed Sep 19 15:30:51 2018 -0600 regulator: fix crash caused by null driver data commit fb6de923ca3358a91525552b4907d4cb38730bdd upstream. dev_set_drvdata() needs to be called before device_register() exposes device to userspace. Otherwise kernel crashes after it gets null pointer from dev_get_drvdata() when userspace tries to access sysfs entries. [Removed backtrace for length -- broonie] Signed-off-by: Yu Zhao Signed-off-by: Mark Brown [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 9d3a6c69c2e083f731f11a3849938a57c826c3f1 Author: Alan Stern Date: Mon Sep 10 14:00:53 2018 -0400 USB: handle NULL config in usb_find_alt_setting() commit c9a4cb204e9eb7fa7dfbe3f7d3a674fa530aa193 upstream. usb_find_alt_setting() takes a pointer to a struct usb_host_config as an argument; it searches for an interface with specified interface and alternate setting numbers in that config. However, it crashes if the usb_host_config pointer argument is NULL. Since this is a general-purpose routine, available for use in many places, we want to to be more robust. This patch makes it return NULL whenever the config argument is NULL. Signed-off-by: Alan Stern Reported-by: syzbot+19c3aaef85a89d451eac@syzkaller.appspotmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit b8a864e3f5e949c0f36f6b60297fd620623f53e5 Author: Alan Stern Date: Mon Sep 10 13:59:59 2018 -0400 USB: fix error handling in usb_driver_claim_interface() commit bd729f9d67aa9a303d8925bb8c4f06af25f407d1 upstream. The syzbot fuzzing project found a use-after-free bug in the USB core. The bug was caused by usbfs not unbinding from an interface when the USB device file was closed, which led another process to attempt the unbind later on, after the private data structure had been deallocated. The reason usbfs did not unbind the interface at the appropriate time was because it thought the interface had never been claimed in the first place. This was caused by the fact that usb_driver_claim_interface() does not clean up properly when device_bind_driver() returns an error. Although the error code gets passed back to the caller, the iface->dev.driver pointer remains set and iface->condition remains equal to USB_INTERFACE_BOUND. This patch adds proper error handling to usb_driver_claim_interface(). Signed-off-by: Alan Stern Reported-by: syzbot+f84aa7209ccec829536f@syzkaller.appspotmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 902f5ab16eaf38db4fc5efa5c269ec9a9e895126 Author: Alan Stern Date: Mon Sep 10 13:58:51 2018 -0400 USB: remove LPM management from usb_driver_claim_interface() commit c183813fcee44a249339b7c46e1ad271ca1870aa upstream. usb_driver_claim_interface() disables and re-enables Link Power Management, but it shouldn't do either one, for the reasons listed below. This patch removes the two LPM-related function calls from the routine. The reason for disabling LPM in the analogous function usb_probe_interface() is so that drivers won't have to deal with unwanted LPM transitions in their probe routine. But usb_driver_claim_interface() doesn't call the driver's probe routine (or any other callbacks), so that reason doesn't apply here. Furthermore, no driver other than usbfs will ever call usb_driver_claim_interface() unless it is already bound to another interface in the same device, which means disabling LPM here would be redundant. usbfs doesn't interact with LPM at all. Lastly, the error return from usb_unlocked_disable_lpm() isn't handled properly; the code doesn't clean up its earlier actions before returning. Signed-off-by: Alan Stern Fixes: 8306095fd2c1 ("USB: Disable USB 3.0 LPM in critical sections.") Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit df1de074c4ebdd3e730f9507c046b1f760577824 Author: Alan Stern Date: Fri Apr 29 15:25:17 2016 -0400 USB: leave LPM alone if possible when binding/unbinding interface drivers commit 6fb650d43da3e7054984dc548eaa88765a94d49f upstream. When a USB driver is bound to an interface (either through probing or by claiming it) or is unbound from an interface, the USB core always disables Link Power Management during the transition and then re-enables it afterward. The reason is because the driver might want to prevent hub-initiated link power transitions, in which case the HCD would have to recalculate the various LPM parameters. This recalculation takes place when LPM is re-enabled and the new parameters are sent to the device and its parent hub. However, if the driver does not want to prevent hub-initiated link power transitions then none of this work is necessary. The parameters don't need to be recalculated, and LPM doesn't need to be disabled and re-enabled. It turns out that disabling and enabling LPM can be time-consuming, enough so that it interferes with user programs that want to claim and release interfaces rapidly via usbfs. Since the usbfs kernel driver doesn't set the disable_hub_initiated_lpm flag, we can speed things up and get the user programs to work by leaving LPM alone whenever the flag isn't set. And while we're improving the way disable_hub_initiated_lpm gets used, let's also fix its kerneldoc. Signed-off-by: Alan Stern Tested-by: Matthew Giassa CC: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 4e4da49c0d312afec7247367a354734ccf79fcec Author: Oliver Neukum Date: Wed Sep 5 12:07:03 2018 +0200 USB: usbdevfs: restore warning for nonsensical flags commit 81e0403b26d94360abd1f6a57311337973bc82cd upstream. If we filter flags before they reach the core we need to generate our own warnings. Signed-off-by: Oliver Neukum Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow") Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 9f6f5880a7e3e7ec54d4acad0947fcfc8652a5c2 Author: Oliver Neukum Date: Wed Sep 5 12:07:02 2018 +0200 USB: usbdevfs: sanitize flags more commit 7a68d9fb851012829c29e770621905529bd9490b upstream. Requesting a ZERO_PACKET or not is sensible only for output. In the input direction the device decides. Likewise accepting short packets makes sense only for input. This allows operation with panic_on_warn without opening up a local DOS. Signed-off-by: Oliver Neukum Reported-by: syzbot+843efa30c8821bd69f53@syzkaller.appspotmail.com Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow") Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 07259ac76d2876a26d7223b825fb0cec403932b8 Author: Paolo Abeni Date: Wed Sep 19 15:02:07 2018 +0200 ip6_tunnel: be careful when accessing the inner header commit 76c0ddd8c3a683f6e2c6e60e11dc1a1558caf4bc upstream. the ip6 tunnel xmit ndo assumes that the processed skb always contains an ip[v6] header, but syzbot has found a way to send frames that fall short of this assumption, leading to the following splat: BUG: KMSAN: uninit-value in ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307 [inline] BUG: KMSAN: uninit-value in ip6_tnl_start_xmit+0x7d2/0x1ef0 net/ipv6/ip6_tunnel.c:1390 CPU: 0 PID: 4504 Comm: syz-executor558 Not tainted 4.16.0+ #87 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x185/0x1d0 lib/dump_stack.c:53 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683 ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307 [inline] ip6_tnl_start_xmit+0x7d2/0x1ef0 net/ipv6/ip6_tunnel.c:1390 __netdev_start_xmit include/linux/netdevice.h:4066 [inline] netdev_start_xmit include/linux/netdevice.h:4075 [inline] xmit_one net/core/dev.c:3026 [inline] dev_hard_start_xmit+0x5f1/0xc70 net/core/dev.c:3042 __dev_queue_xmit+0x27ee/0x3520 net/core/dev.c:3557 dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590 packet_snd net/packet/af_packet.c:2944 [inline] packet_sendmsg+0x7c70/0x8a30 net/packet/af_packet.c:2969 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg net/socket.c:640 [inline] ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046 __sys_sendmmsg+0x42d/0x800 net/socket.c:2136 SYSC_sendmmsg+0xc4/0x110 net/socket.c:2167 SyS_sendmmsg+0x63/0x90 net/socket.c:2162 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x441819 RSP: 002b:00007ffe58ee8268 EFLAGS: 00000213 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441819 RDX: 0000000000000002 RSI: 0000000020000100 RDI: 0000000000000003 RBP: 00000000006cd018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000402510 R13: 00000000004025a0 R14: 0000000000000000 R15: 0000000000000000 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline] kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314 kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2737 [inline] __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369 __kmalloc_reserve net/core/skbuff.c:138 [inline] __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206 alloc_skb include/linux/skbuff.h:984 [inline] alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234 sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085 packet_alloc_skb net/packet/af_packet.c:2803 [inline] packet_snd net/packet/af_packet.c:2894 [inline] packet_sendmsg+0x6454/0x8a30 net/packet/af_packet.c:2969 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg net/socket.c:640 [inline] ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046 __sys_sendmmsg+0x42d/0x800 net/socket.c:2136 SYSC_sendmmsg+0xc4/0x110 net/socket.c:2167 SyS_sendmmsg+0x63/0x90 net/socket.c:2162 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 This change addresses the issue adding the needed check before accessing the inner header. The ipv4 side of the issue is apparently there since the ipv4 over ipv6 initial support, and the ipv6 side predates git history. Fixes: c4d3efafcc93 ("[IPV6] IP6TUNNEL: Add support to IPv4 over IPv6 tunnel.") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+3fde91d4d394747d6db4@syzkaller.appspotmail.com Tested-by: Alexander Potapenko Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 035082475c0b8ff52e06fca7757f80c4a888bfa5 Author: Dan Carpenter Date: Wed Sep 19 13:35:53 2018 +0300 x86/paravirt: Fix some warning messages commit 571d0563c8881595f4ab027aef9ed1c55e3e7b7c upstream. The first argument to WARN_ONCE() is a condition. Fixes: 5800dc5c19f3 ("x86/paravirt: Fix spectre-v2 mitigations for paravirt guests") Signed-off-by: Dan Carpenter Signed-off-by: Thomas Gleixner Reviewed-by: Juergen Gross Cc: Peter Zijlstra Cc: Alok Kataria Cc: "H. Peter Anvin" Cc: virtualization@lists.linux-foundation.org Cc: kernel-janitors@vger.kernel.org Link: https://lkml.kernel.org/r/20180919103553.GD9238@mwanda Signed-off-by: Ben Hutchings commit 5fa44fe0e7c7399ab6ba25031027e0f6679a7474 Author: Thomas Petazzoni Date: Thu Sep 13 16:48:08 2018 +0100 ARM: 8799/1: mm: fix pci_ioremap_io() offset check commit 3a58ac65e2d7969bcdf1b6acb70fa4d12a88e53e upstream. IO_SPACE_LIMIT is the ending address of the PCI IO space, i.e something like 0xfffff (and not 0x100000). Therefore, when offset = 0xf0000 is passed as argument, this function fails even though the offset + SZ_64K fits below the IO_SPACE_LIMIT. This makes the last chunk of 64 KB of the I/O space not usable as it cannot be mapped. This patch fixes that by substracing 1 to offset + SZ_64K, so that we compare the addrss of the last byte of the I/O space against IO_SPACE_LIMIT instead of the address of the first byte of what is after the I/O space. Fixes: c2794437091a4 ("ARM: Add fixed PCI i/o mapping") Signed-off-by: Thomas Petazzoni Acked-by: Nicolas Pitre Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit c56e562cdc9372d07a42eb40361b5ad205a969bd Author: Aaron Ma Date: Tue Sep 18 09:32:22 2018 -0700 Input: elantech - enable middle button of touchpad on ThinkPad P72 commit 91a97507323e1ad4bfc10f4a5922e67cdaf8b3cd upstream. Adding 2 new touchpad IDs to support middle button support. Signed-off-by: Aaron Ma Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 458697ab18b512445ac273ce68a9f8fd623fc0a3 Author: Gustavo A. R. Silva Date: Thu Aug 16 15:30:38 2018 -0500 tty: vt_ioctl: fix potential Spectre v1 commit e97267cb4d1ee01ca0929638ec0fcbb0904f903d upstream. vsa.console is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue 'vc_cons' [r] Fix this by sanitizing vsa.console before using it to index vc_cons Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Reviewed-by: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 85b349356657e7a306e34a40da01257a18c11d45 Author: Christophe Leroy Date: Fri Sep 14 10:32:50 2018 +0000 serial: cpm_uart: return immediately from console poll commit be28c1e3ca29887e207f0cbcd294cefe5074bab6 upstream. kgdb expects poll function to return immediately and returning NO_POLL_CHAR when no character is available. Fixes: f5316b4aea024 ("kgdb,8250,pl011: Return immediately from console poll") Cc: Jason Wessel Signed-off-by: Christophe Leroy Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit ae000eff9069efc2cc848b3e794d01496f81fdb2 Author: Vaibhav Nagarnaik Date: Fri Sep 7 15:31:29 2018 -0700 ring-buffer: Allow for rescheduling when removing pages commit 83f365554e47997ec68dc4eca3f5dce525cd15c3 upstream. When reducing ring buffer size, pages are removed by scheduling a work item on each CPU for the corresponding CPU ring buffer. After the pages are removed from ring buffer linked list, the pages are free()d in a tight loop. The loop does not give up CPU until all pages are removed. In a worst case behavior, when lot of pages are to be freed, it can cause system stall. After the pages are removed from the list, the free() can happen while the work is rescheduled. Call cond_resched() in the loop to prevent the system hangup. Link: http://lkml.kernel.org/r/20180907223129.71994-1-vnagarnaik@google.com Fixes: 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic") Reported-by: Jason Behmer Signed-off-by: Vaibhav Nagarnaik Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Ben Hutchings commit 3ab9d38741264d8d1e625385979b11faf5bf244a Author: Eric Dumazet Date: Fri Sep 14 12:02:31 2018 -0700 ipv6: fix possible use-after-free in ip6_xmit() commit bbd6528d28c1b8e80832b3b018ec402b6f5c3215 upstream. In the unlikely case ip6_xmit() has to call skb_realloc_headroom(), we need to call skb_set_owner_w() before consuming original skb, otherwise we risk a use-after-free. Bring IPv6 in line with what we do in IPv4 to fix this. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit fe902d312e43f1e386c00d439a67ec4e8786a261 Author: Guillaume Nault Date: Fri Sep 14 16:28:05 2018 +0200 pppoe: fix reception of frames with no mac header commit 8540827ebac6b654ab2f69c8fbce9e4fbd6304a0 upstream. pppoe_rcv() needs to look back at the Ethernet header in order to lookup the PPPoE session. Therefore we need to ensure that the mac header is big enough to contain an Ethernet header. Otherwise eth_hdr(skb)->h_source might access invalid data. ================================================================== BUG: KMSAN: uninit-value in __get_item drivers/net/ppp/pppoe.c:172 [inline] BUG: KMSAN: uninit-value in get_item drivers/net/ppp/pppoe.c:236 [inline] BUG: KMSAN: uninit-value in pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450 CPU: 0 PID: 4543 Comm: syz-executor355 Not tainted 4.16.0+ #87 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x185/0x1d0 lib/dump_stack.c:53 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683 __get_item drivers/net/ppp/pppoe.c:172 [inline] get_item drivers/net/ppp/pppoe.c:236 [inline] pppoe_rcv+0xcef/0x10e0 drivers/net/ppp/pppoe.c:450 __netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4562 __netif_receive_skb net/core/dev.c:4627 [inline] netif_receive_skb_internal+0x49d/0x630 net/core/dev.c:4701 netif_receive_skb+0x230/0x240 net/core/dev.c:4725 tun_rx_batched drivers/net/tun.c:1555 [inline] tun_get_user+0x740f/0x7c60 drivers/net/tun.c:1962 tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990 call_write_iter include/linux/fs.h:1782 [inline] new_sync_write fs/read_write.c:469 [inline] __vfs_write+0x7fb/0x9f0 fs/read_write.c:482 vfs_write+0x463/0x8d0 fs/read_write.c:544 SYSC_write+0x172/0x360 fs/read_write.c:589 SyS_write+0x55/0x80 fs/read_write.c:581 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x4447c9 RSP: 002b:00007fff64c8fc28 EFLAGS: 00000297 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004447c9 RDX: 000000000000fd87 RSI: 0000000020000600 RDI: 0000000000000004 RBP: 00000000006cf018 R08: 00007fff64c8fda8 R09: 00007fff00006bda R10: 0000000000005fe7 R11: 0000000000000297 R12: 00000000004020d0 R13: 0000000000402160 R14: 0000000000000000 R15: 0000000000000000 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline] kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314 kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2737 [inline] __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369 __kmalloc_reserve net/core/skbuff.c:138 [inline] __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206 alloc_skb include/linux/skbuff.h:984 [inline] alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234 sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085 tun_alloc_skb drivers/net/tun.c:1532 [inline] tun_get_user+0x2242/0x7c60 drivers/net/tun.c:1829 tun_chr_write_iter+0x1d4/0x330 drivers/net/tun.c:1990 call_write_iter include/linux/fs.h:1782 [inline] new_sync_write fs/read_write.c:469 [inline] __vfs_write+0x7fb/0x9f0 fs/read_write.c:482 vfs_write+0x463/0x8d0 fs/read_write.c:544 SYSC_write+0x172/0x360 fs/read_write.c:589 SyS_write+0x55/0x80 fs/read_write.c:581 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 ================================================================== Fixes: 224cf5ad14c0 ("ppp: Move the PPP drivers") Reported-by: syzbot+f5f6080811c849739212@syzkaller.appspotmail.com Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit fb896edd873d30f796ebbf7a308d24ad117c0b14 Author: Daniel Borkmann Date: Sun Jul 2 02:13:25 2017 +0200 bpf, net: add skb_mac_header_len helper commit 0daf4349406074fc03e4889ba5e97e6fb5311bab upstream. Add a small skb_mac_header_len() helper similarly as the skb_network_header_len() we have and replace open coded places in BPF's bpf_skb_change_proto() helper. Will also be used in upcoming work. Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller [bwh: Backported to 3.16: drop changes in bpf] Signed-off-by: Ben Hutchings commit b85dd158cb0eb52fad5f1a8b982a416c3493f837 Author: Li Dongyang Date: Sat Sep 15 17:11:25 2018 -0400 ext4: don't mark mmp buffer head dirty commit fe18d649891d813964d3aaeebad873f281627fbc upstream. Marking mmp bh dirty before writing it will make writeback pick up mmp block later and submit a write, we don't want the duplicate write as kmmpd thread should have full control of reading and writing the mmp block. Another reason is we will also have random I/O error on the writeback request when blk integrity is enabled, because kmmpd could modify the content of the mmp block(e.g. setting new seq and time) while the mmp block is under I/O requested by writeback. Signed-off-by: Li Dongyang Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Signed-off-by: Ben Hutchings commit 9095f19baae92afb978f8df77d19280fe291b337 Author: Bin Yang Date: Wed Sep 12 03:36:34 2018 +0000 pstore: Fix incorrect persistent ram buffer mapping commit 831b624df1b420c8f9281ed1307a8db23afb72df upstream. persistent_ram_vmap() returns the page start vaddr. persistent_ram_iomap() supports non-page-aligned mapping. persistent_ram_buffer_map() always adds offset-in-page to the vaddr returned from these two functions, which causes incorrect mapping of non-page-aligned persistent ram buffer. By default ftrace_size is 4096 and max_ftrace_cnt is nr_cpu_ids. Without this patch, the zone_sz in ramoops_init_przs() is 4096/nr_cpu_ids which might not be page aligned. If the offset-in-page > 2048, the vaddr will be in next page. If the next page is not mapped, it will cause kernel panic: [ 0.074231] BUG: unable to handle kernel paging request at ffffa19e0081b000 ... [ 0.075000] RIP: 0010:persistent_ram_new+0x1f8/0x39f ... [ 0.075000] Call Trace: [ 0.075000] ramoops_init_przs.part.10.constprop.15+0x105/0x260 [ 0.075000] ramoops_probe+0x232/0x3a0 [ 0.075000] platform_drv_probe+0x3e/0xa0 [ 0.075000] driver_probe_device+0x2cd/0x400 [ 0.075000] __driver_attach+0xe4/0x110 [ 0.075000] ? driver_probe_device+0x400/0x400 [ 0.075000] bus_for_each_dev+0x70/0xa0 [ 0.075000] driver_attach+0x1e/0x20 [ 0.075000] bus_add_driver+0x159/0x230 [ 0.075000] ? do_early_param+0x95/0x95 [ 0.075000] driver_register+0x70/0xc0 [ 0.075000] ? init_pstore_fs+0x4d/0x4d [ 0.075000] __platform_driver_register+0x36/0x40 [ 0.075000] ramoops_init+0x12f/0x131 [ 0.075000] do_one_initcall+0x4d/0x12c [ 0.075000] ? do_early_param+0x95/0x95 [ 0.075000] kernel_init_freeable+0x19b/0x222 [ 0.075000] ? rest_init+0xbb/0xbb [ 0.075000] kernel_init+0xe/0xfc [ 0.075000] ret_from_fork+0x3a/0x50 Signed-off-by: Bin Yang [kees: add comments describing the mapping differences, updated commit log] Fixes: 24c3d2f342ed ("staging: android: persistent_ram: Make it possible to use memory outside of bootmem") Signed-off-by: Kees Cook Signed-off-by: Ben Hutchings commit 5d05a482d46d9f457c0dbe24eef7edfeb3540c3f Author: Dan Carpenter Date: Mon Sep 10 14:12:07 2018 +0300 cifs: integer overflow in in SMB2_ioctl() commit 2d204ee9d671327915260071c19350d84344e096 upstream. The "le32_to_cpu(rsp->OutputOffset) + *plen" addition can overflow and wrap around to a smaller value which looks like it would lead to an information leak. Fixes: 4a72dafa19ba ("SMB2 FSCTL and IOCTL worker function") Signed-off-by: Dan Carpenter Signed-off-by: Steve French Reviewed-by: Aurelien Aptel [bwh: Backported to 3.16: Use get_rfc1002_length(rsp) instead of rsp->iov.iov_len] Signed-off-by: Ben Hutchings commit e09fa2de99ee71f92bd4228da2c03c52e125224b Author: Dan Carpenter Date: Thu Sep 6 12:48:22 2018 +0300 CIFS: fix wrapping bugs in num_entries() commit 56446f218af1133c802dad8e9e116f07f381846c upstream. The problem is that "entryptr + next_offset" and "entryptr + len + size" can wrap. I ended up changing the type of "entryptr" because it makes the math easier when we don't have to do so much casting. Signed-off-by: Dan Carpenter Signed-off-by: Steve French Reviewed-by: Aurelien Aptel Reviewed-by: Pavel Shilovsky Signed-off-by: Ben Hutchings commit 28560a6f2a768c7374e5cc13ebdc8003ba32b391 Author: Dan Carpenter Date: Thu Sep 6 12:47:51 2018 +0300 cifs: prevent integer overflow in nxt_dir_entry() commit 8ad8aa353524d89fa2e09522f3078166ff78ec42 upstream. The "old_entry + le32_to_cpu(pDirInfo->NextEntryOffset)" can wrap around so I have added a check for integer overflow. Reported-by: Dr Silvio Cesare of InfoSect Reviewed-by: Ronnie Sahlberg Reviewed-by: Aurelien Aptel Signed-off-by: Dan Carpenter Signed-off-by: Steve French Signed-off-by: Ben Hutchings commit 71ad1a59d7cc79f9fa5faddd78e7934799f20243 Author: Gustavo A. R. Silva Date: Wed Aug 15 10:50:41 2018 -0500 misc: hmc6352: fix potential Spectre v1 commit de916736aaaadddbd6061472969f667b14204aa9 upstream. val is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/misc/hmc6352.c:54 compass_store() warn: potential spectre issue 'map' [r] Fix this by sanitizing val before using it to index map Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit f379eed7ab1e29c9d434e95aae1ddb718f3dd4c9 Author: K. Y. Srinivasan Date: Fri Aug 10 23:06:07 2018 +0000 Tools: hv: Fix a bug in the key delete code commit 86503bd35dec0ce363e9fdbf5299927422ed3899 upstream. Fix a bug in the key delete code - the num_records range from 0 to num_records-1. Signed-off-by: K. Y. Srinivasan Reported-by: David Binderman Reviewed-by: Michael Kelley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e9eaa9870e763e81e83a1f970b27512311b15cff Author: Boris Ostrovsky Date: Tue Sep 11 15:55:38 2018 -0400 x86/EISA: Don't probe EISA bus for Xen PV guests commit 6a92b11169a65b3f8cc512c75a252cbd0d096ba0 upstream. For unprivileged Xen PV guests this is normal memory and ioremap will not be able to properly map it. While at it, since ioremap may return NULL, add a test for pointer's validity. Reported-by: Andy Smith Signed-off-by: Boris Ostrovsky Signed-off-by: Thomas Gleixner Cc: hpa@zytor.com Cc: xen-devel@lists.xenproject.org Cc: jgross@suse.com Link: https://lkml.kernel.org/r/20180911195538.23289-1-boris.ostrovsky@oracle.com Signed-off-by: Ben Hutchings commit 5aa78e7d008c6619384172da4903a27fc52ed56c Author: Thomas Gleixner Date: Mon Aug 28 08:47:20 2017 +0200 x86/boot: Move EISA setup to a separate file commit f7eaf6e00fd581043bb540dfe865f1d81769b189 upstream. EISA has absolutely nothing to do with traps, so move it out of traps.c into its own eisa.c file. Furthermore, the EISA bus detection does not need to run during very early boot, it's good enough to run it before the EISA bus and drivers are initialized. I.e. instead of calling it from the very early trap_init() code, make it a subsys_initcall(). Signed-off-by: Thomas Gleixner Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Steven Rostedt Link: http://lkml.kernel.org/r/20170828064956.515322409@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit d87fd18dda5e775680f91b87fa36d5da7ebf1038 Author: Mario Limonciello Date: Mon Sep 10 13:01:53 2018 -0500 platform/x86: alienware-wmi: Correct a memory leak commit ff0e9f26288d2daee4950f42b37a3d3d30d36ec1 upstream. An ACPI buffer that was allocated was not being freed after use. Signed-off-by: Mario Limonciello Signed-off-by: Darren Hart (VMware) Signed-off-by: Ben Hutchings commit 889770ece786a8e879588937f257d61851330024 Author: Emil Lundmark Date: Mon May 28 16:27:11 2018 +0200 drm: udl: Destroy framebuffer only if it was initialized commit fcb74da1eb8edd3a4ef9b9724f88ed709d684227 upstream. This fixes a NULL pointer dereference that can happen if the UDL driver is unloaded before the framebuffer is initialized. This can happen e.g. if the USB device is unplugged right after it was plugged in. As explained by Stéphane Marchesin: It happens when fbdev is disabled (which is the case for Chrome OS). Even though intialization of the fbdev part is optional (it's done in udlfb_create which is the callback for fb_probe()), the teardown isn't optional (udl_driver_unload -> udl_fbdev_cleanup -> udl_fbdev_destroy). Note that udl_fbdev_cleanup *tries* to be conditional (you can see it does if (!udl->fbdev)) but that doesn't work, because udl->fbdev is always set during udl_fbdev_init. Suggested-by: Sean Paul Reviewed-by: Sean Paul Acked-by: Daniel Vetter Signed-off-by: Emil Lundmark Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20180528142711.142466-1-lndmrk@chromium.org Signed-off-by: Sean Paul [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit b35cff2b7d2e407b7e61545ada36636d17f8d69d Author: Imre Deak Date: Wed Sep 5 13:00:05 2018 +0300 drm/i915/bdw: Increase IPS disable timeout to 100ms commit 92a6803149465e2339f8f7f8f6415d75be80073d upstream. During IPS disabling the current 42ms timeout value leads to occasional timeouts, increase it to 100ms which seems to get rid of the problem. References: https://bugs.freedesktop.org/show_bug.cgi?id=107494 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107562 Reported-by: Diego Viola Tested-by: Diego Viola Cc: Diego Viola Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180905100005.7663-1-imre.deak@intel.com (cherry picked from commit acb3ef0ee40ea657280a4a11d9f60eb2937c0dca) Signed-off-by: Rodrigo Vivi [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 65f6e78bc86f37ee5ce4c83681ab43f0caf56514 Author: Willy Tarreau Date: Sat Sep 8 08:12:21 2018 +0200 ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO commit 49434c6c575d2008c0abbc93e615019f39e01252 upstream. snd_emu10k1_fx8010_ioctl(SNDRV_EMU10K1_IOCTL_INFO) allocates memory using kmalloc() and partially fills it by calling snd_emu10k1_fx8010_info() before returning the resulting structure to userspace, leaving uninitialized holes. Let's just use kzalloc() here. BugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html Signed-off-by: Willy Tarreau Cc: Jann Horn Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 87de6c966b4ed3f08ffa05255a7f75f53357d68e Author: Takashi Sakamoto Date: Sun Sep 9 22:25:12 2018 +0900 ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping commit 493626f2d87a74e6dbea1686499ed6e7e600484e upstream. When executing 'fw_run_transaction()' with 'TCODE_WRITE_BLOCK_REQUEST', an address of 'payload' argument is used for streaming DMA mapping by 'firewire_ohci' module if 'size' argument is larger than 8 byte. Although in this case the address should not be on kernel stack, current implementation of ALSA bebob driver uses data in kernel stack for a cue to boot M-Audio devices. This often brings unexpected result, especially for a case of CONFIG_VMAP_STACK=y. This commit fixes the bug. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=201021 Reference: https://forum.manjaro.org/t/firewire-m-audio-410-driver-wont-load-firmware/51165 Fixes: a2b2a7798fb6('ALSA: bebob: Send a cue to load firmware for M-Audio Firewire series') Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 1f07011afbf6893f803638b7bec319387b48ef80 Author: Nadav Amit Date: Sun Sep 2 11:14:50 2018 -0700 x86/mm: Use WRITE_ONCE() when setting PTEs commit 9bc4f28af75a91aea0ae383f50b0a430c4509303 upstream. When page-table entries are set, the compiler might optimize their assignment by using multiple instructions to set the PTE. This might turn into a security hazard if the user somehow manages to use the interim PTE. L1TF does not make our lives easier, making even an interim non-present PTE a security hazard. Using WRITE_ONCE() to set PTEs and friends should prevent this potential security hazard. I skimmed the differences in the binary with and without this patch. The differences are (obviously) greater when CONFIG_PARAVIRT=n as more code optimizations are possible. For better and worse, the impact on the binary with this patch is pretty small. Skimming the code did not cause anything to jump out as a security hazard, but it seems that at least move_soft_dirty_pte() caused set_pte_at() to use multiple writes. Signed-off-by: Nadav Amit Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: Dave Hansen Cc: Andi Kleen Cc: Josh Poimboeuf Cc: Michal Hocko Cc: Vlastimil Babka Cc: Sean Christopherson Cc: Andy Lutomirski Link: https://lkml.kernel.org/r/20180902181451.80520-1-namit@vmware.com [bwh: Backported to 3.16: - Use ACCESS_ONCE() instead of WRITE_ONCE() - Drop changes in pmdp_establish(), native_set_p4d(), pudp_set_access_flags()] Signed-off-by: Ben Hutchings commit ffe9e21d08f0f7cf1e072bea1f5c1c47fc26c511 Author: Guenter Roeck Date: Thu Sep 6 09:47:51 2018 -0700 hwmon: (nct6775) Fix access to fan pulse registers commit c793279c77035053e67937f5743c6ebfc303e7c5 upstream. Not all fans have a fan pulse register. This can result in reading beyond the end of REG_FAN_PULSES and FAN_PULSE_SHIFT arrays, and was reported by smatch as possible error. 1672 for (i = 0; i < ARRAY_SIZE(data->rpm); i++) { ^^^^^^^^^^^^^^^^^^^^^^^^ This is a 7 element array. ... 1685 data->fan_pulses[i] = 1686 (nct6775_read_value(data, data->REG_FAN_PULSES[i]) 1687 >> data->FAN_PULSE_SHIFT[i]) & 0x03; ^^^^^^^^^^^^^^^^^^^^^^^^ FAN_PULSE_SHIFT is either 5 or 6 elements. To fix the problem, we have to ensure that all REG_FAN_PULSES and FAN_PULSE_SHIFT have the appropriate length, and that REG_FAN_PULSES is only read if the register actually exists. Fixes: 6c009501ff200 ("hwmon: (nct6775) Add support for NCT6102D/6106D") Reported-by: Dan Carpenter Signed-off-by: Guenter Roeck [bwh: Backported to 3.16: - NCT6776_REG_FAN_PULSES covers only 3 fans - Adjust context] Signed-off-by: Ben Hutchings commit 0d6bea7ce853abe938599d6c66bd2d3b39f4f417 Author: Lyude Paul Date: Wed Aug 15 15:00:14 2018 -0400 drm/nouveau/drm/nouveau: Use pm_runtime_get_noresume() in connector_detect() commit 6833fb1ec120bf078e1a527c573a09d4de286224 upstream. It's true we can't resume the device from poll workers in nouveau_connector_detect(). We can however, prevent the autosuspend timer from elapsing immediately if it hasn't already without risking any sort of deadlock with the runtime suspend/resume operations. So do that instead of entirely avoiding grabbing a power reference. Signed-off-by: Lyude Paul Reviewed-by: Karol Herbst Acked-by: Daniel Vetter Cc: Lukas Wunner Signed-off-by: Ben Skeggs Signed-off-by: Ben Hutchings commit 014344d4fc3b4112d967bac3b1195ac4c08e29a0 Author: Parav Pandit Date: Thu Aug 30 08:35:19 2018 +0300 RDMA/cma: Protect cma dev list with lock commit 954a8e3aea87e896e320cf648c1a5bbe47de443e upstream. When AF_IB addresses are used during rdma_resolve_addr() a lock is not held. A cma device can get removed while list traversal is in progress which may lead to crash. ie CPU0 CPU1 ==== ==== rdma_resolve_addr() cma_resolve_ib_dev() list_for_each() cma_remove_one() cur_dev->device mutex_lock(&lock) list_del(); mutex_unlock(&lock); cma_process_remove(); Therefore, hold a lock while traversing the list which avoids such situation. Fixes: f17df3b0dede ("RDMA/cma: Add support for AF_IB to rdma_resolve_addr()") Signed-off-by: Parav Pandit Reviewed-by: Daniel Jurgens Signed-off-by: Leon Romanovsky Reviewed-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Ben Hutchings commit 181da6034fd98cce59918eda9ab1f5b53bdba8f8 Author: Shubhrajyoti Datta Date: Mon Sep 3 15:11:11 2018 +0530 i2c: xiic: Make the start and the byte count write atomic commit ae7304c3ea28a3ba47a7a8312c76c654ef24967e upstream. Disable interrupts while configuring the transfer and enable them back. We have below as the programming sequence 1. start and slave address 2. byte count and stop In some customer platform there was a lot of interrupts between 1 and 2 and after slave address (around 7 clock cyles) if 2 is not executed then the transaction is nacked. To fix this case make the 2 writes atomic. Signed-off-by: Shubhrajyoti Datta Signed-off-by: Michal Simek [wsa: added a newline for better readability] Signed-off-by: Wolfram Sang Signed-off-by: Ben Hutchings commit 7debb42d0cfeb5df47fd7b4504064215f4acb7d8 Author: Mikulas Patocka Date: Wed Sep 5 09:17:45 2018 -0400 dm: disable CRYPTO_TFM_REQ_MAY_SLEEP to fix a GFP_KERNEL recursion deadlock commit 432061b3da64e488be3403124a72a9250bbe96d4 upstream. There's a XFS on dm-crypt deadlock, recursing back to itself due to the crypto subsystems use of GFP_KERNEL, reported here: https://bugzilla.kernel.org/show_bug.cgi?id=200835 * dm-crypt calls crypt_convert in xts mode * init_crypt from xts.c calls kmalloc(GFP_KERNEL) * kmalloc(GFP_KERNEL) recurses into the XFS filesystem, the filesystem tries to submit some bios and wait for them, causing a deadlock Fix this by updating both the DM crypt and integrity targets to no longer use the CRYPTO_TFM_REQ_MAY_SLEEP flag, which will change the crypto allocations from GFP_KERNEL to GFP_ATOMIC, therefore they can't recurse into a filesystem. A GFP_ATOMIC allocation can fail, but init_crypt() in xts.c handles the allocation failure gracefully - it will fall back to preallocated buffer if the allocation fails. The crypto API maintainer says that the crypto API only needs to allocate memory when dealing with unaligned buffers and therefore turning CRYPTO_TFM_REQ_MAY_SLEEP off is safe (see this discussion: https://www.redhat.com/archives/dm-devel/2018-August/msg00195.html ) Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer [bwh: Backported to 3.16: - Drop change to crypt_alloc_req_aead() in dm-crypt - Drop changes to dm-integrity - Adjust context] Signed-off-by: Ben Hutchings commit 62c8a37974b504b33a733d908b067443f3b753f1 Author: Sven Eckelmann Date: Sun Aug 12 21:04:45 2018 +0200 batman-adv: Prevent duplicated tvlv handler commit ae3cdc97dc10c7a3b31f297dab429bfb774c9ccb upstream. The function batadv_tvlv_handler_register is responsible for adding new tvlv_handler to the handler_list. It first checks whether the entry already is in the list or not. If it is, then the creation of a new entry is aborted. But the lock for the list is only held when the list is really modified. This could lead to duplicated entries because another context could create an entry with the same key between the check and the list manipulation. The check and the manipulation of the list must therefore be in the same locked code section. Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit 365a0ea769fb125d2823a6360e8e41a861ce664b Author: Sven Eckelmann Date: Sun Aug 12 21:04:44 2018 +0200 batman-adv: Prevent duplicated global TT entry commit e7136e48ffdfb9f37b0820f619380485eb407361 upstream. The function batadv_tt_global_orig_entry_add is responsible for adding new tt_orig_list_entry to the orig_list. It first checks whether the entry already is in the list or not. If it is, then the creation of a new entry is aborted. But the lock for the list is only held when the list is really modified. This could lead to duplicated entries because another context could create an entry with the same key between the check and the list manipulation. The check and the manipulation of the list must therefore be in the same locked code section. Fixes: d657e621a0f5 ("batman-adv: add reference counting for type batadv_tt_orig_list_entry") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit becb91556abce1a0da13612e91f3c6bb90b5ce41 Author: Sven Eckelmann Date: Sun Aug 12 21:04:43 2018 +0200 batman-adv: Prevent duplicated softif_vlan entry commit 94cb82f594ed86be303398d6dfc7640a6f1d45d4 upstream. The function batadv_softif_vlan_get is responsible for adding new softif_vlan to the softif_vlan_list. It first checks whether the entry already is in the list or not. If it is, then the creation of a new entry is aborted. But the lock for the list is only held when the list is really modified. This could lead to duplicated entries because another context could create an entry with the same key between the check and the list manipulation. The check and the manipulation of the list must therefore be in the same locked code section. Fixes: 5d2c05b21337 ("batman-adv: add per VLAN interface attribute framework") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich [bwh: Backported to 3.16: - s/kref_get/atomic_inc/ - s/_put/_free_ref/] Signed-off-by: Ben Hutchings commit 6334ac59a83f30e40acc4096415b52ca795b6d0d Author: Sven Eckelmann Date: Fri Jul 15 17:39:29 2016 +0200 batman-adv: Place kref_get for softif_vlan near use commit df28ca6bb3282a4c8dc5b65f60b0136fc190ee52 upstream. It is hard to understand why the refcnt is increased when it isn't done near the actual place the new reference is used. So using kref_get right before the place which requires the reference and in the same function helps to avoid accidental problems caused by incorrect reference counting. Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Simon Wunderlich [bwh: Backported to 3.16: - s/kref_get/atomic_inc/ - s/_put/_free_ref/] Signed-off-by: Ben Hutchings commit d3eb8015ec4bd5d1afc01cabf9c0a72285173e21 Author: Jann Horn Date: Fri Aug 31 21:41:51 2018 +0200 x86/process: Don't mix user/kernel regs in 64bit __show_regs() commit 9fe6299dde587788f245e9f7a5a1b296fad4e8c7 upstream. When the kernel.print-fatal-signals sysctl has been enabled, a simple userspace crash will cause the kernel to write a crash dump that contains, among other things, the kernel gsbase into dmesg. As suggested by Andy, limit output to pt_regs, FS_BASE and KERNEL_GS_BASE in this case. This also moves the bitness-specific logic from show_regs() into process_{32,64}.c. Fixes: 45807a1df9f5 ("vdso: print fatal signals") Signed-off-by: Jann Horn Signed-off-by: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Greg Kroah-Hartman Link: https://lkml.kernel.org/r/20180831194151.123586-1-jannh@google.com [bwh: Backported to 3.16: - Keep using user_mode_vm() to in 32-bit show_regs() - Also update call to __show_regs() in kmemcheck - Don't add redundant rdmsrl()s in 64-bit __show_regs() - Adjust filenames, context] Signed-off-by: Ben Hutchings commit d62d5d3a06e3b2e80729613573552548e3f4f73f Author: Sven Eckelmann Date: Sun Aug 12 21:04:42 2018 +0200 batman-adv: Prevent duplicated nc_node entry commit fa122fec8640eb7186ce5a41b83a4c1744ceef8f upstream. The function batadv_nc_get_nc_node is responsible for adding new nc_nodes to the in_coding_list and out_coding_list. It first checks whether the entry already is in the list or not. If it is, then the creation of a new entry is aborted. But the lock for the list is only held when the list is really modified. This could lead to duplicated entries because another context could create an entry with the same key between the check and the list manipulation. The check and the manipulation of the list must therefore be in the same locked code section. Fixes: d56b1705e28c ("batman-adv: network coding - detect coding nodes and remove these after timeout") Signed-off-by: Sven Eckelmann Acked-by: Marek Lindner Signed-off-by: Simon Wunderlich [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 69165193ace2823e9bdca9b544e5fb8dbab27209 Author: Sven Eckelmann Date: Sat Mar 5 16:09:21 2016 +0100 batman-adv: Use kref_get for batadv_nc_get_nc_node commit 0de32ceee156787429035c974316f4e5098cf722 upstream. batadv_nc_get_nc_node requires that the caller already has a valid reference for orig_neigh_node. It is therefore not possible that it has an reference counter of 0 and was still given to this function The kref_get function instead WARNs (with debug information) when the reference counter would still be 0. This makes a bug in batman-adv better visible because kref_get_unless_zero would have ignored this problem. Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli [bwh: Backported to 3.16: Reference counts are not krefs here, so open- code the equivalent of kref_get()] Signed-off-by: Ben Hutchings commit d7514471eb4747ff411c9feca092f2fea119662c Author: Sven Eckelmann Date: Sun Aug 12 21:04:41 2018 +0200 batman-adv: Prevent duplicated gateway_node entry commit dff9bc42ab0b2d38c5e90ddd79b238fed5b4c7ad upstream. The function batadv_gw_node_add is responsible for adding new gw_node to the gateway_list. It is expecting that the caller already checked that there is not already an entry with the same key or not. But the lock for the list is only held when the list is really modified. This could lead to duplicated entries because another context could create an entry with the same key between the check and the list manipulation. The check and the manipulation of the list must therefore be in the same locked code section. Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Signed-off-by: Sven Eckelmann Acked-by: Marek Lindner Signed-off-by: Simon Wunderlich [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit c9b1bdb0526db891dc697da296bf172a8e070482 Author: Jean Delvare Date: Tue Sep 4 14:55:26 2018 +0200 ACPI / bus: Only call dmi_check_system() on X86 commit 5d128fbd8b20f8a48cb13c3eced789d1f9573ecd upstream. Calling dmi_check_system() early only works on X86. Other architectures initialize the DMI subsystem later so it's not ready yet when ACPI itself gets initialized. In the best case it results in a useless call to a function which will do nothing. But depending on the dmi implementation, it could also result in warnings. Best is to not call the function when it can't work and isn't needed. Additionally, if anyone ever needs to add non-x86 quirks, it would surprisingly not work, so document the limitation to avoid confusion. Signed-off-by: Jean Delvare Fixes: cce4f632db20 (ACPI: fix early DSDT dmi check warnings on ia64) Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 4e2504137525c6bc8af6055ec1eec42773549828 Author: Dan Carpenter Date: Wed Sep 5 10:46:27 2018 +0300 hwmon: (nct6775) Set weight source to zero correctly commit e3f3d7ab00cd459d0f7a839758a4542f4d4b8ac8 upstream. This is dead code because j can never be 1 at this point. We had intended to just test if the bit was clear. Fixes: bbd8decd4123 ("hwmon: (nct6775) Add support for weighted fan control") Signed-off-by: Dan Carpenter Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit 50081dd25ce34e401c1954d5afbfd922ecd01a40 Author: Aaron Knister Date: Fri Aug 24 08:42:46 2018 -0400 IB/ipoib: Avoid a race condition between start_xmit and cm_rep_handler commit 816e846c2eb9129a3e0afa5f920c8bbc71efecaa upstream. Inside of start_xmit() the call to check if the connection is up and the queueing of the packets for later transmission is not atomic which leaves a window where cm_rep_handler can run, set the connection up, dequeue pending packets and leave the subsequently queued packets by start_xmit() sitting on neigh->queue until they're dropped when the connection is torn down. This only applies to connected mode. These dropped packets can really upset TCP, for example, and cause multi-minute delays in transmission for open connections. Here's the code in start_xmit where we check to see if the connection is up: if (ipoib_cm_get(neigh)) { if (ipoib_cm_up(neigh)) { ipoib_cm_send(dev, skb, ipoib_cm_get(neigh)); goto unref; } } The race occurs if cm_rep_handler execution occurs after the above connection check (specifically if it gets to the point where it acquires priv->lock to dequeue pending skb's) but before the below code snippet in start_xmit where packets are queued. if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE) { push_pseudo_header(skb, phdr->hwaddr); spin_lock_irqsave(&priv->lock, flags); __skb_queue_tail(&neigh->queue, skb); spin_unlock_irqrestore(&priv->lock, flags); } else { ++dev->stats.tx_dropped; dev_kfree_skb_any(skb); } The patch acquires the netif tx lock in cm_rep_handler for the section where it sets the connection up and dequeues and retransmits deferred skb's. Fixes: 839fcaba355a ("IPoIB: Connected mode experimental support") Signed-off-by: Aaron Knister Tested-by: Ira Weiny Reviewed-by: Ira Weiny Signed-off-by: Jason Gunthorpe Signed-off-by: Ben Hutchings commit b8abd3f42fb9071a4d462338ac285962246a103d Author: Jia-Ju Bai Date: Sat Sep 1 16:25:08 2018 +0800 usb: misc: uss720: Fix two sleep-in-atomic-context bugs commit bc8acc214d3f1cafebcbcd101a695bbac716595d upstream. async_complete() in uss720.c is a completion handler function for the USB driver. So it should not sleep, but it is can sleep according to the function call paths (from bottom to top) in Linux-4.16. [FUNC] set_1284_register(GFP_KERNEL) drivers/usb/misc/uss720.c, 372: set_1284_register in parport_uss720_frob_control drivers/parport/ieee1284.c, 560: [FUNC_PTR]parport_uss720_frob_control in parport_ieee1284_ack_data_avail drivers/parport/ieee1284.c, 577: parport_ieee1284_ack_data_avail in parport_ieee1284_interrupt ./include/linux/parport.h, 474: parport_ieee1284_interrupt in parport_generic_irq drivers/usb/misc/uss720.c, 116: parport_generic_irq in async_complete [FUNC] get_1284_register(GFP_KERNEL) drivers/usb/misc/uss720.c, 382: get_1284_register in parport_uss720_read_status drivers/parport/ieee1284.c, 555: [FUNC_PTR]parport_uss720_read_status in parport_ieee1284_ack_data_avail drivers/parport/ieee1284.c, 577: parport_ieee1284_ack_data_avail in parport_ieee1284_interrupt ./include/linux/parport.h, 474: parport_ieee1284_interrupt in parport_generic_irq drivers/usb/misc/uss720.c, 116: parport_generic_irq in async_complete Note that [FUNC_PTR] means a function pointer call is used. To fix these bugs, GFP_KERNEL is replaced with GFP_ATOMIC. These bugs are found by my static analysis tool DSAC. Signed-off-by: Jia-Ju Bai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 0870d0175ae04600d20d76c92a68225ea5efcc51 Author: Jia-Ju Bai Date: Sat Sep 1 17:23:47 2018 +0800 usb: host: u132-hcd: Fix a sleep-in-atomic-context bug in u132_get_frame() commit 6d4f268fa132742fe96dad22307c68d237356d88 upstream. i_usX2Y_subs_startup in usbusx2yaudio.c is a completion handler function for the USB driver. So it should not sleep, but it is can sleep according to the function call paths (from bottom to top) in Linux-4.16. [FUNC] msleep drivers/usb/host/u132-hcd.c, 2558: msleep in u132_get_frame drivers/usb/core/hcd.c, 2231: [FUNC_PTR]u132_get_frame in usb_hcd_get_frame_number drivers/usb/core/usb.c, 822: usb_hcd_get_frame_number in usb_get_current_frame_number sound/usb/usx2y/usbusx2yaudio.c, 303: usb_get_current_frame_number in i_usX2Y_urb_complete sound/usb/usx2y/usbusx2yaudio.c, 366: i_usX2Y_urb_complete in i_usX2Y_subs_startup Note that [FUNC_PTR] means a function pointer call is used. To fix this bug, msleep() is replaced with mdelay(). This bug is found by my static analysis tool DSAC. Signed-off-by: Jia-Ju Bai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 01967b5ca351ed3e69c92a5a8f99f458d6463dbd Author: Mathias Nyman Date: Mon Sep 3 15:44:16 2018 +0300 usb: Avoid use-after-free by flushing endpoints early in usb_set_interface() commit f9a5b4f58b280c1d26255376713c132f93837621 upstream. The steps taken by usb core to set a new interface is very different from what is done on the xHC host side. xHC hardware will do everything in one go. One command is used to set up new endpoints, free old endpoints, check bandwidth, and run the new endpoints. All this is done by xHC when usb core asks the hcd to check for available bandwidth. At this point usb core has not yet flushed the old endpoints, which will cause use-after-free issues in xhci driver as queued URBs are cancelled on a re-allocated endpoint. To resolve this add a call to usb_disable_interface() which will flush the endpoints before calling usb_hcd_alloc_bandwidth() Additional checks in xhci driver will also be implemented to gracefully handle stale URB cancel on freed and re-allocated endpoints Reported-by: Sudip Mukherjee Signed-off-by: Mathias Nyman Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 865461b467529556e96be8c59f1c3acfc240d8b2 Author: Mathias Nyman Date: Tue Sep 4 17:35:16 2018 +0300 usb: Don't die twice if PCI xhci host is not responding in resume commit f3dc41c5d22b2ca14a0802a65d8cdc33a3882d4e upstream. usb_hc_died() should only be called once, and with the primary HCD as parameter. It will mark both primary and secondary hcd's dead. Remove the extra call to usb_cd_died with the shared hcd as parameter. Fixes: ff9d78b36f76 ("USB: Set usb_hcd->state and flags for shared roothubs") Signed-off-by: Mathias Nyman Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 47b41884a92e3fb3b305aa48b4f50dcbbfd02b19 Author: Geert Uytterhoeven Date: Wed Sep 5 10:49:39 2018 +0200 spi: rspi: Fix interrupted DMA transfers commit 8dbbaa47b96f6ea5f09f922b4effff3c505cd8cf upstream. When interrupted, wait_event_interruptible_timeout() returns -ERESTARTSYS, and the SPI transfer in progress will fail, as expected: m25p80 spi0.0: SPI transfer failed: -512 spi_master spi0: failed to transfer one message from queue However, as the underlying DMA transfers may not have completed, all subsequent SPI transfers may start to fail: spi_master spi0: receive timeout qspi_transfer_out_in() returned -110 m25p80 spi0.0: SPI transfer failed: -110 spi_master spi0: failed to transfer one message from queue Fix this by calling dmaengine_terminate_all() not only for timeouts, but also for errors. This can be reproduced on r8a7991/koelsch, using "hd /dev/mtd0" followed by CTRL-C. Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit 95289507dfa8cee4c493b68f391a39e1a0937d4c Author: Geert Uytterhoeven Date: Wed Aug 6 14:58:58 2014 +0200 spi: rspi: Fix leaking of unused DMA descriptors commit 3819bc8752367eae0d72fa1c473dc88ea45631a7 upstream. If dmaengine_prep_slave_sg() or dmaengine_submit() fail, we may leak unused DMA descriptors. As per Documentation/dmaengine.txt, once a DMA descriptor has been obtained, it must be submitted. Hence: - First prepare and submit all DMA descriptors, - Prepare the SPI controller for DMA, - Start DMA by calling dma_async_issue_pending(), - Make sure to call dmaengine_terminate_all() on all descriptors that haven't completed. Reported-by: Laurent Pinchart Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit 6c28d6e99d120c910660caa12e2ce4441d121631 Author: Geert Uytterhoeven Date: Wed Jul 9 12:26:22 2014 +0200 spi: rspi: Handle dmaengine_prep_slave_sg() failures gracefully commit 85912a88c1ebcad04a5cfec971771195ce8d6691 upstream. As typically a shmobile SoC has less DMA channels than devices that can use DMA, we may want to prioritize access to the DMA channels in the future. This means that dmaengine_prep_slave_sg() may start failing arbitrarily. Handle dmaengine_prep_slave_sg() failures gracefully by falling back to PIO. Signed-off-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit b5b3f9eea5a83c0b2f08ab73a0c51fb32f73f106 Author: Geert Uytterhoeven Date: Wed Sep 5 10:49:38 2018 +0200 spi: rspi: Fix invalid SPI use during system suspend commit c1ca59c22c56930b377a665fdd1b43351887830b upstream. If the SPI queue is running during system suspend, the system may lock up. Fix this by stopping/restarting the queue during system suspend/resume, by calling spi_master_suspend()/spi_master_resume() from the PM callbacks. In-kernel users will receive an -ESHUTDOWN error while system suspend/resume is in progress. Based on a patch for sh-msiof by Gaku Inami. Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 1f54f92f6c7a4e8489bcf7a643b567bc2f072f97 Author: Hiromitsu Yamasaki Date: Wed Sep 5 10:49:37 2018 +0200 spi: sh-msiof: Fix handling of write value for SISTR register commit 31a5fae4c5a009898da6d177901d5328051641ff upstream. This patch changes writing to the SISTR register according to the H/W user's manual. The TDREQ bit and RDREQ bits of SISTR are read-only, and must be written their initial values of zero. Signed-off-by: Hiromitsu Yamasaki [geert: reword] Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit 790fba1cb9433f84d589e59a67790058a3e2dcdd Author: Geert Uytterhoeven Date: Fri Jun 20 12:16:16 2014 +0200 spi: sh-msiof: Add more register documentation commit 2e2b36872d7b45b1f88a590283b14c67931b777f upstream. Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit b46122642b444438c2c20d5c568cbc1d94d58332 Author: Oliver Neukum Date: Thu Aug 9 16:03:37 2018 +0200 usb: uas: add support for more quirk flags commit 42d1c6d4a06a77b3ab206a919b9050c3080f3a71 upstream. The hope that UAS devices would be less broken than old style storage devices has turned out to be unfounded. Make UAS support more of the quirk flags of the old driver. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 6754ada5b8abf3d4a304fd9ddf4336682db85a4c Author: Tim Anderson Date: Thu Aug 9 14:55:34 2018 -0700 USB: Add quirk to support DJI CineSSD commit f45681f9becaa65111ed0a691ccf080a0cd5feb8 upstream. This device does not correctly handle the LPM operations. Also, the device cannot handle ATA pass-through commands and locks up when attempted while running in super speed. This patch adds the equivalent quirk logic as found in uas. Signed-off-by: Tim Anderson Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 42f9143e90ef58c4f273fe1b927971c7db366ed0 Author: Ben Hutchings Date: Wed Aug 15 21:44:25 2018 +0100 USB: yurex: Fix buffer over-read in yurex_write() commit 7e10f14ebface44a48275c8d6dc1caae3668d5a9 upstream. If the written data starts with a digit, yurex_write() tries to parse it as an integer using simple_strtoull(). This requires a null- terminator, and currently there's no guarantee that there is one. (The sample program at https://github.com/NeoCat/YUREX-driver-for-Linux/blob/master/sample/yurex_clock.pl writes an integer without a null terminator. It seems like it must have worked by chance!) Always add a null byte after the written data. Enlarge the buffer to allow for this. Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 8ed099f05d0da7a9919107294b33b125daf661d0 Author: Maxence Duprès Date: Wed Aug 8 23:56:33 2018 +0000 USB: add quirk for WORLDE Controller KS49 or Prodipe MIDI 49C USB controller commit 9b83a1c301ad6d24988a128c69b42cbaaf537d82 upstream. WORLDE Controller KS49 or Prodipe MIDI 49C USB controller cause a -EPROTO error, a communication restart and loop again. This issue has already been fixed for KS25. https://lore.kernel.org/patchwork/patch/753077/ I just add device 201 for KS49 in quirks.c to get it works. Signed-off-by: Laurent Roux Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit cd95f113f0f8ef793308ac14aab4c37002ca25c9 Author: Andrei Otcheretianski Date: Wed Sep 5 08:06:12 2018 +0300 cfg80211: reg: Init wiphy_idx in regulatory_hint_core() commit 24f33e64fcd0d50a4b1a8e5b41bd0257aa66b0e8 upstream. Core regulatory hints didn't set wiphy_idx to WIPHY_IDX_INVALID. Since the regulatory request is zeroed, wiphy_idx was always implicitly set to 0. This resulted in updating only phy #0. Fix that. Fixes: 806a9e39670b ("cfg80211: make regulatory_request use wiphy_idx instead of wiphy") Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho [add fixes tag] Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit 9e21f1cdfda9c84c825d03457543aa8e165c93ad Author: Steve Wise Date: Fri Aug 31 07:15:56 2018 -0700 iw_cxgb4: only allow 1 flush on user qps commit 308aa2b8f7b7db3332a7d41099fd37851fb793b2 upstream. Once the qp has been flushed, it cannot be flushed again. The user qp flush logic wasn't enforcing it however. The bug can cause touch-after-free crashes like: Unable to handle kernel paging request for data at address 0x000001ec Faulting instruction address: 0xc008000016069100 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c008000016069100] flush_qp+0x80/0x480 [iw_cxgb4] LR [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4] Call Trace: [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4] [c00800001606e868] c4iw_ib_modify_qp+0x118/0x200 [iw_cxgb4] [c0080000119eae80] ib_security_modify_qp+0xd0/0x3d0 [ib_core] [c0080000119c4e24] ib_modify_qp+0xc4/0x2c0 [ib_core] [c008000011df0284] iwcm_modify_qp_err+0x44/0x70 [iw_cm] [c008000011df0fec] destroy_cm_id+0xcc/0x370 [iw_cm] [c008000011ed4358] rdma_destroy_id+0x3c8/0x520 [rdma_cm] [c0080000134b0540] ucma_close+0x90/0x1b0 [rdma_ucm] [c000000000444da4] __fput+0xe4/0x2f0 So fix flush_qp() to only flush the wq once. Signed-off-by: Steve Wise Signed-off-by: Jason Gunthorpe [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit d2c9550c6146f61ea41cf5b2c31746c210db8153 Author: Steve Wise Date: Thu Nov 9 07:21:26 2017 -0800 iw_cxgb4: atomically flush the qp commit bc52e9ca74b9a395897bb640c6671b2cbf716032 upstream. __flush_qp() has a race condition where during the flush operation, the qp lock is released allowing another thread to possibly post a WR, which corrupts the queue state, possibly causing crashes. The lock was released to preserve the cq/qp locking hierarchy of cq first, then qp. However releasing the qp lock is not necessary; both RQ and SQ CQ locks can be acquired first, followed by the qp lock, and then the RQ and SQ flushing can be done w/o unlocking. Signed-off-by: Steve Wise Signed-off-by: Doug Ledford [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit bcc225d9ee295b25e814538aea0b96af8c1c642a Author: Steve Wise Date: Thu Jul 31 14:35:43 2014 -0500 RDMA/cxgb4: Only call CQ completion handler if it is armed commit 678ea9b5baab6800692b249bdba77c3c07261d61 upstream. The function __flush_qp() always calls the ULP's CQ completion handler functions even if the CQ was not armed. This can crash the system if the function pointer is NULL. The iSER ULP behaves this way: no completion handler and never arm the CQ for notification. So now we track whether the CQ is armed at flush time and only call the completion handlers if their CQs were armed. Also, if the RCQ and SCQ are the same CQ, the completion handler is getting called twice. It should only be called once after all SQ and RQ WRs are flushed from the QP. So rearrange the logic to fix this. Signed-off-by: Steve Wise Signed-off-by: Roland Dreier [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 8f7ee8803f2be5723af3ceb9a68e965fc859094f Author: Jann Horn Date: Mon Sep 3 18:54:14 2018 +0200 RDMA/ucma: check fd type in ucma_migrate_id() commit 0d23ba6034b9cf48b8918404367506da3e4b3ee5 upstream. The current code grabs the private_data of whatever file descriptor userspace has supplied and implicitly casts it to a `struct ucma_file *`, potentially causing a type confusion. This is probably fine in practice because the pointer is only used for comparisons, it is never actually dereferenced; and even in the comparisons, it is unlikely that a file from another filesystem would have a ->private_data pointer that happens to also be valid in this context. But ->private_data is not always guaranteed to be a valid pointer to an object owned by the file's filesystem; for example, some filesystems just cram numbers in there. Check the type of the supplied file descriptor to be safe, analogous to how other places in the kernel do it. Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()") Signed-off-by: Jann Horn Signed-off-by: Jason Gunthorpe Signed-off-by: Ben Hutchings commit b1713a2e188d7912c7b5543755b0479ad75c8e11 Author: Jens Axboe Date: Tue Sep 4 11:52:34 2018 -0600 nbd: don't allow invalid blocksize settings commit bc811f05d77f47059c197a98b6ad242eb03999cb upstream. syzbot reports a divide-by-zero off the NBD_SET_BLKSIZE ioctl. We need proper validation of the input here. Not just if it's zero, but also if the value is a power-of-2 and in a valid range. Add that. Reported-by: syzbot Reviewed-by: Josef Bacik Signed-off-by: Jens Axboe [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 299ee9f16058523f0ac3e0a13bb67828e78d541c Author: Theodore Ts'o Date: Mon Sep 3 22:25:01 2018 -0400 ext4: fix online resizing for bigalloc file systems with a 1k block size commit 5f8c10936fab2b69a487400f2872902e597dd320 upstream. An online resize of a file system with the bigalloc feature enabled and a 1k block size would be refused since ext4_resize_begin() did not understand s_first_data_block is 0 for all bigalloc file systems, even when the block size is 1k. Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit 5b000efb941e61b6cc54cf1574a4fa9cc5b5c423 Author: Theodore Ts'o Date: Fri Dec 26 23:58:21 2014 -0500 ext4: prevent online resize with backup superblock commit 011fa99404bea3f5d897c4983f6bd51170e3b18f upstream. Prevent BUG or corrupted file systems after the following: mkfs.ext4 /dev/vdc 100M mount -t ext4 -o sb=40961 /dev/vdc /vdc resize2fs /dev/vdc We previously prevented online resizing using the old resize ioctl. Move the code to ext4_resize_begin(), so the check applies for all of the resize ioctl's. Reported-by: Maxim Malkov Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit d0c816f97c7d1637f6ec77807738a1fd5910d38b Author: Theodore Ts'o Date: Mon Sep 3 22:19:43 2018 -0400 ext4: fix online resize's handling of a too-small final block group commit f0a459dec5495a3580f8d784555e6f8f3bf7f263 upstream. Avoid growing the file system to an extent so that the last block group is too small to hold all of the metadata that must be stored in the block group. This problem can be triggered with the following reproducer: umount /mnt mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \ -E resize=1073741824 /tmp/foo.img 128M mount /tmp/foo.img /mnt truncate --size 1708M /tmp/foo.img resize2fs /dev/loop0 295400 umount /mnt e2fsck -fy /tmp/foo.img Reported-by: Torsten Hilbrich Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit 18e4c58c26ef92cffa2d6bb2d2b2d1ebcbd7db2a Author: Marcel Ziswiler Date: Wed Aug 29 08:47:57 2018 +0200 spi: tegra20-slink: explicitly enable/disable clock commit 7001cab1dabc0b72b2b672ef58a90ab64f5e2343 upstream. Depending on the SPI instance one may get an interrupt storm upon requesting resp. interrupt unless the clock is explicitly enabled beforehand. This has been observed trying to bring up instance 4 on T20. Signed-off-by: Marcel Ziswiler Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit ecb727a93d5c2f57f533a7d926fe9ab7723f40d6 Author: Thadeu Lima de Souza Cascardo Date: Fri Aug 31 08:38:49 2018 -0300 xfrm6: call kfree_skb when skb is toobig commit 215ab0f021c9fea3c18b75e7d522400ee6a49990 upstream. After commit d6990976af7c5d8f55903bfb4289b6fb030bf754 ("vti6: fix PMTU caching and reporting on xmit"), some too big skbs might be potentially passed down to __xfrm6_output, causing it to fail to transmit but not free the skb, causing a leak of skb, and consequentially a leak of dst references. After running pmtu.sh, that shows as failure to unregister devices in a namespace: [ 311.397671] unregister_netdevice: waiting for veth_b to become free. Usage count = 1 The fix is to call kfree_skb in case of transmit failures. Fixes: dd767856a36e ("xfrm6: Don't call icmpv6_send on local error") Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Ben Hutchings commit 4d78d4cabd5817ffab51644024841e280eba6989 Author: Thomas Werschlein Date: Thu Aug 30 18:29:20 2018 +0200 cifs: connect to servername instead of IP for IPC$ share commit 395a2076b4064f97d3fce03af15210ff2a7bb7f9 upstream. This patch is required allows access to a Microsoft fileserver failover cluster behind a 1:1 NAT firewall. The change also provides stronger context for authentication and share connection (see MS-SMB2 3.3.5.7 and MS-SRVS 3.1.6.8) as noted by Tom Talpey, and addresses comments about the buffer size for the UNC made by Aurélien Aptel. Signed-off-by: Thomas Werschlein Signed-off-by: Steve French CC: Tom Talpey Reviewed-by: Aurelien Aptel [bwh: Backported to 3.16: The IPC$ path is generated in get_dfs_path() in a rather fragile way. Rather than replacing all instances of ses->serverName here, switch to using kasprintf() so the new code is close to that used upstream.] Signed-off-by: Ben Hutchings commit 01f87d04cbadd4c9f8fd813c929eab7d033ae174 Author: Steve French Date: Fri Aug 31 15:12:10 2018 -0500 smb3: check for and properly advertise directory lease support commit f801568332321e2b1e7a8bd26c3e4913a312a2ec upstream. Although servers will typically ignore unsupported features, we should advertise the support for directory leases (as Windows e.g. does) in the negotiate protocol capabilities we pass to the server, and should check for the server capability (CAP_DIRECTORY_LEASING) before sending a lease request for an open of a directory. This will prevent us from accidentally sending directory leases to SMB2.1 or SMB2 server for example. Signed-off-by: Steve French Reviewed-by: Ronnie Sahlberg [bwh: Backported to 3.16: - Drop changes to smb3any_values, smbdefault_values, smb311_values - Adjust context] Signed-off-by: Ben Hutchings commit 78bed89050efb915bb98bf4a1d89780527d3b8b7 Author: Steve French Date: Mon Aug 27 17:04:13 2018 -0500 SMB3: Backup intent flag missing for directory opens with backupuid mounts commit 5e19697b56a64004e2d0ff1bb952ea05493c088f upstream. When "backup intent" is requested on the mount (e.g. backupuid or backupgid mount options), the corresponding flag needs to be set on opens of directories (and files) but was missing in some places causing access denied trying to enumerate and backup servers. Fixes kernel bugzilla #200953 https://bugzilla.kernel.org/show_bug.cgi?id=200953 Reported-and-tested-by: Signed-off-by: Steve French Reviewed-by: Pavel Shilovsky [bwh: Backported to 3.16: drop changes in smb2_query_eas(), smb2_set_ea()] Signed-off-by: Ben Hutchings commit 4994f9ea360ba28f605f6442ce922ce687a8dd8c Author: Hangbin Liu Date: Wed Aug 29 18:06:10 2018 +0800 igmp: fix incorrect unsolicit report count after link down and up commit ff06525fcb8ae3c302ac1319bf6c07c026dea964 upstream. After link down and up, i.e. when call ip_mc_up(), we doesn't init im->unsolicit_count. So after igmp_timer_expire(), we will not start timer again and only send one unsolicit report at last. Fix it by initializing im->unsolicit_count in igmp_group_added(), so we can respect igmp robustness value. Fixes: 24803f38a5c0b ("igmp: do not remove igmp souce list info when set link down") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller [bwh: Backported to 3.16: - Keep using constant IGMP_Unsolicited_Report_Count - Adjust context] Signed-off-by: Ben Hutchings commit 79c9f22b1ee1b511b87d12e6c075fc58c388d8e9 Author: Hangbin Liu Date: Wed Aug 29 18:06:08 2018 +0800 igmp: fix incorrect unsolicit report count when join group commit 4fb7253e4f9a8f06a986a3b317e2f79d9b43d552 upstream. We should not start timer if im->unsolicit_count equal to 0 after decrease. Or we will send one more unsolicit report message. i.e. 3 instead of 2 by default. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit b1621dc93979be99046133a4b0415af0fe946b05 Author: Filippo Sironi Date: Tue Jul 31 17:29:30 2018 +0200 x86/microcode: Update the new microcode revision unconditionally commit 8da38ebaad23fe1b0c4a205438676f6356607cfc upstream. Handle the case where microcode gets loaded on the BSP's hyperthread sibling first and the boot_cpu_data's microcode revision doesn't get updated because of early exit due to the siblings sharing a microcode engine. For that, simply write the updated revision on all CPUs unconditionally. Signed-off-by: Filippo Sironi Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: prarit@redhat.com Link: http://lkml.kernel.org/r/1533050970-14385-1-git-send-email-sironi@amazon.de [bwh: Backported to 3.16: - Keep returning 0 on success - Adjust context] Signed-off-by: Ben Hutchings commit dbc0153d7ffaa978ff5ddaeaea7c605f8d3b5144 Author: Prarit Bhargava Date: Tue Jul 31 07:27:39 2018 -0400 x86/microcode: Make sure boot_cpu_data.microcode is up-to-date commit 370a132bb2227ff76278f98370e0e701d86ff752 upstream. When preparing an MCE record for logging, boot_cpu_data.microcode is used to read out the microcode revision on the box. However, on systems where late microcode update has happened, the microcode revision output in a MCE log record is wrong because boot_cpu_data.microcode is not updated when the microcode gets updated. But, the microcode revision saved in boot_cpu_data's microcode member should be kept up-to-date, regardless, for consistency. Make it so. Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check records") Signed-off-by: Prarit Bhargava Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: Tony Luck Cc: sironi@amazon.de Link: http://lkml.kernel.org/r/20180731112739.32338-1-prarit@redhat.com [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 1af1e58f16761e3eb7ac759db9ced4ebd6870b3d Author: Ashok Raj Date: Wed Feb 28 11:28:41 2018 +0100 x86/microcode/intel: Check microcode revision before updating sibling threads commit c182d2b7d0ca48e0d6ff16f7d883161238c447ed upstream. After updating microcode on one of the threads of a core, the other thread sibling automatically gets the update since the microcode resources on a hyperthreaded core are shared between the two threads. Check the microcode revision on the CPU before performing a microcode update and thus save us the WRMSR 0x79 because it is a particularly expensive operation. [ Borislav: Massage changelog and coding style. ] Signed-off-by: Ashok Raj Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Tested-by: Tom Lendacky Tested-by: Ashok Raj Cc: Arjan Van De Ven Link: http://lkml.kernel.org/r/1519352533-15992-2-git-send-email-ashok.raj@intel.com Link: https://lkml.kernel.org/r/20180228102846.13447-3-bp@alien8.de [bwh: Backported to 3.16: - s/mc->/mc_intel->/ - Return 0 in this case - Adjust filename, context] Signed-off-by: Ben Hutchings commit 8acfa7f8ccba01b93b11c8a20fee7dc19106b7a8 Author: Borislav Petkov Date: Mon Jan 9 12:41:45 2017 +0100 x86/microcode/intel: Add a helper which gives the microcode revision commit 4167709bbf826512a52ebd6aafda2be104adaec9 upstream. Since on Intel we're required to do CPUID(1) first, before reading the microcode revision MSR, let's add a special helper which does the required steps so that we don't forget to do them next time, when we want to read the microcode revision. Signed-off-by: Borislav Petkov Link: http://lkml.kernel.org/r/20170109114147.5082-4-bp@alien8.de Signed-off-by: Thomas Gleixner [bwh: Backported to 3.16: - Don't touch prev_rev variable in apply_microcode() - Keep using sync_core(), which will alway includes the necessary CPUID - Adjust filename, context] Signed-off-by: Ben Hutchings commit 55e74f447185409f25612a1add6a777e6a1a9740 Author: Corey Minyard Date: Thu Aug 23 15:22:35 2018 -0500 ipmi: Move BT capabilities detection to the detect call commit c86ba91be75702c013bbf7379542920b6920e98f upstream. The capabilities detection was being done as part of the normal state machine, but it was possible for it to be running while the upper layers of the IPMI driver were initializing the device, resulting in error and failure to initialize. Move the capabilities detection to the the detect function, so it's done before anything else runs on the device. This also simplifies the state machine and removes some code, as a bonus. Signed-off-by: Corey Minyard Reported-by: Andrew Banman Tested-by: Andrew Banman [bwh: Backported to 3.16: - struct si_sm_data doesn't include a dev pointer, so use pr_* functions for logging - Include for schedule_timeout_uninterruptible()] Signed-off-by: Ben Hutchings commit 760eb5ddc90daeb01515912caf386f3abb0085dc Author: Arunk Khandavalli Date: Thu Aug 30 00:40:16 2018 +0300 cfg80211: nl80211_update_ft_ies() to validate NL80211_ATTR_IE commit 4f0223bfe9c3e62d8f45a85f1ef1b18a8a263ef9 upstream. nl80211_update_ft_ies() tried to validate NL80211_ATTR_IE with is_valid_ie_attr() before dereferencing it, but that helper function returns true in case of NULL pointer (i.e., attribute not included). This can result to dereferencing a NULL pointer. Fix that by explicitly checking that NL80211_ATTR_IE is included. Fixes: 355199e02b83 ("cfg80211: Extend support for IEEE 802.11r Fast BSS Transition") Signed-off-by: Arunk Khandavalli Signed-off-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit 7c4feb3cd49f7fd1e8330a28f010610667f305f7 Author: Sabrina Dubroca Date: Tue Aug 28 13:40:52 2018 +0200 ipv6: fix cleanup ordering for pingv6 registration commit a03dc36bdca6b614651fedfcd8559cf914d2d21d upstream. Commit 6d0bfe226116 ("net: ipv6: Add IPv6 support to the ping socket.") contains an error in the cleanup path of inet6_init(): when proto_register(&pingv6_prot, 1) fails, we try to unregister &pingv6_prot. When rawv6_init() fails, we skip unregistering &pingv6_prot. Example of panic (triggered by faking a failure of proto_register(&pingv6_prot, 1)): general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI [...] RIP: 0010:__list_del_entry_valid+0x79/0x160 [...] Call Trace: proto_unregister+0xbb/0x550 ? trace_preempt_on+0x6f0/0x6f0 ? sock_no_shutdown+0x10/0x10 inet6_init+0x153/0x1b8 Fixes: 6d0bfe226116 ("net: ipv6: Add IPv6 support to the ping socket.") Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit ba3114ebb518e18e356151b75dbc591410c3fe27 Author: Alan Stern Date: Wed Aug 8 11:20:39 2018 -0400 USB: net2280: Fix erroneous synchronization change commit dec3c23c9aa1815f07d98ae0375b4cbc10971e13 upstream. Commit f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks") was based on a serious misunderstanding. It introduced regressions into both the dummy-hcd and net2280 drivers. The problem in dummy-hcd was fixed by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), but the problem in net2280 remains. Namely: the ->disconnect(), ->suspend(), ->resume(), and ->reset() callbacks must be invoked without the private lock held; otherwise a deadlock will occur when the callback routine tries to interact with the UDC driver. This patch largely is a reversion of the relevant parts of f16443a034c7. It also drops the private lock around the calls to ->suspend() and ->resume() (something the earlier patch forgot to do). This is safe from races with device interrupts because it occurs within the interrupt handler. Finally, the patch changes where the ->disconnect() callback is invoked when net2280_pullup() turns the pullup off. Rather than making the callback from within stop_activity() at a time when dropping the private lock could be unsafe, the callback is moved to a point after the lock has already been dropped. Signed-off-by: Alan Stern Fixes: f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks") Reported-by: D. Ziesche Tested-by: D. Ziesche Signed-off-by: Felipe Balbi [bwh: Backported to 3.16: - Drop inapplicable change to disconnection handling in handle_stat1_irqs() - Adjust filename, context] Signed-off-by: Ben Hutchings commit 8514f95218d69d0dd3e345cc910f9c89c5bfb2c3 Author: Mian Yousaf Kaukab Date: Sat May 16 22:33:39 2015 +0200 usb: gadget: net2280: fix pullup handling commit 11bece5e063ca567e631c6ea3b1611c10dbc3282 upstream. Gadget must be informed about disconnection when pullup is removed. Tested-by: Ricardo Ribalda Delgado Signed-off-by: Mian Yousaf Kaukab Signed-off-by: Felipe Balbi [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit 4723be7df6675e5ea4dd6637aedae29f36562116 Author: Felipe Balbi Date: Fri Oct 17 11:23:33 2014 -0500 usb: gadget: udc: net2280: do not rely on 'driver' argument commit bfd0ed576dbf9cc71af7dbe42841fc9246524961 upstream. future patches will remove the extra 'driver' argument to ->udc_stop(), in order to do that, we must make sure that our UDC does not rely on it first. Signed-off-by: Felipe Balbi [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit ea7a683de505165bec909660544534a376f4c677 Author: Theodore Ts'o Date: Mon Aug 27 09:22:45 2018 -0400 ext4: avoid divide by zero fault when deleting corrupted inline directories commit 4d982e25d0bdc83d8c64e66fdeca0b89240b3b85 upstream. A specially crafted file system can trick empty_inline_dir() into reading past the last valid entry in a inline directory, and then run into the end of xattr marker. This will trigger a divide by zero fault. Fix this by using the size of the inline directory instead of dir->i_size. Also clean up error reporting in __ext4_check_dir_entry so that the message is clearer and more understandable --- and avoids the division by zero trap if the size passed in is zero. (I'm not sure why we coded it that way in the first place; printing offset % size is actually more confusing and less useful.) https://bugzilla.kernel.org/show_bug.cgi?id=200933 Signed-off-by: Theodore Ts'o Reported-by: Wen Xu Signed-off-by: Ben Hutchings commit e8ac3eaff771e024aee36f71abd5bd7533ce689a Author: Johan Hovold Date: Tue Aug 21 11:59:53 2018 +0200 USB: serial: ti_usb_3410_5052: fix array underflow in completion handler commit 5dfdd24eb3d39d815bc952ae98128e967c9bba49 upstream. Similarly to a recently reported bug in io_ti, a malicious USB device could set port_number to a negative value and we would underflow the port array in the interrupt completion handler. As these devices only have one or two ports, fix this by making sure we only consider the seventh bit when determining the port number (and ignore bits 0xb0 which are typically set to 0x30). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit a0ebefb70b2a2294ce5ba70e48f29507f6ad9dac Author: Mathieu OTHACEHE Date: Thu May 12 10:48:36 2016 +0200 USB: serial: ti_usb_3410_5052: use functions rather than macros commit d8d841e8332779fae2b18420d39ef407ea3729da upstream. Functions are preferable to macros resembling functions. Signed-off-by: Mathieu OTHACEHE [johan: drop inline keyword, move above calling function ] Signed-off-by: Johan Hovold [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 1828e97b238419b0dffe86f2e01e9124a0522122 Author: Johan Hovold Date: Tue Aug 21 11:59:52 2018 +0200 USB: serial: io_ti: fix array underflow in completion handler commit 691a03cfe8ca483f9c48153b869d354e4ae3abef upstream. As reported by Dan Carpenter, a malicious USB device could set port_number to a negative value and we would underflow the port array in the interrupt completion handler. As these devices only have one or two ports, fix this by making sure we only consider the seventh bit when determining the port number (and ignore bits 0xb0 which are typically set to 0x30). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Dan Carpenter Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit e496526dcaf26efb254308c7d14abf05d6830a5c Author: Andi Kleen Date: Fri Aug 24 10:03:50 2018 -0700 x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ commit cc51e5428ea54f575d49cfcede1d4cb3a72b4ec4 upstream. On Nehalem and newer core CPUs the CPU cache internally uses 44 bits physical address space. The L1TF workaround is limited by this internal cache address width, and needs to have one bit free there for the mitigation to work. Older client systems report only 36bit physical address space so the range check decides that L1TF is not mitigated for a 36bit phys/32GB system with some memory holes. But since these actually have the larger internal cache width this warning is bogus because it would only really be needed if the system had more than 43bits of memory. Add a new internal x86_cache_bits field. Normally it is the same as the physical bits field reported by CPUID, but for Nehalem and newerforce it to be at least 44bits. Change the L1TF memory size warning to use the new cache_bits field to avoid bogus warnings and remove the bogus comment about memory size. Fixes: 17dbca119312 ("x86/speculation/l1tf: Add sysfs reporting for l1tf") Reported-by: George Anchev Reported-by: Christopher Snowhill Signed-off-by: Andi Kleen Signed-off-by: Thomas Gleixner Cc: x86@kernel.org Cc: linux-kernel@vger.kernel.org Cc: Michael Hocko Cc: vbabka@suse.cz Link: https://lkml.kernel.org/r/20180824170351.34874-1-andi@firstfloor.org [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit c28ecf0e4ad89314fa0e4fdfdb58e4fa91296987 Author: Andi Kleen Date: Fri Aug 24 10:03:51 2018 -0700 x86/spectre: Add missing family 6 check to microcode check commit 1ab534e85c93945f7862378d8c8adcf408205b19 upstream. The check for Spectre microcodes does not check for family 6, only the model numbers. Add a family 6 check to avoid ambiguity with other families. Fixes: a5b296636453 ("x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 microcodes") Signed-off-by: Andi Kleen Signed-off-by: Thomas Gleixner Cc: x86@kernel.org Cc: linux-kernel@vger.kernel.org Link: https://lkml.kernel.org/r/20180824170351.34874-2-andi@firstfloor.org Signed-off-by: Ben Hutchings commit 085e3928e6dddeacff74040952656f9d54ecfcf6 Author: Theodore Ts'o Date: Mon Aug 27 01:47:09 2018 -0400 ext4: check to make sure the rename(2)'s destination is not freed commit b50282f3241acee880514212d88b6049fb5039c8 upstream. If the destination of the rename(2) system call exists, the inode's link count (i_nlinks) must be non-zero. If it is, the inode can end up on the orphan list prematurely, leading to all sorts of hilarity, including a use-after-free. https://bugzilla.kernel.org/show_bug.cgi?id=200931 Signed-off-by: Theodore Ts'o Reported-by: Wen Xu [bwh: Backported to 3.16: - Return -EIO on error - Adjust context] Signed-off-by: Ben Hutchings commit 25992c86367b78adbe78464fb85083da1b289b43 Author: Gustavo A. R. Silva Date: Wed Aug 15 08:14:37 2018 -0500 hwmon: (nct6775) Fix potential Spectre v1 commit d49dbfade96d5b0863ca8a90122a805edd5ef50a upstream. val can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: vers/hwmon/nct6775.c:2698 store_pwm_weight_temp_sel() warn: potential spectre issue 'data->temp_src' [r] Fix this by sanitizing val before using it to index data->temp_src Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Guenter Roeck [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 8d5761d774afccc0e5056047ddac7bb58f314948 Author: Anssi Hannula Date: Thu Aug 23 10:45:22 2018 +0300 net: macb: do not disable MDIO bus at open/close time commit 0da70f808029476001109b6cb076737bc04cea2e upstream. macb_reset_hw() is called from macb_close() and indirectly from macb_open(). macb_reset_hw() zeroes the NCR register, including the MPE (Management Port Enable) bit. This will prevent accessing any other PHYs for other Ethernet MACs on the MDIO bus, which remains registered at macb_reset_hw() time, until macb_init_hw() is called from macb_open() which sets the MPE bit again. I.e. currently the MDIO bus has a short disruption at open time and is disabled at close time until the interface is opened again. Fix that by only touching the RE and TE bits when enabling and disabling RX/TX. v2: Make macb_init_hw() NCR write a single statement. Fixes: 6c36a7074436 ("macb: Use generic PHY layer") Signed-off-by: Anssi Hannula Reviewed-by: Claudiu Beznea Tested-by: Claudiu Beznea Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit 9755c40858350196b28817bd459e2499b13d871a Author: Nicholas Mc Guire Date: Thu Aug 23 12:24:02 2018 +0200 cifs: check kmalloc before use commit 126c97f4d0d1b5b956e8b0740c81a2b2a2ae548c upstream. The kmalloc was not being checked - if it fails issue a warning and return -ENOMEM to the caller. Signed-off-by: Nicholas Mc Guire Fixes: b8da344b74c8 ("cifs: dynamic allocation of ntlmssp blob") Signed-off-by: Steve French Reviewed-by: Pavel Shilovsky Signed-off-by: Ben Hutchings commit 52c01119020ede1f4f935ed1f81f7f418eca69b1 Author: Peter Zijlstra Date: Wed Aug 22 17:30:14 2018 +0200 mm/tlb: Remove tlb_remove_table() non-concurrent condition commit a6f572084fbee8b30f91465f4a085d7a90901c57 upstream. Will noted that only checking mm_users is incorrect; we should also check mm_count in order to cover CPUs that have a lazy reference to this mm (and could do speculative TLB operations). If removing this turns out to be a performance issue, we can re-instate a more complete check, but in tlb_table_flush() eliding the call_rcu_sched(). Fixes: 267239116987 ("mm, powerpc: move the RCU page-table freeing into generic code") Reported-by: Will Deacon Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rik van Riel Acked-by: Will Deacon Cc: Nicholas Piggin Cc: David Miller Cc: Martin Schwidefsky Cc: Michael Ellerman Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 32e0dc1b86fad6e0da8691c90af2e0d2a1160329 Author: Nicholas Piggin Date: Thu Aug 23 18:47:08 2018 +1000 mm: move tlb_table_flush to tlb_flush_mmu_free commit db7ddef301128dad394f1c0f77027f86ee9a4edb upstream. There is no need to call this from tlb_flush_mmu_tlbonly, it logically belongs with tlb_flush_mmu_free. This makes future fixes simpler. [ This was originally done to allow code consolidation for the mmu_notifier fix, but it also ends up helping simplify the HAVE_RCU_TABLE_INVALIDATE fix. - Linus ] Signed-off-by: Nicholas Piggin Acked-by: Will Deacon Cc: Peter Zijlstra Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 15ed746c6d50f0f84b2bcdf1219782e4bbdc7585 Author: Christian Brauner Date: Thu Jun 7 13:43:48 2018 +0200 getxattr: use correct xattr length commit 82c9a927bc5df6e06b72d206d24a9d10cced4eb5 upstream. When running in a container with a user namespace, if you call getxattr with name = "system.posix_acl_access" and size % 8 != 4, then getxattr silently skips the user namespace fixup that it normally does resulting in un-fixed-up data being returned. This is caused by posix_acl_fix_xattr_to_user() being passed the total buffer size and not the actual size of the xattr as returned by vfs_getxattr(). This commit passes the actual length of the xattr as returned by vfs_getxattr() down. A reproducer for the issue is: touch acl_posix setfacl -m user:0:rwx acl_posix and the compile: #define _GNU_SOURCE #include #include #include #include #include #include #include /* Run in user namespace with nsuid 0 mapped to uid != 0 on the host. */ int main(int argc, void **argv) { ssize_t ret1, ret2; char buf1[128], buf2[132]; int fret = EXIT_SUCCESS; char *file; if (argc < 2) { fprintf(stderr, "Please specify a file with " "\"system.posix_acl_access\" permissions set\n"); _exit(EXIT_FAILURE); } file = argv[1]; ret1 = getxattr(file, "system.posix_acl_access", buf1, sizeof(buf1)); if (ret1 < 0) { fprintf(stderr, "%s - Failed to retrieve " "\"system.posix_acl_access\" " "from \"%s\"\n", strerror(errno), file); _exit(EXIT_FAILURE); } ret2 = getxattr(file, "system.posix_acl_access", buf2, sizeof(buf2)); if (ret2 < 0) { fprintf(stderr, "%s - Failed to retrieve " "\"system.posix_acl_access\" " "from \"%s\"\n", strerror(errno), file); _exit(EXIT_FAILURE); } if (ret1 != ret2) { fprintf(stderr, "The value of \"system.posix_acl_" "access\" for file \"%s\" changed " "between two successive calls\n", file); _exit(EXIT_FAILURE); } for (ssize_t i = 0; i < ret2; i++) { if (buf1[i] == buf2[i]) continue; fprintf(stderr, "Unexpected different in byte %zd: " "%02x != %02x\n", i, buf1[i], buf2[i]); fret = EXIT_FAILURE; } if (fret == EXIT_SUCCESS) fprintf(stderr, "Test passed\n"); else fprintf(stderr, "Test failed\n"); _exit(fret); } and run: ./tester acl_posix On a non-fixed up kernel this should return something like: root@c1:/# ./t Unexpected different in byte 16: ffffffa0 != 00 Unexpected different in byte 17: ffffff86 != 00 Unexpected different in byte 18: 01 != 00 and on a fixed kernel: root@c1:~# ./t Test passed Fixes: 2f6f0654ab61 ("userns: Convert vfs posix_acl support to use kuids and kgids") Link: https://bugzilla.kernel.org/show_bug.cgi?id=199945 Reported-by: Colin Watson Signed-off-by: Christian Brauner Acked-by: Serge Hallyn Signed-off-by: Eric W. Biederman Signed-off-by: Ben Hutchings commit d05549029edc975305f396c48a832f768a93f7f8 Author: John Johansen Date: Tue Aug 21 17:19:53 2018 -0700 apparmor: remove no-op permission check in policy_unpack commit c037bd615885f1d9d3bdb48531bace79fae1505d upstream. The patch 736ec752d95e: "AppArmor: policy routines for loading and unpacking policy" from Jul 29, 2010, leads to the following static checker warning: security/apparmor/policy_unpack.c:410 verify_accept() warn: bitwise AND condition is false here security/apparmor/policy_unpack.c:413 verify_accept() warn: bitwise AND condition is false here security/apparmor/policy_unpack.c 392 #define DFA_VALID_PERM_MASK 0xffffffff 393 #define DFA_VALID_PERM2_MASK 0xffffffff 394 395 /** 396 * verify_accept - verify the accept tables of a dfa 397 * @dfa: dfa to verify accept tables of (NOT NULL) 398 * @flags: flags governing dfa 399 * 400 * Returns: 1 if valid accept tables else 0 if error 401 */ 402 static bool verify_accept(struct aa_dfa *dfa, int flags) 403 { 404 int i; 405 406 /* verify accept permissions */ 407 for (i = 0; i < dfa->tables[YYTD_ID_ACCEPT]->td_lolen; i++) { 408 int mode = ACCEPT_TABLE(dfa)[i]; 409 410 if (mode & ~DFA_VALID_PERM_MASK) 411 return 0; 412 413 if (ACCEPT_TABLE2(dfa)[i] & ~DFA_VALID_PERM2_MASK) 414 return 0; fixes: 736ec752d95e ("AppArmor: policy routines for loading and unpacking policy") Reported-by: Dan Carpenter Signed-off-by: John Johansen Signed-off-by: Ben Hutchings commit 24ae6acad8876679e9004261929e79d9c616f40c Author: Jann Horn Date: Tue Aug 21 21:59:37 2018 -0700 reiserfs: fix broken xattr handling (heap corruption, bad retval) commit a13f085d111e90469faf2d9965eb39b11c114d7e upstream. This fixes the following issues: - When a buffer size is supplied to reiserfs_listxattr() such that each individual name fits, but the concatenation of all names doesn't fit, reiserfs_listxattr() overflows the supplied buffer. This leads to a kernel heap overflow (verified using KASAN) followed by an out-of-bounds usercopy and is therefore a security bug. - When a buffer size is supplied to reiserfs_listxattr() such that a name doesn't fit, -ERANGE should be returned. But reiserfs instead just truncates the list of names; I have verified that if the only xattr on a file has a longer name than the supplied buffer length, listxattr() incorrectly returns zero. With my patch applied, -ERANGE is returned in both cases and the memory corruption doesn't happen anymore. Credit for making me clean this code up a bit goes to Al Viro, who pointed out that the ->actor calling convention is suboptimal and should be changed. Link: http://lkml.kernel.org/r/20180802151539.5373-1-jannh@google.com Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers") Signed-off-by: Jann Horn Acked-by: Jeff Mahoney Cc: Eric Biggers Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: - The xattr handler's list operation does the copy, so also update the buffer size we pass to it - Adjust context] Signed-off-by: Ben Hutchings commit 9d7c5b0db93d3101e15a4e1a6aafebf95685b6a6 Author: Jeremy Cline Date: Tue Jul 31 01:37:31 2018 +0000 fs/quota: Fix spectre gadget in do_quotactl commit 7b6924d94a60c6b8c1279ca003e8744e6cd9e8b1 upstream. 'type' is user-controlled, so sanitize it after the bounds check to avoid using it in speculative execution. This covers the following potential gadgets detected with the help of smatch: * fs/ext4/super.c:5741 ext4_quota_read() warn: potential spectre issue 'sb_dqopt(sb)->files' [r] * fs/ext4/super.c:5778 ext4_quota_write() warn: potential spectre issue 'sb_dqopt(sb)->files' [r] * fs/f2fs/super.c:1552 f2fs_quota_read() warn: potential spectre issue 'sb_dqopt(sb)->files' [r] * fs/f2fs/super.c:1608 f2fs_quota_write() warn: potential spectre issue 'sb_dqopt(sb)->files' [r] * fs/quota/dquot.c:412 mark_info_dirty() warn: potential spectre issue 'sb_dqopt(sb)->info' [w] * fs/quota/dquot.c:933 dqinit_needed() warn: potential spectre issue 'dquots' [r] * fs/quota/dquot.c:2112 dquot_commit_info() warn: potential spectre issue 'dqopt->ops' [r] * fs/quota/dquot.c:2362 vfs_load_quota_inode() warn: potential spectre issue 'dqopt->files' [w] (local cap) * fs/quota/dquot.c:2369 vfs_load_quota_inode() warn: potential spectre issue 'dqopt->ops' [w] (local cap) * fs/quota/dquot.c:2370 vfs_load_quota_inode() warn: potential spectre issue 'dqopt->info' [w] (local cap) * fs/quota/quota.c:110 quota_getfmt() warn: potential spectre issue 'sb_dqopt(sb)->info' [r] * fs/quota/quota_v2.c:84 v2_check_quota_file() warn: potential spectre issue 'quota_magics' [w] * fs/quota/quota_v2.c:85 v2_check_quota_file() warn: potential spectre issue 'quota_versions' [w] * fs/quota/quota_v2.c:96 v2_read_file_info() warn: potential spectre issue 'dqopt->info' [r] * fs/quota/quota_v2.c:172 v2_write_file_info() warn: potential spectre issue 'dqopt->info' [r] Additionally, a quick inspection indicates there are array accesses with 'type' in quota_on() and quota_off() functions which are also addressed by this. Cc: Josh Poimboeuf Signed-off-by: Jeremy Cline Signed-off-by: Jan Kara [bwh: Backported to 3.16: The maximum valid quota type is command-dependent. Introduce a local variable rather than repeating the expression.] Signed-off-by: Ben Hutchings commit 70d0ea3ee67afceb9bdb1dc8b2c6a3c4db45f139 Author: Mike Christie Date: Thu Jul 26 12:13:49 2018 -0500 iscsi target: fix session creation failure handling commit 26abc916a898d34c5ad159315a2f683def3c5555 upstream. The problem is that iscsi_login_zero_tsih_s1 sets conn->sess early in iscsi_login_set_conn_values. If the function fails later like when we alloc the idr it does kfree(sess) and leaves the conn->sess pointer set. iscsi_login_zero_tsih_s1 then returns -Exyz and we then call iscsi_target_login_sess_out and access the freed memory. This patch has iscsi_login_zero_tsih_s1 either completely setup the session or completely tear it down, so later in iscsi_target_login_sess_out we can just check for it being set to the connection. Fixes: 0957627a9960 ("iscsi-target: Fix sess allocation leak in...") Signed-off-by: Mike Christie Acked-by: Martin K. Petersen Signed-off-by: Matthew Wilcox Signed-off-by: Ben Hutchings commit cf57407ef9a2ce26ef4bdfe2f9a84ccefd1e9e86 Author: Evgenii Lepikhin Date: Tue Apr 21 15:49:57 2015 +0300 ISCSI: fix minor memory leak commit a928d28d4487402e6bd18bea1b8cc2b2ec6e6d8f upstream. This patch adds a missing kfree for sess->sess_ops memory upon transport_init_session() failure. Signed-off-by: Evgenii Lepikhin Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit 69ca36db991d2439cf127f0ecfeecbace2b9d3ce Author: Sagi Grimberg Date: Mon Dec 15 15:08:54 2014 +0200 iscsi-target: nullify session in failed login sequence commit a0b3b9b2409b409c677f7eb1e0485b816a5848f7 upstream. In case login sequence failed, make sure conn->sess is NULL before calling wait_conn as some transports (iser) may rely on that (waiting for session commands). Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit f346ea7c7416fb302ebe9d6b349ad8c2d366d03c Author: Rian Hunter Date: Sun Aug 19 16:08:53 2018 -0700 x86/process: Re-export start_thread() commit dc76803e57cc86589c4efcb5362918f9b0c0436f upstream. The consolidation of the start_thread() functions removed the export unintentionally. This breaks binfmt handlers built as a module. Add it back. Fixes: e634d8fc792c ("x86-64: merge the standard and compat start_thread() functions") Signed-off-by: Rian Hunter Signed-off-by: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Vitaly Kuznetsov Cc: Joerg Roedel Cc: Dmitry Safonov Cc: Josh Poimboeuf Link: https://lkml.kernel.org/r/20180819230854.7275-1-rian@alum.mit.edu Signed-off-by: Ben Hutchings commit bcf7c0e1d5a1a7167032d931c83474344f2833e9 Author: Benjamin Herrenschmidt Date: Fri Aug 17 17:30:39 2018 +1000 powerpc/powernv/pci: Work around races in PCI bridge enabling commit db2173198b9513f7add8009f225afa1f1c79bcc6 upstream. The generic code is racy when multiple children of a PCI bridge try to enable it simultaneously. This leads to drivers trying to access a device through a not-yet-enabled bridge, and this EEH errors under various circumstances when using parallel driver probing. There is work going on to fix that properly in the PCI core but it will take some time. x86 gets away with it because (outside of hotplug), the BIOS enables all the bridges at boot time. This patch does the same thing on powernv by enabling all bridges that have child devices at boot time, thus avoiding subsequent races. It's suitable for backporting to stable and distros, while the proper PCI fix will probably be significantly more invasive. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman [bwh: Backported to 3.16: - Use dev_err() instead of pci_err() - Adjust context] Signed-off-by: Ben Hutchings commit bd52aa398818e7ed7c6538f61cf3fbd3613af2b0 Author: Paul Mackerras Date: Mon Aug 20 16:05:45 2018 +1000 KVM: PPC: Book3S HV: Don't truncate HPTE index in xlate function commit 46dec40fb741f00f1864580130779aeeaf24fb3d upstream. This fixes a bug which causes guest virtual addresses to get translated to guest real addresses incorrectly when the guest is using the HPT MMU and has more than 256GB of RAM, or more specifically has a HPT larger than 2GB. This has showed up in testing as a failure of the host to emulate doorbell instructions correctly on POWER9 for HPT guests with more than 256GB of RAM. The bug is that the HPTE index in kvmppc_mmu_book3s_64_hv_xlate() is stored as an int, and in forming the HPTE address, the index gets shifted left 4 bits as an int before being signed-extended to 64 bits. The simple fix is to make the variable a long int, matching the return type of kvmppc_hv_find_lock_hpte(), which is what calculates the index. Fixes: 697d3899dcb4 ("KVM: PPC: Implement MMIO emulation support for Book3S HV guests") Signed-off-by: Paul Mackerras [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 6c1c9fe8444b382595ef52059419d53894452dc2 Author: Greg Hackmann Date: Wed Aug 15 12:51:21 2018 -0700 arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid() commit 5ad356eabc47d26a92140a0c4b20eba471c10de3 upstream. ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input before seeing if the PFN is valid. This leads to false positives when some of the upper bits are set, but the lower bits match a valid PFN. For example, the following userspace code looks up a bogus entry in /proc/kpageflags: int pagemap = open("/proc/self/pagemap", O_RDONLY); int pageflags = open("/proc/kpageflags", O_RDONLY); uint64_t pfn, val; lseek64(pagemap, [...], SEEK_SET); read(pagemap, &pfn, sizeof(pfn)); if (pfn & (1UL << 63)) { /* valid PFN */ pfn &= ((1UL << 55) - 1); /* clear flag bits */ pfn |= (1UL << 55); lseek64(pageflags, pfn * sizeof(uint64_t), SEEK_SET); read(pageflags, &val, sizeof(val)); } On ARM64 this causes the userspace process to crash with SIGSEGV rather than reading (1 << KPF_NOPAGE). kpageflags_read() treats the offset as valid, and stable_page_flags() will try to access an address between the user and kernel address ranges. Fixes: c1cc1552616d ("arm64: MMU initialisation") Signed-off-by: Greg Hackmann Signed-off-by: Will Deacon [bwh: Backported to 3.16: Keep using memblock_is_memory()] Signed-off-by: Ben Hutchings commit 04e75f14a4911c234240afb7eccacea0ef160dd3 Author: Steven Rostedt (VMware) Date: Thu Aug 16 16:08:37 2018 -0400 tracing/blktrace: Fix to allow setting same value commit 757d9140072054528b13bbe291583d9823cde195 upstream. Masami Hiramatsu reported: Current trace-enable attribute in sysfs returns an error if user writes the same setting value as current one, e.g. # cat /sys/block/sda/trace/enable 0 # echo 0 > /sys/block/sda/trace/enable bash: echo: write error: Invalid argument # echo 1 > /sys/block/sda/trace/enable # echo 1 > /sys/block/sda/trace/enable bash: echo: write error: Device or resource busy But this is not a preferred behavior, it should ignore if new setting is same as current one. This fixes the problem as below. # cat /sys/block/sda/trace/enable 0 # echo 0 > /sys/block/sda/trace/enable # echo 1 > /sys/block/sda/trace/enable # echo 1 > /sys/block/sda/trace/enable Link: http://lkml.kernel.org/r/20180816103802.08678002@gandalf.local.home Cc: Ingo Molnar Cc: Jens Axboe Cc: linux-block@vger.kernel.org Fixes: cd649b8bb830d ("blktrace: remove sysfs_blk_trace_enable_show/store()") Reported-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit 9d9d14f8287fc09e3870195ceee093f8eca903c9 Author: Florian Westphal Date: Thu Aug 2 21:44:40 2018 +0200 netfilter: nf_tables: fix register ordering commit d209df3e7f7002d9099fdb0f6df0f972b4386a63 upstream. We must register nfnetlink ops last, as that exposes nf_tables to userspace. Without this, we could theoretically get nfnetlink request before net->nft state has been initialized. Fixes: 99633ab29b213 ("netfilter: nf_tables: complete net namespace support") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso [bwh: Backported to 3.16: - We don't call nft_chain_filter_{init,fini}() or {,un}register_netdevice_notifier() - Adjust context] Signed-off-by: Ben Hutchings commit bb975791057f5fb972599baccb30fd0be98739ff Author: Taehee Yoo Date: Thu Jul 26 00:39:51 2018 +0900 netfilter: nft_set: fix allocation size overflow in privsize callback. commit 4ef360dd6a65f6ef337645e1b65e744034754b19 upstream. In order to determine allocation size of set, ->privsize is invoked. At this point, both desc->size and size of each data structure of set are used. desc->size means number of element that is given by user. desc->size is u32 type. so that upperlimit of set element is 4294967295. but return type of ->privsize is also u32. hence overflow can occurred. test commands: %nft add table ip filter %nft add set ip filter hash1 { type ipv4_addr \; size 4294967295 \; } %nft list ruleset splat looks like: [ 1239.202910] kasan: CONFIG_KASAN_INLINE enabled [ 1239.208788] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 1239.217625] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 1239.219329] CPU: 0 PID: 1603 Comm: nft Not tainted 4.18.0-rc5+ #7 [ 1239.229091] RIP: 0010:nft_hash_walk+0x1d2/0x310 [nf_tables_set] [ 1239.229091] Code: 84 d2 7f 10 4c 89 e7 89 44 24 38 e8 d8 5a 17 e0 8b 44 24 38 48 8d 7b 10 41 0f b6 0c 24 48 89 fa 48 89 fe 48 c1 ea 03 83 e6 07 <42> 0f b6 14 3a 40 38 f2 7f 1a 84 d2 74 16 [ 1239.229091] RSP: 0018:ffff8801118cf358 EFLAGS: 00010246 [ 1239.229091] RAX: 0000000000000000 RBX: 0000000000020400 RCX: 0000000000000001 [ 1239.229091] RDX: 0000000000004082 RSI: 0000000000000000 RDI: 0000000000020410 [ 1239.229091] RBP: ffff880114d5a988 R08: 0000000000007e94 R09: ffff880114dd8030 [ 1239.229091] R10: ffff880114d5a988 R11: ffffed00229bb006 R12: ffff8801118cf4d0 [ 1239.229091] R13: ffff8801118cf4d8 R14: 0000000000000000 R15: dffffc0000000000 [ 1239.229091] FS: 00007f5a8fe0b700(0000) GS:ffff88011b600000(0000) knlGS:0000000000000000 [ 1239.229091] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1239.229091] CR2: 00007f5a8ecc27b0 CR3: 000000010608e000 CR4: 00000000001006f0 [ 1239.229091] Call Trace: [ 1239.229091] ? nft_hash_remove+0xf0/0xf0 [nf_tables_set] [ 1239.229091] ? memset+0x1f/0x40 [ 1239.229091] ? __nla_reserve+0x9f/0xb0 [ 1239.229091] ? memcpy+0x34/0x50 [ 1239.229091] nf_tables_dump_set+0x9a1/0xda0 [nf_tables] [ 1239.229091] ? __kmalloc_reserve.isra.29+0x2e/0xa0 [ 1239.229091] ? nft_chain_hash_obj+0x630/0x630 [nf_tables] [ 1239.229091] ? nf_tables_commit+0x2c60/0x2c60 [nf_tables] [ 1239.229091] netlink_dump+0x470/0xa20 [ 1239.229091] __netlink_dump_start+0x5ae/0x690 [ 1239.229091] nft_netlink_dump_start_rcu+0xd1/0x160 [nf_tables] [ 1239.229091] nf_tables_getsetelem+0x2e5/0x4b0 [nf_tables] [ 1239.229091] ? nft_get_set_elem+0x440/0x440 [nf_tables] [ 1239.229091] ? nft_chain_hash_obj+0x630/0x630 [nf_tables] [ 1239.229091] ? nf_tables_dump_obj_done+0x70/0x70 [nf_tables] [ 1239.229091] ? nla_parse+0xab/0x230 [ 1239.229091] ? nft_get_set_elem+0x440/0x440 [nf_tables] [ 1239.229091] nfnetlink_rcv_msg+0x7f0/0xab0 [nfnetlink] [ 1239.229091] ? nfnetlink_bind+0x1d0/0x1d0 [nfnetlink] [ 1239.229091] ? debug_show_all_locks+0x290/0x290 [ 1239.229091] ? sched_clock_cpu+0x132/0x170 [ 1239.229091] ? find_held_lock+0x39/0x1b0 [ 1239.229091] ? sched_clock_local+0x10d/0x130 [ 1239.229091] netlink_rcv_skb+0x211/0x320 [ 1239.229091] ? nfnetlink_bind+0x1d0/0x1d0 [nfnetlink] [ 1239.229091] ? netlink_ack+0x7b0/0x7b0 [ 1239.229091] ? ns_capable_common+0x6e/0x110 [ 1239.229091] nfnetlink_rcv+0x2d1/0x310 [nfnetlink] [ 1239.229091] ? nfnetlink_rcv_batch+0x10f0/0x10f0 [nfnetlink] [ 1239.229091] ? netlink_deliver_tap+0x829/0x930 [ 1239.229091] ? lock_acquire+0x265/0x2e0 [ 1239.229091] netlink_unicast+0x406/0x520 [ 1239.509725] ? netlink_attachskb+0x5b0/0x5b0 [ 1239.509725] ? find_held_lock+0x39/0x1b0 [ 1239.509725] netlink_sendmsg+0x987/0xa20 [ 1239.509725] ? netlink_unicast+0x520/0x520 [ 1239.509725] ? _copy_from_user+0xa9/0xc0 [ 1239.509725] __sys_sendto+0x21a/0x2c0 [ 1239.509725] ? __ia32_sys_getpeername+0xa0/0xa0 [ 1239.509725] ? retint_kernel+0x10/0x10 [ 1239.509725] ? sched_clock_cpu+0x132/0x170 [ 1239.509725] ? find_held_lock+0x39/0x1b0 [ 1239.509725] ? lock_downgrade+0x540/0x540 [ 1239.509725] ? up_read+0x1c/0x100 [ 1239.509725] ? __do_page_fault+0x763/0x970 [ 1239.509725] ? retint_user+0x18/0x18 [ 1239.509725] __x64_sys_sendto+0x177/0x180 [ 1239.509725] do_syscall_64+0xaa/0x360 [ 1239.509725] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1239.509725] RIP: 0033:0x7f5a8f468e03 [ 1239.509725] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb d0 0f 1f 84 00 00 00 00 00 83 3d 49 c9 2b 00 00 75 13 49 89 ca b8 2c 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 [ 1239.509725] RSP: 002b:00007ffd78d0b778 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 1239.509725] RAX: ffffffffffffffda RBX: 00007ffd78d0c890 RCX: 00007f5a8f468e03 [ 1239.509725] RDX: 0000000000000034 RSI: 00007ffd78d0b7e0 RDI: 0000000000000003 [ 1239.509725] RBP: 00007ffd78d0b7d0 R08: 00007f5a8f15c160 R09: 000000000000000c [ 1239.509725] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd78d0b7e0 [ 1239.509725] R13: 0000000000000034 R14: 00007f5a8f9aff60 R15: 00005648040094b0 [ 1239.509725] Modules linked in: nf_tables_set nf_tables nfnetlink ip_tables x_tables [ 1239.670713] ---[ end trace 39375adcda140f11 ]--- [ 1239.676016] RIP: 0010:nft_hash_walk+0x1d2/0x310 [nf_tables_set] [ 1239.682834] Code: 84 d2 7f 10 4c 89 e7 89 44 24 38 e8 d8 5a 17 e0 8b 44 24 38 48 8d 7b 10 41 0f b6 0c 24 48 89 fa 48 89 fe 48 c1 ea 03 83 e6 07 <42> 0f b6 14 3a 40 38 f2 7f 1a 84 d2 74 16 [ 1239.705108] RSP: 0018:ffff8801118cf358 EFLAGS: 00010246 [ 1239.711115] RAX: 0000000000000000 RBX: 0000000000020400 RCX: 0000000000000001 [ 1239.719269] RDX: 0000000000004082 RSI: 0000000000000000 RDI: 0000000000020410 [ 1239.727401] RBP: ffff880114d5a988 R08: 0000000000007e94 R09: ffff880114dd8030 [ 1239.735530] R10: ffff880114d5a988 R11: ffffed00229bb006 R12: ffff8801118cf4d0 [ 1239.743658] R13: ffff8801118cf4d8 R14: 0000000000000000 R15: dffffc0000000000 [ 1239.751785] FS: 00007f5a8fe0b700(0000) GS:ffff88011b600000(0000) knlGS:0000000000000000 [ 1239.760993] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1239.767560] CR2: 00007f5a8ecc27b0 CR3: 000000010608e000 CR4: 00000000001006f0 [ 1239.775679] Kernel panic - not syncing: Fatal exception [ 1239.776630] Kernel Offset: 0x1f000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 1239.776630] Rebooting in 5 seconds.. Fixes: 20a69341f2d0 ("netfilter: nf_tables: add netlink set API") Signed-off-by: Taehee Yoo Signed-off-by: Pablo Neira Ayuso [bwh: Backported to 3.16: - Drop changes to nft_rhash_privsize() and in nft_set_bitmap.c - Adjust filenames] Signed-off-by: Ben Hutchings commit debdcc64c98f968a67c6c7f9addd6cc913580233 Author: Sebastian Ott Date: Mon Aug 13 11:26:46 2018 +0200 s390/pci: fix out of bounds access during irq setup commit 866f3576a72b2233a76dffb80290f8086dc49e17 upstream. During interrupt setup we allocate interrupt vectors, walk the list of msi descriptors, and fill in the message data. Requesting more interrupts than supported on s390 can lead to an out of bounds access. When we restrict the number of interrupts we should also stop walking the msi list after all supported interrupts are handled. Signed-off-by: Sebastian Ott Signed-off-by: Heiko Carstens Signed-off-by: Ben Hutchings commit b0d2b6dfc721cc4e504005f99023b45c4d1e16f3 Author: Guenter Roeck Date: Fri Aug 3 20:59:51 2018 -0700 mfd: sm501: Set coherent_dma_mask when creating subdevices commit 2f606da78230f09cf1a71fde6ee91d0c710fa2b2 upstream. Instantiating the sm501 OHCI subdevice results in a kernel warning. sm501-usb sm501-usb: SM501 OHCI sm501-usb sm501-usb: new USB bus registered, assigned bus number 1 WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 ohci_init+0x194/0x2d8 Modules linked in: CPU: 0 PID: 1 Comm: swapper Tainted: G W 4.18.0-rc7-00178-g0b5b1f9a78b5 #1 PC is at ohci_init+0x194/0x2d8 PR is at ohci_init+0x168/0x2d8 PC : 8c27844c SP : 8f81dd94 SR : 40008001 TEA : 29613060 R0 : 00000000 R1 : 00000000 R2 : 00000000 R3 : 00000202 R4 : 8fa98b88 R5 : 8c277e68 R6 : 00000000 R7 : 00000000 R8 : 8f965814 R9 : 8c388100 R10 : 8fa98800 R11 : 8fa98928 R12 : 8c48302c R13 : 8fa98920 R14 : 8c48302c MACH: 00000096 MACL: 0000017c GBR : 00000000 PR : 8c278420 Call trace: [<(ptrval)>] usb_add_hcd+0x1e8/0x6ec [<(ptrval)>] _dev_info+0x0/0x54 [<(ptrval)>] arch_local_save_flags+0x0/0x8 [<(ptrval)>] arch_local_irq_restore+0x0/0x24 [<(ptrval)>] ohci_hcd_sm501_drv_probe+0x114/0x2d8 ... Initialize coherent_dma_mask when creating SM501 subdevices to fix the problem. Fixes: b6d6454fdb66f ("mfd: SM501 core driver") Signed-off-by: Guenter Roeck Signed-off-by: Lee Jones Signed-off-by: Ben Hutchings commit c1b43b31923476d84bd3cfcc891eba4b2d88083f Author: Jani Nikula Date: Tue Aug 14 09:00:01 2018 +0300 drm/i915: set DP Main Stream Attribute for color range on DDI platforms commit 6209c285e7a5e68dbcdf8fd2456c6dd68433806b upstream. Since Haswell we have no color range indication either in the pipe or port registers for DP. Instead, there's a separate register for setting the DP Main Stream Attributes (MSA) directly. The MSA register definition makes no references to colorimetry, just a vague reference to the DP spec. The connection to the color range was lost. Apparently we've failed to set the proper MSA bit for limited, or CEA, range ever since the first DDI platforms. We've started setting other MSA parameters since commit dae847991a43 ("drm/i915: add intel_ddi_set_pipe_settings"). Without the crucial bit of information, the DP sink has no way of knowing the source is actually transmitting limited range RGB, leading to "washed out" colors. With the colorimetry information, compliant sinks should be able to handle the limited range properly. Native (i.e. non-LSPCON) HDMI was not affected because we do pass the color range via AVI infoframes. Though not the root cause, the problem was made worse for DDI platforms with commit 55bc60db5988 ("drm/i915: Add "Automatic" mode for the "Broadcast RGB" property"), which selects limited range RGB automatically based on the mode, as per the DP, HDMI and CEA specs. After all these years, the fix boils down to flipping one bit. [Per testing reports, this fixes DP sinks, but not the LSPCON. My educated guess is that the LSPCON fails to turn the CEA range MSA into AVI infoframes for HDMI.] Reported-by: Michał Kopeć Reported-by: N. W. Reported-by: Nicholas Stommel Reported-by: Tom Yan Tested-by: Nicholas Stommel References: https://bugs.freedesktop.org/show_bug.cgi?id=100023 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921 Cc: Paulo Zanoni Cc: Rodrigo Vivi Cc: Ville Syrjälä Reviewed-by: Rodrigo Vivi Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com (cherry picked from commit dc5977da99ea28094b8fa4e9bacbd29bedc41de5) Signed-off-by: Rodrigo Vivi [bwh: Backported to 3.16: - s/crtc_state->/intel_crtc->config./ - Adjust context, indentation] Signed-off-by: Ben Hutchings commit 735bbb86335c08cad3399d9993c8c1091629841b Author: Richard Weinberger Date: Sun Jul 1 23:20:51 2018 +0200 ubifs: Check data node size before truncate commit 95a22d2084d72ea067d8323cc85677dba5d97cae upstream. Check whether the size is within bounds before using it. If the size is not correct, abort and dump the bad data node. Cc: Kees Cook Cc: Silvio Cesare Fixes: 1e51764a3c2ac ("UBIFS: add new flash file system") Reported-by: Silvio Cesare Signed-off-by: Richard Weinberger Reviewed-by: Kees Cook Signed-off-by: Richard Weinberger [bwh: Backported to 3.16: Drop first argument to ubifs_err()] Signed-off-by: Ben Hutchings commit 0ae67939e008c102cb3612358242817056604de8 Author: Richard Weinberger Date: Tue Jun 12 20:49:45 2018 +0200 ubifs: Fix memory leak in lprobs self-check commit eef19816ada3abd56d9f20c88794cc2fea83ebb2 upstream. Allocate the buffer after we return early. Otherwise memory is being leaked. Fixes: 1e51764a3c2a ("UBIFS: add new flash file system") Signed-off-by: Richard Weinberger Signed-off-by: Ben Hutchings commit b38e954d9b9b42da01696b042cce29ce7a3d3091 Author: Richard Weinberger Date: Tue Jun 12 00:52:28 2018 +0200 ubifs: Fix synced_i_size calculation for xattr inodes commit 59965593205fa4044850d35ee3557cf0b7edcd14 upstream. In ubifs_jnl_update() we sync parent and child inodes to the flash, in case of xattrs, the parent inode (AKA host inode) has a non-zero data_len. Therefore we need to adjust synced_i_size too. This issue was reported by ubifs self tests unter a xattr related work load. UBIFS error (ubi0:0 pid 1896): dbg_check_synced_i_size: ui_size is 4, synced_i_size is 0, but inode is clean UBIFS error (ubi0:0 pid 1896): dbg_check_synced_i_size: i_ino 65, i_mode 0x81a4, i_size 4 Fixes: 1e51764a3c2a ("UBIFS: add new flash file system") Signed-off-by: Richard Weinberger [bwh: Backported to 3.16: s/host_ui/dir_ui/] Signed-off-by: Ben Hutchings commit ce34f1978b3e220b98847f121738772c5aa046ed Author: Max Filippov Date: Fri Aug 10 22:21:22 2018 -0700 xtensa: increase ranges in ___invalidate_{i,d}cache_all commit fec3259c9f747c039f90e99570540114c8d81a14 upstream. Cache invalidation macros use cache line size to iterate over invalidated cache lines, assuming that all cache ways are invalidated by single instruction, but xtensa ISA recommends to not assume that for future compatibility: In some implementations all ways at index Addry-1..z are invalidated regardless of the specified way, but for future compatibility this behavior should not be assumed. Iterate over all cache ways in ___invalidate_icache_all and ___invalidate_dcache_all. Signed-off-by: Max Filippov [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 4a44253d6fc398b0ea66692b7027701292391832 Author: Max Filippov Date: Fri Aug 10 20:43:48 2018 -0700 xtensa: limit offsets in __loop_cache_{all,page} commit be75de25251f7cf3e399ca1f584716a95510d24a upstream. When building kernel for xtensa cores with big cache lines (e.g. 128 bytes or more) __loop_cache_all and __loop_cache_page may generate assembly instructions with immediate fields that are too big. This results in the following build errors: arch/xtensa/mm/misc.S: Assembler messages: arch/xtensa/mm/misc.S:464: Error: operand 2 of 'diwbi' has invalid value '256' arch/xtensa/mm/misc.S:464: Error: operand 2 of 'diwbi' has invalid value '384' arch/xtensa/kernel/head.S: Assembler messages: arch/xtensa/kernel/head.S:172: Error: operand 2 of 'diu' has invalid value '256' arch/xtensa/kernel/head.S:172: Error: operand 2 of 'diu' has invalid value '384' arch/xtensa/kernel/head.S:176: Error: operand 2 of 'iiu' has invalid value '256' arch/xtensa/kernel/head.S:176: Error: operand 2 of 'iiu' has invalid value '384' arch/xtensa/kernel/head.S:255: Error: operand 2 of 'diwb' has invalid value '256' arch/xtensa/kernel/head.S:255: Error: operand 2 of 'diwb' has invalid value '384' Add parameter max_immed to these macros and use it to limit values of immediate operands. Extract common code of these macros into the new macro __loop_cache_unroll. Signed-off-by: Max Filippov [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 996e65d8fb23fc6c65e8ab38e0d87f69b6e9d498 Author: Wei Wang Date: Fri Aug 10 11:14:56 2018 -0700 l2tp: use sk_dst_check() to avoid race on sk->sk_dst_cache commit 6d37fa49da1e8db8fb1995be22ac837ca41ac8a8 upstream. In l2tp code, if it is a L2TP_UDP_ENCAP tunnel, tunnel->sk points to a UDP socket. User could call sendmsg() on both this tunnel and the UDP socket itself concurrently. As l2tp_xmit_skb() holds socket lock and call __sk_dst_check() to refresh sk->sk_dst_cache, while udpv6_sendmsg() is lockless and call sk_dst_check() to refresh sk->sk_dst_cache, there could be a race and cause the dst cache to be freed multiple times. So we fix l2tp side code to always call sk_dst_check() to garantee xchg() is called when refreshing sk->sk_dst_cache to avoid race conditions. Syzkaller reported stack trace: BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] BUG: KASAN: use-after-free in atomic_fetch_add_unless include/linux/atomic.h:575 [inline] BUG: KASAN: use-after-free in atomic_add_unless include/linux/atomic.h:597 [inline] BUG: KASAN: use-after-free in dst_hold_safe include/net/dst.h:308 [inline] BUG: KASAN: use-after-free in ip6_hold_safe+0xe6/0x670 net/ipv6/route.c:1029 Read of size 4 at addr ffff8801aea9a880 by task syz-executor129/4829 CPU: 0 PID: 4829 Comm: syz-executor129 Not tainted 4.18.0-rc7-next-20180802+ #30 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267 kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272 atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] atomic_fetch_add_unless include/linux/atomic.h:575 [inline] atomic_add_unless include/linux/atomic.h:597 [inline] dst_hold_safe include/net/dst.h:308 [inline] ip6_hold_safe+0xe6/0x670 net/ipv6/route.c:1029 rt6_get_pcpu_route net/ipv6/route.c:1249 [inline] ip6_pol_route+0x354/0xd20 net/ipv6/route.c:1922 ip6_pol_route_output+0x54/0x70 net/ipv6/route.c:2098 fib6_rule_lookup+0x283/0x890 net/ipv6/fib6_rules.c:122 ip6_route_output_flags+0x2c5/0x350 net/ipv6/route.c:2126 ip6_dst_lookup_tail+0x1278/0x1da0 net/ipv6/ip6_output.c:978 ip6_dst_lookup_flow+0xc8/0x270 net/ipv6/ip6_output.c:1079 ip6_sk_dst_lookup_flow+0x5ed/0xc50 net/ipv6/ip6_output.c:1117 udpv6_sendmsg+0x2163/0x36b0 net/ipv6/udp.c:1354 inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798 sock_sendmsg_nosec net/socket.c:622 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:632 ___sys_sendmsg+0x51d/0x930 net/socket.c:2115 __sys_sendmmsg+0x240/0x6f0 net/socket.c:2210 __do_sys_sendmmsg net/socket.c:2239 [inline] __se_sys_sendmmsg net/socket.c:2236 [inline] __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2236 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x446a29 Code: e8 ac b8 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f4de5532db8 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00000000006dcc38 RCX: 0000000000446a29 RDX: 00000000000000b8 RSI: 0000000020001b00 RDI: 0000000000000003 RBP: 00000000006dcc30 R08: 00007f4de5533700 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dcc3c R13: 00007ffe2b830fdf R14: 00007f4de55339c0 R15: 0000000000000001 Fixes: 71b1391a4128 ("l2tp: ensure sk->dst is still valid") Reported-by: syzbot+05f840f3b04f211bad55@syzkaller.appspotmail.com Signed-off-by: Wei Wang Signed-off-by: Martin KaFai Lau Cc: Guillaume Nault Cc: David Ahern Cc: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 29c81a20822ab0a27ae750174a509c3fba8eeb74 Author: Punit Agrawal Date: Mon Aug 13 11:43:51 2018 +0100 KVM: arm/arm64: Skip updating PTE entry if no change commit 976d34e2dab10ece5ea8fe7090b7692913f89084 upstream. When there is contention on faulting in a particular page table entry at stage 2, the break-before-make requirement of the architecture can lead to additional refaulting due to TLB invalidation. Avoid this by skipping a page table update if the new value of the PTE matches the previous value. Fixes: d5d8184d35c9 ("KVM: ARM: Memory virtualization setup") Reviewed-by: Suzuki Poulose Acked-by: Christoffer Dall Signed-off-by: Punit Agrawal Signed-off-by: Marc Zyngier [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 8ea3919abf6492bf1afa2490d278bbcd29520808 Author: Punit Agrawal Date: Mon Aug 13 11:43:50 2018 +0100 KVM: arm/arm64: Skip updating PMD entry if no change commit 86658b819cd0a9aa584cd84453ed268a6f013770 upstream. Contention on updating a PMD entry by a large number of vcpus can lead to duplicate work when handling stage 2 page faults. As the page table update follows the break-before-make requirement of the architecture, it can lead to repeated refaults due to clearing the entry and flushing the tlbs. This problem is more likely when - * there are large number of vcpus * the mapping is large block mapping such as when using PMD hugepages (512MB) with 64k pages. Fix this by skipping the page table update if there is no change in the entry being updated. Fixes: ad361f093c1e ("KVM: ARM: Support hugetlbfs backed huge pages") Reviewed-by: Suzuki Poulose Acked-by: Christoffer Dall Signed-off-by: Punit Agrawal Signed-off-by: Marc Zyngier [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit a07e75b2ef840fcaf1d2428543feb3a2c7aedd4c Author: jiangyiwen Date: Fri Aug 3 12:11:34 2018 +0800 9p/virtio: fix off-by-one error in sg list bounds check commit 23cba9cbde0bba05d772b335fe5f66aa82b9ad19 upstream. Because the value of limit is VIRTQUEUE_NUM, if index is equal to limit, it will cause sg array out of bounds, so correct the judgement of BUG_ON. Link: http://lkml.kernel.org/r/5B63D5F6.6080109@huawei.com Signed-off-by: Yiwen Jiang Reported-By: Dan Carpenter Acked-by: Jun Piao Signed-off-by: Dominique Martinet Signed-off-by: Ben Hutchings commit 551758acfa47bae936765ad34c1456f9a0540091 Author: Tomas Bortoli Date: Fri Jul 27 13:05:58 2018 +0200 9p: fix multiple NULL-pointer-dereferences commit 10aa14527f458e9867cf3d2cc6b8cb0f6704448b upstream. Added checks to prevent GPFs from raising. Link: http://lkml.kernel.org/r/20180727110558.5479-1-tomasbortoli@gmail.com Signed-off-by: Tomas Bortoli Reported-by: syzbot+1a262da37d3bead15c39@syzkaller.appspotmail.com Signed-off-by: Dominique Martinet [bwh: Backported to 3.16: - Drop changes in trans_xen.c Signed-off-by: Ben Hutchings commit bd531ebf1538b1387cc93545ca647e54a1ff66bc Author: piaojun Date: Wed Jul 25 11:13:16 2018 +0800 fs/9p/xattr.c: catch the error of p9_client_clunk when setting xattr failed commit 3111784bee81591ea2815011688d28b65df03627 upstream. In my testing, v9fs_fid_xattr_set will return successfully even if the backend ext4 filesystem has no space to store xattr key-value. That will cause inconsistent behavior between front end and back end. The reason is that lsetxattr will be triggered by p9_client_clunk, and unfortunately we did not catch the error. This patch will catch the error to notify upper caller. p9_client_clunk (in 9p) p9_client_rpc(clnt, P9_TCLUNK, "d", fid->fid); v9fs_clunk (in qemu) put_fid free_fid v9fs_xattr_fid_clunk v9fs_co_lsetxattr s->ops->lsetxattr ext4_xattr_user_set (in host ext4 filesystem) Link: http://lkml.kernel.org/r/5B57EACC.2060900@huawei.com Signed-off-by: Jun Piao Cc: Eric Van Hensbergen Cc: Ron Minnich Cc: Latchesar Ionkov Cc: Andrew Morton Signed-off-by: Dominique Martinet [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 8aeafabdf4f5db429858c140361674ac57c2b54d Author: Tomas Bortoli Date: Fri Jul 20 11:27:30 2018 +0200 net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree() commit 430ac66eb4c5b5c4eb846b78ebf65747510b30f1 upstream. The patch adds the flush in p9_mux_poll_stop() as it the function used by p9_conn_destroy(), in turn called by p9_fd_close() to stop the async polling associated with the data regarding the connection. Link: http://lkml.kernel.org/r/20180720092730.27104-1-tomasbortoli@gmail.com Signed-off-by: Tomas Bortoli Reported-by: syzbot+39749ed7d9ef6dfb23f6@syzkaller.appspotmail.com To: Eric Van Hensbergen To: Ron Minnich To: Latchesar Ionkov Cc: Yiwen Jiang Signed-off-by: Dominique Martinet Signed-off-by: Ben Hutchings commit fca090b9d9a535ac2553ce778f8634b5a16e7eb3 Author: Chirantan Ekbote Date: Mon Jul 16 17:35:29 2018 -0700 9p/net: Fix zero-copy path in the 9p virtio transport commit d28c756caee6e414d9ba367d0b92da24145af2a8 upstream. The zero-copy optimization when reading or writing large chunks of data is quite useful. However, the 9p messages created through the zero-copy write path have an incorrect message size: it should be the size of the header + size of the data being written but instead it's just the size of the header. This only works if the server ignores the size field of the message and otherwise breaks the framing of the protocol. Fix this by re-writing the message size field with the correct value. Tested by running `dd if=/dev/zero of=out bs=4k count=1` inside a virtio-9p mount. Link: http://lkml.kernel.org/r/20180717003529.114368-1-chirantan@chromium.org Signed-off-by: Chirantan Ekbote Reviewed-by: Greg Kurz Tested-by: Greg Kurz Cc: Dylan Reid Cc: Guenter Roeck Signed-off-by: Dominique Martinet [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit d0f2fd36292ebf7787c8a2344216f58f48bdcf66 Author: Tomas Bortoli Date: Tue Jul 10 00:29:43 2018 +0200 net/9p/client.c: version pointer uninitialized commit 7913690dcc5e18e235769fd87c34143072f5dbea upstream. The p9_client_version() does not initialize the version pointer. If the call to p9pdu_readf() returns an error and version has not been allocated in p9pdu_readf(), then the program will jump to the "error" label and will try to free the version pointer. If version is not initialized, free() will be called with uninitialized, garbage data and will provoke a crash. Link: http://lkml.kernel.org/r/20180709222943.19503-1-tomasbortoli@gmail.com Signed-off-by: Tomas Bortoli Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com Reviewed-by: Jun Piao Reviewed-by: Yiwen Jiang Cc: Eric Van Hensbergen Cc: Ron Minnich Cc: Latchesar Ionkov Signed-off-by: Andrew Morton Signed-off-by: Dominique Martinet Signed-off-by: Ben Hutchings commit 64caa93318d6f4a8a26b8a7ab95447a24add6b80 Author: Steven Rostedt (VMware) Date: Thu Aug 9 15:37:59 2018 -0400 uprobes: Use synchronize_rcu() not synchronize_sched() commit 016f8ffc48cb01d1e7701649c728c5d2e737d295 upstream. While debugging another bug, I was looking at all the synchronize*() functions being used in kernel/trace, and noticed that trace_uprobes was using synchronize_sched(), with a comment to synchronize with {u,ret}_probe_trace_func(). When looking at those functions, the data is protected with "rcu_read_lock()" and not with "rcu_read_lock_sched()". This is using the wrong synchronize_*() function. Link: http://lkml.kernel.org/r/20180809160553.469e1e32@gandalf.local.home Fixes: 70ed91c6ec7f8 ("tracing/uprobes: Support ftrace_event_file base multibuffer") Acked-by: Oleg Nesterov Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Ben Hutchings commit bd86251525fafedc27f952d6ac08e526f54a7f51 Author: Mahesh Salgaonkar Date: Tue Aug 7 19:46:46 2018 +0530 powerpc/pseries: Fix endianness while restoring of r3 in MCE handler. commit cd813e1cd7122f2c261dce5b54d1e0c97f80e1a5 upstream. During Machine Check interrupt on pseries platform, register r3 points RTAS extended event log passed by hypervisor. Since hypervisor uses r3 to pass pointer to rtas log, it stores the original r3 value at the start of the memory (first 8 bytes) pointed by r3. Since hypervisor stores this info and rtas log is in BE format, linux should make sure to restore r3 value in correct endian format. Without this patch when MCE handler, after recovery, returns to code that that caused the MCE may end up with Data SLB access interrupt for invalid address followed by kernel panic or hang. Severe Machine check interrupt [Recovered] NIP [d00000000ca301b8]: init_module+0x1b8/0x338 [bork_kernel] Initiator: CPU Error type: SLB [Multihit] Effective address: d00000000ca70000 cpu 0xa: Vector: 380 (Data SLB Access) at [c0000000fc7775b0] pc: c0000000009694c0: vsnprintf+0x80/0x480 lr: c0000000009698e0: vscnprintf+0x20/0x60 sp: c0000000fc777830 msr: 8000000002009033 dar: a803a30c000000d0 current = 0xc00000000bc9ef00 paca = 0xc00000001eca5c00 softe: 3 irq_happened: 0x01 pid = 8860, comm = insmod vscnprintf+0x20/0x60 vprintk_emit+0xb4/0x4b0 vprintk_func+0x5c/0xd0 printk+0x38/0x4c init_module+0x1c0/0x338 [bork_kernel] do_one_initcall+0x54/0x230 do_init_module+0x8c/0x248 load_module+0x12b8/0x15b0 sys_finit_module+0xa8/0x110 system_call+0x58/0x6c --- Exception: c00 (System Call) at 00007fff8bda0644 SP (7fffdfbfe980) is in userspace This patch fixes this issue. Fixes: a08a53ea4c97 ("powerpc/le: Enable RTAS events support") Reviewed-by: Nicholas Piggin Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit db7014e21b556b071db7b704d5b2598ef8982ad6 Author: Hari Bathini Date: Tue Aug 7 02:12:45 2018 +0530 powerpc/fadump: handle crash memory ranges array index overflow commit 1bd6a1c4b80a28d975287630644e6b47d0f977a5 upstream. Crash memory ranges is an array of memory ranges of the crashing kernel to be exported as a dump via /proc/vmcore file. The size of the array is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since commit 142b45a72e22 ("memblock: Add array resizing support"). On large memory systems with a few DLPAR operations, the memblock memory regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such systems, registering fadump results in crash or other system failures like below: task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000 NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180 REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+) MSR: 8000000000009033 CR: 22004484 XER: 20000000 CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0 ... NIP [c000000000047df4] smp_send_reschedule+0x24/0x80 LR [c0000000000f9e58] resched_curr+0x138/0x160 Call Trace: resched_curr+0x138/0x160 (unreliable) check_preempt_curr+0xc8/0xf0 ttwu_do_wakeup+0x38/0x150 try_to_wake_up+0x224/0x4d0 __wake_up_common+0x94/0x100 ep_poll_callback+0xac/0x1c0 __wake_up_common+0x94/0x100 __wake_up_sync_key+0x70/0xa0 sock_def_readable+0x58/0xa0 unix_stream_sendmsg+0x2dc/0x4c0 sock_sendmsg+0x68/0xa0 ___sys_sendmsg+0x2cc/0x2e0 __sys_sendmsg+0x5c/0xc0 SyS_socketcall+0x36c/0x3f0 system_call+0x3c/0x100 as array index overflow is not checked for while setting up crash memory ranges causing memory corruption. To resolve this issue, dynamically allocate memory for crash memory ranges and resize it incrementally, in units of pagesize, on hitting array size limit. Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.") Signed-off-by: Hari Bathini Reviewed-by: Mahesh Salgaonkar [mpe: Just use PAGE_SIZE directly, fixup variable placement] Signed-off-by: Michael Ellerman [bwh: Backported to 3.16: - register_fadump() returns void - Include for kfree(), krealloc()] Signed-off-by: Ben Hutchings commit 0641d6135565d91f60daf0f1955a9c76d80f59f5 Author: Dan Carpenter Date: Wed Aug 8 14:57:24 2018 +0300 powerpc: Fix size calculation using resource_size() commit c42d3be0c06f0c1c416054022aa535c08a1f9b39 upstream. The problem is the the calculation should be "end - start + 1" but the plus one is missing in this calculation. Fixes: 8626816e905e ("powerpc: add support for MPIC message register API") Signed-off-by: Dan Carpenter Reviewed-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit 0dfcace9369911f089858ef54450130cfdd7259d Author: Michael Büsch Date: Tue Jul 31 21:14:16 2018 +0200 b43legacy/leds: Ensure NUL-termination of LED name string commit 4d77a89e3924b12f4a5628b21237e57ab4703866 upstream. strncpy might not NUL-terminate the string, if the name equals the buffer size. Use strlcpy instead. Signed-off-by: Michael Buesch Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit bae102ee0220833f123c6973aa66c4c7a92ee5ca Author: Michael Büsch Date: Tue Jul 31 21:14:04 2018 +0200 b43/leds: Ensure NUL-termination of LED name string commit 2aa650d1950fce94f696ebd7db30b8830c2c946f upstream. strncpy might not NUL-terminate the string, if the name equals the buffer size. Use strlcpy instead. Signed-off-by: Michael Buesch Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 067bc5f5a0140ce31176f4e8ef89fcf401f902aa Author: Dan Carpenter Date: Wed Aug 8 17:29:09 2018 +0300 scsi: aic94xx: fix an error code in aic94xx_init() commit 0756c57bce3d26da2592d834d8910b6887021701 upstream. We accidentally return success instead of -ENOMEM on this error path. Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Signed-off-by: Dan Carpenter Reviewed-by: Johannes Thumshirn Reviewed-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit 94443ddc1c27743e7c1e6fe6a42473923f66e3dd Author: Mauro Carvalho Chehab Date: Tue Aug 7 06:49:26 2018 -0400 media: rtl28xxu: be sure that it won't go past the array size commit 845b978a871bff3707eee611b32e4be0b9a94dd2 upstream. smatch warns that the RC query code could go past the array size: drivers/media/usb/dvb-usb-v2/rtl28xxu.c:1757 rtl2832u_rc_query() error: buffer overflow 'buf' 128 <= 130 drivers/media/usb/dvb-usb-v2/rtl28xxu.c:1758 rtl2832u_rc_query() error: buffer overflow 'buf' 128 <= 130 The driver logic gets the length of the IR RX buffer with: ret = rtl28xxu_rd_reg(d, IR_RX_BC, &buf[0]); ... len = buf[0]; In thesis, this could range between 0 and 255 [1]. While this should never happen in practice, due to hardware limits, smatch is right when it complains about that, as there's nothing at the logic that would prevent it. So, if for whatever reason, buf[0] gets filled by rtl28xx read functions with a value bigger than 128, it will go past the array. So, add an explicit check. [1] I've no idea why smatch thinks that the maximum value is 130. I double-checked the code several times. Was unable to find any reason for assuming 130. Perhaps smatch is not properly parsing u8 here? Fixes: b5cbaa43a676 ("[media] rtl28xx: initial support for rtl2832u") Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit fa7328b080f9eb446fcfde4a3d6cb17425cc9172 Author: Thomas Petazzoni Date: Fri Aug 3 16:38:44 2018 +0200 PCI: mvebu: Fix I/O space end address calculation commit dfd0309fd7b30a5baffaf47b2fccb88b46d64d69 upstream. pcie->realio.end should be the address of last byte of the area, therefore using resource_size() of another resource is not correct, we must substract 1 to get the address of the last byte. Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout") Signed-off-by: Thomas Petazzoni Signed-off-by: Lorenzo Pieralisi [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 52fcc51987280ac59ae81717ca4a43648d74028a Author: Steve French Date: Thu Jun 28 18:46:40 2018 -0500 cifs: add missing debug entries for kconfig options commit 950132afd59385caf6e2b84e5235d069fa10681d upstream. /proc/fs/cifs/DebugData displays the features (Kconfig options) used to build cifs.ko but it was missing some, and needed comma separator. These can be useful in debugging certain problems so we know which optional features were enabled in the user's build. Also clarify them, by making them more closely match the corresponding CONFIG_CIFS_* parm. Old format: Features: dfs fscache posix spnego xattr acl New format: Features: DFS,FSCACHE,SMB_DIRECT,STATS,DEBUG2,ALLOW_INSECURE_LEGACY,CIFS_POSIX,UPCALL(SPNEGO),XATTR,ACL Signed-off-by: Steve French Reviewed-by: Ronnie Sahlberg Reviewed-by: Pavel Shilovsky Reviewed-by: Paulo Alcantara Signed-off-by: Ben Hutchings commit af7463de2b7bd17080006829fe3672d7972003ea Author: Steve French Date: Sun Jun 24 23:18:52 2018 -0500 smb3: fill in statfs fsid and correct namelen commit 21ba3845b59c733a79ed4fe1c4f3732e7ece9df7 upstream. Fil in the correct namelen (typically 255 not 4096) in the statfs response and also fill in a reasonably unique fsid (in this case taken from the volume id, and the creation time of the volume). In the case of the POSIX statfs all fields are now filled in, and in the case of non-POSIX mounts, all fields are filled in which can be. Signed-off-by: Steve French Reviewed-by: Aurelien Aptel [bwh: Backported to 3.16: Only use cifs_tcon::vol_{serial_number,create_time} if CONFIG_CIFS_SMB2 is enabled] Signed-off-by: Ben Hutchings commit 726e55771695497ef46d1b1a2f100ecb9c15d5b2 Author: Mike Snitzer Date: Thu Aug 2 16:08:52 2018 -0400 dm cache metadata: save in-core policy_hint_size to on-disk superblock commit fd2fa95416188a767a63979296fa3e169a9ef5ec upstream. policy_hint_size starts as 0 during __write_initial_superblock(). It isn't until the policy is loaded that policy_hint_size is set in-core (cmd->policy_hint_size). But it never got recorded in the on-disk superblock because __commit_transaction() didn't deal with transfering the in-core cmd->policy_hint_size to the on-disk superblock. The in-core cmd->policy_hint_size gets initialized by metadata_open()'s __begin_transaction_flags() which re-reads all superblock fields. Because the superblock's policy_hint_size was never properly stored, when the cache was created, hints_array_available() would always return false when re-activating a previously created cache. This means __load_mappings() always considered the hints invalid and never made use of the hints (these hints served to optimize). Another detremental side-effect of this oversight is the cache_check utility would fail with: "invalid hint width: 0" Signed-off-by: Mike Snitzer Signed-off-by: Ben Hutchings commit 20a334b403478c0fe7e4f27712b645f5a51174b2 Author: Mahesh Salgaonkar Date: Wed Jul 4 23:27:02 2018 +0530 powerpc/pseries: Avoid using the size greater than RTAS_ERROR_LOG_MAX. commit 74e96bf44f430cf7a01de19ba6cf49b361cdfd6e upstream. The global mce data buffer that used to copy rtas error log is of 2048 (RTAS_ERROR_LOG_MAX) bytes in size. Before the copy we read extended_log_length from rtas error log header, then use max of extended_log_length and RTAS_ERROR_LOG_MAX as a size of data to be copied. Ideally the platform (phyp) will never send extended error log with size > 2048. But if that happens, then we have a risk of buffer overrun and corruption. Fix this by using min_t instead. Fixes: d368514c3097 ("powerpc: Fix corruption when grabbing FWNMI data") Reported-by: Michal Suchanek Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit 29002321516dd7a79e4840d3800a86f2aaa070c3 Author: Gustavo A. R. Silva Date: Mon Aug 6 07:14:51 2018 -0500 ASoC: wm8994: Fix missing break in switch commit ad0eaee6195db1db1749dd46b9e6f4466793d178 upstream. Add missing break statement in order to prevent the code from falling through to the default case. Addresses-Coverity-ID: 115050 ("Missing break in switch") Reported-by: Valdis Kletnieks Signed-off-by: Gustavo A. R. Silva Acked-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit 68ca4087a2c47400158dcf91b1556acff835d6b8 Author: Gustavo A. R. Silva Date: Wed Aug 1 14:56:16 2018 -0500 ASoC: wm8994: Mark expected switch fall-through commit 2cea1542859bc812f1ec51ea71c06e927e5b922e upstream. In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 115050 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit e842d8fbbc67385b464d38424133968b5f516056 Author: Anand Jain Date: Wed Aug 20 10:54:17 2014 +0800 btrfs: rename total_bytes to avoid confusion commit 3c1dbdf54a31f4f049a33214c3096595988786bf upstream. we are assigning number_devices to the total_bytes, that's very confusing for a moment Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Ben Hutchings commit adc2d442ee30acecbdc57150237b920acc945192 Author: Josef Bacik Date: Fri Jul 20 11:46:10 2018 -0700 Btrfs: fix btrfs_write_inode vs delayed iput deadlock commit 3c4276936f6fbe52884b4ea4e6cc120b890a0f9f upstream. We recently ran into the following deadlock involving btrfs_write_inode(): [ +0.005066] __schedule+0x38e/0x8c0 [ +0.007144] schedule+0x36/0x80 [ +0.006447] bit_wait+0x11/0x60 [ +0.006446] __wait_on_bit+0xbe/0x110 [ +0.007487] ? bit_wait_io+0x60/0x60 [ +0.007319] __inode_wait_for_writeback+0x96/0xc0 [ +0.009568] ? autoremove_wake_function+0x40/0x40 [ +0.009565] inode_wait_for_writeback+0x21/0x30 [ +0.009224] evict+0xb0/0x190 [ +0.006099] iput+0x1a8/0x210 [ +0.006103] btrfs_run_delayed_iputs+0x73/0xc0 [ +0.009047] btrfs_commit_transaction+0x799/0x8c0 [ +0.009567] btrfs_write_inode+0x81/0xb0 [ +0.008008] __writeback_single_inode+0x267/0x320 [ +0.009569] writeback_sb_inodes+0x25b/0x4e0 [ +0.008702] wb_writeback+0x102/0x2d0 [ +0.007487] wb_workfn+0xa4/0x310 [ +0.006794] ? wb_workfn+0xa4/0x310 [ +0.007143] process_one_work+0x150/0x410 [ +0.008179] worker_thread+0x6d/0x520 [ +0.007490] kthread+0x12c/0x160 [ +0.006620] ? put_pwq_unlocked+0x80/0x80 [ +0.008185] ? kthread_park+0xa0/0xa0 [ +0.007484] ? do_syscall_64+0x53/0x150 [ +0.007837] ret_from_fork+0x29/0x40 Writeback calls: btrfs_write_inode btrfs_commit_transaction btrfs_run_delayed_iputs If iput() is called on that same inode, evict() will wait for writeback forever. btrfs_write_inode() was originally added way back in 4730a4bc5bf3 ("btrfs_dirty_inode") to support O_SYNC writes. However, ->write_inode() hasn't been used for O_SYNC since 148f948ba877 ("vfs: Introduce new helpers for syncing after writing to O_SYNC file or IS_SYNC inode"), so btrfs_write_inode() is actually unnecessary (and leads to a bunch of unnecessary commits). Get rid of it, which also gets rid of the deadlock. Signed-off-by: Josef Bacik [Omar: new commit message] Signed-off-by: Omar Sandoval Signed-off-by: David Sterba [bwh: Backported to 3.16: deleted function is slightly different] Signed-off-by: Ben Hutchings commit 8c4b98ace63cb039a33259eea80845b7cd377fa4 Author: Ethan Lien Date: Mon Jul 2 15:44:58 2018 +0800 btrfs: use correct compare function of dirty_metadata_bytes commit d814a49198eafa6163698bdd93961302f3a877a4 upstream. We use customized, nodesize batch value to update dirty_metadata_bytes. We should also use batch version of compare function or we will easily goto fast path and get false result from percpu_counter_compare(). Fixes: e2d845211eda ("Btrfs: use percpu counter for dirty metadata count") Signed-off-by: Ethan Lien Reviewed-by: Nikolay Borisov Signed-off-by: David Sterba [bwh: Backported to 3.16: In __btrfs_btree_balance_dirty(), use root->fs_info instead of fs_info] Signed-off-by: Ben Hutchings commit 5f2c8b3ceecd49d0a8a4b048e07e5f8c61e20be2 Author: Dave Chinner Date: Fri May 29 07:39:34 2015 +1000 percpu_counter: batch size aware __percpu_counter_compare() commit 80188b0d77d7426b494af739ac129e0e684acb84 upstream. XFS uses non-stanard batch sizes for avoiding frequent global counter updates on it's allocated inode counters, as they increment or decrement in batches of 64 inodes. Hence the standard percpu counter batch of 32 means that the counter is effectively a global counter. Currently Xfs uses a batch size of 128 so that it doesn't take the global lock on every single modification. However, Xfs also needs to compare accurately against zero, which means we need to use percpu_counter_compare(), and that has a hard-coded batch size of 32, and hence will spuriously fail to detect when it is supposed to use precise comparisons and hence the accounting goes wrong. Add __percpu_counter_compare() to take a custom batch size so we can use it sanely in XFS and factor percpu_counter_compare() to use it. Signed-off-by: Dave Chinner Acked-by: Tejun Heo Signed-off-by: Dave Chinner Signed-off-by: Ben Hutchings commit faeb75a4ae227efccb09ec2cc673999460b0e176 Author: Alexander Aring Date: Mon Jul 2 16:32:03 2018 -0400 net: mac802154: tx: expand tailroom if necessary commit f9c52831133050c6b82aa8b6831c92da2bbf2a0b upstream. This patch is necessary if case of AF_PACKET or other socket interface which I am aware of it and didn't allocated the necessary room. Reported-by: David Palma Reported-by: Rabi Narayan Sahoo Signed-off-by: Alexander Aring Signed-off-by: Stefan Schmidt [bwh: Backported to 3.16: - Substitute literal number for IEEE802154_FCS_LEN - Adjust context] Signed-off-by: Ben Hutchings commit fbf6086661ae673a8f1b29b8e86438aa9a6f05de Author: Alexander Aring Date: Mon Oct 27 17:13:28 2014 +0100 mac802154: tx: use put_unaligned_le16 for copy crc commit 061ef8f915988839b12460c47ebfcf3700e124f0 upstream. This patch replaces the memcpy with a put_unaligned_le16. The placement of crc inside of PSDU can also be unaligned. With memcpy this can fail on some architectures. Signed-off-by: Alexander Aring Reported-by: Marcel Holtmann Signed-off-by: Marcel Holtmann [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 6c9b4a9f64d772ae7df389e6b186afca382864c8 Author: Alexander Aring Date: Sun Oct 26 09:37:11 2014 +0100 mac802154: tx: cleanup crc calculation commit b7eec52bcb7ab93a8cce0f718f42fa17d6d91745 upstream. Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 903e7d927e9a69d7b0dbada4896f21dc7d25777f Author: Varka Bhadram Date: Mon Aug 11 13:25:10 2014 +0200 mac802154: common tx error path commit f55889128a776b51581394b20abd0b470304cf95 upstream. This patch introduce the common error path on failure of Tx by inserting the label 'err_tx'. Signed-off-by: Varka Bhadram Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann Signed-off-by: Ben Hutchings commit 96d2e7f6f1b475b070c6f462acf328a59f9a34f8 Author: Alexander Aring Date: Sat Jul 14 12:52:10 2018 -0400 net: 6lowpan: fix reserved space for single frames commit ac74f87c789af40936a80131c4759f3e72579c3a upstream. This patch fixes patch add handling to take care tail and headroom for single 6lowpan frames. We need to be sure we have a skb with the right head and tailroom for single frames. This patch do it by using skb_copy_expand() if head and tailroom is not enough allocated by upper layer. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195059 Reported-by: David Palma Reported-by: Rabi Narayan Sahoo Signed-off-by: Alexander Aring Signed-off-by: Stefan Schmidt [bwh: Backported to 3.16: - s/ldev/dev/ - Adjust filename] Signed-off-by: Ben Hutchings commit 5abf9a4229ba19fbb05dbbcff2e2d8c54022d196 Author: Simon Vincent Date: Wed Sep 24 12:21:33 2014 +0200 ieee802154: 6lowpan: ensure header compression does not corrupt ipv6 header commit f19f4f9525cf32f97341fac20ce66392e86a1b67 upstream. The 6lowpan ipv6 header compression was causing problems for other interfaces that expected a ipv6 header to still be in place, as we were replacing the ipv6 header with a compressed version. This happened if you sent a packet to a multicast address as the packet would be output on 802.15.4, ethernet, and also be sent to the loopback interface. The skb data was shared between these interfaces so all interfaces ended up with a compressed ipv6 header. The solution is to ensure that before we do any header compression we are not sharing the skb or skb data with any other interface. If we are then we must take a copy of the skb and skb data before modifying the ipv6 header. The only place we can copy the skb is inside the xmit function so we don't leave dangling references to skb. This patch moves all the header compression to inside the xmit function. Very little code has been changed it has mostly been moved from lowpan_header_create to lowpan_xmit. At the top of the xmit function we now check if the skb is shared and if so copy it. In lowpan_header_create all we do now is store the source and destination addresses for use later when we compress the header. Signed-off-by: Simon Vincent Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann Signed-off-by: Ben Hutchings commit 31c442b69caa213d74a091c659f69ce05177125c Author: YueHaibing Date: Wed Aug 1 13:10:49 2018 +0800 pinctrl: berlin: fix 'pctrl->functions' allocation in berlin_pinctrl_build_state commit b5031b7db77dc47f474f0efc2b2552c32b7bb59d upstream. fixes following Smatch static check warning: drivers/pinctrl/berlin/berlin.c:237 berlin_pinctrl_build_state() warn: passing devm_ allocated variable to kfree. 'pctrl->functions' As we will be calling krealloc() on pointer 'pctrl->functions', which means kfree() will be called in there, devm_kzalloc() shouldn't be used with the allocation in the first place. Fix the warning by calling kcalloc() and managing the free procedure in error path on our own. Fixes: 3de68d331c24 ("pinctrl: berlin: add the core pinctrl driver for Marvell Berlin SoCs") Signed-off-by: YueHaibing Reviewed-by: Jisheng Zhang Signed-off-by: Linus Walleij [bwh: Backported to 3.16: berlin_pinctrl_state() was not yet converted to devm_kcalloc()] Signed-off-by: Ben Hutchings commit f3963877fbd9da68820e644892cb2a8dbe43aeb1 Author: Eric Biggers Date: Mon Jul 23 10:54:58 2018 -0700 crypto: ablkcipher - fix crash flushing dcache in error path commit 318abdfbe708aaaa652c79fb500e9bd60521f9dc upstream. Like the skcipher_walk and blkcipher_walk cases: scatterwalk_done() is only meant to be called after a nonzero number of bytes have been processed, since scatterwalk_pagedone() will flush the dcache of the *previous* page. But in the error case of ablkcipher_walk_done(), e.g. if the input wasn't an integer number of blocks, scatterwalk_done() was actually called after advancing 0 bytes. This caused a crash ("BUG: unable to handle kernel paging request") during '!PageSlab(page)' on architectures like arm and arm64 that define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE, provided that the input was page-aligned as in that case walk->offset == 0. Fix it by reorganizing ablkcipher_walk_done() to skip the scatterwalk_advance() and scatterwalk_done() if an error has occurred. Reported-by: Liu Chao Fixes: bf06099db18a ("crypto: skcipher - Add ablkcipher_walk interfaces") Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit 63d208ad1e047bba8fb32488bb86b5cbac02c27b Author: Eric Biggers Date: Mon Jul 23 10:54:57 2018 -0700 crypto: blkcipher - fix crash flushing dcache in error path commit 0868def3e4100591e7a1fdbf3eed1439cc8f7ca3 upstream. Like the skcipher_walk case: scatterwalk_done() is only meant to be called after a nonzero number of bytes have been processed, since scatterwalk_pagedone() will flush the dcache of the *previous* page. But in the error case of blkcipher_walk_done(), e.g. if the input wasn't an integer number of blocks, scatterwalk_done() was actually called after advancing 0 bytes. This caused a crash ("BUG: unable to handle kernel paging request") during '!PageSlab(page)' on architectures like arm and arm64 that define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE, provided that the input was page-aligned as in that case walk->offset == 0. Fix it by reorganizing blkcipher_walk_done() to skip the scatterwalk_advance() and scatterwalk_done() if an error has occurred. This bug was found by syzkaller fuzzing. Reproducer, assuming ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE: #include #include #include int main() { struct sockaddr_alg addr = { .salg_type = "skcipher", .salg_name = "ecb(aes-generic)", }; char buffer[4096] __attribute__((aligned(4096))) = { 0 }; int fd; fd = socket(AF_ALG, SOCK_SEQPACKET, 0); bind(fd, (void *)&addr, sizeof(addr)); setsockopt(fd, SOL_ALG, ALG_SET_KEY, buffer, 16); fd = accept(fd, NULL, NULL); write(fd, buffer, 15); read(fd, buffer, 15); } Reported-by: Liu Chao Fixes: 5cde0af2a982 ("[CRYPTO] cipher: Added block cipher type") Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit 9528f6656f459de10fc0c036932804d9eddcf8e5 Author: Steffen Klassert Date: Wed Aug 1 13:45:11 2018 +0200 xfrm: Validate address prefix lengths in the xfrm selector. commit 07bf7908950a8b14e81aa1807e3c667eab39287a upstream. We don't validate the address prefix lengths in the xfrm selector we got from userspace. This can lead to undefined behaviour in the address matching functions if the prefix is too big for the given address family. Fix this by checking the prefixes and refuse SA/policy insertation when a prefix is invalid. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Air Icy Signed-off-by: Steffen Klassert Signed-off-by: Ben Hutchings commit 5aa0637990f0f2db75698e2101b3e52dd80dbacb Author: Bart Van Assche Date: Thu Aug 2 10:51:41 2018 -0700 scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock commit 0ee223b2e1f67cb2de9c0e3247c510d846e74d63 upstream. A long time ago the unfortunate decision was taken to add a self-deletion attribute to the sysfs SCSI device directory. That decision was unfortunate because self-deletion is really tricky. We can't drop that attribute because widely used user space software depends on it, namely the rescan-scsi-bus.sh script. Hence this patch that avoids that writing into that attribute triggers a deadlock. See also commit 7973cbd9fbd9 ("[PATCH] add sysfs attributes to scan and delete scsi_devices"). This patch avoids that self-removal triggers the following deadlock: ====================================================== WARNING: possible circular locking dependency detected 4.18.0-rc2-dbg+ #5 Not tainted ------------------------------------------------------ modprobe/6539 is trying to acquire lock: 000000008323c4cd (kn->count#202){++++}, at: kernfs_remove_by_name_ns+0x45/0x90 but task is already holding lock: 00000000a6ec2c69 (&shost->scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150 [scsi_mod] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&shost->scan_mutex){+.+.}: __mutex_lock+0xfe/0xc70 mutex_lock_nested+0x1b/0x20 scsi_remove_device+0x26/0x40 [scsi_mod] sdev_store_delete+0x27/0x30 [scsi_mod] dev_attr_store+0x3e/0x50 sysfs_kf_write+0x87/0xa0 kernfs_fop_write+0x190/0x230 __vfs_write+0xd2/0x3b0 vfs_write+0x101/0x270 ksys_write+0xab/0x120 __x64_sys_write+0x43/0x50 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #0 (kn->count#202){++++}: lock_acquire+0xd2/0x260 __kernfs_remove+0x424/0x4a0 kernfs_remove_by_name_ns+0x45/0x90 remove_files.isra.1+0x3a/0x90 sysfs_remove_group+0x5c/0xc0 sysfs_remove_groups+0x39/0x60 device_remove_attrs+0x82/0xb0 device_del+0x251/0x580 __scsi_remove_device+0x19f/0x1d0 [scsi_mod] scsi_forget_host+0x37/0xb0 [scsi_mod] scsi_remove_host+0x9b/0x150 [scsi_mod] sdebug_driver_remove+0x4b/0x150 [scsi_debug] device_release_driver_internal+0x241/0x360 device_release_driver+0x12/0x20 bus_remove_device+0x1bc/0x290 device_del+0x259/0x580 device_unregister+0x1a/0x70 sdebug_remove_adapter+0x8b/0xf0 [scsi_debug] scsi_debug_exit+0x76/0xe8 [scsi_debug] __x64_sys_delete_module+0x1c1/0x280 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&shost->scan_mutex); lock(kn->count#202); lock(&shost->scan_mutex); lock(kn->count#202); *** DEADLOCK *** 2 locks held by modprobe/6539: #0: 00000000efaf9298 (&dev->mutex){....}, at: device_release_driver_internal+0x68/0x360 #1: 00000000a6ec2c69 (&shost->scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150 [scsi_mod] stack backtrace: CPU: 10 PID: 6539 Comm: modprobe Not tainted 4.18.0-rc2-dbg+ #5 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0xa4/0xf5 print_circular_bug.isra.34+0x213/0x221 __lock_acquire+0x1a7e/0x1b50 lock_acquire+0xd2/0x260 __kernfs_remove+0x424/0x4a0 kernfs_remove_by_name_ns+0x45/0x90 remove_files.isra.1+0x3a/0x90 sysfs_remove_group+0x5c/0xc0 sysfs_remove_groups+0x39/0x60 device_remove_attrs+0x82/0xb0 device_del+0x251/0x580 __scsi_remove_device+0x19f/0x1d0 [scsi_mod] scsi_forget_host+0x37/0xb0 [scsi_mod] scsi_remove_host+0x9b/0x150 [scsi_mod] sdebug_driver_remove+0x4b/0x150 [scsi_debug] device_release_driver_internal+0x241/0x360 device_release_driver+0x12/0x20 bus_remove_device+0x1bc/0x290 device_del+0x259/0x580 device_unregister+0x1a/0x70 sdebug_remove_adapter+0x8b/0xf0 [scsi_debug] scsi_debug_exit+0x76/0xe8 [scsi_debug] __x64_sys_delete_module+0x1c1/0x280 do_syscall_64+0x77/0x230 entry_SYSCALL_64_after_hwframe+0x49/0xbe See also https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg54525.html. Fixes: ac0ece9174ac ("scsi: use device_remove_file_self() instead of device_schedule_callback()") Signed-off-by: Bart Van Assche Cc: Greg Kroah-Hartman Acked-by: Tejun Heo Cc: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit e8a37b2fd5b5087bec6cbbf6946ee3caa712953b Author: Bart Van Assche Date: Thu Aug 2 10:51:40 2018 -0700 scsi: sysfs: Introduce sysfs_{un,}break_active_protection() commit 2afc9166f79b8f6da5f347f48515215ceee4ae37 upstream. Introduce these two functions and export them such that the next patch can add calls to these functions from the SCSI core. Signed-off-by: Bart Van Assche Acked-by: Tejun Heo Acked-by: Greg Kroah-Hartman Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit 618a41aecf23b5eefc1d6200cacb22d5beb3debc Author: Dan Carpenter Date: Thu Aug 2 11:24:47 2018 +0300 uio: potential double frees if __uio_register_device() fails commit f019f07ecf6a6b8bd6d7853bce70925d90af02d1 upstream. The uio_unregister_device() function assumes that if "info->uio_dev" is non-NULL that means "info" is fully allocated. Setting info->uio_de has to be the last thing in the function. In the current code, if request_threaded_irq() fails then we return with info->uio_dev set to non-NULL but info is not fully allocated and it can lead to double frees. Fixes: beafc54c4e2f ("UIO: Add the User IO core code") Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 8c475c52f5553d35ca00aee9af658de119ef9614 Author: Denis Drozdov Date: Sun Jul 29 11:42:28 2018 +0300 IB/IPoIB: Set ah valid flag in multicast send flow commit 75da96067ade4e7854379ec2f7834f3497652b1a upstream. The change of ipoib_ah data structure with adding "valid" flag and checks of ah->valid in ipoib_start_xmit affected multicast packet flow. Since the multicast flow doesn't invoke path_rec_start, "ah->valid" flag remains unset, so that ipoib_start_xmit end up with neigh_refresh_path instead of sending the packet using neigh. "ah->valid" has to be set in multicast send flow. As a result IPoIB starts sending packets via neigh immediately and eliminates 60sec delay of neigh keep alive interval. The typical example of this issue are two sequential arpings: arping 11.134.208.9 -> got response (mcast_send) arping 11.134.208.9 -> no response (ah->valid = 0) Fixes: fa9391dbad4b ("RDMA/ipoib: Update paths on CLIENT_REREG/SM_CHANGE events") Signed-off-by: Denis Drozdov Reviewed-by: Erez Shitrit Reviewed-by: Feras Daoud Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Ben Hutchings commit e94d8cd6012da14cf18296d6342c16b295c12cbe Author: Jeremy Cline Date: Thu Aug 2 00:03:40 2018 -0400 ext4: fix spectre gadget in ext4_mb_regular_allocator() commit 1a5d5e5d51e75a5bca67dadbcea8c841934b7b85 upstream. 'ac->ac_g_ex.fe_len' is a user-controlled value which is used in the derivation of 'ac->ac_2order'. 'ac->ac_2order', in turn, is used to index arrays which makes it a potential spectre gadget. Fix this by sanitizing the value assigned to 'ac->ac2_order'. This covers the following accesses found with the help of smatch: * fs/ext4/mballoc.c:1896 ext4_mb_simple_scan_group() warn: potential spectre issue 'grp->bb_counters' [w] (local cap) * fs/ext4/mballoc.c:445 mb_find_buddy() warn: potential spectre issue 'EXT4_SB(e4b->bd_sb)->s_mb_offsets' [r] (local cap) * fs/ext4/mballoc.c:446 mb_find_buddy() warn: potential spectre issue 'EXT4_SB(e4b->bd_sb)->s_mb_maxs' [r] (local cap) Suggested-by: Josh Poimboeuf Signed-off-by: Jeremy Cline Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 9747d760ab1fcd91e6d1a556cababe34117a1747 Author: Dan Carpenter Date: Fri Jul 13 17:55:15 2018 +0300 pinctrl: freescale: off by one in imx1_pinconf_group_dbg_show() commit 19da44cd33a3a6ff7c97fff0189999ff15b241e4 upstream. The info->groups[] array is allocated in imx1_pinctrl_parse_dt(). It has info->ngroups elements. Thus the > here should be >= to prevent reading one element beyond the end of the array. Fixes: 30612cd90005 ("pinctrl: imx1 core driver") Signed-off-by: Dan Carpenter Reviewed-by: Uwe Kleine-König Acked-by: Dong Aisheng Signed-off-by: Linus Walleij [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit ba1bd77cdf6279fac8dd3a8ede6c6945e1d51f72 Author: Steven Rostedt (VMware) Date: Wed Aug 1 15:40:57 2018 -0400 tracing: Do not call start/stop() functions when tracing_on does not change commit f143641bfef9a4a60c57af30de26c63057e7e695 upstream. Currently, when one echo's in 1 into tracing_on, the current tracer's "start()" function is executed, even if tracing_on was already one. This can lead to strange side effects. One being that if the hwlat tracer is enabled, and someone does "echo 1 > tracing_on" into tracing_on, the hwlat tracer's start() function is called again which will recreate another kernel thread, and make it unable to remove the old one. Link: http://lkml.kernel.org/r/1533120354-22923-1-git-send-email-erica.bugden@linutronix.de Fixes: 2df8f8a6a897e ("tracing: Fix regression with irqsoff tracer and tracing_on file") Reported-by: Erica Bugden Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Ben Hutchings commit 59f1c7b8bbfcd734fb99393fbd83b427c6ef6a28 Author: Theodore Ts'o Date: Wed Aug 1 12:36:52 2018 -0400 ext4: check for NUL characters in extended attribute's name commit 7d95178c77014dbd8dce36ee40bbbc5e6c121ff5 upstream. Extended attribute names are defined to be NUL-terminated, so the name must not contain a NUL character. This is important because there are places when remove extended attribute, the code uses strlen to determine the length of the entry. That should probably be fixed at some point, but code is currently really messy, so the simplest fix for now is to simply validate that the extended attributes are sane. https://bugzilla.kernel.org/show_bug.cgi?id=200401 Reported-by: Wen Xu Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: return -EIO instead of -EFSCORRUPTED] Signed-off-by: Ben Hutchings commit 3f78d8034dbf4aa5f12cb68df54b0a7da79759d0 Author: Sven Eckelmann Date: Thu Jul 26 15:59:48 2018 +0200 ath10k: prevent active scans on potential unusable channels commit 3f259111583801013cb605bb4414aa529adccf1c upstream. The QCA4019 hw1.0 firmware 10.4-3.2.1-00050 and 10.4-3.5.3-00053 (and most likely all other) seem to ignore the WMI_CHAN_FLAG_DFS flag during the scan. This results in transmission (probe requests) on channels which are not "available" for transmissions. Since the firmware is closed source and nothing can be done from our side to fix the problem in it, the driver has to work around this problem. The WMI_CHAN_FLAG_PASSIVE seems to be interpreted by the firmware to not scan actively on a channel unless an AP was detected on it. Simple probe requests will then be transmitted by the STA on the channel. ath10k must therefore also use this flag when it queues a radar channel for scanning. This should reduce the chance of an active scan when the channel might be "unusable" for transmissions. Fixes: e8a50f8ba44b ("ath10k: introduce DFS implementation") Signed-off-by: Sven Eckelmann Signed-off-by: Kalle Valo Signed-off-by: Ben Hutchings commit 3b323f1b1bcfd5520ef922c6812b7643ede8520b Author: Mikulas Patocka Date: Sun Jun 3 16:40:57 2018 +0200 udl-kms: fix crash due to uninitialized memory commit 09a00abe3a9941c2715ca83eb88172cd2f54d8fd upstream. We must use kzalloc when allocating the fb_deferred_io structure. Otherwise, the field first_io is undefined and it causes a crash. Signed-off-by: Mikulas Patocka Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 2c836ab27f5830f71e748c878dbe02127cd6563b Author: Mikulas Patocka Date: Sun Jun 3 16:40:56 2018 +0200 udl-kms: handle allocation failure commit 542bb9788a1f485eb1a2229178f665d8ea166156 upstream. Allocations larger than PAGE_ALLOC_COSTLY_ORDER are unreliable and they may fail anytime. This patch fixes the udl kms driver so that when a large alloactions fails, it tries to do multiple smaller allocations. Signed-off-by: Mikulas Patocka Signed-off-by: Dave Airlie [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 3a20c56110e8b93b50e3ae3df781e6a0b5d1e85c Author: Mikulas Patocka Date: Sun Jun 3 16:40:55 2018 +0200 udl-kms: change down_interruptible to down commit 8456b99c16d193c4c3b7df305cf431e027f0189c upstream. If we leave urbs around, it causes not only leak, but also memory corruption. This patch fixes the function udl_free_urb_list, so that it always waits for all urbs that are in progress. Signed-off-by: Mikulas Patocka Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 4580f31124785043838de3e8ed2c50889b77f11e Author: Dan Carpenter Date: Thu Jul 19 11:16:48 2018 +0300 pinctrl: imx: off by one in imx_pinconf_group_dbg_show() commit b4859f3edb47825f62d1b2efdd75fe7945996f49 upstream. The > should really be >= here. It's harmless because pinctrl_generic_get_group() will return a NULL if group is invalid. Fixes: ae75ff814538 ("pinctrl: pinctrl-imx: add imx pinctrl core driver") Reported-by: Dong Aisheng Signed-off-by: Dan Carpenter Signed-off-by: Linus Walleij [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit a8c55820501476db59f4bbc44023d0ba337f2a86 Author: Yelena Krivosheev Date: Wed Jul 18 18:10:51 2018 +0200 net: mvneta: fix mtu change on port without link commit 8466baf788ec3e18836bd9c91ba0b1a07af25878 upstream. It is incorrect to enable TX/RX queues (call by mvneta_port_up()) for port without link. Indeed MTU change for interface without link causes TX queues to stuck. Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit") Signed-off-by: Yelena Krivosheev [gregory.clement: adding Fixes tags and rewording commit log] Signed-off-by: Gregory CLEMENT Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit fc02101c917716b2e990e997707a5a8d9de73dbc Author: Lars-Peter Clausen Date: Fri Jul 27 09:42:45 2018 +0300 iio: ad9523: Fix return value for ad952x_store() commit 9a5094ca29ea9b1da301b31fd377c0c0c4c23034 upstream. A sysfs write callback function needs to either return the number of consumed characters or an error. The ad952x_store() function currently returns 0 if the input value was "0", this will signal that no characters have been consumed and the function will be called repeatedly in a loop indefinitely. Fix this by returning number of supplied characters to indicate that the whole input string has been consumed. Signed-off-by: Lars-Peter Clausen Signed-off-by: Alexandru Ardelean Fixes: cd1678f96329 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator") Signed-off-by: Jonathan Cameron Signed-off-by: Ben Hutchings commit c87826868f5b09cc724fbc8396e1f19db756ebcd Author: Mauricio Faria de Oliveira Date: Wed Jul 25 22:46:29 2018 -0300 partitions/aix: append null character to print data from disk commit d43fdae7bac2def8c4314b5a49822cb7f08a45f1 upstream. Even if properly initialized, the lvname array (i.e., strings) is read from disk, and might contain corrupt data (e.g., lack the null terminating character for strings). So, make sure the partition name string used in pr_warn() has the null terminating character. Fixes: 6ceea22bbbc8 ("partitions: add aix lvm partition support files") Suggested-by: Daniel J. Axtens Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit 452a0aac138b603626c2af666d1626e49e3dbf75 Author: Mauricio Faria de Oliveira Date: Wed Jul 25 22:46:28 2018 -0300 partitions/aix: fix usage of uninitialized lv_info and lvname structures commit 14cb2c8a6c5dae57ee3e2da10fa3db2b9087e39e upstream. The if-block that sets a successful return value in aix_partition() uses 'lvip[].pps_per_lv' and 'n[].name' potentially uninitialized. For example, if 'numlvs' is zero or alloc_lvn() fails, neither is initialized, but are used anyway if alloc_pvd() succeeds after it. So, make the alloc_pvd() call conditional on their initialization. This has been hit when attaching an apparently corrupted/stressed AIX LUN, misleading the kernel to pr_warn() invalid data and hang. [...] partition (null) (11 pp's found) is not contiguous [...] partition (null) (2 pp's found) is not contiguous [...] partition (null) (3 pp's found) is not contiguous [...] partition (null) (64 pp's found) is not contiguous Fixes: 6ceea22bbbc8 ("partitions: add aix lvm partition support files") Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit ef9227615d276afc0b15be8e130c29ac15b41f7a Author: Mika Båtsman Date: Wed May 16 16:32:19 2018 -0400 media: gl861: fix probe of dvb_usb_gl861 commit 48db0089bff6f9154f6bd98ce7a6ae3786fa8ebe upstream. Probe of dvb_usb_gl861 was working at least with v4.4. Noticed the issue with v4.13 but according to similar issues the problem started with v4.9. [ 15.288065] transfer buffer not dma capable [ 15.288090] WARNING: CPU: 2 PID: 493 at drivers/usb/core/hcd.c:1595 usb_hcd_map_urb_for_dma+0x4e2/0x640 ...CUT... [ 15.288791] dvb_usb_gl861: probe of 3-7:1.0 failed with error -5 Tested with MSI Mega Sky 580 DVB-T Tuner [GL861] [mchehab+samsung@kernel.org: rebased on the top of upstream] Signed-off-by: Mika Båtsman Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 3564939e5eed9a6282203cd767b925f596643ea3 Author: Akihiro Tsukada Date: Sun Apr 8 13:21:38 2018 -0400 media: dvb-usb-v2/gl861: ensure USB message buffers DMA'able commit 86f65c218123c4e36fd855fbbc38147ffaf29974 upstream. i2c message buf might be on stack. Signed-off-by: Akihiro Tsukada Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit dc06b2632c2cd5a07a7cbdf66840cb185df688d6 Author: Takashi Iwai Date: Thu Jul 26 14:27:59 2018 +0200 ALSA: virmidi: Fix too long output trigger loop commit 50e9ffb1996a5d11ff5040a266585bad4ceeca0a upstream. The virmidi output trigger tries to parse the all available bytes and process sequencer events as much as possible. In a normal situation, this is supposed to be relatively short, but a program may give a huge buffer and it'll take a long time in a single spin lock, which may eventually lead to a soft lockup. This patch simply adds a workaround, a cond_resched() call in the loop if applicable. A better solution would be to move the event processor into a work, but let's put a duct-tape quickly at first. Reported-and-tested-by: Dae R. Jeong Reported-by: syzbot+619d9f40141d826b097e@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 56b0417092e4c12793276637e010e53b4482d658 Author: Greg Edwards Date: Thu Jul 26 15:52:54 2018 -0400 scsi: virtio_scsi: fix pi_bytes{out,in} on 4 KiB block size devices commit cdcdcaae8450a975e7d07e1bfec21f9b8c016d0c upstream. When the underlying device is a 4 KiB logical block size device with a protection interval exponent of 0, i.e. 4096 bytes data + 8 bytes PI, the driver miscalculates the pi_bytes{out,in} by a factor of 8x (64 bytes). This leads to errors on all reads and writes on 4 KiB logical block size devices when CONFIG_BLK_DEV_INTEGRITY is enabled and the VIRTIO_SCSI_F_T10_PI feature bit has been negotiated. Fixes: e6dc783a38ec0 ("virtio-scsi: Enable DIF/DIX modes in SCSI host LLD") Acked-by: Martin K. Petersen Signed-off-by: Greg Edwards Signed-off-by: Jens Axboe [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit ed1a4f65447b5475afaf2f13a74cddf332e3e5ad Author: Greg Edwards Date: Wed Jul 25 10:22:58 2018 -0400 block: move bio_integrity_{intervals,bytes} into blkdev.h commit 359f642700f2ff05d9c94cd9216c97af7b8e9553 upstream. This allows bio_integrity_bytes() to be called from drivers instead of open coding it. Acked-by: Martin K. Petersen Signed-off-by: Greg Edwards Signed-off-by: Jens Axboe [bwh: Backported to 3.16: bio_integrity_intervals() was called bio_integrity_hw_sectors() and had a different implementation. Move it without renaming.] Signed-off-by: Ben Hutchings commit 3090ef98dce0ade500bd2e6e71aa27db7efa3fb9 Author: Kirill Tkhai Date: Thu Jul 19 15:49:39 2018 +0300 fuse: Add missed unlock_page() to fuse_readpages_fill() commit 109728ccc5933151c68d1106e4065478a487a323 upstream. The above error path returns with page unlocked, so this place seems also to behave the same. Fixes: f8dbdf81821b ("fuse: rework fuse_readpages()") Signed-off-by: Kirill Tkhai Signed-off-by: Miklos Szeredi Signed-off-by: Ben Hutchings commit 2d74743c19298b69268e4a62c0e439d75c3010e4 Author: Andrey Ryabinin Date: Tue Jul 17 19:00:33 2018 +0300 fuse: Don't access pipe->buffers without pipe_lock() commit a2477b0e67c52f4364a47c3ad70902bc2a61bd4c upstream. fuse_dev_splice_write() reads pipe->buffers to determine the size of 'bufs' array before taking the pipe_lock(). This is not safe as another thread might change the 'pipe->buffers' between the allocation and taking the pipe_lock(). So we end up with too small 'bufs' array. Move the bufs allocations inside pipe_lock()/pipe_unlock() to fix this. Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device") Signed-off-by: Andrey Ryabinin Signed-off-by: Miklos Szeredi [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 84dd9744f4adb87b5a830b3097047a3f0099ccf5 Author: Miklos Szeredi Date: Thu Jul 26 16:13:11 2018 +0200 fuse: Fix oops at process_init_reply() commit e8f3bd773d22f488724dffb886a1618da85c2966 upstream. syzbot is hitting NULL pointer dereference at process_init_reply(). This is because deactivate_locked_super() is called before response for initial request is processed. Fix this by aborting and waiting for all requests (including FUSE_INIT) before resetting fc->sb. Original patch by Tetsuo Handa . Reported-by: syzbot Fixes: e27c9d3877a0 ("fuse: fuse: add time_gran to INIT_OUT") Signed-off-by: Miklos Szeredi [bwh: Backported to 3.16: - Drop second argument to fuse_abort_conn() - fuse_wait_aborted() is not needed] Signed-off-by: Ben Hutchings commit 779b6307f009684be663066d377504dce4cb58c7 Author: Miklos Szeredi Date: Fri Dec 12 09:49:04 2014 +0100 fuse: flush requests on umount commit 580640ba5d331eb5631a5de46941c98f5ed90886 upstream. Use fuse_abort_conn() instead of fuse_conn_kill() in fuse_put_super(). This flushes and aborts requests still on any queues. But since we've already reset fc->connected, those requests would not be useful anyway and would be flushed when the fuse device is closed. Next patches will rely on requests being flushed before the superblock is destroyed. Use fuse_abort_conn() in cuse_process_init_reply() too, since it makes no difference there, and we can get rid of fuse_conn_kill(). Signed-off-by: Miklos Szeredi Signed-off-by: Ben Hutchings commit 0ab98f5465a1b8155ab398d3cb39b05acc1d2035 Author: Miklos Szeredi Date: Fri Dec 12 09:49:04 2014 +0100 fuse: don't wake up reserved req in fuse_conn_kill() commit 0c4dd4ba1426c599072511dcf95a15ee5e12725b upstream. Waking up reserved_req_waitq from fuse_conn_kill() doesn't make sense since we aren't chaging ff->reserved_req here, which is what this waitqueue signals. Signed-off-by: Miklos Szeredi Signed-off-by: Ben Hutchings commit 7e9a97bc680f238b733470e1942154d0ff864c8d Author: Takashi Iwai Date: Wed Jul 25 17:59:26 2018 +0200 ALSA: cs5535audio: Fix invalid endian conversion commit 69756930f2de0457d51db7d505a1e4f40e9fd116 upstream. One place in cs5535audio_build_dma_packets() does an extra conversion via cpu_to_le32(); namely jmpprd_addr is passed to setup_prd() ops, which writes the value via cs_writel(). That is, the callback does the conversion by itself, and we don't need to convert beforehand. This patch fixes that bogus conversion. Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit c51e8e322b73de19513d6c97572a6e2a598d5ce9 Author: Takashi Iwai Date: Wed Jul 25 17:11:38 2018 +0200 ALSA: vxpocket: Fix invalid endian conversions commit 3acd3e3bab95ec3622ff98da313290ee823a0f68 upstream. The endian conversions used in vxp_dma_read() and vxp_dma_write() are superfluous and even wrong on big-endian machines, as inw() and outw() already do conversions. Kill them. Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit b2bc9005df253ea2b02f1937c8208a7a9af3644c Author: Takashi Iwai Date: Wed Jul 25 17:10:11 2018 +0200 ALSA: vx222: Fix invalid endian conversions commit fff71a4c050ba46e305d910c837b99ba1728135e upstream. The endian conversions used in vx2_dma_read() and vx2_dma_write() are superfluous and even wrong on big-endian machines, as inl() and outl() already do conversions. Kill them. Spotted by sparse, a warning like: sound/pci/vx222/vx222_ops.c:278:30: warning: incorrect type in argument 1 (different base types) Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 2ead590bbf852d94bc1c6aa25bfaf4f673da6ce5 Author: Takashi Iwai Date: Wed Jan 4 12:19:15 2017 +0100 ALSA: vx: Fix possible transfer overflow commit 874e1f6fad9a5184b67f4cee37c1335cd2cc5677 upstream. The pseudo DMA transfer codes in VX222 and VX-pocket driver have a slight bug where they check the buffer boundary wrongly, and may overflow. Also, the zero sample count might be handled badly for the playback (although it shouldn't happen in theory). This patch addresses these issues. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=141541 Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 1e5b77503cfd6fd633039d20ae22309777538c0f Author: Takashi Iwai Date: Wed Jul 25 16:34:12 2018 +0200 ALSA: seq: Fix poll() error return commit a49a71f6e25da2acc637fcd31e73debd96ca18f8 upstream. The sanity checks in ALSA sequencer and OSS sequencer emulation codes return falsely -ENXIO from poll callback. They should be EPOLLERR instead. This was caught thanks to the recent change to the return value. Signed-off-by: Takashi Iwai [bwh: Backported to 3.16: s/EPOLLERR/POLLERR/] Signed-off-by: Ben Hutchings commit ca3e7984c7c3bb2e92ceeaaaa49c75e76bd36914 Author: YueHaibing Date: Wed Jul 25 16:54:33 2018 +0800 xfrm: fix 'passing zero to ERR_PTR()' warning commit 934ffce1343f22ed5e2d0bd6da4440f4848074de upstream. Fix a static code checker warning: net/xfrm/xfrm_policy.c:1836 xfrm_resolve_and_create_bundle() warn: passing zero to 'ERR_PTR' xfrm_tmpl_resolve return 0 just means no xdst found, return NULL instead of passing zero to ERR_PTR. Fixes: d809ec895505 ("xfrm: do not assume that template resolving always returns xfrms") Signed-off-by: YueHaibing Signed-off-by: Steffen Klassert Signed-off-by: Ben Hutchings commit b512c468090995285becae095574417a13cd140b Author: Mikulas Patocka Date: Wed Jul 25 15:41:56 2018 +0200 udlfb: set line_length in dlfb_ops_set_par commit 0ac319b7af1bb24a33365d0ec82a2f56a59b2a78 upstream. Set the variable "line_length" in the function dlfb_ops_set_par. Without this, we get garbage if we select different videomode with fbset. Signed-off-by: Mikulas Patocka Signed-off-by: Bartlomiej Zolnierkiewicz [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit e1d6b8994184c2004cd9aa460dd84a7071d14468 Author: Mikulas Patocka Date: Wed Jul 25 15:41:56 2018 +0200 udlfb: handle allocation failure commit 080fb5240bdcabed7387b814139c3ea172d59fc5 upstream. Allocations larger than PAGE_ALLOC_COSTLY_ORDER are unreliable and they may fail anytime. This patch fixes the udlfb driver so that when a large alloactions fails, it tries to do multiple smaller allocations. Signed-off-by: Mikulas Patocka Signed-off-by: Bartlomiej Zolnierkiewicz [bwh: Backported to 3.16: - Pointers to struct dlfb_data are named "dev" rather than "dlfb" - Adjust context] Signed-off-by: Ben Hutchings commit ae0011e34b1b619b3ecd250405e1695de50f7162 Author: Mikulas Patocka Date: Wed Jul 25 15:41:55 2018 +0200 udlfb: set optimal write delay commit bb24153a3f13dd0dbc1f8055ad97fe346d598f66 upstream. The default delay 5 jiffies is too much when the kernel is compiled with HZ=100 - it results in jumpy cursor in Xwindow. In order to find out the optimal delay, I benchmarked the driver on 1280x720x30fps video. I found out that with HZ=1000, 10ms is acceptable, but with HZ=250 or HZ=300, we need 4ms, so that the video is played without any frame skips. This patch changes the delay to this value. Signed-off-by: Mikulas Patocka Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Ben Hutchings commit 2986bfce51d7edf380ebf358accde598d149fbf8 Author: Mikulas Patocka Date: Wed Jul 25 15:41:55 2018 +0200 udlfb: make a local copy of fb_ops commit 2c29cfc3eaf11779176bf41475cfca49bccba11c upstream. The defio subsystem overwrites the method fb_osp->mmap. That method is stored in module's static data - and that means that if we have multiple diplaylink adapters, they will over write each other's method. In order to avoid interference between multiple adapters, we copy the fb_ops structure to a device-local memory. Signed-off-by: Mikulas Patocka Signed-off-by: Bartlomiej Zolnierkiewicz [bwh: Backported to 3.16: Pointer to struct dlfb_data is named "dev" rather than "dlfb"] Signed-off-by: Ben Hutchings commit 1b29d4b71e820e1f68c031b819a7f828d8296ce3 Author: Mikulas Patocka Date: Wed Jul 25 15:41:55 2018 +0200 udlfb: don't switch if we are switching to the same videomode commit 564f1807379298dfdb12ed0d5b25fcb89c238527 upstream. The udlfb driver reprograms the hardware everytime the user switches the console, that makes quite unusable when working on the console. This patch makes the driver remember the videomode we are in and avoid reprogramming the hardware if we switch to the same videomode. We mask the "activate" field and the "FB_VMODE_SMOOTH_XPAN" flag when comparing the videomode, because they cause spurious switches when switching to and from the Xserver. Signed-off-by: Mikulas Patocka Signed-off-by: Bartlomiej Zolnierkiewicz [bwh: Backported to 3.16: Pointer to struct dlfb_data is named "dev" rather than "dlfb"] Signed-off-by: Ben Hutchings commit 7a202d95c7668c894a38bad5c63a5546ace9a3ae Author: Mikulas Patocka Date: Wed Jul 25 15:41:54 2018 +0200 udlfb: fix display corruption of the last line commit 4e705e17ce3409a1f492cfd5dadcf6a4f6075842 upstream. The displaylink hardware has such a peculiarity that it doesn't render a command until next command is received. This produces occasional corruption, such as when setting 22x11 font on the console, only the first line of the cursor will be blinking if the cursor is located at some specific columns. When we end up with a repeating pixel, the driver has a bug that it leaves one uninitialized byte after the command (and this byte is enough to flush the command and render it - thus it fixes the screen corruption), however whe we end up with a non-repeating pixel, there is no byte appended and this results in temporary screen corruption. This patch fixes the screen corruption by always appending a byte 0xAF at the end of URB. It also removes the uninitialized byte. Signed-off-by: Mikulas Patocka Signed-off-by: Bartlomiej Zolnierkiewicz [bwh: Backported to 3.16: - Pointers to struct dlfb_data are named "dev" rather than "dlfb" - s/BPP/bpp/ Signed-off-by: Ben Hutchings commit e121fd6cf61de56105ec013bc0f0449f78af4ca7 Author: Mikulas Patocka Date: Wed Jul 25 15:41:54 2018 +0200 udlfb: fix semaphore value leak commit 9d0aa601e4cd9c0892f90d36e8488d79b72f4073 upstream. I observed that the performance of the udl fb driver degrades over time. On a freshly booted machine, it takes 6 seconds to do "ls -la /usr/bin"; after some time of use, the same operation takes 14 seconds. The reason is that the value of "limit_sem" decays over time. The udl driver uses a semaphore "limit_set" to specify how many free urbs are there on dlfb->urbs.list. If the count is zero, the "down" operation will sleep until some urbs are added to the freelist. In order to avoid some hypothetical deadlock, the driver will not call "up" immediately, but it will offload it to a workqueue. The problem is that if we call "schedule_delayed_work" on the same work item multiple times, the work item may only be executed once. This is happening: * some urb completes * dlfb_urb_completion adds it to the free list * dlfb_urb_completion calls schedule_delayed_work to schedule the function dlfb_release_urb_work to increase the semaphore count * as the urb is on the free list, some other task grabs it and submits it * the submitted urb completes, dlfb_urb_completion is called again * dlfb_urb_completion calls schedule_delayed_work, but the work is already scheduled, so it does nothing * finally, dlfb_release_urb_work is called, it increases the semaphore count by 1, although it should increase it by 2 So, the semaphore count is decreasing over time, and this causes gradual performance degradation. Note that in the current kernel, the "up" function may be called from interrupt and it may race with the "down" function called by another thread, so we don't have to offload the call of "up" to a workqueue at all. This patch removes the workqueue code. The patch also changes "down_interruptible" to "down" in dlfb_free_urb_list, so that we will clean up the driver properly even if a signal arrives. With this patch, the performance of udlfb no longer degrades. Signed-off-by: Mikulas Patocka [b.zolnierkie: fix immediatelly -> immediately typo] Signed-off-by: Bartlomiej Zolnierkiewicz [bwh: Backported to 3.16: Pointers to struct dlfb_data are named "dev" rather than "dlfb"] Signed-off-by: Ben Hutchings commit 92d15f40cbb413e8e19ebc709ff3b6473d1de262 Author: Ladislav Michl Date: Mon Mar 12 17:06:53 2018 +0100 video: udlfb: Fix unaligned access commit 115e77597efcc94cb1f6cbb7df5cf7ce8feb8632 upstream. Driver generates lots of alignment trap exceptions on ARM. Fix that by replacing typecasting of odd addresses with byte shifting and remove uneccessary typecasting. Signed-off-by: Ladislav Michl Cc: Bernie Thompson Signed-off-by: Bartlomiej Zolnierkiewicz [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 82d975fad02822493d3aeae56e144d1d99c8f9ad Author: Ladislav Michl Date: Mon Jan 15 17:04:22 2018 +0100 video: udlfb: Remove noisy warnings commit de4b74bda8e87a4ed45ebc2c26cc3e2eaae38429 upstream. These warnings comes from times of driver development and do not carry any usefull debugging information. Signed-off-by: Ladislav Michl Cc: Bernie Thompson Signed-off-by: Bartlomiej Zolnierkiewicz [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 539485a9af3c7009a5399f8cff51563b22a4e928 Author: Mikulas Patocka Date: Wed Jul 25 15:41:54 2018 +0200 fb: fix lost console when the user unplugs a USB adapter commit 8c5b044299951acd91e830a688dd920477ea1eda upstream. I have a USB display adapter using the udlfb driver and I use it on an ARM board that doesn't have any graphics card. When I plug the adapter in, the console is properly displayed, however when I unplug and re-plug the adapter, the console is not displayed and I can't access it until I reboot the board. The reason is this: When the adapter is unplugged, dlfb_usb_disconnect calls unlink_framebuffer, then it waits until the reference count drops to zero and then it deallocates the framebuffer. However, the console that is attached to the framebuffer device keeps the reference count non-zero, so the framebuffer device is never destroyed. When the USB adapter is plugged again, it creates a new device /dev/fb1 and the console is not attached to it. This patch fixes the bug by unbinding the console from unlink_framebuffer. The code to unbind the console is moved from do_unregister_framebuffer to a function unbind_console. When the console is unbound, the reference count drops to zero and the udlfb driver frees the framebuffer. When the adapter is plugged back, a new framebuffer is created and the console is attached to it. Signed-off-by: Mikulas Patocka Cc: Dave Airlie Cc: Bernie Thompson Cc: Ladislav Michl [b.zolnierkie: preserve old behavior for do_unregister_framebuffer()] Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Ben Hutchings commit f4ad34c7ecaa299f8478a6f220e9ef5474ae835b Author: Lars-Peter Clausen Date: Mon Jun 25 11:03:07 2018 +0300 iio: ad9523: Fix displayed phase commit 5a4e33c1c53ae7d4425f7d94e60e4458a37b349e upstream. Fix the displayed phase for the ad9523 driver. Currently the most significant decimal place is dropped and all other digits are shifted one to the left. This is due to a multiplication by 10, which is not necessary, so remove it. Signed-off-by: Lars-Peter Clausen Signed-off-by: Alexandru Ardelean Fixes: cd1678f9632 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator") Signed-off-by: Jonathan Cameron Signed-off-by: Ben Hutchings commit 9ba687a9f8686a9658ba106f7240789a4c2a920f Author: Dan Carpenter Date: Tue Jul 24 19:11:28 2018 +0200 fbdev: omapfb: off by one in omapfb_register_client() commit 5ec1ec35b2979b59d0b33381e7c9aac17e159d16 upstream. The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the > should be >= or we are one element beyond the end of the array. Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver") Signed-off-by: Dan Carpenter Cc: Imre Deak Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Ben Hutchings commit c28c5c78a887306c8d7cbe863766790bbfb13b2f Author: Lukas Wunner Date: Thu Jul 19 17:27:34 2018 -0500 PCI: pciehp: Fix unprotected list iteration in IRQ handler commit 1204e35bedf4e5015cda559ed8c84789a6dae24e upstream. Commit b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device") iterates over the devices on a hotplug port's subordinate bus in pciehp's IRQ handler without acquiring pci_bus_sem. It is thus possible for a user to cause a crash by concurrently manipulating the device list, e.g. by disabling slot power via sysfs on a different CPU or by initiating a remove/rescan via sysfs. This can't be fixed by acquiring pci_bus_sem because it may sleep. The simplest fix is to avoid the list iteration altogether and just check the ignore_hotplug flag on the port itself. This works because pci_ignore_hotplug() sets the flag both on the device as well as on its parent bridge. We do lose the ability to print the name of the device blocking hotplug in the debug message, but that's probably bearable. Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device") Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas [bwh: Backported to 3.16: s/events/intr_loc/] Signed-off-by: Ben Hutchings commit 848daaa8493f7501095d7099715d299a84d4e443 Author: Lukas Wunner Date: Thu Jul 19 17:27:32 2018 -0500 PCI: pciehp: Fix use-after-free on unplug commit 281e878eab191cce4259abbbf1a0322e3adae02c upstream. When pciehp is unbound (e.g. on unplug of a Thunderbolt device), the hotplug_slot struct is deregistered and thus freed before freeing the IRQ. The IRQ handler and the work items it schedules print the slot name referenced from the freed structure in various informational and debug log messages, each time resulting in a quadruple dereference of freed pointers (hotplug_slot -> pci_slot -> kobject -> name). At best the slot name is logged as "(null)", at worst kernel memory is exposed in logs or the driver crashes: pciehp 0000:10:00.0:pcie204: Slot((null)): Card not present An attacker may provoke the bug by unplugging multiple devices on a Thunderbolt daisy chain at once. Unplugging can also be simulated by powering down slots via sysfs. The bug is particularly easy to trigger in poll mode. It has been present since the driver's introduction in 2004: https://git.kernel.org/tglx/history/c/c16b4b14d980 Fix by rearranging teardown such that the IRQ is freed first. Run the work items queued by the IRQ handler to completion before freeing the hotplug_slot struct by draining the work queue from the ->release_slot callback which is invoked by pci_hp_deregister(). Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 1fa3ed6898b12091e3dffaf591031031f9fec048 Author: Lukas Wunner Date: Thu Jul 19 17:27:31 2018 -0500 PCI: hotplug: Don't leak pci_slot on registration failure commit 4ce6435820d1f1cc2c2788e232735eb244bcc8a3 upstream. If addition of sysfs files fails on registration of a hotplug slot, the struct pci_slot as well as the entry in the slot_list is leaked. The issue has been present since the hotplug core was introduced in 2002: https://git.kernel.org/tglx/history/c/a8a2069f432c Perhaps the idea was that even though sysfs addition fails, the slot should still be usable. But that's not how drivers use the interface, they abort probe if a non-zero value is returned. Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Cc: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit d92bb9a9dc3865f222e0c934a893cb63ac14c372 Author: Huacai Chen Date: Fri Jul 13 15:37:57 2018 +0800 MIPS: Change definition of cpu_relax() for Loongson-3 commit a30718868915fbb991a9ae9e45594b059f28e9ae upstream. Linux expects that if a CPU modifies a memory location, then that modification will eventually become visible to other CPUs in the system. Loongson 3 CPUs include a Store Fill Buffer (SFB) which sits between a core & its L1 data cache, queueing memory accesses & allowing for faster forwarding of data from pending stores to younger loads from the core. Unfortunately the SFB prioritizes loads such that a continuous stream of loads may cause a pending write to be buffered indefinitely. This is problematic if we end up with 2 CPUs which each perform a store that the other polls for - one or both CPUs may end up with their stores buffered in the SFB, never reaching cache due to the continuous reads from the poll loop. Such a deadlock condition has been observed whilst running qspinlock code. This patch changes the definition of cpu_relax() to smp_mb() for Loongson-3, forcing a flush of the SFB on SMP systems which will cause any pending writes to make it as far as the L1 caches where they will become visible to other CPUs. If the kernel is not compiled for SMP support, this will expand to a barrier() as before. This workaround matches that currently implemented for ARM when CONFIG_ARM_ERRATA_754327=y, which was introduced by commit 534be1d5a2da ("ARM: 6194/1: change definition of cpu_relax() for ARM11MPCore"). Although the workaround is only required when the Loongson 3 SFB functionality is enabled, and we only began explicitly enabling that functionality in v4.7 with commit 1e820da3c9af ("MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT"), existing or future firmware may enable the SFB which means we may need the workaround backported to earlier kernels too. [paul.burton@mips.com: - Reword commit message & comment. - Limit stable backport to v3.15+ where we support Loongson 3 CPUs.] Signed-off-by: Huacai Chen Signed-off-by: Paul Burton References: 534be1d5a2da ("ARM: 6194/1: change definition of cpu_relax() for ARM11MPCore") References: 1e820da3c9af ("MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT") Patchwork: https://patchwork.linux-mips.org/patch/19830/ Cc: Ralf Baechle Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: Huacai Chen Signed-off-by: Ben Hutchings commit 2b5854033f68ad312522f8b0fc820fa453a34bdf Author: Takashi Iwai Date: Thu Jul 19 11:01:04 2018 +0200 ALSA: memalloc: Don't exceed over the requested size commit dfef01e150824b0e6da750cacda8958188d29aea upstream. snd_dma_alloc_pages_fallback() tries to allocate pages again when the allocation fails with reduced size. But the first try actually *increases* the size to power-of-two, which may give back a larger chunk than the requested size. This confuses the callers, e.g. sgbuf assumes that the size is equal or less, and it may result in a bad loop due to the underflow and eventually lead to Oops. The code of this function seems incorrectly assuming the usage of get_order(). We need to decrease at first, then align to power-of-two. Reported-and-tested-by: he, bo Reported-by: zhang jun Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 4baf01b6d3c8213aff1df698ec0bf8de25feb7af Author: Vitaly Kuznetsov Date: Fri Jul 20 18:33:59 2018 +0200 xen-netfront: fix queue name setting commit 2d408c0d4574b01b9ed45e02516888bf925e11a9 upstream. Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and open") changed the initialization order: xennet_create_queues() now happens before we do register_netdev() so using netdev->name in xennet_init_queue() is incorrect, we end up with the following in /proc/interrupts: 60: 139 0 xen-dyn -event eth%d-q0-tx 61: 265 0 xen-dyn -event eth%d-q0-rx 62: 234 0 xen-dyn -event eth%d-q1-tx 63: 1 0 xen-dyn -event eth%d-q1-rx and this looks ugly. Actually, using early netdev name (even when it's already set) is also not ideal: nowadays we tend to rename eth devices and queue name may end up not corresponding to the netdev name. Use nodename from xenbus device for queue naming: this can't change in VM's lifetime. Now /proc/interrupts looks like 62: 202 0 xen-dyn -event device/vif/0-q0-tx 63: 317 0 xen-dyn -event device/vif/0-q0-rx 64: 262 0 xen-dyn -event device/vif/0-q1-tx 65: 17 0 xen-dyn -event device/vif/0-q1-rx Fixes: f599c64fdf7d ("xen-netfront: Fix race between device setup and open") Signed-off-by: Vitaly Kuznetsov Reviewed-by: Ross Lagerwall Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2c25bea357380b811d35c33ad38da91b4902b558 Author: Maciej W. Rozycki Date: Tue May 15 23:33:26 2018 +0100 MIPS: Correct the 64-bit DSP accumulator register size commit f5958b4cf4fc38ed4583ab83fb7c4cd1ab05f47b upstream. Use the `unsigned long' rather than `__u32' type for DSP accumulator registers, like with the regular MIPS multiply/divide accumulator and general-purpose registers, as all are 64-bit in 64-bit implementations and using a 32-bit data type leads to contents truncation on context saving. Update `arch_ptrace' and `compat_arch_ptrace' accordingly, removing casts that are similarly not used with multiply/divide accumulator or general-purpose register accesses. Signed-off-by: Maciej W. Rozycki Signed-off-by: Paul Burton Fixes: e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.") Patchwork: https://patchwork.linux-mips.org/patch/19329/ Cc: Alexander Viro Cc: James Hogan Cc: Ralf Baechle Cc: linux-fsdevel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ben Hutchings commit d1d36225c7685da1c43f5e70e496becb1bd99094 Author: Maciej W. Rozycki Date: Tue May 15 23:32:45 2018 +0100 binfmt_elf: Respect error return from `regset->active' commit 2f819db565e82e5f73cd42b39925098986693378 upstream. The regset API documented in defines -ENODEV as the result of the `->active' handler to be used where the feature requested is not available on the hardware found. However code handling core file note generation in `fill_thread_core_info' interpretes any non-zero result from the `->active' handler as the regset requested being active. Consequently processing continues (and hopefully gracefully fails later on) rather than being abandoned right away for the regset requested. Fix the problem then by making the code proceed only if a positive result is returned from the `->active' handler. Signed-off-by: Maciej W. Rozycki Signed-off-by: Paul Burton Fixes: 4206d3aa1978 ("elf core dump: notes user_regset") Patchwork: https://patchwork.linux-mips.org/patch/19332/ Cc: Alexander Viro Cc: James Hogan Cc: Ralf Baechle Cc: linux-fsdevel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ben Hutchings commit 1dead6b0b9c9f368aab74d042bd76646e3c8abc2 Author: Jann Horn Date: Sat Jul 7 05:37:22 2018 +0200 mtdchar: fix overflows in adjustment of `count` commit 6c6bc9ea84d0008024606bf5ba10519e20d851bf upstream. The first checks in mtdchar_read() and mtdchar_write() attempt to limit `count` such that `*ppos + count <= mtd->size`. However, they ignore the possibility of `*ppos > mtd->size`, allowing the calculation of `count` to wrap around. `mtdchar_lseek()` prevents seeking beyond mtd->size, but the pread/pwrite syscalls bypass this. I haven't found any codepath on which this actually causes dangerous behavior, but it seems like a sensible change anyway. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jann Horn Signed-off-by: Boris Brezillon Signed-off-by: Ben Hutchings commit b0a3a2f97c9308501eedb7715a0589b38ad344b3 Author: Martin Kaiser Date: Wed Jun 27 22:47:44 2018 +0200 mtd: rawnand: mxc: remove __init qualifier from mxcnd_probe_dt commit 24f0ae995deb728076e3ea93fea1949a9775debf upstream. Using the sysfs unbind, bind nodes, mxcnd_probe and mxcnd_probe_dt can potentially be called at any time. After the __init functions are cleaned, mxcnd_probe_dt is no longer available. Calling it anyway causes a crash. mxcnd_probe used to be marked as __init, this was removed years ago. Remove the __init qualifier from from mxcnd_probe_dt as well. Fixes: 06f255106923 ("mtd: remove use of __devinit") Signed-off-by: Martin Kaiser Reviewed-by: Boris Brezillon Signed-off-by: Miquel Raynal [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit a4d1b4a0862b140c6f21e5ffce784908873841ee Author: Nicholas Mc Guire Date: Thu Jul 12 11:28:24 2018 +0200 ARM: hisi: handle of_iomap and fix missing of_node_put commit d396cb185c0337aae5664b250cdd9a73f6eb1503 upstream. Relying on an unchecked of_iomap() which can return NULL is problematic here, an explicit check seems mandatory. Also the call to of_find_compatible_node() returns a device node with refcount incremented therefor an explicit of_node_put() is needed here. Signed-off-by: Nicholas Mc Guire Fixes: commit 22bae4290457 ("ARM: hi3xxx: add hotplug support") Signed-off-by: Wei Xu Signed-off-by: Ben Hutchings commit be1a6d7d10f4706c848abea02c2d080609a5e8f3 Author: Claudio Imbrenda Date: Mon Jul 16 10:38:57 2018 +0200 s390/kvm: fix deadlock when killed by oom commit 306d6c49ac9ded11114cb53b0925da52f2c2ada1 upstream. When the oom killer kills a userspace process in the page fault handler while in guest context, the fault handler fails to release the mm_sem if the FAULT_FLAG_RETRY_NOWAIT option is set. This leads to a deadlock when tearing down the mm when the process terminates. This bug can only happen when pfault is enabled, so only KVM clients are affected. The problem arises in the rare cases in which handle_mm_fault does not release the mm_sem. This patch fixes the issue by manually releasing the mm_sem when needed. Fixes: 24eb3a824c4f3 ("KVM: s390: Add FAULT_FLAG_RETRY_NOWAIT for guest fault") Signed-off-by: Claudio Imbrenda Signed-off-by: Martin Schwidefsky Signed-off-by: Ben Hutchings commit b106483b4a080048f3e811a9d4edcd34f576317b Author: Johan Hovold Date: Sun Jul 15 15:39:34 2018 +0200 tty: fix termios input-speed encoding when using BOTHER commit 1cee38f0363a88db374e50b232ca17b9a4c12fa0 upstream. When the termios CIBAUD bits are left unset (i.e. B0), we use the same output and input speed and should leave CIBAUD unchanged. When the user requests a rate using BOTHER and c_ospeed which the driver cannot set exactly, the driver can report back the actual baud rate using tty_termios_encode_baud_rate(). If this rate is close enough to a standard rate however, we could end up setting CIBAUD to a Bfoo value despite the user having left it unset. This in turn could lead to an unexpected input rate being set on subsequent termios updates. Fix this by using a zero tolerance value also for the input rate when CIBAUD is clear so that the matching logic works as expected. Fixes: 78137e3b34e1 ("[PATCH] tty: improve encode_baud_rate logic") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 99183227ce0624edc5a4aaf9f8f4e6b071f557d2 Author: Johan Hovold Date: Sun Jul 15 15:39:33 2018 +0200 tty: fix termios input-speed encoding commit fada18c48d774b9e837928ecdce6a5d5fdd11ee7 upstream. Make sure to clear the CIBAUD bits before OR-ing the new mask when encoding the termios input baud rate. This could otherwise lead to an incorrect input rate being reported back and incidentally set on subsequent termios updates. Fixes: edc6afc54968 ("[PATCH] tty: switch to ktermios and new framework") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 0247466190be2280506b94ddc53ab0b086f1ba26 Author: Matthias Brugger Date: Fri Aug 8 13:01:21 2014 +0200 tty: fix typo in comment of tty_termios_encode_baud_rate commit a1d51aa2214cea3f91611893610a2f769cada0e7 upstream. Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 3015158b088e8b6a7f0eecc5f9d6e2960ea9a59a Author: Tycho Andersen Date: Fri Jul 6 10:24:57 2018 -0600 uart: fix race between uart_put_char() and uart_shutdown() commit a5ba1d95e46ecaea638ddd7cd144107c783acb5d upstream. We have reports of the following crash: PID: 7 TASK: ffff88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0" #0 [ffff88085c6db710] machine_kexec at ffffffff81046239 #1 [ffff88085c6db760] crash_kexec at ffffffff810fc248 #2 [ffff88085c6db830] oops_end at ffffffff81008ae7 #3 [ffff88085c6db860] no_context at ffffffff81050b8f #4 [ffff88085c6db8b0] __bad_area_nosemaphore at ffffffff81050d75 #5 [ffff88085c6db900] bad_area_nosemaphore at ffffffff81050e83 #6 [ffff88085c6db910] __do_page_fault at ffffffff8105132e #7 [ffff88085c6db9b0] do_page_fault at ffffffff8105152c #8 [ffff88085c6db9c0] page_fault at ffffffff81a3f122 [exception RIP: uart_put_char+149] RIP: ffffffff814b67b5 RSP: ffff88085c6dba78 RFLAGS: 00010006 RAX: 0000000000000292 RBX: ffffffff827c5120 RCX: 0000000000000081 RDX: 0000000000000000 RSI: 000000000000005f RDI: ffffffff827c5120 RBP: ffff88085c6dba98 R8: 000000000000012c R9: ffffffff822ea320 R10: ffff88085fe4db04 R11: 0000000000000001 R12: ffff881059f9c000 R13: 0000000000000001 R14: 000000000000005f R15: 0000000000000fba ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #9 [ffff88085c6dbaa0] tty_put_char at ffffffff81497544 #10 [ffff88085c6dbac0] do_output_char at ffffffff8149c91c #11 [ffff88085c6dbae0] __process_echoes at ffffffff8149cb8b #12 [ffff88085c6dbb30] commit_echoes at ffffffff8149cdc2 #13 [ffff88085c6dbb60] n_tty_receive_buf_fast at ffffffff8149e49b #14 [ffff88085c6dbbc0] __receive_buf at ffffffff8149ef5a #15 [ffff88085c6dbc20] n_tty_receive_buf_common at ffffffff8149f016 #16 [ffff88085c6dbca0] n_tty_receive_buf2 at ffffffff8149f194 #17 [ffff88085c6dbcb0] flush_to_ldisc at ffffffff814a238a #18 [ffff88085c6dbd50] process_one_work at ffffffff81090be2 #19 [ffff88085c6dbe20] worker_thread at ffffffff81091b4d #20 [ffff88085c6dbeb0] kthread at ffffffff81096384 #21 [ffff88085c6dbf50] ret_from_fork at ffffffff81a3d69f​ after slogging through some dissasembly: ffffffff814b6720 : ffffffff814b6720: 55 push %rbp ffffffff814b6721: 48 89 e5 mov %rsp,%rbp ffffffff814b6724: 48 83 ec 20 sub $0x20,%rsp ffffffff814b6728: 48 89 1c 24 mov %rbx,(%rsp) ffffffff814b672c: 4c 89 64 24 08 mov %r12,0x8(%rsp) ffffffff814b6731: 4c 89 6c 24 10 mov %r13,0x10(%rsp) ffffffff814b6736: 4c 89 74 24 18 mov %r14,0x18(%rsp) ffffffff814b673b: e8 b0 8e 58 00 callq ffffffff81a3f5f0 ffffffff814b6740: 4c 8b a7 88 02 00 00 mov 0x288(%rdi),%r12 ffffffff814b6747: 45 31 ed xor %r13d,%r13d ffffffff814b674a: 41 89 f6 mov %esi,%r14d ffffffff814b674d: 49 83 bc 24 70 01 00 cmpq $0x0,0x170(%r12) ffffffff814b6754: 00 00 ffffffff814b6756: 49 8b 9c 24 80 01 00 mov 0x180(%r12),%rbx ffffffff814b675d: 00 ffffffff814b675e: 74 2f je ffffffff814b678f ffffffff814b6760: 48 89 df mov %rbx,%rdi ffffffff814b6763: e8 a8 67 58 00 callq ffffffff81a3cf10 <_raw_spin_lock_irqsave> ffffffff814b6768: 41 8b 8c 24 78 01 00 mov 0x178(%r12),%ecx ffffffff814b676f: 00 ffffffff814b6770: 89 ca mov %ecx,%edx ffffffff814b6772: f7 d2 not %edx ffffffff814b6774: 41 03 94 24 7c 01 00 add 0x17c(%r12),%edx ffffffff814b677b: 00 ffffffff814b677c: 81 e2 ff 0f 00 00 and $0xfff,%edx ffffffff814b6782: 75 23 jne ffffffff814b67a7 ffffffff814b6784: 48 89 c6 mov %rax,%rsi ffffffff814b6787: 48 89 df mov %rbx,%rdi ffffffff814b678a: e8 e1 64 58 00 callq ffffffff81a3cc70 <_raw_spin_unlock_irqrestore> ffffffff814b678f: 44 89 e8 mov %r13d,%eax ffffffff814b6792: 48 8b 1c 24 mov (%rsp),%rbx ffffffff814b6796: 4c 8b 64 24 08 mov 0x8(%rsp),%r12 ffffffff814b679b: 4c 8b 6c 24 10 mov 0x10(%rsp),%r13 ffffffff814b67a0: 4c 8b 74 24 18 mov 0x18(%rsp),%r14 ffffffff814b67a5: c9 leaveq ffffffff814b67a6: c3 retq ffffffff814b67a7: 49 8b 94 24 70 01 00 mov 0x170(%r12),%rdx ffffffff814b67ae: 00 ffffffff814b67af: 48 63 c9 movslq %ecx,%rcx ffffffff814b67b2: 41 b5 01 mov $0x1,%r13b ffffffff814b67b5: 44 88 34 0a mov %r14b,(%rdx,%rcx,1) ffffffff814b67b9: 41 8b 94 24 78 01 00 mov 0x178(%r12),%edx ffffffff814b67c0: 00 ffffffff814b67c1: 83 c2 01 add $0x1,%edx ffffffff814b67c4: 81 e2 ff 0f 00 00 and $0xfff,%edx ffffffff814b67ca: 41 89 94 24 78 01 00 mov %edx,0x178(%r12) ffffffff814b67d1: 00 ffffffff814b67d2: eb b0 jmp ffffffff814b6784 ffffffff814b67d4: 66 66 66 2e 0f 1f 84 data32 data32 nopw %cs:0x0(%rax,%rax,1) ffffffff814b67db: 00 00 00 00 00 for our build, this is crashing at: circ->buf[circ->head] = c; Looking in uart_port_startup(), it seems that circ->buf (state->xmit.buf) protected by the "per-port mutex", which based on uart_port_check() is state->port.mutex. Indeed, the lock acquired in uart_put_char() is uport->lock, i.e. not the same lock. Anyway, since the lock is not acquired, if uart_shutdown() is called, the last chunk of that function may release state->xmit.buf before its assigned to null, and cause the race above. To fix it, let's lock uport->lock when allocating/deallocating state->xmit.buf in addition to the per-port mutex. v2: switch to locking uport->lock on allocation/deallocation instead of locking the per-port mutex in uart_put_char. Note that since uport->lock is a spin lock, we have to switch the allocation to GFP_ATOMIC. v3: move the allocation outside the lock, so we can switch back to GFP_KERNEL Signed-off-by: Tycho Andersen Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: Use uport->lock directly rather than through uart_port_{,un}lock()] Signed-off-by: Ben Hutchings commit 5d5a6ad948ca9f5f601dc73c63cee75d681e7cfa Author: Dan Carpenter Date: Wed Jul 11 15:29:31 2018 +0300 mei: bus: type promotion bug in mei_nfc_if_version() commit b40b3e9358fbafff6a4ba0f4b9658f6617146f9c upstream. We accidentally removed the check for negative returns without considering the issue of type promotion. The "if_version_length" variable is type size_t so if __mei_cl_recv() returns a negative then "bytes_recv" is type promoted to a high positive value and treated as success. Fixes: 582ab27a063a ("mei: bus: fix received data size check in NFC fixup") Signed-off-by: Dan Carpenter Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit acb9ef02c3b0e6222d5686aee4728eb2ab565857 Author: Dan Carpenter Date: Wed Jul 4 12:38:09 2018 +0300 drm/panel: type promotion bug in s6e8aa0_read_mtp_id() commit cd0e0ca69109d025b1a1b6609f70682db62138b0 upstream. The ARRAY_SIZE() macro is type size_t. If s6e8aa0_dcs_read() returns a negative error code, then "ret < ARRAY_SIZE(id)" is false because the negative error code is type promoted to a high positive value. Fixes: 02051ca06371 ("drm/panel: add S6E8AA0 driver") Signed-off-by: Dan Carpenter Reviewed-by: Andrzej Hajda Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20180704093807.s3lqsb2v6dg2k43d@kili.mountain [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit 52a5924326b557c75ef0d3c1e675c749906a6aa0 Author: Vignesh R Date: Mon Jun 11 11:39:56 2018 +0530 pwm: tiehrpwm: Fix disabling of output of PWMs commit 38dabd91ff0bde33352ca3cc65ef515599b77a05 upstream. pwm-tiehrpwm driver disables PWM output by putting it in low output state via active AQCSFRC register in ehrpwm_pwm_disable(). But, the AQCSFRC shadow register is not updated. Therefore, when shadow AQCSFRC register is re-enabled in ehrpwm_pwm_enable() (say to enable second PWM output), previous settings are lost as shadow register value is loaded into active register. This results in things like PWMA getting enabled automatically, when PWMB is enabled and vice versa. Fix this by updating AQCSFRC shadow register as well during ehrpwm_pwm_disable(). Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Signed-off-by: Vignesh R Signed-off-by: Thierry Reding Signed-off-by: Ben Hutchings commit 02f808052bdabf6b7ea1a44b7d81d018c9b65028 Author: Vignesh R Date: Mon Jun 11 11:39:55 2018 +0530 pwm: tiehrpwm: Don't use emulation mode bits to control PWM output commit aa49d628f6e016bcec8c6f8e704b9b18ee697329 upstream. As per AM335x TRM SPRUH73P "15.2.2.11 ePWM Behavior During Emulation", TBCTL[15:14] only have effect during emulation suspend events (IOW, to stop PWM when debugging using a debugger). These bits have no effect on PWM output during normal running of system. Hence, remove code accessing these bits as they have no role in enabling/disabling PWMs. Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM") Signed-off-by: Vignesh R Signed-off-by: Thierry Reding [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 0e3db9f650a6f6fdba17e6da378d0cbacb40d20b Author: Jon Hunter Date: Tue Jul 3 09:59:47 2018 +0100 ARM: tegra: Fix Tegra30 Cardhu PCA954x reset commit 6e1811900b6fe6f2b4665dba6bd6ed32c6b98575 upstream. On all versions of Tegra30 Cardhu, the reset signal to the NXP PCA9546 I2C mux is connected to the Tegra GPIO BB0. Currently, this pin on the Tegra is not configured as a GPIO but as a special-function IO (SFIO) that is multiplexing the pin to an I2S controller. On exiting system suspend, I2C commands sent to the PCA9546 are failing because there is no ACK. Although it is not possible to see exactly what is happening to the reset during suspend, by ensuring it is configured as a GPIO and driven high, to de-assert the reset, the failures are no longer seen. Please note that this GPIO is also used to drive the reset signal going to the camera connector on the board. However, given that there is no camera support currently for Cardhu, this should not have any impact. Fixes: 40431d16ff11 ("ARM: tegra: enable PCA9546 on Cardhu") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Ben Hutchings commit e1d88c70284398e15e3a1994768624f1aacc2615 Author: Douglas Anderson Date: Mon Jul 2 15:59:38 2018 -0700 pinctrl: msm: Fix msm_config_group_get() to be compliant commit 05e0c828955c1cab58dd71a04539442e5375d917 upstream. If you do this on an sdm845 board: cat /sys/kernel/debug/pinctrl/3400000.pinctrl/pinconf-groups ...it looks like nonsense. For every pin you see listed: input bias bus hold, input bias disabled, input bias pull down, input bias pull up That's because msm_config_group_get() isn't complying with the rules that pinconf_generic_dump_one() expects. Specifically for boolean parameters (anything with a "struct pin_config_item" where has_arg is false) the function expects that the function should return its value not through the "config" parameter but should return "0" if the value is set and "-EINVAL" if the value isn't set. Let's fix this. From a quick sample of other pinctrl drivers, it appears to be tradition to also return 1 through the config parameter for these boolean parameters when they exist. I'm not one to knock tradition, so I'll follow tradition and return 1 in these cases. While I'm at it, I'll also continue searching for four leaf clovers, kocking on wood three times, and trying not to break mirrors. Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver") Signed-off-by: Douglas Anderson Signed-off-by: Linus Walleij [bwh: Backported to 3.16: - Drop change to case PIN_CONFIG_BIAS_BUS_HOLD - Adjust filename, context] Signed-off-by: Ben Hutchings commit 57a7debcebba9afb6b49967f6c954e8f8771161c Author: Dan Carpenter Date: Wed Jul 4 12:33:34 2018 +0300 vmci: type promotion bug in qp_host_get_user_memory() commit 7fb2fd4e25fc1fb10dcb30b5519de257cfeae84c upstream. The problem is that if get_user_pages_fast() fails and returns a negative error code, it gets type promoted to a high positive value and treated as a success. Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit fe60b182095d808b0b38f89e829b86057636a43d Author: Roopa Prabhu Date: Wed Jul 4 16:46:32 2018 -0700 vxlan: fix default fdb entry netlink notify ordering during netdev create commit 0241b836732f5f43c3f0fd9e9073c1fb24ea6757 upstream. Problem: In vxlan_newlink, a default fdb entry is added before register_netdev. The default fdb creation function also notifies user-space of the fdb entry on the vxlan device which user-space does not know about yet. (RTM_NEWNEIGH goes before RTM_NEWLINK for the same ifindex). This patch fixes the user-space netlink notification ordering issue with the following changes: - decouple fdb notify from fdb create. - Move fdb notify after register_netdev. - Call rtnl_configure_link in vxlan newlink handler to notify userspace about the newlink before fdb notify and hence avoiding the user-space race. Fixes: afbd8bae9c79 ("vxlan: add implicit fdb entry for default destination") Signed-off-by: Roopa Prabhu Signed-off-by: David S. Miller [bwh: Backported to 3.16: - Drop changes to vxlan_changelink() - Drop last argument to vxlan_fdb_destroy() - Adjust context] Signed-off-by: Ben Hutchings commit 3c5cc4a8a32af86c7464f1d3c8fd84fc69e9e021 Author: Roopa Prabhu Date: Wed Jul 4 16:46:30 2018 -0700 vxlan: add new fdb alloc and create helpers commit 25e20e730d56471cffa25419bf2a66078bd55330 upstream. - Add new vxlan_fdb_alloc helper - rename existing vxlan_fdb_create into vxlan_fdb_update: because it really creates or updates an existing fdb entry - move new fdb creation into a separate vxlan_fdb_create Main motivation for this change is to introduce the ability to decouple vxlan fdb creation and notify, used in a later patch. Signed-off-by: Roopa Prabhu Signed-off-by: David S. Miller [bwh: Backported to 3.16: - s/vxlan->cfg\.addrmax/vxlan->addrmax/g - Drop src_vni parameters and initialisation of vxlan_fdb::vni - Drop last argument to vxlan_fdb_head() - Drop change to vxlan_changelink()] Signed-off-by: Ben Hutchings commit 189d83e81aaa267f9c4fc4256e2f628c220ea607 Author: Haishuang Yan Date: Tue Nov 29 09:59:36 2016 +0800 vxlan: fix a potential issue when create a new vxlan fdb entry. commit 17b463654f41f0aa334efd5a6efeab8a6e9496f7 upstream. vxlan_fdb_append may return error, so add the proper check, otherwise it will cause memory leak. Signed-off-by: Haishuang Yan Changes in v2: - Unnecessary to initialize rc to zero. Acked-by: Jiri Benc Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 51e9753f79f894885100ad6d6991a67d07f975a2 Author: H. Nikolaus Schaller Date: Tue Jun 26 15:28:30 2018 +0200 power: generic-adc-battery: check for duplicate properties copied from iio channels commit a427503edaaed9b75ed9746a654cece7e93e60a8 upstream. If an iio channel defines a basic property, there are duplicate entries in /sys/class/power/*/uevent. So add a check to avoid duplicates. Since all channels may be duplicates, we have to modify the related error check. Signed-off-by: H. Nikolaus Schaller Fixes: e60fea794e6e ("power: battery: Generic battery driver using IIO") Signed-off-by: Sebastian Reichel [bwh: Backported to 3.16: - s/psy_desc/psy/ - Adjust filename] Signed-off-by: Ben Hutchings commit 640fbee0b753fb2ce9f30115230430f03678a13c Author: H. Nikolaus Schaller Date: Tue Jun 26 15:28:29 2018 +0200 power: generic-adc-battery: fix out-of-bounds write when copying channel properties commit 932d47448c3caa0fa99e84d7f5bc302aa286efd8 upstream. We did have sporadic problems in the pinctrl framework during boot where a pin group name unexpectedly became NULL leading to a NULL dereference in strcmp. Detailled analysis of the failing cases did reveal that there were two devm allocated objects close to each other. The second one was the affected group_desc in pinmux and the first one was the psy_desc->properties buffer of the gab driver. Review of the gab code showed that the address calculation for one memcpy() is wrong. It does properties + sizeof(type) * index but C is defined to do the index multiplication already for pointer + integer additions. Hence the factor was applied twice and the memcpy() does write outside of the properties buffer. Sometimes it happened to be the pinctrl and triggered the strcmp(NULL). Anyways, it is overkill to use a memcpy() here instead of a simple assignment, which is easier to read and has less risk for wrong address calculations. So we change code to a simple assignment. If we initialize the index to the first free location, we can even remove the local variable 'properties'. This bug seems to exist right from the beginning in 3.7-rc1 in commit e60fea794e6e ("power: battery: Generic battery driver using IIO") Signed-off-by: H. Nikolaus Schaller Fixes: e60fea794e6e ("power: battery: Generic battery driver using IIO") Signed-off-by: Sebastian Reichel [bwh: Backported to 3.16: - s/psy_desc/psy/g - Adjust filename] Signed-off-by: Ben Hutchings commit 03b694d995539ad4dd8a2143994083f84783a28d Author: Colin Ian King Date: Mon Jul 2 14:27:35 2018 +0100 staging: rts5208: fix missing error check on call to rtsx_write_register commit c5fae4f4fd28189b1062fb8ef7b21fec37cb8b17 upstream. Currently the check on error return from the call to rtsx_write_register is checking the error status from the previous call. Fix this by adding in the missing assignment of retval. Detected by CoverityScan, CID#709877 Fixes: fa590c222fba ("staging: rts5208: add support for rts5208 and rts5288") Signed-off-by: Colin Ian King Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 6db5b3d549d4a45bc537c4a50e8c891ecadb9f3e Author: Johan Hovold Date: Wed Jul 4 17:02:18 2018 +0200 USB: serial: kobil_sct: fix modem-status error handling commit a420b5d939ee58f1d950f0ea782834056520aeaa upstream. Make sure to return -EIO in case of a short modem-status read request. While at it, split the debug message to not include the (zeroed) transfer-buffer content in case of errors. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 2581931d459ae6dd2b088e10cfefff9209a16974 Author: Sylwester Nawrocki Date: Tue May 15 05:21:45 2018 -0400 media: exynos4-is: Prevent NULL pointer dereference in __isp_video_try_fmt() commit 7c1b9a5aeed91bef98988ac0fcf38c8c1f4f9a3a upstream. This patch fixes potential NULL pointer dereference as indicated by the following static checker warning: drivers/media/platform/exynos4-is/fimc-isp-video.c:408 isp_video_try_fmt_mplane() error: NULL dereference inside function '__isp_video_try_fmt(isp, &f->fmt.pix_mp, (0))()'. Fixes: 34947b8aebe3: ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver") Reported-by: Dan Carpenter Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings commit 916b0798550ffa806458578e00fdd1e8f243e13d Author: Daniel Mack Date: Wed Jun 27 20:58:45 2018 +0200 libertas: fix suspend and resume for SDIO connected cards commit 7444a8092906ed44c09459780c56ba57043e39b1 upstream. Prior to commit 573185cc7e64 ("mmc: core: Invoke sdio func driver's PM callbacks from the sdio bus"), the MMC core used to call into the power management functions of SDIO clients itself and removed the card if the return code was non-zero. IOW, the mmc handled errors gracefully and didn't upchain them to the pm core. Since this change, the mmc core relies on generic power management functions which treat all errors as a reason to cancel the suspend immediately. This causes suspend attempts to fail when the libertas driver is loaded. To fix this, power down the card explicitly in if_sdio_suspend() when we know we're about to lose power and return success. Also set a flag in these cases, and power up the card again in if_sdio_resume(). Fixes: 573185cc7e64 ("mmc: core: Invoke sdio func driver's PM callbacks from the sdio bus") Signed-off-by: Daniel Mack Reviewed-by: Chris Ball Reviewed-by: Ulf Hansson Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filenames] Signed-off-by: Ben Hutchings commit 4a7e0ef5da5e342e4ca37ca17508127ba449d3a8 Author: Colin Ian King Date: Mon Jul 2 17:50:37 2018 +0100 leds: max8997: use mode when calling max8997_led_set_mode commit 7a5de56db902ea632a0ff0c2b47481d278db645f upstream. Variable mode is assigned to pdata->led_pdata->mode[led->id] and yet is not being used when calling function max8997_led_set_mode. Fix this by using mode when calling max8997_led_set_mode. Cleans up clang warning: warning: variable 'mode' set but not used [-Wunused-but-set-variable] Fixes: 8584cb82f151 ("leds: Add suuport for MAX8997-LED driver") Signed-off-by: Colin Ian King Signed-off-by: Jacek Anaszewski Signed-off-by: Ben Hutchings commit a19f546126e13e4a508e9ff8359b566d29383ac7 Author: Bart Van Assche Date: Fri Jun 22 14:53:01 2018 -0700 scsi: target/iscsi: Make iscsit_ta_authentication() respect the output buffer size commit 35bea5c84fd13c643cce63f0b5cd4b148f8c901d upstream. Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1") Signed-off-by: Bart Van Assche Reviewed-by: Mike Christie Cc: Mike Christie Cc: Christoph Hellwig Cc: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit b396dc52e302a0610abfd6467e20fb58352cdb69 Author: Thomas Gleixner Date: Mon Jul 2 09:34:29 2018 +0200 alarmtimer: Prevent overflow for relative nanosleep commit 5f936e19cc0ef97dbe3a56e9498922ad5ba1edef upstream. Air Icy reported: UBSAN: Undefined behaviour in kernel/time/alarmtimer.c:811:7 signed integer overflow: 1529859276030040771 + 9223372036854775807 cannot be represented in type 'long long int' Call Trace: alarm_timer_nsleep+0x44c/0x510 kernel/time/alarmtimer.c:811 __do_sys_clock_nanosleep kernel/time/posix-timers.c:1235 [inline] __se_sys_clock_nanosleep kernel/time/posix-timers.c:1213 [inline] __x64_sys_clock_nanosleep+0x326/0x4e0 kernel/time/posix-timers.c:1213 do_syscall_64+0xb8/0x3a0 arch/x86/entry/common.c:290 alarm_timer_nsleep() uses ktime_add() to add the current time and the relative expiry value. ktime_add() has no sanity checks so the addition can overflow when the relative timeout is large enough. Use ktime_add_safe() which has the necessary sanity checks in place and limits the result to the valid range. Fixes: 9a7adcf5c6de ("timers: Posix interface for alarm-timers") Reported-by: Team OWL337 Signed-off-by: Thomas Gleixner Cc: John Stultz Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1807020926360.1595@nanos.tec.linutronix.de Signed-off-by: Ben Hutchings commit 217adca3b54b81a8d5e194022f3895d9cecb5c8d Author: Eric Biggers Date: Mon Jun 18 10:22:38 2018 -0700 crypto: vmac - separate tfm and request context commit bb29648102335586e9a66289a1d98a0cb392b6e5 upstream. syzbot reported a crash in vmac_final() when multiple threads concurrently use the same "vmac(aes)" transform through AF_ALG. The bug is pretty fundamental: the VMAC template doesn't separate per-request state from per-tfm (per-key) state like the other hash algorithms do, but rather stores it all in the tfm context. That's wrong. Also, vmac_final() incorrectly zeroes most of the state including the derived keys and cached pseudorandom pad. Therefore, only the first VMAC invocation with a given key calculates the correct digest. Fix these bugs by splitting the per-tfm state from the per-request state and using the proper init/update/final sequencing for requests. Reproducer for the crash: #include #include #include int main() { int fd; struct sockaddr_alg addr = { .salg_type = "hash", .salg_name = "vmac(aes)", }; char buf[256] = { 0 }; fd = socket(AF_ALG, SOCK_SEQPACKET, 0); bind(fd, (void *)&addr, sizeof(addr)); setsockopt(fd, SOL_ALG, ALG_SET_KEY, buf, 16); fork(); fd = accept(fd, NULL, NULL); for (;;) write(fd, buf, 256); } The immediate cause of the crash is that vmac_ctx_t.partial_size exceeds VMAC_NHBYTES, causing vmac_final() to memset() a negative length. Reported-by: syzbot+264bca3a6e8d645550d3@syzkaller.appspotmail.com Fixes: f1939f7c5645 ("crypto: vmac - New hash algorithm for intel_txt support") Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit 8e7eefa4884c8c6c381a02d286c8bb8c81642d02 Author: Daniel Borkmann Date: Sun Sep 7 23:23:38 2014 +0200 crypto: memzero_explicit - make sure to clear out sensitive data commit 7185ad2672a7d50bc384de0e38d90b75d99f3d82 upstream. Recently, in commit 13aa93c70e71 ("random: add and use memzero_explicit() for clearing data"), we have found that GCC may optimize some memset() cases away when it detects a stack variable is not being used anymore and going out of scope. This can happen, for example, in cases when we are clearing out sensitive information such as keying material or any e.g. intermediate results from crypto computations, etc. With the help of Coccinelle, we can figure out and fix such occurences in the crypto subsytem as well. Julia Lawall provided the following Coccinelle program: @@ type T; identifier x; @@ T x; ... when exists when any -memset +memzero_explicit (&x, -0, ...) ... when != x when strict @@ type T; identifier x; @@ T x[...]; ... when exists when any -memset +memzero_explicit (x, -0, ...) ... when != x when strict Therefore, make use of the drop-in replacement memzero_explicit() for exactly such cases instead of using memset(). Signed-off-by: Daniel Borkmann Cc: Julia Lawall Cc: Herbert Xu Cc: Theodore Ts'o Cc: Hannes Frederic Sowa Acked-by: Hannes Frederic Sowa Acked-by: Herbert Xu Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit e9754e4a01403ebcbec6e5384e78e92b0e26a5a1 Author: Eric Biggers Date: Mon Jun 18 10:22:37 2018 -0700 crypto: vmac - require a block cipher with 128-bit block size commit 73bf20ef3df262026c3470241ae4ac8196943ffa upstream. The VMAC template assumes the block cipher has a 128-bit block size, but it failed to check for that. Thus it was possible to instantiate it using a 64-bit block size cipher, e.g. "vmac(cast5)", causing uninitialized memory to be used. Add the needed check when instantiating the template. Fixes: f1939f7c5645 ("crypto: vmac - New hash algorithm for intel_txt support") Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit e43438a210722d334bab39637343a95503b56d3e Author: Bart Van Assche Date: Tue Jun 26 15:24:48 2018 -0700 IB/srpt: Support HCAs with more than two ports commit e620ebfc228dcbef7519e3d16f43c6c6f1a1d0cb upstream. Since there are adapters that have four ports, increase the size of the srpt_device.port[] array. This patch avoids that the following warning is hit with quad port Chelsio adapters: WARN_ON(sdev->device->phys_port_cnt > ARRAY_SIZE(sdev->port)); Reported-by: Steve Wise Signed-off-by: Bart Van Assche Cc: Steve Wise Cc: Christoph Hellwig Reviewed-by: Steve Wise Signed-off-by: Jason Gunthorpe [bwh: Backported to 3.16: - Use inline calculation instead of struct_size; the number of ports is not user-controlled so no overflow check is needed - Adjust context] Signed-off-by: Ben Hutchings commit b360bd40db35a0bf956b5a5defdb982f45476381 Author: Nicholas Mc Guire Date: Fri Jun 29 19:07:42 2018 +0200 ALSA: snd-aoa: add of_node_put() in error path commit 222bce5eb88d1af656419db04bcd84b2419fb900 upstream. Both calls to of_find_node_by_name() and of_get_next_child() return a node pointer with refcount incremented thus it must be explicidly decremented here after the last usage. As we are assured to have a refcounted np either from the initial of_find_node_by_name(NULL, name); or from the of_get_next_child(gpio, np) in the while loop if we reached the error code path below, an x of_node_put(np) is needed. Signed-off-by: Nicholas Mc Guire Fixes: commit f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 88cba9483cb429fd54b215f98905efe6e704524d Author: Javier Martinez Canillas Date: Sat Jun 9 08:22:45 2018 -0400 media: omap3isp: zero-initialize the isp cam_xclk{a,b} initial data commit 2ec7debd44b49927a6e2861521994cc075a389ed upstream. The struct clk_init_data init variable is declared in the isp_xclk_init() function so is an automatic variable allocated in the stack. But it's not explicitly zero-initialized, so some init fields are left uninitialized. This causes the data structure to have undefined values that may confuse the common clock framework when the clock is registered. For example, the uninitialized .flags field could have the CLK_IS_CRITICAL bit set, causing the framework to wrongly prepare the clk on registration. This leads to the isp_xclk_prepare() callback being called, which in turn calls to the omap3isp_get() function that increments the isp dev refcount. Since this omap3isp_get() call is unexpected, this leads to an unbalanced omap3isp_get() call that prevents the requested IRQ to be later enabled, due the refcount not being 0 when the correct omap3isp_get() call happens. Fixes: 9b28ee3c9122 ("[media] omap3isp: Use the common clock framework") Signed-off-by: Javier Martinez Canillas Reviewed-by: Sebastian Reichel Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 7a8ff493a11b908a36853173b56592b73476851e Author: Christophe JAILLET Date: Mon Jun 11 19:30:35 2018 +0200 serial: pxa: Fix an error handling path in 'serial_pxa_probe()' commit 95a0e656580fab3128c7bee5f660c50784f53651 upstream. If port.line is out of range, we still need to release some resources, or we will leak them. Fixes: afc7851fab83 ("serial: pxa: Fix out-of-bounds access through serial port index") Signed-off-by: Christophe JAILLET Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 827e66c044ed6e0fc6a737e37a7a3185fef6ae20 Author: Dan Carpenter Date: Tue Jun 5 14:31:39 2018 +0300 rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication() commit ae636fb1554833ee5133ca47bf4b2791b6739c52 upstream. This is a static checker fix, not something I have tested. The issue is that on the second iteration through the loop, we jump forward by le32_to_cpu(auth_req->length) bytes. The problem is that if the length is more than "buflen" then we end up with a negative "buflen". A negative buflen is type promoted to a high positive value and the loop continues but it's accessing beyond the end of the buffer. I believe the "auth_req->length" comes from the firmware and if the firmware is malicious or buggy, you're already toasted so the impact of this bug is probably not very severe. Fixes: 030645aceb3d ("rndis_wlan: handle 802.11 indications from device") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Signed-off-by: Ben Hutchings commit 9823373ff384a5b3fe1e962d7463b92cddda00a3 Author: Takashi Iwai Date: Fri Jun 22 10:59:17 2018 +0200 platform/x86: ideapad-laptop: Apply no_hw_rfkill to Y20-15IKBM, too commit 58e73aa177850babb947555257fd4f79e5275cf1 upstream. The commit 5d9f40b56630 ("platform/x86: ideapad-laptop: Add Y520-15IKBN to no_hw_rfkill") added the entry for Y20-15IKBN, and it turned out that another variant, Y20-15IKBM, also requires the no_hw_rfkill. Trim the last letter from the string so that it matches to both Y20-15IKBN and Y20-15IKBM models. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1098626 Signed-off-by: Takashi Iwai Signed-off-by: Darren Hart (VMware) Signed-off-by: Ben Hutchings commit 3c34f3e69210855a3f6654a6faa27c1a3ebb7530 Author: Olle Liljenzin Date: Sun Jun 18 13:09:31 2017 +0200 platform/x86: ideapad-laptop: Add Y520-15IKBN to no_hw_rfkill commit 5d9f40b56630a8702b5f7a61a770f9b73aa07464 upstream. Lenovo Legion Y520-15IKBN is yet another Lenovo model that does not have an hw rfkill switch, resulting in wifi always reported as hard blocked. Add the model to the list of models without rfkill switch. Signed-off-by: Olle Liljenzin Signed-off-by: Andy Shevchenko Signed-off-by: Ben Hutchings commit 88dd051c0c0a03728ee669d61e68aca671d14496 Author: John Ogness Date: Sun Jun 24 00:32:11 2018 +0200 USB: serial: sierra: fix potential deadlock at close commit e60870012e5a35b1506d7b376fddfb30e9da0b27 upstream. The portdata spinlock can be taken in interrupt context (via sierra_outdat_callback()). Disable interrupts when taking the portdata spinlock when discarding deferred URBs during close to prevent a possible deadlock. Fixes: 014333f77c0b ("USB: sierra: fix urb and memory leak on disconnect") Signed-off-by: John Ogness Signed-off-by: Sebastian Andrzej Siewior [ johan: amend commit message and add fixes and stable tags ] Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 0184414f3d52f5e9a4c84599582a73b5ae2faa4b Author: Julian Wiedmann Date: Wed May 16 09:37:25 2018 +0200 s390/qdio: reset old sbal_state flags commit 64e03ff72623b8c2ea89ca3cb660094e019ed4ae upstream. When allocating a new AOB fails, handle_outbound() is still capable of transmitting the selected buffer (just without async completion). But if a previous transfer on this queue slot used async completion, its sbal_state flags field is still set to QDIO_OUTBUF_STATE_FLAG_PENDING. So when the upper layer driver sees this stale flag, it expects an async completion that never happens. Fix this by unconditionally clearing the flags field. Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks") Signed-off-by: Julian Wiedmann Signed-off-by: Martin Schwidefsky Signed-off-by: Ben Hutchings commit 3cb01937c13c311ed4b399d2f011f092b3521d2a Author: Masami Hiramatsu Date: Sat Apr 28 21:35:01 2018 +0900 kprobes: Make list and blacklist root user read only commit f2a3ab36077222437b4826fc76111caa14562b7c upstream. Since the blacklist and list files on debugfs indicates a sensitive address information to reader, it should be restricted to the root user. Suggested-by: Thomas Richter Suggested-by: Ingo Molnar Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc: Anil S Keshavamurthy Cc: Arnd Bergmann Cc: David Howells Cc: David S . Miller Cc: Heiko Carstens Cc: Jon Medhurst Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tobin C . Harding Cc: Will Deacon Cc: acme@kernel.org Cc: akpm@linux-foundation.org Cc: brueckner@linux.vnet.ibm.com Cc: linux-arch@vger.kernel.org Cc: rostedt@goodmis.org Cc: schwidefsky@de.ibm.com Link: https://lkml.kernel.org/lkml/152491890171.9916.5183693615601334087.stgit@devbox Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit cd73c62241381c4f895305c14a739f64b58502d1 Author: Ondrej Mosnáček Date: Tue Jun 5 11:00:10 2018 +0200 audit: Fix extended comparison of GID/EGID commit af85d1772e31fed34165a1b3decef340cf4080c0 upstream. The audit_filter_rules() function in auditsc.c used the in_[e]group_p() functions to check GID/EGID match, but these functions use the current task's credentials, while the comparison should use the credentials of the task given to audit_filter_rules() as a parameter (tsk). Note that we can use group_search(cred->group_info, ...) as a replacement for both in_group_p and in_egroup_p as these functions only compare the parameter to cred->fsgid/egid and then call group_search. In fact, the usage of in_group_p was even more incorrect: it compares to cred->fsgid (which is usually equal to cred->egid) and not cred->gid. GitHub issue: https://github.com/linux-audit/audit-kernel/issues/82 Fixes: 37eebe39c973 ("audit: improve GID/EGID comparation logic") Signed-off-by: Ondrej Mosnacek Signed-off-by: Paul Moore Signed-off-by: Ben Hutchings commit 9ac50e942c5153cff3323760a90b15be1712a48c Author: Johan Hovold Date: Tue Jun 12 14:43:35 2018 +0200 EDAC, i7core: Fix memleaks and use-after-free on probe and remove commit 6c974d4dfafe5e9ee754f2a6fba0eb1864f1649e upstream. Make sure to free and deregister the addrmatch and chancounts devices allocated during probe in all error paths. Also fix use-after-free in a probe error path and in the remove success path where the devices were being put before before deregistration. Signed-off-by: Johan Hovold Cc: Mauro Carvalho Chehab Cc: linux-edac Fixes: 356f0a30860d ("i7core_edac: change the mem allocation scheme to make Documentation/kobject.txt happy") Link: http://lkml.kernel.org/r/20180612124335.6420-2-johan@kernel.org Signed-off-by: Borislav Petkov Signed-off-by: Ben Hutchings commit ed47292d0503b701d33abfa51cb6a4638d3e8b01 Author: Takashi Iwai Date: Wed Feb 4 11:48:54 2015 +0100 EDAC: i7core: Return proper error codes for kzalloc() errors commit e97d7e38162dc305b4734a316ca758a2bbd1fa6e upstream. ... instead of possibly uninitialized return value. Signed-off-by: Takashi Iwai Link: http://lkml.kernel.org/r/1423046938-18111-5-git-send-email-tiwai@suse.de [ Add a commit message, albeit a small one. ] Signed-off-by: Borislav Petkov Signed-off-by: Ben Hutchings commit e36f7bfc0ae8598af6dc75d6f2bf5edb190b60c5 Author: Johan Hovold Date: Tue Jun 12 14:43:34 2018 +0200 EDAC: Fix memleak in module init error path commit 4708aa85d50cc6e962dfa8acf5ad4e0d290a21db upstream. Make sure to use put_device() to free the initialised struct device so that resources managed by driver core also gets released in the event of a registration failure. Signed-off-by: Johan Hovold Cc: Denis Kirjanov Cc: Mauro Carvalho Chehab Cc: linux-edac Fixes: 2d56b109e3a5 ("EDAC: Handle error path in edac_mc_sysfs_init() properly") Link: http://lkml.kernel.org/r/20180612124335.6420-1-johan@kernel.org Signed-off-by: Borislav Petkov [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings