- 16 May, 2019 21 commits
-
-
Ilan Peer authored
[ Upstream commit 08a75a88 ] The support added for regulatory WMM rules did not handle the case of regulatory domain intersections. Fix it. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Fixes: 230ebaa1 ("cfg80211: read wmm rules from regulatory database") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andrei Otcheretianski authored
[ Upstream commit 78be2d21 ] Looks that 100 chars isn't enough for messages, as we keep getting warnings popping from different places due to message shortening. Instead of trying to shorten the prints, just increase the buffer size. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
-
Felix Fietkau authored
[ Upstream commit 40586e3f ] The pointer to the last four bytes of the address is not guaranteed to be aligned, so we need to use __get_unaligned_cpu32 here Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
-
Peter Oberparleiter authored
[ Upstream commit 2cc9637c ] The DASD driver incorrectly limits the maximum number of blocks of ECKD DASD volumes to 32 bit numbers. Volumes with a capacity greater than 2^32-1 blocks are incorrectly recognized as smaller volumes. This results in the following volume capacity limits depending on the formatted block size: BLKSIZE MAX_GB MAX_CYL 512 2047 5843492c 1024 4095 8676701 2048 8191 13634816 4096 16383 23860929 The same problem occurs when a volume with more than 17895697 cylinders is accessed in raw-track-access mode. Fix this problem by adding an explicit type cast when calculating the maximum number of blocks. Signed-off-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by:
Stefan Haberland <sth@linux.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Aditya Pakki authored
[ Upstream commit 486fa92d ] In case kmemdup fails, the fix releases resources and returns to avoid the NULL pointer dereference. Signed-off-by:
Aditya Pakki <pakki001@umn.edu> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Dmitry Torokhov authored
[ Upstream commit c01908a1 ] According to HUT 1.12 usage 0xb5 from the generic desktop page is reserved for switching between external and internal display, so let's add the mapping. Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Dmitry Torokhov authored
[ Upstream commit 7975a1d6 ] According to HUTRR73 usages 0x79, 0x7a and 0x7c from the consumer page correspond to Brightness Up/Down/Toggle keys, so let's add the mappings. Signed-off-by:
-
Dmitry Torokhov authored
[ Upstream commit 96dd8687 ] According to HUTRR77 usage 0x29f from the consumer page is reserved for the Desktop application to present all running user’s application windows. Linux defines KEY_SCALE to request Compiz Scale (Expose) mode, so let's add the mapping. Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 55c1fc0a ] In case kmemdup fails, the fix goes to blk_err to avoid NULL pointer dereference. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Signed-off-by:
-
Dan Williams authored
[ Upstream commit 351f339f ] The dynamic-debug statements for command payload output only get emitted when the command is not ND_CMD_CALL. Move the output payload dumping ahead of the early return path for ND_CMD_CALL. Fixes: 31eca76b ("...whitelisted dimm command marshaling mechanism") Reported-by:
Vishal Verma <vishal.l.verma@intel.com> Signed-off-by:
-
Sven Van Asbroeck authored
[ Upstream commit 2e4b88f7 ] In remove, the clock is disabled before canceling the delayed work. This means that the delayed work may be touching unclocked hardware. Fix by disabling the clock after the delayed work is fully canceled. This is consistent with the probe error path order. Signed-off-by:
Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Sven Van Asbroeck authored
[ Upstream commit 862e4644 ] If probe errors out after request_irq(), its error path does not explicitly cancel the delayed work, which may have been scheduled by the interrupt handler. This means the delayed work may still be running when the core frees the private structure (struct xadc). This is a potential use-after-free. Fix by inserting cancel_delayed_work_sync() in the probe error path. Signed-off-by:
-
Sven Van Asbroeck authored
[ Upstream commit 62039b6a ] When cancel_delayed_work() returns, the delayed work may still be running. This means that the core could potentially free the private structure (struct xadc) while the delayed work is still using it. This is a potential use-after-free. Fix by calling cancel_delayed_work_sync(), which waits for any residual work to finish before returning. Signed-off-by:
-
Johan Hovold authored
commit 3f5edd58 upstream. Fix two long-standing bugs which could potentially lead to memory corruption or leave the port throttled until it is reopened (on weakly ordered systems), respectively, when read-URB completion races with unthrottle(). First, the URB must not be marked as free before processing is complete to prevent it from being submitted by unthrottle() on another CPU. CPU 1 CPU 2 ================ ================ complete() unthrottle() process_urb(); smp_mb__before_atomic(); set_bit(i, free); if (test_and_clear_bit(i, free)) submit_urb(); Second, the URB must be marked as free before checking the throttled flag to prevent unthrottle() on another CPU from failing to observe that the URB needs to be submitted if complete() sees that the throttled flag is set. CPU 1 CPU 2 ================ ================ complete() unthrottle() set_bit(i, free); throttled = 0; smp_mb__after_atomic(); smp_mb(); if (throttled) if (test_and_clear_bit(i, free)) return; submit_urb(); Note that test_and_clear_bit() only implies barriers when the test is successful. To handle the case where the URB is still in use an explicit barrier needs to be added to unthrottle() for the second race condition. Fixes: d83b4053 ("USB: serial: add support for multiple read urbs") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
commit cf4f2ad6 upstream. Userspace can make host function calls, called hgcm-calls through the /dev/vboxguest device. In this case we should not accept all hgcm-function-parameter-types, some are only valid for in kernel calls. This commit adds proper hgcm-function-parameter-type validation to the ioctl for doing a hgcm-call from userspace. Cc: stable@vger.kernel.org Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Andrea Parri authored
commit 99826790 upstream. smp_mb__before_atomic() can not be applied to atomic_set(). Remove the barrier and rely on RELEASE synchronization. Fixes: ba16b284 ("kernfs: add an API to get kernfs node from inode number") Cc: stable@vger.kernel.org Signed-off-by:
Andrea Parri <andrea.parri@amarulasolutions.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Stefan Wahren authored
commit 53f1647d upstream. In case pwm_fan_of_get_cooling_data() fails we should disable the PWM just like in the other error cases. Fixes: 2e5219c7 ("hwmon: (pwm-fan) Read PWM FAN configuration from device tree") Cc: <stable@vger.kernel.org> # 4.14+ Reported-by:
Guenter Rock <linux@roeck-us.net> Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
Mario Limonciello authored
commit 6cc13c28 upstream. When converting the driver two arguments were transposed leading to rfkill not working. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201427Reported-by:
Pepijn de Vos <pepijndevos@gmail.com> Fixes: 549b49 ("platform/x86: dell-smbios: Introduce dispatcher for SMM calls") Signed-off-by:
Mario Limonciello <mario.limonciello@dell.com> Acked-by:
Pali Rohár <pali.rohar@gmail.com> Cc: <stable@vger.kernel.org> # 4.14.x Signed-off-by:
Darren Hart (VMware) <dvhart@infradead.org> Signed-off-by:
-
Jiaxun Yang authored
commit f7db839f upstream. Some AMD based ThinkPads have a firmware bug that calling "GBDC" will cause Bluetooth on Intel wireless cards blocked. Probe these models by DMI match and disable Bluetooth subdriver if specified Intel wireless card exist. Cc: stable <stable@vger.kernel.org> # 4.14+ Signed-off-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Gustavo A. R. Silva authored
commit 1cbd7a64 upstream. It seems that the default case should return AE_CTRL_TERMINATE, instead of falling through to case ACPI_RESOURCE_TYPE_END_TAG and returning AE_OK; otherwise the line of code at the end of the function is unreachable and makes no sense: return AE_CTRL_TERMINATE; This fix is based on the following thread of discussion: https://lore.kernel.org/patchwork/patch/959782/ Fixes: 33a04454 ("sony-laptop: Add SNY6001 device handling (sonypi reimplementation)") Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Jens Axboe authored
commit 77f1e0a5 upstream A previous commit moved the shallow depth and BFQ depth map calculations to be done at init time, moving it outside of the hotter IO path. This potentially causes hangs if the users changes the depth of the scheduler map, by writing to the 'nr_requests' sysfs file for that device. Add a blk-mq-sched hook that allows blk-mq to inform the scheduler if the depth changes, so that the scheduler can update its internal state. Signed-off-by:
Eric Wheeler <bfq@linux.ewheeler.net> Tested-by:
Kai Krakow <kai@kaishome.de> Reported-by:
Paolo Valente <paolo.valente@linaro.org> Fixes: f0635b8a ("bfq: calculate shallow depths at init time") Signed-off-by:
Jens Axboe <axboe@kernel.dk> Cc: stable@vger.kernel.org Signed-off-by:
-
- 14 May, 2019 19 commits
-
-
Greg Kroah-Hartman authored
-
Josh Poimboeuf authored
commit 95310e34 upstream Fix a minor typo in the MDS documentation: "eanbled" -> "enabled". Reported-by:
Jeff Bastian <jbastian@redhat.com> Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Tyler Hicks authored
commit ea01668f upstream Adjust the last two rows in the table that display possible values when MDS mitigation is enabled. They both were slightly innacurate. In addition, convert the table of possible values and their descriptions to a list-table. The simple table format uses the top border of equals signs to determine cell width which resulted in the first column being far too wide in comparison to the second column that contained the majority of the text. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
-
speck for Pawan Gupta authored
commit e672f8bf upstream Updated the documentation for a new CVE-2019-11091 Microarchitectural Data Sampling Uncacheable Memory (MDSUM) which is a variant of Microarchitectural Data Sampling (MDS). MDS is a family of side channel attacks on internal buffers in Intel CPUs. MDSUM is a special case of MSBDS, MFBDS and MLPDS. An uncacheable load from memory that takes a fault or assist can leave data in a microarchitectural structure that may later be observed using one of the same methods used by MSBDS, MFBDS or MLPDS. There are no new code changes expected for MDSUM. The existing mitigation for MDS applies to MDSUM as well. Signed-off-by:
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by:
Jon Masters <jcm@redhat.com> Signed-off-by:
-
Josh Poimboeuf authored
commit 5c14068f upstream Add MDS to the new 'mitigations=' cmdline option. Signed-off-by:
-
Josh Poimboeuf authored
commit 0336e04a upstream Configure s390 runtime CPU speculation bug mitigations in accordance with the 'mitigations=' cmdline option. This affects Spectre v1 and Spectre v2. The default behavior is unchanged. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Cc: Borislav Petkov <bp@alien8.de> Cc: "H . Peter Anvin" <hpa@zytor.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Waiman Long <longman@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Jon Masters <jcm@redhat.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: linux-s390@vger.kernel.org Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-arch@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tyler Hicks <tyhicks@canonical.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Steven Price <steven.price@arm.com> Cc: Phil Auld <pauld@redhat.com> Link: https://lkml.kernel.org/r/e4a161805458a5ec88812aac0307ae3908a030fc.1555085500.git.jpoimboe@redhat.comSigned-off-by:
-
Josh Poimboeuf authored
commit 782e69ef upstream Configure powerpc CPU runtime speculation bug mitigations in accordance with the 'mitigations=' cmdline option. This affects Meltdown, Spectre v1, Spectre v2, and Speculative Store Bypass. The default behavior is unchanged. Signed-off-by:
-
Josh Poimboeuf authored
commit d68be4c4 upstream Configure x86 runtime CPU speculation bug mitigations in accordance with the 'mitigations=' cmdline option. This affects Meltdown, Spectre v2, Speculative Store Bypass, and L1TF. The default behavior is unchanged. Signed-off-by:
-
Josh Poimboeuf authored
commit 98af8452 upstream Keeping track of the number of mitigations for all the CPU speculation bugs has become overwhelming for many users. It's getting more and more complicated to decide which mitigations are needed for a given architecture. Complicating matters is the fact that each arch tends to have its own custom way to mitigate the same vulnerability. Most users fall into a few basic categories: a) they want all mitigations off; b) they want all reasonable mitigations on, with SMT enabled even if it's vulnerable; or c) they want all reasonable mitigations on, with SMT disabled if vulnerable. Define a set of curated, arch-independent options, each of which is an aggregation of existing options: - mitigations=off: Disable all mitigations. - mitigations=auto: [default] Enable all the default mitigations, but leave SMT enabled, even if it's vulnerable. - mitigations=auto,nosmt: Enable all the default mitigations, disabling SMT if needed by a mitigation. Currently, these options are placeholders which don't actually do anything. They will be fleshed out in upcoming patches. Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit e2c3c947 upstream This code is only for CPUs which are affected by MSBDS, but are *not* affected by the other two MDS issues. For such CPUs, enabling the mds_idle_clear mitigation is enough to mitigate SMT. However if user boots with 'mds=off' and still has SMT enabled, we should not report that SMT is mitigated: $cat /sys//devices/system/cpu/vulnerabilities/mds Vulnerable; SMT mitigated But rather: Vulnerable; SMT vulnerable Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Boris Ostrovsky authored
commit cae5ec34 upstream s/L1TF/MDS/ Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Josh Poimboeuf authored
commit 39226ef0 upstream MDS is vulnerable with SMT. Make that clear with a one-time printk whenever SMT first gets enabled. Signed-off-by:
-
Josh Poimboeuf authored
commit 7c3658b2 upstream arch_smt_update() now has a dependency on both Spectre v2 and MDS mitigations. Move its initial call to after all the mitigation decisions have been made. Signed-off-by:
-
Josh Poimboeuf authored
commit d71eb0ce upstream Add the mds=full,nosmt cmdline option. This is like mds=full, but with SMT disabled if the CPU is vulnerable. Signed-off-by:
-
Thomas Gleixner authored
commit 5999bbe7 upstream Add the initial MDS vulnerability documentation. Signed-off-by:
-
Thomas Gleixner authored
commit 65fd4cb6 upstream Move L!TF to a separate directory so the MDS stuff can be added at the side. Otherwise the all hardware vulnerabilites have their own top level entry. Should have done that right away. Signed-off-by:
-
Thomas Gleixner authored
commit 22dd8365 upstream In virtualized environments it can happen that the host has the microcode update which utilizes the VERW instruction to clear CPU buffers, but the hypervisor is not yet updated to expose the X86_FEATURE_MD_CLEAR CPUID bit to guests. Introduce an internal mitigation mode VMWERV which enables the invocation of the CPU buffer clearing even if X86_FEATURE_MD_CLEAR is not set. If the system has no updated microcode this results in a pointless execution of the VERW instruction wasting a few CPU cycles. If the microcode is updated, but not exposed to a guest then the CPU buffers will be cleared. That said: Virtual Machines Will Eventually Receive Vaccine Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
-
Thomas Gleixner authored
commit 8a4b06d3 upstream Add the sysfs reporting file for MDS. It exposes the vulnerability and mitigation state similar to the existing files for the other speculative hardware vulnerabilities. Signed-off-by:
-
Thomas Gleixner authored
commit bc124170 upstream Now that the mitigations are in place, add a command line parameter to control the mitigation, a mitigation selector function and a SMT update mechanism. This is the minimal straight forward initial implementation which just provides an always on/off mode. The command line parameter is: mds=[full|off] This is consistent with the existing mitigations for other speculative hardware vulnerabilities. The idle invocation is dynamically updated according to the SMT state of the system similar to the dynamic update of the STIBP mitigation. The idle mitigation is limited to CPUs which are only affected by MSBDS and not any other variant, because the other variants cannot be mitigated on SMT enabled systems. Signed-off-by:
-
