commit 6b12ebc0ecce75d7bd3660cd85f8b47a615c2071 Author: Sasha Levin Date: Wed May 11 00:09:19 2016 -0400 Linux 3.18.33 Signed-off-by: Sasha Levin commit b7c4a9d51100cf69d87b758fb8aac3c2eb7b8499 Author: Tony Luck Date: Thu Apr 14 10:21:52 2016 -0700 x86 EDAC, sb_edac.c: Repair damage introduced when "fixing" channel address [ Upstream commit ff15e95c82768d589957dbb17d7eb7dba7904659 ] In commit: eb1af3b71f9d ("Fix computation of channel address") I switched the "sck_way" variable from holding the log2 value read from the h/w to instead be the actual number. Unfortunately it is needed in log2 form when used to shift the address. Tested-by: Patrick Geary Signed-off-by: Tony Luck Acked-by: Mauro Carvalho Chehab Cc: Aristeu Rozanski Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-edac@vger.kernel.org Cc: stable@vger.kernel.org Fixes: eb1af3b71f9d ("Fix computation of channel address") Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 24b769352bd519d6d932ea070e295e8b13f43af8 Author: Jan Beulich Date: Thu Apr 21 00:27:04 2016 -0600 x86/mm/xen: Suppress hugetlbfs in PV guests [ Upstream commit 103f6112f253017d7062cd74d17f4a514ed4485c ] Huge pages are not normally available to PV guests. Not suppressing hugetlbfs use results in an endless loop of page faults when user mode code tries to access a hugetlbfs mapped area (since the hypervisor denies such PTEs to be created, but error indications can't be propagated out of xen_set_pte_at(), just like for various of its siblings), and - once killed in an oops like this: kernel BUG at .../fs/hugetlbfs/inode.c:428! invalid opcode: 0000 [#1] SMP ... RIP: e030:[] [] remove_inode_hugepages+0x25b/0x320 ... Call Trace: [] hugetlbfs_evict_inode+0x15/0x40 [] evict+0xbd/0x1b0 [] __dentry_kill+0x19a/0x1f0 [] dput+0x1fe/0x220 [] __fput+0x155/0x200 [] task_work_run+0x60/0xa0 [] do_exit+0x160/0x400 [] do_group_exit+0x3b/0xa0 [] get_signal+0x1ed/0x470 [] do_signal+0x14/0x110 [] prepare_exit_to_usermode+0xe9/0xf0 [] retint_user+0x8/0x13 This is CVE-2016-3961 / XSA-174. Reported-by: Vitaly Kuznetsov Signed-off-by: Jan Beulich Cc: Andrew Morton Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Juergen Gross Cc: Linus Torvalds Cc: Luis R. Rodriguez Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Toshi Kani Cc: stable@vger.kernel.org Cc: xen-devel Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit baa806a8577e0d8b1d5a0ccbf735ceedb3a6bcfe Author: Dominik Dingel Date: Fri Jul 17 16:23:39 2015 -0700 s390/hugetlb: add hugepages_supported define [ Upstream commit 7f9be77555bb2e52de84e9dddf7b4eb20cc6e171 ] On s390 we only can enable hugepages if the underlying hardware/hypervisor also does support this. Common code now would assume this to be signaled by setting HPAGE_SHIFT to 0. But on s390, where we only support one hugepage size, there is a link between HPAGE_SHIFT and pageblock_order. So instead of setting HPAGE_SHIFT to 0, we will implement the check for the hardware capability. Signed-off-by: Dominik Dingel Acked-by: Martin Schwidefsky Cc: Heiko Carstens Cc: Christian Borntraeger Cc: Michael Holzheu Cc: Gerald Schaefer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e583da6d2b7a035f1c8a526da37b1b8b3bb59166 Author: Dominik Dingel Date: Fri Jul 17 16:23:37 2015 -0700 mm: hugetlb: allow hugepages_supported to be architecture specific [ Upstream commit 2531c8cf56a640cd7d17057df8484e570716a450 ] s390 has a constant hugepage size, by setting HPAGE_SHIFT we also change e.g. the pageblock_order, which should be independent in respect to hugepage support. With this patch every architecture is free to define how to check for hugepage support. Signed-off-by: Dominik Dingel Acked-by: Martin Schwidefsky Cc: Heiko Carstens Cc: Christian Borntraeger Cc: Michael Holzheu Cc: Gerald Schaefer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 837d4fb351122928fec781a8ff2686fc0d0fe2dc Author: Huacai Chen Date: Tue Apr 19 19:19:11 2016 +0800 drm: Loongson-3 doesn't fully support wc memory [ Upstream commit 221004c66a58949a0f25c937a6789c0839feb530 ] Signed-off-by: Huacai Chen Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit ebaea24c09f7ea15dfb8e010fbf8acef781eefb0 Author: Jérôme Glisse Date: Tue Apr 19 09:07:50 2016 -0400 drm/radeon: forbid mapping of userptr bo through radeon device file [ Upstream commit b5dcec693f87cb8475f2291c0075b2422addd3d6 ] Allowing userptr bo which are basicly a list of page from some vma (so either anonymous page or file backed page) would lead to serious corruption of kernel structures and counters (because we overwrite the page->mapping field when mapping buffer). This will already block if the buffer was populated before anyone does try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm vm fault handler. So to be safe just add a check to verify_access() callback. Reviewed-by: Christian König Signed-off-by: Jérôme Glisse Cc: Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 14e3f70aa72393b31d4775292ef7bdeb56c088cc Author: Takashi Iwai Date: Thu Apr 21 17:37:54 2016 +0200 ALSA: pcxhr: Fix missing mutex unlock [ Upstream commit 67f3754b51f22b18c4820fb84062f658c30e8644 ] The commit [9bef72bdb26e: ALSA: pcxhr: Use nonatomic PCM ops] converted to non-atomic PCM ops, but shamelessly with an unbalanced mutex locking, which leads to the hangup easily. Fix it. Fixes: 9bef72bdb26e ('ALSA: pcxhr: Use nonatomic PCM ops') Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116441 Cc: # 3.18+ Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 561c943e1709fe80588f21bdc2e2badc69540ead Author: Sebastian Andrzej Siewior Date: Fri Apr 15 14:35:39 2016 +0200 futex: Handle unlock_pi race gracefully [ Upstream commit 89e9e66ba1b3bde9d8ea90566c2aee20697ad681 ] If userspace calls UNLOCK_PI unconditionally without trying the TID -> 0 transition in user space first then the user space value might not have the waiters bit set. This opens the following race: CPU0 CPU1 uval = get_user(futex) lock(hb) lock(hb) futex |= FUTEX_WAITERS .... unlock(hb) cmpxchg(futex, uval, newval) So the cmpxchg fails and returns -EINVAL to user space, which is wrong because the futex value is valid. To handle this (yes, yet another) corner case gracefully, check for a flag change and retry. [ tglx: Massaged changelog and slightly reworked implementation ] Fixes: ccf9e6a80d9e ("futex: Make unlock_pi more robust") Signed-off-by: Sebastian Andrzej Siewior Cc: stable@vger.kernel.org Cc: Davidlohr Bueso Cc: Darren Hart Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1460723739-5195-1-git-send-email-bigeasy@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 0a3c8132816028ad6870dd89a149e68f7f3f7f86 Author: Alex Deucher Date: Mon Apr 18 11:19:19 2016 -0400 Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control" [ Upstream commit bfaddd9fc8ac048b99475f000dbef6f08297417f ] This reverts commit e64c952efb8e0c15ae82cec8e455ab4910690ef1. ATPX is the ACPI method for controlling AMD PowerXpress laptops. There are flags to indicate which methods are supported. If the dGPU power down flag is not supported, the driver needs to implement the dGPU power down manually. We had previously always forced the driver to assume the ATPX dGPU power down was present, but this causes problems on boards where it is not, leading to GPU hangs when attempting to power down the dGPU. Manual dGPU power down is not currently supported in the Linux driver. Some laptops indicate that the ATPX dGPU power down method is not present, but it actually apparently is. I'm not sure if this is a bios bug and it should be set or if there is a reason it was unset and the method should not be used. This is not an issue on other OSes since both the ATPX and the manual driver power down methods are supported. This is apparently fairly widespread, so just revert for now. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=115321 https://bugzilla.kernel.org/show_bug.cgi?id=116581 https://bugzilla.kernel.org/show_bug.cgi?id=116251 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 3e84fc86e20c54f4210aaaa0eb40f0664c70e293 Author: Alex Deucher Date: Thu Apr 14 14:15:16 2016 -0400 drm/radeon: add a quirk for a XFX R9 270X [ Upstream commit bcb31eba4a4ea356fd61cbd5dec5511c3883f57e ] bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit e5b6f4903ec297faf5851850578d691b1b9fc0b8 Author: Alex Deucher Date: Mon Mar 28 10:16:40 2016 -0400 drm/radeon: add another R7 370 quirk [ Upstream commit a64663d9870364bd2a2df62bf0d3a9fbe5ea62a8 ] bug: https://bugzilla.kernel.org/show_bug.cgi?id=115291 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 0d66b712280902c86f5c608d2e0fdadceffd1c07 Author: Alex Deucher Date: Fri Oct 2 16:12:07 2015 -0400 drm/radeon: add quirk for ASUS R7 370 [ Upstream commit 2b02ec79004388a8c65e227bc289ed891b5ac8c6 ] Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92260 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 196c77c94be40a292bd8a685326b27446d01d513 Author: Maxim Sheviakov Date: Wed Sep 23 17:10:51 2015 -0400 drm/radeon: add quirk for MSI R7 370 [ Upstream commit e78654799135a788a941bacad3452fbd7083e518 ] Just adds the quirk for MSI R7 370 Armor 2X Bug: https://bugs.freedesktop.org/show_bug.cgi?id=91294 Signed-off-by: Maxim Sheviakov Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d123375e55cb78061df3e8f2bf1b0fb4ad59f4ac Author: Anton Blanchard Date: Fri Apr 15 12:07:24 2016 +1000 powerpc: Update cpu_user_features2 in scan_features() [ Upstream commit beff82374b259d726e2625ec6c518a5f2613f0ae ] scan_features() updates cpu_user_features but not cpu_user_features2. Amongst other things, cpu_user_features2 contains the user TM feature bits which we must keep in sync with the kernel TM feature bit. Signed-off-by: Anton Blanchard Cc: stable@vger.kernel.org Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit f8f33fcd9640d5288696cba98613e231d7cfe76c Author: Anton Blanchard Date: Fri Apr 15 12:06:13 2016 +1000 powerpc: scan_features() updates incorrect bits for REAL_LE [ Upstream commit 6997e57d693b07289694239e52a10d2f02c3a46f ] The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU feature value, meaning all the remaining elements initialise the wrong values. This means instead of checking for byte 5, bit 0, we check for byte 0, bit 0, and then we incorrectly set the CPU feature bit as well as MMU feature bit 1 and CPU user feature bits 0 and 2 (5). Checking byte 0 bit 0 (IBM numbering), means we're looking at the "Memory Management Unit (MMU)" feature - ie. does the CPU have an MMU. In practice that bit is set on all platforms which have the property. This means we set CPU_FTR_REAL_LE always. In practice that seems not to matter because all the modern cpus which have this property also implement REAL_LE, and we've never needed to disable it. We're also incorrectly setting MMU feature bit 1, which is: #define MMU_FTR_TYPE_8xx 0x00000002 Luckily the only place that looks for MMU_FTR_TYPE_8xx is in Book3E code, which can't run on the same cpus as scan_features(). So this also doesn't matter in practice. Finally in the CPU user feature mask, we're setting bits 0 and 2. Bit 2 is not currently used, and bit 0 is: #define PPC_FEATURE_PPC_LE 0x00000001 Which says the CPU supports the old style "PPC Little Endian" mode. Again this should be harmless in practice as no 64-bit CPUs implement that mode. Fix the code by adding the missing initialisation of the MMU feature. Also add a comment marking CPU user feature bit 2 (0x4) as reserved. It would be unsafe to start using it as old kernels incorrectly set it. Fixes: 44ae3ab3358e ("powerpc: Free up some CPU feature bits by moving out MMU-related features") Signed-off-by: Anton Blanchard Cc: stable@vger.kernel.org [mpe: Flesh out changelog, add comment reserving 0x4] Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit ee3bc5355937261e5487c572741cf0e0f0003b64 Author: Aneesh Kumar K.V Date: Sun Nov 2 20:02:42 2014 +0530 powerpc: Disable CPU_FTR_TM if TM is disabled by firmware [ Upstream commit 9e819963b45f79e87f5a8c44960a66c0727c80e6 ] Firmware is allowed to communicate to us via the "ibm,pa-features" property that TM (Transactional Memory) support is disabled. Currently this doesn't happen on any platform we're aware of, but we should honor it anyway. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 1e53b1951e8a48266144d3a79a6a03950111b717 Author: Tom Lendacky Date: Wed Apr 13 10:52:25 2016 -0500 crypto: ccp - Prevent information leakage on export [ Upstream commit f709b45ec461b548c41a00044dba1f1b572783bf ] Prevent information from leaking to userspace by doing a memset to 0 of the export state structure before setting the structure values and copying it. This prevents un-initialized padding areas from being copied into the export area. Cc: # 3.14.x- Reported-by: Ben Hutchings Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5630c73cc47a028e0d2c8ff298f73ba86226d4a3 Author: Xiaodong Liu Date: Tue Apr 12 09:45:51 2016 +0000 crypto: sha1-mb - use corrcet pointer while completing jobs [ Upstream commit 0851561d9c965df086ef8a53f981f5f95a57c2c8 ] In sha_complete_job, incorrect mcryptd_hash_request_ctx pointer is used when check and complete other jobs. If the memory of first completed req is freed, while still completing other jobs in the func, kernel will crash since NULL pointer is assigned to RIP. Cc: Signed-off-by: Xiaodong Liu Acked-by: Tim Chen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2ad570ce34473b014b7cdda6da09f2c811beae56 Author: Dmitry Ivanov Date: Wed Apr 6 17:23:18 2016 +0300 nl80211: check netlink protocol in socket release notification [ Upstream commit 8f815cdde3e550e10c2736990d791f60c2ce43eb ] A non-privileged user can create a netlink socket with the same port_id as used by an existing open nl80211 netlink socket (e.g. as used by a hostapd process) with a different protocol number. Closing this socket will then lead to the notification going to nl80211's socket release notification handler, and possibly cause an action such as removing a virtual interface. Fix this issue by checking that the netlink protocol is NETLINK_GENERIC. Since generic netlink has no notifier chain of its own, we can't fix the problem more generically. Fixes: 026331c4d9b5 ("cfg80211/mac80211: allow registering for and sending action frames") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Ivanov [rewrite commit message] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6b314d424e2fda751e4cc330f050ceac2c7edce8 Author: Vladis Dronov Date: Thu Mar 31 10:53:42 2016 -0700 Input: gtco - fix crash on detecting device without endpoints [ Upstream commit 162f98dea487206d9ab79fc12ed64700667a894d ] The gtco driver expects at least one valid endpoint. If given malicious descriptors that specify 0 for the number of endpoints, it will crash in the probe function. Ensure there is at least one endpoint on the interface before using it. Also let's fix a minor coding style issue. The full correct report of this issue can be found in the public Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283385 Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin