- 01 Jul, 2019 40 commits
-
-
Arend van Spriel authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit a4176ec3 upstream. For USB there is no separate channel being used to pass events from firmware to the host driver and as such are passed over the data path. In order to detect mock event messages an additional check is needed on event subtype. This check is added conditionally using unlikely() keyword. Reviewed-by:
Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> [bwh: Backported to 4.4: adjust filenames] Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Arend Van Spriel authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 4835f37e upstream. Assure the event data buffer is long enough to hold the array of netinfo items and that SSID length does not exceed the maximum of 32 characters as per 802.11 spec. Reviewed-by:
-
Gavin Li authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 8e290cec upstream. brcmf_sdio_fromevntchan() was being called on the the data frame rather than the software header, causing some frames to be mischaracterized as on the event channel rather than the data channel. This fixes a major performance regression (due to dropped packets). With this patch the download speed jumped from 1Mbit/s back up to 40MBit/s due to the sheer amount of packets being incorrectly processed. Fixes: c56caa9d ("brcmfmac: screening firmware event packet") Signed-off-by:
Gavin Li <git@thegavinli.com> Acked-by:
-
Arend van Spriel authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 9c349892 upstream. Move event handling out of brcmf_netif_rx() avoiding the need to pass a flag. This flag is only ever true for USB hosts as other interface use separate brcmf_rx_event() function. Reviewed-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Franky Lin authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit c56caa9d upstream. Firmware uses asynchronized events as a communication method to the host. The event packets are marked as ETH_P_LINK_CTL protocol type. For SDIO and PCIe bus, this kind of packets are delivered through virtual event channel not data channel. This patch adds a screening logic to make sure the event handler only processes the events coming from the correct channel. Reviewed-by:
-
Hante Meuleman authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 0aedbcaf upstream. Add additional length checks on firmware events to create more robust code. Reviewed-by:
Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Lei Zhang <leizh@broadcom.com> Signed-off-by:
Hante Meuleman <meuleman@broadcom.com> Signed-off-by:
-
Todd Kjos authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 8ca86f16 upstream. The format specifier "%p" can leak kernel addresses. Use "%pK" instead. There were 4 remaining cases in binder.c. Signed-off-by:
Todd Kjos <tkjos@google.com> Signed-off-by:
-
Ben Hutchings authored
BugLink: https://bugs.launchpad.net/bugs/1832661 This was done as part of upstream commits fdfb4a99 "8inder: separate binder allocator structure from binder proc", 19c98724 "binder: separate out binder_alloc functions", and 7a4408c6 "binder: make sure accesses to proc/thread are safe". However, those commits made lots of other changes that are not suitable for stable. Signed-off-by:
-
Roberto Bergantinos Corpas authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 31fad7d4 upstream. In cifs_read_allocate_pages, in case of ENOMEM, we go through whole rdata->pages array but we have failed the allocation before nr_pages, therefore we may end up calling put_page with NULL pointer, causing oops Signed-off-by:
Roberto Bergantinos Corpas <rbergant@redhat.com> Acked-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
-
Zhenliang Wei authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 98af37d6 upstream. In the fixes commit, removing SIGKILL from each thread signal mask and executing "goto fatal" directly will skip the call to "trace_signal_deliver". At this point, the delivery tracking of the SIGKILL signal will be inaccurate. Therefore, we need to add trace_signal_deliver before "goto fatal" after executing sigdelset. Note: SEND_SIG_NOINFO matches the fact that SIGKILL doesn't have any info. Link: http://lkml.kernel.org/r/20190425025812.91424-1-weizhenliang@huawei.com Fixes: cf43a757 ("signal: Restore the stop PTRACE_EVENT_EXIT") Signed-off-by:
Zhenliang Wei <weizhenliang@huawei.com> Reviewed-by:
Christian Brauner <christian@brauner.io> Reviewed-by:
Oleg Nesterov <oleg@redhat.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Ivan Delalande <colona@arista.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Deepa Dinamani <deepa.kernel@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jiri Slaby authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 3e858996 upstream. We have a single node system with node 0 disabled: Scanning NUMA topology in Northbridge 24 Number of physical nodes 2 Skipping disabled node 0 Node 1 MemBase 0000000000000000 Limit 00000000fbff0000 NODE_DATA(1) allocated [mem 0xfbfda000-0xfbfeffff] This causes crashes in memcg when system boots: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 #PF error: [normal kernel read fault] ... RIP: 0010:list_lru_add+0x94/0x170 ... Call Trace: d_lru_add+0x44/0x50 dput.part.34+0xfc/0x110 __fput+0x108/0x230 task_work_run+0x9f/0xc0 exit_to_usermode_loop+0xf5/0x100 It is reproducible as far as 4.12. I did not try older kernels. You have to have a new enough systemd, e.g. 241 (the reason is unknown -- was not investigated). Cannot be reproduced with systemd 234. The system crashes because the size of lru array is never updated in memcg_update_all_list_lrus and the reads are past the zero-sized array, causing dereferences of random memory. The root cause are list_lru_memcg_aware checks in the list_lru code. The test in list_lru_memcg_aware is broken: it assumes node 0 is always present, but it is not true on some systems as can be seen above. So fix this by avoiding checks on node 0. Remember the memcg-awareness by a bool flag in struct list_lru. Link: http://lkml.kernel.org/r/20190522091940.3615-1-jslaby@suse.cz Fixes: 60d3fd32 ("list_lru: introduce per-memcg lists") Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Acked-by:
Michal Hocko <mhocko@suse.com> Suggested-by:
Vladimir Davydov <vdavydov.dev@gmail.com> Acked-by:
Shakeel Butt <shakeelb@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Joe Burmeister authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 5d24f455 upstream. The datasheet states: Bit 4: ClockEnSet the ClockEn bit high to enable an external clocking (crystal or clock generator at XIN). Set the ClockEn bit to 0 to disable clocking Bit 1: CrystalEnSet the CrystalEn bit high to enable the crystal oscillator. When using an external clock source at XIN, CrystalEn must be set low. The bit 4, MAX310X_CLKSRC_EXTCLK_BIT, should be set and was not. This was required to make the MAX3107 with an external crystal on our board able to send or receive data. Signed-off-by:
Joe Burmeister <joe.burmeister@devtank.co.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Jorge Ramirez-Ortiz authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 61c0e379 upstream. When the tty layer requests the uart to throttle, the current code executing in msm_serial will trigger "Bad mode in Error Handler" and generate an invalid stack frame in pstore before rebooting (that is if pstore is indeed configured: otherwise the user shall just notice a reboot with no further information dumped to the console). This patch replaces the PIO byte accessor with the word accessor already used in PIO mode. Fixes: 68252424 ("tty: serial: msm: Support big-endian CPUs") Cc: stable@vger.kernel.org Signed-off-by:
Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
Lyude Paul authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 342406e4 upstream. For a while, we've had the problem of i2c bus access not grabbing a runtime PM ref when it's being used in userspace by i2c-dev, resulting in nouveau spamming the kernel log with errors if anything attempts to access the i2c bus while the GPU is in runtime suspend. An example: [ 130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff Since the GPU is in runtime suspend, the MMIO region that the i2c bus is on isn't accessible. On x86, the standard behavior for accessing an unavailable MMIO region is to just return ~0. Except, that turned out to be a lie. While computers with a clean concious will return ~0 in this scenario, some machines will actually completely hang a CPU on certian bad MMIO accesses. This was witnessed with someone's Lenovo ThinkPad P50, where sensors-detect attempting to access the i2c bus while the GPU was suspended would result in a CPU hang: CPU: 5 PID: 12438 Comm: sensors-detect Not tainted 5.0.0-0.rc4.git3.1.fc30.x86_64 #1 Hardware name: LENOVO 20EQS64N17/20EQS64N17, BIOS N1EET74W (1.47 ) 11/21/2017 RIP: 0010:ioread32+0x2b/0x30 Code: 81 ff ff ff 03 00 77 20 48 81 ff 00 00 01 00 76 05 0f b7 d7 ed c3 48 c7 c6 e1 0c 36 96 e8 2d ff ff ff b8 ff ff ff ff c3 8b 07 <c3> 0f 1f 40 00 49 89 f0 48 81 fe ff ff 03 00 76 04 40 88 3e c3 48 RSP: 0018:ffffaac3c5007b48 EFLAGS: 00000292 ORIG_RAX: ffffffffffffff13 RAX: 0000000001111000 RBX: 0000000001111000 RCX: 0000043017a97186 RDX: 0000000000000aaa RSI: 0000000000000005 RDI: ffffaac3c400e4e4 RBP: ffff9e6443902c00 R08: ffffaac3c400e4e4 R09: ffffaac3c5007be7 R10: 0000000000000004 R11: 0000000000000001 R12: ffff9e6445dd0000 R13: 000000000000e4e4 R14: 00000000000003c4 R15: 0000000000000000 FS: 00007f253155a740(0000) GS:ffff9e644f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005630d1500358 CR3: 0000000417c44006 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: g94_i2c_aux_xfer+0x326/0x850 [nouveau] nvkm_i2c_aux_i2c_xfer+0x9e/0x140 [nouveau] __i2c_transfer+0x14b/0x620 i2c_smbus_xfer_emulated+0x159/0x680 ? _raw_spin_unlock_irqrestore+0x1/0x60 ? rt_mutex_slowlock.constprop.0+0x13d/0x1e0 ? __lock_is_held+0x59/0xa0 __i2c_smbus_xfer+0x138/0x5a0 i2c_smbus_xfer+0x4f/0x80 i2cdev_ioctl_smbus+0x162/0x2d0 [i2c_dev] i2cdev_ioctl+0x1db/0x2c0 [i2c_dev] do_vfs_ioctl+0x408/0x750 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x60/0x1e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f25317f546b Code: 0f 1e fa 48 8b 05 1d da 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed d9 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffc88caab68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00005630d0fe7260 RCX: 00007f25317f546b RDX: 00005630d1598e80 RSI: 0000000000000720 RDI: 0000000000000003 RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0 R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80 R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0 watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438] Yikes! While I wanted to try to make it so that accessing an i2c bus on nouveau would wake up the GPU as needed, airlied pointed out that pretty much any usecase for userspace accessing an i2c bus on a GPU (mainly for the DDC brightness control that some displays have) is going to only be useful while there's at least one display enabled on the GPU anyway, and the GPU never sleeps while there's displays running. Since teaching the i2c bus to wake up the GPU on userspace accesses is a good deal more difficult than it might seem, mostly due to the fact that we have to use the i2c bus during runtime resume of the GPU, we instead opt for the easiest solution: don't let userspace access i2c busses on the GPU at all while it's in runtime suspend. Changes since v1: * Also disable i2c busses that run over DP AUX Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Kailang Yang authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 317d9313 upstream. I measured power consumption between power_save_node=1 and power_save_node=0. It's almost the same. Codec will enter to runtime suspend and suspend. That pin also will enter to D3. Don't need to enter to D3 by single pin. So, Disable power_save_node as default. It will avoid more issues. Windows Driver also has not this option at runtime PM. Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Filipe Manana authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 06989c79 upstream. When syncing the log, the final phase of a fsync operation, we need to either create a log root's item or update the existing item in the log tree of log roots, and that depends on the current value of the log root's log_transid - if it's 1 we need to create the log root item, otherwise it must exist already and we update it. Since there is no synchronization between updating the log_transid and checking it for deciding whether the log root's item needs to be created or updated, we end up with a tiny race window that results in attempts to update the item to fail because the item was not yet created: CPU 1 CPU 2 btrfs_sync_log() lock root->log_mutex set log root's log_transid to 1 unlock root->log_mutex btrfs_sync_log() lock root->log_mutex sets log root's log_transid to 2 unlock root->log_mutex update_log_root() sees log root's log_transid with a value of 2 calls btrfs_update_root(), which fails with -EUCLEAN and causes transaction abort Until recently the race lead to a BUG_ON at btrfs_update_root(), but after the recent commit 7ac1e464 ("btrfs: Don't panic when we can't find a root key") we just abort the current transaction. A sample trace of the BUG_ON() on a SLE12 kernel: ------------[ cut here ]------------ kernel BUG at ../fs/btrfs/root-tree.c:157! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=2048 NUMA pSeries (...) Supported: Yes, External CPU: 78 PID: 76303 Comm: rtas_errd Tainted: G X 4.4.156-94.57-default #1 task: c00000ffa906d010 ti: c00000ff42b08000 task.ti: c00000ff42b08000 NIP: d000000036ae5cdc LR: d000000036ae5cd8 CTR: 0000000000000000 REGS: c00000ff42b0b860 TRAP: 0700 Tainted: G X (4.4.156-94.57-default) MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 22444484 XER: 20000000 CFAR: d000000036aba66c SOFTE: 1 GPR00: d000000036ae5cd8 c00000ff42b0bae0 d000000036bda220 0000000000000054 GPR04: 0000000000000001 0000000000000000 c00007ffff8d37c8 0000000000000000 GPR08: c000000000e19c00 0000000000000000 0000000000000000 3736343438312079 GPR12: 3930373337303434 c000000007a3a800 00000000007fffff 0000000000000023 GPR16: c00000ffa9d26028 c00000ffa9d261f8 0000000000000010 c00000ffa9d2ab28 GPR20: c00000ff42b0bc48 0000000000000001 c00000ff9f0d9888 0000000000000001 GPR24: c00000ffa9d26000 c00000ffa9d261e8 c00000ffa9d2a800 c00000ff9f0d9888 GPR28: c00000ffa9d26028 c00000ffa9d2aa98 0000000000000001 c00000ffa98f5b20 NIP [d000000036ae5cdc] btrfs_update_root+0x25c/0x4e0 [btrfs] LR [d000000036ae5cd8] btrfs_update_root+0x258/0x4e0 [btrfs] Call Trace: [c00000ff42b0bae0] [d000000036ae5cd8] btrfs_update_root+0x258/0x4e0 [btrfs] (unreliable) [c00000ff42b0bba0] [d000000036b53610] btrfs_sync_log+0x2d0/0xc60 [btrfs] [c00000ff42b0bce0] [d000000036b1785c] btrfs_sync_file+0x44c/0x4e0 [btrfs] [c00000ff42b0bd80] [c00000000032e300] vfs_fsync_range+0x70/0x120 [c00000ff42b0bdd0] [c00000000032e44c] do_fsync+0x5c/0xb0 [c00000ff42b0be10] [c00000000032e8dc] SyS_fdatasync+0x2c/0x40 [c00000ff42b0be30] [c000000000009488] system_call+0x3c/0x100 Instruction dump: 7f43d378 4bffebb9 60000000 88d90008 3d220000 e8b90000 3b390009 e87a01f0 e8898e08 e8f90000 4bfd48e5 60000000 <0fe00000> e95b0060 39200004 394a0ea0 ---[ end trace 8f2dc8f919cabab8 ]--- So fix this by doing the check of log_transid and updating or creating the log root's item while holding the root's log_mutex. Fixes: 7237f183 ("Btrfs: fix tree logs parallel sync") CC: stable@vger.kernel.org # 4.4+ Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Steffen Maier authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit ef4021fe upstream. When the user tries to remove a zfcp port via sysfs, we only rejected it if there are zfcp unit children under the port. With purely automatically scanned LUNs there are no zfcp units but only SCSI devices. In such cases, the port_remove erroneously continued. We close the port and this implicitly closes all LUNs under the port. The SCSI devices survive with their private zfcp_scsi_dev still holding a reference to the "removed" zfcp_port (still allocated but invisible in sysfs) [zfcp_get_port_by_wwpn in zfcp_scsi_slave_alloc]. This is not a problem as long as the fc_rport stays blocked. Once (auto) port scan brings back the removed port, we unblock its fc_rport again by design. However, there is no mechanism that would recover (open) the LUNs under the port (no "ersfs_3" without zfcp_unit [zfcp_erp_strategy_followup_success]). Any pending or new I/O to such LUN leads to repeated: Done: NEEDS_RETRY Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK See also v4.10 commit 6f2ce1c6 ("scsi: zfcp: fix rport unblock race with LUN recovery"). Even a manual LUN recovery (echo 0 > /sys/bus/scsi/devices/H:C:T:L/zfcp_failed) does not help, as the LUN links to the old "removed" port which remains to lack ZFCP_STATUS_COMMON_RUNNING [zfcp_erp_required_act]. The only workaround is to first ensure that the fc_rport is blocked (e.g. port_remove again in case it was re-discovered by (auto) port scan), then delete the SCSI devices, and finally re-discover by (auto) port scan. The port scan includes an fc_rport unblock, which in turn triggers a new scan on the scsi target to freshly get new pure auto scan LUNs. Fix this by rejecting port_remove also if there are SCSI devices (even without any zfcp_unit) under this port. Re-use mechanics from v3.7 commit d99b601b ("[SCSI] zfcp: restore refcount check on port_remove"). However, we have to give up zfcp_sysfs_port_units_mutex earlier in unit_add to prevent a deadlock with scsi_host scan taking shost->scan_mutex first and then zfcp_sysfs_port_units_mutex now in our zfcp_scsi_slave_alloc(). Signed-off-by:
Steffen Maier <maier@linux.ibm.com> Fixes: b62a8d9b ("[SCSI] zfcp: Use SCSI device data zfcp scsi dev instead of zfcp unit") Fixes: f8210e34 ("[SCSI] zfcp: Allow midlayer to scan for LUNs when running in NPIV mode") Cc: <stable@vger.kernel.org> #2.6.37+ Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Steffen Maier authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit d27e5e07 upstream. With this early return due to zfcp_unit child(ren), we don't use the zfcp_port reference from the earlier zfcp_get_port_by_wwpn() anymore and need to put it. Signed-off-by:
Jens Remus <jremus@linux.ibm.com> Reviewed-by:
-
Mauro Carvalho Chehab authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit a4768663 upstream. Most Siano devices require an alignment for the response. Changeset f3be52b0056a ("media: usb: siano: Fix general protection fault in smsusb") changed the logic with gets such aligment, but it now produces a sparce warning: drivers/media/usb/siano/smsusb.c: In function 'smsusb_init_device': drivers/media/usb/siano/smsusb.c:447:37: warning: 'in_maxp' may be used uninitialized in this function [-Wmaybe-uninitialized] 447 | dev->response_alignment = in_maxp - sizeof(struct sms_msg_hdr); | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ The sparse message itself is bogus, but a broken (or fake) USB eeprom could produce a negative value for response_alignment. So, change the code in order to check if the result is not negative. Fixes: 31e0456d ("media: usb: siano: Fix general protection fault in smsusb") CC: <stable@vger.kernel.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 45457c01 upstream. GCC complains about an apparently uninitialized variable recently added to smsusb_init_device(). It's a false positive, but to silence the warning this patch adds a trivial initialization. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
kbuild test robot <lkp@intel.com> CC: <stable@vger.kernel.org> Signed-off-by:
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 31e0456d upstream. The syzkaller USB fuzzer found a general-protection-fault bug in the smsusb part of the Siano DVB driver. The fault occurs during probe because the driver assumes without checking that the device has both IN and OUT endpoints and the IN endpoint is ep1. By slightly rearranging the driver's initialization code, we can make the appropriate checks early on and thus avoid the problem. If the expected endpoints aren't present, the new code safely returns -ENODEV from the probe routine. Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Oliver Neukum authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit e0feb734 upstream. If a disconnected device is closed, rio_close() must free the buffers. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Oliver Neukum authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 3864d339 upstream. This driver is using a global variable. It cannot handle more than one device at a time. The issue has been existing since the dawn of the driver. Signed-off-by:
-
Maximilian Luz authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit ea261113 upstream. Without USB_QUIRK_NO_LPM ethernet will not work and rtl8152 will complain with r8152 <device...>: Stop submitting intr, status -71 Adding the quirk resolves this. As the dock is externally powered, this should not have any drawbacks. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Oliver Neukum authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 9a5729f6 upstream. The pointer used to log a failure of usb_register_dev() must be set before the error is logged. v2: fix that minor is not available before registration Signed-off-by:
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit a03ff544 upstream. The syzkaller USB fuzzer found a slab-out-of-bounds write bug in the USB core, caused by a failure to check the actual size of a BOS descriptor. This patch adds a check to make sure the descriptor is at least as large as it is supposed to be, so that the code doesn't inadvertently access memory beyond the end of the allocated region when assigning to dev->bos->desc->bNumDeviceCaps later on. Signed-off-by:
-
Carsten Schmid authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 7aa1bb2f upstream. With defective USB sticks we see the following error happen: usb 1-3: new high-speed USB device number 6 using xhci_hcd usb 1-3: device descriptor read/64, error -71 usb 1-3: device descriptor read/64, error -71 usb 1-3: new high-speed USB device number 7 using xhci_hcd usb 1-3: device descriptor read/64, error -71 usb 1-3: unable to get BOS descriptor set usb 1-3: New USB device found, idVendor=0781, idProduct=5581 usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 ... BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 This comes from the following place: [ 1660.215380] IP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd] [ 1660.222092] PGD 0 P4D 0 [ 1660.224918] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 1660.425520] CPU: 1 PID: 38 Comm: kworker/1:1 Tainted: P U W O 4.14.67-apl #1 [ 1660.434277] Workqueue: usb_hub_wq hub_event [usbcore] [ 1660.439918] task: ffffa295b6ae4c80 task.stack: ffffad4580150000 [ 1660.446532] RIP: 0010:xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd] [ 1660.453821] RSP: 0018:ffffad4580153c70 EFLAGS: 00010046 [ 1660.459655] RAX: 0000000000000000 RBX: ffffa295b4d7c000 RCX: 0000000000000002 [ 1660.467625] RDX: 0000000000000002 RSI: ffffffff984a55b2 RDI: ffffffff984a55b2 [ 1660.475586] RBP: ffffad4580153cc8 R08: 0000000000d6520a R09: 0000000000000001 [ 1660.483556] R10: ffffad4580a004a0 R11: 0000000000000286 R12: ffffa295b4d7c000 [ 1660.491525] R13: 0000000000010648 R14: ffffa295a84e1800 R15: 0000000000000000 [ 1660.499494] FS: 0000000000000000(0000) GS:ffffa295bfc80000(0000) knlGS:0000000000000000 [ 1660.508530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1660.514947] CR2: 0000000000000008 CR3: 000000025a114000 CR4: 00000000003406a0 [ 1660.522917] Call Trace: [ 1660.525657] usb_set_usb2_hardware_lpm+0x3d/0x70 [usbcore] [ 1660.531792] usb_disable_device+0x242/0x260 [usbcore] [ 1660.537439] usb_disconnect+0xc1/0x2b0 [usbcore] [ 1660.542600] hub_event+0x596/0x18f0 [usbcore] [ 1660.547467] ? trace_preempt_on+0xdf/0x100 [ 1660.552040] ? process_one_work+0x1c1/0x410 [ 1660.556708] process_one_work+0x1d2/0x410 [ 1660.561184] ? preempt_count_add.part.3+0x21/0x60 [ 1660.566436] worker_thread+0x2d/0x3f0 [ 1660.570522] kthread+0x122/0x140 [ 1660.574123] ? process_one_work+0x410/0x410 [ 1660.578792] ? kthread_create_on_node+0x60/0x60 [ 1660.583849] ret_from_fork+0x3a/0x50 [ 1660.587839] Code: 00 49 89 c3 49 8b 84 24 50 16 00 00 8d 4a ff 48 8d 04 c8 48 89 ca 4c 8b 10 45 8b 6a 04 48 8b 00 48 89 45 c0 49 8b 86 80 03 00 00 <48> 8b 40 08 8b 40 03 0f 1f 44 00 00 45 85 ff 0f 84 81 01 00 00 [ 1660.608980] RIP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd] RSP: ffffad4580153c70 [ 1660.617921] CR2: 0000000000000008 Tracking this down shows that udev->bos is NULL in the following code: (xhci.c, in xhci_set_usb2_hardware_lpm) field = le32_to_cpu(udev->bos->ext_cap->bmAttributes); <<<<<<< here xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n", enable ? "enable" : "disable", port_num + 1); if (enable) { /* Host supports BESL timeout instead of HIRD */ if (udev->usb2_hw_lpm_besl_capable) { /* if device doesn't have a preferred BESL value use a * default one which works with mixed HIRD and BESL * systems. See XHCI_DEFAULT_BESL definition in xhci.h */ if ((field & USB_BESL_SUPPORT) && (field & USB_BESL_BASELINE_VALID)) hird = USB_GET_BESL_BASELINE(field); else hird = udev->l1_params.besl; The failing case is when disabling LPM. So it is sufficient to avoid access to udev->bos by moving the instruction into the "enable" clause. Cc: Stable <stable@vger.kernel.org> Signed-off-by:
Carsten Schmid <carsten_schmid@mentor.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Andrey Smirnov authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit f7fac17c upstream. Xhci_handshake() implements the algorithm already captured by readl_poll_timeout_atomic(). Convert the former to use the latter to avoid repetition. Turned out this patch also fixes a bug on the AMD Stoneyridge platform where usleep(1) sometimes takes over 10ms. This means a 5 second timeout can easily take over 15 seconds which will trigger the watchdog and reboot the system. [Add info about patch fixing a bug to commit message -Mathias] Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Tested-by:
Raul E Rangel <rrangel@chromium.org> Reviewed-by:
-
Rasmus Villemoes authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit ef4d6f6b upstream. The ror32 implementation (word >> shift) | (word << (32 - shift) has undefined behaviour if shift is outside the [1, 31] range. Similarly for the 64 bit variants. Most callers pass a compile-time constant (naturally in that range), but there's an UBSAN report that these may actually be called with a shift count of 0. Instead of special-casing that, we can make them DTRT for all values of shift while also avoiding UB. For some reason, this was already partly done for rol32 (which was well-defined for [0, 31]). gcc 8 recognizes these patterns as rotates, so for example __u32 rol32(__u32 word, unsigned int shift) { return (word << (shift & 31)) | (word >> ((-shift) & 31)); } compiles to 0000000000000020 <rol32>: 20: 89 f8 mov %edi,%eax 22: 89 f1 mov %esi,%ecx 24: d3 c0 rol %cl,%eax 26: c3 retq Older compilers unfortunately do not do as well, but this only affects the small minority of users that don't pass constants. Due to integer promotions, ro[lr]8 were already well-defined for shifts in [0, 8], and ro[lr]16 were mostly well-defined for shifts in [0, 16] (only mostly - u16 gets promoted to _signed_ int, so if bit 15 is set, word << 16 is undefined). For consistency, update those as well. Link: http://lkml.kernel.org/r/20190410211906.2190-1-linux@rasmusvillemoes.dkSigned-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Reported-by:
Ido Schimmel <idosch@mellanox.com> Tested-by:
Will Deacon <will.deacon@arm.com> Cc: Vadim Pasternak <vadimp@mellanox.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
-
James Clarke authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit d3c976c1 upstream. Previously, %g2 would end up with the value PAGE_SIZE, but after the commit mentioned below it ends up with the value 1 due to being reused for a different purpose. We need it to be PAGE_SIZE as we use it to step through pages in our demap loop, otherwise we set different flags in the low 12 bits of the address written to, thereby doing things other than a nucleus page flush. Fixes: a74ad5e6 ("sparc64: Handle extremely large kernel TLB range flushes more gracefully.") Reported-by:
Meelis Roos <mroos@linux.ee> Tested-by:
James Clarke <jrtc27@jrtc27.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Junwei Hu authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 526f5b85 upstream. Error message printed: modprobe: ERROR: could not insert 'tipc': Address family not supported by protocol. when modprobe tipc after the following patch: switch order of device registration, commit 7e27e8d6 ("tipc: switch order of device registration to fix a crash") Because sock_create_kern(net, AF_TIPC, ...) called by tipc_topsrv_create_listener() in the initialization process of tipc_init_net(), so tipc_socket_init() must be execute before that. Meanwhile, tipc_net_id need to be initialized when sock_create() called, and tipc_socket_init() is no need to be called for each namespace. I add a variable tipc_topsrv_net_ops, and split the register_pernet_subsys() of tipc into two parts, and split tipc_socket_init() with initialization of pernet params. By the way, I fixed resources rollback error when tipc_bcast_init() failed in tipc_init_net(). Fixes: 7e27e8d6 ("tipc: switch order of device registration to fix a crash") Signed-off-by:
Junwei Hu <hujunwei4@huawei.com> Reported-by:
Wang Wang <wangwang2@huawei.com> Reported-by: syzbot+1e8114b61079bfe9cbc5@syzkaller.appspotmail.com Reviewed-by:
Kang Zhou <zhoukang7@huawei.com> Reviewed-by:
Suanming Mou <mousuanming@huawei.com> Signed-off-by:
-
David S. Miller authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 5593530e upstream. This reverts commit 532b0f7e. More revisions coming up. Signed-off-by:
-
Konrad Rzeszutek Wilk authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 7681f31e upstream. There is no need for this at all. Worst it means that if the guest tries to write to BARs it could lead (on certain platforms) to PCI SERR errors. Please note that with af6fc858 "xen-pciback: limit guest control of command register" a guest is still allowed to enable those control bits (safely), but is not allowed to disable them and that therefore a well behaved frontend which enables things before using them will still function correctly. This is done via an write to the configuration register 0x4 which triggers on the backend side: command_write \- pci_enable_device \- pci_enable_device_flags \- do_pci_enable_device \- pcibios_enable_device \-pci_enable_resourcess [which enables the PCI_COMMAND_MEMORY|PCI_COMMAND_IO] However guests (and drivers) which don't do this could cause problems, including the security issues which XSA-120 sought to address. Reported-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Daniel Axtens authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 357d065a upstream. VMX ghash was using a fallback that did not support interleaving simd and nosimd operations, leading to failures in the extended test suite. If I understood correctly, Eric's suggestion was to use the same data format that the generic code uses, allowing us to call into it with the same contexts. I wasn't able to get that to work - I think there's a very different key structure and data layout being used. So instead steal the arm64 approach and perform the fallback operations directly if required. Fixes: cc333cd6 ("crypto: vmx - Adding GHASH routines for VMX module") Cc: stable@vger.kernel.org # v4.1+ Reported-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Daniel Axtens <dja@axtens.net> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Antoine Tenart authored
BugLink: https://bugs.launchpad.net/bugs/1832661 [ Upstream commit 21808437 ] MVPP2_TXQ_SCHED_TOKEN_CNTR_REG() expects the logical queue id but the current code is passing the global tx queue offset, so it ends up writing to unknown registers (between 0x8280 and 0x82fc, which seemed to be unused by the hardware). This fixes the issue by using the logical queue id instead. Fixes: 3f518509 ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
Michael Chan authored
BugLink: https://bugs.launchpad.net/bugs/1832661 [ Upstream commit 296d5b54 ] For every RX packet, the driver replenishes all buffers used for that packet and puts them back into the RX ring and RX aggregation ring. In one code path where the RX packet has one RX buffer and one or more aggregation buffers, we missed recycling the aggregation buffer(s) if we are unable to allocate a new SKB buffer. This leads to the aggregation ring slowly running out of buffers over time. Fix it by properly recycling the aggregation buffers. Fixes: c0c050c5 ("bnxt_en: New Broadcom ethernet driver.") Reported-by:
Rakesh Hemnani <rhemnani@fb.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Chris Packham authored
BugLink: https://bugs.launchpad.net/bugs/1832661 TLV_SET is called with a data pointer and a len parameter that tells us how many bytes are pointed to by data. When invoking memcpy() we need to careful to only copy len bytes. Previously we would copy TLV_LENGTH(len) bytes which would copy an extra 4 bytes past the end of the data pointer which newer GCC versions complain about. In file included from test.c:17: In function 'TLV_SET', inlined from 'test' at test.c:186:5: /usr/include/linux/tipc_config.h:317:3: warning: 'memcpy' forming offset [33, 36] is out of the bounds [0, 32] of object 'bearer_name' with type 'char[32]' [-Warray-bounds] memcpy(TLV_DATA(tlv_ptr), data, tlv_len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ test.c: In function 'test': test.c::161:10: note: 'bearer_name' declared here char bearer_name[TIPC_MAX_BEARER_NAME]; ^~~~~~~~~~~ We still want to ensure any padding bytes at the end are initialised, do this with a explicit memset() rather than copy bytes past the end of data. Apply the same logic to TCM_SET. Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by:
-
Kloetzke Jan authored
BugLink: https://bugs.launchpad.net/bugs/1832661 [ Upstream commit ad70411a ] When disconnecting cdc_ncm the kernel sporadically crashes shortly after the disconnect: [ 57.868812] Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... [ 58.006653] PC is at 0x0 [ 58.009202] LR is at call_timer_fn+0xec/0x1b4 [ 58.013567] pc : [<0000000000000000>] lr : [<ffffff80080f5130>] pstate: 00000145 [ 58.020976] sp : ffffff8008003da0 [ 58.024295] x29: ffffff8008003da0 x28: 0000000000000001 [ 58.029618] x27: 000000000000000a x26: 0000000000000100 [ 58.034941] x25: 0000000000000000 x24: ffffff8008003e68 [ 58.040263] x23: 0000000000000000 x22: 0000000000000000 [ 58.045587] x21: 0000000000000000 x20: ffffffc68fac1808 [ 58.050910] x19: 0000000000000100 x18: 0000000000000000 [ 58.056232] x17: 0000007f885aff8c x16: 0000007f883a9f10 [ 58.061556] x15: 0000000000000001 x14: 000000000000006e [ 58.066878] x13: 0000000000000000 x12: 00000000000000ba [ 58.072201] x11: ffffffc69ff1db30 x10: 0000000000000020 [ 58.077524] x9 : 8000100008001000 x8 : 0000000000000001 [ 58.082847] x7 : 0000000000000800 x6 : ffffff8008003e70 [ 58.088169] x5 : ffffffc69ff17a28 x4 : 00000000ffff138b [ 58.093492] x3 : 0000000000000000 x2 : 0000000000000000 [ 58.098814] x1 : 0000000000000000 x0 : 0000000000000000 ... [ 58.205800] [< (null)>] (null) [ 58.210521] [<ffffff80080f5298>] expire_timers+0xa0/0x14c [ 58.215937] [<ffffff80080f542c>] run_timer_softirq+0xe8/0x128 [ 58.221702] [<ffffff8008081120>] __do_softirq+0x298/0x348 [ 58.227118] [<ffffff80080a6304>] irq_exit+0x74/0xbc [ 58.232009] [<ffffff80080e17dc>] __handle_domain_irq+0x78/0xac [ 58.237857] [<ffffff8008080cf4>] gic_handle_irq+0x80/0xac ... The crash happens roughly 125..130ms after the disconnect. This correlates with the 'delay' timer that is started on certain USB tx/rx errors in the URB completion handler. The problem is a race of usbnet_stop() with usbnet_start_xmit(). In usbnet_stop() we call usbnet_terminate_urbs() to cancel all URBs in flight. This only makes sense if no new URBs are submitted concurrently, though. But the usbnet_start_xmit() can run at the same time on another CPU which almost unconditionally submits an URB. The error callback of the new URB will then schedule the timer after it was already stopped. The fix adds a check if the tx queue is stopped after the tx list lock has been taken. This should reliably prevent the submission of new URBs while usbnet_terminate_urbs() does its job. The same thing is done on the rx side even though it might be safe due to other flags that are checked there. Signed-off-by:
Jan Klötzke <Jan.Kloetzke@preh.de> Signed-off-by:
-
Jisheng Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1832661 [ Upstream commit 49ce881c ] Commit 984203ce ("net: stmmac: mdio: remove reset gpio free") removed the reset gpio free, when the driver is unbinded or rmmod, we miss the gpio free. This patch uses managed API to request the reset gpio, so that the gpio could be freed properly. Fixes: 984203ce ("net: stmmac: mdio: remove reset gpio free") Signed-off-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1832661 [ Upstream commit a4270d67 ] If a network driver provides to napi_gro_frags() an skb with a page fragment of exactly 14 bytes, the call to gro_pull_from_frag0() will 'consume' the fragment by calling skb_frag_unref(skb, 0), and the page might be freed and reused. Reading eth->h_proto at the end of napi_frags_skb() might read mangled data, or crash under specific debugging features. BUG: KASAN: use-after-free in napi_frags_skb net/core/dev.c:5833 [inline] BUG: KASAN: use-after-free in napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841 Read of size 2 at addr ffff88809366840c by task syz-executor599/8957 CPU: 1 PID: 8957 Comm: syz-executor599 Not tainted 5.2.0-rc1+ #32 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188 __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 kasan_report+0x12/0x20 mm/kasan/common.c:614 __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:142 napi_frags_skb net/core/dev.c:5833 [inline] napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841 tun_get_user+0x2f3c/0x3ff0 drivers/net/tun.c:1991 tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2037 call_write_iter include/linux/fs.h:1872 [inline] do_iter_readv_writev+0x5f8/0x8f0 fs/read_write.c:693 do_iter_write fs/read_write.c:970 [inline] do_iter_write+0x184/0x610 fs/read_write.c:951 vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015 do_writev+0x15b/0x330 fs/read_write.c:1058 Fixes: a50e233c ("net-gro: restore frag0 optimization") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
