- 01 Dec, 2018 15 commits
-
-
Takashi Iwai authored
commit 65766ee0 upstream. PCM OSS layer may allocate a few temporary buffers, one for the core read/write and another for the conversions via plugins. Currently both are allocated via vmalloc(). But as the allocation size is equivalent with the PCM period size, the required size might be quite small, depending on the application. This patch replaces these vmalloc() calls with kvzalloc() for covering small period sizes better. Also, we use "z"-alloc variant here for addressing the possible uninitialized access reported by syzkaller. Reported-by: syzbot+1cb36954e127c98dd037@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mathias Nyman authored
commit 2f31a67f upstream. USB3 roothub might autosuspend before a plugged USB3 device is detected, causing USB3 device enumeration failure. USB3 devices don't show up as connected and enabled until USB3 link trainig completes. On a fast booting platform with a slow USB3 link training the link might reach the connected enabled state just as the bus is suspending. If this device is discovered first time by the xhci_bus_suspend() routine it will be put to U3 suspended state like the other ports which failed to suspend earlier. The hub thread will notice the connect change and resume the bus, moving the port back to U0 This U0 -> U3 -> U0 transition right after being connected seems to be too much for some devices, causing them to first go to SS.Inactive state, and finally end up stuck in a polling state with reset asserted Fix this by failing the bus suspend if a port has a connect change or is in a polling state in xhci_bus_suspend(). Don't do any port changes until all ports are checked, buffer all port changes and only write them in the end if suspend can proceed Cc: stable@vger.kernel.org Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Cherian, George authored
commit 11644a76 upstream. Implement workaround for ThunderX2 Errata-129 (documented in CN99XX Known Issues" available at Cavium support site). As per ThunderX2errata-129, USB 2 device may come up as USB 1 if a connection to a USB 1 device is followed by another connection to a USB 2 device, the link will come up as USB 1 for the USB 2 device. Resolution: Reset the PHY after the USB 1 device is disconnected. The PHY reset sequence is done using private registers in XHCI register space. After the PHY is reset we check for the PLL lock status and retry the operation if it fails. From our tests, retrying 4 times is sufficient. Add a new quirk flag XHCI_RESET_PLL_ON_DISCONNECT to invoke the workaround in handle_xhci_port_status(). Cc: stable@vger.kernel.org Signed-off-by:
George Cherian <george.cherian@cavium.com> Signed-off-by:
-
Aaron Ma authored
commit a5baeaea upstream. This definition is used by msecs_to_jiffies in milliseconds. According to the comments, max rexit timeout should be 20ms. Align with the comments to properly calculate the delay. Verified on Sunrise Point-LP and Cannon Lake. Cc: stable@vger.kernel.org Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Signed-off-by:
-
Aaron Ma authored
commit 958c0bd8 upstream. Realtek USB3.0 Card Reader [0bda:0328] reports wrong port status on Cannon lake PCH USB3.1 xHCI [8086:a36d] after resume from S3, after clear port reset it works fine. Since this device is registered on USB3 roothub at boot, when port status reports not superspeed, xhci_get_port_status will call an uninitialized completion in bus_state[0]. Kernel will hang because of NULL pointer. Restrict the USB2 resume status check in USB2 roothub to fix hang issue. Cc: stable@vger.kernel.org Signed-off-by:
-
Sandeep Singh authored
commit d9193efb upstream. Observed "TRB completion code (27)" error which corresponds to Stopped - Length Invalid error(xhci spec section 4.17.4) while connecting USB to SATA bridge. Looks like this case was not considered when the following patch[1] was committed. Hence adding this new check which can prevent the invalid byte size error. [1] ade2e3a1 xhci: handle transfer events without TRB pointer Cc: <stable@vger.kernel.org> Signed-off-by:
Sandeep Singh <sandeep.singh@amd.com> cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by:
-
Mathias Nyman authored
commit 1245374e upstream. At xhci removal the USB3 hcd (shared_hcd) is removed before the primary USB2 hcd. Interrupts for port status changes may still occur for USB3 ports after the shared_hcd is freed, causing NULL pointer dereference. Check if xhci->shared_hcd is still valid before handing USB3 port events Cc: <stable@vger.kernel.org> Reported-by:
Peter Chen <peter.chen@nxp.com> Tested-by:
Jack Pham <jackp@codeaurora.org> Signed-off-by:
-
Mathias Nyman authored
commit f0680904 upstream. Ensure that the shared_hcd pointer is valid when calling usb_put_hcd() The shared_hcd is removed and freed in xhci by first calling usb_remove_hcd(xhci->shared_hcd), and later usb_put_hcd(xhci->shared_hcd) Afer commit fe190ed0 ("xhci: Do not halt the host until both HCD have disconnected their devices.") the shared_hcd was never properly put as xhci->shared_hcd was set to NULL before usb_put_hcd(xhci->shared_hcd) was called. shared_hcd (USB3) is removed before primary hcd (USB2). While removing the primary hcd we might need to handle xhci interrupts to cleanly remove last USB2 devices, therefore we need to set xhci->shared_hcd to NULL before removing the primary hcd to let xhci interrupt handler know shared_hcd is no longer available. xhci-plat.c, xhci-histb.c and xhci-mtk first create both their hcd's before adding them. so to keep the correct reverse removal order use a temporary shared_hcd variable for them. For more details see commit 4ac53087 ("usb: xhci: plat: Create both HCDs before adding them") Fixes: fe190ed0 ("xhci: Do not halt the host until both HCD have disconnected their devices.") Cc: Joel Stanley <joel@jms.id.au> Cc: Chunfeng Yun <chunfeng.yun@mediatek.com> Cc: Thierry Reding <treding@nvidia.com> Cc: Jianguo Sun <sunjianguo1@huawei.com> Cc: <stable@vger.kernel.org> Reported-by:
-
Kuppuswamy Sathyanarayanan authored
commit 7b412b04 upstream. In dwc3_pci_quirks() function, gpiod lookup table is only registered for baytrail SOC. But in dwc3_pci_remove(), we try to unregistered it without any checks. This leads to NULL pointer de-reference exception in gpiod_remove_lookup_table() when unloading the module for non baytrail SOCs. This patch fixes this issue. Fixes: 5741022c ("usb: dwc3: pci: Add GPIO lookup table on platforms without ACPI GPIO resources") Cc: <stable@vger.kernel.org> Signed-off-by:
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
commit 08fd9a82 upstream. If dwc3_core_init_mode() fails with deferred probe, next probe fails on sysfs with sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:11.0/dwc3.0.auto/dwc3.0.auto.ulpi' To avoid this failure, clean up ULPI device. Cc: <stable@vger.kernel.org> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Thinh Nguyen authored
commit ba3a51ac upstream. Current check for the last extra TRB for zero and unaligned transfers does not account for isoc OUT. The last TRB of the Buffer Descriptor for isoc OUT transfers will be retired with HWO=0. As a result, we won't return early. The req->remaining will be updated to include the BUFSIZ count of the extra TRB, and the actual number of transferred bytes calculation will be wrong. To fix this, check whether it's a short or zero packet and the last TRB chain bit to return early. Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: <stable@vger.kernel.org> Signed-off-by:
Thinh Nguyen <thinhn@synopsys.com> Signed-off-by:
-
Felipe Balbi authored
commit 2fc6d4be upstream. When chaining ISOC TRBs together, only the first ISOC TRB should be of type ISOC_FIRST, all others should be of type ISOC. This patch fixes that. Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by:
-
Dennis Wassenberg authored
commit 22454b79 upstream. This will clear the USB_PORT_FEAT_C_CONNECTION bit in case of a hub port reset only if a device is was attached to the hub port before resetting the hub port. Using a Lenovo T480s attached to the ultra dock it was not possible to detect some usb-c devices at the dock usb-c ports because the hub_port_reset code will clear the USB_PORT_FEAT_C_CONNECTION bit after the actual hub port reset. Using this device combo the USB_PORT_FEAT_C_CONNECTION bit was set between the actual hub port reset and the clear of the USB_PORT_FEAT_C_CONNECTION bit. This ends up with clearing the USB_PORT_FEAT_C_CONNECTION bit after the new device was attached such that it was not detected. This patch will not clear the USB_PORT_FEAT_C_CONNECTION bit if there is currently no device attached to the port before the hub port reset. This will avoid clearing the connection bit for new attached devices. Signed-off-by:
Dennis Wassenberg <dennis.wassenberg@secunet.com> Acked-by:
-
Alistair Strachan authored
commit 41f1c484 upstream. When building with CONFIG_EFI and CONFIG_EFI_STUB on ARM, the libstub Makefile would use -mno-single-pic-base without checking it was supported by the compiler. As the ARM (32-bit) clang backend does not support this flag, the build would fail. This changes the Makefile to check the compiler's support for -mno-single-pic-base before using it, similar to c1c38668 ("ARM: 8767/1: add support for building ARM kernel with clang"). Signed-off-by:
Alistair Strachan <astrachan@google.com> Reviewed-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Rodrigo Rivas Costa authored
commit 385a4886 upstream. Previously, when a HID client such as the Steam Client was running, this driver disabled its input device to avoid doubling the input events. While it worked mostly fine, some games got confused by the idle gamepad, and switched to two player mode, or asked the user to choose which gamepad to use. Other games just crashed, probably a bug in Unity [1]. With this commit, when a HID client starts, the input device is removed; when the HID client ends the input device is recreated. [1]: https://github.com/ValveSoftware/steam-for-linux/issues/5645Signed-off-by:
Rodrigo Rivas Costa <rodrigorivascosta@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Cc: Pierre-Loup Griffais <pgriffais@valvesoftware.com> Signed-off-by:
-
- 27 Nov, 2018 25 commits
-
-
Greg Kroah-Hartman authored
-
Lorenzo Bianconi authored
commit 473f0a76 upstream. According to vendor sdk, vco calibration has to be executed for each channel configuration whereas mcu calibration has to be performed during channel scanning. This patch fixes the mt76x0 monitor mode issue since in that configuration vco calibration was never executed Fixes: 10de7a8b ("mt76x0: phy files") Tested-by:
Sid Hayn <sidhayn@gmail.com> Signed-off-by:
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name> Cc: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Ilya Dryomov authored
commit 7e241f64 upstream. skb_can_coalesce() allows coalescing neighboring slab objects into a single frag: return page == skb_frag_page(frag) && off == frag->page_offset + skb_frag_size(frag); ceph_tcp_sendpage() can be handed slab pages. One example of this is XFS: it passes down sector sized slab objects for its metadata I/O. If the kernel client is co-located on the OSD node, the skb may go through loopback and pop on the receive side with the exact same set of frags. When tcp_recvmsg() attempts to copy out such a frag, hardened usercopy complains because the size exceeds the object's allocated size: usercopy: kernel memory exposure attempt detected from ffff9ba917f20a00 (kmalloc-512) (1024 bytes) Although skb_can_coalesce() could be taught to return false if the resulting frag would cross a slab object boundary, we already have a fallback for non-refcounted pages. Utilize it for slab pages too. Cc: stable@vger.kernel.org # 4.8+ Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Sebastian Parschauer authored
commit e82e62e3 upstream. The PixArt OEM mice are known for disconnecting every minute in runlevel 1 or 3 if they are not always polled. So add quirk ALWAYS_POLL for this one as well. References: https://www.spinics.net/lists/linux-usb/msg88965.html http://linet.gr.jp/~kojima/PlamoWeb/ML/htdocs/201808/msg00019.htmlSigned-off-by:
Sebastian Parschauer <sparschauer@suse.de> CC: stable@vger.kernel.org Signed-off-by:
-
Sebastian Parschauer authored
commit fb862c3b upstream. The PixArt OEM mice are known for disconnecting every minute in runlevel 1 or 3 if they are not always polled. So add quirk ALWAYS_POLL for two Primax mice as well. 0x4e22 is the Dell MS111-P and 0x4d0f is the unbranded HP Portia mouse HP 697738-001. Both were built until approx. 2014. Those were the standard mice from those vendors and are still around - even as new old stock. Reference: https://github.com/sriemer/fix-linux-mouse/issues/11Signed-off-by:
-
Eric Biggers authored
commit 8c01db76 upstream. When a UHID_CREATE command is written to the uhid char device, a copy_from_user() is done from a user pointer embedded in the command. When the address limit is KERNEL_DS, e.g. as is the case during sys_sendfile(), this can read from kernel memory. Alternatively, information can be leaked from a setuid binary that is tricked to write to the file descriptor. Therefore, forbid UHID_CREATE in these cases. No other commands in uhid_char_write() are affected by this bug and UHID_CREATE is marked as "obsolete", so apply the restriction to UHID_CREATE only rather than to uhid_char_write() entirely. Thanks to Dmitry Vyukov for adding uhid definitions to syzkaller and to Jann Horn for commit 9da3f2b7 ("x86/fault: BUG() when uaccess helpers fault on kernel addresses"), allowing this bug to be found. Reported-by: syzbot+72473edc9bf4eb1c6556@syzkaller.appspotmail.com Fixes: d365c6cf ("HID: uhid: add UHID_CREATE and UHID_DESTROY events") Cc: <stable@vger.kernel.org> # v3.6+ Cc: Jann Horn <jannh@google.com> Cc: Andy Lutomirski <luto@kernel.org> Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Jann Horn <jannh@google.com> Signed-off-by:
-
Hans de Goede authored
commit 2bbb5fa3 upstream. Many HP AMD based laptops contain an SMB0001 device like this: Device (SMBD) { Name (_HID, "SMB0001") // _HID: Hardware ID Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { IO (Decode16, 0x0B20, // Range Minimum 0x0B20, // Range Maximum 0x20, // Alignment 0x20, // Length ) IRQ (Level, ActiveLow, Shared, ) {7} }) } The legacy style IRQ resource here causes acpi_dev_get_irqresource() to be called with legacy=true and this message to show in dmesg: ACPI: IRQ 7 override to edge, high This causes issues when later on the AMD0030 GPIO device gets enumerated: Device (GPIO) { Name (_HID, "AMDI0030") // _HID: Hardware ID Name (_CID, "AMDI0030") // _CID: Compatible ID Name (_UID, Zero) // _UID: Unique ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) { 0x00000007, } Memory32Fixed (ReadWrite, 0xFED81500, // Address Base 0x00000400, // Address Length ) }) Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */ } } Now acpi_dev_get_irqresource() gets called with legacy=false, but because of the earlier override of the trigger-type acpi_register_gsi() returns -EBUSY (because we try to register the same interrupt with a different trigger-type) and we end up setting IORESOURCE_DISABLED in the flags. The setting of IORESOURCE_DISABLED causes platform_get_irq() to call acpi_irq_get() which is not implemented on x86 and returns -EINVAL. resulting in the following in dmesg: amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22 amd_gpio: probe of AMDI0030:00 failed with error -22 The SMB0001 is a "virtual" device in the sense that the only way the OS interacts with it is through calling a couple of methods to do SMBus transfers. As such it is weird that it has IO and IRQ resources at all, because the driver for it is not expected to ever access the hardware directly. The Linux driver for the SMB0001 device directly binds to the acpi_device through the acpi_bus, so we do not need to instantiate a platform_device for this ACPI device. This commit adds the SMB0001 HID to the forbidden_id_list, avoiding the instantiating of a platform_device for it. Not instantiating a platform_device means we will no longer call acpi_dev_get_irqresource() for the legacy IRQ resource fixing the probe of the AMDI0030 device failing. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1644013 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198715 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199523Reported-by:
Lukas Kahnert <openproggerfreak@gmail.com> Tested-by:
Marc <suaefar@googlemail.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Gustavo A. R. Silva authored
commit fee05f45 upstream. req.gid can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: vers/misc/sgi-gru/grukdump.c:200 gru_dump_chiplet_request() warn: potential spectre issue 'gru_base' [w] Fix this by sanitizing req.gid before calling macro GID_TO_GRU, which uses it to index gru_base. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Johan Hovold authored
commit 5d1e9c22 upstream. Use the new of_get_compatible_child() helper to lookup the nfc child node instead of using of_find_compatible_node(), which searches the entire tree from a given start node and thus can return an unrelated (i.e. non-child) node. This also addresses a potential use-after-free (e.g. after probe deferral) as the tree-wide helper drops a reference to its first argument (i.e. the node of the device being probed). While at it, also fix a related nfc-node reference leak. Fixes: f88fc122 ("mtd: nand: Cleanup/rework the atmel_nand driver") Cc: stable <stable@vger.kernel.org> # 4.11 Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Josh Wu <rainyfeeling@outlook.com> Cc: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by:
-
Johan Hovold authored
commit 1decef37 upstream. Passing a timeout of zero to the synchronous serdev_device_write() helper does currently not imply to wait forever (unlike passing zero to serdev_device_wait_until_sent()). Instead, if there's insufficient room in the write buffer, we'd end up with an incomplete write. Fixes: d2efbbd1 ("gnss: add driver for sirfstar-based receivers") Cc: stable <stable@vger.kernel.org> # 4.19 Signed-off-by:
-
Johan Hovold authored
commit 56a6c726 upstream. Passing a timeout of zero to the synchronous serdev_device_write() helper does currently not imply to wait forever (unlike passing zero to serdev_device_wait_until_sent()). Instead, if there's insufficient room in the write buffer, we'd end up with an incomplete write. Fixes: 37768b05 ("gnss: add generic serial driver") Cc: stable <stable@vger.kernel.org> # 4.19 Signed-off-by:
-
Mattias Jacobsson authored
commit f6501f49 upstream. Add another Apple Cinema Display to the list of supported displays Signed-off-by:
Mattias Jacobsson <2pi@mok.nu> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Nathan Chancellor authored
commit 7c973012 upstream. After building the kernel with Clang, the following section mismatch warning appears: WARNING: vmlinux.o(.text+0x3bf19a6): Section mismatch in reference from the function ssc_probe() to the function .init.text:atmel_ssc_get_driver_data() The function ssc_probe() references the function __init atmel_ssc_get_driver_data(). This is often because ssc_probe lacks a __init annotation or the annotation of atmel_ssc_get_driver_data is wrong. Remove __init from atmel_ssc_get_driver_data to get rid of the mismatch. Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Emmanuel Pescosta authored
commit a7711257 upstream. Following on from this patch: https://lkml.org/lkml/2017/11/3/516, Corsair K70 LUX RGB keyboards also require the DELAY_INIT quirk to start correctly at boot. Dmesg output: usb 1-6: string descriptor 0 read error: -110 usb 1-6: New USB device found, idVendor=1b1c, idProduct=1b33 usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-6: can't set config #1, error -110 Signed-off-by:
Emmanuel Pescosta <emmanuelpescosta099@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Kai-Heng Feng authored
commit 781f0766 upstream. Devices connected under Terminus Technology Inc. Hub (1a40:0101) may fail to work after the system resumes from suspend: [ 206.063325] usb 3-2.4: reset full-speed USB device number 4 using xhci_hcd [ 206.143691] usb 3-2.4: device descriptor read/64, error -32 [ 206.351671] usb 3-2.4: device descriptor read/64, error -32 Info for this hub: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1a40 ProdID=0101 Rev=01.11 S: Product=USB 2.0 Hub C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub Some expirements indicate that the USB devices connected to the hub are innocent, it's the hub itself is to blame. The hub needs extra delay time after it resets its port. Hence wait for extra delay, if the device is connected to this quirky hub. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Kai-Heng Feng authored
commit deefd242 upstream. Raydium USB touchscreen fails to set config if LPM is enabled: [ 2.030658] usb 1-8: New USB device found, idVendor=2386, idProduct=3119 [ 2.030659] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2.030660] usb 1-8: Product: Raydium Touch System [ 2.030661] usb 1-8: Manufacturer: Raydium Corporation [ 7.132209] usb 1-8: can't set config #1, error -110 Same behavior can be observed on 2386:3114. Raydium claims the touchscreen supports LPM under Windows, so I used Microsoft USB Test Tools (MUTT) [1] to check its LPM status. MUTT shows that the LPM doesn't work under Windows, either. So let's just disable LPM for Raydium touchscreens. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-test-toolsSigned-off-by:
-
Maarten Jacobs authored
commit 63529eaa upstream. The cdc-acm kernel module currently does not support the Hiro (Conexant) H05228 USB modem. The patch below adds the device specific information: idVendor 0x0572 idProduct 0x1349 Signed-off-by:
Maarten Jacobs <maarten256@outlook.com> Acked-by:
Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Jimmy Assarsson authored
commit 95217260 upstream. If alloc_can_err_skb() fails, cf is never initialized. Move assignment of cf inside check. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jimmy Assarsson <jimmyassarsson@gmail.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Jimmy Assarsson authored
commit e13fb9b3 upstream. The call to can_put_echo_skb() may result in the skb being freed. The skb is later used in the call to dev->ops->dev_frame_to_cmd(). This is avoided by moving the call to can_put_echo_skb() after dev->ops->dev_frame_to_cmd(). Reported-by:
-
Takashi Iwai authored
commit d99501b8 upstream. We need to call pci_iounmap() instead of iounmap() for the regions obtained via pci_iomap() call for some archs that need special treatment. Fixes: aa31704f ("ALSA: hda/ca0132: Add PCI region2 iomap for SBZ") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
commit 563785ed upstream. HP Pavilion 15 (103c:820d) with ALC295 codec requires the quirk for the mute LED control over mic3 pin. Added the corresponding quirk entry. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201653 Cc: <stable@vger.kernel.org> Signed-off-by:
-
Dan Carpenter authored
commit 43279819 upstream. I was trying to solve a double free but I introduced a more serious NULL dereference bug. The problem is that if there is an IRQ which triggers immediately, then we need "info->uio_dev" but it's not set yet. This patch puts the original initialization back to how it was and just sets info->uio_dev to NULL on the error path so it should solve both the Oops and the double free. Fixes: f019f07e ("uio: potential double frees if __uio_register_device() fails") Reported-by:
Mathias Thore <Mathias.Thore@infinera.com> Signed-off-by:
-
Olof Johansson authored
commit 21f70d4a upstream. Sparse highlighted it, and appears to be a pure bug (from vs to). ./arch/riscv/include/asm/uaccess.h:403:35: warning: incorrect type in argument 1 (different address spaces) ./arch/riscv/include/asm/uaccess.h:403:39: warning: incorrect type in argument 2 (different address spaces) ./arch/riscv/include/asm/uaccess.h:409:37: warning: incorrect type in argument 1 (different address spaces) ./arch/riscv/include/asm/uaccess.h:409:41: warning: incorrect type in argument 2 (different address spaces) Signed-off-by:
Olof Johansson <olof@lixom.net> Cc: stable@vger.kernel.org Signed-off-by:
Palmer Dabbelt <palmer@sifive.com> Signed-off-by:
-
Aaro Koskinen authored
commit 82fba2df upstream. Re-enable OCTEON USB driver which is needed on older hardware (e.g. EdgeRouter Lite) for mass storage etc. This got accidentally deleted when config options were changed for OCTEON2/3 USB. Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Paul Burton <paul.burton@mips.com> Fixes: f922bc0a ("MIPS: Octeon: cavium_octeon_defconfig: Enable more drivers") Patchwork: https://patchwork.linux-mips.org/patch/21077/ Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 4.14+ Signed-off-by:
-
Sakari Ailus authored
commit 92539d3e upstream. Patch ad608fbc changed how events were subscribed to address an issue elsewhere. As a side effect of that change, the "add" callback was called before the event subscription was added to the list of subscribed events, causing the first event queued by the add callback (and possibly other events arriving soon afterwards) to be lost. Fix this by adding the subscription to the list before calling the "add" callback, and clean up afterwards if that fails. Fixes: ad608fbc ("media: v4l: event: Prevent freeing event subscriptions while accessed") Reported-by:
Dave Stevenson <dave.stevenson@raspberrypi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Tested-by:
Hans Verkuil <hans.verkuil@cisco.com> Tested-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
