- 16 May, 2016 5 commits
-
-
Daniel Jurgens authored
BugLink: http://bugs.launchpad.net/bugs/1574697 Maintain the PCI status and provide wrappers for enabling and disabling the PCI device. Performing the actions more than once without doing its opposite results in warning logs. This occurred when EEH hotplugged the device causing a warning for disabling an already disabled device. Fixes: 2ba5fbd6 ('net/mlx4_core: Handle AER flow properly') Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (back ported from commit 4bfd2e6e) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Conflicts: drivers/net/ethernet/mellanox/mlx4/main.c Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Daniel Jurgens authored
BugLink: http://bugs.launchpad.net/bugs/1574697 Move resume related activities to a new pci_resume function instead of performing them in mlx4_pci_slot_reset. This change is needed to avoid a hotplug during EEH recovery due to commit f2da4ccf ("powerpc/eeh: More relaxed hotplug criterion"). Fixes: 2ba5fbd6 ('net/mlx4_core: Handle AER flow properly') Signed-off-by:
-
Pali Rohár authored
BugLink: http://bugs.launchpad.net/bugs/1574498 This patch adds support for controlling keyboard backlight via standard linux led class interface (::kbd_backlight). It uses ACPI HKEY device with MLCG and MLCS methods. Signed-off-by:
Pali Rohár <pali.rohar@gmail.com> Tested-by:
Fabio D'Urso <fabiodurso@hotmail.it> Acked-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> (cherry picked from commit bb28f3d5) Signed-off-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1499089Signed-off-by:
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 12 May, 2016 4 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Radim Krčmář authored
MSR 0x2f8 accessed the 124th Variable Range MTRR ever since MTRR support was introduced by 9ba075a6 ("KVM: MTRR support"). 0x2f8 became harmful when 910a6aae ("KVM: MTRR: exactly define the size of variable MTRRs") shrinked the array of VR MTRRs from 256 to 8, which made access to index 124 out of bounds. The surrounding code only WARNs in this situation, thus the guest gained a limited read/write access to struct kvm_arch_vcpu. 0x2f8 is not a valid VR MTRR MSR, because KVM has/advertises only 16 VR MTRR MSRs, 0x200-0x20f. Every VR MTRR is set up using two MSRs, 0x2f8 was treated as a PHYSBASE and 0x2f9 would be its PHYSMASK, but 0x2f9 was not implemented in KVM, therefore 0x2f8 could never do anything useful and getting rid of it is safe. This fixes CVE-2016-3713. Fixes: 910a6aae ("KVM: MTRR: exactly define the size of variable MTRRs") Cc: stable@vger.kernel.org Reported-by:
David Matlack <dmatlack@google.com> Signed-off-by:
Radim Krèmáø <rkrcmar@redhat.com> BugLink: http://bugs.launchpad.net/bugs/1581201Acked-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
David Howells authored
This fixes CVE-2016-0758. In the ASN.1 decoder, when the length field of an ASN.1 value is extracted, it isn't validated against the remaining amount of data before being added to the cursor. With a sufficiently large size indicated, the check: datalen - dp < 2 may then fail due to integer overflow. Fix this by checking the length indicated against the amount of remaining data in both places a definite length is determined. Whilst we're at it, make the following changes: (1) Check the maximum size of extended length does not exceed the capacity of the variable it's being stored in (len) rather than the type that variable is assumed to be (size_t). (2) Compare the EOC tag to the symbolic constant ASN1_EOC rather than the integer 0. (3) To reduce confusion, move the initialisation of len outside of: for (len = 0; n > 0; n--) { since it doesn't have anything to do with the loop counter n. Signed-off-by:David Howells <dhowells@redhat.com> Reviewed-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by:
David Woodhouse <David.Woodhouse@intel.com> Acked-by:
Peter Jones <pjones@redhat.com> Reference: https://lkml.org/lkml/2016/5/12/270 BugLink: http://bugs.launchpad.net/bugs/1581202Acked-by:
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 05 May, 2016 3 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Jann Horn authored
BugLink: http://bugs.launchpad.net/bugs/1578705 When bpf(BPF_PROG_LOAD, ...) was invoked with a BPF program whose bytecode references a non-map file descriptor as a map file descriptor, the error handling code called fdput() twice instead of once (in __bpf_map_get() and in replace_map_fd_with_map_ptr()). If the file descriptor table of the current task is shared, this causes f_count to be decremented too much, allowing the struct file to be freed while it is still in use (use-after-free). This can be exploited to gain root privileges by an unprivileged user. This bug was introduced in commit 0246e64d ("bpf: handle pseudo BPF_LD_IMM64 insn"), but is only exploitable since commit 1be7f75d ("bpf: enable non-root eBPF programs") because previously, CAP_SYS_ADMIN was required to reach the vulnerable code. (posted publicly according to request by maintainer) Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Steve Beattie <steve.beattie@canonical.com> Signed-off-by:
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 24 Apr, 2016 2 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1574362Signed-off-by:
-
- 22 Apr, 2016 9 commits
-
-
Jon Paul Maloy authored
BugLink: http://bugs.launchpad.net/bugs/1567064 In commit 5cbb28a4 ("tipc: linearize arriving NAME_DISTR and LINK_PROTO buffers") we added linearization of NAME_DISTRIBUTOR, LINK_PROTOCOL/RESET and LINK_PROTOCOL/ACTIVATE to the function tipc_udp_recv(). The location of the change was selected in order to make the commit easily appliable to 'net' and 'stable'. We now move this linearization to where it should be done, in the functions tipc_named_rcv() and tipc_link_proto_rcv() respectively. Reviewed-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Jake Oshins authored
BugLink: http://bugs.launchpad.net/bugs/1570124 Simplify the logic that picks MMIO ranges by pulling out the logic related to trying to lay frame buffer claim on top of where the firmware placed the frame buffer. Signed-off-by:
Jake Oshins <jakeo@microsoft.com> Signed-off-by:
-
Jake Oshins authored
BugLink: http://bugs.launchpad.net/bugs/1570124 Later in the boot sequence, we need to figure out which memory ranges can be given out to various paravirtual drivers. The hyperv_fb driver should, ideally, be placed right on top of the frame buffer, without some other device getting plopped on top of this range in the meantime. Recording this now allows that to be guaranteed. Signed-off-by:
-
Jake Oshins authored
BugLink: http://bugs.launchpad.net/bugs/1570124 This patch changes vmbus_allocate_mmio() and vmbus_free_mmio() so that when child paravirtual devices allocate memory-mapped I/O space, they allocate it privately from a resource tree pointed at by hyperv_mmio and also by the public resource tree iomem_resource. This allows the region to be marked as "busy" in the private tree, but a "bridge window" in the public tree, guaranteeing that no two bridge windows will overlap each other but while also allowing the PCI device children of the bridge windows to overlap that window. One might conclude that this belongs in the pnp layer, rather than in this driver. Rafael Wysocki, the maintainter of the pnp layer, has previously asked that we not modify the pnp layer as it is considered deprecated. This patch is thus essentially a workaround. Signed-off-by:
-
Jake Oshins authored
BugLink: http://bugs.launchpad.net/bugs/1570124 A patch later in this series allocates child nodes in this resource tree. For that to work, this tree needs to be sorted in ascending order. Signed-off-by:
-
Jake Oshins authored
BugLink: http://bugs.launchpad.net/bugs/1570124 Existing code just called release_mem_region(). Adding a wrapper around it allows the more complex range tracking that is introduced later in this patch series. Signed-off-by:
-
Jake Oshins authored
BugLink: http://bugs.launchpad.net/bugs/1570124 In existing code, this tree of resources is created in single-threaded code and never modified after it is created, and thus needs no locking. This patch introduces a semaphore for tree access, as other patches in this series introduce run-time modifications of this resource tree which can happen on multiple threads. Signed-off-by:
-
Andy Whitcroft authored
Reference: https://launchpad.net/ubuntu/+source/virtualbox/5.0.18-dfsg-2build1 BugLink: http://bugs.launchpad.net/bugs/1571156Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1557776Signed-off-by:
-
- 21 Apr, 2016 17 commits
-
-
Hector Marco-Gisbert authored
Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only the stack and the executable are randomized but not other mmapped files (libraries, vDSO, etc.). This patch enables randomization for the libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode. By default on i386 there are 8 bits for the randomization of the libraries, vDSO and mmaps which only uses 1MB of VA. This patch preserves the original randomness, using 1MB of VA out of 3GB or 4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR. The first obvious security benefit is that all objects are randomized (not only the stack and the executable) in legacy mode which highly increases the ASLR effectiveness, otherwise the attackers may use these non-randomized areas. But also sensitive setuid/setgid applications are more secure because currently, attackers can disable the randomization of these applications by setting the ulimit stack to "unlimited". This is a very old and widely known trick to disable the ASLR in i386 which has been allowed for too long. Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE personality flag, but fortunately this doesn't work on setuid/setgid applications because there is security checks which clear Security-relevant flags. This patch always randomizes the mmap_legacy_base address, removing the possibility to disable the ASLR by setting the stack to "unlimited". Signed-off-by:
Hector Marco-Gisbert <hecmargi@upv.es> Acked-by:
Ismael Ripoll Ripoll <iripoll@upv.es> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Arjan van de Ven <arjan@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: akpm@linux-foundation.org Cc: kees Cook <keescook@chromium.org> Link: http://lkml.kernel.org/r/1457639460-5242-1-git-send-email-hecmargi@upv.esSigned-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit 8b8addf8) CVE-2016-3672 BugLink: https://bugs.launchpad.net/bugs/1568523Signed-off-by:
-
Ignat Korchagin authored
Fix potential out-of-bounds write to urb->transfer_buffer usbip handles network communication directly in the kernel. When receiving a packet from its peer, usbip code parses headers according to protocol. As part of this parsing urb->actual_length is filled. Since the input for urb->actual_length comes from the network, it should be treated as untrusted. Any entity controlling the network may put any value in the input and the preallocated urb->transfer_buffer may not be large enough to hold the data. Thus, the malicious entity is able to write arbitrary data to kernel memory. Signed-off-by:
Ignat Korchagin <ignat.korchagin@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit b348d7dd) CVE-2016-3955 BugLink: https://bugs.launchpad.net/bugs/1572666Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1573034Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit e5bdfd50 upstream. This reverts commit d8f00cd6. Tony writes: This upstream commit is causing an oops: d8f00cd6 ("usb: hub: do not clear BOS field during reset device") This patch has already been included in several -stable kernels. Here are the affected kernels: 4.5.0-rc4 (current git) 4.4.2 4.3.6 (currently in review) 4.1.18 3.18.27 3.14.61 How to reproduce the problem: Boot kernel with slub debugging enabled (otherwise memory corruption will cause random oopses later instead of immediately) Plug in USB 3.0 disk to xhci USB 3.0 port dd if=/dev/sdc of=/dev/null bs=65536 (where /dev/sdc is the USB 3.0 disk) Unplug USB cable while dd is still going Oops is immediate: Reported-by:
Tony Battersby <tonyb@cybernetics.com> Cc: Du, Changbin <changbin.du@intel.com> Cc: Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Vladis Dronov authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit fa52bd50 upstream. The usbvision driver crashes when a specially crafted usb device with invalid number of interfaces or endpoints is detected. This fix adds checks that the device has proper configuration expected by the driver. Reported-by:
Ralf Spenneberg <ralf@spenneberg.net> Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Liviu Dudau authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit 70bc916b upstream. ion_buffer_create() will allocate a buffer and then create a DMA mapping for it, but it forgot to set the length of the page entries. Signed-off-by:
Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
Jon Medhurst <tixy@linaro.org> Acked-by:
Laura Abbott <labbott@redhat.com> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit 6c777e87 upstream. 991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug. Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not v4.3 and bisected it to 991de2e5. Sunjin reported that the RocketRAID 272x driver worked in v4.2 but not v4.3. In both cases booting with "pci=routirq" is a workaround. I think the problem is that after 991de2e5, we no longer call pcibios_enable_irq() for upstream bridges. Prior to 991de2e5, when a driver called pci_enable_device(), we recursively called pcibios_enable_irq() for upstream bridges via pci_enable_bridge(). After 991de2e5, we call pcibios_enable_irq() from pci_device_probe() instead of the pci_enable_device() path, which does *not* call pcibios_enable_irq() for upstream bridges. Revert 991de2e5 to fix these driver regressions. Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211 Fixes: 991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") Reported-and-tested-by:
Олег Мороз <oleg.moroz@mcc.vniiem.ru> Reported-by:
Sunjin Yang <fan4326@gmail.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Rafael J. Wysocki <rafael@kernel.org> CC: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit 67b4eab9 upstream. Revert 811a4e6f ("PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"). This is part of reverting 991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it introduced. Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211 Fixes: 991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") Signed-off-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit fe25d078 upstream. Revert 8affb487 ("x86/PCI: Don't alloc pcibios-irq when MSI is enabled"). This is part of reverting 991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it introduced. Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211 Fixes: 991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") Signed-off-by:
-
Alan Stern authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit 972e6a99 upstream. The usbhid driver has inconsistently duplicated code in its post-reset, resume, and reset-resume pathways. reset-resume doesn't check HID_STARTED before trying to restart the I/O queues. resume fails to clear the HID_SUSPENDED flag if HID_STARTED isn't set. resume calls usbhid_restart_queues() with usbhid->lock held and the others call it without holding the lock. The first item in particular causes a problem following a reset-resume if the driver hasn't started up its I/O. URB submission fails because usbhid->urbin is NULL, and this triggers an unending reset-retry loop. This patch fixes the problem by creating a new subroutine, hid_restart_io(), to carry out all the common activities. It also adds some checks that were missing in the original code: After a reset, there's no need to clear any halted endpoints. After a resume, if a reset is pending there's no need to restart any I/O until the reset is finished. After a resume, if the interrupt-IN endpoint is halted there's no need to submit the input URB until the halt has been cleared. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Daniel Fraga <fragabr@gmail.com> Tested-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Benjamin Tissoires authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit 580549ef upstream. Looks like recent changes in the Wacom driver made the Bamboo ONE crashes. The tablet behaves as if it was a regular Bamboo device with pen, touch and pad, but there is no physical pad connected to it. The weird part is that the pad is still sending events and given that there is no input node connected to it, we get anull pointer exception. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317116Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
-
Kailang Yang authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit adcdd0d5 upstream. This is Dell usb dock audio workaround. It was fixed the master volume keep lower. [Some background: the patch essentially skips the controls of a couple of FU volumes. Although the firmware exposes the dB and the value information via the usb descriptor, changing the values (we set the min volume as default) screws up the device. Although this has been fixed in the newer firmware, the devices are shipped with the old firmware, thus we need the workaround in the driver side. -- tiwai] Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Dennis Kadioglu authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit b4203ff5 upstream. Plantronics BT300 does not support reading the sample rate which leads to many lines of "cannot get freq at ep 0x1". This patch adds the USB ID of the BT300 to quirks.c and avoids those error messages. Signed-off-by:
Dennis Kadioglu <denk@post.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit f03b24a8 upstream. Phoenix Audio TMX320 gives the similar error when the sample rate is asked: usb 2-1.3: 2:1: cannot get freq at ep 0x85 usb 2-1.3: 1:1: cannot get freq at ep 0x2 .... Add the corresponding USB-device ID (1de7:0014) to snd_usb_get_sample_rate_quirk() list. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221Signed-off-by:
-
Sven Eckelmann authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit c636b95e upstream. The Lenovo Thinkpad T460s requires the alc_fixup_tpt440_dock as well in order to get working sound output on the docking stations headphone jack. Patch tested on a Thinkpad T460s (20F9CT01WW) using a ThinkPad Ultradock on kernel 4.4.6. Signed-off-by:
Sven Eckelmann <sven@narfation.org> Tested-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit f883982d upstream. HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic working. Also, it suffers from the loopback noise problem, so we should disable aamix path as well. Reported-by:
Derick Eddington <derick.eddington@gmail.com> Signed-off-by:
-
David Henningsson authored
BugLink: http://bugs.launchpad.net/bugs/1573034 commit 2ae95577 upstream. On one of the machines we enable, we found that the actual speaker volume did not always correspond to the volume set in alsamixer. This patch fixes that problem. This patch was orginally written by Kailang @ Realtek, I've rebased it to fit sound git master. BugLink: https://bugs.launchpad.net/bugs/1549660Co-Authored-By:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
