summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2019-05-16qede: fix write to free'd pointer error and double free of ptpColin Ian King1-4/+3
[ Upstream commit 1dc2b3d65523780ed1972d446c76e62e13f3e8f5 ] The err2 error return path calls qede_ptp_disable that cleans up on an error and frees ptp. After this, the free'd ptp is dereferenced when ptp->clock is set to NULL and the code falls-through to error path err1 that frees ptp again. Fix this by calling qede_ptp_disable and exiting via an error return path that does not set ptp->clock or kfree ptp. Addresses-Coverity: ("Write to pointer after free") Fixes: 035744975aec ("qede: Add support for PTP resource locking.") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16vxge: fix return of a free'd memblock on a failed dma mappingColin Ian King1-0/+1
[ Upstream commit 0a2c34f18c94b596562bf3d019fceab998b8b584 ] Currently if a pci dma mapping failure is detected a free'd memblock address is returned rather than a NULL (that indicates an error). Fix this by ensuring NULL is returned on this error case. Addresses-Coverity: ("Use after free") Fixes: 528f727279ae ("vxge: code cleanup and reorganization") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16mISDN: Check address length before reading address familyTetsuo Handa1-2/+2
[ Upstream commit 238ffdc49ef98b15819cfd5e3fb23194e3ea3d39 ] KMSAN will complain if valid address length passed to bind() is shorter than sizeof("struct sockaddr_mISDN"->family) bytes. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16drm/amdgpu: shadow in shadow_list without tbo.mem.start cause page fault in ↵wentalou1-0/+1
sriov TDR [ Upstream commit b575f10dbd6f84c2c8744ff1f486bfae1e4f6f38 ] shadow was added into shadow_list by amdgpu_bo_create_shadow. meanwhile, shadow->tbo.mem was not fully configured. tbo.mem would be fully configured by amdgpu_vm_sdma_map_table until calling amdgpu_vm_clear_bo. If sriov TDR occurred between amdgpu_bo_create_shadow and amdgpu_vm_sdma_map_table, amdgpu_device_recover_vram would deal with shadow without tbo.mem.start. Signed-off-by: Wentao Lou <Wentao.Lou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16clocksource/drivers/oxnas: Fix OX820 compatibleNeil Armstrong1-1/+1
[ Upstream commit fbc87aa0f7c429999dc31f1bac3b2615008cac32 ] The OX820 compatible is wrong is the driver, fix it. Fixes: 2ea3401e2a84 ("clocksource/drivers/oxnas: Add OX820 compatible") Reported-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16clocksource/drivers/npcm: select TIMER_OFArnd Bergmann1-0/+1
[ Upstream commit 99834eead2a04e93a120abb112542b87c42ff5e1 ] When this is disabled, we get a link failure: drivers/clocksource/timer-npcm7xx.o: In function `npcm7xx_timer_init': timer-npcm7xx.c:(.init.text+0xf): undefined reference to `timer_of_init' Fixes: 1c00289ecd12 ("clocksource/drivers/npcm: Add NPCM7xx timer driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16drm/amd/display: extending AUX SW TimeoutMartin Leung2-6/+9
[ Upstream commit f4bbebf8e7eb4d294b040ab2d2ba71e70e69b930 ] [Why] AUX takes longer to reply when using active DP-DVI dongle on some asics resulting in up to 2000+ us edid read (timeout). [How] 1. Adjust AUX poll to match spec 2. Extend the SW timeout. This does not affect normal operation since we exit the loop as soon as AUX acks. Signed-off-by: Martin Leung <martin.leung@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Joshua Aberback <Joshua.Aberback@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16drm/ttm: fix dma_fence refcount imbalance on error pathLin Yi1-1/+3
[ Upstream commit 543c364d8eeeb42c0edfaac9764f4e9f3d777ec1 ] the ttm_bo_add_move_fence takes a reference to the struct dma_fence, but failed to release it on the error path, leading to a memory leak. add dma_fence_put before return when error occur. Signed-off-by: Lin Yi <teroincn@163.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16s390/3270: fix lockdep false positive on view->lockMartin Schwidefsky5-5/+10
[ Upstream commit 5712f3301a12c0c3de9cc423484496b0464f2faf ] The spinlock in the raw3270_view structure is used by con3270, tty3270 and fs3270 in different ways. For con3270 the lock can be acquired in irq context, for tty3270 and fs3270 the highest context is bh. Lockdep sees the view->lock as a single class and if the 3270 driver is used for the console the following message is generated: WARNING: inconsistent lock state 5.1.0-rc3-05157-g5c168033979d #12 Not tainted -------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. swapper/0/1 [HC0[0]:SC1[1]:HE1:SE0] takes: (____ptrval____) (&(&view->lock)->rlock){?.-.}, at: tty3270_update+0x7c/0x330 Introduce a lockdep subclass for the view lock to distinguish bh from irq locks. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16libnvdimm/pmem: fix a possible OOB access when read and write pmemLi RongQing1-4/+4
[ Upstream commit 9dc6488e84b0f64df17672271664752488cd6a25 ] If offset is not zero and length is bigger than PAGE_SIZE, this will cause to out of boundary access to a page memory Fixes: 98cc093cba1e ("block, THP: make block_device_operations.rw_page support THP") Co-developed-by: Liang ZhiCheng <liangzhicheng@baidu.com> Signed-off-by: Liang ZhiCheng <liangzhicheng@baidu.com> Signed-off-by: Li RongQing <lirongqing@baidu.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Jeff Moyer <jmoyer@redhat.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16libnvdimm/security: provide fix for secure-erase to use zero-keyDave Jiang1-5/+12
[ Upstream commit 037c8489ade669e0f09ad40d5b91e5e1159a14b1 ] Add a zero key in order to standardize hardware that want a key of 0's to be passed. Some platforms defaults to a zero-key with security enabled rather than allow the OS to enable the security. The zero key would allow us to manage those platform as well. This also adds a fix to secure erase so it can use the zero key to do crypto erase. Some other security commands already use zero keys. This introduces a standard zero-key to allow unification of semantics cross nvdimm security commands. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16s390/dasd: Fix capacity calculation for large volumesPeter Oberparleiter1-3/+3
[ Upstream commit 2cc9637ce825f3a9f51f8f78af7474e9e85bfa5f ] 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 5843492 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: Sasha Levin <sashal@kernel.org>
2019-05-16libnvdimm/btt: Fix a kmemdup failure checkAditya Pakki1-5/+13
[ Upstream commit 486fa92df4707b5df58d6508728bdb9321a59766 ] 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: Sasha Levin <sashal@kernel.org>
2019-05-16HID: input: add mapping for "Toggle Display" keyDmitry Torokhov1-0/+8
[ Upstream commit c01908a14bf735b871170092807c618bb9dae654 ] 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: Sasha Levin <sashal@kernel.org>
2019-05-16HID: input: add mapping for keyboard Brightness Up/Down/Toggle keysDmitry Torokhov1-0/+4
[ Upstream commit 7975a1d6a7afeb3eb61c971a153d24dd8fa032f3 ] 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 <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16HID: input: add mapping for Expose/Overview keyDmitry Torokhov1-0/+2
[ Upstream commit 96dd86871e1fffbc39e4fa61c9c75ec54ee9af0f ] 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: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16libnvdimm/namespace: Fix a potential NULL pointer dereferenceKangjie Lu1-1/+4
[ Upstream commit 55c1fc0af29a6c1b92f217b7eb7581a882e0c07c ] 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 <dan.j.williams@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16acpi/nfit: Always dump _DSM output payloadDan Williams1-6/+6
[ Upstream commit 351f339faa308c1c1461314a18c832239a841ca0 ] 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: 31eca76ba2fc9 ("...whitelisted dimm command marshaling mechanism") Reported-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16iio: adc: xilinx: prevent touching unclocked h/w on removeSven Van Asbroeck1-1/+1
[ Upstream commit 2e4b88f73966adead360e47621df0183586fac32 ] 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: Sasha Levin <sashal@kernel.org>
2019-05-16iio: adc: xilinx: fix potential use-after-free on probeSven Van Asbroeck1-0/+1
[ Upstream commit 862e4644fd2d7df8998edc65e0963ea2f567bde9 ] 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 <TheSven73@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16iio: adc: xilinx: fix potential use-after-free on removeSven Van Asbroeck1-1/+1
[ Upstream commit 62039b6aef63380ba7a37c113bbaeee8a55c5342 ] 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: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16USB: serial: fix unthrottle racesJohan Hovold1-7/+32
commit 3f5edd58d040bfa4b74fb89bc02f0bc6b9cd06ab 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: d83b405383c9 ("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>
2019-05-16virt: vbox: Sanity-check parameter types for hgcm-calls coming from userspaceHans de Goede1-0/+31
commit cf4f2ad6b87dda2dbe0573b1ebeb0273f8d4aac6 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-16hwmon: (occ) Fix extended status bitsLei YU1-4/+4
commit b88c5049219a7f322bb1fd65fc30d17472a23563 upstream. The occ's extended status is checked and shown as sysfs attributes. But the code was incorrectly checking the "status" bits. Fix it by checking the "ext_status" bits. Cc: stable@vger.kernel.org Fixes: df04ced684d4 ("hwmon (occ): Add sysfs attributes for additional OCC data") Signed-off-by: Lei YU <mine260309@gmail.com> Reviewed-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-16hwmon: (pwm-fan) Disable PWM if fetching cooling data failsStefan Wahren1-1/+1
commit 53f1647da3e8fb3e89066798f0fdc045064d353d upstream. In case pwm_fan_of_get_cooling_data() fails we should disable the PWM just like in the other error cases. Fixes: 2e5219c77183 ("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: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-16platform/x86: dell-laptop: fix rfkill functionalityMario Limonciello1-3/+3
commit 6cc13c28da5beee0f706db6450e190709700b34a upstream. When converting the driver two arguments were transposed leading to rfkill not working. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201427 Reported-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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-16platform/x86: thinkpad_acpi: Disable Bluetooth for some machinesJiaxun Yang1-2/+70
commit f7db839fccf087664e5587966220821289b6a9cb 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-16platform/x86: sony-laptop: Fix unintentional fall-throughGustavo A. R. Silva1-3/+5
commit 1cbd7a64959d33e7a2a1fa2bf36a62b350a9fcbd 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: 33a04454527e ("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: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-14x86/speculation/mds: Add sysfs reporting for MDSThomas Gleixner1-0/+8
commit 8a4b06d391b0a42a373808979b5028f5c84d9c6a 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 <tglx@linutronix.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Borislav Petkov <bp@suse.de> Reviewed-by: Jon Masters <jcm@redhat.com> Tested-by: Jon Masters <jcm@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10i3c: Fix a shift wrap bug in i3c_bus_set_addr_slot_status()Dan Carpenter1-2/+3
commit 476c7e1d34f2a03b1aa5a924c50703053fe5f77c upstream. The problem here is that addr can be I3C_BROADCAST_ADDR (126). That means we're shifting by (126 * 2) % 64 which is 60. The I3C_ADDR_SLOT_STATUS_MASK is an enum which is an unsigned int in GCC so shifts greater than 31 are undefined. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: <stable@vger.kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10UAS: fix alignment of scatter/gather segmentsOliver Neukum1-13/+22
commit 3ae62a42090f1ed48e2313ed256a1182a85fb575 upstream. This is the UAS version of 747668dbc061b3e62bc1982767a3a1f9815fcf0e usb-storage: Set virt_boundary_mask to avoid SG overflows We are not as likely to be vulnerable as storage, as it is unlikelier that UAS is run over a controller without native support for SG, but the issue exists. The issue has been existing since the inception of the driver. Fixes: 115bb1ffa54c ("USB: Add UAS driver") Signed-off-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10Bluetooth: hci_bcm: Fix empty regulator supplies for Intel MacsChen-Yu Tsai1-4/+16
commit 62611abc8f37d00e3b0cff0eb2d72fa92b05fd27 upstream. The code path for Macs goes through bcm_apple_get_resources(), which skips over the code that sets up the regulator supplies. As a result, the call to regulator_bulk_enable() / regulator_bulk_disable() results in a NULL pointer dereference. This was reported on the kernel.org Bugzilla, bug 202963. Unbreak Broadcom Bluetooth support on Intel Macs by checking if the supplies were set up before enabling or disabling them. The same does not need to be done for the clocks, as the common clock framework API checks for NULL pointers. Fixes: 75d11676dccb ("Bluetooth: hci_bcm: Add support for regulator supplies") Cc: <stable@vger.kernel.org> # 5.0.x Signed-off-by: Chen-Yu Tsai <wens@csie.org> Tested-by: Imre Kaloz <kaloz@openwrt.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10scsi: qla2xxx: Fix device staying in blocked stateQuinn Tran1-2/+2
commit 2137490f2147a8d0799b72b9a1023efb012d40c7 upstream. This patch fixes issue reported by some of the customers, who discovered that after cable pull scenario the devices disappear and path seems to remain in blocked state. Once the device reappears, driver does not seem to update path to online. This issue appears because of the defer flag creating race condition where the same session reappears. This patch fixes this issue by indicating SCSI-ML of device lost when qlt_free_session_done() is called from qlt_unreg_sess(). Fixes: 41dc529a4602a ("qla2xxx: Improve RSCN handling in driver") Signed-off-by: Quinn Tran <qtran@marvell.com> Cc: stable@vger.kernel.org #4.19 Signed-off-by: Himanshu Madhani <hmadhani@marvell.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10scsi: qla2xxx: Fix incorrect region-size setting in optrom SYSFS routinesAndrew Vasquez1-2/+2
commit 5cbdae10bf11f96e30b4d14de7b08c8b490e903c upstream. Commit e6f77540c067 ("scsi: qla2xxx: Fix an integer overflow in sysfs code") incorrectly set 'optrom_region_size' to 'start+size', which can overflow option-rom boundaries when 'start' is non-zero. Continue setting optrom_region_size to the proper adjusted value of 'size'. Fixes: e6f77540c067 ("scsi: qla2xxx: Fix an integer overflow in sysfs code") Cc: stable@vger.kernel.org Signed-off-by: Andrew Vasquez <andrewv@marvell.com> Signed-off-by: Himanshu Madhani <hmadhani@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10scsi: lpfc: change snprintf to scnprintf for possible overflowSilvio Cesare4-329/+336
commit e7f7b6f38a44697428f5a2e7c606de028df2b0e3 upstream. Change snprintf to scnprintf. There are generally two cases where using snprintf causes problems. 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...) In this case, if snprintf would have written more characters than what the buffer size (SIZE) is, then size will end up larger than SIZE. In later uses of snprintf, SIZE - size will result in a negative number, leading to problems. Note that size might already be too large by using size = snprintf before the code reaches a case of size += snprintf. 2) If size is ultimately used as a length parameter for a copy back to user space, then it will potentially allow for a buffer overflow and information disclosure when size is greater than SIZE. When the size is used to index the buffer directly, we can have memory corruption. This also means when size = snprintf... is used, it may also cause problems since size may become large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel configuration. The solution to these issues is to use scnprintf which returns the number of characters actually written to the buffer, so the size variable will never exceed SIZE. Signed-off-by: Silvio Cesare <silvio.cesare@gmail.com> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: James Smart <james.smart@broadcom.com> Cc: Dick Kennedy <dick.kennedy@broadcom.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Kees Cook <keescook@chromium.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10soc: sunxi: Fix missing dependency on REGMAP_MMIOSamuel Holland2-1/+2
commit a84014e1db35d8e7af09878d0b4bf30804fb17d5 upstream. When enabling ARCH_SUNXI from allnoconfig, SUNXI_SRAM is enabled, but not REGMAP_MMIO, so the kernel fails to link with an undefined reference to __devm_regmap_init_mmio_clk. Select REGMAP_MMIO, as suggested in drivers/base/regmap/Kconfig. This creates the following dependency loop: drivers/of/Kconfig:68: symbol OF_IRQ depends on IRQ_DOMAIN kernel/irq/Kconfig:63: symbol IRQ_DOMAIN is selected by REGMAP drivers/base/regmap/Kconfig:7: symbol REGMAP default is visible depending on REGMAP_MMIO drivers/base/regmap/Kconfig:39: symbol REGMAP_MMIO is selected by SUNXI_SRAM drivers/soc/sunxi/Kconfig:4: symbol SUNXI_SRAM is selected by USB_MUSB_SUNXI drivers/usb/musb/Kconfig:63: symbol USB_MUSB_SUNXI depends on GENERIC_PHY drivers/phy/Kconfig:7: symbol GENERIC_PHY is selected by PHY_BCM_NS_USB3 drivers/phy/broadcom/Kconfig:29: symbol PHY_BCM_NS_USB3 depends on MDIO_BUS drivers/net/phy/Kconfig:12: symbol MDIO_BUS default is visible depending on PHYLIB drivers/net/phy/Kconfig:181: symbol PHYLIB is selected by ARC_EMAC_CORE drivers/net/ethernet/arc/Kconfig:18: symbol ARC_EMAC_CORE is selected by ARC_EMAC drivers/net/ethernet/arc/Kconfig:24: symbol ARC_EMAC depends on OF_IRQ To fix the circular dependency, make USB_MUSB_SUNXI select GENERIC_PHY instead of depending on it. This matches the use of GENERIC_PHY by all but two other drivers. Cc: <stable@vger.kernel.org> # 4.19 Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock reg on A64") Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10ACPI / LPSS: Use acpi_lpss_* instead of acpi_subsys_* functions for hibernateHans de Goede1-2/+2
commit c8afd03486c26accdda4846e5561aa3f8e862a9d upstream. Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early on BYT/CHT as resume_from_noirq is set. This means that on resume from hibernate dw_i2c_plat_resume() doesn't get called by the restore_early callback, acpi_lpss_resume_early(). Instead it should be called by the restore_noirq callback matching how things are done when resume_from_noirq is set and we are doing a regular resume. Change the restore_noirq callback to acpi_lpss_resume_noirq so that dw_i2c_plat_resume() gets properly called when resume_from_noirq is set and we are resuming from hibernate. Likewise also change the poweroff_noirq callback so that dw_i2c_plat_suspend gets called properly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202139 Fixes: 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq") Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: 4.20+ <stable@vger.kernel.org> # 4.20+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10cpufreq: armada-37xx: fix frequency calculation for oppGregory CLEMENT1-3/+19
commit 8db82563451f976597ab7b282ec655e4390a4088 upstream. The frequency calculation was based on the current(max) frequency of the CPU. However for low frequency, the value used was already the parent frequency divided by a factor of 2. Instead of using this frequency, this fix directly get the frequency from the parent clock. Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") Cc: <stable@vger.kernel.org> Reported-by: Christian Neubert <christian.neubert.86@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10iio: adc: qcom-spmi-adc5: Fix of-based module autoloadingBjorn Andersson1-0/+1
commit 447ccb4e0834a9f9f0dd5643e421c7f1a1649e6a upstream. The of_device_id table needs to be registered as module alias in order for automatic module loading to pick the kernel module based on the DeviceTree compatible. So add MODULE_DEVICE_TABLE() to make this happen. Fixes: e13d757279bb ("iio: adc: Add QCOM SPMI PMIC5 ADC driver") Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10intel_th: pci: Add Comet Lake supportAlexander Shishkin1-0/+5
commit e60e9a4b231a20a199d7a61caadc48693c30d695 upstream. This adds support for Intel TH on Comet Lake. Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10usb-storage: Set virt_boundary_mask to avoid SG overflowsAlan Stern1-14/+12
commit 747668dbc061b3e62bc1982767a3a1f9815fcf0e upstream. The USB subsystem has always had an unusual requirement for its scatter-gather transfers: Each element in the scatterlist (except the last one) must have a length divisible by the bulk maxpacket size. This is a particular issue for USB mass storage, which uses SG lists created by the block layer rather than setting up its own. So far we have scraped by okay because most devices have a logical block size of 512 bytes or larger, and the bulk maxpacket sizes for USB 2 and below are all <= 512. However, USB 3 has a bulk maxpacket size of 1024. Since the xhci-hcd driver includes native SG support, this hasn't mattered much. But now people are trying to use USB-3 mass storage devices with USBIP, and the vhci-hcd driver currently does not have full SG support. The result is an overflow error, when the driver attempts to implement an SG transfer of 63 512-byte blocks as a single 3584-byte (7 blocks) transfer followed by seven 4096-byte (8 blocks) transfers. The device instead sends 31 1024-byte packets followed by a 512-byte packet, and this overruns the first SG buffer. Ideally this would be fixed by adding better SG support to vhci-hcd. But for now it appears we can work around the problem by asking the block layer to respect the maxpacket limitation, through the use of the virt_boundary_mask. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Seth Bollinger <Seth.Bollinger@digi.com> Tested-by: Seth Bollinger <Seth.Bollinger@digi.com> CC: Ming Lei <tom.leiming@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10USB: cdc-acm: fix unthrottle racesJohan Hovold1-7/+25
commit 764478f41130f1b8d8057575b89e69980a0f600d 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. Also note that the first race was fixed by 36e59e0d70d6 ("cdc-acm: fix race between callback and unthrottle") back in 2015, but the bug was reintroduced a year later. Fixes: 1aba579f3cf5 ("cdc-acm: handle read pipe errors") Fixes: 088c64f81284 ("USB: cdc-acm: re-write read processing") Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10USB: serial: f81232: fix interrupt worker not stopJi-Ze Hong (Peter Hong)1-0/+39
commit 804dbee1e49774918339c1e5a87400988c0819e8 upstream. The F81232 will use interrupt worker to handle MSR change. This patch will fix the issue that interrupt work should stop in close() and suspend(). This also fixes line-status events being disabled after a suspend cycle until the port is re-opened. Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com> [ johan: amend commit message ] Fixes: 87fe5adcd8de ("USB: f81232: implement read IIR/MSR with endpoint") Cc: stable <stable@vger.kernel.org> # 4.1 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10usb: dwc3: Fix default lpm_nyet_threshold valueThinh Nguyen1-1/+1
commit 8d791929b2fbdf7734c1596d808e55cb457f4562 upstream. The max possible value for DCTL.LPM_NYET_THRES is 15 and not 255. Change the default value to 15. Cc: stable@vger.kernel.org Fixes: 80caf7d21adc ("usb: dwc3: add lpm erratum support") Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10usb: dwc3: Allow building USB_DWC3_QCOM without EXTCONMarc Gonzalez1-2/+4
commit 77a4946516fe488b6a33390de6d749f934a243ba upstream. Keep EXTCON support optional, as some platforms do not need it. Do the same for USB_DWC3_OMAP while we're at it. Fixes: 3def4031b3e3f ("usb: dwc3: add EXTCON dependency for qcom") Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10iommu/amd: Set exclusion range correctlyJoerg Roedel1-1/+1
[ Upstream commit 3c677d206210f53a4be972211066c0f1cd47fe12 ] The exlcusion range limit register needs to contain the base-address of the last page that is part of the range, as bits 0-11 of this register are treated as 0xfff by the hardware for comparisons. So correctly set the exclusion range in the hardware to the last page which is _in_ the range. Fixes: b2026aa2dce44 ('x86, AMD IOMMU: add functions for programming IOMMU MMIO space') Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-10platform/x86: pmc_atom: Drop __initconst on dmi tableStephen Boyd1-1/+1
[ Upstream commit b995dcca7cf12f208cfd95fd9d5768dca7cccec7 ] It's used by probe and that isn't an init function. Drop this so that we don't get a section mismatch. Reported-by: kbuild test robot <lkp@intel.com> Cc: David Müller <dave.mueller@gmx.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Fixes: 7c2e07130090 ("clk: x86: Add system specific quirk to mark clocks as critical") Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-10nvmet: fix discover log page when offsets are usedKeith Busch3-23/+51
[ Upstream commit d808b7f759b50acf0784ce6230ffa63e12ef465d ] The nvme target hadn't been taking the Get Log Page offset parameter into consideration, and so has been returning corrupted log pages when offsets are used. Since many tools, including nvme-cli, split the log request to 4k, we've been breaking discovery log responses when more than 3 subsystems exist. Fix the returned data by internally generating the entire discovery log page and copying only the requested bytes into the user buffer. The command log page offset type has been modified to a native __le64 to make it easier to extract the value from a command. Signed-off-by: Keith Busch <keith.busch@intel.com> Tested-by: Minwoo Im <minwoo.im@samsung.com> Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: James Smart <james.smart@broadcom.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-10nvme-fc: correct csn initialization and increments on errorJames Smart1-5/+15
[ Upstream commit 67f471b6ed3b09033c4ac77ea03f92afdb1989fe ] This patch fixes a long-standing bug that initialized the FC-NVME cmnd iu CSN value to 1. Early FC-NVME specs had the connection starting with CSN=1. By the time the spec reached approval, the language had changed to state a connection should start with CSN=0. This patch corrects the initialization value for FC-NVME connections. Additionally, in reviewing the transport, the CSN value is assigned to the new IU early in the start routine. It's possible that a later dma map request may fail, causing the command to never be sent to the controller. Change the location of the assignment so that it is immediately prior to calling the lldd. Add a comment block to explain the impacts if the lldd were to additionally fail sending the command. Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-10nvme: cancel request synchronouslyMing Lei1-1/+1
[ Upstream commit eb3afb75b57c28599af0dfa03a99579d410749e9 ] nvme_cancel_request() is used in error handler, and it is always reliable to cancel request synchronously, and avoids possible race in which request may be completed after real hw queue is destroyed. One issue is reported by our customer on NVMe RDMA, in which freed ib queue pair may be used in nvme_rdma_complete_rq(). Cc: Sagi Grimberg <sagi@grimberg.me> Cc: Bart Van Assche <bvanassche@acm.org> Cc: James Smart <james.smart@broadcom.com> Cc: linux-nvme@lists.infradead.org Reviewed-by: Keith Busch <keith.busch@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>