commit c3f4bb14a264a96c2709b026dca37a4eb252a82a Author: Sasha Levin Date: Sun Dec 3 10:08:35 2017 -0500 Linux 4.1.47 Signed-off-by: Sasha Levin commit 610622cac573aef67811fbffc865d9fba1611050 Author: Jann Horn Date: Tue Nov 14 01:03:44 2017 +0100 mm/pagewalk.c: report holes in hugetlb ranges [ Upstream commit 373c4557d2aa362702c4c2d41288fb1e54990b7c ] This matters at least for the mincore syscall, which will otherwise copy uninitialized memory from the page allocator to userspace. It is probably also a correctness error for /proc/$pid/pagemap, but I haven't tested that. Removing the `walk->hugetlb_entry` condition in walk_hugetlb_range() has no effect because the caller already checks for that. This only reports holes in hugetlb ranges to callers who have specified a hugetlb_entry callback. This issue was found using an AFL-based fuzzer. v2: - don't crash on ->pte_hole==NULL (Andrew Morton) - add Cc stable (Andrew Morton) Fixes: 1e25a271c8ac ("mincore: apply page table walker on do_mincore()") Signed-off-by: Jann Horn Cc: Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 66971c62fc2ed5cae67e46d3ec576339f55aed4b Author: Jaewon Kim Date: Wed Nov 15 17:39:07 2017 -0800 mm/page_ext.c: check if page_ext is not prepared [ Upstream commit e492080e640c2d1235ddf3441cae634cfffef7e1 ] online_page_ext() and page_ext_init() allocate page_ext for each section, but they do not allocate if the first PFN is !pfn_present(pfn) or !pfn_valid(pfn). Then section->page_ext remains as NULL. lookup_page_ext checks NULL only if CONFIG_DEBUG_VM is enabled. For a valid PFN, __set_page_owner will try to get page_ext through lookup_page_ext. Without CONFIG_DEBUG_VM lookup_page_ext will misuse NULL pointer as value 0. This incurrs invalid address access. This is the panic example when PFN 0x100000 is not valid but PFN 0x13FC00 is being used for page_ext. section->page_ext is NULL, get_entry returned invalid page_ext address as 0x1DFA000 for a PFN 0x13FC00. To avoid this panic, CONFIG_DEBUG_VM should be removed so that page_ext will be checked at all times. Unable to handle kernel paging request at virtual address 01dfa014 ------------[ cut here ]------------ Kernel BUG at ffffff80082371e0 [verbose debug info unavailable] Internal error: Oops: 96000045 [#1] PREEMPT SMP Modules linked in: PC is at __set_page_owner+0x48/0x78 LR is at __set_page_owner+0x44/0x78 __set_page_owner+0x48/0x78 get_page_from_freelist+0x880/0x8e8 __alloc_pages_nodemask+0x14c/0xc48 __do_page_cache_readahead+0xdc/0x264 filemap_fault+0x2ac/0x550 ext4_filemap_fault+0x3c/0x58 __do_fault+0x80/0x120 handle_mm_fault+0x704/0xbb0 do_page_fault+0x2e8/0x394 do_mem_abort+0x88/0x124 Pre-4.7 kernels also need commit f86e4271978b ("mm: check the return value of lookup_page_ext for all call sites"). Link: http://lkml.kernel.org/r/20171107094131.14621-1-jaewon31.kim@samsung.com Fixes: eefa864b701d ("mm/page_ext: resurrect struct page extending code for debugging") Signed-off-by: Jaewon Kim Acked-by: Michal Hocko Cc: Vlastimil Babka Cc: Minchan Kim Cc: Joonsoo Kim Cc: [depends on f86e427197, see above] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 47c253b95c094b7d087884b99c91fd99ad33d220 Author: Jan Harkes Date: Wed Sep 27 15:52:12 2017 -0400 coda: fix 'kernel memory exposure attempt' in fsync [ Upstream commit d337b66a4c52c7b04eec661d86c2ef6e168965a2 ] When an application called fsync on a file in Coda a small request with just the file identifier was allocated, but the declared length was set to the size of union of all possible upcall requests. This bug has been around for a very long time and is now caught by the extra checking in usercopy that was introduced in Linux-4.8. The exposure happens when the Coda cache manager process reads the fsync upcall request at which point it is killed. As a result there is nobody servicing any further upcalls, trapping any processes that try to access the mounted Coda filesystem. Cc: stable@vger.kernel.org Signed-off-by: Jan Harkes Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit bead4ab544f2b3f5d0a963cdd1e1b0382a4d218b Author: Corey Minyard Date: Sat Jul 29 21:14:55 2017 -0500 ipmi: fix unsigned long underflow [ Upstream commit 392a17b10ec4320d3c0e96e2a23ebaad1123b989 ] When I set the timeout to a specific value such as 500ms, the timeout event will not happen in time due to the overflow in function check_msg_timeout: ... ent->timeout -= timeout_period; if (ent->timeout > 0) return; ... The type of timeout_period is long, but ent->timeout is unsigned long. This patch makes the type consistent. Reported-by: Weilong Chen Signed-off-by: Corey Minyard Tested-by: Weilong Chen Cc: # 3.16.x Signed-off-by: Sasha Levin commit 1a4fecae70240a7f41615a20d8e5982f833b7268 Author: alex chen Date: Wed Nov 15 17:31:40 2017 -0800 ocfs2: should wait dio before inode lock in ocfs2_setattr() [ Upstream commit 28f5a8a7c033cbf3e32277f4cc9c6afd74f05300 ] we should wait dio requests to finish before inode lock in ocfs2_setattr(), otherwise the following deadlock will happen: process 1 process 2 process 3 truncate file 'A' end_io of writing file 'A' receiving the bast messages ocfs2_setattr ocfs2_inode_lock_tracker ocfs2_inode_lock_full inode_dio_wait __inode_dio_wait -->waiting for all dio requests finish dlm_proxy_ast_handler dlm_do_local_bast ocfs2_blocking_ast ocfs2_generic_handle_bast set OCFS2_LOCK_BLOCKED flag dio_end_io dio_bio_end_aio dio_complete ocfs2_dio_end_io ocfs2_dio_end_io_write ocfs2_inode_lock __ocfs2_cluster_lock ocfs2_wait_for_mask -->waiting for OCFS2_LOCK_BLOCKED flag to be cleared, that is waiting for 'process 1' unlocking the inode lock inode_dio_end -->here dec the i_dio_count, but will never be called, so a deadlock happened. Link: http://lkml.kernel.org/r/59F81636.70508@huawei.com Signed-off-by: Alex Chen Reviewed-by: Jun Piao Reviewed-by: Joseph Qi Acked-by: Changwei Ge Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 269ebf46453ae48a4537a4a4aa4cc9f8e3c31234 Author: Lukas Wunner Date: Sat Oct 21 10:50:18 2017 +0200 serial: omap: Fix EFR write on RTS deassertion [ Upstream commit 2a71de2f7366fb1aec632116d0549ec56d6a3940 ] Commit 348f9bb31c56 ("serial: omap: Fix RTS handling") sought to enable auto RTS upon manual RTS assertion and disable it on deassertion. However it seems the latter was done incorrectly, it clears all bits in the Extended Features Register *except* auto RTS. Fixes: 348f9bb31c56 ("serial: omap: Fix RTS handling") Cc: Peter Hurley Cc: stable Signed-off-by: Lukas Wunner Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 312ce4d0bfd851679d4f819ac9c6878a1b0baca6 Author: Roberto Sassu Date: Tue Nov 7 11:37:07 2017 +0100 ima: do not update security.ima if appraisal status is not INTEGRITY_PASS [ Upstream commit 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb ] Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters") moved the call of ima_file_check() from may_open() to do_filp_open() at a point where the file descriptor is already opened. This breaks the assumption made by IMA that file descriptors being closed belong to files whose access was granted by ima_file_check(). The consequence is that security.ima and security.evm are updated with good values, regardless of the current appraisal status. For example, if a file does not have security.ima, IMA will create it after opening the file for writing, even if access is denied. Access to the file will be allowed afterwards. Avoid this issue by checking the appraisal status before updating security.ima. Cc: stable@vger.kernel.org Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: James Morris Signed-off-by: Sasha Levin commit 946a4249b83f4fbbb1d2c025faa653c33a692705 Author: Eric W. Biederman Date: Wed Nov 15 22:17:48 2017 -0600 net/sctp: Always set scope_id in sctp_inet6_skb_msgname [ Upstream commit 7c8a61d9ee1df0fb4747879fa67a99614eb62fec ] Alexandar Potapenko while testing the kernel with KMSAN and syzkaller discovered that in some configurations sctp would leak 4 bytes of kernel stack. Working with his reproducer I discovered that those 4 bytes that are leaked is the scope id of an ipv6 address returned by recvmsg. With a little code inspection and a shrewd guess I discovered that sctp_inet6_skb_msgname only initializes the scope_id field for link local ipv6 addresses to the interface index the link local address pertains to instead of initializing the scope_id field for all ipv6 addresses. That is almost reasonable as scope_id's are meaniningful only for link local addresses. Set the scope_id in all other cases to 0 which is not a valid interface index to make it clear there is nothing useful in the scope_id field. There should be no danger of breaking userspace as the stack leak guaranteed that previously meaningless random data was being returned. Fixes: 372f525b495c ("SCTP: Resync with LKSCTP tree.") History-tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Reported-by: Alexander Potapenko Tested-by: Alexander Potapenko Signed-off-by: "Eric W. Biederman" Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2aebd895529a57e565edb92ee5affeb590353faa Author: Huacai Chen Date: Thu Nov 16 11:07:15 2017 +0800 fealnx: Fix building error on MIPS [ Upstream commit cc54c1d32e6a4bb3f116721abf900513173e4d02 ] This patch try to fix the building error on MIPS. The reason is MIPS has already defined the LONG macro, which conflicts with the LONG enum in drivers/net/ethernet/fealnx.c. Signed-off-by: Huacai Chen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1723ce9816ab84ab20a4307999085e776d8032b1 Author: Jason A. Donenfeld Date: Thu Nov 9 13:04:44 2017 +0900 af_netlink: ensure that NLMSG_DONE never fails in dumps [ Upstream commit 0642840b8bb008528dbdf929cec9f65ac4231ad0 ] The way people generally use netlink_dump is that they fill in the skb as much as possible, breaking when nla_put returns an error. Then, they get called again and start filling out the next skb, and again, and so forth. The mechanism at work here is the ability for the iterative dumping function to detect when the skb is filled up and not fill it past the brim, waiting for a fresh skb for the rest of the data. However, if the attributes are small and nicely packed, it is possible that a dump callback function successfully fills in attributes until the skb is of size 4080 (libmnl's default page-sized receive buffer size). The dump function completes, satisfied, and then, if it happens to be that this is actually the last skb, and no further ones are to be sent, then netlink_dump will add on the NLMSG_DONE part: nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, sizeof(len), NLM_F_MULTI); It is very important that netlink_dump does this, of course. However, in this example, that call to nlmsg_put_answer will fail, because the previous filling by the dump function did not leave it enough room. And how could it possibly have done so? All of the nla_put variety of functions simply check to see if the skb has enough tailroom, independent of the context it is in. In order to keep the important assumptions of all netlink dump users, it is therefore important to give them an skb that has this end part of the tail already reserved, so that the call to nlmsg_put_answer does not fail. Otherwise, library authors are forced to find some bizarre sized receive buffer that has a large modulo relative to the common sizes of messages received, which is ugly and buggy. This patch thus saves the NLMSG_DONE for an additional message, for the case that things are dangerously close to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 29215e44692c8723aadbbf7278cb89af0afc35ba Author: Cong Wang Date: Thu Nov 9 16:43:13 2017 -0800 vlan: fix a use-after-free in vlan_device_event() [ Upstream commit 052d41c01b3a2e3371d66de569717353af489d63 ] After refcnt reaches zero, vlan_vid_del() could free dev->vlan_info via RCU: RCU_INIT_POINTER(dev->vlan_info, NULL); call_rcu(&vlan_info->rcu, vlan_info_rcu_free); However, the pointer 'grp' still points to that memory since it is set before vlan_vid_del(): vlan_info = rtnl_dereference(dev->vlan_info); if (!vlan_info) goto out; grp = &vlan_info->grp; Depends on when that RCU callback is scheduled, we could trigger a use-after-free in vlan_group_for_each_dev() right following this vlan_vid_del(). Fix it by moving vlan_vid_del() before setting grp. This is also symmetric to the vlan_vid_add() we call in vlan_device_event(). Reported-by: Fengguang Wu Fixes: efc73f4bbc23 ("net: Fix memory leak - vlan_info struct") Cc: Alexander Duyck Cc: Linus Torvalds Cc: Girish Moodalbail Signed-off-by: Cong Wang Reviewed-by: Girish Moodalbail Tested-by: Fengguang Wu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 758019fb31b790abe771a63f8556c263e6800224 Author: Hangbin Liu Date: Mon Nov 6 09:01:57 2017 +0800 bonding: discard lowest hash bit for 802.3ad layer3+4 [ Upstream commit b5f862180d7011d9575d0499fa37f0f25b423b12 ] After commit 07f4c90062f8 ("tcp/dccp: try to not exhaust ip_local_port_range in connect()"), we will try to use even ports for connect(). Then if an application (seen clearly with iperf) opens multiple streams to the same destination IP and port, each stream will be given an even source port. So the bonding driver's simple xmit_hash_policy based on layer3+4 addressing will always hash all these streams to the same interface. And the total throughput will limited to a single slave. Change the tcp code will impact the whole tcp behavior, only for bonding usage. Paolo Abeni suggested fix this by changing the bonding code only, which should be more reasonable, and less impact. Fix this by discarding the lowest hash bit because it contains little entropy. After the fix we can re-balance between slaves. Signed-off-by: Paolo Abeni Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9eb6a97a5a890f2fad4990af14af5ba63859dadf Author: Ye Yin Date: Thu Oct 26 16:57:05 2017 +0800 netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed [ Upstream commit 2b5ec1a5f9738ee7bf8f5ec0526e75e00362c48f ] When run ipvs in two different network namespace at the same host, and one ipvs transport network traffic to the other network namespace ipvs. 'ipvs_property' flag will make the second ipvs take no effect. So we should clear 'ipvs_property' when SKB network namespace changed. Fixes: 621e84d6f373 ("dev: introduce skb_scrub_packet()") Signed-off-by: Ye Yin Signed-off-by: Wei Zhou Signed-off-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7a7e7af06539cb2841425f7cc861e779b0f94b91 Author: Eric Dumazet Date: Thu Nov 2 12:30:25 2017 -0700 tcp: do not mangle skb->cb[] in tcp_make_synack() [ Upstream commit 3b11775033dc87c3d161996c54507b15ba26414a ] Christoph Paasch sent a patch to address the following issue : tcp_make_synack() is leaving some TCP private info in skb->cb[], then send the packet by other means than tcp_transmit_skb() tcp_transmit_skb() makes sure to clear skb->cb[] to not confuse IPv4/IPV6 stacks, but we have no such cleanup for SYNACK. tcp_make_synack() should not use tcp_init_nondata_skb() : tcp_init_nondata_skb() really should be limited to skbs put in write/rtx queues (the ones that are only sent via tcp_transmit_skb()) This patch fixes the issue and should even save few cpu cycles ;) Fixes: 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses") Signed-off-by: Eric Dumazet Reported-by: Christoph Paasch Reviewed-by: Christoph Paasch Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 80c32c0f8027e913d44fd44cd25dda62cb8cfd9e Author: Johan Hovold Date: Wed Oct 11 14:02:58 2017 +0200 USB: serial: garmin_gps: fix memory leak on probe errors [ Upstream commit 74d471b598444b7f2d964930f7234779c80960a0 ] Make sure to free the port private data before returning after a failed probe attempt. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 5ad0509a3e6febe99b968aa8d8d90b8c0d216b72 Author: Johan Hovold Date: Wed Oct 11 14:02:57 2017 +0200 USB: serial: garmin_gps: fix I/O after failed probe and remove [ Upstream commit 19a565d9af6e0d828bd0d521d3bafd5017f4ce52 ] Make sure to stop any submitted interrupt and bulk-out URBs before returning after failed probe and when the port is being unbound to avoid later NULL-pointer dereferences in the completion callbacks. Also fix up the related and broken I/O cancellation on failed open and on close. (Note that port->write_urb was never submitted.) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable # 51a2f077 ("USB: introduce usb_anchor") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 5a306396567a66856bdc8eb7048e4e3460d49424 Author: Douglas Fischer Date: Sun Oct 29 23:29:55 2017 +0000 USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update [ Upstream commit 771394a54148f18926ca86414e51c69eda27d0cd ] Add USB PID/VID for Sierra Wireless EM7355 LTE modem QDL firmware update mode. Signed-off-by: Douglas Fischer Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 5cbde640665c9b0a0c89c32aa11207248af91f12 Author: Bernhard Rosenkraenzer Date: Fri Nov 3 16:46:02 2017 +0100 USB: Add delay-init quirk for Corsair K70 LUX keyboards [ Upstream commit a0fea6027f19c62727315aba1a7fae75a9caa842 ] Without this patch, K70 LUX keyboards don't work, saying usb 3-3: unable to read config index 0 descriptor/all usb 3-3: can't read configurations, error -110 usb usb3-port3: unable to enumerate USB device Signed-off-by: Bernhard Rosenkraenzer Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2ef0c44f3f6852b1df9c2ba1ce126fbac66c4259 Author: Alan Stern Date: Wed Nov 8 12:23:17 2017 -0500 USB: usbfs: compute urb->actual_length for isochronous [ Upstream commit 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 ] The USB kerneldoc says that the actual_length field "is read in non-iso completion functions", but the usbfs driver uses it for all URB types in processcompl(). Since not all of the host controller drivers set actual_length for isochronous URBs, programs using usbfs with some host controllers don't work properly. For example, Minas reports that a USB camera controlled by libusb doesn't work properly with a dwc2 controller. It doesn't seem worthwhile to change the HCDs and the documentation, since the in-kernel USB class drivers evidently don't rely on actual_length for isochronous transfers. The easiest solution is for usbfs to calculate the actual_length value for itself, by adding up the lengths of the individual packets in an isochronous transfer. Signed-off-by: Alan Stern CC: Minas Harutyunyan Reported-and-tested-by: wlf CC: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 78fad35aab599a6651e4fadb4fdb6e5099571a7a Author: Paul Burton Date: Mon Nov 7 11:30:41 2016 +0000 MIPS: Netlogic: Exclude netlogic,xlp-pic code from XLR builds [ Upstream commit 9799270affc53414da96e77e454a5616b39cdab0 ] Code in arch/mips/netlogic/common/irq.c which handles the XLP PIC fails to build in XLR configurations due to cpu_is_xlp9xx not being defined, leading to the following build failure: arch/mips/netlogic/common/irq.c: In function ‘xlp_of_pic_init’: arch/mips/netlogic/common/irq.c:298:2: error: implicit declaration of function ‘cpu_is_xlp9xx’ [-Werror=implicit-function-declaration] if (cpu_is_xlp9xx()) { ^ Although the code was conditional upon CONFIG_OF which is indirectly selected by CONFIG_NLM_XLP_BOARD but not CONFIG_NLM_XLR_BOARD, the failing XLR with CONFIG_OF configuration can be configured manually or by randconfig. Fix the build failure by making the affected XLP PIC code conditional upon CONFIG_CPU_XLP which is used to guard the inclusion of asm/netlogic/xlp-hal/xlp.h that provides the required cpu_is_xlp9xx function. [ralf@linux-mips.org: Fixed up as per Jayachandran's suggestion.] Signed-off-by: Paul Burton Cc: Jayachandran C Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14524/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 91bd758412f30bd9fc3658f3efaf02ebfd974879 Author: Marcin Nowakowski Date: Wed Nov 23 14:43:44 2016 +0100 MIPS: init: Ensure reserved memory regions are not added to bootmem [ Upstream commit e89ef66d7682f031f026eee6bba03c8c2248d2a9 ] Memories managed through boot_mem_map are generally expected to define non-crossing areas. However, if part of a larger memory block is marked as reserved, it would still be added to bootmem allocator as an available block and could end up being overwritten by the allocator. Prevent this by explicitly marking the memory as reserved it if exists in the range used by bootmem allocator. Signed-off-by: Marcin Nowakowski Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14608/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 78d36a51aff258a26c4c2c12c4d86de0fae64e3a Author: Marcin Nowakowski Date: Wed Nov 23 14:43:45 2016 +0100 MIPS: init: Ensure bootmem does not corrupt reserved memory [ Upstream commit d9b5b658210f28ed9f70c757d553e679d76e2986 ] Current init code initialises bootmem allocator with all of the low memory that it assumes is available, but does not check for reserved memory block, which can lead to corruption of data that may be stored there. Move bootmem's allocation map to a location that does not cross any reserved regions Signed-off-by: Marcin Nowakowski Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14609/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 76af872c855e1021df82326e20dfc452d25e851c Author: Paul Burton Date: Mon Nov 7 11:14:09 2016 +0000 MIPS: End asm function prologue macros with .insn [ Upstream commit 08889582b8aa0bbc01a1e5a0033b9f98d2e11caa ] When building a kernel targeting a microMIPS ISA, recent GNU linkers will fail the link if they cannot determine that the target of a branch or jump is microMIPS code, with errors such as the following: mips-img-linux-gnu-ld: arch/mips/built-in.o: .text+0x542c: Unsupported jump between ISA modes; consider recompiling with interlinking enabled. mips-img-linux-gnu-ld: final link failed: Bad value or: ./arch/mips/include/asm/uaccess.h:1017: warning: JALX to a non-word-aligned address Placing anything other than an instruction at the start of a function written in assembly appears to trigger such errors. In order to prepare for allowing us to follow function prologue macros with an EXPORT_SYMBOL invocation, end the prologue macros (LEAD, NESTED & FEXPORT) with a .insn directive. This ensures that the start of the function is marked as code, which always makes sense for functions & safely prevents us from hitting the link errors described above. Signed-off-by: Paul Burton Reviewed-by: Maciej W. Rozycki Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14508/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 7206e115253750a3ccdf6984fdcf43dd8561a6e7 Author: Emil Tantilov Date: Fri Nov 4 14:03:03 2016 -0700 ixgbe: add mask for 64 RSS queues [ Upstream commit 2bf1a87b903bd81b1448a1cef73de59fb6c4d340 ] The indirection table was reported incorrectly for X550 and newer where we can support up to 64 RSS queues. Reported-by Krishneil Singh Signed-off-by: Emil Tantilov Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 4baa4d5e65c787816d6a6818c7f7a4835f938d22 Author: Emil Tantilov Date: Fri Nov 11 10:07:47 2016 -0800 ixgbe: handle close/suspend race with netif_device_detach/present [ Upstream commit f7f37e7ff2b9b7eff7fbd035569cab35896869a3 ] When an interface is part of a namespace it is possible that ixgbe_close() may be called while __ixgbe_shutdown() is running which ends up in a double free WARN and/or a BUG in free_msi_irqs(). To handle this situation we extend the rtnl_lock() to protect the call to netif_device_detach() and ixgbe_clear_interrupt_scheme() in __ixgbe_shutdown() and check for netif_device_present() to avoid clearing the interrupts second time in ixgbe_close(); Also extend the rtnl lock in ixgbe_resume() to netif_device_attach(). Signed-off-by: Emil Tantilov Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 3277e197e4cfc0cbb92cf8dab16dbaeb2a16a3f9 Author: Emil Tantilov Date: Wed Nov 16 09:48:02 2016 -0800 ixgbe: fix AER error handling [ Upstream commit 126db13fa0e6d05c9f94e0125f61e773bd5ab079 ] Make sure that we free the IRQs in ixgbe_io_error_detected() when responding to an PCIe AER error and also restore them when the interface recovers from it. Previously it was possible to trigger BUG_ON() check in free_msix_irqs() in the case where we call ixgbe_remove() after a failed recovery from AER error because the interrupts were not freed. Signed-off-by: Emil Tantilov Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 00dc6f1ea96af0ae955a91ce7cc8ae08ec46ce78 Author: Arvind Yadav Date: Tue Jan 3 17:00:27 2017 +0530 gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap [ Upstream commit 4b0ea93f250afc6c1128e201b0a8a115ae613e47 ] Here, pci_iomap can fail, handle this case and return -ENOMEM. Signed-off-by: Arvind Yadav Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483443027-13444-1-git-send-email-arvind.yadav.cs@gmail.com Signed-off-by: Sasha Levin commit 7b4079cf2ee13c811de80d1abcea6bfc7ba50c1a Author: Alexey Khoroshilov Date: Sat Jul 9 01:19:51 2016 +0300 backlight: adp5520: Fix error handling in adp5520_bl_probe() [ Upstream commit 0eb3fba8c68275f0122f65f7316efaaf86448016 ] If adp5520_bl_setup() fails, sysfs group left unremoved. By the way, fix overcomplicated assignement of error code. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Acked-by: Michael Hennerich Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 02583f005c715177a0332755da321b7d658bb97b Author: Uwe Kleine-König Date: Wed Jul 6 19:33:05 2016 +0200 backlight: lcd: Fix race condition during register [ Upstream commit cc21942bce652d1a92dae85b785378256e1df1f7 ] Once device_register is called for a device its attributes might be accessed. As the callbacks of a lcd device's attributes make use of the lcd_ops, the respective member must be setup before calling device_register. Signed-off-by: Uwe Kleine-König Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 01e135f94414d4fc0abf6febc48108d989ad7c45 Author: Takashi Iwai Date: Wed Jan 4 12:19:15 2017 +0100 ALSA: vx: Fix possible transfer overflow [ Upstream commit 874e1f6fad9a5184b67f4cee37c1335cd2cc5677 ] 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: Sasha Levin commit db2e059fb898dc8142796b3a7010a626c0c398f5 Author: Takashi Iwai Date: Wed Jan 4 12:34:14 2017 +0100 ALSA: vx: Don't try to update capture stream before running [ Upstream commit ed3c177d960bb5881b945ca6f784868126bb90db ] The update of stream costs significantly, and we should avoid it unless the stream really has started. Check pipe->running flag instead of pipe->prepared. Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c2bca39c34d8b5e8edcb7d7b629c7f24e011bbe5 Author: James Smart Date: Mon Dec 19 15:07:23 2016 -0800 scsi: lpfc: Correct issue leading to oops during link reset [ Upstream commit e6c6acc0e0223ddaf867628d420ee196349c6fae ] Correct issue leading to oops during link reset. Missing vport pointer. [mkp: fixed typo] Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3eeb3a1b55fbb84a4d55c5e81f29024e68808df3 Author: James Smart Date: Mon Dec 19 15:07:24 2016 -0800 scsi: lpfc: Correct host name in symbolic_name field [ Upstream commit 6c9231f604c2575be24c96d38deb70f145172f92 ] Correct host name in symbolic_name field of nameserver registrations Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 364cadbea4766e7328b21d67d1f675d00dde69a2 Author: James Smart Date: Mon Dec 19 15:07:25 2016 -0800 scsi: lpfc: FCoE VPort enable-disable does not bring up the VPort [ Upstream commit 104450eb08ca662e6b1d02da11aca9598e978f3e ] FCoE VPort enable-disable does not bring up the VPort. VPI structure needed to be initialized before being re-registered. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1174a8d6324497bb070ca15b03a5e4c343bc3848 Author: James Smart Date: Mon Dec 19 15:07:30 2016 -0800 scsi: lpfc: Add missing memory barrier [ Upstream commit 6b3b3bdb83b4ad51252d21bb13596db879e51850 ] On loosely ordered memory systems (PPC for example), the WQE elements were being updated in memory, but not necessarily flushed before the separate doorbell was written to hw which would cause hw to dma the WQE element. Thus, the hardware occasionally received partially updated WQE data. Add the memory barrier after updating the WQE memory. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2f98e2999cd53774720b4d0815c8e9021fcefefc Author: Galo Navarro Date: Tue Jan 3 23:12:09 2017 +0100 staging: rtl8188eu: fix incorrect ERROR tags from logs [ Upstream commit 401579c22ccbcb54244494069973e64b1fe980d2 ] Several lifecycle events in the rtl8188eu driver are logged using the DBG_88E_LEVEL macro from rtw_debug.h, which is tagged as ERROR regardless of the actual level. Below are dmesg excerpts after loading and unloading the module, the messages are misleading as there was no error. [517434.916239] usbcore: registered new interface driver r8188eu [517435.680653] R8188EU: ERROR indicate disassoc [517437.122606] R8188EU: ERROR assoc success [517797.735611] usbcore: deregistering interface driver r8188eu [517797.736069] R8188EU: ERROR indicate disassoc Remove the ERROR prefix from the logs. After the patch, logs are: [517949.873976] usbcore: registered new interface driver r8188eu [517950.592845] R8188EU: indicate disassoc [517951.993973] R8188EU: assoc success [521778.784448] usbcore: deregistering interface driver r8188eu [521778.784838] R8188EU: indicate disassoc Signed-off-by: Galo Navarro Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 82b964612daa3d222a2e4ace8d6469c6b84db310 Author: Hannu Lounento Date: Mon Jan 2 18:26:06 2017 +0100 igb: Fix hw_dbg logging in igb_update_flash_i210 [ Upstream commit 76ed5a8f47476e4984cc8c0c1bc4cee62650f7fd ] Fix an if statement with hw_dbg lines where the logic was inverted with regards to the corresponding return value used in the if statement. Signed-off-by: Hannu Lounento Signed-off-by: Peter Senna Tschudin Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 0e373d9dcd9074c479e944a222028e1f94a37453 Author: Todd Fujinaka Date: Tue Nov 15 08:54:26 2016 -0800 igb: close/suspend race in netif_device_detach [ Upstream commit 9474933caf21a4cb5147223dca1551f527aaac36 ] Similar to ixgbe, when an interface is part of a namespace it is possible that igb_close() may be called while __igb_shutdown() is running which ends up in a double free WARN and/or a BUG in free_msi_irqs(). Extend the rtnl_lock() to protect the call to netif_device_detach() and igb_clear_interrupt_scheme() in __igb_shutdown() and check for netif_device_present() to avoid calling igb_clear_interrupt_scheme() a second time in igb_close(). Also extend the rtnl lock in igb_resume() to netif_device_attach(). Signed-off-by: Todd Fujinaka Acked-by: Alexander Duyck Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit ef528d447e2b6ef5c340de4812a6973e9ca54371 Author: Aaron Sierra Date: Tue Nov 29 10:03:56 2016 -0600 igb: reset the PHY before reading the PHY ID [ Upstream commit 182785335447957409282ca745aa5bc3968facee ] Several people have reported firmware leaving the I210/I211 PHY's page select register set to something other than the default of zero. This causes the first accesses, PHY_IDx register reads, to access something else, resulting in device probe failure: igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k igb: Copyright (c) 2007-2014 Intel Corporation. igb: probe of 0000:01:00.0 failed with error -2 This problem began for them after a previous patch I submitted was applied: commit 2a3cdead8b408351fa1e3079b220fa331480ffbc Author: Aaron Sierra Date: Tue Nov 3 12:37:09 2015 -0600 igb: Remove GS40G specific defines/functions I personally experienced this problem after attempting to PXE boot from I210 devices using this firmware: Intel(R) Boot Agent GE v1.5.78 Copyright (C) 1997-2014, Intel Corporation Resetting the PHY before reading from it, ensures the page select register is in its default state and doesn't make assumptions about the PHY's register set before the PHY has been probed. Cc: Matwey V. Kornilov Cc: Chris Arges Cc: Jochen Henneberg Signed-off-by: Aaron Sierra Tested-by: Matwey V. Kornilov Tested-by: Chris J Arges Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 010165909ea27ecc7e522c200fdf5ab62c67576b Author: Arvind Yadav Date: Wed Dec 21 11:00:12 2016 +0530 drm/sti: sti_vtg: Handle return NULL error from devm_ioremap_nocache [ Upstream commit 1ae0d5af347df224a6e76334683f13a96d915a44 ] Here, If devm_ioremap_nocache will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by: Arvind Yadav Acked-by: Vincent Abriou Signed-off-by: Sasha Levin commit b1fe3ac7ec7cdee9ad941a916a437dcd953d7083 Author: Geert Uytterhoeven Date: Tue Jan 3 19:09:44 2017 +0100 ata: SATA_MV should depend on HAS_DMA [ Upstream commit 62989cebd367a1aae1e009e1a5b1ec046a4c8fdc ] If NO_DMA=y: ERROR: "dma_pool_alloc" [drivers/ata/sata_mv.ko] undefined! ERROR: "dmam_pool_create" [drivers/ata/sata_mv.ko] undefined! ERROR: "dma_pool_free" [drivers/ata/sata_mv.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b40bfbd6fc2bf29f2f20491f7f847426881570be Author: Geert Uytterhoeven Date: Tue Jan 3 19:09:45 2017 +0100 ata: SATA_HIGHBANK should depend on HAS_DMA [ Upstream commit 2a736e0585e585c2566b5119af8381910a170e44 ] If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/ata/sata_highbank.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 455616ce75cede734ddd0c8f4d6fed1b9da7fc6d Author: Geert Uytterhoeven Date: Tue Jan 3 19:09:46 2017 +0100 ata: ATA_BMDMA should depend on HAS_DMA [ Upstream commit 7bc7ab1e63dfe004931502f90ce7020e375623da ] If NO_DMA=y: ERROR: "dmam_alloc_coherent" [drivers/ata/libata.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit f9c2730953ea26b467948f5e67e6daa622690cc6 Author: Tony Lindgren Date: Thu Jan 5 11:07:18 2017 -0800 ARM: dts: Fix omap3 off mode pull defines [ Upstream commit d97556c8012015901a3ce77f46960078139cd79d ] We need to also have OFFPULLUDENABLE bit set to use the off mode pull values. Otherwise the line is pulled down internally if no external pull exists. This is has some documentation at: http://processors.wiki.ti.com/index.php/Optimizing_OMAP35x_and_AM/DM37x_OFF_mode_PAD_configuration Note that the value is still glitchy during off mode transitions as documented in spz319f.pdf "Advisory 1.45". It's best to use external pulls instead of relying on the internal ones for off mode and even then anything pulled up will get driven down momentarily on off mode restore for GPIO banks other than bank1. Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 1188f297f5c1bd65f1358ecdf05b3afe7d274bcd Author: Tony Lindgren Date: Thu Jan 5 11:08:20 2017 -0800 ARM: OMAP2+: Fix init for multiple quirks for the same SoC [ Upstream commit 6e613ebf4405fc09e2a8c16ed193b47f80a3cbed ] It's possible that there are multiple quirks that need to be initialized for the same SoC. Fix the issue by not returning on the first match. Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit c7a08d877c2095e536f95f8e915d074fd38637fe Author: Ngai-Mint Kwan Date: Wed Nov 2 16:44:46 2016 -0700 fm10k: request reset when mbx->state changes [ Upstream commit 2f3fc1e6200309ccf87f61dea56e57e563c4f800 ] Multiple IES API resets can cause a race condition where the mailbox interrupt request bits can be cleared before being handled. This can leave certain mailbox messages from the PF to be untreated and the PF will enter in some inactive state. If this situation occurs, the IES API will initiate a mailbox version reset which, then, trigger a mailbox state change. Once this mailbox transition occurs (from OPEN to CONNECT state), a request for reset will be returned. This ensures that PF will undergo a reset whenever IES API encounters an unknown global mailbox interrupt event or whenever the IES API terminates. Signed-off-by: Ngai-Mint Kwan Signed-off-by: Jacob Keller Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 89b1ca55dde96630c686b44b903119e403df0e4e Author: Roger Quadros Date: Thu Dec 8 10:45:31 2016 +0200 extcon: palmas: Check the parent instance to prevent the NULL [ Upstream commit 9fe172b9be532acc23e35ba693700383ab775e66 ] extcon-palmas must be child of palmas and expects parent's drvdata to be valid. Check for non NULL parent drvdata and fail if it is NULL. Not doing so will result in a NULL pointer dereference later in the probe() parent drvdata is NULL (e.g. misplaced extcon-palmas node in device tree). Signed-off-by: Roger Quadros Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 86b88cbb0727bbb4ddf562ead6bd64aa8fe52819 Author: Adam Wallis Date: Thu Nov 2 08:53:30 2017 -0400 dmaengine: dmatest: warn user when dma test times out [ Upstream commit a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 ] Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()") introduced a bug (that is in fact documented by the patch commit text) that leaves behind a dangling pointer. Since the done_wait structure is allocated on the stack, future invocations to the DMATEST can produce undesirable results (e.g., corrupted spinlocks). Ideally, this would be cleaned up in the thread handler, but at the very least, the kernel is left in a very precarious scenario that can lead to some long debug sessions when the crash comes later. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605 Signed-off-by: Adam Wallis Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 8e3bc0d48890704abdac3d5e0eb81ebc599cb921 Author: Bjørn Mork Date: Mon Nov 6 15:32:18 2017 +0100 net: qmi_wwan: fix divide by 0 on bad descriptors [ Upstream commit 7fd078337201cf7468f53c3d9ef81ff78cb6df3b ] A CDC Ethernet functional descriptor with wMaxSegmentSize = 0 will cause a divide error in usbnet_probe: divide error: 0000 [#1] PREEMPT SMP KASAN Modules linked in: CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event task: ffff88006bef5c00 task.stack: ffff88006bf60000 RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355 RSP: 0018:ffff88006bf67508 EFLAGS: 00010246 RAX: 00000000000163c8 RBX: ffff8800621fce40 RCX: ffff8800621fcf34 RDX: 0000000000000000 RSI: ffffffff837ecb7a RDI: ffff8800621fcf34 RBP: ffff88006bf67520 R08: ffff88006bef5c00 R09: ffffed000c43f881 R10: ffffed000c43f880 R11: ffff8800621fc406 R12: 0000000000000003 R13: ffffffff85c71de0 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe9c0d6dac CR3: 00000000614f4000 CR4: 00000000000006f0 Call Trace: usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783 qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338 usb_probe_interface+0x324/0x940 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:413 driver_probe_device+0x522/0x740 drivers/base/dd.c:557 Fix by simply ignoring the bogus descriptor, as it is optional for QMI devices anyway. Fixes: 423ce8caab7e ("net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices") Reported-by: Andrey Konovalov Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e33c3b35af697c34d89086580386c768ca038623 Author: Xin Long Date: Tue Oct 17 23:26:10 2017 +0800 sctp: do not peel off an assoc from one netns to another one [ Upstream commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74 ] Now when peeling off an association to the sock in another netns, all transports in this assoc are not to be rehashed and keep use the old key in hashtable. As a transport uses sk->net as the hash key to insert into hashtable, it would miss removing these transports from hashtable due to the new netns when closing the sock and all transports are being freeed, then later an use-after-free issue could be caused when looking up an asoc and dereferencing those transports. This is a very old issue since very beginning, ChunYu found it with syzkaller fuzz testing with this series: socket$inet6_sctp() bind$inet6() sendto$inet6() unshare(0x40000000) getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST() getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF() This patch is to block this call when peeling one assoc off from one netns to another one, so that the netns of all transport would not go out-sync with the key in hashtable. Note that this patch didn't fix it by rehashing transports, as it's difficult to handle the situation when the tuple is already in use in the new netns. Besides, no one would like to peel off one assoc to another netns, considering ipaddrs, ifaces, etc. are usually different. Reported-by: ChunYu Wang Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 516e503b7e1ea541ea3eac082ad1ee165ca6756a Author: Jan Beulich Date: Tue Jun 13 16:28:27 2017 -0400 xen-blkback: don't leak stack data via response ring [ Upstream commit 089bc0143f489bd3a4578bdff5f4ca68fb26f341 ] Rather than constructing a local structure instance on the stack, fill the fields directly on the shared ring, just like other backends do. Build on the fact that all response structure flavors are actually identical (the old code did make this assumption too). This is XSA-216. Cc: stable@vger.kernel.org Signed-off-by: Jan Beulich Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Sasha Levin commit c39c42d6c9291e3541cffee226b028961d35a9fb Author: Paolo Bonzini Date: Wed Jun 7 15:13:14 2017 +0200 KVM: x86: fix singlestepping over syscall [ Upstream commit c8401dda2f0a00cd25c0af6a95ed50e478d25de4 ] TF is handled a bit differently for syscall and sysret, compared to the other instructions: TF is checked after the instruction completes, so that the OS can disable #DB at a syscall by adding TF to FMASK. When the sysret is executed the #DB is taken "as if" the syscall insn just completed. KVM emulates syscall so that it can trap 32-bit syscall on Intel processors. Fix the behavior, otherwise you could get #DB on a user stack which is not nice. This does not affect Linux guests, as they use an IST or task gate for #DB. This fixes CVE-2017-7518. Cc: stable@vger.kernel.org Reported-by: Andy Lutomirski Signed-off-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 314b1400b2ee51d719023b9f7a2caa15c51d7368 Author: Jan Kara Date: Sun Apr 24 00:56:03 2016 -0400 ext4: fix data exposure after a crash [ Upstream commit 06bd3c36a733ac27962fea7d6f47168841376824 ] Huang has reported that in his powerfail testing he is seeing stale block contents in some of recently allocated blocks although he mounts ext4 in data=ordered mode. After some investigation I have found out that indeed when delayed allocation is used, we don't add inode to transaction's list of inodes needing flushing before commit. Originally we were doing that but commit f3b59291a69d removed the logic with a flawed argument that it is not needed. The problem is that although for delayed allocated blocks we write their contents immediately after allocating them, there is no guarantee that the IO scheduler or device doesn't reorder things and thus transaction allocating blocks and attaching them to inode can reach stable storage before actual block contents. Actually whenever we attach freshly allocated blocks to inode using a written extent, we should add inode to transaction's ordered inode list to make sure we properly wait for block contents to be written before committing the transaction. So that is what we do in this patch. This also handles other cases where stale data exposure was possible - like filling hole via mmap in data=ordered,nodelalloc mode. The only exception to the above rule are extending direct IO writes where blkdev_direct_IO() waits for IO to complete before increasing i_size and thus stale data exposure is not possible. For now we don't complicate the code with optimizing this special case since the overhead is pretty low. In case this is observed to be a performance problem we can always handle it using a special flag to ext4_map_blocks(). CC: stable@vger.kernel.org Fixes: f3b59291a69d0b734be1fc8be489fef2dd846d3d Reported-by: "HUANG Weller (CM/ESW12-CN)" Tested-by: "HUANG Weller (CM/ESW12-CN)" Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 10e6847a353761dbd0c710feed6c530c3a5f62af Author: Andrey Konovalov Date: Thu Nov 2 10:38:21 2017 -0400 media: dib0700: fix invalid dvb_detach argument [ Upstream commit eb0c19942288569e0ae492476534d5a485fb8ab4 ] dvb_detach(arg) calls symbol_put_addr(arg), where arg should be a pointer to a function. Right now a pointer to state->dib7000p_ops is passed to dvb_detach(), which causes a BUG() in symbol_put_addr() as discovered by syzkaller. Pass state->dib7000p_ops.set_wbd_ref instead. ------------[ cut here ]------------ kernel BUG at kernel/module.c:1081! invalid opcode: 0000 [#1] PREEMPT SMP KASAN Modules linked in: CPU: 1 PID: 1151 Comm: kworker/1:1 Tainted: G W 4.14.0-rc1-42251-gebb2c2437d80 #224 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event task: ffff88006a336300 task.stack: ffff88006a7c8000 RIP: 0010:symbol_put_addr+0x54/0x60 kernel/module.c:1083 RSP: 0018:ffff88006a7ce210 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880062a8d190 RCX: 0000000000000000 RDX: dffffc0000000020 RSI: ffffffff85876d60 RDI: ffff880062a8d190 RBP: ffff88006a7ce218 R08: 1ffff1000d4f9c12 R09: 1ffff1000d4f9ae4 R10: 1ffff1000d4f9bed R11: 0000000000000000 R12: ffff880062a8d180 R13: 00000000ffffffed R14: ffff880062a8d190 R15: ffff88006947c000 FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6416532000 CR3: 00000000632f5000 CR4: 00000000000006e0 Call Trace: stk7070p_frontend_attach+0x515/0x610 drivers/media/usb/dvb-usb/dib0700_devices.c:1013 dvb_usb_adapter_frontend_init+0x32b/0x660 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:286 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86 dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:162 dvb_usb_device_init+0xf70/0x17f0 drivers/media/usb/dvb-usb/dvb-usb-init.c:277 dib0700_probe+0x171/0x5a0 drivers/media/usb/dvb-usb/dib0700_core.c:886 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:413 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523 device_add+0xd0b/0x1660 drivers/base/core.c:1835 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266 really_probe drivers/base/dd.c:413 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523 device_add+0xd0b/0x1660 drivers/base/core.c:1835 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457 hub_port_connect drivers/usb/core/hub.c:4903 hub_port_connect_change drivers/usb/core/hub.c:5009 port_event drivers/usb/core/hub.c:5115 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119 worker_thread+0x221/0x1850 kernel/workqueue.c:2253 kthread+0x3a1/0x470 kernel/kthread.c:231 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431 Code: ff ff 48 85 c0 74 24 48 89 c7 e8 48 ea ff ff bf 01 00 00 00 e8 de 20 e3 ff 65 8b 05 b7 2f c2 7e 85 c0 75 c9 e8 f9 0b c1 ff eb c2 <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 b8 00 00 RIP: symbol_put_addr+0x54/0x60 RSP: ffff88006a7ce210 ---[ end trace b75b357739e7e116 ]--- Signed-off-by: Andrey Konovalov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 95dba59e4def2ccef608665ed2439e1f8ff38799 Author: Arvind Yadav Date: Mon Oct 9 20:14:48 2017 +0200 media: imon: Fix null-ptr-deref in imon_probe [ Upstream commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 ] It seems that the return value of usb_ifnum_to_if() can be NULL and needs to be checked. Signed-off-by: Arvind Yadav Tested-by: Andrey Konovalov Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a1754697ffb36173b1804416fd5cc768bbbc47ad Author: Chi-hsien Lin Date: Thu May 18 17:22:19 2017 +0800 brcmfmac: remove setting IBSS mode when stopping AP [ Upstream commit 9029679f66d976f8c720eb03c4898274803c9923 ] Upon stopping an AP interface the driver disable INFRA mode effectively setting the interface in IBSS mode. However, this may affect other interfaces running in INFRA mode. For instance, if user creates and stops hostap daemon on virtual interface, then association cannot work on primary interface because default BSS has been set to IBSS mode in firmware side. The IBSS mode should be set when cfg80211 changes the interface. Reviewed-by: Wright Feng Signed-off-by: Chi-hsien Lin [kvalo@codeaurora.org: rephased commit log based on discussion] Signed-off-by: Wright Feng Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 58e1fb13e2bcde09f732055c9a2414cd9e222a4e Author: Bilal Amarni Date: Thu Jun 8 14:47:26 2017 +0100 security/keys: add CONFIG_KEYS_COMPAT to Kconfig [ Upstream commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 ] CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for several 64-bit architectures : mips, parisc, tile. At the moment and for those architectures, calling in 32-bit userspace the keyctl syscall would return an ENOSYS error. This patch moves the CONFIG_KEYS_COMPAT option to security/keys/Kconfig, to make sure the compatibility wrapper is registered by default for any 64-bit architecture as long as it is configured with CONFIG_COMPAT. [DH: Modified to remove arm64 compat enablement also as requested by Eric Biggers] Signed-off-by: Bilal Amarni Signed-off-by: David Howells Reviewed-by: Arnd Bergmann cc: Eric Biggers Signed-off-by: James Morris Signed-off-by: Sasha Levin commit 0ed361e53713c508d10db5b7c47a41845abf1267 Author: Xin Long Date: Thu Oct 26 19:19:56 2017 +0800 ipip: only increase err_count for some certain type icmp in ipip_err [ Upstream commit f3594f0a7ea36661d7fd942facd7f31a64245f1a ] t->err_count is used to count the link failure on tunnel and an err will be reported to user socket in tx path if t->err_count is not 0. udp socket could even return EHOSTUNREACH to users. Since commit fd58156e456d ("IPIP: Use ip-tunneling code.") removed the 'switch check' for icmp type in ipip_err(), err_count would be increased by the icmp packet with ICMP_EXC_FRAGTIME code. an link failure would be reported out due to this. In Jianlin's case, when receiving ICMP_EXC_FRAGTIME a icmp packet, udp netperf failed with the err: send_data: data send error: No route to host (errno 113) We expect this error reported from tunnel to socket when receiving some certain type icmp, but not ICMP_EXC_FRAGTIME, ICMP_SR_FAILED or ICMP_PARAMETERPROB ones. This patch is to bring 'switch check' for icmp type back to ipip_err so that it only reports link failure for the right type icmp, just as in ipgre_err() and ipip6_err(). Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.") Reported-by: Jianlin Shi Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b3ddcc298910341a8e2919f84ef435b2f4e91a89 Author: Xin Long Date: Sat Oct 28 02:13:29 2017 +0800 sctp: reset owner sk for data chunks on out queues when migrating a sock [ Upstream commit d04adf1b355181e737b6b1e23d801b07f0b7c4c0 ] Now when migrating sock to another one in sctp_sock_migrate(), it only resets owner sk for the data in receive queues, not the chunks on out queues. It would cause that data chunks length on the sock is not consistent with sk sk_wmem_alloc. When closing the sock or freeing these chunks, the old sk would never be freed, and the new sock may crash due to the overflow sk_wmem_alloc. syzbot found this issue with this series: r0 = socket$inet_sctp() sendto$inet(r0) listen(r0) accept4(r0) close(r0) Although listen() should have returned error when one TCP-style socket is in connecting (I may fix this one in another patch), it could also be reproduced by peeling off an assoc. This issue is there since very beginning. This patch is to reset owner sk for the chunks on out queues so that sk sk_wmem_alloc has correct value after accept one sock or peeloff an assoc to one sock. Note that when resetting owner sk for chunks on outqueue, it has to sctp_clear_owner_w/skb_orphan chunks before changing assoc->base.sk first and then sctp_set_owner_w them after changing assoc->base.sk, due to that sctp_wfree and it's callees are using assoc->base.sk. Reported-by: Dmitry Vyukov Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 54e87a6e36afc6939355f7459ae12e0ada21721d Author: Julien Gomes Date: Wed Oct 25 11:50:50 2017 -0700 tun: allow positive return values on dev_get_valid_name() call [ Upstream commit 5c25f65fd1e42685f7ccd80e0621829c105785d9 ] If the name argument of dev_get_valid_name() contains "%d", it will try to assign it a unit number in __dev__alloc_name() and return either the unit number (>= 0) or an error code (< 0). Considering positive values as error values prevent tun device creations relying this mechanism, therefor we should only consider negative values as errors here. Signed-off-by: Julien Gomes Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d43600f2129c3d34eb22f75c1038d13df6aca5eb Author: Andrei Vagin Date: Wed Oct 25 10:16:42 2017 -0700 net/unix: don't show information about sockets from other namespaces [ Upstream commit 0f5da659d8f1810f44de14acf2c80cd6499623a0 ] socket_diag shows information only about sockets from a namespace where a diag socket lives. But if we request information about one unix socket, the kernel don't check that its netns is matched with a diag socket namespace, so any user can get information about any unix socket in a system. This looks like a bug. v2: add a Fixes tag Fixes: 51d7cccf0723 ("net: make sock diag per-namespace") Signed-off-by: Andrei Vagin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 46683fcf1965b258ff9fa8aefffbf468af17f8c1 Author: Eric Dumazet Date: Sat Oct 21 12:26:23 2017 -0700 ipv6: flowlabel: do not leave opt->tot_len with garbage [ Upstream commit 864e2a1f8aac05effac6063ce316b480facb46ff ] When syzkaller team brought us a C repro for the crash [1] that had been reported many times in the past, I finally could find the root cause. If FlowLabel info is merged by fl6_merge_options(), we leave part of the opt_space storage provided by udp/raw/l2tp with random value in opt_space.tot_len, unless a control message was provided at sendmsg() time. Then ip6_setup_cork() would use this random value to perform a kzalloc() call. Undefined behavior and crashes. Fix is to properly set tot_len in fl6_merge_options() At the same time, we can also avoid consuming memory and cpu cycles to clear it, if every option is copied via a kmemdup(). This is the change in ip6_setup_cork(). [1] kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 0 PID: 6613 Comm: syz-executor0 Not tainted 4.14.0-rc4+ #127 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 task: ffff8801cb64a100 task.stack: ffff8801cc350000 RIP: 0010:ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168 RSP: 0018:ffff8801cc357550 EFLAGS: 00010203 RAX: dffffc0000000000 RBX: ffff8801cc357748 RCX: 0000000000000010 RDX: 0000000000000002 RSI: ffffffff842bd1d9 RDI: 0000000000000014 RBP: ffff8801cc357620 R08: ffff8801cb17f380 R09: ffff8801cc357b10 R10: ffff8801cb64a100 R11: 0000000000000000 R12: ffff8801cc357ab0 R13: ffff8801cc357b10 R14: 0000000000000000 R15: ffff8801c3bbf0c0 FS: 00007f9c5c459700(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020324000 CR3: 00000001d1cf2000 CR4: 00000000001406f0 DR0: 0000000020001010 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 Call Trace: ip6_make_skb+0x282/0x530 net/ipv6/ip6_output.c:1729 udpv6_sendmsg+0x2769/0x3380 net/ipv6/udp.c:1340 inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 SYSC_sendto+0x358/0x5a0 net/socket.c:1750 SyS_sendto+0x40/0x50 net/socket.c:1718 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4520a9 RSP: 002b:00007f9c5c458c08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 00000000004520a9 RDX: 0000000000000001 RSI: 0000000020fd1000 RDI: 0000000000000016 RBP: 0000000000000086 R08: 0000000020e0afe4 R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004bb1ee R13: 00000000ffffffff R14: 0000000000000016 R15: 0000000000000029 Code: e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ea 0f 00 00 48 8d 79 04 48 b8 00 00 00 00 00 fc ff df 45 8b 74 24 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 RIP: ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168 RSP: ffff8801cc357550 Signed-off-by: Eric Dumazet Reported-by: Dmitry Vyukov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2428532b076b0ab6a0e3af69ae75554bced08007 Author: Xin Long Date: Wed Oct 18 21:37:49 2017 +0800 sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect [ Upstream commit 1cc276cec9ec574d41cf47dfc0f51406b6f26ab4 ] Now sctp processes icmp redirect packet in sctp_icmp_redirect where it calls sctp_transport_dst_check in which tp->dst can be released. The problem is before calling sctp_transport_dst_check, it doesn't check sock_owned_by_user, which means tp->dst could be freed while a process is accessing it with owning the socket. An use-after-free issue could be triggered by this. This patch is to fix it by checking sock_owned_by_user before calling sctp_transport_dst_check in sctp_icmp_redirect, so that it would not release tp->dst if users still hold sock lock. Besides, the same issue fixed in commit 45caeaa5ac0b ("dccp/tcp: fix routing redirect race") on sctp also needs this check. Fixes: 55be7a9c6074 ("ipv4: Add redirect support to all protocol icmp error handlers") Reported-by: Eric Dumazet Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9bcd3577312ffa7e52b42e94ef3cf74d06e7b42f Author: Cong Wang Date: Fri Oct 13 11:58:53 2017 -0700 tun: call dev_get_valid_name() before register_netdevice() [ Upstream commit 0ad646c81b2182f7fa67ec0c8c825e0ee165696d ] register_netdevice() could fail early when we have an invalid dev name, in which case ->ndo_uninit() is not called. For tun device, this is a problem because a timer etc. are already initialized and it expects ->ndo_uninit() to clean them up. We could move these initializations into a ->ndo_init() so that register_netdevice() knows better, however this is still complicated due to the logic in tun_detach(). Therefore, I choose to just call dev_get_valid_name() before register_netdevice(), which is quicker and much easier to audit. And for this specific case, it is already enough. Fixes: 96442e42429e ("tuntap: choose the txq based on rxq") Reported-by: Dmitry Alexeev Cc: Jason Wang Cc: "Michael S. Tsirkin" Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6cef30faac469de48ffb2c6245f03d9128f6efef Author: Guillaume Nault Date: Fri Oct 13 19:22:35 2017 +0200 l2tp: check ps->sock before running pppol2tp_session_ioctl() [ Upstream commit 5903f594935a3841137c86b9d5b75143a5b7121c ] When pppol2tp_session_ioctl() is called by pppol2tp_tunnel_ioctl(), the session may be unconnected. That is, it was created by pppol2tp_session_create() and hasn't been connected with pppol2tp_connect(). In this case, ps->sock is NULL, so we need to check for this case in order to avoid dereferencing a NULL pointer. Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP") Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5cabef21a8fa20704f23efa60d535a4ced702a38 Author: Eric Dumazet Date: Mon Oct 30 23:08:20 2017 -0700 tcp: fix tcp_mtu_probe() vs highest_sack [ Upstream commit 2b7cda9c35d3b940eb9ce74b30bbd5eb30db493d ] Based on SNMP values provided by Roman, Yuchung made the observation that some crashes in tcp_sacktag_walk() might be caused by MTU probing. Looking at tcp_mtu_probe(), I found that when a new skb was placed in front of the write queue, we were not updating tcp highest sack. If one skb is freed because all its content was copied to the new skb (for MTU probing), then tp->highest_sack could point to a now freed skb. Bad things would then happen, including infinite loops. This patch renames tcp_highest_sack_combine() and uses it from tcp_mtu_probe() to fix the bug. Note that I also removed one test against tp->sacked_out, since we want to replace tp->highest_sack regardless of whatever condition, since keeping a stale pointer to freed skb is a recipe for disaster. Fixes: a47e5a988a57 ("[TCP]: Convert highest_sack to sk_buff to allow direct access") Signed-off-by: Eric Dumazet Reported-by: Alexei Starovoitov Reported-by: Roman Gushchin Reported-by: Oleksandr Natalenko Acked-by: Alexei Starovoitov Acked-by: Neal Cardwell Acked-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0ab664ae906dbb60bde678f600b0fd0fadd5e69b Author: Craig Gallek Date: Mon Oct 30 18:50:11 2017 -0400 tun/tap: sanitize TUNSETSNDBUF input [ Upstream commit 93161922c658c714715686cd0cf69b090cb9bf1d ] Syzkaller found several variants of the lockup below by setting negative values with the TUNSETSNDBUF ioctl. This patch adds a sanity check to both the tun and tap versions of this ioctl. watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [repro:2389] Modules linked in: irq event stamp: 329692056 hardirqs last enabled at (329692055): [] _raw_spin_unlock_irqrestore+0x31/0x75 hardirqs last disabled at (329692056): [] apic_timer_interrupt+0x98/0xb0 softirqs last enabled at (35659740): [] __do_softirq+0x328/0x48c softirqs last disabled at (35659731): [] irq_exit+0xbc/0xd0 CPU: 0 PID: 2389 Comm: repro Not tainted 4.14.0-rc7 #23 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff880009452140 task.stack: ffff880006a20000 RIP: 0010:_raw_spin_lock_irqsave+0x11/0x80 RSP: 0018:ffff880006a27c50 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff10 RAX: ffff880009ac68d0 RBX: ffff880006a27ce0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff880006a27ce0 RDI: ffff880009ac6900 RBP: ffff880006a27c60 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 000000000063ff00 R12: ffff880009ac6900 R13: ffff880006a27cf8 R14: 0000000000000001 R15: ffff880006a27cf8 FS: 00007f4be4838700(0000) GS:ffff88000cc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020101000 CR3: 0000000009616000 CR4: 00000000000006f0 Call Trace: prepare_to_wait+0x26/0xc0 sock_alloc_send_pskb+0x14e/0x270 ? remove_wait_queue+0x60/0x60 tun_get_user+0x2cc/0x19d0 ? __tun_get+0x60/0x1b0 tun_chr_write_iter+0x57/0x86 __vfs_write+0x156/0x1e0 vfs_write+0xf7/0x230 SyS_write+0x57/0xd0 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x7f4be4356df9 RSP: 002b:00007ffc18101c08 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4be4356df9 RDX: 0000000000000046 RSI: 0000000020101000 RDI: 0000000000000005 RBP: 00007ffc18101c40 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000293 R12: 0000559c75f64780 R13: 00007ffc18101d30 R14: 0000000000000000 R15: 0000000000000000 Fixes: 33dccbb050bb ("tun: Limit amount of queued packets per device") Fixes: 20d29d7a916a ("net: macvtap driver") Signed-off-by: Craig Gallek Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c617803955ec5ec9a0310e76e34e4e03e02ca803 Author: Takashi Iwai Date: Tue Sep 12 12:41:20 2017 +0200 ALSA: seq: Cancel pending autoload work at unbinding device [ Upstream commit fc27fe7e8deef2f37cba3f2be2d52b6ca5eb9d57 ] ALSA sequencer core has a mechanism to load the enumerated devices automatically, and it's performed in an off-load work. This seems causing some race when a sequencer is removed while the pending autoload work is running. As syzkaller spotted, it may lead to some use-after-free: BUG: KASAN: use-after-free in snd_rawmidi_dev_seq_free+0x69/0x70 sound/core/rawmidi.c:1617 Write of size 8 at addr ffff88006c611d90 by task kworker/2:1/567 CPU: 2 PID: 567 Comm: kworker/2:1 Not tainted 4.13.0+ #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: events autoload_drivers Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x192/0x22c lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x230/0x340 mm/kasan/report.c:409 __asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435 snd_rawmidi_dev_seq_free+0x69/0x70 sound/core/rawmidi.c:1617 snd_seq_dev_release+0x4f/0x70 sound/core/seq_device.c:192 device_release+0x13f/0x210 drivers/base/core.c:814 kobject_cleanup lib/kobject.c:648 [inline] kobject_release lib/kobject.c:677 [inline] kref_put include/linux/kref.h:70 [inline] kobject_put+0x145/0x240 lib/kobject.c:694 put_device+0x25/0x30 drivers/base/core.c:1799 klist_devices_put+0x36/0x40 drivers/base/bus.c:827 klist_next+0x264/0x4a0 lib/klist.c:403 next_device drivers/base/bus.c:270 [inline] bus_for_each_dev+0x17e/0x210 drivers/base/bus.c:312 autoload_drivers+0x3b/0x50 sound/core/seq_device.c:117 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231 kthread+0x324/0x3f0 kernel/kthread.c:231 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425 The fix is simply to assure canceling the autoload work at removing the device. Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 84513107dc8602c675ec871b616128b49c6e259e Author: Dmitry Torokhov Date: Sat Oct 7 11:07:47 2017 -0700 Input: ims-psu - check if CDC union descriptor is sane [ Upstream commit ea04efee7635c9120d015dcdeeeb6988130cb67a ] Before trying to use CDC union descriptor, try to validate whether that it is sane by checking that intf->altsetting->extra is big enough and that descriptor bLength is not too big and not too small. Reported-by: Andrey Konovalov Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit b3c0b63e11eda6ef786fc35e0126e6e5ff828913 Author: Alan Stern Date: Fri Sep 29 10:54:24 2017 -0400 usb: usbtest: fix NULL pointer dereference [ Upstream commit 7c80f9e4a588f1925b07134bb2e3689335f6c6d8 ] If the usbtest driver encounters a device with an IN bulk endpoint but no OUT bulk endpoint, it will try to dereference a NULL pointer (out->desc.bEndpointAddress). The problem can be solved by adding a missing test. Signed-off-by: Alan Stern Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit ffff8defb5b4bc855a55ba160a3efeefb51e55fd Author: Johannes Berg Date: Tue Oct 24 21:12:13 2017 +0200 mac80211: don't compare TKIP TX MIC key in reinstall prevention [ Upstream commit cfbb0d90a7abb289edc91833d0905931f8805f12 ] For the reinstall prevention, the code I had added compares the whole key. It turns out though that iwlwifi firmware doesn't provide the TKIP TX MIC key as it's not needed in client mode, and thus the comparison will always return false. For client mode, thus always zero out the TX MIC key part before doing the comparison in order to avoid accepting the reinstall of the key with identical encryption and RX MIC key, but not the same TX MIC key (since the supplicant provides the real one.) Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit db6a015e846a747a4b8a96daad1d9ff59454c0cc Author: Jason A. Donenfeld Date: Tue Oct 17 20:32:07 2017 +0200 mac80211: use constant time comparison with keys [ Upstream commit 2bdd713b92a9cade239d3c7d15205a09f556624d ] Otherwise we risk leaking information via timing side channel. Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") Signed-off-by: Jason A. Donenfeld Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 003aa22c9619b49efe950aca3aebd1235a04940d Author: Johannes Berg Date: Tue Sep 5 14:54:54 2017 +0200 mac80211: accept key reinstall without changing anything [ Upstream commit fdf7cb4185b60c68e1a75e61691c4afdc15dea0e ] When a key is reinstalled we can reset the replay counters etc. which can lead to nonce reuse and/or replay detection being impossible, breaking security properties, as described in the "KRACK attacks". In particular, CVE-2017-13080 applies to GTK rekeying that happened in firmware while the host is in D3, with the second part of the attack being done after the host wakes up. In this case, the wpa_supplicant mitigation isn't sufficient since wpa_supplicant doesn't know the GTK material. In case this happens, simply silently accept the new key coming from userspace but don't take any action on it since it's the same key; this keeps the PN replay counters intact. Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5bc2cd75720b00ab1f02b3783cb608c5345c39a5 Author: Borislav Petkov Date: Tue Nov 7 18:53:07 2017 +0100 x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context [ Upstream commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da ] The warning below says it all: BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1 caller is __this_cpu_preempt_check CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4 Call Trace: dump_stack check_preemption_disabled ? do_early_param __this_cpu_preempt_check arch_perfmon_init op_nmi_init ? alloc_pci_root_info oprofile_arch_init oprofile_init do_one_initcall ... These accessors should not have been used in the first place: it is PPro so no mixed silicon revisions and thus it can simply use boot_cpu_data. Reported-by: Fengguang Wu Tested-by: Fengguang Wu Fix-creation-mandated-by: Linus Torvalds Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: Robert Richter Cc: x86@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ccc985eb3e67085cd02dace96014a2a5a9247d97 Author: Richard Schütz Date: Sun Oct 29 13:03:22 2017 +0100 can: c_can: don't indicate triple sampling support for D_CAN [ Upstream commit fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 ] The D_CAN controller doesn't provide a triple sampling mode, so don't set the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling triple sampling is a no-op. Signed-off-by: Richard Schütz Cc: linux-stable # >= v3.6 Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit fea04c3a158ae110a014d3102c01b41f9fe1f7d3 Author: Ilya Dryomov Date: Mon Nov 6 11:33:36 2017 +0100 rbd: use GFP_NOIO for parent stat and data requests [ Upstream commit 1e37f2f84680fa7f8394fd444b6928e334495ccc ] rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on the writeback path for cloned images -- we attempt a stat on the parent object to see if it exists and potentially read it in to call copyup. GFP_NOIO should be used instead of GFP_KERNEL here. Cc: stable@vger.kernel.org Link: http://tracker.ceph.com/issues/22014 Signed-off-by: Ilya Dryomov Reviewed-by: David Disseldorp Signed-off-by: Sasha Levin commit 7fa5db224efef5a2aa4d8cfcca2ffc4d300f134d Author: Oswald Buddenhagen Date: Sun Oct 29 16:27:20 2017 +0100 MIPS: AR7: Ensure that serial ports are properly set up [ Upstream commit b084116f8587b222a2c5ef6dcd846f40f24b9420 ] Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is never copied, resulting in a dead port. Fixes: 154615d55459 ("MIPS: AR7: Use correct UART port type") Signed-off-by: Oswald Buddenhagen [jonas.gorski: add Fixes tag] Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Cc: Ralf Baechle Cc: Greg Kroah-Hartman Cc: Yoshihiro YUNOMAE Cc: Nicolas Schichan Cc: Oswald Buddenhagen Cc: linux-mips@linux-mips.org Cc: linux-serial@vger.kernel.org Cc: Patchwork: https://patchwork.linux-mips.org/patch/17543/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 9568cf6348ff46e2a09699f48818c460294b5b98 Author: Jonas Gorski Date: Sun Oct 29 16:27:19 2017 +0100 MIPS: AR7: Defer registration of GPIO [ Upstream commit e6b03ab63b4d270e0249f96536fde632409dc1dc ] When called from prom init code, ar7_gpio_init() will fail as it will call gpiochip_add() which relies on a working kmalloc() to alloc the gpio_desc array and kmalloc is not useable yet at prom init time. Move ar7_gpio_init() to ar7_register_devices() (a device_initcall) where kmalloc works. Fixes: 14e85c0e69d5 ("gpio: remove gpio_descs global array") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Cc: Ralf Baechle Cc: Greg Kroah-Hartman Cc: Yoshihiro YUNOMAE Cc: Nicolas Schichan Cc: linux-mips@linux-mips.org Cc: linux-serial@vger.kernel.org Cc: # 3.19+ Patchwork: https://patchwork.linux-mips.org/patch/17542/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit cc0b03b2fcea5a46d7f86460b476a7d2ef0f143b Author: Luis R. Rodriguez Date: Mon Jan 23 08:11:07 2017 -0800 tools: firmware: check for distro fallback udev cancel rule [ Upstream commit afb999cdef69148f366839e74470d8f5375ba5f1 ] Some distributions (Debian, OpenSUSE) have a udev rule in place to cancel all fallback mechanism uevents immediately. This would obviously make it hard to test against the fallback mechanism test interface, so we need to check for this. Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9873619cda31f4f1816da39d112e19195c079892 Author: Luis R. Rodriguez Date: Fri Dec 16 03:10:35 2016 -0800 selftests: firmware: send expected errors to /dev/null [ Upstream commit 880444e214cfd293a2e8cc4bd3505f7ffa6ce33a ] Error that we expect should not be spilled to stdout. Without this we get: ./fw_filesystem.sh: line 58: printf: write error: Invalid argument ./fw_filesystem.sh: line 63: printf: write error: No such device ./fw_filesystem.sh: line 69: echo: write error: No such file or directory ./fw_filesystem.sh: filesystem loading works ./fw_filesystem.sh: async filesystem loading works With it: ./fw_filesystem.sh: filesystem loading works ./fw_filesystem.sh: async filesystem loading works Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 368fa63769739d61faa4f94227fe00a18478435c Author: Brian Norris Date: Wed Dec 9 14:50:29 2015 -0800 selftests: firmware: add empty string and async tests [ Upstream commit 1b1fe542b6f010cf6bc7e1c92805e1c0e133e007 ] Now that we've added a 'trigger_async_request' knob to test the request_firmware_nowait() API, let's use it. Also add tests for the empty ("") string, since there have been a couple errors in that handling already. Since we now have real ways that the sysfs write might fail, let's add the appropriate check on the 'echo' lines too. Signed-off-by: Brian Norris Acked-by: Kees Cook Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 1201551923258d881d3da469f7e40b4bdd4798f8 Author: Brian Norris Date: Wed Dec 9 14:50:25 2015 -0800 test: firmware_class: report errors properly on failure [ Upstream commit 47e0bbb7fa985a0f1b5794a8653fae4f8f49de77 ] request_firmware() failures currently won't get reported at all (the error code is discarded). What's more, we get confusing messages, like: # echo -n notafile > /sys/devices/virtual/misc/test_firmware/trigger_request [ 8280.311856] test_firmware: loading 'notafile' [ 8280.317042] test_firmware: load of 'notafile' failed: -2 [ 8280.322445] test_firmware: loaded: 0 # echo $? 0 Report the failures via write() errors, and don't say we "loaded" anything. Signed-off-by: Brian Norris Acked-by: Kees Cook Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit ce22f7f94f48f6280e278d905665ababd757d302 Author: Matt Redfearn Date: Wed Sep 27 10:13:25 2017 +0100 MIPS: SMP: Fix deadlock & online race [ Upstream commit 9e8c399a88f0b87e41a894911475ed2a8f8dff9e ] Commit 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") effectively reverted commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online") and thus has reinstated the possibility of deadlock. The commit was based on testing of kernel v4.4, where the CPU hotplug core code issued a BUG() if the starting CPU is not marked online when the boot CPU returns from __cpu_up. The commit fixes this race (in v4.4), but re-introduces the deadlock situation. As noted in the commit message, upstream differs in this area. Commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up") adds a completion event in the CPU hotplug core code, making this race impossible. However, people were unhappy with relying on the core code to do the right thing. To address the issues both commits were trying to fix, add a second completion event in the MIPS smp hotplug path. It removes the possibility of a race, since the MIPS smp hotplug code now synchronises both the boot and secondary CPUs before they return to the hotplug core code. It also addresses the deadlock by ensuring that the secondary CPU is not marked online before it's counters are synchronised. This fix should also be backported to fix the race condition introduced by the backport of commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online"), through really that race only existed before commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up"). Signed-off-by: Matt Redfearn Fixes: 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") CC: Matija Glavinic Pecotic Cc: # v4.1+: 8f46cca1e6c0: "MIPS: SMP: Fix possibility of deadlock when bringing CPUs online" Cc: # v4.1+: a00eeede507c: "MIPS: SMP: Use a completion event to signal CPU up" Cc: # v4.1+: 6f542ebeaee0: "MIPS: Fix race on setting and getting cpu_online_mask" Cc: # v4.1+ Patchwork: https://patchwork.linux-mips.org/patch/17376/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit c3cba1e87164cd514a92f7ddcd8d05fdcfac87b9 Author: Matija Glavinic Pecotic Date: Thu Aug 3 08:20:22 2017 +0200 MIPS: Fix race on setting and getting cpu_online_mask [ Upstream commit 6f542ebeaee0ee552a902ce3892220fc22c7ec8e ] While testing cpu hoptlug (cpu down and up in loops) on kernel 4.4, it was observed that occasionally check for cpu online will fail in kernel/cpu.c, _cpu_up: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/kernel/cpu.c?h=v4.4.79#n485 518 /* Arch-specific enabling code. */ 519 ret = __cpu_up(cpu, idle); 520 521 if (ret != 0) 522 goto out_notify; 523 BUG_ON(!cpu_online(cpu)); Reason is race between start_secondary and _cpu_up. cpu_callin_map is set before cpu_online_mask. In __cpu_up, cpu_callin_map is waited for, but cpu online mask is not, resulting in race in which secondary processor started and set cpu_callin_map, but not yet set the online mask,resulting in above BUG being hit. Upstream differs in the area. cpu_online check is in bringup_wait_for_ap, which is after cpu reached AP_ONLINE_IDLE,where secondary passed its start function. Nonetheless, fix makes start_secondary safe and not depending on other locks throughout the code. It protects as well against cpu_online checks put in between sometimes in the future. Fix this by moving completion after all flags are set. Signed-off-by: Matija Glavinic Pecotic Cc: Alexander Sverdlin Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16925/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit 7c69ade19896f9acf64fded92ce27e0991972a5c Author: Matt Redfearn Date: Fri Nov 4 09:28:56 2016 +0000 MIPS: SMP: Use a completion event to signal CPU up [ Upstream commit a00eeede507c975087b7b8df8cf2c9f88ba285de ] If a secondary CPU failed to start, for any reason, the CPU requesting the secondary to start would get stuck in the loop waiting for the secondary to be present in the cpu_callin_map. Rather than that, use a completion event to signal that the secondary CPU has started and is waiting to synchronise counters. Since the CPU presence will no longer be marked in cpu_callin_map, remove the redundant test from arch_cpu_idle_dead(). Signed-off-by: Matt Redfearn Cc: Maciej W. Rozycki Cc: Jiri Slaby Cc: Paul Gortmaker Cc: Chris Metcalf Cc: Thomas Gleixner Cc: Qais Yousef Cc: James Hogan Cc: Paul Burton Cc: Marcin Nowakowski Cc: Andrew Morton Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14502/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin commit b52ba3495bbac74c48d733c5a713b93542ecd92b Author: Paul Burton Date: Tue Oct 31 15:09:22 2017 -0700 MIPS: Fix CM region target definitions [ Upstream commit 6a6cba1d945a7511cdfaf338526871195e420762 ] The default CM target field in the GCR_BASE register is encoded with 0 meaning memory & 1 being reserved. However the definitions we use for those bits effectively get these two values backwards - likely because they were copied from the definitions for the CM regions where the target is encoded differently. This results in use setting up GCR_BASE with the reserved target value by default, rather than targeting memory as intended. Although we currently seem to get away with this it's not a great idea to rely upon. Fix this by changing our macros to match the documentated target values. The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") in the Linux v3.15 cycle, and was likely carried forwards from older but unused code introduced by commit 39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the v2.6.26 cycle. Fixes: 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") Signed-off-by: Paul Burton Reported-by: Matt Redfearn Reviewed-by: James Hogan Cc: Matt Redfearn Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17562/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit cf9dfe611df7fed447c8d09943704dafa8cf87da Author: Gustavo A. R. Silva Date: Tue Oct 31 00:35:03 2017 -0500 MIPS: microMIPS: Fix incorrect mask in insn_table_MM [ Upstream commit 77238e76b9156d28d86c1e31c00ed2960df0e4de ] It seems that this is a typo error and the proper bit masking is "RT | RS" instead of "RS | RS". This issue was detected with the help of Coccinelle. Fixes: d6b3314b49e1 ("MIPS: uasm: Add lh uam instruction") Reported-by: Julia Lawall Signed-off-by: Gustavo A. R. Silva Reviewed-by: James Hogan Cc: # 3.16+ Patchwork: https://patchwork.linux-mips.org/patch/17551/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 1437d2f78eb1aac418b549915fa39adb065ba10b Author: Takashi Iwai Date: Mon Nov 6 20:16:50 2017 +0100 ALSA: seq: Avoid invalid lockdep class warning [ Upstream commit 3510c7aa069aa83a2de6dab2b41401a198317bdc ] The recent fix for adding rwsem nesting annotation was using the given "hop" argument as the lock subclass key. Although the idea itself works, it may trigger a kernel warning like: BUG: looking up invalid subclass: 8 .... since the lockdep has a smaller number of subclasses (8) than we currently allow for the hops there (10). The current definition is merely a sanity check for avoiding the too deep delivery paths, and the 8 hops are already enough. So, as a quick fix, just follow the max hops as same as the max lockdep subclasses. Fixes: 1f20f9ff57ca ("ALSA: seq: Fix nested rwsem annotation for lockdep splat") Reported-by: syzbot Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b975b771930e4931a11f9d6fe7d9d54fd884c8ea Author: Takashi Iwai Date: Tue Nov 7 16:05:24 2017 +0100 ALSA: seq: Fix OSS sysex delivery in OSS emulation [ Upstream commit 132d358b183ac6ad8b3fea32ad5e0663456d18d1 ] The SYSEX event delivery in OSS sequencer emulation assumed that the event is encoded in the variable-length data with the straight buffering. This was the normal behavior in the past, but during the development, the chained buffers were introduced for carrying more data, while the OSS code was left intact. As a result, when a SYSEX event with the chained buffer data is passed to OSS sequencer port, it may end up with the wrong memory access, as if it were having a too large buffer. This patch addresses the bug, by applying the buffer data expansion by the generic snd_seq_dump_var_event() helper function. Reported-by: syzbot Reported-by: Mark Salyzyn Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b015088a56ff94376d0d499087cac2dc1c5fa815 Author: Mark Rutland Date: Thu Nov 2 18:44:28 2017 +0100 ARM: 8720/1: ensure dump_instr() checks addr_limit [ Upstream commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 ] When CONFIG_DEBUG_USER is enabled, it's possible for a user to deliberately trigger dump_instr() with a chosen kernel address. Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory. So that we can use the same code to dump user instructions and kernel instructions, the common dumping code is factored out to __dump_instr(), with the fs manipulated appropriately in dump_instr() around calls to this. Signed-off-by: Mark Rutland Cc: stable@vger.kernel.org Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 33156b4899ee8ffeeca6151b5888a3453c53f42e Author: Eric Biggers Date: Tue Nov 7 22:29:02 2017 +0000 KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] [ Upstream commit 624f5ab8720b3371367327a822c267699c1823b8 ] syzkaller reported a NULL pointer dereference in asn1_ber_decoder(). It can be reproduced by the following command, assuming CONFIG_PKCS7_TEST_KEY=y: keyctl add pkcs7_test desc '' @s The bug is that if the data buffer is empty, an integer underflow occurs in the following check: if (unlikely(dp >= datalen - 1)) goto data_overrun_error; This results in the NULL data pointer being dereferenced. Fix it by checking for 'datalen - dp < 2' instead. Also fix the similar check for 'dp >= datalen - n' later in the same function. That one possibly could result in a buffer overread. The NULL pointer dereference was reproducible using the "pkcs7_test" key type but not the "asymmetric" key type because the "asymmetric" key type checks for a 0-length payload before calling into the ASN.1 decoder but the "pkcs7_test" key type does not. The bug report was: BUG: unable to handle kernel NULL pointer dereference at (null) IP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 PGD 7b708067 P4D 7b708067 PUD 7b6ee067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 522 Comm: syz-executor1 Not tainted 4.14.0-rc8 #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014 task: ffff9b6b3798c040 task.stack: ffff9b6b37970000 RIP: 0010:asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: 0018:ffff9b6b37973c78 EFLAGS: 00010216 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000021c RDX: ffffffff814a04ed RSI: ffffb1524066e000 RDI: ffffffff910759e0 RBP: ffff9b6b37973d60 R08: 0000000000000001 R09: ffff9b6b3caa4180 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f10ed1f2700(0000) GS:ffff9b6b3ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000007b6f3000 CR4: 00000000000006f0 Call Trace: pkcs7_parse_message+0xee/0x240 crypto/asymmetric_keys/pkcs7_parser.c:139 verify_pkcs7_signature+0x33/0x180 certs/system_keyring.c:216 pkcs7_preparse+0x41/0x70 crypto/asymmetric_keys/pkcs7_key_type.c:63 key_create_or_update+0x180/0x530 security/keys/key.c:855 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0xbf/0x250 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4585c9 RSP: 002b:00007f10ed1f1bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000f8 RAX: ffffffffffffffda RBX: 00007f10ed1f2700 RCX: 00000000004585c9 RDX: 0000000020000000 RSI: 0000000020008ffb RDI: 0000000020008000 RBP: 0000000000000000 R08: ffffffffffffffff R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff1b2260ae R13: 00007fff1b2260af R14: 00007f10ed1f2700 R15: 0000000000000000 Code: dd ca ff 48 8b 45 88 48 83 e8 01 4c 39 f0 0f 86 a8 07 00 00 e8 53 dd ca ff 49 8d 46 01 48 89 85 58 ff ff ff 48 8b 85 60 ff ff ff <42> 0f b6 0c 30 89 c8 88 8d 75 ff ff ff 83 e0 1f 89 8d 28 ff ff RIP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: ffff9b6b37973c78 CR2: 0000000000000000 Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder") Reported-by: syzbot Cc: # v3.7+ Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: James Morris Signed-off-by: Sasha Levin commit a88836e03824b5023167532b0f0cf5bbc91d346b Author: Andrey Ryabinin Date: Mon Oct 16 18:51:31 2017 +0300 crypto: x86/sha1-mb - fix panic due to unaligned access [ Upstream commit d041b557792c85677f17e08eee535eafbd6b9aa2 ] struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc() and later passed in sha1_mb_flusher_mgr_flush_avx2() function where instructions vmovdqa used to access the struct. vmovdqa requires 16-bytes aligned argument, but nothing guarantees that struct sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2") Signed-off-by: Andrey Ryabinin Cc: Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4734b2fb13da86312c31b487066e850bb866eced Author: Carlo Caione Date: Wed Apr 19 22:36:39 2017 +0200 platform/x86: hp-wmi: Do not shadow error values [ Upstream commit d313876925f3e7a480a02773fd333bcab9202d5e ] All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state, ...) using hp_wmi_perform_query to perform an HP WMI query shadow the returned value in case of error. We return -EINVAL only when the HP WMI query returns a positive value (the specific error code) to not mix this up with the actual value returned by the helper function. Suggested-by: Andy Shevchenko Signed-off-by: Carlo Caione Signed-off-by: Darren Hart (VMware) Signed-off-by: Sasha Levin commit 6269123a3cbbc54bf398f249f9303cc35ab9fe8e Author: Carlo Caione Date: Sun Apr 9 15:56:07 2017 +0200 platform/x86: hp-wmi: Fix error value for hp_wmi_tablet_state [ Upstream commit c7dfc2facbd69dad89b75e13c608da709668dcd0 ] hp_wmi_tablet_state() fails to return the correct error code when hp_wmi_perform_query() returns the HP WMI query specific error code that is a positive value. Signed-off-by: Carlo Caione Signed-off-by: Darren Hart (VMware) Signed-off-by: Sasha Levin commit 4bdd21e60b800877fa57dd585a3ba6a64cbe9f1d Author: Carlo Caione Date: Sun Apr 9 15:56:08 2017 +0200 platform/x86: hp-wmi: Fix detection for dock and tablet mode [ Upstream commit 298747b7579f5bbbced793d997b333fd10a24921 ] The current driver code is not checking for the error values returned by 'hp_wmi_dock_state()' and 'hp_wmi_tablet_state()' before passing the returned values down to 'input_report_switch()'. This error code is being translated to '1' in the input subsystem, reporting the wrong status. The biggest problem caused by this issue is that several laptops are wrongly reported by the driver as docked, preventing them to be put to sleep using the LID (and in most cases they are not even dockable). With this patch we create the report switches only if we are able to read the dock and tablet mode status correctly from ACPI. Signed-off-by: Carlo Caione Signed-off-by: Darren Hart (VMware) Signed-off-by: Sasha Levin commit 2535023f366b9705d7e927767a19bbfa66afd8a7 Author: Vivien Didelot Date: Mon Jan 9 16:49:26 2017 -0500 net: dsa: select NET_SWITCHDEV [ Upstream commit 3a89eaa65db68bf53bf92dedc60084f810e1779a ] The support for DSA Ethernet switch chips depends on TCP/IP networking, thus explicit that HAVE_NET_DSA depends on INET. DSA uses SWITCHDEV, thus select it instead of depending on it. Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Tested-by: Randy Dunlap Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8eb76021102d534fa14c3755125646ffb877da8c Author: Julian Wiedmann Date: Thu Jan 12 15:48:42 2017 +0100 s390/qeth: issue STARTLAN as first IPA command [ Upstream commit 1034051045d125579ab1e8fcd5a724eeb0e70149 ] STARTLAN needs to be the first IPA command after MPC initialization completes. So move the qeth_send_startlan() call from the layer disciplines into the core path, right after the MPC handshake. While at it, replace the magic LAN OFFLINE return code with the existing enum. Signed-off-by: Julian Wiedmann Reviewed-by: Thomas Richter Reviewed-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2faf550cd806c9caccdaceed38897cc70adc6f37 Author: Feras Daoud Date: Wed Dec 28 14:47:28 2016 +0200 IB/ipoib: Change list_del to list_del_init in the tx object [ Upstream commit 27d41d29c7f093f6f77843624fbb080c1b4a8b9c ] Since ipoib_cm_tx_start function and ipoib_cm_tx_reap function belong to different work queues, they can run in parallel. In this case if ipoib_cm_tx_reap calls list_del and release the lock, ipoib_cm_tx_start may acquire it and call list_del_init on the already deleted object. Changing list_del to list_del_init in ipoib_cm_tx_reap fixes the problem. Fixes: 839fcaba355a ("IPoIB: Connected mode experimental support") Signed-off-by: Feras Daoud Signed-off-by: Erez Shitrit Reviewed-by: Alex Vesker Signed-off-by: Leon Romanovsky Reviewed-by: Yuval Shaia Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 6e54507f537ceae62e9c7ae8e6c294fd01c7fd9c Author: Akinobu Mita Date: Sun Jan 15 14:44:05 2017 -0800 Input: mpr121 - set missing event capability [ Upstream commit 9723ddc8fe0d76ce41fe0dc16afb241ec7d0a29d ] This driver reports misc scan input events on the sensor's status register changes. But the event capability for them was not set in the device initialization, so these events were ignored. This change adds the missing event capability. Signed-off-by: Akinobu Mita Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 7c52146ea9a188dcaffe2a58af7bcc410b7eef87 Author: Akinobu Mita Date: Sun Jan 15 14:44:30 2017 -0800 Input: mpr121 - handle multiple bits change of status register [ Upstream commit 08fea55e37f58371bffc5336a59e55d1f155955a ] This driver reports input events on their interrupts which are triggered by the sensor's status register changes. But only single bit change is reported in the interrupt handler. So if there are multiple bits are changed at almost the same time, other press or release events are ignored. This fixes it by detecting all changed bits in the status register. Signed-off-by: Akinobu Mita Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 627437a3d7a3815691d3a335eaa5155884c9ecb3 Author: Gilad Ben-Yossef Date: Mon Jan 16 13:17:55 2017 +0200 IPsec: do not ignore crypto err in ah4 input [ Upstream commit ebd89a2d0675f1325c2be5b7576fd8cb7e8defd0 ] ah4 input processing uses the asynchronous hash crypto API which supplies an error code as part of the operation completion but the error code was being ignored. Treat a crypto API error indication as a verification failure. While a crypto API reported error would almost certainly result in a memcpy of the digest failing anyway and thus the security risk seems minor, performing a memory compare on what might be uninitialized memory is wrong. Signed-off-by: Gilad Ben-Yossef Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit dd86161dc50512f33799ca9eac71945e2a0672ed Author: William wu Date: Fri Jan 13 11:04:22 2017 +0800 usb: hcd: initialize hcd->flags to 0 when rm hcd [ Upstream commit 76b8db0d480e8045e1a1902fc9ab143b3b9ef115 ] On some platforms(e.g. rk3399 board), we can call hcd_add/remove consecutively without calling usb_put_hcd/usb_create_hcd in between, so hcd->flags can be stale. If the HC dies due to whatever reason then without this patch we get the below error on next hcd_add. [173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up [173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller [173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6 [173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM. [173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003 [173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [173.297222] usb usb6: Product: xHCI Host Controller [173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd [173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto [173.298680] hub 6-0:1.0: USB hub found [173.298749] hub 6-0:1.0: 1 port detected [173.299382] rockchip-dwc3 usb@fe800000: USB HOST connected [173.395418] hub 5-0:1.0: activate --> -19 [173.603447] irq 228: nobody cared (try booting with the "irqpoll" option) [173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9 [173.603513] Hardware name: Google Kevin (DT) [173.603531] Call trace: [173.603568] [] dump_backtrace+0x0/0x160 [173.603596] [] show_stack+0x20/0x28 [173.603623] [] dump_stack+0x90/0xb0 [173.603650] [] __report_bad_irq+0x48/0xe8 [173.603674] [] note_interrupt+0x1e8/0x28c [173.603698] [] handle_irq_event_percpu+0x1d4/0x25c [173.603722] [] handle_irq_event+0x4c/0x7c [173.603748] [] handle_fasteoi_irq+0xb4/0x124 [173.603777] [] generic_handle_irq+0x30/0x44 [173.603804] [] __handle_domain_irq+0x90/0xbc [173.603827] [] gic_handle_irq+0xcc/0x188 ... [173.604500] [] el1_irq+0x80/0xf8 [173.604530] [] cpu_startup_entry+0x38/0x3cc [173.604558] [] rest_init+0x8c/0x94 [173.604585] [] start_kernel+0x3d0/0x3fc [173.604607] [<0000000000b16000>] 0xb16000 [173.604622] handlers: [173.604648] [] usb_hcd_irq [173.604673] Disabling IRQ #228 Signed-off-by: William wu Acked-by: Roger Quadros Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 38fbadd17cf6df781b31e0e7285f42455f02e31d Author: Laurent Pinchart Date: Wed Jan 11 16:43:32 2017 +0200 serial: sh-sci: Fix register offsets for the IRDA serial port [ Upstream commit a752ba18af8285e3eeda572f40dddaebff0c3621 ] Even though most of its registers are 8-bit wide, the IRDA has two 16-bit registers that make it a 16-bit peripheral and not a 8-bit peripheral with addresses shifted by one. Fix the registers offset in the driver and the platform data regshift value. Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d6c286fdcbe0c4f5c3540c24718709af91053c48 Author: Volodymyr Bendiuga Date: Thu Jan 19 17:05:04 2017 +0100 phy: increase size of MII_BUS_ID_SIZE and bus_id [ Upstream commit 4567d686f5c6d955e57a3afa1741944c1e7f4033 ] Some bus names are pretty long and do not fit into 17 chars. Increase therefore MII_BUS_ID_SIZE and phy_fixup.bus_id to larger number. Now mii_bus.id can host larger name. Signed-off-by: Volodymyr Bendiuga Signed-off-by: Magnus Öberg Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 150aa7b72c8159fd1cca73934d36a0aba7590c16 Author: Alison Schofield Date: Thu Jan 19 19:47:38 2017 -0800 iio: trigger: free trigger resource correctly [ Upstream commit 10e840dfb0b7fc345082dd9e5fff3c1c02e7690e ] These stand-alone trigger drivers were using iio_trigger_put() where they should have been using iio_trigger_free(). The iio_trigger_put() adds a module_put which is bad since they never did a module_get. In the sysfs driver, module_get/put's are used as triggers are added & removed. This extra module_put() occurs on an error path in the probe routine (probably rare). In the bfin-timer & interrupt trigger drivers, the module resources are not explicitly managed, so it's doing a put on something that was never get'd. It occurs on the probe error path and on the remove path (not so rare). Tested with the sysfs trigger driver. The bfin & interrupt drivers were build tested & inspected only. Signed-off-by: Alison Schofield Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9348fd9fda031f525db5661f84fec520a01f75a3 Author: Tony Lindgren Date: Fri Jan 20 12:13:19 2017 -0800 ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6 [ Upstream commit 4cd6a59f5c1a9b0cca0da09fbba42b9450ffc899 ] We have more than four uarts on some SoCs and that can cause noise with errors while booting. Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 716b56753a5acf0bb83ad919ed95125c1fc010d2 Author: Li Zhong Date: Fri Nov 11 12:57:33 2016 +0800 KVM: PPC: Book 3S: XICS: correct the real mode ICP rejecting counter [ Upstream commit 37451bc95dee0e666927d6ffdda302dbbaaae6fa ] Some counters are added in Commit 6e0365b78273 ("KVM: PPC: Book3S HV: Add ICP real mode counters"), to provide some performance statistics to determine whether further optimizing is needed for real mode functions. The n_reject counter counts how many times ICP rejects an irq because of priority in real mode. The redelivery of an lsi that is still asserted after eoi doesn't fall into this category, so the increasement there is removed. Also, it needs to be increased in icp_rm_deliver_irq() if it rejects another one. Signed-off-by: Li Zhong Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit 003ee19e5187e5df5df067917e3f757c237c1021 Author: Noralf Trønnes Date: Thu Jan 26 23:56:04 2017 +0100 drm: drm_minor_register(): Clean up debugfs on failure [ Upstream commit a67834f8bfa1e2f48bb27d07b9a552ba7c3af82a ] Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to cover for failure in the drm_driver.debugfs_init callback. Signed-off-by: Noralf Trønnes Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-3-noralf@tronnes.org Signed-off-by: Sasha Levin commit a788b976c6a4778a12655e97309cb28371b1c8f0 Author: Juergen Gross Date: Tue Jan 10 14:32:52 2017 +0100 xen/netback: set default upper limit of tx/rx queues to 8 [ Upstream commit 56dd5af9bc23d0d5d23bb207c477715b4c2216c5 ] The default for the maximum number of tx/rx queues of one interface is the number of cpus of the system today. As each queue pair reserves 512 grant pages this default consumes a ridiculous number of grants for large guests. Limit the queue number to 8 as default. This value can be modified via a module parameter if required. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 3961a944e2881383bf8d62fa1f334480c5b5bce2 Author: Jason Gunthorpe Date: Mon Dec 12 11:30:20 2016 -0700 PCI: mvebu: Handle changes to the bridge windows while enabled [ Upstream commit d9bf28e2650fe3eeefed7e34841aea07d10c6543 ] The PCI core will write to the bridge window config multiple times while they are enabled. This can lead to mbus failures like this: mvebu_mbus: cannot add window '4:e8', conflicts with another window mvebu-pcie mbus:pex@e0000000: Could not create MBus window at [mem 0xe0000000-0xe00fffff]: -22 For me this is happening during a hotplug cycle. The PCI core is not changing the values, just writing them twice while active. The patch addresses the general case of any change to an active window, but not atomically. The code is slightly refactored so io and mem can share more of the window logic. Signed-off-by: Jason Gunthorpe Signed-off-by: Bjorn Helgaas Acked-by: Jason Cooper Signed-off-by: Sasha Levin commit 4327ff3e949a4141506cb82e20b3a507ba2f8d3b Author: Maciej W. Rozycki Date: Mon Jan 30 17:39:48 2017 +0100 video: fbdev: pmag-ba-fb: Remove bad `__init' annotation [ Upstream commit 879e5a0df626f39cbb3c61bb90373e56d67012c4 ] Fix: WARNING: drivers/video/fbdev/pmag-ba-fb.o(.text+0x308): Section mismatch in reference from the function pmagbafb_probe() to the function .init.text:pmagbafb_erase_cursor() The function pmagbafb_probe() references the function __init pmagbafb_erase_cursor(). This is often because pmagbafb_probe lacks a __init annotation or the annotation of pmagbafb_erase_cursor is wrong. -- a fallout from a missed update from commit 9625b51350cc ("VIDEO: PMAG-BA: Fix section mismatch") and then commit 48c68c4f1b54 ("Drivers: video: remove __dev* attributes.") Signed-off-by: Maciej W. Rozycki Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit b3b35cec84392ca3644cb43ad729a13f7ce78d72 Author: Lars-Peter Clausen Date: Tue Nov 29 09:23:48 2016 -0200 [media] adv7604: Initialize drive strength to default when using DT [ Upstream commit da8892d410db224d9a24104529794e6e37e0c100 ] The adv7604 driver platform data contains fields for configuring the drive strength of the output pins. When probing the driver through DT these fields are not explicitly initialized, which means they are left at 0. This is a reserved setting for the drive strength configuration though and can cause signal integrity issues. Whether these signal integrity issues are visible depends on the PCB specifics (e.g. the higher the load capacitance for the output the more visible the issue). But it has been observed on existing solutions at high pixel clock rates. Initialize the drive strength settings to the power-on-reset value of the device when probing through devicetree to avoid this issue. Fixes: 0e158be0162b ("adv7604: Add DT support") Signed-off-by: Lars-Peter Clausen Reviewed-by: Laurent Pinchart Tested-by: Niklas Söderlund Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0cd5bb44bf9992c2601ef96e98640b67d665d41b Author: Juergen Gross Date: Tue May 30 20:52:26 2017 +0200 xen: don't print error message in case of missing Xenstore entry [ Upstream commit 4e93b6481c87ea5afde944a32b4908357ec58992 ] When registering for the Xenstore watch of the node control/sysrq the handler will be called at once. Don't issue an error message if the Xenstore node isn't there, as it will be created only when an event is being triggered. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 99fb1891ebf2555c1b513312adaf6a2465e01278 Author: Sudip Mukherjee Date: Sat Oct 7 22:37:49 2017 +0000 [media] bt8xx: fix memory leak [ Upstream commit 6792eb0cf9310ec240b7e7c9bfa86dff4c758c68 ] If dvb_attach() fails then we were just printing an error message and exiting but the memory allocated to state was not released. Signed-off-by: Sudip Mukherjee Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3bd8a277dd47a171331abfcdb1c2f29db9a98444 Author: Stefan Haberland Date: Sat Oct 7 22:37:49 2017 +0000 s390/dasd: check for device error pointer within state change interrupts [ Upstream commit 2202134e48a3b50320aeb9e3dd1186833e9d7e66 ] Check if the device pointer is valid. Just a sanity check since we already are in the int handler of the device. Signed-off-by: Stefan Haberland Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 5364170e256d863391265887473d064ab6a6a845 Author: Arvind Yadav Date: Sat Oct 7 22:37:48 2017 +0000 [media] exynos4-is: fimc-is: Unmap region obtained by of_iomap() [ Upstream commit 4742575cde1f3cee0ea6b41af42781672315b04b ] Free memory mapping, if fimc_is_probe is not successful. Signed-off-by: Arvind Yadav Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e5d7294b399656ba9d9a583419ecc2fa583901a4 Author: Alexander Boyko Date: Sat Oct 7 22:37:48 2017 +0000 staging: lustre: ptlrpc: skip lock if export failed [ Upstream commit 4c43c27ddc461d8473cedd70f2549614641dfbc7 ] This patch resolves IO vs eviction race. After eviction failed export stayed at stale list, a client had IO processing and reconnected during it. A client sent brw rpc with last lock cookie and new connection. The lock with failed export was found and assert was happened. (ost_handler.c:1812:ost_prolong_lock_one()) ASSERTION( lock->l_export == opd->opd_exp ) failed: 1. Skip the lock at ldlm_handle2lock if lock export failed. 2. Validation of lock for IO was added at hpreq_check(). The lock searching is based on granted interval tree. If server doesn`t have a valid lock, it reply to client with ESTALE. Signed-off-by: Alexander Boyko Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7702 Seagate-bug-id: MRP-2787 Reviewed-on: http://review.whamcloud.com/18120 Reviewed-by: Fan Yong Reviewed-by: Vitaly Fertman Reviewed-by: Oleg Drokin Signed-off-by: James Simmons Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 42c577d86a9080a8f4d07ad7f2da0d8bfb9efce9 Author: frank zago Date: Sat Oct 7 22:37:48 2017 +0000 staging: lustre: hsm: stack overrun in hai_dump_data_field [ Upstream commit 22aadb91c0a0055935109c175f5446abfb130702 ] The function hai_dump_data_field will do a stack buffer overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has some data in it. hai_dump_data_field uses snprintf. But there is no check for truncation, and the value returned by snprintf is used as-is. The coordinator code calls hai_dump_data_field with 12 bytes in the buffer. The 6th byte of data is printed incompletely to make room for the terminating NUL. However snprintf still returns 2, so when hai_dump_data_field writes the final NUL, it does it outside the reserved buffer, in the 13th byte of the buffer. This stack buffer overrun hangs my VM. Fix by checking that there is enough room for the next 2 characters plus the NUL terminator. Don't print half bytes. Change the format to 02X instead of .2X, which makes more sense. Signed-off-by: frank zago Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8171 Reviewed-on: http://review.whamcloud.com/20338 Reviewed-by: John L. Hammond Reviewed-by: Jean-Baptiste Riaux Reviewed-by: Oleg Drokin Signed-off-by: James Simmons Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2114021bdcf8f032cbedc37fad0cdc5e651ce51e Author: Yang Sheng Date: Sat Oct 7 22:37:48 2017 +0000 staging: lustre: llite: don't invoke direct_IO for the EOF case [ Upstream commit 77759771fb95420d23876cb104ab65c022613325 ] The function generic_file_read_iter() does not check EOF before invoke direct_IO callback. So we have to check it ourselves. Signed-off-by: Yang Sheng Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8969 Reviewed-on: https://review.whamcloud.com/24552 Reviewed-by: Bob Glossman Reviewed-by: Bobi Jam Reviewed-by: Oleg Drokin Signed-off-by: James Simmons Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bbf26bcf07412ca12de0934c6f82b6817ed840c0 Author: Javier Martinez Canillas Date: Sat Oct 7 22:37:47 2017 +0000 platform/x86: intel_mid_thermal: Fix module autoload [ Upstream commit a93151a72061e944a4915458b1b1d6d505c03bbf ] If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias $ After this patch: $ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias alias: platform:msic_thermal Signed-off-by: Javier Martinez Canillas Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 4eacd5f68a83224b876f48a22b35fd1ca9c28b93 Author: Jan Beulich Date: Sat Oct 7 22:37:47 2017 +0000 xen/manage: correct return value check on xenbus_scanf() [ Upstream commit 4fed1b125eb6252bde478665fc05d4819f774fa8 ] A negative return value indicates an error; in fact the function at present won't ever return zero. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 997ca6b8e9484b7279fb25e9246fa6c5ae41b7ae Author: Oleh Kravchenko Date: Sat Oct 7 22:37:46 2017 +0000 [media] cx231xx: Fix I2C on Internal Master 3 Bus [ Upstream commit 6c5da8031a3abfad259190d35f83d89568b72ee2 ] Internal Master 3 Bus can send and receive only 4 bytes per time. Signed-off-by: Oleh Kravchenko Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1c844c83093322d14b656069aa08ad7180f19886 Author: Chris Brandt Date: Sat Oct 7 22:37:45 2017 +0000 i2c: riic: correctly finish transfers [ Upstream commit 71ccea095ea1d4efd004dab971be6d599e06fc3f ] This fixes the condition where the controller has not fully completed its final transfer and leaves the bus and controller in a undesirable state. At the end of the last transmitted byte, the existing driver would just signal for a STOP condition to be transmitted then immediately signal completion. However, the full STOP procedure might not have fully taken place by the time the runtime PM shuts off the peripheral clock, leaving the bus in a suspended state. Alternatively, the STOP condition on the bus may have completed, but when the next transaction is requested by the upper layer, not all the necessary register cleanup was finished from the last transfer which made the driver return BUS BUSY when it really wasn't. This patch now makes all transmit and receive transactions wait for the STOP condition to fully complete before signaling a completed transaction. With this new method, runtime PM no longer seems to be an issue. Fixes: 310c18a41450 ("i2c: riic: add driver") Signed-off-by: Chris Brandt Reviewed-by: Wolfram Sang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit c7ffd6065da68bb79f965514e4a71468230ffe47 Author: Jan Kara Date: Sat Oct 7 22:37:45 2017 +0000 ext4: do not use stripe_width if it is not set [ Upstream commit 5469d7c3087ecaf760f54b447f11af6061b7c897 ] Avoid using stripe_width for sbi->s_stripe value if it is not actually set. It prevents using the stride for sbi->s_stripe. Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit d986a8aa8ca3e8d7439e07e4a5c28bf86920ac4a Author: Jan Kara Date: Sat Oct 7 22:37:45 2017 +0000 ext4: fix stripe-unaligned allocations [ Upstream commit d9b22cf9f5466a057f2a4f1e642b469fa9d73117 ] When a filesystem is created using: mkfs.ext4 -b 4096 -E stride=512 and we try to allocate 64MB extent, we will end up directly in ext4_mb_complex_scan_group(). This is because the request is detected as power-of-two allocation (so we start in ext4_mb_regular_allocator() with ac_criteria == 0) however the check before ext4_mb_simple_scan_group() refuses the direct buddy scan because the allocation request is too large. Since cr == 0, the check whether we should use ext4_mb_scan_aligned() fails as well and we fall back to ext4_mb_complex_scan_group(). Fix the problem by checking for upper limit on power-of-two requests directly when detecting them. Reported-by: Ross Zwisler Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e3c1b154c3d2a7771f2bf13b62089a703296030b Author: Larry Finger Date: Sat Oct 7 22:37:45 2017 +0000 staging: rtl8712u: Fix endian settings for structs describing network packets [ Upstream commit 221c46d28957bd6e2158abc2179ce4a8c9ce07d3 ] The headers describing a number of network packets do not have the correct endian settings for several types of data. Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 24688f2ac7a48d337250f9e33aa91c543bce2864 Author: Linus Walleij Date: Sat Oct 7 22:37:44 2017 +0000 mfd: ab8500-sysctrl: Handle probe deferral [ Upstream commit 7e9c40c63933a643908d686bd89dfc2315e8c70a ] In the current boot, clients making use of the AB8500 sysctrl may be probed before the ab8500-sysctrl driver. This gives them -EINVAL, but should rather give -EPROBE_DEFER. Before this, the abx500 clock driver didn't probe properly, and as a result the codec driver in turn using the clocks did not probe properly. After this patch, everything probes properly. Also add OF compatible-string probing. This driver is all device tree, so let's just make a drive-by-fix of that as well. Signed-off-by: Linus Walleij Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e3b91143e95011b9df7689afc7302ac1de5cda42 Author: Ulf Hansson Date: Sat Oct 7 22:37:44 2017 +0000 ARM: pxa: Don't rely on public mmc header to include leds.h [ Upstream commit 40d727a2defa176b78159d445bcf7afcc2ed9021 ] Some of the pxa platforms, balloon3, colibri-pxa270-income, corgi, trizeps4, vpac270, zeus and zylonite depends on leds.h. Explicitly include it instead of relying on the public mmc header host.h. Cc: Daniel Mack Cc: Haojian Zhuang Cc: Robert Jarzmik Cc: Signed-off-by: Ulf Hansson Acked-by: Robert Jarzmik Signed-off-by: Sasha Levin commit 4c7028375cd432fcde90bdd52f5edbd9b293b44c Author: Arnd Bergmann Date: Sat Oct 7 22:37:44 2017 +0000 mmc: s3cmci: include linux/interrupt.h for tasklet_struct [ Upstream commit e1c6ec26b853e9062f0b3daaf695c546d0702953 ] I got this new build error on today's linux-next drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type struct tasklet_struct pio_tasklet; drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq': drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration] While I haven't found out why this happened now and not earlier, the solution is obvious, we should include the header that defines the structure. Signed-off-by: Arnd Bergmann Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit d3e2ef5f6ef08adac90cd4384ade5a020aa7797d Author: Linus Torvalds Date: Fri Oct 27 20:35:31 2017 -0700 Fix tracing sample code warning. [ Upstream commit a0cb2b5c390151837b08e5f7bca4a6ecddbcd39c ] Commit 6575257c60e1 ("tracing/samples: Fix creation and deletion of simple_thread_fn creation") introduced a new warning due to using a boolean as a counter. Just make it "int". Fixes: 6575257c60e1 ("tracing/samples: Fix creation and deletion of simple_thread_fn creation") Cc: Steven Rostedt Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6d40d4f2772bb93975f145f21915cdf03bd232f9 Author: Steven Rostedt (VMware) Date: Tue Oct 17 14:55:24 2017 -0400 tracing/samples: Fix creation and deletion of simple_thread_fn creation [ Upstream commit 6575257c60e1a26a5319ccf2b5ce5b6449001017 ] Commit 7496946a8 ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()") added template examples for all the events. It created a DEFINE_EVENT_FN() example which reused the foo_bar_reg and foo_bar_unreg functions. Enabling both the TRACE_EVENT_FN() and DEFINE_EVENT_FN() example trace events caused the foo_bar_reg to be called twice, creating the test thread twice. The foo_bar_unreg would remove it only once, even if it was called multiple times, leaving a thread existing when the module is unloaded, causing an oops. Add a ref count and allow foo_bar_reg() and foo_bar_unreg() be called by multiple trace events. Cc: stable@vger.kernel.org Fixes: 7496946a8 ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 9cc11635340aa4103ccb07fc5e4d29973c582347 Author: Dan Carpenter Date: Fri Jun 30 10:59:15 2017 +0300 drm/msm: fix an integer overflow test [ Upstream commit 65e93108891e571f177c202add9288eda9ac4100 ] We recently added an integer overflow check but it needs an additional tweak to work properly on 32 bit systems. The problem is that we're doing the right hand side of the assignment as type unsigned long so the max it will have an integer overflow instead of being larger than SIZE_MAX. That means the "sz > SIZE_MAX" condition is never true even on 32 bit systems. We need to first cast it to u64 and then do the math. Fixes: 4a630fadbb29 ("drm/msm: Fix potential buffer overflow issue") Signed-off-by: Dan Carpenter Acked-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 3ab2e16ed810d77380109b9556d0afe5ef126b70 Author: Kasin Li Date: Mon Jun 19 15:36:53 2017 -0600 drm/msm: Fix potential buffer overflow issue [ Upstream commit 4a630fadbb29d9efaedb525f1a8f7449ad107641 ] In function submit_create, if nr_cmds or nr_bos is assigned with negative value, the allocated buffer may be small than intended. Using this buffer will lead to buffer overflow issue. Signed-off-by: Kasin Li Signed-off-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 67903f1a76502fd11c53f3a08df8feb019ce5bd7 Author: Ashish Samant Date: Thu Nov 2 15:59:37 2017 -0700 ocfs2: fstrim: Fix start offset of first cluster group during fstrim [ Upstream commit 105ddc93f06ebe3e553f58563d11ed63dbcd59f0 ] The first cluster group descriptor is not stored at the start of the group but at an offset from the start. We need to take this into account while doing fstrim on the first cluster group. Otherwise we will wrongly start fstrim a few blocks after the desired start block and the range can cross over into the next cluster group and zero out the group descriptor there. This can cause filesytem corruption that cannot be fixed by fsck. Link: http://lkml.kernel.org/r/1507835579-7308-1-git-send-email-ashish.samant@oracle.com Signed-off-by: Ashish Samant Reviewed-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9f507cd1016ea71591973b26428bd1c214a3d3bb Author: Arnd Bergmann Date: Fri Oct 20 21:17:05 2017 +0100 ARM: 8715/1: add a private asm/unaligned.h [ Upstream commit 1cce91dfc8f7990ca3aea896bfb148f240b12860 ] The asm-generic/unaligned.h header provides two different implementations for accessing unaligned variables: the access_ok.h version used when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers are in fact aligned, while the le_struct.h version convinces gcc that the alignment of a pointer is '1', to make it issue the correct load/store instructions depending on the architecture flags. On ARMv5 and older, we always use the second version, to let the compiler use byte accesses. On ARMv6 and newer, we currently use the access_ok.h version, so the compiler can use any instruction including stm/ldm and ldrd/strd that will cause an alignment trap. This trap can significantly impact performance when we have to do a lot of fixups and, worse, has led to crashes in the LZ4 decompressor code that does not have a trap handler. This adds an ARM specific version of asm/unaligned.h that uses the le_struct.h/be_struct.h implementation unconditionally. This should lead to essentially the same code on ARMv6+ as before, with the exception of using regular load/store instructions instead of the trapping instructions multi-register variants. The crash in the LZ4 decompressor code was probably introduced by the patch replacing the LZ4 implementation, commit 4e1a33b105dd ("lib: update LZ4 compressor module"), so linux-4.11 and higher would be affected most. However, we probably want to have this backported to all older stable kernels as well, to help with the performance issues. There are two follow-ups that I think we should also work on, but not backport to stable kernels, first to change the asm-generic version of the header to remove the ARM special case, and second to review all other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they might be affected by the same problem on ARM. Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 734702a79cbcb77cf604f15eb7973d99c676cc79 Author: Mark Rutland Date: Thu Nov 2 16:12:03 2017 +0000 arm64: ensure __dump_instr() checks addr_limit [ Upstream commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 ] It's possible for a user to deliberately trigger __dump_instr with a chosen kernel address. Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory. Where we use __dump_instr() on kernel text, we already switch to KERNEL_DS, so this shouldn't adversely affect those cases. Fixes: 60ffc30d5652810d ("arm64: Exception handling") Cc: stable@vger.kernel.org Acked-by: Will Deacon Signed-off-by: Mark Rutland Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit d3c7fd753c609330faee3c45be539e33141b5bbf Author: Ricard Wanderlof Date: Thu Sep 7 15:31:38 2017 +0200 ASoC: adau17x1: Workaround for noise bug in ADC [ Upstream commit 1e6f4fc06f6411adf98bbbe7fcd79442cd2b2a75 ] The ADC in the ADAU1361 (and possibly other Analog Devices codecs) exhibits a cyclic variation in the noise floor (in our test setup between -87 and -93 dB), a new value being attained within this range whenever a new capture stream is started. The cycle repeats after about 10 or 11 restarts. The workaround recommended by the manufacturer is to toggle the ADOSR bit in the Converter Control 0 register each time a new capture stream is started. I have verified that the patch fixes this problem on the ADAU1361, and according to the manufacturer toggling the bit in question in this manner will at least have no detrimental effect on other chips served by this driver. Signed-off-by: Ricard Wanderlof Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 5a3b40184c18e8bf3797d5850ffab9026f2f304c Author: Eric Biggers Date: Thu Nov 2 00:47:19 2017 +0000 KEYS: fix out-of-bounds read during ASN.1 parsing [ Upstream commit 2eb9eabf1e868fda15808954fb29b0f105ed65f1 ] syzkaller with KASAN reported an out-of-bounds read in asn1_ber_decoder(). It can be reproduced by the following command, assuming CONFIG_X509_CERTIFICATE_PARSER=y and CONFIG_KASAN=y: keyctl add asymmetric desc $'\x30\x30' @s The bug is that the length of an ASN.1 data value isn't validated in the case where it is encoded using the short form, causing the decoder to read past the end of the input buffer. Fix it by validating the length. The bug report was: BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233 Read of size 1 at addr ffff88003cccfa02 by task syz-executor0/6818 CPU: 1 PID: 6818 Comm: syz-executor0 Not tainted 4.14.0-rc7-00008-g5f479447d983 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0xb3/0x10b lib/dump_stack.c:52 print_address_description+0x79/0x2a0 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x236/0x340 mm/kasan/report.c:409 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427 asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233 x509_cert_parse+0x1db/0x650 crypto/asymmetric_keys/x509_cert_parser.c:89 x509_key_preparse+0x64/0x7a0 crypto/asymmetric_keys/x509_public_key.c:174 asymmetric_key_preparse+0xcb/0x1a0 crypto/asymmetric_keys/asymmetric_type.c:388 key_create_or_update+0x347/0xb20 security/keys/key.c:855 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0x1cd/0x340 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x447c89 RSP: 002b:00007fca7a5d3bd8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8 RAX: ffffffffffffffda RBX: 00007fca7a5d46cc RCX: 0000000000447c89 RDX: 0000000020006f4a RSI: 0000000020006000 RDI: 0000000020001ff5 RBP: 0000000000000046 R08: fffffffffffffffd R09: 0000000000000000 R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fca7a5d49c0 R15: 00007fca7a5d4700 Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder") Cc: # v3.7+ Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: James Morris Signed-off-by: Sasha Levin commit b0bee71210700175866ada0cb179f3bf63b80ceb Author: Eric Biggers Date: Thu Nov 2 00:47:03 2017 +0000 KEYS: return full count in keyring_read() if buffer is too small [ Upstream commit 3239b6f29bdfb4b0a2ba59df995fc9e6f4df7f1f ] Commit e645016abc80 ("KEYS: fix writing past end of user-supplied buffer in keyring_read()") made keyring_read() stop corrupting userspace memory when the user-supplied buffer is too small. However it also made the return value in that case be the short buffer size rather than the size required, yet keyctl_read() is actually documented to return the size required. Therefore, switch it over to the documented behavior. Note that for now we continue to have it fill the short buffer, since it did that before (pre-v3.13) and dump_key_tree_aux() in keyutils arguably relies on it. Fixes: e645016abc80 ("KEYS: fix writing past end of user-supplied buffer in keyring_read()") Reported-by: Ben Hutchings Cc: # v3.13+ Signed-off-by: Eric Biggers Signed-off-by: David Howells Reviewed-by: James Morris Signed-off-by: James Morris Signed-off-by: Sasha Levin commit a2547e969cc97a7336b7de3b52ce69054bddf911 Author: Ronnie Sahlberg Date: Mon Oct 30 13:28:03 2017 +1100 cifs: check MaxPathNameComponentLength != 0 before using it [ Upstream commit f74bc7c6679200a4a83156bb89cbf6c229fe8ec0 ] And fix tcon leak in error path. Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French CC: Stable Reviewed-by: David Disseldorp Signed-off-by: Sasha Levin commit 6abd54bb4b96875884a36241d6fd57dbd8992889 Author: Takashi Iwai Date: Sun Oct 29 11:10:43 2017 +0100 ALSA: seq: Fix nested rwsem annotation for lockdep splat [ Upstream commit 1f20f9ff57ca23b9f5502fca85ce3977e8496cb1 ] syzkaller reported the lockdep splat due to the possible deadlock of grp->list_mutex of each sequencer client object. Actually this is rather a false-positive report due to the missing nested lock annotations. The sequencer client may deliver the event directly to another client which takes another own lock. For addressing this issue, this patch replaces the simple down_read() with down_read_nested(). As a lock subclass, the already existing "hop" can be re-used, which indicates the depth of the call. Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com Reported-by: syzbot Reported-by: Dmitry Vyukov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 07816537f8860dc083b62be49d145899d2e978f2 Author: Takashi Iwai Date: Sun Oct 29 11:02:04 2017 +0100 ALSA: timer: Add missing mutex lock for compat ioctls [ Upstream commit 79fb0518fec8c8b4ea7f1729f54f293724b3dbb0 ] The races among ioctl and other operations were protected by the commit af368027a49a ("ALSA: timer: Fix race among timer ioctls") and later fixes, but one code path was forgotten in the scenario: the 32bit compat ioctl. As syzkaller recently spotted, a very similar use-after-free may happen with the combination of compat ioctls. The fix is simply to apply the same ioctl_lock to the compat_ioctl callback, too. Fixes: af368027a49a ("ALSA: timer: Fix race among timer ioctls") Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com Reported-by: syzbot Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2d2aa8962c14fa0bc15b471c27343a3d835084e4 Author: Eric Biggers Date: Mon Oct 9 12:40:00 2017 -0700 FS-Cache: fix dereference of NULL user_key_payload [ Upstream commit d124b2c53c7bee6569d2a2d0b18b4a1afde00134 ] When the file /proc/fs/fscache/objects (available with CONFIG_FSCACHE_OBJECT_LIST=y) is opened, we request a user key with description "fscache:objlist", then access its payload. However, a revoked key has a NULL payload, and we failed to check for this. request_key() *does* skip revoked keys, but there is still a window where the key can be revoked before we access its payload. Fix it by checking for a NULL payload, treating it like a key which was already revoked at the time it was requested. Fixes: 4fbf4291aa15 ("FS-Cache: Allow the current state of all objects to be dumped") Reviewed-by: James Morris Cc: [v2.6.32+] Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 0149e2bdac423ee6488ed361500b0847197dd7f3 Author: Eric Biggers Date: Mon Oct 9 12:37:49 2017 -0700 KEYS: encrypted: fix dereference of NULL user_key_payload [ Upstream commit 13923d0865ca96312197962522e88bc0aedccd74 ] A key of type "encrypted" references a "master key" which is used to encrypt and decrypt the encrypted key's payload. However, when we accessed the master key's payload, we failed to handle the case where the master key has been revoked, which sets the payload pointer to NULL. Note that request_key() *does* skip revoked keys, but there is still a window where the key can be revoked before we acquire its semaphore. Fix it by checking for a NULL payload, treating it like a key which was already revoked at the time it was requested. This was an issue for master keys of type "user" only. Master keys can also be of type "trusted", but those cannot be revoked. Fixes: 7e70cb497850 ("keys: add new key-type encrypted") Reviewed-by: James Morris Cc: [v2.6.38+] Cc: Mimi Zohar Cc: David Safford Signed-off-by: Eric Biggers Signed-off-by: David Howells Signed-off-by: Sasha Levin commit a9f34f34520b6f2bfda4bd06cde1d7a50bc01e44 Author: Stefano Stabellini Date: Tue Feb 7 19:58:02 2017 +0200 swiotlb-xen: implement xen_swiotlb_dma_mmap callback [ Upstream commit 7e91c7df29b5e196de3dc6f086c8937973bd0b88 ] This function creates userspace mapping for the DMA-coherent memory. Signed-off-by: Stefano Stabellini Signed-off-by: Oleksandr Dmytryshyn Signed-off-by: Andrii Anisov Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Sasha Levin commit 18a5c92a15bc7623df049f43d34d81b2fe78be27 Author: Nicholas Bellinger Date: Thu Nov 16 06:14:19 2017 +0000 target: Fix node_acl demo-mode + uncached dynamic shutdown regression commit 6f48655facfd7f7ccfe6d252ac0fe319ab02e4dd upstream. This patch fixes a generate_node_acls = 1 + cache_dynamic_acls = 0 regression, that was introduced by commit 01d4d673558985d9a118e1e05026633c3e2ade9b Author: Nicholas Bellinger Date: Wed Dec 7 12:55:54 2016 -0800 which originally had the proper list_del_init() usage, but was dropped during list review as it was thought unnecessary by HCH. However, list_del_init() usage is required during the special generate_node_acls = 1 + cache_dynamic_acls = 0 case when transport_free_session() does a list_del(&se_nacl->acl_list), followed by target_complete_nacl() doing the same thing. This was manifesting as a general protection fault as reported by Justin: kernel: general protection fault: 0000 [#1] SMP kernel: Modules linked in: kernel: CPU: 0 PID: 11047 Comm: iscsi_ttx Not tainted 4.13.0-rc2.x86_64.1+ #20 kernel: Hardware name: Intel Corporation S5500BC/S5500BC, BIOS S5500.86B.01.00.0064.050520141428 05/05/2014 kernel: task: ffff88026939e800 task.stack: ffffc90007884000 kernel: RIP: 0010:target_put_nacl+0x49/0xb0 kernel: RSP: 0018:ffffc90007887d70 EFLAGS: 00010246 kernel: RAX: dead000000000200 RBX: ffff8802556ca000 RCX: 0000000000000000 kernel: RDX: dead000000000100 RSI: 0000000000000246 RDI: ffff8802556ce028 kernel: RBP: ffffc90007887d88 R08: 0000000000000001 R09: 0000000000000000 kernel: R10: ffffc90007887df8 R11: ffffea0009986900 R12: ffff8802556ce020 kernel: R13: ffff8802556ce028 R14: ffff8802556ce028 R15: ffffffff88d85540 kernel: FS: 0000000000000000(0000) GS:ffff88027fc00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00007fffe36f5f94 CR3: 0000000009209000 CR4: 00000000003406f0 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 kernel: Call Trace: kernel: transport_free_session+0x67/0x140 kernel: transport_deregister_session+0x7a/0xc0 kernel: iscsit_close_session+0x92/0x210 kernel: iscsit_close_connection+0x5f9/0x840 kernel: iscsit_take_action_for_connection_exit+0xfe/0x110 kernel: iscsi_target_tx_thread+0x140/0x1e0 kernel: ? wait_woken+0x90/0x90 kernel: kthread+0x124/0x160 kernel: ? iscsit_thread_get_cpumask+0x90/0x90 kernel: ? kthread_create_on_node+0x40/0x40 kernel: ret_from_fork+0x22/0x30 kernel: Code: 00 48 89 fb 4c 8b a7 48 01 00 00 74 68 4d 8d 6c 24 08 4c 89 ef e8 e8 28 43 00 48 8b 93 20 04 00 00 48 8b 83 28 04 00 00 4c 89 ef <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 20 kernel: RIP: target_put_nacl+0x49/0xb0 RSP: ffffc90007887d70 kernel: ---[ end trace f12821adbfd46fed ]--- To address this, go ahead and use proper list_del_list() for all cases of se_nacl->acl_list deletion. Reported-by: Justin Maggard Tested-by: Justin Maggard Cc: Justin Maggard Cc: stable@vger.kernel.org # 4.1+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 540093e4cd3818c34c16920705288945cfca32ea Author: Nicholas Bellinger Date: Thu Nov 16 06:14:18 2017 +0000 Revert "target: Fix VERIFY and WRITE VERIFY command parsing" commit 984a9d4c40bed351a92ed31f0723a710444295da upstream. This reverts commit 0e2eb7d12eaa8e391bf5615d4271bb87a649caaa Author: Bart Van Assche Date: Thu Mar 30 10:12:39 2017 -0700 target: Fix VERIFY and WRITE VERIFY command parsing This patch broke existing behaviour for WRITE_VERIFY because it dropped the original SCF_SCSI_DATA_CDB assignment for bytchk = 0 so target_cmd_size_check() no longer rejected this case, allowing an overflow case to trigger an OOPs in iscsi-target. Since the short term and long term fixes are still being discussed, revert it for now since it's late in the merge window and try again in v4.13-rc1. drivers/target/target_core_sbc.c Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 8beb14119b84d0ade39d9106d93b7acfa856df8e Author: Jiang Yi Date: Thu Nov 16 06:14:17 2017 +0000 iscsi-target: Always wait for kthread_should_stop() before kthread exit commit 5e0cf5e6c43b9e19fc0284f69e5cd2b4a47523b0 upstream. There are three timing problems in the kthread usages of iscsi_target_mod: - np_thread of struct iscsi_np - rx_thread and tx_thread of struct iscsi_conn In iscsit_close_connection(), it calls send_sig(SIGINT, conn->tx_thread, 1); kthread_stop(conn->tx_thread); In conn->tx_thread, which is iscsi_target_tx_thread(), when it receive SIGINT the kthread will exit without checking the return value of kthread_should_stop(). So if iscsi_target_tx_thread() exit right between send_sig(SIGINT...) and kthread_stop(...), the kthread_stop() will try to stop an already stopped kthread. This is invalid according to the documentation of kthread_stop(). (Fix -ECONNRESET logout handling in iscsi_target_tx_thread and early iscsi_target_rx_thread failure case - nab) Signed-off-by: Jiang Yi Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit ca84f64e33058df99a8fa8ff88fc4c01b2fd8b17 Author: Nicholas Bellinger Date: Thu Nov 16 06:14:16 2017 +0000 target: Avoid mappedlun symlink creation during lun shutdown commit 49cb77e297dc611a1b795cfeb79452b3002bd331 upstream. This patch closes a race between se_lun deletion during configfs unlink in target_fabric_port_unlink() -> core_dev_del_lun() -> core_tpg_remove_lun(), when transport_clear_lun_ref() blocks waiting for percpu_ref RCU grace period to finish, but a new NodeACL mappedlun is added before the RCU grace period has completed. This can happen in target_fabric_mappedlun_link() because it only checks for se_lun->lun_se_dev, which is not cleared until after transport_clear_lun_ref() percpu_ref RCU grace period finishes. This bug originally manifested as NULL pointer dereference OOPsen in target_stat_scsi_att_intr_port_show_attr_dev() on v4.1.y code, because it dereferences lun->lun_se_dev without a explicit NULL pointer check. In post v4.1 code with target-core RCU conversion, the code in target_stat_scsi_att_intr_port_show_attr_dev() no longer uses se_lun->lun_se_dev, but the same race still exists. To address the bug, go ahead and set se_lun>lun_shutdown as early as possible in core_tpg_remove_lun(), and ensure new NodeACL mappedlun creation in target_fabric_mappedlun_link() fails during se_lun shutdown. Reported-by: James Shen Cc: James Shen Tested-by: James Shen Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit ddc63153e305ede443fc67a66dec489a127e837d Author: Bart Van Assche Date: Thu Nov 16 06:14:15 2017 +0000 target/iscsi: Fix iSCSI task reassignment handling commit 59b6986dbfcdab96a971f9663221849de79a7556 upstream. Allocate a task management request structure for all task management requests, including task reassignment. This change avoids that the se_tmr->response assignment dereferences an uninitialized se_tmr pointer. Reported-by: Moshe David Signed-off-by: Bart Van Assche Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Cc: Moshe David Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit d35de9aa877a47a890518c6e799e5ca0001e1875 Author: Nicholas Bellinger Date: Thu Nov 16 06:14:14 2017 +0000 target: Fix multi-session dynamic se_node_acl double free OOPs commit 01d4d673558985d9a118e1e05026633c3e2ade9b upstream. This patch addresses a long-standing bug with multi-session (eg: iscsi-target + iser-target) se_node_acl dynamic free withini transport_deregister_session(). This bug is caused when a storage endpoint is configured with demo-mode (generate_node_acls = 1 + cache_dynamic_acls = 1) initiators, and initiator login creates a new dynamic node acl and attaches two sessions to it. After that, demo-mode for the storage instance is disabled via configfs (generate_node_acls = 0 + cache_dynamic_acls = 0) and the existing dynamic acl is never converted to an explicit ACL. The end result is dynamic acl resources are released twice when the sessions are shutdown in transport_deregister_session(). If the storage instance is not changed to disable demo-mode, or the dynamic acl is converted to an explict ACL, or there is only a single session associated with the dynamic ACL, the bug is not triggered. To address this big, move the release of dynamic se_node_acl memory into target_complete_nacl() so it's only freed once when se_node_acl->acl_kref reaches zero. (Drop unnecessary list_del_init usage - HCH) Reported-by: Rob Millner Tested-by: Rob Millner Cc: Rob Millner Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 126ec06eb2002dc8e04b3d7d5349e68099a85bc9 Author: Nicholas Bellinger Date: Thu Nov 16 06:14:13 2017 +0000 target: Obtain se_node_acl->acl_kref during get_initiator_node_acl commit 21aaa23b0ebbd19334fa461370c03cbb076b3295 upstream. This patch addresses a long standing race where obtaining se_node_acl->acl_kref in __transport_register_session() happens a bit too late, and leaves open the potential for core_tpg_del_initiator_node_acl() to hit a NULL pointer dereference. Instead, take ->acl_kref in core_tpg_get_initiator_node_acl() while se_portal_group->acl_node_mutex is held, and move the final target_put_nacl() from transport_deregister_session() into transport_free_session() so that fabric driver login failure handling using the modern method to still work as expected. Also, update core_tpg_get_initiator_node_acl() to take an extra reference for dynamically generated acls for demo-mode, before returning to fabric caller. Also update iscsi-target sendtargets special case handling to use target_tpg_has_node_acl() when checking if demo_mode_discovery == true during discovery lookup. Note the existing wait_for_completion(&acl->acl_free_comp) in core_tpg_del_initiator_node_acl() does not change. Cc: Sagi Grimberg Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Andy Grover Cc: Mike Christie Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin