- 01 Dec, 2018 34 commits
-
-
Xin Long authored
commit df132eff upstream. If a transport is removed by asconf but there still are some chunks with this transport queuing on out_chunk_list, later an use-after-free issue will be caused when accessing this transport from these chunks in sctp_outq_flush(). This is an old bug, we fix it by clearing the transport of these chunks in out_chunk_list when removing a transport in sctp_assoc_rm_peer(). Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tetsuo Handa authored
commit 9f2df09a upstream. syzbot is reporting too large memory allocation at bfs_fill_super() [1]. Since file system image is corrupted such that bfs_sb->s_start == 0, bfs_fill_super() is trying to allocate 8MB of continuous memory. Fix this by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and printf(). [1] https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96 Link: http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jpSigned-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by:
syzbot <syzbot+71c6b5d68e91149fc8a4@syzkaller.appspotmail.com> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Tigran Aivazian <aivazian.tigran@gmail.com> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dmitry Torokhov authored
commit f39f8688 upstream. synaptics_detect() does not check whether sending commands to the device succeeds and instead relies on getting unique data from the device. Let's make sure we seed entire buffer with zeroes to make sure we will not use garbage on stack that just happen to be 0x47. Reported-by: syzbot+13cb3b01d0784e4ffc3f@syzkaller.appspotmail.com Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Tetsuo Handa authored
commit 4458bba0 upstream. syzbot is hitting warning at str_read() [1] because len parameter can become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for this case. [1] https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0Signed-off-by:
syzbot <syzbot+ac488b9811036cea7ea0@syzkaller.appspotmail.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Dominique Martinet authored
commit 81c99089 upstream. p9stat_read will call p9stat_free on error, we should only free the struct content on success. There also is no need to "p9stat_init" st as the read function will zero the whole struct for us anyway, so clean up the code a bit while we are here. Link: http://lkml.kernel.org/r/1535410108-20650-1-git-send-email-asmadeus@codewreck.orgSigned-off-by:
Dominique Martinet <dominique.martinet@cea.fr> Reported-by: syzbot+d4252148d198410b864f@syzkaller.appspotmail.com Signed-off-by:
-
Konstantin Khlebnikov authored
commit 9de9aa45 upstream. Rename duplicate sysfs_read_file into cpupower_read_sysfs and fix linking. Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Acked-by:
Thomas Renninger <trenn@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by:
Shuah Khan (Samsung OSG) <shuah@kernel.org> Signed-off-by:
-
Keerthy authored
commit 622fecbc upstream. _get_optimal_vdd_voltage call provides new_supply_vbb->u_volt as the reference voltage while it should be really new_supply_vdd->u_volt. Cc: 4.16+ <stable@vger.kernel.org> # v4.16+ Fixes: 9a835fa6 ("PM / OPP: Add ti-opp-supply driver") Signed-off-by:
Keerthy <j-keerthy@ti.com> Acked-by:
Dave Gerlach <d-gerlach@ti.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Keerthy authored
commit ba038546 upstream. The voltage range (min, max) provided in the device tree is from the data manual and is pretty big, catering to a wide range of devices. On a i2c read/write failure the regulator_set_voltage_triplet function falls back to set voltage between min and max. The min value from Device Tree can be lesser than the optimal value and in that case that can lead to a hang or crash. Hence set the u_volt_min dynamically to the optimal voltage value. Cc: 4.16+ <stable@vger.kernel.org> # v4.16+ Fixes: 9a835fa6 ("PM / OPP: Add ti-opp-supply driver") Signed-off-by:
-
Rafał Miłecki authored
commit d1fe6ad6 upstream. Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's important to provide valid & complete info about supported bands for each channel. By default no support for 160 MHz should be assumed unless firmware reports it for a given channel later. This fixes info passed to the userspace. Without that change userspace could try to use invalid channel and fail to start an interface. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Cc: stable@vger.kernel.org Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Luca Coelho authored
commit 5d041c46 upstream. We can't use SAR Geo if basic SAR is not enabled, since the SAR Geo tables define offsets in relation to the basic SAR table in use. To fix this, make iwl_mvm_sar_init() return one in case WRDS is not available, so we can skip reading WGDS entirely. Fixes: a6bff3cb ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table") Cc: stable@vger.kernel.org # 4.12+ Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 82715ac7 upstream. When the firmware starts, it doesn't have any regulatory information, hence it uses the world wide limitations. The driver can feed the firmware with previous knowledge that was kept in the driver, but the firmware may still not update its internal tables. This happens when we start a BSS interface, and then the firmware can change the regulatory tables based on our location and it'll use more lenient, location specific rules. Then, if the firmware is shut down (when the interface is brought down), and then an AP interface is created, the firmware will forget the country specific rules. The host will think that we are in a certain country that may allow channels and will try to teach the firmware about our location, but the firmware may still not allow to drop the world wide limitations and apply country specific rules because it was just re-started. In this case, the firmware will reply with MCC_RESP_ILLEGAL to the MCC_UPDATE_CMD. In that case, iwlwifi needs to let the upper layers (cfg80211 / hostapd) know that the channel list they know about has been updated. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201105 Cc: stable@vger.kernel.org Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit ec484d03 upstream. The oldest firmware supported by iwlmvm do support getting the average beacon RSSI. Enable the sta_statistics() call from mac80211 even on older firmware versions. Fixes: 33cef925 ("iwlwifi: mvm: support beacon statistics for BSS client") Cc: stable@vger.kernel.org # 4.2+ Signed-off-by:
-
Matt Chen authored
commit 66e83903 upstream. From coreboot/BIOS: Name ("WGDS", Package() { Revision, Package() { DomainType, // 0x7:WiFi ==> We miss this one. WgdsWiFiSarDeltaGroup1PowerMax1, // Group 1 FCC 2400 Max WgdsWiFiSarDeltaGroup1PowerChainA1, // Group 1 FCC 2400 A Offset WgdsWiFiSarDeltaGroup1PowerChainB1, // Group 1 FCC 2400 B Offset WgdsWiFiSarDeltaGroup1PowerMax2, // Group 1 FCC 5200 Max WgdsWiFiSarDeltaGroup1PowerChainA2, // Group 1 FCC 5200 A Offset WgdsWiFiSarDeltaGroup1PowerChainB2, // Group 1 FCC 5200 B Offset WgdsWiFiSarDeltaGroup2PowerMax1, // Group 2 EC Jap 2400 Max WgdsWiFiSarDeltaGroup2PowerChainA1, // Group 2 EC Jap 2400 A Offset WgdsWiFiSarDeltaGroup2PowerChainB1, // Group 2 EC Jap 2400 B Offset WgdsWiFiSarDeltaGroup2PowerMax2, // Group 2 EC Jap 5200 Max WgdsWiFiSarDeltaGroup2PowerChainA2, // Group 2 EC Jap 5200 A Offset WgdsWiFiSarDeltaGroup2PowerChainB2, // Group 2 EC Jap 5200 B Offset WgdsWiFiSarDeltaGroup3PowerMax1, // Group 3 ROW 2400 Max WgdsWiFiSarDeltaGroup3PowerChainA1, // Group 3 ROW 2400 A Offset WgdsWiFiSarDeltaGroup3PowerChainB1, // Group 3 ROW 2400 B Offset WgdsWiFiSarDeltaGroup3PowerMax2, // Group 3 ROW 5200 Max WgdsWiFiSarDeltaGroup3PowerChainA2, // Group 3 ROW 5200 A Offset WgdsWiFiSarDeltaGroup3PowerChainB2, // Group 3 ROW 5200 B Offset } }) When read the ACPI data to find out the WGDS, the DATA_SIZE is never matched. From the above format, it gives 19 numbers, but our driver is hardcode as 18. Fix it to pass then can parse the data into our wgds table. Then we will see: iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init Sending GEO_TX_POWER_LIMIT iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[0] Band[0]: chain A = 68 chain B = 69 max_tx_power = 54 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[0] Band[1]: chain A = 48 chain B = 49 max_tx_power = 70 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[1] Band[0]: chain A = 51 chain B = 67 max_tx_power = 50 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[1] Band[1]: chain A = 69 chain B = 70 max_tx_power = 68 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[2] Band[0]: chain A = 49 chain B = 50 max_tx_power = 48 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[2] Band[1]: chain A = 52 chain B = 53 max_tx_power = 51 Cc: stable@vger.kernel.org # 4.12+ Fixes: a6bff3cb ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table") Signed-off-by:
Matt Chen <matt.chen@intel.com> Signed-off-by:
-
Vladimir Zapolskiy authored
commit a05a1404 upstream. The change corrects the error path in gpiochip_add_data_with_key() by avoiding to call ida_simple_remove(), if ida_simple_get() returns an error. Note that ida_simple_remove()/ida_free() throws a BUG(), if id argument is negative, it allows to easily check the correctness of the fix by fuzzing the return value from ida_simple_get(). Fixes: ff2b1359 ("gpio: make the gpiochip a real device") Cc: stable@vger.kernel.org # v4.6+ Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Adrian Hunter authored
commit 5305ec6a upstream. GLK firmware can indicate that the tuning value will be restored after runtime suspend, but not actually do that. Add a workaround that detects such cases, and lets the driver do re-tuning instead. Reported-by:
Anisse Astier <anisse@astier.eu> Tested-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Rajat Jain authored
commit cdcefe6b upstream. Problem: The card detect IRQ does not work with modern BIOS (that want to use _DSD to provide the card detect GPIO to the driver). Details: The mmc core provides the mmc_gpiod_request_cd() API to let host drivers request the gpio descriptor for the "card detect" pin. This pin is specified in the ACPI for the SDHC device: * Either as a resource using _CRS. This is a method used by legacy BIOS. (The driver needs to tell which resource index). * Or as a named property ("cd-gpios"/"cd-gpio") in _DSD (which internally points to an entry in _CRS). This way, the driver can lookup using a string. This is what modern BIOS prefer to use. This API finally results in a call to the following code: struct gpio_desc *acpi_find_gpio(..., const char *con_id,...) { ... /* Lookup gpio (using "<con_id>-gpio") in the _DSD */ ... if (!acpi_can_fallback_to_crs(adev, con_id)) return ERR_PTR(-ENOENT); ... /* Falling back to _CRS is allowed, Lookup gpio in the _CRS */ ... } Note that this means that if the ACPI has _DSD properties, the kernel will never use _CRS for the lookup (Because acpi_can_fallback_to_crs() will always be false for any device hat has _DSD entries). The SDHCI driver is thus currently broken on a modern BIOS, even if BIOS provides both _CRS (for index based lookup) and _DSD entries (for string based lookup). Ironically, none of these will be used for the lookup currently because: * Since the con_id is NULL, acpi_find_gpio() does not find a matching entry in DSDT. (The _DSDT entry has the property name = "cd-gpios") * Because ACPI contains DSDT entries, thus acpi_can_fallback_to_crs() returns false (because device properties have been populated from _DSD), thus the _CRS is never used for the lookup. Fix: Try "cd" for lookup in the _DSD before falling back to using NULL so as to try looking up in the _CRS. I've tested this patch successfully with both Legacy BIOS (that provide only _CRS method) as well as modern BIOS (that provide both _CRS and _DSD). Also the use of "cd" appears to be fairly consistent across other users of this API (other MMC host controller drivers). Link: https://lkml.org/lkml/2018/9/25/1113Signed-off-by:
Rajat Jain <rajatja@google.com> Acked-by:
-
Will Deacon authored
commit 544b03da upstream. At the request of the reporter, the Linux kernel security team offers to postpone the publishing of a fix for up to 5 business days from the date of a report. While it is generally undesirable to keep a fix private after it has been developed, this short window is intended to allow distributions to package the fix into their kernel builds and permits early inclusion of the security team in the case of a co-ordinated disclosure with other parties. Unfortunately, discussions with major Linux distributions and cloud providers has revealed that 5 business days is not sufficient to achieve either of these two goals. As an example, cloud providers need to roll out KVM security fixes to a global fleet of hosts with sufficient early ramp-up and monitoring. An end-to-end timeline of less than two weeks dramatically cuts into the amount of early validation and increases the chance of guest-visible regressions. The consequence of this timeline mismatch is that security issues are commonly fixed without the involvement of the Linux kernel security team and are instead analysed and addressed by an ad-hoc group of developers across companies contributing to Linux. In some cases, mainline (and therefore the official stable kernels) can be left to languish for extended periods of time. This undermines the Linux kernel security process and puts upstream developers in a difficult position should they find themselves involved with an undisclosed security problem that they are unable to report due to restrictions from their employer. To accommodate the needs of these users of the Linux kernel and encourage them to engage with the Linux security team when security issues are first uncovered, extend the maximum period for which fixes may be delayed to 7 calendar days, or 14 calendar days in exceptional cases, where the logistics of QA and large scale rollouts specifically need to be accommodated. This brings parity with the linux-distros@ maximum embargo period of 14 calendar days. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Amit Shah <aams@amazon.com> Cc: Laura Abbott <labbott@redhat.com> Acked-by:
Kees Cook <keescook@chromium.org> Co-developed-by:
Thomas Gleixner <tglx@linutronix.de> Co-developed-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
Will Deacon <will.deacon@arm.com> Reviewed-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Will Deacon authored
commit 14fdc2c5 upstream. The Linux kernel security team has been accused of rejecting the idea of security embargoes. This is incorrect, and could dissuade people from reporting security issues to us under the false assumption that the issue would leak prematurely. Clarify the handling of embargoed information in our process documentation. Co-developed-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit cb5d2194 upstream. Sasha has somehow been convinced into helping me with the stable kernel maintenance. Codify this slip in good judgement before he realizes what he really signed up for :) Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
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:
-
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 6 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:
-
