- 09 Aug, 2020 40 commits
-
-
Ian Abbott authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit f07804ec upstream. `ni6527_intr_insn_config()` processes `INSN_CONFIG` comedi instructions for the "interrupt" subdevice. When `data[0]` is `INSN_CONFIG_DIGITAL_TRIG` it is configuring the digital trigger. When `data[2]` is `COMEDI_DIGITAL_TRIG_ENABLE_EDGES` it is configuring rising and falling edge detection for the digital trigger, using a base channel number (or shift amount) in `data[3]`, a rising edge bitmask in `data[4]` and falling edge bitmask in `data[5]`. If the base channel number (shift amount) is greater than or equal to the number of channels (24) of the digital input subdevice, there are no changes to the rising and falling edges, so the mask of channels to be changed can be set to 0, otherwise the mask of channels to be changed, and the rising and falling edge bitmasks are shifted by the base channel number before calling `ni6527_set_edge_detection()` to change the appropriate registers. Unfortunately, the code is comparing the base channel (shift amount) to the interrupt subdevice's number of channels (1) instead of the digital input subdevice's number of channels (24). Fix it by comparing to 32 because all shift amounts for an `unsigned int` must be less than that and everything from bit 24 upwards is ignored by `ni6527_set_edge_detection()` anyway. Fixes: 110f9e68 ("staging: comedi: ni_6527: support INSN_CONFIG_DIGITAL_TRIG") Cc: <stable@vger.kernel.org> # 3.17+ Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20200717145257.112660-2-abbotti@mev.co.ukSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Ian Abbott authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 0bd0db42 upstream. The `INSN_CONFIG` comedi instruction with sub-instruction code `INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is used as a right shift amount for other bitmask values without being checked. Shift amounts greater than or equal to 32 will result in undefined behavior. Add code to deal with this. Fixes: 33cdce62 ("staging: comedi: addi_apci_1032: conform to new INSN_CONFIG_DIGITAL_TRIG") Cc: <stable@vger.kernel.org> #3.8+ Signed-off-by:
-
Rustam Kovhaev authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit faaff976 upstream. As syzkaller detected, wlan-ng driver does not do sanity check of endpoints in prism2sta_probe_usb(), add check for xfer direction and type Reported-and-tested-by: syzbot+c2a1fa67c02faa0de723@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=c2a1fa67c02faa0de723Signed-off-by:
Rustam Kovhaev <rkovhaev@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200722161052.999754-1-rkovhaev@gmail.comSigned-off-by:
-
Steve French authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 0e670518 upstream. This reverts commit 9ffad926. Upon additional testing with older servers, it was found that the original commit introduced a regression when using the old SMB1 dialect and rsyncing over an existing file. The patch will need to be respun to address this, likely including a larger refactoring of the SMB1 and SMB3 rename code paths to make it less confusing and also to address some additional rename error cases that SMB3 may be able to workaround. Signed-off-by:
Steve French <stfrench@microsoft.com> Reported-by:
Patrick Fernie <patrick.fernie@gmail.com> CC: Stable <stable@vger.kernel.org> Acked-by:
Ronnie Sahlberg <lsahlber@redhat.com> Acked-by:
Pavel Shilovsky <pshilov@microsoft.com> Acked-by:
Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 81e96851 ] The clang integrated assembler requires the 'cmp' instruction to have a length prefix here: arch/x86/math-emu/wm_sqrt.S:212:2: error: ambiguous instructions require an explicit suffix (could be 'cmpb', 'cmpw', or 'cmpl') cmp $0xffffffff,-24(%ebp) ^ Make this a 32-bit comparison, which it was clearly meant to be. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://lkml.kernel.org/r/20200527135352.1198078-1-arnd@arndb.deSigned-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Will Deacon authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 5afc7855 ] Rather than open-code test_tsk_thread_flag() at each callsite, simply replace the couple of offenders with calls to test_tsk_thread_flag() directly. Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Evgeny Novikov authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit c8f8529e ] gr_ep_init() does not assign the allocated request anywhere if allocation of memory for the buffer fails. This is a memory leak fixed by the given patch. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Evgeny Novikov <novikov@ispras.ru> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Marc Kleine-Budde authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit e84861fe ] This function is used by dev_get_regmap() to retrieve a regmap for the specified device. If the device has more than one regmap, the name parameter can be used to specify one. The code here uses a pointer comparison to check for equal strings. This however will probably always fail, as the regmap->name is allocated via kstrdup_const() from the regmap's config->name. Fix this by using strcmp() instead. Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20200703103315.267996-1-mkl@pengutronix.deSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Pi-Hsun Shih authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit d178770d ] Currently the basepath is removed only from the beginning of the string. When the symbol is inlined and there's multiple line outputs of addr2line, only the first line would have basepath removed. Change to remove the basepath prefix from all lines. Fixes: 31013836 ("scripts/decode_stacktrace: match basepath using shell prefix operator, not regex") Co-developed-by:
Shik Chen <shik@chromium.org> Signed-off-by:
Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Cc: Sasha Levin <sashal@kernel.org> Cc: Nicolas Boichat <drinkcat@chromium.org> Cc: Jiri Slaby <jslaby@suse.cz> Link: http://lkml.kernel.org/r/20200720082709.252805-1-pihsun@chromium.orgSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Wang Hai authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit bca9749b ] If try_toggle_control_gpio() failed in smc_drv_probe(), free_netdev(ndev) should be called to free the ndev created earlier. Otherwise, a memleak will occur. Fixes: 7d2911c4 ("net: smc91x: Fix gpios for device tree based booting") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sergey Organov authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 473309fb ] From Documentation/networking/timestamping.txt: A driver which supports hardware time stamping shall update the struct with the actual, possibly more permissive configuration. Do update the struct passed when we upscale the requested time stamping mode. Fixes: cb646e2b ("ptp: Added a clock driver for the National Semiconductor PHYTER.") Signed-off-by:
Sergey Organov <sorganov@gmail.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
George Kennedy authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit c28d9a28 ] If ax88172a_unbind() fails, make sure that the return code is less than zero so that cleanup is done properly and avoid UAF. Fixes: a9a51bd7 ("ax88172a: fix information leak on short answers") Signed-off-by:
George Kennedy <george.kennedy@oracle.com> Reported-by: syzbot+4cd84f527bf4a10fc9c1@syzkaller.appspotmail.com Signed-off-by:
-
Christophe JAILLET authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 3195c470 ] The size used when calling 'pci_alloc_consistent()' and 'pci_free_consistent()' should match. Fix it and have it consistent with the corresponding call in 'rr_close()'. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Boris Burkov authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 48cfa61b ] It is possible to cause a btrfs mount to fail by racing it with a slow umount. The crux of the sequence is generic_shutdown_super not yet calling sop->put_super before btrfs_mount_root calls btrfs_open_devices. If that occurs, btrfs_open_devices will decide the opened counter is non-zero, increment it, and skip resetting fs_devices->total_rw_bytes to 0. From here, mount will call sget which will result in grab_super trying to take the super block umount semaphore. That semaphore will be held by the slow umount, so mount will block. Before up-ing the semaphore, umount will delete the super block, resulting in mount's sget reliably allocating a new one, which causes the mount path to dutifully fill it out, and increment total_rw_bytes a second time, which causes the mount to fail, as we see double the expected bytes. Here is the sequence laid out in greater detail: CPU0 CPU1 down_write sb->s_umount btrfs_kill_super kill_anon_super(sb) generic_shutdown_super(sb); shrink_dcache_for_umount(sb); sync_filesystem(sb); evict_inodes(sb); // SLOW btrfs_mount_root btrfs_scan_one_device fs_devices = device->fs_devices fs_info->fs_devices = fs_devices // fs_devices-opened makes this a no-op btrfs_open_devices(fs_devices, mode, fs_type) s = sget(fs_type, test, set, flags, fs_info); find sb in s_instances grab_super(sb); down_write(&s->s_umount); // blocks sop->put_super(sb) // sb->fs_devices->opened == 2; no-op spin_lock(&sb_lock); hlist_del_init(&sb->s_instances); spin_unlock(&sb_lock); up_write(&sb->s_umount); return 0; retry lookup don't find sb in s_instances (deleted by CPU0) s = alloc_super return s; btrfs_fill_super(s, fs_devices, data) open_ctree // fs_devices total_rw_bytes improperly set! btrfs_read_chunk_tree read_one_dev // increment total_rw_bytes again!! super_total_bytes < fs_devices->total_rw_bytes // ERROR!!! To fix this, we clear total_rw_bytes from within btrfs_read_chunk_tree before the calls to read_one_dev, while holding the sb umount semaphore and the uuid mutex. To reproduce, it is sufficient to dirty a decent number of inodes, then quickly umount and mount. for i in $(seq 0 500) do dd if=/dev/zero of="/mnt/foo/$i" bs=1M count=1 done umount /mnt/foo& mount /mnt/foo does the trick for me. CC: stable@vger.kernel.org # 4.4+ Signed-off-by:
Boris Burkov <boris@bur.io> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 68239654 ] The sequence fpu->initialized = 1; /* step A */ preempt_disable(); /* step B */ fpu__restore(fpu); preempt_enable(); in __fpu__restore_sig() is racy in regard to a context switch. For 32bit frames, __fpu__restore_sig() prepares the FPU state within fpu->state. To ensure that a context switch (switch_fpu_prepare() in particular) does not modify fpu->state it uses fpu__drop() which sets fpu->initialized to 0. After fpu->initialized is cleared, the CPU's FPU state is not saved to fpu->state during a context switch. The new state is loaded via fpu__restore(). It gets loaded into fpu->state from userland and ensured it is sane. fpu->initialized is then set to 1 in order to avoid fpu__initialize() doing anything (overwrite the new state) which is part of fpu__restore(). A context switch between step A and B above would save CPU's current FPU registers to fpu->state and overwrite the newly prepared state. This looks like a tiny race window but the Kernel Test Robot reported this back in 2016 while we had lazy FPU support. Borislav Petkov made the link between that report and another patch that has been posted. Since the removal of the lazy FPU support, this race goes unnoticed because the warning has been removed. Disable bottom halves around the restore sequence to avoid the race. BH need to be disabled because BH is allowed to run (even with preemption disabled) and might invoke kernel_fpu_begin() by doing IPsec. [ bp: massage commit message a bit. ] Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
-
Filipe Manana authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 580c079b upstream. At btrfs_find_all_roots_safe() we allocate a ulist and set the **roots argument to point to it. However if later we fail due to an error returned by find_parent_nodes(), we free that ulist but leave a dangling pointer in the **roots argument. Upon receiving the error, a caller of this function can attempt to free the same ulist again, resulting in an invalid memory access. One such scenario is during qgroup accounting: btrfs_qgroup_account_extents() --> calls btrfs_find_all_roots() passes &new_roots (a stack allocated pointer) to btrfs_find_all_roots() --> btrfs_find_all_roots() just calls btrfs_find_all_roots_safe() passing &new_roots to it --> allocates ulist and assigns its address to **roots (which points to new_roots from btrfs_qgroup_account_extents()) --> find_parent_nodes() returns an error, so we free the ulist and leave **roots pointing to it after returning --> btrfs_qgroup_account_extents() sees btrfs_find_all_roots() returned an error and jumps to the label 'cleanup', which just tries to free again the same ulist Stack trace example: ------------[ cut here ]------------ BTRFS: tree first key check failed WARNING: CPU: 1 PID: 1763215 at fs/btrfs/disk-io.c:422 btrfs_verify_level_key+0xe0/0x180 [btrfs] Modules linked in: dm_snapshot dm_thin_pool (...) CPU: 1 PID: 1763215 Comm: fsstress Tainted: G W 5.8.0-rc3-btrfs-next-64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:btrfs_verify_level_key+0xe0/0x180 [btrfs] Code: 28 5b 5d (...) RSP: 0018:ffffb89b473779a0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff90397759bf08 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000027 RDI: 00000000ffffffff RBP: ffff9039a419c000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: ffffb89b43301000 R12: 000000000000005e R13: ffffb89b47377a2e R14: ffffb89b473779af R15: 0000000000000000 FS: 00007fc47e1e1000(0000) GS:ffff9039ac200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc47e1df000 CR3: 00000003d9e4e001 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: read_block_for_search+0xf6/0x350 [btrfs] btrfs_next_old_leaf+0x242/0x650 [btrfs] resolve_indirect_refs+0x7cf/0x9e0 [btrfs] find_parent_nodes+0x4ea/0x12c0 [btrfs] btrfs_find_all_roots_safe+0xbf/0x130 [btrfs] btrfs_qgroup_account_extents+0x9d/0x390 [btrfs] btrfs_commit_transaction+0x4f7/0xb20 [btrfs] btrfs_sync_file+0x3d4/0x4d0 [btrfs] do_fsync+0x38/0x70 __x64_sys_fdatasync+0x13/0x20 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc47e2d72e3 Code: Bad RIP value. RSP: 002b:00007fffa32098c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004b RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc47e2d72e3 RDX: 00007fffa3209830 RSI: 00007fffa3209830 RDI: 0000000000000003 RBP: 000000000000072e R08: 0000000000000001 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000003e8 R13: 0000000051eb851f R14: 00007fffa3209970 R15: 00005607c4ac8b50 irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffffffffb8eb5e85>] copy_process+0x755/0x1eb0 softirqs last enabled at (0): [<ffffffffb8eb5e85>] copy_process+0x755/0x1eb0 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 8639237550317b48 ]--- BTRFS error (device sdc): tree first key mismatch detected, bytenr=62324736 parent_transid=94 key expected=(262,108,1351680) has=(259,108,1921024) general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 2 PID: 1763215 Comm: fsstress Tainted: G W 5.8.0-rc3-btrfs-next-64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ulist_release+0x14/0x60 [btrfs] Code: c7 07 00 (...) RSP: 0018:ffffb89b47377d60 EFLAGS: 00010282 RAX: 6b6b6b6b6b6b6b6b RBX: ffff903959b56b90 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000270024 RDI: ffff9036e2adc840 RBP: ffff9036e2adc848 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9036e2adc840 R13: 0000000000000015 R14: ffff9039a419ccf8 R15: ffff90395d605840 FS: 00007fc47e1e1000(0000) GS:ffff9039ac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8c1c0a51c8 CR3: 00000003d9e4e004 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ulist_free+0x13/0x20 [btrfs] btrfs_qgroup_account_extents+0xf3/0x390 [btrfs] btrfs_commit_transaction+0x4f7/0xb20 [btrfs] btrfs_sync_file+0x3d4/0x4d0 [btrfs] do_fsync+0x38/0x70 __x64_sys_fdatasync+0x13/0x20 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc47e2d72e3 Code: Bad RIP value. RSP: 002b:00007fffa32098c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004b RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc47e2d72e3 RDX: 00007fffa3209830 RSI: 00007fffa3209830 RDI: 0000000000000003 RBP: 000000000000072e R08: 0000000000000001 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000003e8 R13: 0000000051eb851f R14: 00007fffa3209970 R15: 00005607c4ac8b50 Modules linked in: dm_snapshot dm_thin_pool (...) ---[ end trace 8639237550317b49 ]--- RIP: 0010:ulist_release+0x14/0x60 [btrfs] Code: c7 07 00 (...) RSP: 0018:ffffb89b47377d60 EFLAGS: 00010282 RAX: 6b6b6b6b6b6b6b6b RBX: ffff903959b56b90 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000270024 RDI: ffff9036e2adc840 RBP: ffff9036e2adc848 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9036e2adc840 R13: 0000000000000015 R14: ffff9039a419ccf8 R15: ffff90395d605840 FS: 00007fc47e1e1000(0000) GS:ffff9039ad200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6a776f7d40 CR3: 00000003d9e4e002 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fix this by making btrfs_find_all_roots_safe() set *roots to NULL after it frees the ulist. Fixes: 8da6d581 ("Btrfs: added btrfs_find_all_roots()") CC: stable@vger.kernel.org # 4.4+ Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Signed-off-by:
Filipe Manana <fdmanana@suse.com> Reviewed-by:
-
Hans de Goede authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 5cacc6f5 upstream. The RT5670_PWR_ANLG1 register has 3 bits to select the LDO voltage, so the correct mask is 0x7 not 0x3. Because of this wrong mask we were programming the ldo bits to a setting of binary 001 (0x05 & 0x03) instead of binary 101 when moving to SND_SOC_BIAS_PREPARE. According to the datasheet 001 is a reserved value, so no idea what it did, since the driver was working fine before I guess we got lucky and it does something which is ok. Fixes: 5e8351de ("ASoC: add RT5670 CODEC driver") Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200628155231.71089-3-hdegoede@redhat.comSigned-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 60379ba0 upstream. snd_info_get_line() has a sanity check of NULL buffer -- both buffer itself being NULL and buffer->buffer being NULL. Basically both checks are valid and necessary, but the problem is that it's with snd_BUG_ON() macro that triggers WARN_ON(). The latter condition (NULL buffer->buffer) can be met arbitrarily by user since the buffer is allocated at the first write, so it means that user can trigger WARN_ON() at will. This patch addresses it by simply moving buffer->buffer NULL check out of snd_BUG_ON() so that spurious WARNING is no longer triggered. Reported-by: syzbot+e42d0746c3c3699b6061@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200717084023.5928-1-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Oleg Nesterov authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit fe5ed7ab upstream. If a tracee is uprobed and it hits int3 inserted by debugger, handle_swbp() does send_sig(SIGTRAP, current, 0) which means si_code == SI_USER. This used to work when this code was written, but then GDB started to validate si_code and now it simply can't use breakpoints if the tracee has an active uprobe: # cat test.c void unused_func(void) { } int main(void) { return 0; } # gcc -g test.c -o test # perf probe -x ./test -a unused_func # perf record -e probe_test:unused_func gdb ./test -ex run GNU gdb (GDB) 10.0.50.20200714-git ... Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff7ddf909 in dl_main () from /lib64/ld-linux-x86-64.so.2 (gdb) The tracee hits the internal breakpoint inserted by GDB to monitor shared library events but GDB misinterprets this SIGTRAP and reports a signal. Change handle_swbp() to use force_sig(SIGTRAP), this matches do_int3_user() and fixes the problem. This is the minimal fix for -stable, arch/x86/kernel/uprobes.c is equally wrong; it should use send_sigtrap(TRAP_TRACE) instead of send_sig(SIGTRAP), but this doesn't confuse GDB and needs another x86-specific patch. Reported-by:
Aaron Merey <amerey@redhat.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200723154420.GA32043@redhat.comSigned-off-by:
-
Jiri Olsa authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 2aeb1883 upstream. We're missing ctx lock when iterating children siblings within the perf_read path for group reading. Following race and crash can happen: User space doing read syscall on event group leader: T1: perf_read lock event->ctx->mutex perf_read_group lock leader->child_mutex __perf_read_group_add(child) list_for_each_entry(sub, &leader->sibling_list, group_entry) ----> sub might be invalid at this point, because it could get removed via perf_event_exit_task_context in T2 Child exiting and cleaning up its events: T2: perf_event_exit_task_context lock ctx->mutex list_for_each_entry_safe(child_event, next, &child_ctx->event_list,... perf_event_exit_event(child) lock ctx->lock perf_group_detach(child) unlock ctx->lock ----> child is removed from sibling_list without any sync with T1 path above ... free_event(child) Before the child is removed from the leader's child_list, (and thus is omitted from perf_read_group processing), we need to ensure that perf_read_group touches child's siblings under its ctx->lock. Peter further notes: | One additional note; this bug got exposed by commit: | | ba5213ae ("perf/core: Correct event creation with PERF_FORMAT_GROUP") | | which made it possible to actually trigger this code-path. Tested-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: ba5213ae ("perf/core: Correct event creation with PERF_FORMAT_GROUP") Link: http://lkml.kernel.org/r/20170720141455.2106-1-jolsa@kernel.orgSigned-off-by:
-
Olga Kornievskaia authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 65caafd0 upstream. Reverting commit d03727b2 "NFSv4 fix CLOSE not waiting for direct IO compeletion". This patch made it so that fput() by calling inode_dio_done() in nfs_file_release() would wait uninterruptably for any outstanding directIO to the file (but that wait on IO should be killable). The problem the patch was also trying to address was REMOVE returning ERR_ACCESS because the file is still opened, is supposed to be resolved by server returning ERR_FILE_OPEN and not ERR_ACCESS. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Ben Skeggs authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 0156e76d ] Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Tom Rix authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 28b18e4e ] clang static analysis flags this garbage return drivers/net/ethernet/marvell/sky2.c:208:2: warning: Undefined or garbage value returned to caller [core.uninitialized.UndefReturn] return v; ^~~~~~~~ static inline u16 gm_phy_read( ... { u16 v; __gm_phy_read(hw, port, reg, &v); return v; } __gm_phy_read can return without setting v. So handle similar to skge.c's gm_phy_read, initialize v. Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Xie He authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 9dc829a1 ] When this driver transmits data, first this driver will remove a pseudo header of 1 byte, then the lapb module will prepend the LAPB header of 2 or 3 bytes, then this driver will prepend a length field of 2 bytes, then the underlying Ethernet device will prepend its own header. So, the header length required should be: -1 + 3 + 2 + "the header length needed by the underlying device". This patch fixes kernel panic when this driver is used with AF_PACKET SOCK_DGRAM sockets. Signed-off-by:
Xie He <xie.he.0141@gmail.com> Signed-off-by:
-
Max Filippov authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 0d5ab144 ] Increment *pos in the cpuinfo_op.next to fix the following warning triggered by cat /proc/cpuinfo: seq_file: buggy .next function c_next did not update position index Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Max Filippov authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 73f99413 ] Building xtensa kernel with gcc-10 produces the following warnings: arch/xtensa/kernel/xtensa_ksyms.c:90:15: warning: conflicting types for built-in function ‘__sync_fetch_and_and_4’; expected ‘unsigned int(volatile void *, unsigned int)’ [-Wbuiltin-declaration-mismatch] arch/xtensa/kernel/xtensa_ksyms.c:96:15: warning: conflicting types for built-in function ‘__sync_fetch_and_or_4’; expected ‘unsigned int(volatile void *, unsigned int)’ [-Wbuiltin-declaration-mismatch] Fix declarations of these functions to avoid the warning. Signed-off-by:
-
Tom Rix authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 5aee52c4 ] clang static analysis flags several null function pointer problems. drivers/scsi/scsi_transport_spi.c:374:1: warning: Called function pointer is null (null dereference) [core.CallAndMessage] spi_transport_max_attr(offset, "%d\n"); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reviewing the store_spi_store_max macro if (i->f->set_##field) return -EINVAL; should be if (!i->f->set_##field) return -EINVAL; Link: https://lore.kernel.org/r/20200627133242.21618-1-trix@redhat.comReviewed-by:
James Bottomley <jejb@linux.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Markus Theil authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 0b467b63 ] Without this patch, eapol frames cannot be received in mesh mode, when 802.1X should be used. Initially only a MGTK is defined, which is found and set as rx->key, when there are no other keys set. ieee80211_drop_unencrypted would then drop these eapol frames, as they are data frames without encryption and there exists some rx->key. Fix this by differentiating between mesh eapol frames and other data frames with existing rx->key. Allow mesh mesh eapol frames only if they are for our vif address. With this patch in-place, ieee80211_rx_h_mesh_fwding continues after the ieee80211_drop_unencrypted check and notices, that these eapol frames have to be delivered locally, as they should. Signed-off-by:
Markus Theil <markus.theil@tu-ilmenau.de> Link: https://lore.kernel.org/r/20200625104214.50319-1-markus.theil@tu-ilmenau.de [small code cleanups] Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Jacky Hu authored
BugLink: https://bugs.launchpad.net/bugs/1889928 [ Upstream commit 69339d08 ] uart0_pins is defined as: static const unsigned uart0_pins[] = {135, 136, 137, 138, 139}; which npins is wronly specified as 9 later { .name = "uart0", .pins = uart0_pins, .npins = 9, }, npins should be 5 instead of 9 according to the definition. Signed-off-by:
Jacky Hu <hengqing.hu@gmail.com> Link: https://lore.kernel.org/r/20200616015024.287683-1-hengqing.hu@gmail.comSigned-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Kamal Mostafa authored
BugLink: https://bugs.launchpad.net/bugs/1888690 Ignore: yes Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1888690Signed-off-by:
-
Vincent Guittot authored
BugLink: https://bugs.launchpad.net/bugs/1888690 commit 01cfcde9 upstream. task_h_load() can return 0 in some situations like running stress-ng mmapfork, which forks thousands of threads, in a sched group on a 224 cores system. The load balance doesn't handle this correctly because env->imbalance never decreases and it will stop pulling tasks only after reaching loop_max, which can be equal to the number of running tasks of the cfs. Make sure that imbalance will be decreased by at least 1. misfit task is the other feature that doesn't handle correctly such situation although it's probably more difficult to face the problem because of the smaller number of CPUs and running tasks on heterogenous system. We can't simply ensure that task_h_load() returns at least one because it would imply to handle underflow in other places. Signed-off-by:
Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by:
Valentin Schneider <valentin.schneider@arm.com> Reviewed-by:
Dietmar Eggemann <dietmar.eggemann@arm.com> Tested-by:
-
Michał Mirosław authored
BugLink: https://bugs.launchpad.net/bugs/1888690 commit b037d60a upstream. Uninterruptible context is not needed in the driver and causes lockdep warning because of mutex taken in of_alias_get_id(). Convert the lock to mutex to avoid the issue. Cc: stable@vger.kernel.org Fixes: 099343c6 ("ARM: at91: atmel-ssc: add device tree support") Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/50f0d7fa107f318296afb49477c3571e4d6978c5.1592998403.git.mirq-linux@rere.qmqm.plSigned-off-by:
-
Krzysztof Kozlowski authored
BugLink: https://bugs.launchpad.net/bugs/1888690 commit f5e5677c upstream. NULL pointer exception happens occasionally on serial output initiated by login timeout. This was reproduced only if kernel was built with significant debugging options and EDMA driver is used with serial console. col-vf50 login: root Password: Login timed out after 60 seconds. Unable to handle kernel NULL pointer dereference at virtual address 00000044 Internal error: Oops: 5 [#1] ARM CPU: 0 PID: 157 Comm: login Not tainted 5.7.0-next-20200610-dirty #4 Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) (fsl_edma_tx_handler) from [<8016eb10>] (__handle_irq_event_percpu+0x64/0x304) (__handle_irq_event_percpu) from [<8016eddc>] (handle_irq_event_percpu+0x2c/0x7c) (handle_irq_event_percpu) from [<8016ee64>] (handle_irq_event+0x38/0x5c) (handle_irq_event) from [<801729e4>] (handle_fasteoi_irq+0xa4/0x160) (handle_fasteoi_irq) from [<8016ddcc>] (generic_handle_irq+0x34/0x44) (generic_handle_irq) from [<8016e40c>] (__handle_domain_irq+0x54/0xa8) (__handle_domain_irq) from [<80508bc8>] (gic_handle_irq+0x4c/0x80) (gic_handle_irq) from [<80100af0>] (__irq_svc+0x70/0x98) Exception stack(0x8459fe80 to 0x8459fec8) fe80: 72286b00 e3359f64 00000001 0000412d a0070013 85c98840 85c98840 a0070013 fea0: 8054e0d4 00000000 00000002 00000000 00000002 8459fed0 8081fbe8 8081fbec fec0: 60070013 ffffffff (__irq_svc) from [<8081fbec>] (_raw_spin_unlock_irqrestore+0x30/0x58) (_raw_spin_unlock_irqrestore) from [<8056cb48>] (uart_flush_buffer+0x88/0xf8) (uart_flush_buffer) from [<80554e60>] (tty_ldisc_hangup+0x38/0x1ac) (tty_ldisc_hangup) from [<8054c7f4>] (__tty_hangup+0x158/0x2bc) (__tty_hangup) from [<80557b90>] (disassociate_ctty.part.1+0x30/0x23c) (disassociate_ctty.part.1) from [<8011fc18>] (do_exit+0x580/0xba0) (do_exit) from [<801214f8>] (do_group_exit+0x3c/0xb4) (do_group_exit) from [<80121580>] (__wake_up_parent+0x0/0x14) Issue looks like race condition between interrupt handler fsl_edma_tx_handler() (called as result of fsl_edma_xfer_desc()) and terminating the transfer with fsl_edma_terminate_all(). The fsl_edma_tx_handler() handles interrupt for a transfer with already freed edesc and idle==true. Fixes: d6be34fb ("dma: Add Freescale eDMA engine driver support") Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
Robin Gong <yibin.gong@nxp.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1591877861-28156-2-git-send-email-krzk@kernel.orgSigned-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Vishwas M authored
BugLink: https://bugs.launchpad.net/bugs/1888690 commit 14b0e83d upstream. This patch fixes a bug which does not let FAN mode to be changed from sysfs(pwm1_enable). i.e pwm1_enable can not be set to 3, it will always remain at 0. This is caused because the device driver handles the result of "read_u8_from_i2c(client, REG_FAN_CONF1, &conf_reg)" incorrectly. The driver thinks an error has occurred if the (result != 0). This has been fixed by changing the condition to (result < 0). Signed-off-by:
Vishwas M <vishwas.reddy.vr@gmail.com> Link: https://lore.kernel.org/r/20200707142747.118414-1-vishwas.reddy.vr@gmail.com Fixes: 9df7305b ("hwmon: Add driver for SMSC EMC2103 temperature monitor and fan controller") Cc: stable@vger.kernel.org Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Huacai Chen authored
BugLink: https://bugs.launchpad.net/bugs/1888690 Commit ed26aacf ("mips: Add udelay lpj numbers adjustment") has backported to 4.4~5.4, but the "struct cpufreq_freqs" (and also the cpufreq notifier machanism) of 4.4~4.19 are different from the upstream kernel. These differences cause build errors, and this patch can fix the build. Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Stable <stable@vger.kernel.org> # 4.4/4.9/4.14/4.19 Signed-off-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
-
Esben Haabendal authored
BugLink: https://bugs.launchpad.net/bugs/1888690 commit bf12fdf0 upstream. While e3a3c3a2 ("UIO: fix uio_pdrv_genirq with device tree but no interrupt") added support for using uio_pdrv_genirq for devices without interrupt for device tree platforms, the removal of uio_pdrv in 26dac3c4 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead") broke the support for non device tree platforms. This change fixes this, so that uio_pdrv_genirq can be used without interrupt on all platforms. This still leaves the support that uio_pdrv had for custom interrupt handler lacking, as uio_pdrv_genirq does not handle it (yet). Fixes: 26dac3c4 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead") Signed-off-by:
Esben Haabendal <esben@geanix.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200701145659.3978-3-esben@geanix.comSigned-off-by:
-
David Pedersen authored
BugLink: https://bugs.launchpad.net/bugs/1888690 commit 17d51429 upstream. This fixes two finger trackpad scroll on the Lenovo XiaoXin Air 12. Without nomux, the trackpad behaves as if only one finger is present and moves the cursor when trying to scroll. Signed-off-by:
David Pedersen <limero1337@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200625133754.291325-1-limero1337@gmail.comSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Alexander Usyskin authored
BugLink: https://bugs.launchpad.net/bugs/1888690 commit e852c2c2 upstream. It's not needed to set driver to NULL in mei_cl_device_remove() which is bus_type remove() handler as this is done anyway in __device_release_driver(). Actually this is causing an endless loop in driver_detach() on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module. The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty. as the check is always true in __device_release_driver() if (dev->driver != drv) return; The non upstream patch is causing this behavior, titled: 'vfio -- release device lock before userspace requests' Nevertheless the fix is correct also for the upstream. Link: https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20180912085046.3401-2-apw@canonical.com/ Cc: <stable@vger.kernel.org> Cc: Andy Whitcroft <apw@canonical.com> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20200628225359.2185929-1-tomas.winkler@intel.comSigned-off-by:
-
Chirantan Ekbote authored
BugLink: https://bugs.launchpad.net/bugs/1888690 commit 31070f6c upstream. The ioctl encoding for this parameter is a long but the documentation says it should be an int and the kernel drivers expect it to be an int. If the fuse driver treats this as a long it might end up scribbling over the stack of a userspace process that only allocated enough space for an int. This was previously discussed in [1] and a patch for fuse was proposed in [2]. From what I can tell the patch in [2] was nacked in favor of adding new, "fixed" ioctls and using those from userspace. However there is still no "fixed" version of these ioctls and the fact is that it's sometimes infeasible to change all userspace to use the new one. Handling the ioctls specially in the fuse driver seems like the most pragmatic way for fuse servers to support them without causing crashes in userspace applications that call them. [1]: https://lore.kernel.org/linux-fsdevel/20131126200559.GH20559@hall.aurel32.net/T/ [2]: https://sourceforge.net/p/fuse/mailman/message/31771759/Signed-off-by:
Chirantan Ekbote <chirantan@chromium.org> Fixes: 59efec7b ("fuse: implement ioctl support") Cc: <stable@vger.kernel.org> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
