- 01 Apr, 2020 40 commits
-
-
Jakub Kicinski authored
BugLink: https://bugs.launchpad.net/bugs/1868629 [ Upstream commit b60673c4 ] Add missing attribute type validation for IEEE802154_ATTR_DEV_TYPE to the netlink policy. Fixes: 90c049b2 ("ieee802154: interface type to be added") Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Acked-by:
Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Kelsey Skunberg <kelsey.skunberg@canonical.com>
-
Jakub Kicinski authored
BugLink: https://bugs.launchpad.net/bugs/1868629 [ Upstream commit 9322cd7c ] Add missing attribute validation for several u8 types. Fixes: 2c21d115 ("net: add NL802154 interface for configuration of 802.15.4 devices") Signed-off-by:
-
Jakub Kicinski authored
BugLink: https://bugs.launchpad.net/bugs/1868629 [ Upstream commit 4c16d64e ] Add missing netlink policy entry for FRA_TUN_ID. Fixes: e7030878 ("fib: Add fib rule match on tunnel id") Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Vasundhara Volam authored
BugLink: https://bugs.launchpad.net/bugs/1868629 [ Upstream commit a9b952d2 ] MTU changes may affect the number of IRQs so we must call bnxt_close_nic()/bnxt_open_nic() with the irq_re_init parameter set to true. The reason is that a larger MTU may require aggregation rings not needed with smaller MTU. We may not be able to allocate the required number of aggregation rings and so we reduce the number of channels which will change the number of IRQs. Without this patch, it may crash eventually in pci_disable_msix() when the IRQs are not properly unwound. Fixes: c0c050c5 ("bnxt_en: New Broadcom ethernet driver.") Signed-off-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1868629 [ Upstream commit a3aefbfe ] This is similar to commit 674d9de0 ("NFC: Fix possible memory corruption when handling SHDLC I-Frame commands") and commit d7ee81ad ("NFC: nci: Add some bounds checking in nci_hci_cmd_received()") which added range checks on "pipe". The "pipe" variable comes skb->data[0] in nfc_hci_msg_rx_work(). It's in the 0-255 range. We're using it as the array index into the hdev->pipes[] array which has NFC_HCI_MAX_PIPES (128) members. Fixes: 118278f2 ("NFC: hci: Add pipes table to reference them with a tuple {gate, host}") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
You-Sheng Yang authored
BugLink: https://bugs.launchpad.net/bugs/1868629 [ Upstream commit d64c7a08 ] Dell USB Type C docking WD19/WD19DC attaches additional peripherals as: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the dock. When hotplugging such dock with additional usb devices already attached on it, the probing process may reset usb 2.1 port, therefore r8152 ethernet device is also reset. However, during r8152 device init there are several for-loops that, when it's unable to retrieve hardware registers due to being disconnected from USB, may take up to 14 seconds each in practice, and that has to be completed before USB may re-enumerate devices on the bus. As a result, devices attached to the dock will only be available after nearly 1 minute after the dock was plugged in: [ 216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface [ 216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id [ 258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY not ready [ 258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Invalid header when reading pass-thru MAC addr [ 258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get ether addr fail This happens in, for example, r8153_init: static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size, void *data, u16 type) { if (test_bit(RTL8152_UNPLUG, &tp->flags)) return -ENODEV; ... } static u16 ocp_read_word(struct r8152 *tp, u16 type, u16 index) { u32 data; ... generic_ocp_read(tp, index, sizeof(tmp), &tmp, type | byen); data = __le32_to_cpu(tmp); ... return (u16)data; } static void r8153_init(struct r8152 *tp) { ... if (test_bit(RTL8152_UNPLUG, &tp->flags)) return; for (i = 0; i < 500; i++) { if (ocp_read_word(tp, MCU_TYPE_PLA, PLA_BOOT_CTRL) & AUTOLOAD_DONE) break; msleep(20); } ... } Since ocp_read_word() doesn't check the return status of generic_ocp_read(), and the only exit condition for the loop is to have a match in the returned value, such loops will only ends after exceeding its maximum runs when the device has been marked as disconnected, which takes 500 * 20ms = 10 seconds in theory, 14 in practice. To solve this long latency another test to RTL8152_UNPLUG flag should be added after those 20ms sleep to skip unnecessary loops, so that the device probe can complete early and proceed to parent port reset/reprobe process. This can be reproduced on all kernel versions up to latest v5.6-rc2, but after v5.5-rc7 the reproduce rate is dramatically lowered to 1/30 or less while it was around 1/2. Signed-off-by:
You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by:
-
Petr Malat authored
BugLink: https://bugs.launchpad.net/bugs/1868629 Array is mapped by nfs_readdir_get_array(), the further kmap is a result of a bad merge and should be removed. This resource leakage can be exploited for DoS by receptively reading a content of a directory on NFS (e.g. by running ls). Fixes: 67a56e97 ("NFS: Fix memory leaks and corruption in readdir") Signed-off-by:
Petr Malat <oss@malat.biz> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1868628Signed-off-by:
-
yangerkun authored
BugLink: https://bugs.launchpad.net/bugs/1868628 Nowdays, we trigger a oops: ... kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] SMP KASAN ... Call Trace: [<ffffffff81a26fb1>] skcipher_recvmsg_async+0x3f1/0x1400 x86/../crypto/algif_skcipher.c:543 [<ffffffff81a28053>] skcipher_recvmsg+0x93/0x7f0 x86/../crypto/algif_skcipher.c:723 [<ffffffff823e43a4>] sock_recvmsg_nosec x86/../net/socket.c:702 [inline] [<ffffffff823e43a4>] sock_recvmsg x86/../net/socket.c:710 [inline] [<ffffffff823e43a4>] sock_recvmsg+0x94/0xc0 x86/../net/socket.c:705 [<ffffffff823e464b>] sock_read_iter+0x27b/0x3a0 x86/../net/socket.c:787 [<ffffffff817f479b>] aio_run_iocb+0x21b/0x7a0 x86/../fs/aio.c:1520 [<ffffffff817f57c9>] io_submit_one x86/../fs/aio.c:1630 [inline] [<ffffffff817f57c9>] do_io_submit+0x6b9/0x10b0 x86/../fs/aio.c:1688 [<ffffffff817f902d>] SYSC_io_submit x86/../fs/aio.c:1713 [inline] [<ffffffff817f902d>] SyS_io_submit+0x2d/0x40 x86/../fs/aio.c:1710 [<ffffffff828b33c3>] tracesys_phase2+0x90/0x95 In skcipher_recvmsg_async, we use '!sreq->tsg' to determine does we calloc fail. However, kcalloc may return ZERO_SIZE_PTR, and with this, the latter sg_init_table will trigger the bug. Fix it be use ZERO_OF_NULL_PTR. This function was introduced with ' commit a596999b ("crypto: algif - change algif_skcipher to be asynchronous")', and has been removed with 'commit e870456d ("crypto: algif_skcipher - overhaul memory management")'. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
yangerkun <yangerkun@huawei.com> Signed-off-by:
-
Mikulas Patocka authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 7cdf6a0a upstream. The crash can be reproduced by running the lvm2 testsuite test lvconvert-thin-external-cache.sh for several minutes, e.g.: while :; do make check T=shell/lvconvert-thin-external-cache.sh; done The crash happens in this call chain: do_waker -> policy_tick -> smq_tick -> end_hotspot_period -> clear_bitset -> memset -> __memset -- which accesses an invalid pointer in the vmalloc area. The work entry on the workqueue is executed even after the bitmap was freed. The problem is that cancel_delayed_work doesn't wait for the running work item to finish, so the work item can continue running and re-submitting itself even after cache_postsuspend. In order to make sure that the work item won't be running, we must use cancel_delayed_work_sync. Also, change flush_workqueue to drain_workqueue, so that if some work item submits itself or another work item, we are properly waiting for both of them. Fixes: c6b4fcba ("dm: add cache target") Cc: stable@vger.kernel.org # v3.9 Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Desnes A. Nunes do Rosario authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit fc37a163 upstream. PowerVM systems running compatibility mode on a few Power8 revisions are still vulnerable to the hardware defect that loses PMU exceptions arriving prior to a context switch. The software fix for this issue is enabled through the CPU_FTR_PMAO_BUG cpu_feature bit, nevertheless this bit also needs to be set for PowerVM compatibility mode systems. Fixes: 68f2f0d4 ("powerpc: Add a cpu feature CPU_FTR_PMAO_BUG") Signed-off-by:
Desnes A. Nunes do Rosario <desnesn@linux.ibm.com> Reviewed-by:
Leonardo Bras <leonardo@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200227134715.9715-1-desnesn@linux.ibm.comSigned-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 36d5d220 upstream. The caller is already holding the lock so this will deadlock. Fixes: 0b58828c ("DMAENGINE: COH 901 318 remove irq counting") Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 44f2f882 upstream. This is only called from adt7462_update_device(). The caller expects it to return zero on error. I fixed a similar issue earlier in commit a4bf06d5 ("hwmon: (adt7462) ADT7462_REG_VOLT_MAX() should return 0") but I missed this one. Fixes: c0b4e3ab ("adt7462: new hwmon driver") Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Link: https://lore.kernel.org/r/20200303101608.kqjwfcazu2ylhi2a@kili.mountainSigned-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Ahmad Fatoum authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 512a928a upstream. This function is not only needed by the platform suspend code, but is also reused as the CPU resume function when the ARM cores can be powered down completely in deep idle, which is the case on i.MX6SX and i.MX6UL(L). Providing the static inline stub whenever CONFIG_SUSPEND is disabled means that those platforms will hang on resume from cpuidle if suspend is disabled. So there are two problems: - The static inline stub masks the linker error - The function is not available where needed Fix both by just building the function unconditionally, when CONFIG_SOC_IMX6 is enabled. The actual code is three instructions long, so it's arguably ok to just leave it in for all i.MX6 kernel configurations. Fixes: 05136f08 ("ARM: imx: support arm power off in cpuidle for i.mx6sx") Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
Rouven Czerwinski <r.czerwinski@pengutronix.de> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Jason Gunthorpe authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit c14dfddb upstream. The algorithm pre-allocates a cm_id since allocation cannot be done while holding the cm.lock spinlock, however it doesn't free it on one error path, leading to a memory leak. Fixes: 067b171b ("IB/cm: Share listening CM IDs") Link: https://lore.kernel.org/r/20200221152023.GA8680@ziepe.caSigned-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Bernard Metzler authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 810dbc69 upstream. The dealloc_work_entries() function must update the work_free_list pointer while freeing its entries, since potentially called again on same list. A second iteration of the work list caused system crash. This happens, if work allocation fails during cma_iw_listen() and free_cm_id() tries to free the list again during cleanup. Fixes: 922a8e9f ("RDMA: iWARP Connection Manager.") Link: https://lore.kernel.org/r/20200302181614.17042-1-bmt@zurich.ibm.com Reported-by: syzbot+cb0c054eabfba4342146@syzkaller.appspotmail.com Signed-off-by:
Bernard Metzler <bmt@zurich.ibm.com> Reviewed-by:
-
Charles Keepax authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 9b319308 upstream. commit c2caa4da ("ASoC: Fix widget powerdown on shutdown") added a set of the power state during snd_soc_dapm_shutdown to ensure the widgets powered off. However, when commit 39eb5fd1 ("ASoC: dapm: Delay w->power update until the changes are written") added the new_power member of the widget structure, to differentiate between the current power state and the target power state, it did not update the shutdown to use the new_power member. As new_power has not updated it will be left in the state set by the last DAPM sequence, ie. 1 for active widgets. So as the DAPM sequence for the shutdown proceeds it will turn the widgets on (despite them already being on) rather than turning them off. Fixes: 39eb5fd1 ("ASoC: dapm: Delay w->power update until the changes are written") Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200228153145.21013-1-ckeepax@opensource.cirrus.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Matthias Reichl authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit ac0a6899 upstream. When we get a clock error during probe we have to call regulator_bulk_disable before bailing out, otherwise we trigger a warning in regulator_put. Fix this by using "goto err" like in the error cases above. Fixes: 5a3af129 ("ASoC: pcm512x: Add PCM512x driver") Signed-off-by:
Matthias Reichl <hias@horus.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200220202956.29233-1-hias@horus.comSigned-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 6c89ffea upstream. dpcm_show_state() invokes multiple snprintf() calls to concatenate formatted strings on the fixed size buffer. The usage of snprintf() is supposed for avoiding the buffer overflow, but it doesn't work as expected because snprintf() doesn't return the actual output size but the size to be written. Fix this bug by replacing all snprintf() calls with scnprintf() calls. Fixes: f86dcef8 ("ASoC: dpcm: Add debugFS support for DPCM") Signed-off-by:
Takashi Iwai <tiwai@suse.de> Acked-by:
Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20200218111737.14193-4-tiwai@suse.deSigned-off-by:
-
Dmitry Osipenko authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit c33ee130 upstream. The interrupt handler puts a half-completed DMA descriptor on a free list and then schedules tasklet to process bottom half of the descriptor that executes client's callback, this creates possibility to pick up the busy descriptor from the free list. Thus, let's disallow descriptor's re-use until it is fully processed. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Acked-by:
Jon Hunter <jonathanh@nvidia.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200209163356.6439-3-digetx@gmail.comSigned-off-by:
-
Dmitry Osipenko authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 94788af4 upstream. I was doing some experiments with I2C and noticed that Tegra APB DMA driver crashes sometime after I2C DMA transfer termination. The crash happens because tegra_dma_terminate_all() bails out immediately if pending list is empty, and thus, it doesn't release the half-completed descriptors which are getting re-used before ISR tasklet kicks-in. tegra-i2c 7000c400.i2c: DMA transfer timeout elants_i2c 0-0010: elants_i2c_irq: failed to read data: -110 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 142 at lib/list_debug.c:45 __list_del_entry_valid+0x45/0xac list_del corruption, ddbaac44->next is LIST_POISON1 (00000100) Modules linked in: CPU: 0 PID: 142 Comm: kworker/0:2 Not tainted 5.5.0-rc2-next-20191220-00175-gc3605715758d-dirty #538 Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) Workqueue: events_freezable_power_ thermal_zone_device_check [<c010e5c5>] (unwind_backtrace) from [<c010a1c5>] (show_stack+0x11/0x14) [<c010a1c5>] (show_stack) from [<c0973925>] (dump_stack+0x85/0x94) [<c0973925>] (dump_stack) from [<c011f529>] (__warn+0xc1/0xc4) [<c011f529>] (__warn) from [<c011f7e9>] (warn_slowpath_fmt+0x61/0x78) [<c011f7e9>] (warn_slowpath_fmt) from [<c042497d>] (__list_del_entry_valid+0x45/0xac) [<c042497d>] (__list_del_entry_valid) from [<c047a87f>] (tegra_dma_tasklet+0x5b/0x154) [<c047a87f>] (tegra_dma_tasklet) from [<c0124799>] (tasklet_action_common.constprop.0+0x41/0x7c) [<c0124799>] (tasklet_action_common.constprop.0) from [<c01022ab>] (__do_softirq+0xd3/0x2a8) [<c01022ab>] (__do_softirq) from [<c0124683>] (irq_exit+0x7b/0x98) [<c0124683>] (irq_exit) from [<c0168c19>] (__handle_domain_irq+0x45/0x80) [<c0168c19>] (__handle_domain_irq) from [<c043e429>] (gic_handle_irq+0x45/0x7c) [<c043e429>] (gic_handle_irq) from [<c0101aa5>] (__irq_svc+0x65/0x94) Exception stack(0xde2ebb90 to 0xde2ebbd8) Signed-off-by:
-
Jiri Slaby authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit e8c75a30 upstream. sel_lock cannot nest in the console lock. Thanks to syzkaller, the kernel states firmly: > WARNING: possible circular locking dependency detected > 5.6.0-rc3-syzkaller #0 Not tainted > ------------------------------------------------------ > syz-executor.4/20336 is trying to acquire lock: > ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136 > > but task is already holding lock: > ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374 > > which lock already depends on the new lock. > > the existing dependency chain (in reverse order) is: > > -> #2 (sel_lock){+.+.}: > mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118 > set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217 > set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181 > tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050 > vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364 This is ioctl(TIOCL_SETSEL). Locks held on the path: console_lock -> sel_lock > -> #1 (console_lock){+.+.}: > console_lock+0x46/0x70 kernel/printk/printk.c:2289 > con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223 > n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350 > do_tty_write drivers/tty/tty_io.c:962 [inline] > tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046 This is write(). Locks held on the path: termios_rwsem -> console_lock > -> #0 (&tty->termios_rwsem){++++}: > down_write+0x57/0x140 kernel/locking/rwsem.c:1534 > tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136 > mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902 > tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465 > paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389 > tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055 > vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364 This is ioctl(TIOCL_PASTESEL). Locks held on the path: sel_lock -> termios_rwsem > other info that might help us debug this: > > Chain exists of: > &tty->termios_rwsem --> console_lock --> sel_lock Clearly. From the above, we have: console_lock -> sel_lock sel_lock -> termios_rwsem termios_rwsem -> console_lock Fix this by reversing the console_lock -> sel_lock dependency in ioctl(TIOCL_SETSEL). First, lock sel_lock, then console_lock. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com Fixes: 07e6124a ("vt: selection, close sel_buffer race") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200228115406.5735-2-jslaby@suse.czSigned-off-by:
-
Jiri Slaby authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 4b70dd57 upstream. We need to nest the console lock in sel_lock, so we have to push it down a bit. Fortunately, the callers of set_selection_* just lock the console lock around the function call. So moving it down is easy. In the next patch, we switch the order. Signed-off-by:
-
Jiri Slaby authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 07e6124a upstream. syzkaller reported this UAF: BUG: KASAN: use-after-free in n_tty_receive_buf_common+0x2481/0x2940 drivers/tty/n_tty.c:1741 Read of size 1 at addr ffff8880089e40e9 by task syz-executor.1/13184 CPU: 0 PID: 13184 Comm: syz-executor.1 Not tainted 5.4.7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: ... kasan_report+0xe/0x20 mm/kasan/common.c:634 n_tty_receive_buf_common+0x2481/0x2940 drivers/tty/n_tty.c:1741 tty_ldisc_receive_buf+0xac/0x190 drivers/tty/tty_buffer.c:461 paste_selection+0x297/0x400 drivers/tty/vt/selection.c:372 tioclinux+0x20d/0x4e0 drivers/tty/vt/vt.c:3044 vt_ioctl+0x1bcf/0x28d0 drivers/tty/vt/vt_ioctl.c:364 tty_ioctl+0x525/0x15a0 drivers/tty/tty_io.c:2657 vfs_ioctl fs/ioctl.c:47 [inline] It is due to a race between parallel paste_selection (TIOCL_PASTESEL) and set_selection_user (TIOCL_SETSEL) invocations. One uses sel_buffer, while the other frees it and reallocates a new one for another selection. Add a mutex to close this race. The mutex takes care properly of sel_buffer and sel_buffer_lth only. The other selection global variables (like sel_start, sel_end, and sel_cons) are protected only in set_selection_user. The other functions need quite some more work to close the races of the variables there. This is going to happen later. This likely fixes (I am unsure as there is no reproducer provided) bug 206361 too. It was marked as CVE-2020-8648. Signed-off-by:
-
OGAWA Hirofumi authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit bc87302a upstream. When get an error in the middle of reading an inode, some fields in the inode might be still not initialized. And then the evict_inode path may access those fields via iput(). To fix, this makes sure that inode fields are initialized. Reported-by: syzbot+9d82b8de2992579da5d0@syzkaller.appspotmail.com Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/871rqnreqx.fsf@mail.parknet.co.jpSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Zhang Xiaoxu authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 513dc792 upstream. When syzkaller tests, there is a UAF: BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr ffff880000100000 Read of size 2 by task syz-executor.1/16489 page:ffffea0000004000 count:0 mapcount:-127 mapping: (null) index:0x0 page flags: 0xfffff00000000() page dumped because: kasan: bad access detected CPU: 1 PID: 16489 Comm: syz-executor.1 Not tainted Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 Call Trace: [<ffffffffb119f309>] dump_stack+0x1e/0x20 [<ffffffffb04af957>] kasan_report+0x577/0x950 [<ffffffffb04ae652>] __asan_load2+0x62/0x80 [<ffffffffb090f26d>] vgacon_invert_region+0x9d/0x110 [<ffffffffb0a39d95>] invert_screen+0xe5/0x470 [<ffffffffb0a21dcb>] set_selection+0x44b/0x12f0 [<ffffffffb0a3bfae>] tioclinux+0xee/0x490 [<ffffffffb0a1d114>] vt_ioctl+0xff4/0x2670 [<ffffffffb0a0089a>] tty_ioctl+0x46a/0x1a10 [<ffffffffb052db3d>] do_vfs_ioctl+0x5bd/0xc40 [<ffffffffb052e2f2>] SyS_ioctl+0x132/0x170 [<ffffffffb11c9b1b>] system_call_fastpath+0x22/0x27 Memory state around the buggy address: ffff8800000fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8800000fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff880000100000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff It can be reproduce in the linux mainline by the program: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/ioctl.h> #include <linux/vt.h> struct tiocl_selection { unsigned short xs; /* X start */ unsigned short ys; /* Y start */ unsigned short xe; /* X end */ unsigned short ye; /* Y end */ unsigned short sel_mode; /* selection mode */ }; #define TIOCL_SETSEL 2 struct tiocl { unsigned char type; unsigned char pad; struct tiocl_selection sel; }; int main() { int fd = 0; const char *dev = "/dev/char/4:1"; struct vt_consize v = {0}; struct tiocl tioc = {0}; fd = open(dev, O_RDWR, 0); v.v_rows = 3346; ioctl(fd, VT_RESIZEX, &v); tioc.type = TIOCL_SETSEL; ioctl(fd, TIOCLINUX, &tioc); return 0; } When resize the screen, update the 'vc->vc_size_row' to the new_row_size, but when 'set_origin' in 'vgacon_set_origin', vgacon use 'vga_vram_base' for 'vc_origin' and 'vc_visible_origin', not 'vc_screenbuf'. It maybe smaller than 'vc_screenbuf'. When TIOCLINUX, use the new_row_size to calc the offset, it maybe larger than the vga_vram_size in vgacon driver, then bad access. Also, if set an larger screenbuf firstly, then set an more larger screenbuf, when copy old_origin to new_origin, a bad access may happen. So, If the screen size larger than vga_vram, resize screen should be failed. This alse fix CVE-2020-8649 and CVE-2020-8647. Linus pointed out that overflow checking seems absent. We're saved by the existing bounds checks in vc_do_resize() with rather strict limits: if (cols > VC_RESIZE_MAXCOL || lines > VC_RESIZE_MAXROW) return -EINVAL; Fixes: 0aec4867 ("[PATCH] SVGATextMode fix") Reference: CVE-2020-8647 and CVE-2020-8649 Reported-by:
Zhang Xiaoxu <zhangxiaoxu5@huawei.com> [danvet: augment commit message to point out overflow safety] Cc: stable@vger.kernel.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200304022429.37738-1-zhangxiaoxu5@huawei.comSigned-off-by:
-
Eugeniu Rosca authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 1f8b39bc upstream. Reviewing a fresh portion of coverity defects in USB core (specifically CID 1458999), Alan Stern noted below in [1]: On Tue, Feb 25, 2020 at 02:39:23PM -0500, Alan Stern wrote: > A revised search finds line 997 in drivers/usb/core/hub.c and lines > 216, 269 in drivers/usb/core/port.c. (I didn't try looking in any > other directories.) AFAICT all three of these should check the > return value, although a error message in the kernel log probably > isn't needed. Factor out the usb_port_runtime_{resume,suspend}() changes into a standalone patch to allow conflict-free porting on top of stable v3.9+. [1] https://lore.kernel.org/lkml/Pine.LNX.4.44L0.2002251419120.1485-100000@iolanthe.rowland.org Fixes: 971fcd49 ("usb: add runtime pm support for usb port device") Cc: stable@vger.kernel.org # v3.9+ Suggested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by:
-
Eugeniu Rosca authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 60e3f6e4 upstream. Reviewing a fresh portion of coverity defects in USB core (specifically CID 1458999), Alan Stern noted below in [1]: On Tue, Feb 25, 2020 at 02:39:23PM -0500, Alan Stern wrote: > A revised search finds line 997 in drivers/usb/core/hub.c and lines > 216, 269 in drivers/usb/core/port.c. (I didn't try looking in any > other directories.) AFAICT all three of these should check the > return value, although a error message in the kernel log probably > isn't needed. Factor out the usb_remove_device() change into a standalone patch to allow conflict-free integration on top of the earliest stable branches. [1] https://lore.kernel.org/lkml/Pine.LNX.4.44L0.2002251419120.1485-100000@iolanthe.rowland.org Fixes: 253e0572 ("USB: add a "remove hardware" sysfs attribute") Cc: stable@vger.kernel.org # v2.6.33+ Suggested-by:
-
Dan Lazewatsky authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit b96ed52d upstream. LPM on the device appears to cause xHCI host controllers to claim that there isn't enough bandwidth to support additional devices. Signed-off-by:
Dan Lazewatsky <dlaz@chromium.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.com> Link: https://lore.kernel.org/r/20200226143438.1445-1-gustavo.padovan@collabora.comSigned-off-by:
-
Jim Lin authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 86d92f54 upstream. Current driver has 240 (USB2.0) and 2048 (USB3.0) as max_sectors, e.g., /sys/bus/scsi/devices/0:0:0:0/max_sectors If data access times out, driver error handling will issue a port reset. Sometimes Samsung Fit (090C:1000) flash disk will not respond to later Set Address or Get Descriptor command. Adding this quirk to limit max_sectors to 64 sectors to avoid issue occurring. Signed-off-by:
Jim Lin <jilin@nvidia.com> Acked-by:
-
Ronnie Sahlberg authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit fc513fac upstream. If from cifs_revalidate_dentry_attr() the SMB2/QUERY_INFO call fails with an error, such as STATUS_SESSION_EXPIRED, causing the session to be reconnected it is possible we will leak -EAGAIN back to the application even for system calls such as stat() where this is not a valid error. Fix this by re-trying the operation from within cifs_revalidate_dentry_attr() if cifs_get_inode_info*() returns -EAGAIN. This fixes stat() and possibly also other system calls that uses cifs_revalidate_dentry*(). Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 8b101a5e ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206283 Link: https://lore.kernel.org/r/d44c53a7-9bc1-15c7-6d4a-0c10cb9dffce@virtuozzo.comReviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
Marco Felsch authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit e9a0e65e ] The da9062 hw has a minimum ping cool down phase of at least 200ms. The driver takes that into account by setting the min_hw_heartbeat_ms to 300ms and the core guarantees that the hw limit is observed for the ping() calls. But the core can't guarantee the required minimum ping cool down phase if a stop() command is send immediately after the ping() command. So it is not allowed to ping the watchdog within the stop() command as the driver does. Remove the ping can be done without doubts because the watchdog gets disabled anyway and a (re)start resets the watchdog counter too. Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Reviewed-by:
Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by:
-
Marek Vasut authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 58292104 ] The Micrel KSZ8851-16MLLI datasheet DS00002357B page 12 states that BE[3:0] signals are active high. This contradicts the measurements of the behavior of the actual chip, where these signals behave as active low. For example, to read the CIDER register, the bus must expose 0xc0c0 during the address phase, which means BE[3:0]=4'b1100. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: David S. Miller <davem@davemloft.net> Cc: Lukas Wunner <lukas@wunner.de> Cc: Petr Stetiar <ynezz@true.cz> Cc: YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Marek Vasut authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit edacb098 ] The packet data written to and read from Micrel KSZ8851-16MLLI must be byte-swapped in 16-bit mode, add this byte-swapping. Signed-off-by:
-
Marek Vasut authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 69233bba ] This driver is mixing 8-bit and 16-bit bus accessors for reasons unknown, however the speculation is that this was some sort of attempt to support the 8-bit bus mode. As per the KS8851-16MLL documentation, all two registers accessed via the 8-bit accessors are internally 16-bit registers, so reading them using 16-bit accessors is fine. The KS_CCR read can be converted to 16-bit read outright, as it is already a concatenation of two 8-bit reads of that register. The KS_RXQCR accesses are 8-bit only, however writing the top 8 bits of the register is OK as well, since the driver caches the entire 16-bit register value anyway. Finally, the driver is not used by any hardware in the kernel right now. The only hardware available to me is one with 16-bit bus, so I have no way to test the 8-bit bus mode, however it is unlikely this ever really worked anyway. If the 8-bit bus mode is ever required, it can be easily added by adjusting the 16-bit accessors to do 2 consecutive accesses, which is how this should have been done from the beginning. Signed-off-by:
-
Harigovindan P authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit a1028dcf ] Save pll state before dsi host is powered off. Without this change some register values gets resetted. Signed-off-by:
Harigovindan P <harigovi@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org> Signed-off-by:
-
John Stultz authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 7fd2dfc3 ] I was hitting kCFI crashes when building with clang, and after some digging finally narrowed it down to the dsi_mgr_connector_mode_valid() function being implemented as returning an int, instead of an enum drm_mode_status. This patch fixes it, and appeases the opaque word of the kCFI gods (seriously, clang inlining everything makes the kCFI backtraces only really rough estimates of where things went wrong). Thanks as always to Sami for his help narrowing this down. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Alistair Delva <adelva@google.com> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: freedreno@lists.freedesktop.org Cc: clang-built-linux@googlegroups.com Signed-off-by:
John Stultz <john.stultz@linaro.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Tested-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
Sergey Organov authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit e4bfded5 ] Symptom: application opens /dev/ttyGS0 and starts sending (writing) to it while either USB cable is not connected, or nobody listens on the other side of the cable. If driver circular buffer overflows before connection is established, no data will be written to the USB layer until/unless /dev/ttyGS0 is closed and re-opened again by the application (the latter besides having no means of being notified about the event of establishing of the connection.) Fix: on open and/or connect, kick Tx to flush circular buffer data to USB layer. Signed-off-by:
Sergey Organov <sorganov@gmail.com> Reviewed-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Lars-Peter Clausen authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 43d56572 ] ffs_aio_cancel() can be called from both interrupt and thread context. Make sure that the current IRQ state is saved and restored by using spin_{un,}lock_irq{save,restore}(). Otherwise undefined behavior might occur. Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
-
