commit 7a1dbe97cc4fdc6099430de4b00d64d2aa20f30e Author: Greg Kroah-Hartman Date: Sat May 22 10:38:30 2021 +0200 Linux 4.4.269 Link: https://lore.kernel.org/r/20210520092102.149300807@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20210520152221.547672231@linuxfoundation.org Tested-by: Guenter Roeck Tested-by: Jason Self Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit 0e0a7106082f6277fdd62a79d893092e240a57a8 Author: Colin Ian King Date: Fri May 7 19:30:41 2021 +0100 iio: tsl2583: Fix division by a zero lux_val commit af0e1871d79cfbb91f732d2c6fa7558e45c31038 upstream. The lux_val returned from tsl2583_get_lux can potentially be zero, so check for this to avoid a division by zero and an overflowed gain_trim_val. Fixes clang scan-build warning: drivers/iio/light/tsl2583.c:345:40: warning: Either the condition 'lux_val<0' is redundant or there is division by zero at line 345. [zerodivcond] Fixes: ac4f6eee8fe8 ("staging: iio: TAOS tsl258x: Device driver") Signed-off-by: Colin Ian King Cc: Signed-off-by: Jonathan Cameron [iwamatsu: Change file path.] Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit d744ccbfb5aeb451617cc6b73a3fa0a102db0c2c Author: Christophe JAILLET Date: Wed May 12 11:08:14 2021 +0300 xhci: Do not use GFP_KERNEL in (potentially) atomic context commit dda32c00c9a0fa103b5d54ef72c477b7aa993679 upstream. 'xhci_urb_enqueue()' is passed a 'mem_flags' argument, because "URBs may be submitted in interrupt context" (see comment related to 'usb_submit_urb()' in 'drivers/usb/core/urb.c') So this flag should be used in all the calling chain. Up to now, 'xhci_check_maxpacket()' which is only called from 'xhci_urb_enqueue()', uses GFP_KERNEL. Be safe and pass the mem_flags to this function as well. Fixes: ddba5cd0aeff ("xhci: Use command structures when queuing commands on the command ring") Cc: Signed-off-by: Christophe JAILLET Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-4-mathias.nyman@linux.intel.com [iwamatsu: Adjust context] Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit c5534ba6d4a6bec37ee7849b3c32f0ec31aba691 Author: Eric Dumazet Date: Wed Mar 31 14:38:11 2021 -0700 ipv6: remove extra dev_hold() for fallback tunnels commit 0d7a7b2014b1a499a0fe24c9f3063d7856b5aaaf upstream. My previous commits added a dev_hold() in tunnels ndo_init(), but forgot to remove it from special functions setting up fallback tunnels. Fallback tunnels do call their respective ndo_init() This leads to various reports like : unregister_netdevice: waiting for ip6gre0 to become free. Usage count = 2 Fixes: 48bb5697269a ("ip6_tunnel: sit: proper dev_{hold|put} in ndo_[un]init methods") Fixes: 6289a98f0817 ("sit: proper dev_{hold|put} in ndo_[un]init methods") Fixes: 40cb881b5aaa ("ip6_vti: proper dev_{hold|put} in ndo_[un]init methods") Fixes: 7f700334be9a ("ip6_gre: proper dev_{hold|put} in ndo_[un]init methods") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2ddf83904cdb37e8077c844f77f4d2d86ff0b52e Author: Eric Dumazet Date: Mon Mar 29 23:45:51 2021 -0700 ip6_tunnel: sit: proper dev_{hold|put} in ndo_[un]init methods commit 48bb5697269a7cbe5194dbb044dc38c517e34c58 upstream. Same reasons than for the previous commits : 6289a98f0817 ("sit: proper dev_{hold|put} in ndo_[un]init methods") 40cb881b5aaa ("ip6_vti: proper dev_{hold|put} in ndo_[un]init methods") 7f700334be9a ("ip6_gre: proper dev_{hold|put} in ndo_[un]init methods") After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger a warning [1] Issue here is that: - all dev_put() should be paired with a corresponding prior dev_hold(). - A driver doing a dev_put() in its ndo_uninit() MUST also do a dev_hold() in its ndo_init(), only when ndo_init() is returning 0. Otherwise, register_netdevice() would call ndo_uninit() in its error path and release a refcount too soon. [1] WARNING: CPU: 1 PID: 21059 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Modules linked in: CPU: 1 PID: 21059 Comm: syz-executor.4 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Code: 1d 6a 5a e8 09 31 ff 89 de e8 8d 1a ab fd 84 db 75 e0 e8 d4 13 ab fd 48 c7 c7 a0 e1 c1 89 c6 05 4a 5a e8 09 01 e8 2e 36 fb 04 <0f> 0b eb c4 e8 b8 13 ab fd 0f b6 1d 39 5a e8 09 31 ff 89 de e8 58 RSP: 0018:ffffc900025aefe8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815c51f5 RDI: fffff520004b5def RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815bdf8e R11: 0000000000000000 R12: ffff888023488568 R13: ffff8880254e9000 R14: 00000000dfd82cfd R15: ffff88802ee2d7c0 FS: 00007f13bc590700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0943e74000 CR3: 0000000025273000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_dec include/linux/refcount.h:344 [inline] refcount_dec include/linux/refcount.h:359 [inline] dev_put include/linux/netdevice.h:4135 [inline] ip6_tnl_dev_uninit+0x370/0x3d0 net/ipv6/ip6_tunnel.c:387 register_netdevice+0xadf/0x1500 net/core/dev.c:10308 ip6_tnl_create2+0x1b5/0x400 net/ipv6/ip6_tunnel.c:263 ip6_tnl_newlink+0x312/0x580 net/ipv6/ip6_tunnel.c:2052 __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3443 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 919067cc845f ("net: add CONFIG_PCPU_DEV_REFCNT") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1316d11c8730dcff7f8e59127be62868639928d7 Author: Eric Dumazet Date: Mon Mar 29 12:25:22 2021 -0700 sit: proper dev_{hold|put} in ndo_[un]init methods commit 6289a98f0817a4a457750d6345e754838eae9439 upstream. After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger a warning [1] Issue here is that: - all dev_put() should be paired with a corresponding prior dev_hold(). - A driver doing a dev_put() in its ndo_uninit() MUST also do a dev_hold() in its ndo_init(), only when ndo_init() is returning 0. Otherwise, register_netdevice() would call ndo_uninit() in its error path and release a refcount too soon. Fixes: 919067cc845f ("net: add CONFIG_PCPU_DEV_REFCNT") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 40027f114cc1feaee2f7224567e5466ba00edb91 Author: Hui Wang Date: Tue May 4 15:39:17 2021 +0800 ALSA: hda: generic: change the DAC ctl name for LO+SPK or LO+HP [ Upstream commit f48652bbe3ae62ba2835a396b7e01f063e51c4cd ] Without this change, the DAC ctl's name could be changed only when the machine has both Speaker and Headphone, but we met some machines which only has Lineout and Headhpone, and the Lineout and Headphone share the Audio Mixer0 and DAC0, the ctl's name is set to "Front". On most of machines, the "Front" is used for Speaker only or Lineout only, but on this machine it is shared by Lineout and Headphone, This introduces an issue in the pipewire and pulseaudio, suppose users want the Headphone to be on and the Speaker/Lineout to be off, they could turn off the "Front", this works on most of the machines, but on this machine, the "Front" couldn't be turned off otherwise the headphone will be off too. Here we do some change to let the ctl's name change to "Headphone+LO" on this machine, and pipewire and pulseaudio already could handle "Headphone+LO" and "Speaker+LO". (https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/747) BugLink: http://bugs.launchpad.net/bugs/804178 Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20210504073917.22406-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit fffa02e229b87b94058ca2cc5a2b85b8938fd866 Author: Johannes Berg Date: Fri Mar 5 21:43:15 2021 +0100 um: Mark all kernel symbols as local [ Upstream commit d5027ca63e0e778b641cf23e3f5c6d6212cf412b ] Ritesh reported a bug [1] against UML, noting that it crashed on startup. The backtrace shows the following (heavily redacted): (gdb) bt ... #26 0x0000000060015b5d in sem_init () at ipc/sem.c:268 #27 0x00007f89906d92f7 in ?? () from /lib/x86_64-linux-gnu/libcom_err.so.2 #28 0x00007f8990ab8fb2 in call_init (...) at dl-init.c:72 ... #40 0x00007f89909bf3a6 in nss_load_library (...) at nsswitch.c:359 ... #44 0x00007f8990895e35 in _nss_compat_getgrnam_r (...) at nss_compat/compat-grp.c:486 #45 0x00007f8990968b85 in __getgrnam_r [...] #46 0x00007f89909d6b77 in grantpt [...] #47 0x00007f8990a9394e in __GI_openpty [...] #48 0x00000000604a1f65 in openpty_cb (...) at arch/um/os-Linux/sigio.c:407 #49 0x00000000604a58d0 in start_idle_thread (...) at arch/um/os-Linux/skas/process.c:598 #50 0x0000000060004a3d in start_uml () at arch/um/kernel/skas/process.c:45 #51 0x00000000600047b2 in linux_main (...) at arch/um/kernel/um_arch.c:334 #52 0x000000006000574f in main (...) at arch/um/os-Linux/main.c:144 indicating that the UML function openpty_cb() calls openpty(), which internally calls __getgrnam_r(), which causes the nsswitch machinery to get started. This loads, through lots of indirection that I snipped, the libcom_err.so.2 library, which (in an unknown function, "??") calls sem_init(). Now, of course it wants to get libpthread's sem_init(), since it's linked against libpthread. However, the dynamic linker looks up that symbol against the binary first, and gets the kernel's sem_init(). Hajime Tazaki noted that "objcopy -L" can localize a symbol, so the dynamic linker wouldn't do the lookup this way. I tried, but for some reason that didn't seem to work. Doing the same thing in the linker script instead does seem to work, though I cannot entirely explain - it *also* works if I just add "VERSION { { global: *; }; }" instead, indicating that something else is happening that I don't really understand. It may be that explicitly doing that marks them with some kind of empty version, and that's different from the default. Explicitly marking them with a version breaks kallsyms, so that doesn't seem to be possible. Marking all the symbols as local seems correct, and does seem to address the issue, so do that. Also do it for static link, nsswitch libraries could still be loaded there. [1] https://bugs.debian.org/983379 Reported-by: Ritesh Raj Sarraf Signed-off-by: Johannes Berg Acked-By: Anton Ivanov Tested-By: Ritesh Raj Sarraf Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit d81519a05c92393cdd2b5a9a83993fa1fb2692b0 Author: Feilong Lin Date: Thu Mar 25 15:26:00 2021 +0800 ACPI / hotplug / PCI: Fix reference count leak in enable_slot() [ Upstream commit 3bbfd319034ddce59e023837a4aa11439460509b ] In enable_slot(), if pci_get_slot() returns NULL, we clear the SLOT_ENABLED flag. When pci_get_slot() finds a device, it increments the device's reference count. In this case, we did not call pci_dev_put() to decrement the reference count, so the memory of the device (struct pci_dev type) will eventually leak. Call pci_dev_put() to decrement its reference count when pci_get_slot() returns a PCI device. Link: https://lore.kernel.org/r/b411af88-5049-a1c6-83ac-d104a1f429be@huawei.com Signed-off-by: Feilong Lin Signed-off-by: Zhiqiang Liu Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit dac2e1cca82145613ccc9072b6dcd723d333f860 Author: Arnd Bergmann Date: Mon Mar 22 17:44:29 2021 +0100 isdn: capi: fix mismatched prototypes commit 5ee7d4c7fbc9d3119a20b1c77d34003d1f82ac26 upstream. gcc-11 complains about a prototype declaration that is different from the function definition: drivers/isdn/capi/kcapi.c:724:44: error: argument 2 of type ‘u8 *’ {aka ‘unsigned char *’} declared as a pointer [-Werror=array-parameter=] 724 | u16 capi20_get_manufacturer(u32 contr, u8 *buf) | ~~~~^~~ In file included from drivers/isdn/capi/kcapi.c:13: drivers/isdn/capi/kcapi.h:62:43: note: previously declared as an array ‘u8[64]’ {aka ‘unsigned char[64]’} 62 | u16 capi20_get_manufacturer(u32 contr, u8 buf[CAPI_MANUFACTURER_LEN]); | ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/isdn/capi/kcapi.c:790:38: error: argument 2 of type ‘u8 *’ {aka ‘unsigned char *’} declared as a pointer [-Werror=array-parameter=] 790 | u16 capi20_get_serial(u32 contr, u8 *serial) | ~~~~^~~~~~ In file included from drivers/isdn/capi/kcapi.c:13: drivers/isdn/capi/kcapi.h:64:37: note: previously declared as an array ‘u8[8]’ {aka ‘unsigned char[8]’} 64 | u16 capi20_get_serial(u32 contr, u8 serial[CAPI_SERIAL_LEN]); | ~~~^~~~~~~~~~~~~~~~~~~~~~~ Change the definition to make them match. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 993103e7b4fb6e38cf07538c52e32b60993f0f52 Author: Kaixu Xia Date: Wed Nov 4 13:24:04 2020 +0800 cxgb4: Fix the -Wmisleading-indentation warning commit ea8146c6845799142aa4ee2660741c215e340cdf upstream. Fix the gcc warning: drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c:2673:9: warning: this 'for' clause does not guard... [-Wmisleading-indentation] 2673 | for (i = 0; i < n; ++i) \ Reported-by: Tosk Robot Signed-off-by: Kaixu Xia Link: https://lore.kernel.org/r/1604467444-23043-1-git-send-email-kaixuxia@tencent.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9af1581d4976349a7917b59657f83e3bb2ec640c Author: Arnd Bergmann Date: Mon Mar 22 17:42:26 2021 +0100 usb: sl811-hcd: improve misleading indentation commit 8460f6003a1d2633737b89c4f69d6f4c0c7c65a3 upstream. gcc-11 now warns about a confusingly indented code block: drivers/usb/host/sl811-hcd.c: In function ‘sl811h_hub_control’: drivers/usb/host/sl811-hcd.c:1291:9: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation] 1291 | if (*(u16*)(buf+2)) /* only if wPortChange is interesting */ | ^~ drivers/usb/host/sl811-hcd.c:1295:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 1295 | break; Rewrite this to use a single if() block with the __is_defined() macro. Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210322164244.827589-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 015106b310baecf3e68fe29979698934ed8206b0 Author: Arnd Bergmann Date: Mon Mar 22 17:43:03 2021 +0100 kgdb: fix gcc-11 warning on indentation commit 40cc3a80bb42587db1e6ae21d6f3090582d33e89 upstream. gcc-11 starts warning about misleading indentation inside of macros: drivers/misc/kgdbts.c: In function ‘kgdbts_break_test’: drivers/misc/kgdbts.c:103:9: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation] 103 | if (verbose > 1) \ | ^~ drivers/misc/kgdbts.c:200:9: note: in expansion of macro ‘v2printk’ 200 | v2printk("kgdbts: breakpoint complete\n"); | ^~~~~~~~ drivers/misc/kgdbts.c:105:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 105 | touch_nmi_watchdog(); \ | ^~~~~~~~~~~~~~~~~~ The code looks correct to me, so just reindent it for readability. Fixes: e8d31c204e36 ("kgdb: add kgdb internal test suite") Acked-by: Daniel Thompson Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210322164308.827846-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 064da98e700acbec4c5c2d0848025ae5cf638d6a Author: Arnd Bergmann Date: Mon Mar 22 17:45:36 2021 +0100 x86/msr: Fix wr/rdmsr_safe_regs_on_cpu() prototypes commit 396a66aa1172ef2b78c21651f59b40b87b2e5e1e upstream. gcc-11 warns about mismatched prototypes here: arch/x86/lib/msr-smp.c:255:51: error: argument 2 of type ‘u32 *’ {aka ‘unsigned int *’} declared as a pointer [-Werror=array-parameter=] 255 | int rdmsr_safe_regs_on_cpu(unsigned int cpu, u32 *regs) | ~~~~~^~~~ arch/x86/include/asm/msr.h:347:50: note: previously declared as an array ‘u32[8]’ {aka ‘unsigned int[8]’} GCC is right here - fix up the types. [ mingo: Twiddled the changelog. ] Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210322164541.912261-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5a5aa16d8445d2da1fda36a78923cdabce5589a8 Author: Greg Kroah-Hartman Date: Mon Apr 5 11:48:52 2021 +0200 kobject_uevent: remove warning in init_uevent_argv() commit b4104180a2efb85f55e1ba1407885c9421970338 upstream. syzbot can trigger the WARN() in init_uevent_argv() which isn't the nicest as the code does properly recover and handle the error. So change the WARN() call to pr_warn() and provide some more information on what the buffer size that was needed. Link: https://lore.kernel.org/r/20201107082206.GA19079@kroah.com Cc: "Rafael J. Wysocki" Cc: linux-kernel@vger.kernel.org Reported-by: syzbot+92340f7b2b4789907fdb@syzkaller.appspotmail.com Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20210405094852.1348499-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 0c0f93fbd20276d65ae0581edfcdc93579aa1dc7 Author: Mikulas Patocka Date: Fri Mar 26 14:32:32 2021 -0400 dm ioctl: fix out of bounds array access when no devices commit 4edbe1d7bcffcd6269f3b5eb63f710393ff2ec7a upstream. If there are not any dm devices, we need to zero the "dev" argument in the first structure dm_name_list. However, this can cause out of bounds write, because the "needed" variable is zero and len may be less than eight. Fix this bug by reporting DM_BUFFER_FULL_FLAG if the result buffer is too small to hold the "nl->dev" value. Signed-off-by: Mikulas Patocka Reported-by: Dan Carpenter Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer [iwamatsu: Adjust context] Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit f763e65c10480e35d04f0b8d7d7e4646a1a593f1 Author: Lukasz Luba Date: Thu Apr 22 16:36:22 2021 +0100 thermal/core/fair share: Lock the thermal zone while looping over instances commit fef05776eb02238dcad8d5514e666a42572c3f32 upstream. The tz->lock must be hold during the looping over the instances in that thermal zone. This lock was missing in the governor code since the beginning, so it's hard to point into a particular commit. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Lukasz Luba Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210422153624.6074-2-lukasz.luba@arm.com Signed-off-by: Greg Kroah-Hartman commit 7bea311f06e165ea6abe538e7b6e04c5f2d51cf2 Author: Maciej W. Rozycki Date: Wed Mar 10 13:03:14 2021 +0100 FDDI: defxx: Make MMIO the configuration default except for EISA commit 193ced4a79599352d63cb8c9e2f0c6043106eb6a upstream. Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. The default kernel configuration choice for the defxx driver is the use of I/O ports rather than MMIO for PCI and EISA systems. It may have made sense as a conservative backwards compatible choice back when MMIO operation support was added to the driver as a part of TURBOchannel bus support. However nowadays this configuration choice makes the driver unusable with systems that do not implement I/O transactions for PCIe. Make DEFXX_MMIO the configuration default then, except where configured for EISA. This exception is because an EISA adapter can have its MMIO decoding disabled with ECU (EISA Configuration Utility) and therefore not available with the resource allocation infrastructure we implement, while port I/O is always readily available as it uses slot-specific addressing, directly mapped to the slot an option card has been placed in and handled with our EISA bus support core. Conversely a kernel that supports modern systems which may not have I/O transactions implemented for PCIe will usually not be expected to handle legacy EISA systems. The change of the default will make it easier for people, including but not limited to distribution packagers, to make a working choice for the driver. Update the option description accordingly and while at it replace the potentially ambiguous PIO acronym with IOP for "port I/O" vs "I/O ports" according to our nomenclature used elsewhere. Signed-off-by: Maciej W. Rozycki Fixes: e89a2cfb7d7b ("[TC] defxx: TURBOchannel support") Cc: stable@vger.kernel.org # v2.6.21+ Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5822103eb6af0acc30b06f545078666781044172 Author: Thomas Gleixner Date: Wed May 5 23:48:17 2021 +0200 KVM: x86: Cancel pvclock_gtod_work on module removal commit 594b27e677b35f9734b1969d175ebc6146741109 upstream. Nothing prevents the following: pvclock_gtod_notify() queue_work(system_long_wq, &pvclock_gtod_work); ... remove_module(kvm); ... work_queue_run() pvclock_gtod_work() <- UAF Ditto for any other operation on that workqueue list head which touches pvclock_gtod_work after module removal. Cancel the work in kvm_arch_exit() to prevent that. Fixes: 16e8d74d2da9 ("KVM: x86: notifier for clocksource changes") Signed-off-by: Thomas Gleixner Message-Id: <87czu4onry.ffs@nanos.tec.linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 4e4620fee76562b05cc1ae670817c8bbdf2d9eb4 Author: Chunfeng Yun Date: Wed May 12 10:07:38 2021 +0800 usb: core: hub: fix race condition about TRSMRCY of resume commit 975f94c7d6c306b833628baa9aec3f79db1eb3a1 upstream. This may happen if the port becomes resume status exactly when usb_port_resume() gets port status, it still need provide a TRSMCRY time before access the device. CC: Reported-by: Tianping Fang Acked-by: Alan Stern Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/20210512020738.52961-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit c4ed56cd72eed867603911d3d43a6eb593066666 Author: Phil Elwell Date: Thu May 6 12:22:00 2021 +0100 usb: dwc2: Fix gadget DMA unmap direction commit 75a41ce46bae6cbe7d3bb2584eb844291d642874 upstream. The dwc2 gadget support maps and unmaps DMA buffers as necessary. When mapping and unmapping it uses the direction of the endpoint to select the direction of the DMA transfer, but this fails for Control OUT transfers because the unmap occurs after the endpoint direction has been reversed for the status phase. A possible solution would be to unmap the buffer before the direction is changed, but a safer, less invasive fix is to remember the buffer direction independently of the endpoint direction. Fixes: fe0b94abcdf6 ("usb: dwc2: gadget: manage ep0 state in software") Acked-by: Minas Harutyunyan Cc: stable Signed-off-by: Phil Elwell Link: https://lore.kernel.org/r/20210506112200.2893922-1-phil@raspberrypi.com Signed-off-by: Greg Kroah-Hartman commit 72b08f62a6b657fa1c8fb5598e9cb1849dbfb9e5 Author: Maximilian Luz Date: Wed May 12 11:08:15 2021 +0300 usb: xhci: Increase timeout for HC halt commit ca09b1bea63ab83f4cca3a2ae8bc4f597ec28851 upstream. On some devices (specifically the SC8180x based Surface Pro X with QCOM04A6) HC halt / xhci_halt() times out during boot. Manually binding the xhci-hcd driver at some point later does not exhibit this behavior. To work around this, double XHCI_MAX_HALT_USEC, which also resolves this issue. Cc: Signed-off-by: Maximilian Luz Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210512080816.866037-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 39b6e6ca84ef2673ced6e71859cfa0107107ea65 Author: Christophe JAILLET Date: Thu May 6 22:39:10 2021 +0200 usb: fotg210-hcd: Fix an error message [ Upstream commit a60a34366e0d09ca002c966dd7c43a68c28b1f82 ] 'retval' is known to be -ENODEV here. This is a hard-coded default error code which is not useful in the error message. Moreover, another error message is printed at the end of the error handling path. The corresponding error code (-ENOMEM) is more informative. So remove simplify the first error message. While at it, also remove the useless initialization of 'retval'. Fixes: 7d50195f6c50 ("usb: host: Faraday fotg210-hcd driver") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/94531bcff98e46d4f9c20183a90b7f47f699126c.1620333419.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 51f2bc5cc8c8d6506d5bd257c71fd7451e1b7d43 Author: Phillip Lougher Date: Fri May 14 17:27:16 2021 -0700 squashfs: fix divide error in calculate_skip() commit d6e621de1fceb3b098ebf435ef7ea91ec4838a1a upstream. Sysbot has reported a "divide error" which has been identified as being caused by a corrupted file_size value within the file inode. This value has been corrupted to a much larger value than expected. Calculate_skip() is passed i_size_read(inode) >> msblk->block_log. Due to the file_size value corruption this overflows the int argument/variable in that function, leading to the divide error. This patch changes the function to use u64. This will accommodate any unexpectedly large values due to corruption. The value returned from calculate_skip() is clamped to be never more than SQUASHFS_CACHED_BLKS - 1, or 7. So file_size corruption does not lead to an unexpectedly large return result here. Link: https://lkml.kernel.org/r/20210507152618.9447-1-phillip@squashfs.org.uk Signed-off-by: Phillip Lougher Reported-by: Reported-by: Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8382b15864e5014261b4f36c2aa89723612ee058 Author: Michael Ellerman Date: Thu May 6 14:49:59 2021 +1000 powerpc/64s: Fix crashes when toggling entry flush barrier commit aec86b052df6541cc97c5fca44e5934cbea4963b upstream. The entry flush mitigation can be enabled/disabled at runtime via a debugfs file (entry_flush), which causes the kernel to patch itself to enable/disable the relevant mitigations. However depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are active. For example the following crash: sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20 Shows that we returned to userspace with a corrupted LR that points into the kernel, due to executing the partially patched call to the fallback entry flush (ie. we missed the LR restore). Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes, because none of the patching we do is to that code or anywhere in the vicinity. Fixes: f79643787e0a ("powerpc/64s: flush L1D on kernel entry") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210506044959.1298123-2-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit 7772ad465478eca423c32a75ebb02cfdf1ab54d3 Author: Vineet Gupta Date: Fri Apr 23 12:16:25 2021 -0700 ARC: entry: fix off-by-one error in syscall number validation commit 3433adc8bd09fc9f29b8baddf33b4ecd1ecd2cdc upstream. We have NR_syscall syscalls from [0 .. NR_syscall-1]. However the check for invalid syscall number is "> NR_syscall" as opposed to >=. This off-by-one error erronesously allows "NR_syscall" to be treated as valid syscall causeing out-of-bounds access into syscall-call table ensuing a crash (holes within syscall table have a invalid-entry handler but this is beyond the array implementing the table). This problem showed up on v5.6 kernel when testing glibc 2.33 (v5.10 kernel capable, includng faccessat2 syscall 439). The v5.6 kernel has NR_syscalls=439 (0 to 438). Due to the bug, 439 passed by glibc was not handled as -ENOSYS but processed leading to a crash. Link: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/48 Reported-by: Shahab Vahedi Cc: Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit d15fd53afac908af3b8ad5233aae8fdeb67acbc7 Author: Jia-Ju Bai Date: Thu May 6 18:04:38 2021 -0700 kernel: kexec_file: fix error return code of kexec_calculate_store_digests() [ Upstream commit 31d82c2c787d5cf65fedd35ebbc0c1bd95c1a679 ] When vzalloc() returns NULL to sha_regions, no error return code of kexec_calculate_store_digests() is assigned. To fix this bug, ret is assigned with -ENOMEM in this case. Link: https://lkml.kernel.org/r/20210309083904.24321-1-baijiaju1990@gmail.com Fixes: a43cac0d9dc2 ("kexec: split kexec_file syscall code to kexec_file.c") Signed-off-by: Jia-Ju Bai Reported-by: TOTE Robot Acked-by: Baoquan He Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ab079e85405922f19fe9a87f4657eab90e9dac06 Author: Miaohe Lin Date: Tue May 4 18:37:45 2021 -0700 ksm: fix potential missing rmap_item for stable_node [ Upstream commit c89a384e2551c692a9fe60d093fd7080f50afc51 ] When removing rmap_item from stable tree, STABLE_FLAG of rmap_item is cleared with head reserved. So the following scenario might happen: For ksm page with rmap_item1: cmp_and_merge_page stable_node->head = &migrate_nodes; remove_rmap_item_from_tree, but head still equal to stable_node; try_to_merge_with_ksm_page failed; return; For the same ksm page with rmap_item2, stable node migration succeed this time. The stable_node->head does not equal to migrate_nodes now. For ksm page with rmap_item1 again: cmp_and_merge_page stable_node->head != &migrate_nodes && rmap_item->head == stable_node return; We would miss the rmap_item for stable_node and might result in failed rmap_walk_ksm(). Fix this by set rmap_item->head to NULL when rmap_item is removed from stable tree. Link: https://lkml.kernel.org/r/20210330140228.45635-5-linmiaohe@huawei.com Fixes: 4146d2d673e8 ("ksm: make !merge_across_nodes migration safe") Signed-off-by: Miaohe Lin Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e30489b73de99e79fcb32165a0f522247d9fb3ae Author: Kees Cook Date: Sun May 2 22:06:07 2021 -0700 drm/radeon: Fix off-by-one power_state index heap overwrite [ Upstream commit 5bbf219328849e83878bddb7c226d8d42e84affc ] An out of bounds write happens when setting the default power state. KASAN sees this as: [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 ================================================================== BUG: KASAN: slab-out-of-bounds in radeon_atombios_parse_power_table_1_3+0x1837/0x1998 [radeon] Write of size 4 at addr ffff88810178d858 by task systemd-udevd/157 CPU: 0 PID: 157 Comm: systemd-udevd Not tainted 5.12.0-E620 #50 Hardware name: eMachines eMachines E620 /Nile , BIOS V1.03 09/30/2008 Call Trace: dump_stack+0xa5/0xe6 print_address_description.constprop.0+0x18/0x239 kasan_report+0x170/0x1a8 radeon_atombios_parse_power_table_1_3+0x1837/0x1998 [radeon] radeon_atombios_get_power_modes+0x144/0x1888 [radeon] radeon_pm_init+0x1019/0x1904 [radeon] rs690_init+0x76e/0x84a [radeon] radeon_device_init+0x1c1a/0x21e5 [radeon] radeon_driver_load_kms+0xf5/0x30b [radeon] drm_dev_register+0x255/0x4a0 [drm] radeon_pci_probe+0x246/0x2f6 [radeon] pci_device_probe+0x1aa/0x294 really_probe+0x30e/0x850 driver_probe_device+0xe6/0x135 device_driver_attach+0xc1/0xf8 __driver_attach+0x13f/0x146 bus_for_each_dev+0xfa/0x146 bus_add_driver+0x2b3/0x447 driver_register+0x242/0x2c1 do_one_initcall+0x149/0x2fd do_init_module+0x1ae/0x573 load_module+0x4dee/0x5cca __do_sys_finit_module+0xf1/0x140 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Without KASAN, this will manifest later when the kernel attempts to allocate memory that was stomped, since it collides with the inline slab freelist pointer: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 PID: 781 Comm: openrc-run.sh Tainted: G W 5.10.12-gentoo-E620 #2 Hardware name: eMachines eMachines E620 /Nile , BIOS V1.03 09/30/2008 RIP: 0010:kfree+0x115/0x230 Code: 89 c5 e8 75 ea ff ff 48 8b 00 0f ba e0 09 72 63 e8 1f f4 ff ff 41 89 c4 48 8b 45 00 0f ba e0 10 72 0a 48 8b 45 08 a8 01 75 02 <0f> 0b 44 89 e1 48 c7 c2 00 f0 ff ff be 06 00 00 00 48 d3 e2 48 c7 RSP: 0018:ffffb42f40267e10 EFLAGS: 00010246 RAX: ffffd61280ee8d88 RBX: 0000000000000004 RCX: 000000008010000d RDX: 4000000000000000 RSI: ffffffffba1360b0 RDI: ffffd61280ee8d80 RBP: ffffd61280ee8d80 R08: ffffffffb91bebdf R09: 0000000000000000 R10: ffff8fe2c1047ac8 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000100 FS: 00007fe80eff6b68(0000) GS:ffff8fe339c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe80eec7bc0 CR3: 0000000038012000 CR4: 00000000000006f0 Call Trace: __free_fdtable+0x16/0x1f put_files_struct+0x81/0x9b do_exit+0x433/0x94d do_group_exit+0xa6/0xa6 __x64_sys_exit_group+0xf/0xf do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fe80ef64bea Code: Unable to access opcode bytes at RIP 0x7fe80ef64bc0. RSP: 002b:00007ffdb1c47528 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fe80ef64bea RDX: 00007fe80ef64f60 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 00007fe80ee2c620 R11: 0000000000000246 R12: 00007fe80eff41e0 R13: 00000000ffffffff R14: 0000000000000024 R15: 00007fe80edf9cd0 Modules linked in: radeon(+) ath5k(+) snd_hda_codec_realtek ... Use a valid power_state index when initializing the "flags" and "misc" and "misc2" fields. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211537 Reported-by: Erhard F. Fixes: a48b9b4edb8b ("drm/radeon/kms/pm: add asic specific callbacks for getting power state (v2)") Fixes: 79daedc94281 ("drm/radeon/kms: minor pm cleanups") Signed-off-by: Kees Cook Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dc9d299c1a189930dc9501458ffcdad84c6ddf96 Author: Xin Long Date: Mon May 3 04:41:20 2021 +0800 sctp: fix a SCTP_MIB_CURRESTAB leak in sctp_sf_do_dupcook_b [ Upstream commit f282df0391267fb2b263da1cc3233aa6fb81defc ] Normally SCTP_MIB_CURRESTAB is always incremented once asoc enter into ESTABLISHED from the state < ESTABLISHED and decremented when the asoc is being deleted. However, in sctp_sf_do_dupcook_b(), the asoc's state can be changed to ESTABLISHED from the state >= ESTABLISHED where it shouldn't increment SCTP_MIB_CURRESTAB. Otherwise, one asoc may increment MIB_CURRESTAB multiple times but only decrement once at the end. I was able to reproduce it by using scapy to do the 4-way shakehands, after that I replayed the COOKIE-ECHO chunk with 'peer_vtag' field changed to different values, and SCTP_MIB_CURRESTAB was incremented multiple times and never went back to 0 even when the asoc was freed. This patch is to fix it by only incrementing SCTP_MIB_CURRESTAB when the state < ESTABLISHED in sctp_sf_do_dupcook_b(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Marcelo Ricardo Leitner Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5b5c74cf45077c49e69c2601e67d472e9944bc1b Author: Olga Kornievskaia Date: Wed Mar 31 15:30:25 2021 -0400 NFSv4.2 fix handling of sr_eof in SEEK's reply [ Upstream commit 73f5c88f521a630ea1628beb9c2d48a2e777a419 ] Currently the client ignores the value of the sr_eof of the SEEK operation. According to the spec, if the server didn't find the requested extent and reached the end of the file, the server would return sr_eof=true. In case the request for DATA and no data was found (ie in the middle of the hole), then the lseek expects that ENXIO would be returned. Fixes: 1c6dcbe5ceff8 ("NFS: Implement SEEK") Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 0c5ccd5e2a2e291774618c24c459fa397fd1b7da Author: Nikola Livic Date: Mon Mar 29 11:56:49 2021 +0300 pNFS/flexfiles: fix incorrect size check in decode_nfs_fh() [ Upstream commit ed34695e15aba74f45247f1ee2cf7e09d449f925 ] We (adam zabrocki, alexander matrosov, alexander tereshkin, maksym bazalii) observed the check: if (fh->size > sizeof(struct nfs_fh)) should not use the size of the nfs_fh struct which includes an extra two bytes from the size field. struct nfs_fh { unsigned short size; unsigned char data[NFS_MAXFHSIZE]; } but should determine the size from data[NFS_MAXFHSIZE] so the memcpy will not write 2 bytes beyond destination. The proposed fix is to compare against the NFS_MAXFHSIZE directly, as is done elsewhere in fs code base. Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Signed-off-by: Nikola Livic Signed-off-by: Dan Carpenter Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit cb12c649f33a2e9b19e15887a2e5d605656b7e4a Author: Trond Myklebust Date: Mon Mar 29 16:46:05 2021 -0400 NFS: Deal correctly with attribute generation counter overflow [ Upstream commit 9fdbfad1777cb4638f489eeb62d85432010c0031 ] We need to use unsigned long subtraction and then convert to signed in order to deal correcly with C overflow rules. Fixes: f5062003465c ("NFS: Set an attribute barrier on all updates") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 85d7a427bb5fa5a57f3d963eafc887a04e8f21de Author: Dmitry Baryshkov Date: Mon Jan 25 02:28:26 2021 +0300 PCI: Release OF node in pci_scan_device()'s error path [ Upstream commit c99e755a4a4c165cad6effb39faffd0f3377c02d ] In pci_scan_device(), if pci_setup_device() fails for any reason, the code will not release device's of_node by calling pci_release_of_node(). Fix that by calling the release function. Fixes: 98d9f30c820d ("pci/of: Match PCI devices to OF nodes dynamically") Link: https://lore.kernel.org/r/20210124232826.1879-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Bjorn Helgaas Reviewed-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e71fe3f0cc8842b5b37b21771d2897fc084a5b02 Author: David Ward Date: Sun Apr 18 09:46:57 2021 -0400 ASoC: rt286: Make RT286_SET_GPIO_* readable and writable [ Upstream commit cd8499d5c03ba260e3191e90236d0e5f6b147563 ] The GPIO configuration cannot be applied if the registers are inaccessible. This prevented the headset mic from working on the Dell XPS 13 9343. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=114171 Signed-off-by: David Ward Link: https://lore.kernel.org/r/20210418134658.4333-5-david.ward@gatech.edu Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 161fccdf5cb7bce567609f94cbd0fccb23aa1bd4 Author: Alexey Kardashevskiy Date: Mon Mar 1 17:36:53 2021 +1100 powerpc/iommu: Annotate nested lock for lockdep [ Upstream commit cc7130bf119add37f36238343a593b71ef6ecc1e ] The IOMMU table is divided into pools for concurrent mappings and each pool has a separate spinlock. When taking the ownership of an IOMMU group to pass through a device to a VM, we lock these spinlocks which triggers a false negative warning in lockdep (below). This fixes it by annotating the large pool's spinlock as a nest lock which makes lockdep not complaining when locking nested locks if the nest lock is locked already. === WARNING: possible recursive locking detected 5.11.0-le_syzkaller_a+fstn1 #100 Not tainted -------------------------------------------- qemu-system-ppc/4129 is trying to acquire lock: c0000000119bddb0 (&(p->lock)/1){....}-{2:2}, at: iommu_take_ownership+0xac/0x1e0 but task is already holding lock: c0000000119bdd30 (&(p->lock)/1){....}-{2:2}, at: iommu_take_ownership+0xac/0x1e0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(p->lock)/1); lock(&(p->lock)/1); === Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210301063653.51003-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit 06b4af0bcdcc452f4f5bc55cac2ba26dfe5f8a3f Author: Gustavo A. R. Silva Date: Wed Apr 14 18:45:15 2021 -0500 wl3501_cs: Fix out-of-bounds warnings in wl3501_mgmt_join [ Upstream commit bb43e5718d8f1b46e7a77e7b39be3c691f293050 ] Fix the following out-of-bounds warnings by adding a new structure wl3501_req instead of duplicating the same members in structure wl3501_join_req and wl3501_scan_confirm: arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [39, 108] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 36 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [25, 95] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 22 [-Warray-bounds] Refactor the code, accordingly: $ pahole -C wl3501_req drivers/net/wireless/wl3501_cs.o struct wl3501_req { u16 beacon_period; /* 0 2 */ u16 dtim_period; /* 2 2 */ u16 cap_info; /* 4 2 */ u8 bss_type; /* 6 1 */ u8 bssid[6]; /* 7 6 */ struct iw_mgmt_essid_pset ssid; /* 13 34 */ struct iw_mgmt_ds_pset ds_pset; /* 47 3 */ struct iw_mgmt_cf_pset cf_pset; /* 50 8 */ struct iw_mgmt_ibss_pset ibss_pset; /* 58 4 */ struct iw_mgmt_data_rset bss_basic_rset; /* 62 10 */ /* size: 72, cachelines: 2, members: 10 */ /* last cacheline: 8 bytes */ }; $ pahole -C wl3501_join_req drivers/net/wireless/wl3501_cs.o struct wl3501_join_req { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 reserved; /* 3 1 */ struct iw_mgmt_data_rset operational_rset; /* 4 10 */ u16 reserved2; /* 14 2 */ u16 timeout; /* 16 2 */ u16 probe_delay; /* 18 2 */ u8 timestamp[8]; /* 20 8 */ u8 local_time[8]; /* 28 8 */ struct wl3501_req req; /* 36 72 */ /* size: 108, cachelines: 2, members: 10 */ /* last cacheline: 44 bytes */ }; $ pahole -C wl3501_scan_confirm drivers/net/wireless/wl3501_cs.o struct wl3501_scan_confirm { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 reserved; /* 3 1 */ u16 status; /* 4 2 */ char timestamp[8]; /* 6 8 */ char localtime[8]; /* 14 8 */ struct wl3501_req req; /* 22 72 */ /* --- cacheline 1 boundary (64 bytes) was 30 bytes ago --- */ u8 rssi; /* 94 1 */ /* size: 96, cachelines: 2, members: 8 */ /* padding: 1 */ /* last cacheline: 32 bytes */ }; The problem is that the original code is trying to copy data into a bunch of struct members adjacent to each other in a single call to memcpy(). Now that a new struct wl3501_req enclosing all those adjacent members is introduced, memcpy() doesn't overrun the length of &sig.beacon_period and &this->bss_set[i].beacon_period, because the address of the new struct object _req_ is used as the destination, instead. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1fbaf516da763b50edac47d792a9145aa4482e29.1618442265.git.gustavoars@kernel.org Signed-off-by: Sasha Levin commit df9738c9da4fdc4299ffa81d92df3509f114c2e1 Author: Gustavo A. R. Silva Date: Wed Apr 14 18:43:19 2021 -0500 wl3501_cs: Fix out-of-bounds warnings in wl3501_send_pkt [ Upstream commit 820aa37638a252b57967bdf4038a514b1ab85d45 ] Fix the following out-of-bounds warnings by enclosing structure members daddr and saddr into new struct addr, in structures wl3501_md_req and wl3501_md_ind: arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds] Refactor the code, accordingly: $ pahole -C wl3501_md_req drivers/net/wireless/wl3501_cs.o struct wl3501_md_req { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 routing; /* 3 1 */ u16 data; /* 4 2 */ u16 size; /* 6 2 */ u8 pri; /* 8 1 */ u8 service_class; /* 9 1 */ struct { u8 daddr[6]; /* 10 6 */ u8 saddr[6]; /* 16 6 */ } addr; /* 10 12 */ /* size: 22, cachelines: 1, members: 8 */ /* last cacheline: 22 bytes */ }; $ pahole -C wl3501_md_ind drivers/net/wireless/wl3501_cs.o struct wl3501_md_ind { u16 next_blk; /* 0 2 */ u8 sig_id; /* 2 1 */ u8 routing; /* 3 1 */ u16 data; /* 4 2 */ u16 size; /* 6 2 */ u8 reception; /* 8 1 */ u8 pri; /* 9 1 */ u8 service_class; /* 10 1 */ struct { u8 daddr[6]; /* 11 6 */ u8 saddr[6]; /* 17 6 */ } addr; /* 11 12 */ /* size: 24, cachelines: 1, members: 9 */ /* padding: 1 */ /* last cacheline: 24 bytes */ }; The problem is that the original code is trying to copy data into a couple of arrays adjacent to each other in a single call to memcpy(). Now that a new struct _addr_ enclosing those two adjacent arrays is introduced, memcpy() doesn't overrun the length of &sig.daddr[0] and &sig.daddr, because the address of the new struct object _addr_ is used, instead. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Reviewed-by: Kees Cook Signed-off-by: Gustavo A. R. Silva Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/d260fe56aed7112bff2be5b4d152d03ad7b78e78.1618442265.git.gustavoars@kernel.org Signed-off-by: Sasha Levin commit 8cc1685b9768ccc2da25fec909c010acc53d1961 Author: David Ward Date: Sun Apr 18 09:46:58 2021 -0400 ASoC: rt286: Generalize support for ALC3263 codec [ Upstream commit aa2f9c12821e6a4ba1df4fb34a3dbc6a2a1ee7fe ] The ALC3263 codec on the XPS 13 9343 is also found on the Latitude 13 7350 and Venue 11 Pro 7140. They require the same handling for the combo jack to work with a headset: GPIO pin 6 must be set. The HDA driver always sets this pin on the ALC3263, which it distinguishes by the codec vendor/device ID 0x10ec0288 and PCI subsystem vendor ID 0x1028 (Dell). The ASoC driver does not use PCI, so adapt this check to use DMI to determine if Dell is the system vendor. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=150601 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205961 Signed-off-by: David Ward Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210418134658.4333-6-david.ward@gatech.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4ab507070718d03a97cd47cacfbdebafa2e63411 Author: Gustavo A. R. Silva Date: Fri Apr 16 14:12:36 2021 -0500 sctp: Fix out-of-bounds warning in sctp_process_asconf_param() [ Upstream commit e5272ad4aab347dde5610c0aedb786219e3ff793 ] Fix the following out-of-bounds warning: net/sctp/sm_make_chunk.c:3150:4: warning: 'memcpy' offset [17, 28] from the object at 'addr' is out of the bounds of referenced subobject 'v4' with type 'struct sockaddr_in' at offset 0 [-Warray-bounds] This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4d688ff9741805c1552c9372b6fec52f8eb4db45 Author: Mihai Moldovan Date: Thu Apr 15 09:28:03 2021 +0200 kconfig: nconf: stop endless search loops [ Upstream commit 8c94b430b9f6213dec84e309bb480a71778c4213 ] If the user selects the very first entry in a page and performs a search-up operation, or selects the very last entry in a page and performs a search-down operation that will not succeed (e.g., via [/]asdfzzz[Up Arrow]), nconf will never terminate searching the page. The reason is that in this case, the starting point will be set to -1 or n, which is then translated into (n - 1) (i.e., the last entry of the page) or 0 (i.e., the first entry of the page) and finally the search begins. This continues to work fine until the index reaches 0 or (n - 1), at which point it will be decremented to -1 or incremented to n, but not checked against the starting point right away. Instead, it's wrapped around to the bottom or top again, after which the starting point check occurs... and naturally fails. My original implementation added another check for -1 before wrapping the running index variable around, but Masahiro Yamada pointed out that the actual issue is that the comparison point (starting point) exceeds bounds (i.e., the [0,n-1] interval) in the first place and that, instead, the starting point should be fixed. This has the welcome side-effect of also fixing the case where the starting point was n while searching down, which also lead to an infinite loop. OTOH, this code is now essentially all his work. Amazingly, nobody seems to have been hit by this for 11 years - or at the very least nobody bothered to debug and fix this. Signed-off-by: Mihai Moldovan Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit c69c91b57e8b991f8292e80cb9445627978bdb51 Author: Yonghong Song Date: Tue Apr 13 08:34:13 2021 -0700 selftests: Set CC to clang in lib.mk if LLVM is set [ Upstream commit 26e6dd1072763cd5696b75994c03982dde952ad9 ] selftests/bpf/Makefile includes lib.mk. With the following command make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 V=1 some files are still compiled with gcc. This patch fixed lib.mk issue which sets CC to gcc in all cases. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210413153413.3027426-1-yhs@fb.com Signed-off-by: Sasha Levin commit 874e94e21eb8bf3f91e3fb214690be30f07ee699 Author: Miklos Szeredi Date: Wed Apr 14 10:40:58 2021 +0200 cuse: prevent clone [ Upstream commit 8217673d07256b22881127bf50dce874d0e51653 ] For cloned connections cuse_channel_release() will be called more than once, resulting in use after free. Prevent device cloning for CUSE, which does not make sense at this point, and highly unlikely to be used in real life. Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 9db8f0eb4cfdfc89c1426621c596334e82485729 Author: Emmanuel Grumbach Date: Thu Apr 8 14:31:25 2021 +0200 mac80211: clear the beacon's CRC after channel switch [ Upstream commit d6843d1ee283137723b4a8c76244607ce6db1951 ] After channel switch, we should consider any beacon with a CSA IE as a new switch. If the CSA IE is a leftover from before the switch that the AP forgot to remove, we'll get a CSA-to-Self. This caused issues in iwlwifi where the firmware saw a beacon with a CSA-to-Self with mode = 1 on the new channel after a switch. The firmware considered this a new switch and closed its queues. Since the beacon didn't change between before and after the switch, we wouldn't handle it (the CRC is the same) and we wouldn't let the firmware open its queues again or disconnect if the CSA IE stays for too long. Clear the CRC valid state after we switch to make sure that we handle the beacon and handle the CSA IE as required. Signed-off-by: Emmanuel Grumbach Link: https://lore.kernel.org/r/20210408143124.b9e68aa98304.I465afb55ca2c7d59f7bf610c6046a1fd732b4c28@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c89a1a5edf330025539c0c1a93c42db83e7684da Author: Eric Dumazet Date: Mon Mar 29 12:12:54 2021 -0700 ip6_vti: proper dev_{hold|put} in ndo_[un]init methods [ Upstream commit 40cb881b5aaa0b69a7d93dec8440d5c62dae299f ] After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger a warning [1] Issue here is that: - all dev_put() should be paired with a corresponding prior dev_hold(). - A driver doing a dev_put() in its ndo_uninit() MUST also do a dev_hold() in its ndo_init(), only when ndo_init() is returning 0. Otherwise, register_netdevice() would call ndo_uninit() in its error path and release a refcount too soon. Therefore, we need to move dev_hold() call from vti6_tnl_create2() to vti6_dev_init_gen() [1] WARNING: CPU: 0 PID: 15951 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Modules linked in: CPU: 0 PID: 15951 Comm: syz-executor.3 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Code: 1d 6a 5a e8 09 31 ff 89 de e8 8d 1a ab fd 84 db 75 e0 e8 d4 13 ab fd 48 c7 c7 a0 e1 c1 89 c6 05 4a 5a e8 09 01 e8 2e 36 fb 04 <0f> 0b eb c4 e8 b8 13 ab fd 0f b6 1d 39 5a e8 09 31 ff 89 de e8 58 RSP: 0018:ffffc90001eaef28 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815c51f5 RDI: fffff520003d5dd7 RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815bdf8e R11: 0000000000000000 R12: ffff88801bb1c568 R13: ffff88801f69e800 R14: 00000000ffffffff R15: ffff888050889d40 FS: 00007fc79314e700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1c1ff47108 CR3: 0000000020fd5000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_dec include/linux/refcount.h:344 [inline] refcount_dec include/linux/refcount.h:359 [inline] dev_put include/linux/netdevice.h:4135 [inline] vti6_dev_uninit+0x31a/0x360 net/ipv6/ip6_vti.c:297 register_netdevice+0xadf/0x1500 net/core/dev.c:10308 vti6_tnl_create2+0x1b5/0x400 net/ipv6/ip6_vti.c:190 vti6_newlink+0x9d/0xd0 net/ipv6/ip6_vti.c:1020 __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3443 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x331/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmmsg+0x195/0x470 net/socket.c:2490 __do_sys_sendmmsg net/socket.c:2519 [inline] __se_sys_sendmmsg net/socket.c:2516 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2516 Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d3cee2c50ebf883d33a35507c0705f5aa75a5cb Author: Tetsuo Handa Date: Mon Mar 22 07:52:07 2021 +0900 Bluetooth: initialize skb_queue_head at l2cap_chan_create() [ Upstream commit be8597239379f0f53c9710dd6ab551bbf535bec6 ] syzbot is hitting "INFO: trying to register non-static key." message [1], for "struct l2cap_chan"->tx_q.lock spinlock is not yet initialized when l2cap_chan_del() is called due to e.g. timeout. Since "struct l2cap_chan"->lock mutex is initialized at l2cap_chan_create() immediately after "struct l2cap_chan" is allocated using kzalloc(), let's as well initialize "struct l2cap_chan"->{tx_q,srej_q}.lock spinlocks there. [1] https://syzkaller.appspot.com/bug?extid=fadfba6a911f6bf71842 Reported-and-tested-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit a331dbb34de69dd26179386f20b7d9072eb43c04 Author: Archie Pusaka Date: Mon Mar 22 14:02:15 2021 +0800 Bluetooth: Set CONF_NOT_COMPLETE as l2cap_chan default [ Upstream commit 3a9d54b1947ecea8eea9a902c0b7eb58a98add8a ] Currently l2cap_chan_set_defaults() reset chan->conf_state to zero. However, there is a flag CONF_NOT_COMPLETE which is set when creating the l2cap_chan. It is suggested that the flag should be cleared when l2cap_chan is ready, but when l2cap_chan_set_defaults() is called, l2cap_chan is not yet ready. Therefore, we must set this flag as the default. Example crash call trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0xc4/0x118 lib/dump_stack.c:56 panic+0x1c6/0x38b kernel/panic.c:117 __warn+0x170/0x1b9 kernel/panic.c:471 warn_slowpath_fmt+0xc7/0xf8 kernel/panic.c:494 debug_print_object+0x175/0x193 lib/debugobjects.c:260 debug_object_assert_init+0x171/0x1bf lib/debugobjects.c:614 debug_timer_assert_init kernel/time/timer.c:629 [inline] debug_assert_init kernel/time/timer.c:677 [inline] del_timer+0x7c/0x179 kernel/time/timer.c:1034 try_to_grab_pending+0x81/0x2e5 kernel/workqueue.c:1230 cancel_delayed_work+0x7c/0x1c4 kernel/workqueue.c:2929 l2cap_clear_timer+0x1e/0x41 include/net/bluetooth/l2cap.h:834 l2cap_chan_del+0x2d8/0x37e net/bluetooth/l2cap_core.c:640 l2cap_chan_close+0x532/0x5d8 net/bluetooth/l2cap_core.c:756 l2cap_sock_shutdown+0x806/0x969 net/bluetooth/l2cap_sock.c:1174 l2cap_sock_release+0x64/0x14d net/bluetooth/l2cap_sock.c:1217 __sock_release+0xda/0x217 net/socket.c:580 sock_close+0x1b/0x1f net/socket.c:1039 __fput+0x322/0x55c fs/file_table.c:208 ____fput+0x17/0x19 fs/file_table.c:244 task_work_run+0x19b/0x1d3 kernel/task_work.c:115 exit_task_work include/linux/task_work.h:21 [inline] do_exit+0xe4c/0x204a kernel/exit.c:766 do_group_exit+0x291/0x291 kernel/exit.c:891 get_signal+0x749/0x1093 kernel/signal.c:2396 do_signal+0xa5/0xcdb arch/x86/kernel/signal.c:737 exit_to_usermode_loop arch/x86/entry/common.c:243 [inline] prepare_exit_to_usermode+0xed/0x235 arch/x86/entry/common.c:277 syscall_return_slowpath+0x3a7/0x3b3 arch/x86/entry/common.c:348 int_ret_from_sys_call+0x25/0xa3 Signed-off-by: Archie Pusaka Reported-by: syzbot+338f014a98367a08a114@syzkaller.appspotmail.com Reviewed-by: Alain Michaud Reviewed-by: Abhishek Pandit-Subedi Reviewed-by: Guenter Roeck Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 294c984173155e34f38ded1dfcb0238d69c330ab Author: Tong Zhang Date: Sun Mar 21 11:38:40 2021 -0400 ALSA: rme9652: don't disable if not enabled [ Upstream commit f57a741874bb6995089020e97a1dcdf9b165dcbe ] rme9652 wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.751595] snd_rme9652 0000:00:03.0: disabling already-disabled device [ 1.751605] WARNING: CPU: 0 PID: 174 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.759968] Call Trace: [ 1.760145] snd_rme9652_card_free+0x76/0xa0 [snd_rme9652] [ 1.760434] release_card_device+0x4b/0x80 [snd] [ 1.760679] device_release+0x3b/0xa0 [ 1.760874] kobject_put+0x94/0x1b0 [ 1.761059] put_device+0x13/0x20 [ 1.761235] snd_card_free+0x61/0x90 [snd] [ 1.761454] snd_rme9652_probe+0x3be/0x700 [snd_rme9652] Suggested-by: Takashi Iwai Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210321153840.378226-4-ztong0001@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d1e8b4a161d19ce0208af3fc76bb0dc33a7e7c86 Author: Tong Zhang Date: Sun Mar 21 11:38:39 2021 -0400 ALSA: hdspm: don't disable if not enabled [ Upstream commit 790f5719b85e12e10c41753b864e74249585ed08 ] hdspm wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.786391] snd_hdspm 0000:00:03.0: disabling already-disabled device [ 1.786400] WARNING: CPU: 0 PID: 182 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.795181] Call Trace: [ 1.795320] snd_hdspm_card_free+0x58/0xa0 [snd_hdspm] [ 1.795595] release_card_device+0x4b/0x80 [snd] [ 1.795860] device_release+0x3b/0xa0 [ 1.796072] kobject_put+0x94/0x1b0 [ 1.796260] put_device+0x13/0x20 [ 1.796438] snd_card_free+0x61/0x90 [snd] [ 1.796659] snd_hdspm_probe+0x97b/0x1440 [snd_hdspm] Suggested-by: Takashi Iwai Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210321153840.378226-3-ztong0001@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1343c690e7e55f5d4525e48367621ca6575e0df7 Author: Tong Zhang Date: Sun Mar 21 11:38:38 2021 -0400 ALSA: hdsp: don't disable if not enabled [ Upstream commit 507cdb9adba006a7798c358456426e1aea3d9c4f ] hdsp wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable. [ 1.758292] snd_hdsp 0000:00:03.0: disabling already-disabled device [ 1.758327] WARNING: CPU: 0 PID: 180 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0 [ 1.766985] Call Trace: [ 1.767121] snd_hdsp_card_free+0x94/0xf0 [snd_hdsp] [ 1.767388] release_card_device+0x4b/0x80 [snd] [ 1.767639] device_release+0x3b/0xa0 [ 1.767838] kobject_put+0x94/0x1b0 [ 1.768027] put_device+0x13/0x20 [ 1.768207] snd_card_free+0x61/0x90 [snd] [ 1.768430] snd_hdsp_probe+0x524/0x5e0 [snd_hdsp] Suggested-by: Takashi Iwai Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210321153840.378226-2-ztong0001@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a582b502ea52de7b27a1aa01c9b29b0bcbb3e37a Author: Jonathan McDowell Date: Sat Mar 13 13:18:26 2021 +0000 net: stmmac: Set FIFO sizes for ipq806x [ Upstream commit e127906b68b49ddb3ecba39ffa36a329c48197d3 ] Commit eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values") started using the TX FIFO size to verify what counts as a valid MTU request for the stmmac driver. This is unset for the ipq806x variant. Looking at older patches for this it seems the RX + TXs buffers can be up to 8k, so set appropriately. (I sent this as an RFC patch in June last year, but received no replies. I've been running with this on my hardware (a MikroTik RB3011) since then with larger MTUs to support both the internal qca8k switch and VLANs with no problems. Without the patch it's impossible to set the larger MTU required to support this.) Signed-off-by: Jonathan McDowell Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7ef25db0e32e9c65ba15e2bd29538d2bf3edac24 Author: Hoang Le Date: Thu Mar 11 10:33:22 2021 +0700 tipc: convert dest node's address to network order [ Upstream commit 1980d37565061ab44bdc2f9e4da477d3b9752e81 ] (struct tipc_link_info)->dest is in network order (__be32), so we must convert the value to network order before assigning. The problem detected by sparse: net/tipc/netlink_compat.c:699:24: warning: incorrect type in assignment (different base types) net/tipc/netlink_compat.c:699:24: expected restricted __be32 [usertype] dest net/tipc/netlink_compat.c:699:24: got int Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b6963dbe7867dc2696650838ab61e00b24b41bcb Author: Alexander Aring Date: Mon Mar 1 17:05:08 2021 -0500 fs: dlm: fix debugfs dump [ Upstream commit 92c48950b43f4a767388cf87709d8687151a641f ] This patch fixes the following message which randomly pops up during glocktop call: seq_file: buggy .next function table_seq_next did not update position index The issue is that seq_read_iter() in fs/seq_file.c also needs an increment of the index in an non next record case as well which this patch fixes otherwise seq_read_iter() will print out the above message. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit ad4dc0db54f9796af2411243292e0e7a10da0f58 Author: Xin Long Date: Mon May 3 05:11:42 2021 +0800 sctp: delay auto_asconf init until binding the first addr commit 34e5b01186858b36c4d7c87e1a025071e8e2401f upstream. As Or Cohen described: If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock held and sp->do_auto_asconf is true, then an element is removed from the auto_asconf_splist without any proper locking. This can happen in the following functions: 1. In sctp_accept, if sctp_sock_migrate fails. 2. In inet_create or inet6_create, if there is a bpf program attached to BPF_CGROUP_INET_SOCK_CREATE which denies creation of the sctp socket. This patch is to fix it by moving the auto_asconf init out of sctp_init_sock(), by which inet_create()/inet6_create() won't need to operate it in sctp_destroy_sock() when calling sk_common_release(). It also makes more sense to do auto_asconf init while binding the first addr, as auto_asconf actually requires an ANY addr bind, see it in sctp_addr_wq_timeout_handler(). This addresses CVE-2021-23133. Fixes: 610236587600 ("bpf: Add new cgroup attach type to enable sock modifications") Reported-by: Or Cohen Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1b6863dd6a24f84643fe138b46ae9046e1ed52f0 Author: Xin Long Date: Mon May 3 05:11:41 2021 +0800 Revert "net/sctp: fix race condition in sctp_destroy_sock" commit 01bfe5e8e428b475982a98a46cca5755726f3f7f upstream. This reverts commit b166a20b07382b8bc1dcee2a448715c9c2c81b5b. This one has to be reverted as it introduced a dead lock, as syzbot reported: CPU0 CPU1 ---- ---- lock(&net->sctp.addr_wq_lock); lock(slock-AF_INET6); lock(&net->sctp.addr_wq_lock); lock(slock-AF_INET6); CPU0 is the thread of sctp_addr_wq_timeout_handler(), and CPU1 is that of sctp_close(). The original issue this commit fixed will be fixed in the next patch. Reported-by: syzbot+959223586843e69a2674@syzkaller.appspotmail.com Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bfd21f05118c8e9d9ecaa97b9672eb68c248083f Author: Dan Carpenter Date: Thu Apr 29 22:54:15 2021 -0700 kfifo: fix ternary sign extension bugs [ Upstream commit 926ee00ea24320052b46745ef4b00d91c05bd03d ] The intent with this code was to return negative error codes but instead it returns positives. The problem is how type promotion works with ternary operations. These functions return long, "ret" is an int and "copied" is a u32. The negative error code is first cast to u32 so it becomes a high positive and then cast to long where it's still a positive. We could fix this by declaring "ret" as a ssize_t but let's just get rid of the ternaries instead. Link: https://lkml.kernel.org/r/YIE+/cK1tBzSuQPU@mwanda Fixes: 5bf2b19320ec ("kfifo: add example files to the kernel sample directory") Signed-off-by: Dan Carpenter Cc: Stefani Seibold Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5ef149f289ca0ab607971f981ce07a52187613c2 Author: Lv Yunlong Date: Tue Apr 27 09:22:58 2021 -0700 net:nfc:digital: Fix a double free in digital_tg_recv_dep_req [ Upstream commit 75258586793efc521e5dd52a5bf6c7a4cf7002be ] In digital_tg_recv_dep_req, it calls nfc_tm_data_received(..,resp). If nfc_tm_data_received() failed, the callee will free the resp via kfree_skb() and return error. But in the exit branch, the resp will be freed again. My patch sets resp to NULL if nfc_tm_data_received() failed, to avoid the double free. Fixes: 1c7a4c24fbfd9 ("NFC Digital: Add target NFC-DEP support") Signed-off-by: Lv Yunlong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2fbfe3e61ac80e901628eea6be04cfcca3d80fef Author: Christophe Leroy Date: Wed Apr 21 17:24:03 2021 +0000 powerpc/52xx: Fix an invalid ASM expression ('addi' used instead of 'add') [ Upstream commit 8a87a507714386efc39c3ae6fa24d4f79846b522 ] AS arch/powerpc/platforms/52xx/lite5200_sleep.o arch/powerpc/platforms/52xx/lite5200_sleep.S: Assembler messages: arch/powerpc/platforms/52xx/lite5200_sleep.S:184: Warning: invalid register expression In the following code, 'addi' is wrong, has to be 'add' /* local udelay in sram is needed */ udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */ mullw r12, r12, r11 mftb r13 /* start */ addi r12, r13, r12 /* end */ Fixes: ee983079ce04 ("[POWERPC] MPC5200 low power mode") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/cb4cec9131c8577803367f1699209a7e104cec2a.1619025821.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 211a5eb32aa7aaacef9cff845bba1827c6c24760 Author: Toke Høiland-Jørgensen Date: Fri Mar 26 19:08:19 2021 +0100 ath9k: Fix error check in ath9k_hw_read_revisions() for PCI devices [ Upstream commit 7dd9a40fd6e0d0f1fd8e1931c007e080801dfdce ] When the error check in ath9k_hw_read_revisions() was added, it checked for -EIO which is what ath9k_regread() in the ath9k_htc driver uses. However, for plain ath9k, the register read function uses ioread32(), which just returns -1 on error. So if such a read fails, it still gets passed through and ends up as a weird mac revision in the log output. Fix this by changing ath9k_regread() to return -1 on error like ioread32() does, and fix the error check to look for that instead of -EIO. Fixes: 2f90c7e5d094 ("ath9k: Check for errors when reading SREV register") Signed-off-by: Toke Høiland-Jørgensen Reviewed-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210326180819.142480-1-toke@redhat.com Signed-off-by: Sasha Levin commit 24f03b88d1226310e6f3630d700d184db957e64a Author: Colin Ian King Date: Tue Apr 20 18:16:14 2021 +0100 net: davinci_emac: Fix incorrect masking of tx and rx error channel [ Upstream commit d83b8aa5207d81f9f6daec9888390f079cc5db3f ] The bit-masks used for the TXERRCH and RXERRCH (tx and rx error channels) are incorrect and always lead to a zero result. The mask values are currently the incorrect post-right shifted values, fix this by setting them to the currect values. (I double checked these against the TMS320TCI6482 data sheet, section 5.30, page 127 to ensure I had the correct mask values for the TXERRCH and RXERRCH fields in the MACSTATUS register). Addresses-Coverity: ("Operands don't affect result") Fixes: a6286ee630f6 ("net: Add TI DaVinci EMAC driver") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 878ffbe40a45187e5d6dbfa15ae41a014645f8ef Author: Stefano Garzarella Date: Fri Apr 16 12:44:16 2021 +0200 vsock/vmci: log once the failed queue pair allocation [ Upstream commit e16edc99d658cd41c60a44cc14d170697aa3271f ] VMCI feature is not supported in conjunction with the vSphere Fault Tolerance (FT) feature. VMware Tools can repeatedly try to create a vsock connection. If FT is enabled the kernel logs is flooded with the following messages: qp_alloc_hypercall result = -20 Could not attach to queue pair with -20 "qp_alloc_hypercall result = -20" was hidden by commit e8266c4c3307 ("VMCI: Stop log spew when qp allocation isn't possible"), but "Could not attach to queue pair with -20" is still there flooding the log. Since the error message can be useful in some cases, print it only once. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Signed-off-by: Stefano Garzarella Reviewed-by: Jorgen Hansen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e993f744a14e52b309427a683b816b20e92e04c7 Author: Lv Yunlong Date: Fri Apr 2 11:26:27 2021 -0700 mwl8k: Fix a double Free in mwl8k_probe_hw [ Upstream commit a8e083ee8e2a6c94c29733835adae8bf5b832748 ] In mwl8k_probe_hw, hw->priv->txq is freed at the first time by dma_free_coherent() in the call chain: if(!priv->ap_fw)->mwl8k_init_txqs(hw)->mwl8k_txq_init(hw, i). Then in err_free_queues of mwl8k_probe_hw, hw->priv->txq is freed at the second time by mwl8k_txq_deinit(hw, i)->dma_free_coherent(). My patch set txq->txd to NULL after the first free to avoid the double free. Fixes: a66098daacee2 ("mwl8k: Marvell TOPDOG wireless driver") Signed-off-by: Lv Yunlong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210402182627.4256-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Sasha Levin commit 892d74ebd2e44d7791c661c05396d167b9b255c5 Author: Sergey Shtylyov Date: Sat Apr 17 22:05:05 2021 +0300 i2c: sh7760: fix IRQ error path [ Upstream commit 92dfb27240fea2776f61c5422472cb6defca7767 ] While adding the invalid IRQ check after calling platform_get_irq(), I managed to overlook that the driver has a complex error path in its probe() method, thus a simple *return* couldn't be used. Use a proper *goto* instead! Fixes: e5b2e3e74201 ("i2c: sh7760: add IRQ check") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit d3a3e6babcb1187bd529a6a175f192509bab47ca Author: Tyrel Datwyler Date: Thu Feb 11 12:24:35 2021 -0600 powerpc/pseries: extract host bridge from pci_bus prior to bus removal [ Upstream commit 38d0b1c9cec71e6d0f3bddef0bbce41d05a3e796 ] The pci_bus->bridge reference may no longer be valid after pci_bus_remove() resulting in passing a bad value to device_unregister() for the associated bridge device. Store the host_bridge reference in a separate variable prior to pci_bus_remove(). Fixes: 7340056567e3 ("powerpc/pci: Reorder pci bus/bridge unregistration during PHB removal") Signed-off-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210211182435.47968-1-tyreld@linux.ibm.com Signed-off-by: Sasha Levin commit 30e76acb2f9e83a2a826a50b59442dfa11be918e Author: Sergey Shtylyov Date: Sat Apr 10 23:25:10 2021 +0300 i2c: sh7760: add IRQ check [ Upstream commit e5b2e3e742015dd2aa6bc7bcef2cb59b2de1221c ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: a26c20b1fa6d ("i2c: Renesas SH7760 I2C master driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit a7d0e4e71c2f7d40fb1324030b7221ed1b1a4187 Author: Sergey Shtylyov Date: Sat Apr 10 23:18:31 2021 +0300 i2c: jz4780: add IRQ check [ Upstream commit c5e5f7a8d931fb4beba245bdbc94734175fda9de ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: ba92222ed63a ("i2c: jz4780: Add i2c bus controller driver for Ingenic JZ4780") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 2043cd51d09e4ecac3d4532b4be627c5c3b0c492 Author: Sergey Shtylyov Date: Sat Apr 10 23:14:35 2021 +0300 i2c: cadence: add IRQ check [ Upstream commit 5581c2c5d02bc63a0edb53e061c8e97cd490646e ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit e8681a4596b8cbbce8e2fd06a56b5a17e927bd90 Author: Colin Ian King Date: Fri Apr 9 14:07:26 2021 +0100 net: thunderx: Fix unintentional sign extension issue [ Upstream commit e701a25840360706fe4cf5de0015913ca19c274b ] The shifting of the u8 integers rq->caching by 26 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that rq->caching is greater than 0x1f then all then all the upper 32 bits of the u64 end up as also being set because of the int sign-extension. Fix this by casting the u8 values to a u64 before the 26 bit left shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 4863dea3fab0 ("net: Adding support for Cavium ThunderX network controller") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f4c9ba3be5e8bfd0ed5220da91539388d66a7fca Author: Colin Ian King Date: Thu Feb 25 18:32:41 2021 +0000 mt7601u: fix always true expression [ Upstream commit 87fce88658ba047ae62e83497d3f3c5dc22fa6f9 ] Currently the expression ~nic_conf1 is always true because nic_conf1 is a u16 and according to 6.5.3.3 of the C standard the ~ operator promotes the u16 to an integer before flipping all the bits. Thus the top 16 bits of the integer result are all set so the expression is always true. If the intention was to flip all the bits of nic_conf1 then casting the integer result back to a u16 is a suitabel fix. Interestingly static analyzers seem to thing a bitwise ! should be used instead of ~ for this scenario, so I think the original intent of the expression may need some extra consideration. Addresses-Coverity: ("Logical vs. bitwise operator") Fixes: c869f77d6abb ("add mt7601u driver") Signed-off-by: Colin Ian King Acked-by: Jakub Kicinski Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210225183241.1002129-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 3c708d4dacc975895730615f4821f317a48f78af Author: Johannes Berg Date: Thu Apr 8 14:31:50 2021 +0200 mac80211: bail out if cipher schemes are invalid [ Upstream commit db878e27a98106a70315d264cc92230d84009e72 ] If any of the cipher schemes specified by the driver are invalid, bail out and fail the registration rather than just warning. Otherwise, we might later crash when we try to use the invalid cipher scheme, e.g. if the hdr_len is (significantly) less than the pn_offs + pn_len, we'd have an out-of-bounds access in RX validation. Fixes: 2475b1cc0d52 ("mac80211: add generic cipher scheme support") Link: https://lore.kernel.org/r/20210408143149.38a3a13a1b19.I6b7f5790fa0958ed8049cf02ac2a535c61e9bc96@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e9b0ecec26e73fea9e9d9c772f50b9bf40c4a8ba Author: Randy Dunlap Date: Sun Apr 4 12:26:23 2021 -0700 powerpc: iommu: fix build when neither PCI or IBMVIO is set [ Upstream commit b27dadecdf9102838331b9a0b41ffc1cfe288154 ] When neither CONFIG_PCI nor CONFIG_IBMVIO is set/enabled, iommu.c has a build error. The fault injection code is not useful in that kernel config, so make the FAIL_IOMMU option depend on PCI || IBMVIO. Prevents this build error (warning escalated to error): ../arch/powerpc/kernel/iommu.c:178:30: error: 'fail_iommu_bus_notifier' defined but not used [-Werror=unused-variable] 178 | static struct notifier_block fail_iommu_bus_notifier = { Fixes: d6b9a81b2a45 ("powerpc: IOMMU fault injection") Reported-by: kernel test robot Suggested-by: Michael Ellerman Signed-off-by: Randy Dunlap Acked-by: Randy Dunlap # build-tested Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210404192623.10697-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 0624a1c8cf6e32bc568b41dffc964b1b4dabaede Author: Takashi Iwai Date: Tue Apr 6 13:35:34 2021 +0200 ALSA: usb-audio: Add error checks for usb_driver_claim_interface() calls [ Upstream commit 5fb45414ae03421255593fd5556aa2d1d82303aa ] There are a few calls of usb_driver_claim_interface() but all of those miss the proper error checks, as reported by Coverity. This patch adds those missing checks. Along with it, replace the magic pointer with -1 with a constant USB_AUDIO_IFACE_UNUSED for better readability. Reported-by: coverity-bot Addresses-Coverity-ID: 1475943 ("Error handling issues") Addresses-Coverity-ID: 1475944 ("Error handling issues") Addresses-Coverity-ID: 1475945 ("Error handling issues") Fixes: b1ce7ba619d9 ("ALSA: usb-audio: claim autodetected PCM interfaces all at once") Fixes: e5779998bf8b ("ALSA: usb-audio: refactor code") Link: https://lore.kernel.org/r/202104051059.FB7F3016@keescook Link: https://lore.kernel.org/r/20210406113534.30455-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f1df51ff6b8e97871c5a0771f3715dc3a93daaaf Author: Dan Carpenter Date: Fri Apr 2 14:44:42 2021 +0300 nfc: pn533: prevent potential memory corruption [ Upstream commit ca4d4c34ae9aa5c3c0da76662c5e549d2fc0cc86 ] If the "type_a->nfcid_len" is too large then it would lead to memory corruption in pn533_target_found_type_a() when we do: memcpy(nfc_tgt->nfcid1, tgt_type_a->nfcid_data, nfc_tgt->nfcid1_len); Fixes: c3b1e1e8a76f ("NFC: Export NFCID1 from pn533") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6682ee4724e4b3363c269adc50996768f938cedf Author: Jia Zhou Date: Tue Mar 30 13:19:23 2021 +0200 ALSA: core: remove redundant spin_lock pair in snd_card_disconnect [ Upstream commit abc21649b3e5c34b143bf86f0c78e33d5815e250 ] modification in commit 2a3f7221acdd ("ALSA: core: Fix card races between register and disconnect") resulting in this problem. Fixes: 2a3f7221acdd ("ALSA: core: Fix card races between register and disconnect") Signed-off-by: Jia Zhou Signed-off-by: Yi Wang Link: https://lore.kernel.org/r/1616989007-34429-1-git-send-email-wang.yi59@zte.com.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3f2361b3def26199a55985421807a51e0c7d1625 Author: Nathan Chancellor Date: Tue Mar 2 13:08:29 2021 -0700 powerpc/prom: Mark identical_pvr_fixup as __init [ Upstream commit 1ef1dd9c7ed27b080445e1576e8a05957e0e4dfc ] If identical_pvr_fixup() is not inlined, there are two modpost warnings: WARNING: modpost: vmlinux.o(.text+0x54e8): Section mismatch in reference from the function identical_pvr_fixup() to the function .init.text:of_get_flat_dt_prop() The function identical_pvr_fixup() references the function __init of_get_flat_dt_prop(). This is often because identical_pvr_fixup lacks a __init annotation or the annotation of of_get_flat_dt_prop is wrong. WARNING: modpost: vmlinux.o(.text+0x551c): Section mismatch in reference from the function identical_pvr_fixup() to the function .init.text:identify_cpu() The function identical_pvr_fixup() references the function __init identify_cpu(). This is often because identical_pvr_fixup lacks a __init annotation or the annotation of identify_cpu is wrong. identical_pvr_fixup() calls two functions marked as __init and is only called by a function marked as __init so it should be marked as __init as well. At the same time, remove the inline keywork as it is not necessary to inline this function. The compiler is still free to do so if it feels it is worthwhile since commit 889b3c1245de ("compiler: remove CONFIG_OPTIMIZE_INLINING entirely"). Fixes: 14b3d926a22b ("[POWERPC] 4xx: update 440EP(x)/440GR(x) identical PVR issue workaround") Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://github.com/ClangBuiltLinux/linux/issues/1316 Link: https://lore.kernel.org/r/20210302200829.2680663-1-nathan@kernel.org Signed-off-by: Sasha Levin commit b5a0e273be0db98e5a5c20663edb38f9a66f0c96 Author: Xie He Date: Wed Mar 10 23:23:09 2021 -0800 net: lapbether: Prevent racing when checking whether the netif is running [ Upstream commit 5acd0cfbfbb5a688da1bfb1a2152b0c855115a35 ] There are two "netif_running" checks in this driver. One is in "lapbeth_xmit" and the other is in "lapbeth_rcv". They serve to make sure that the LAPB APIs called in these functions are called before "lapb_unregister" is called by the "ndo_stop" function. However, these "netif_running" checks are unreliable, because it's possible that immediately after "netif_running" returns true, "ndo_stop" is called (which causes "lapb_unregister" to be called). This patch adds locking to make sure "lapbeth_xmit" and "lapbeth_rcv" can reliably check and ensure the netif is running while doing their work. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xie He Acked-by: Martin Schiller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 308fd71e6592354f36245b188e0979724452510f Author: Maxim Mikityanskiy Date: Sun Feb 7 16:47:40 2021 +0200 HID: plantronics: Workaround for double volume key presses [ Upstream commit f567d6ef8606fb427636e824c867229ecb5aefab ] Plantronics Blackwire 3220 Series (047f:c056) sends HID reports twice for each volume key press. This patch adds a quirk to hid-plantronics for this product ID, which will ignore the second volume key press if it happens within 5 ms from the last one that was handled. The patch was tested on the mentioned model only, it shouldn't affect other models, however, this quirk might be needed for them too. Auto-repeat (when a key is held pressed) is not affected, because the rate is about 3 times per second, which is far less frequent than once in 5 ms. Fixes: 81bb773faed7 ("HID: plantronics: Update to map volume up/down controls") Signed-off-by: Maxim Mikityanskiy Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a019970ed4603d98317658ec82569affd2f8bc14 Author: Nathan Chancellor Date: Wed Apr 14 17:11:11 2021 -0700 x86/events/amd/iommu: Fix sysfs type mismatch [ Upstream commit de5bc7b425d4c27ae5faa00ea7eb6b9780b9a355 ] dev_attr_show() calls _iommu_event_show() via an indirect call but _iommu_event_show()'s type does not currently match the type of the show() member in 'struct device_attribute', resulting in a Control Flow Integrity violation. $ cat /sys/devices/amd_iommu_1/events/mem_dte_hit csource=0x0a $ dmesg | grep "CFI failure" [ 3526.735140] CFI failure (target: _iommu_event_show...): Change _iommu_event_show() and 'struct amd_iommu_event_desc' to 'struct device_attribute' so that there is no more CFI violation. Fixes: 7be6296fdd75 ("perf/x86/amd: AMD IOMMU Performance Counter PERF uncore PMU implementation") Signed-off-by: Nathan Chancellor Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210415001112.3024673-1-nathan@kernel.org Signed-off-by: Sasha Levin commit 3cab0cfd396aa06222b1f7117a6f235c051fa38b Author: Dan Carpenter Date: Fri Apr 9 14:08:17 2021 +0300 HSI: core: fix resource leaks in hsi_add_client_from_dt() [ Upstream commit 5c08b0f75575648032f309a6f58294453423ed93 ] If some of the allocations fail between the dev_set_name() and the device_register() then the name will not be freed. Fix this by moving dev_set_name() directly in front of the call to device_register(). Fixes: a2aa24734d9d ("HSI: Add common DT binding for HSI client devices") Signed-off-by: Dan Carpenter Reviewed-by: Jason Gunthorpe Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c43166e6beeacc1c1e843ba39ff04b7159105c7b Author: Sergey Shtylyov Date: Tue Mar 30 20:45:12 2021 +0300 scsi: sni_53c710: Add IRQ check [ Upstream commit 1160d61bc51e87e509cfaf9da50a0060f67b6de4 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #s), causing it to fail with -EINVAL (overridden by -ENODEV further below). Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/8f4b8fa5-8251-b977-70a1-9099bcb4bb17@omprussia.ru Fixes: c27d85f3f3c5 ("[SCSI] SNI RM 53c710 driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4aff784e937e9b519d94fe06a2ab5bd5ba4ce539 Author: Sergey Shtylyov Date: Tue Mar 30 20:44:08 2021 +0300 scsi: sun3x_esp: Add IRQ check [ Upstream commit 14b321380eb333c82853d7d612d0995f05f88fdc ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/363eb4c8-a3bf-4dc9-2a9e-90f349030a15@omprussia.ru Fixes: 0bb67f181834 ("[SCSI] sun3x_esp: convert to esp_scsi") Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1dc0a24e458d1329a869cbd036d2a7d358c41175 Author: Sergey Shtylyov Date: Tue Mar 30 20:43:23 2021 +0300 scsi: jazz_esp: Add IRQ check [ Upstream commit 38fca15c29db6ed06e894ac194502633e2a7d1fb ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/594aa9ae-2215-49f6-f73c-33bd38989912@omprussia.ru Fixes: 352e921f0dd4 ("[SCSI] jazz_esp: converted to use esp_core") Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d3170c132406edc1feea6e892c870d32f88d6469 Author: Arnd Bergmann Date: Mon Mar 22 17:46:00 2021 +0100 media: dvb-usb-remote: fix dvb_usb_nec_rc_key_to_event type mismatch [ Upstream commit 0fa430e96d3c3561a78701f51fd8593da68b8474 ] gcc-11 warns about the prototype not exactly matching the function definition: drivers/media/usb/dvb-usb/dvb-usb-remote.c:363:20: error: argument 2 of type ‘u8[5]’ {aka ‘unsigned char[5]’} with mismatched bound [-Werror=array-parameter=] 363 | u8 keybuf[5], u32 *event, int *state) | ~~~^~~~~~~~~ In file included from drivers/media/usb/dvb-usb/dvb-usb-common.h:13, from drivers/media/usb/dvb-usb/dvb-usb-remote.c:9: drivers/media/usb/dvb-usb/dvb-usb.h:490:65: note: previously declared as ‘u8[]’ {aka ‘unsigned char[]’} 490 | extern int dvb_usb_nec_rc_key_to_event(struct dvb_usb_device *, u8[], u32 *, int *); | ^~~~ Fixes: 776338e121b9 ("[PATCH] dvb: Add generalized dvb-usb driver") Signed-off-by: Arnd Bergmann Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8b75d208f2667a4a0444f611fd3599783a3c302d Author: Arnd Bergmann Date: Mon Mar 22 17:46:59 2021 +0100 scsi: fcoe: Fix mismatched fcoe_wwn_from_mac declaration [ Upstream commit 5b11c9d80bde81f6896cc85b23aeaa9502a704ed ] An old cleanup changed the array size from MAX_ADDR_LEN to unspecified in the declaration, but now gcc-11 warns about this: drivers/scsi/fcoe/fcoe_ctlr.c:1972:37: error: argument 1 of type ‘unsigned char[32]’ with mismatched bound [-Werror=array-parameter=] 1972 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], | ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~ In file included from /git/arm-soc/drivers/scsi/fcoe/fcoe_ctlr.c:33: include/scsi/libfcoe.h:252:37: note: previously declared as ‘unsigned char[]’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[], unsigned int, unsigned int); | ~~~~~~~~~~~~~~^~~~~ Change the type back to what the function definition uses. Link: https://lore.kernel.org/r/20210322164702.957810-1-arnd@kernel.org Fixes: fdd78027fd47 ("[SCSI] fcoe: cleans up libfcoe.h and adds fcoe.h for fcoe module") Signed-off-by: Arnd Bergmann Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a236b23a163dccb415e4a64f99ac2cdc16ff4938 Author: Sergey Shtylyov Date: Mon Mar 15 23:15:06 2021 +0300 ata: libahci_platform: fix IRQ check [ Upstream commit b30d0040f06159de97ad9c0b1536f47250719d7d ] Iff platform_get_irq() returns 0, ahci_platform_init_host() would return 0 early (as if the call was successful). Override IRQ0 with -EINVAL instead as the 'libata' regards 0 as "no IRQ" (thus polling) anyway... Fixes: c034640a32f8 ("ata: libahci: properly propagate return value of platform_get_irq()") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/4448c8cc-331f-2915-0e17-38ea34e251c8@omprussia.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7baf481334352c4668a3cfae052450d6e157d712 Author: Sergey Shtylyov Date: Sun Mar 28 00:13:49 2021 +0300 sata_mv: add IRQ checks [ Upstream commit e6471a65fdd5efbb8dd2732dd0f063f960685ceb ] The function mv_platform_probe() neglects to check the results of the calls to platform_get_irq() and irq_of_parse_and_map() and blithely passes them to ata_host_activate() -- while the latter only checks for IRQ0 (treating it as a polling mode indicattion) and passes the negative values to devm_request_irq() causing it to fail as it takes unsigned values for the IRQ #... Add to mv_platform_probe() the proper IRQ checks to pass the positive IRQ #s to ata_host_activate(), propagate upstream the negative error codes, and override the IRQ0 with -EINVAL (as we don't want the polling mode). Fixes: f351b2d638c3 ("sata_mv: Support SoC controllers") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/51436f00-27a1-e20b-c21b-0e817e0a7c86@omprussia.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0d5d7067ebf7f387a97dbcfeb2139c5b79eeac26 Author: Sergey Shtylyov Date: Thu Mar 25 23:51:10 2021 +0300 pata_ipx4xx_cf: fix IRQ check [ Upstream commit e379b40cc0f179403ce0b82b7e539f635a568da5 ] The driver's probe() method is written as if platform_get_irq() returns 0 on error, while actually it returns a negative error code (with all the other values considered valid IRQs). Rewrite the driver's IRQ checking code to pass the positive IRQ #s to ata_host_activate(), propagate errors upstream, and treat IRQ0 as error, returning -EINVAL, as the libata code treats 0 as an indication that polling should be used anyway... Fixes: 0df0d0a0ea9f ("[libata] ARM: add ixp4xx PATA driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5d6a2571936a46a0714cd3e21a967a796d621490 Author: Sergey Shtylyov Date: Thu Mar 25 23:50:24 2021 +0300 pata_arasan_cf: fix IRQ check [ Upstream commit c7e8f404d56b99c80990b19a402c3f640d74be05 ] The driver's probe() method is written as if platform_get_irq() returns 0 on error, while actually it returns a negative error code (with all the other values considered valid IRQs). Rewrite the driver's IRQ checking code to pass the positive IRQ #s to ata_host_activate(), propagate upstream -EPROBE_DEFER, and set up the driver to polling mode on (negative) errors and IRQ0 (libata treats IRQ #0 as a polling mode anyway)... Fixes: a480167b23ef ("pata_arasan_cf: Adding support for arasan compact flash host controller") Signed-off-by: Sergey Shtylyov Acked-by: Viresh Kumar Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b95690fa10becec157f3b7ffb3de9a19770e2322 Author: Colin Ian King Date: Wed Oct 7 14:16:28 2020 +0200 media: m88rs6000t: avoid potential out-of-bounds reads on arrays [ Upstream commit 9baa3d64e8e2373ddd11c346439e5dfccb2cbb0d ] There a 3 array for-loops that don't check the upper bounds of the index into arrays and this may lead to potential out-of-bounds reads. Fix this by adding array size upper bounds checks to be full safe. Addresses-Coverity: ("Out-of-bounds read") Link: https://lore.kernel.org/linux-media/20201007121628.20676-1-colin.king@canonical.com Fixes: 333829110f1d ("[media] m88rs6000t: add new dvb-s/s2 tuner for integrated chip M88RS6000") Signed-off-by: Colin Ian King Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fe0027ba2e0f633da25240ffa5e237d816502c5e Author: Yang Yingliang Date: Tue Nov 17 03:50:41 2020 +0100 media: omap4iss: return error code when omap4iss_get() failed [ Upstream commit 8938c48fa25b491842ece9eb38f0bea0fcbaca44 ] If omap4iss_get() failed, it need return error code in iss_probe(). Fixes: 59f0ad807681 ("[media] v4l: omap4iss: Add support for OMAP4...") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6ad7534152d68aae7e18108947465bc8ce15872c Author: Colin Ian King Date: Thu Feb 25 16:43:27 2021 +0100 media: vivid: fix assignment of dev->fbuf_out_flags [ Upstream commit 5cde22fcc7271812a7944c47b40100df15908358 ] Currently the chroma_flags and alpha_flags are being zero'd with a bit-wise mask and the following statement should be bit-wise or'ing in the new flag bits but instead is making a direct assignment. Fix this by using the |= operator rather than an assignment. Addresses-Coverity: ("Unused value") Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts") Signed-off-by: Colin Ian King Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 49e6b88161ac93a1b0f597510882b0e2414051e1 Author: Tetsuo Handa Date: Thu Apr 15 09:22:22 2021 +0900 ttyprintk: Add TTY hangup callback. [ Upstream commit c0070e1e60270f6a1e09442a9ab2335f3eaeaad2 ] syzbot is reporting hung task due to flood of tty_warn(tty, "%s: tty->count = 1 port count = %d\n", __func__, port->count); message [1], for ioctl(TIOCVHANGUP) prevents tty_port_close() from decrementing port->count due to tty_hung_up_p() == true. ---------- #include #include #include #include #include int main(int argc, char *argv[]) { int i; int fd[10]; for (i = 0; i < 10; i++) fd[i] = open("/dev/ttyprintk", O_WRONLY); ioctl(fd[0], TIOCVHANGUP); for (i = 0; i < 10; i++) close(fd[i]); close(open("/dev/ttyprintk", O_WRONLY)); return 0; } ---------- When TTY hangup happens, port->count needs to be reset via "struct tty_operations"->hangup callback. [1] https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a Reported-by: syzbot Reported-by: syzbot Tested-by: syzbot Signed-off-by: Tetsuo Handa Fixes: 24b4b67d17c308aa ("add ttyprintk driver") Link: https://lore.kernel.org/r/17e0652d-89b7-c8c0-fb53-e7566ac9add4@i-love.sakura.ne.jp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d9aeb5f9cc381956e97cbe240177f9b6b10f9987 Author: Johan Hovold Date: Wed Apr 7 11:52:02 2021 +0200 tty: fix return value for unsupported ioctls [ Upstream commit 1b8b20868a6d64cfe8174a21b25b74367bdf0560 ] Drivers should return -ENOTTY ("Inappropriate I/O control operation") when an ioctl isn't supported, while -EINVAL is used for invalid arguments. Fix up the TIOCMGET, TIOCMSET and TIOCGICOUNT helpers which returned -EINVAL when a tty driver did not implement the corresponding operations. Note that the TIOCMGET and TIOCMSET helpers predate git and do not get a corresponding Fixes tag below. Fixes: d281da7ff6f7 ("tty: Make tiocgicount a handler") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407095208.31838-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cb0abd7c2878cf1594f0f0371e1c60968f9ab803 Author: Johan Hovold Date: Thu Apr 8 15:16:01 2021 +0200 USB: cdc-acm: fix unprivileged TIOCCSERIAL [ Upstream commit dd5619582d60007139f0447382d2839f4f9e339b ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. A non-privileged user has only ever been able to set the since long deprecated ASYNC_SPD flags and trying to change any other *supported* feature should result in -EPERM being returned. Setting the current values for any supported features should return success. Fix the cdc-acm implementation which instead indicated that the TIOCSSERIAL ioctl was not even implemented when a non-privileged user set the current values. Fixes: ba2d8ce9db0a ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)") Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210408131602.27956-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a303fd410c78d8b7992a553299aa0b137d311fb9 Author: Colin Ian King Date: Tue Apr 6 19:45:10 2021 +0100 usb: gadget: r8a66597: Add missing null check on return from platform_get_resource [ Upstream commit 9c2076090c2815fe7c49676df68dde7e60a9b9fc ] The call to platform_get_resource can potentially return a NULL pointer on failure, so add this check and return -EINVAL if it fails. Fixes: c41442474a26 ("usb: gadget: R8A66597 peripheral controller support.") Signed-off-by: Colin Ian King Addresses-Coverity: ("Dereference null return") Link: https://lore.kernel.org/r/20210406184510.433497-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8cbd176bf6ae5262c1e3f41459c50490b37ba698 Author: Lv Yunlong Date: Fri Apr 2 10:13:48 2021 -0700 crypto: qat - Fix a double free in adf_create_ring [ Upstream commit f7cae626cabb3350b23722b78fe34dd7a615ca04 ] In adf_create_ring, if the callee adf_init_ring() failed, the callee will free the ring->base_addr by dma_free_coherent() and return -EFAULT. Then adf_create_ring will goto err and the ring->base_addr will be freed again in adf_cleanup_ring(). My patch sets ring->base_addr to NULL after the first freed to avoid the double free. Fixes: a672a9dc872ec ("crypto: qat - Intel(R) QAT transport code") Signed-off-by: Lv Yunlong Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1e56446729adc3937f1a343f419c6d45acb2e02e Author: Colin Ian King Date: Wed Apr 7 16:03:08 2021 +0100 staging: rtl8192u: Fix potential infinite loop [ Upstream commit f9b9263a25dc3d2eaaa829e207434db6951ca7bc ] The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of riv->ieee80211->LinkDetectInfo.SlotNum that is a u16 type. There is a potential infinite loop if SlotNum is larger than the u8 loop counter. Fix this by making the loop counter the same type as SlotNum. Addresses-Coverity: ("Infinite loop") Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210407150308.496623-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6c1f20b8754a320e3bc2f9a13737380626ce380b Author: Giovanni Cabiddu Date: Thu Mar 25 08:34:18 2021 +0000 crypto: qat - fix error path in adf_isr_resource_alloc() [ Upstream commit 83dc1173d73f80cbce2fee4d308f51f87b2f26ae ] The function adf_isr_resource_alloc() is not unwinding correctly in case of error. This patch fixes the error paths and propagate the errors to the caller. Fixes: 7afa232e76ce ("crypto: qat - Intel(R) QAT DH895xcc accelerator") Signed-off-by: Giovanni Cabiddu Reviewed-by: Marco Chiappero Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f4d28d8b9b0e7c4ae04214b8d7e0b0466ec6bcaf Author: Michael Walle Date: Wed Mar 3 16:57:35 2021 +0100 mtd: require write permissions for locking and badblock ioctls [ Upstream commit 1e97743fd180981bef5f01402342bb54bf1c6366 ] MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once. MEMSETBADBLOCK modifies the bad block table. Fixes: f7e6b19bc764 ("mtd: properly check all write ioctls for permissions") Signed-off-by: Michael Walle Reviewed-by: Greg Kroah-Hartman Acked-by: Rafał Miłecki Acked-by: Richard Weinberger Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210303155735.25887-1-michael@walle.cc Signed-off-by: Sasha Levin commit 62455d7943c1ac49911fcda6d1a7bf4f8edb06be Author: Fabian Vogt Date: Wed Mar 24 15:11:15 2021 +0100 fotg210-udc: Complete OUT requests on short packets [ Upstream commit 75bb93be0027123b5db6cbcce89eb62f0f6b3c5b ] A short packet indicates the end of a transfer and marks the request as complete. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-8-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 257f1877074dc58b0a927628ae57294cc109aeee Author: Fabian Vogt Date: Wed Mar 24 15:11:14 2021 +0100 fotg210-udc: Don't DMA more than the buffer can take [ Upstream commit 3e7c2510bdfe89a9ec223dd7acd6bfc8bb1cbeb6 ] Before this, it wrote as much as available into the buffer, even if it didn't fit. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-7-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4542bd78f3dad7a1feb0f14bb3f368d17195532a Author: Fabian Vogt Date: Wed Mar 24 15:11:12 2021 +0100 fotg210-udc: Mask GRP2 interrupts we don't handle [ Upstream commit 9aee3a23d6455200702f3a57e731fa11e8408667 ] Currently it leaves unhandled interrupts unmasked, but those are never acked. In the case of a "device idle" interrupt, this leads to an effectively frozen system until plugging it in. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-5-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e5d0549ed8ea630fa12b1b97a59280bafcb5434a Author: Fabian Vogt Date: Wed Mar 24 15:11:11 2021 +0100 fotg210-udc: Remove a dubious condition leading to fotg210_done [ Upstream commit c7f755b243494d6043aadcd9a2989cb157958b95 ] When the EP0 IN request was not completed but less than a packet sent, it would complete the request successfully. That doesn't make sense and can't really happen as fotg210_start_dma always sends min(length, maxpkt) bytes. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-4-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 232986c3c6658df2275670f498bb108c7d45c6a5 Author: Fabian Vogt Date: Wed Mar 24 15:11:10 2021 +0100 fotg210-udc: Fix EP0 IN requests bigger than two packets [ Upstream commit 078ba935651e149c92c41161e0322e3372cc2705 ] For a 134 Byte packet, it sends the first two 64 Byte packets just fine, but then notice that less than a packet is remaining and call fotg210_done without actually sending the rest. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-3-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 05b001e259c4070d6881a5496e96faa03c10cece Author: Fabian Vogt Date: Wed Mar 24 15:11:09 2021 +0100 fotg210-udc: Fix DMA on EP0 for length > max packet size [ Upstream commit 755915fc28edfc608fa89a163014acb2f31c1e19 ] For a 75 Byte request, it would send the first 64 separately, then detect that the remaining 11 Byte fit into a single DMA, but due to this bug set the length to the original 75 Bytes. This leads to a DMA failure (which is ignored...) and the request completes without the remaining bytes having been sent. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-2-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dfb4663d594a83c4b19ebe2903307804446245fa Author: Tong Zhang Date: Thu Mar 18 23:39:59 2021 -0400 crypto: qat - don't release uninitialized resources [ Upstream commit b66accaab3791e15ac99c92f236d0d3a6d5bd64e ] adf_vf_isr_resource_alloc() is not unwinding correctly when error happens and it want to release uninitialized resources. To fix this, only release initialized resources. [ 1.792845] Trying to free already-free IRQ 11 [ 1.793091] WARNING: CPU: 0 PID: 182 at kernel/irq/manage.c:1821 free_irq+0x202/0x380 [ 1.801340] Call Trace: [ 1.801477] adf_vf_isr_resource_free+0x32/0xb0 [intel_qat] [ 1.801785] adf_vf_isr_resource_alloc+0x14d/0x150 [intel_qat] [ 1.802105] adf_dev_init+0xba/0x140 [intel_qat] Signed-off-by: Tong Zhang Reviewed-by: Andy Shevchenko Fixes: dd0f368398ea ("crypto: qat - Add qat dh895xcc VF driver") Acked-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5f7ed3f51cf2c337f9e7771cfed4dede38a05f4f Author: Andy Shevchenko Date: Tue Mar 23 17:36:22 2021 +0200 usb: gadget: pch_udc: Check for DMA mapping error [ Upstream commit 4a28d77e359009b846951b06f7c0d8eec8dce298 ] DMA mapping might fail, we have to check it with dma_mapping_error(). Otherwise DMA-API is not happy: DMA-API: pch_udc 0000:02:02.4: device driver failed to check map error[device address=0x00000000027ee678] [size=64 bytes] [mapped as single] Fixes: abab0c67c061 ("usb: pch_udc: Fixed issue which does not work with g_serial") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 39bcbca51a7403220bfc7fde582f32539e621e98 Author: Andy Shevchenko Date: Tue Mar 23 17:36:21 2021 +0200 usb: gadget: pch_udc: Check if driver is present before calling ->setup() [ Upstream commit fbdbbe6d3ee502b3bdeb4f255196bb45003614be ] Since we have a separate routine for VBUS sense, the interrupt may occur before gadget driver is present. Hence, ->setup() call may oops the kernel: [ 55.245843] BUG: kernel NULL pointer dereference, address: 00000010 ... [ 55.245843] EIP: pch_udc_isr.cold+0x162/0x33f ... [ 55.245843] [ 55.245843] ? pch_udc_svc_data_out+0x160/0x160 Check if driver is present before calling ->setup(). Fixes: f646cf94520e ("USB device driver of Topcliff PCH") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0493fd0698e645c5b967ae2d0a0a9c2337fb2717 Author: Andy Shevchenko Date: Tue Mar 23 17:36:20 2021 +0200 usb: gadget: pch_udc: Replace cpu_to_le32() by lower_32_bits() [ Upstream commit 91356fed6afd1c83bf0d3df1fc336d54e38f0458 ] Either way ~0 will be in the correct byte order, hence replace cpu_to_le32() by lower_32_bits(). Moreover, it makes sparse happy, otherwise it complains: .../pch_udc.c:1813:27: warning: incorrect type in assignment (different base types) .../pch_udc.c:1813:27: expected unsigned int [usertype] dataptr .../pch_udc.c:1813:27: got restricted __le32 [usertype] Fixes: f646cf94520e ("USB device driver of Topcliff PCH") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 84456c63eec114a765bd073463b79b0bfdd39201 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:25 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Snow [ Upstream commit 8987efbb17c2522be8615085df9a14da2ab53d34 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: c61248afa819 ("ARM: dts: Add max77686 RTC interrupt to cros5250-common") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-9-krzk@kernel.org Signed-off-by: Sasha Levin commit a523cec2d42195615e87cc4fe98262fb7278f628 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:24 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on SMDK5250 [ Upstream commit f6368c60561370e4a92fac22982a3bd656172170 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: 47580e8d94c2 ("ARM: dts: Specify MAX77686 pmic interrupt for exynos5250-smdk5250") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-8-krzk@kernel.org Signed-off-by: Sasha Levin commit 35cc21c271055f777e6d2ddf3edaacbc0bca320b Author: Colin Ian King Date: Tue Feb 23 19:38:21 2021 +0000 memory: gpmc: fix out of bounds read and dereference on gpmc_cs[] [ Upstream commit e004c3e67b6459c99285b18366a71af467d869f5 ] Currently the array gpmc_cs is indexed by cs before it cs is range checked and the pointer read from this out-of-index read is dereferenced. Fix this by performing the range check on cs before the read and the following pointer dereference. Addresses-Coverity: ("Negative array index read") Fixes: 9ed7a776eb50 ("ARM: OMAP2+: Fix support for multiple devices on a GPMC chip select") Signed-off-by: Colin Ian King Reviewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20210223193821.17232-1-colin.king@canonical.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 304e474ebc9914b0ee0db8818992731a799386e4 Author: Andy Shevchenko Date: Tue Mar 23 17:36:24 2021 +0200 usb: gadget: pch_udc: Revert d3cb25a12138 completely commit 50a318cc9b54a36f00beadf77e578a50f3620477 upstream. The commit d3cb25a12138 ("usb: gadget: udc: fix spin_lock in pch_udc") obviously was not thought through and had made the situation even worse than it was before. Two changes after almost reverted it. but a few leftovers have been left as it. With this revert d3cb25a12138 completely. While at it, narrow down the scope of unlocked section to prevent potential race when prot_stall is assigned. Fixes: d3cb25a12138 ("usb: gadget: udc: fix spin_lock in pch_udc") Fixes: 9903b6bedd38 ("usb: gadget: pch-udc: fix lock") Fixes: 1d23d16a88e6 ("usb: gadget: pch_udc: reorder spin_[un]lock to avoid deadlock") Cc: Iago Abal Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-5-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit d9199089758e39577bfc5e38bef212c9553b07fe Author: Claudio Imbrenda Date: Mon Mar 22 15:05:58 2021 +0100 KVM: s390: split kvm_s390_real_to_abs commit c5d1f6b531e68888cbe6718b3f77a60115d58b9c upstream. A new function _kvm_s390_real_to_abs will apply prefixing to a real address with a given prefix value. The old kvm_s390_real_to_abs becomes now a wrapper around the new function. This is needed to avoid code duplication in vSIE. Signed-off-by: Claudio Imbrenda Reviewed-by: David Hildenbrand Reviewed-by: Thomas Huth Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210322140559.500716-2-imbrenda@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit fe837ad770a957c700aa38cb3c9c57d15ded9814 Author: Takashi Iwai Date: Wed Apr 28 13:27:03 2021 +0200 ALSA: hda/realtek: Remove redundant entry for ALC861 Haier/Uniwill devices commit defce244b01ee12534910a4544e11be5eb927d25 upstream. The quirk entry for Uniwill ECS M31EI is with the PCI SSID device 0, which means matching with all. That is, it's essentially equivalent with SND_PCI_QUIRK_VENDOR(0x1584), which also matches with the previous entry for Haier W18 applying the very same quirk. Let's unify them with the single vendor-quirk entry. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-13-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0fb1cb88d812a25b4802ad132108f459ada5dea2 Author: Takashi Iwai Date: Wed Apr 28 13:26:59 2021 +0200 ALSA: hda/realtek: Re-order ALC269 Sony quirk table entries commit cab561f8d4bc9b196ae20c960aa5da89fd786ab5 upstream. Just re-order the alc269_fixup_tbl[] entries for Sony devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-9-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1025351e63fa95896548420f6aac192ed229b510 Author: Takashi Iwai Date: Wed Apr 28 13:26:53 2021 +0200 ALSA: hda/realtek: Re-order ALC882 Sony quirk table entries commit b7529c18feecb1af92f9db08c8e7fe446a82d96d upstream. Just re-order the alc882_fixup_tbl[] entries for Sony devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3c6f2daccb95b5ca08f7181373920e6ef1e5e87c Author: Takashi Iwai Date: Wed Apr 28 13:26:52 2021 +0200 ALSA: hda/realtek: Re-order ALC882 Acer quirk table entries commit b265047ac56bad8c4f3d0c8bf9cb4e828ee0d28e upstream. Just re-order the alc882_fixup_tbl[] entries for Acer devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cde344e0b221f01b7000804733d90ae3da0abe76 Author: Colin Ian King Date: Wed Mar 3 00:27:59 2021 +0000 drm/radeon: fix copy of uninitialized variable back to userspace commit 8dbc2ccac5a65c5b57e3070e36a3dc97c7970d96 upstream. Currently the ioctl command RADEON_INFO_SI_BACKEND_ENABLED_MASK can copy back uninitialised data in value_tmp that pointer *value points to. This can occur when rdev->family is less than CHIP_BONAIRE and less than CHIP_TAHITI. Fix this by adding in a missing -EINVAL so that no invalid value is copied back to userspace. Addresses-Coverity: ("Uninitialized scalar variable) Cc: stable@vger.kernel.org # 3.13+ Fixes: 439a1cfffe2c ("drm/radeon: expose render backend mask to the userspace") Reviewed-by: Christian König Signed-off-by: Colin Ian King Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5c7888013af2d7dae306f11d6bd3daa621c86e05 Author: Johannes Berg Date: Fri Apr 16 09:42:14 2021 +0200 cfg80211: scan: drop entry from hidden_list on overflow commit 010bfbe768f7ecc876ffba92db30432de4997e2a upstream. If we overflow the maximum number of BSS entries and free the new entry, drop it from any hidden_list that it may have been added to in the code above or in cfg80211_combine_bsses(). Reported-by: Dan Carpenter Link: https://lore.kernel.org/r/20210416094212.5de7d1676ad7.Ied283b0bc5f504845e7d6ab90626bdfa68bb3dc0@changeid Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e825dd8a9c0bbe9d88e3c1233dc5610272dd6c1a Author: Dan Carpenter Date: Wed Apr 14 11:29:55 2021 +0300 ipw2x00: potential buffer overflow in libipw_wx_set_encodeext() commit 260a9ad9446723d4063ed802989758852809714d upstream. The "ext->key_len" is a u16 that comes from the user. If it's over SCM_KEY_LEN (32) that could lead to memory corruption. Fixes: e0d369d1d969 ("[PATCH] ieee82011: Added WE-18 support to default wireless extension handler") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Acked-by: Stanislav Yakovlev Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YHaoA1i+8uT4ir4h@mwanda Signed-off-by: Greg Kroah-Hartman commit 9b9597c8708504731243f33d43557b27bbe8ad0e Author: Zhao Heming Date: Sat Apr 3 11:01:25 2021 +0800 md: md_open returns -EBUSY when entering racing area commit 6a4db2a60306eb65bfb14ccc9fde035b74a4b4e7 upstream. commit d3374825ce57 ("md: make devices disappear when they are no longer needed.") introduced protection between mddev creating & removing. The md_open shouldn't create mddev when all_mddevs list doesn't contain mddev. With currently code logic, there will be very easy to trigger soft lockup in non-preempt env. This patch changes md_open returning from -ERESTARTSYS to -EBUSY, which will break the infinitely retry when md_open enter racing area. This patch is partly fix soft lockup issue, full fix needs mddev_find is split into two functions: mddev_find & mddev_find_or_alloc. And md_open should call new mddev_find (it only does searching job). For more detail, please refer with Christoph's "split mddev_find" patch in later commits. *** env *** kvm-qemu VM 2C1G with 2 iscsi luns kernel should be non-preempt *** script *** about trigger every time with below script ``` 1 node1="mdcluster1" 2 node2="mdcluster2" 3 4 mdadm -Ss 5 ssh ${node2} "mdadm -Ss" 6 wipefs -a /dev/sda /dev/sdb 7 mdadm -CR /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda \ /dev/sdb --assume-clean 8 9 for i in {1..10}; do 10 echo ==== $i ====; 11 12 echo "test ...." 13 ssh ${node2} "mdadm -A /dev/md0 /dev/sda /dev/sdb" 14 sleep 1 15 16 echo "clean ....." 17 ssh ${node2} "mdadm -Ss" 18 done ``` I use mdcluster env to trigger soft lockup, but it isn't mdcluster speical bug. To stop md array in mdcluster env will do more jobs than non-cluster array, which will leave enough time/gap to allow kernel to run md_open. *** stack *** ``` [ 884.226509] mddev_put+0x1c/0xe0 [md_mod] [ 884.226515] md_open+0x3c/0xe0 [md_mod] [ 884.226518] __blkdev_get+0x30d/0x710 [ 884.226520] ? bd_acquire+0xd0/0xd0 [ 884.226522] blkdev_get+0x14/0x30 [ 884.226524] do_dentry_open+0x204/0x3a0 [ 884.226531] path_openat+0x2fc/0x1520 [ 884.226534] ? seq_printf+0x4e/0x70 [ 884.226536] do_filp_open+0x9b/0x110 [ 884.226542] ? md_release+0x20/0x20 [md_mod] [ 884.226543] ? seq_read+0x1d8/0x3e0 [ 884.226545] ? kmem_cache_alloc+0x18a/0x270 [ 884.226547] ? do_sys_open+0x1bd/0x260 [ 884.226548] do_sys_open+0x1bd/0x260 [ 884.226551] do_syscall_64+0x5b/0x1e0 [ 884.226554] entry_SYSCALL_64_after_hwframe+0x44/0xa9 ``` *** rootcause *** "mdadm -A" (or other array assemble commands) will start a daemon "mdadm --monitor" by default. When "mdadm -Ss" is running, the stop action will wakeup "mdadm --monitor". The "--monitor" daemon will immediately get info from /proc/mdstat. This time mddev in kernel still exist, so /proc/mdstat still show md device, which makes "mdadm --monitor" to open /dev/md0. The previously "mdadm -Ss" is removing action, the "mdadm --monitor" open action will trigger md_open which is creating action. Racing is happening. ``` : "mdadm -Ss" md_release mddev_put deletes mddev from all_mddevs queue_work for mddev_delayed_delete at this time, "/dev/md0" is still available for opening : "mdadm --monitor ..." md_open + mddev_find can't find mddev of /dev/md0, and create a new mddev and | return. + trigger "if (mddev->gendisk != bdev->bd_disk)" and return -ERESTARTSYS. ``` In non-preempt kernel, is occupying on current CPU. and mddev_delayed_delete which was created in also can't be schedule. In preempt kernel, it can also trigger above racing. But kernel doesn't allow one thread running on a CPU all the time. after running some time, the later "mdadm -A" (refer above script line 13) will call md_alloc to alloc a new gendisk for mddev. it will break md_open statement "if (mddev->gendisk != bdev->bd_disk)" and return 0 to caller, the soft lockup is broken. Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Zhao Heming Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit a96a51965a9bfcdb7b6f1fb32dbec30f8fed4e17 Author: Christoph Hellwig Date: Sat Apr 3 18:15:28 2021 +0200 md: factor out a mddev_find_locked helper from mddev_find commit 8b57251f9a91f5e5a599de7549915d2d226cc3af upstream. Factor out a self-contained helper to just lookup a mddev by the dev_t "unit". Cc: stable@vger.kernel.org Reviewed-by: Heming Zhao Signed-off-by: Christoph Hellwig Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 91ca6f6a91f679c8645d7f3307e03ce86ad518c4 Author: Steven Rostedt (VMware) Date: Fri Apr 30 12:17:58 2021 -0400 tracing: Restructure trace_clock_global() to never block commit aafe104aa9096827a429bc1358f8260ee565b7cc upstream. It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded "prev_time" simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it. Link: https://lkml.kernel.org/r/20210430121758.650b6e8a@gandalf.local.home Cc: stable@vger.kernel.org Tested-by: Konstantin Kharlamov Tested-by: Todd Brandt Fixes: b02414c8f045 ("ring-buffer: Fix recursion protection transitions between interrupt context") # started showing the problem Fixes: 14131f2f98ac3 ("tracing: implement trace_clock_*() APIs") # where the bug happened Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 1769898f23dee402e71d63cbb7ba4b4468369929 Author: Steven Rostedt (VMware) Date: Tue Apr 27 11:32:07 2021 -0400 tracing: Map all PIDs to command lines commit 785e3c0a3a870e72dc530856136ab4c8dd207128 upstream. The default max PID is set by PID_MAX_DEFAULT, and the tracing infrastructure uses this number to map PIDs to the comm names of the tasks, such output of the trace can show names from the recorded PIDs in the ring buffer. This mapping is also exported to user space via the "saved_cmdlines" file in the tracefs directory. But currently the mapping expects the PIDs to be less than PID_MAX_DEFAULT, which is the default maximum and not the real maximum. Recently, systemd will increases the maximum value of a PID on the system, and when tasks are traced that have a PID higher than PID_MAX_DEFAULT, its comm is not recorded. This leads to the entire trace to have "<...>" as the comm name, which is pretty useless. Instead, keep the array mapping the size of PID_MAX_DEFAULT, but instead of just mapping the index to the comm, map a mask of the PID (PID_MAX_DEFAULT - 1) to the comm, and find the full PID from the map_cmdline_to_pid array (that already exists). This bug goes back to the beginning of ftrace, but hasn't been an issue until user space started increasing the maximum value of PIDs. Link: https://lkml.kernel.org/r/20210427113207.3c601884@gandalf.local.home Cc: stable@vger.kernel.org Fixes: bc0c38d139ec7 ("ftrace: latency tracer infrastructure") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 39746bd89b422c30cbd05bf9f9ca144075f291f1 Author: Joel Fernandes Date: Thu Jul 6 16:00:21 2017 -0700 tracing: Treat recording comm for idle task as a success commit eaf260ac04d9b4cf9f458d5c97555bfff2da526e upstream. Currently we stop recording comm for non-idle tasks when switching from/to idle task since we treat that as a record failure. Fix that by treat recording of comm for idle task as a success. Link: http://lkml.kernel.org/r/20170706230023.17942-1-joelaf@google.com Cc: kernel-team@android.com Cc: Ingo Molnar Reported-by: Michael Sartain Signed-off-by: Joel Fernandes Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 150381302389fa01425396489a21dc7c53383a5b Author: Amey Telawane Date: Wed May 3 15:41:14 2017 +0530 tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline() commit e09e28671cda63e6308b31798b997639120e2a21 upstream. Strcpy is inherently not safe, and strlcpy() should be used instead. __trace_find_cmdline() uses strcpy() because the comms saved must have a terminating nul character, but it doesn't hurt to add the extra protection of using strlcpy() instead of strcpy(). Link: http://lkml.kernel.org/r/1493806274-13936-1-git-send-email-amit.pundir@linaro.org Signed-off-by: Amey Telawane [AmitP: Cherry-picked this commit from CodeAurora kernel/msm-3.10 https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=2161ae9a70b12cf18ac8e5952a20161ffbccb477] Signed-off-by: Amit Pundir [ Updated change log and removed the "- 1" from len parameter ] Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 9da15c9a594100ba434246cb29e6fedd1a3eb8bc Author: Tetsuo Handa Date: Fri Apr 2 21:17:42 2021 +0900 misc: vmw_vmci: explicitly initialize vmci_datagram payload commit b2192cfeba8481224da0a4ec3b4a7ccd80b1623b upstream. KMSAN complains that vmci_check_host_caps() left the payload part of check_msg uninitialized. ===================================================== BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 CPU: 1 PID: 1 Comm: swapper/0 Tainted: G B 5.11.0-rc7+ #4 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 Call Trace: dump_stack+0x21c/0x280 kmsan_report+0xfb/0x1e0 kmsan_internal_check_memory+0x202/0x520 kmsan_check_memory+0xd/0x10 iowrite8_rep+0x86/0x380 vmci_guest_probe_device+0xf0b/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Uninit was created at: kmsan_internal_poison_shadow+0x5c/0xf0 kmsan_slab_alloc+0x8d/0xe0 kmem_cache_alloc+0x84f/0xe30 vmci_guest_probe_device+0xd11/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Bytes 28-31 of 36 are uninitialized Memory access of size 36 starts at ffff8881675e5f00 ===================================================== Fixes: 1f166439917b69d3 ("VMCI: guest side driver implementation.") Cc: Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/r/20210402121742.3917-2-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman commit a25152574bd792f0674013905c1f0c6c5a0b9fe5 Author: Tetsuo Handa Date: Fri Apr 2 21:17:41 2021 +0900 misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg struct commit 376565b9717c30cd58ad33860fa42697615fa2e4 upstream. KMSAN complains that the vmci_use_ppn64() == false path in vmci_dbell_register_notification_bitmap() left upper 32bits of bitmap_set_msg.bitmap_ppn64 member uninitialized. ===================================================== BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc7+ #4 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 Call Trace: dump_stack+0x21c/0x280 kmsan_report+0xfb/0x1e0 kmsan_internal_check_memory+0x484/0x520 kmsan_check_memory+0xd/0x10 iowrite8_rep+0x86/0x380 vmci_send_datagram+0x150/0x280 vmci_dbell_register_notification_bitmap+0x133/0x1e0 vmci_guest_probe_device+0xcab/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Local variable ----bitmap_set_msg@vmci_dbell_register_notification_bitmap created at: vmci_dbell_register_notification_bitmap+0x50/0x1e0 vmci_dbell_register_notification_bitmap+0x50/0x1e0 Bytes 28-31 of 32 are uninitialized Memory access of size 32 starts at ffff88810098f570 ===================================================== Fixes: 83e2ec765be03e8a ("VMCI: doorbell implementation.") Cc: Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/r/20210402121742.3917-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman commit fc26191ce9c73a6394e0caf7b52f14c1cf0fd7a9 Author: Hans de Goede Date: Wed Feb 17 11:24:59 2021 +0100 misc: lis3lv02d: Fix false-positive WARN on various HP models commit 3641762c1c9c7cfd84a7061a0a73054f09b412e3 upstream. Before this commit lis3lv02d_get_pwron_wait() had a WARN_ONCE() to catch a potential divide by 0. WARN macros should only be used to catch internal kernel bugs and that is not the case here. We have been receiving a lot of bug reports about kernel backtraces caused by this WARN. The div value being checked comes from the lis3->odrs[] array. Which is sized to be a power-of-2 matching the number of bits in lis3->odr_mask. The only lis3 model where this array is not entirely filled with non zero values. IOW the only model where we can hit the div == 0 check is the 3dc ("8 bits 3DC sensor") model: int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000}; Note the 0 value at index 0, according to the datasheet an odr index of 0 means "Power-down mode". HP typically uses a lis3 accelerometer for HDD fall protection. What I believe is happening here is that on newer HP devices, which only contain a SDD, the BIOS is leaving the lis3 device powered-down since it is not used for HDD fall protection. Note that the lis3_3dc_rates array initializer only specifies 10 values, which matches the datasheet. So it also contains 6 zero values at the end. Replace the WARN with a normal check, which treats an odr index of 0 as power-down and uses a normal dev_err() to report the error in case odr index point past the initialized part of the array. Fixes: 1510dd5954be ("lis3lv02d: avoid divide by zero due to unchecked") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=785814 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1817027 BugLink: https://bugs.centos.org/view.php?id=10720 Link: https://lore.kernel.org/r/20210217102501.31758-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 165216c3c26407a05682b784d706615d8e0ff1b9 Author: Maciej W. Rozycki Date: Wed Mar 10 13:03:09 2021 +0100 FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR commit f626ca682912fab55dff15469ce893ae16b65c7e upstream. Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. For those systems the PCI BARs that request a mapping in the I/O space have the length recorded in the corresponding PCI resource set to zero, which makes it unassigned: # lspci -s 0031:02:04.0 -v 0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02) Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA) Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8 Memory at 620c080020000 (32-bit, non-prefetchable) [size=128] I/O ports at [disabled] Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Kernel driver in use: defxx Kernel modules: defxx # Regardless the driver goes ahead and requests it (here observed with a Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry: # cat /proc/ioports 00000000-ffffffffffffffff : 0031:02:04.0 # Furthermore, the system gets confused as the driver actually continues and pokes at those locations, causing a flood of messages being output to the system console by the underlying system firmware, like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others defxx 0031:02:04.0: enabling device (0140 -> 0142) LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event and so on and so on (possibly intermixed actually, as there's no locking between the kernel and the firmware in console port access with this particular system, but cleaned up above for clarity), and once some 10k of such pairs of the latter two messages have been produced an interace eventually shows up in a useless state: 0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00 This was not expected to happen as resource handling was added to the driver a while ago, because it was not known at that time that a PCI system would be possible that cannot assign port I/O resources, and oddly enough `request_region' does not fail, which would have caught it. Correct the problem then by checking for the length of zero for the CSR resource and bail out gracefully refusing to register an interface if that turns out to be the case, producing messages like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 0031:02:04.0: Cannot use I/O, no address set, aborting 0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y" Keep the original check for the EISA MMIO resource as implemented, because in that case the length is hardwired to 0x400 as a consequence of how the compare/mask address decoding works in the ESIC chip and it is only the base address that is set to zero if MMIO has been disabled for the adapter in EISA configuration, which in turn could be a valid bus address in a legacy-free system implementing PCI, especially for port I/O. Where the EISA MMIO resource has been disabled for the adapter in EISA configuration this arrangement keeps producing messages like: eisa 00:05: EISA: slot 5: DEC3002 detected defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 00:05: Cannot use MMIO, no address set, aborting 00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n" 00:05: Or run ECU and set adapter's MMIO location with the last two lines now swapped for easier handling in the driver. There is no need to check for and catch the case of a port I/O resource not having been assigned for EISA as the adapter uses the slot-specific I/O space, which gets assigned by how EISA has been specified and maps directly to the particular slot an option card has been placed in. And the EISA variant of the adapter has additional registers that are only accessible via the port I/O space anyway. While at it factor out the error message calls into helpers and fix an argument order bug with the `pr_err' call now in `dfx_register_res_err'. Signed-off-by: Maciej W. Rozycki Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management") Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 26157c82ba756767b2bd66d28a71b1bc454447f6 Author: Or Cohen Date: Tue May 4 10:16:46 2021 +0300 net/nfc: fix use-after-free llcp_sock_bind/connect commit c61760e6940dd4039a7f5e84a6afc9cdbf4d82b6 upstream. Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134. Reported-by: Or Cohen Reported-by: Nadav Markus Fixes: c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") Signed-off-by: Or Cohen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9ecbac05a5310eea293314c82de4649df1d0a633 Author: Taehee Yoo Date: Fri Feb 28 18:01:46 2020 +0000 hsr: use netdev_err() instead of WARN_ONCE() commit 4b793acdca0050739b99ace6a8b9e7f717f57c6b upstream. When HSR interface is sending a frame, it finds a node with the destination ethernet address from the list. If there is no node, it calls WARN_ONCE(). But, using WARN_ONCE() for this situation is a little bit overdoing. So, in this patch, the netdev_err() is used instead. Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Cc: George Kennedy Signed-off-by: Greg Kroah-Hartman commit b27a218d166b7f07cd5616fb90e727b6ed662b1a Author: Archie Pusaka Date: Mon Mar 22 14:03:11 2021 +0800 Bluetooth: verify AMP hci_chan before amp_destroy commit 5c4c8c9544099bb9043a10a5318130a943e32fc3 upstream. hci_chan can be created in 2 places: hci_loglink_complete_evt() if it is an AMP hci_chan, or l2cap_conn_add() otherwise. In theory, Only AMP hci_chan should be removed by a call to hci_disconn_loglink_complete_evt(). However, the controller might mess up, call that function, and destroy an hci_chan which is not initiated by hci_loglink_complete_evt(). This patch adds a verification that the destroyed hci_chan must have been init'd by hci_loglink_complete_evt(). Example crash call trace: Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe3/0x144 lib/dump_stack.c:118 print_address_description+0x67/0x22a mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report mm/kasan/report.c:412 [inline] kasan_report+0x251/0x28f mm/kasan/report.c:396 hci_send_acl+0x3b/0x56e net/bluetooth/hci_core.c:4072 l2cap_send_cmd+0x5af/0x5c2 net/bluetooth/l2cap_core.c:877 l2cap_send_move_chan_cfm_icid+0x8e/0xb1 net/bluetooth/l2cap_core.c:4661 l2cap_move_fail net/bluetooth/l2cap_core.c:5146 [inline] l2cap_move_channel_rsp net/bluetooth/l2cap_core.c:5185 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:5464 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5799 [inline] l2cap_recv_frame+0x1d12/0x51aa net/bluetooth/l2cap_core.c:7023 l2cap_recv_acldata+0x2ea/0x693 net/bluetooth/l2cap_core.c:7596 hci_acldata_packet net/bluetooth/hci_core.c:4606 [inline] hci_rx_work+0x2bd/0x45e net/bluetooth/hci_core.c:4796 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Allocated by task 38: set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0x8d/0x9a mm/kasan/kasan.c:553 kmem_cache_alloc_trace+0x102/0x129 mm/slub.c:2787 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] hci_chan_create+0x86/0x26d net/bluetooth/hci_conn.c:1674 l2cap_conn_add.part.0+0x1c/0x814 net/bluetooth/l2cap_core.c:7062 l2cap_conn_add net/bluetooth/l2cap_core.c:7059 [inline] l2cap_connect_cfm+0x134/0x852 net/bluetooth/l2cap_core.c:7381 hci_connect_cfm+0x9d/0x122 include/net/bluetooth/hci_core.h:1404 hci_remote_ext_features_evt net/bluetooth/hci_event.c:4161 [inline] hci_event_packet+0x463f/0x72fa net/bluetooth/hci_event.c:5981 hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Freed by task 1732: set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free mm/kasan/kasan.c:521 [inline] __kasan_slab_free+0x106/0x128 mm/kasan/kasan.c:493 slab_free_hook mm/slub.c:1409 [inline] slab_free_freelist_hook+0xaa/0xf6 mm/slub.c:1436 slab_free mm/slub.c:3009 [inline] kfree+0x182/0x21e mm/slub.c:3972 hci_disconn_loglink_complete_evt net/bluetooth/hci_event.c:4891 [inline] hci_event_packet+0x6a1c/0x72fa net/bluetooth/hci_event.c:6050 hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 The buggy address belongs to the object at ffff8881d7af9180 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 24 bytes inside of 128-byte region [ffff8881d7af9180, ffff8881d7af9200) The buggy address belongs to the page: page:ffffea00075ebe40 count:1 mapcount:0 mapping:ffff8881da403200 index:0x0 flags: 0x8000000000000200(slab) raw: 8000000000000200 dead000000000100 dead000000000200 ffff8881da403200 raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881d7af9080: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ffff8881d7af9100: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff8881d7af9180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881d7af9200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881d7af9280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Signed-off-by: Archie Pusaka Reported-by: syzbot+98228e7407314d2d4ba2@syzkaller.appspotmail.com Reviewed-by: Alain Michaud Reviewed-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann Cc: George Kennedy Signed-off-by: Greg Kroah-Hartman commit e9ebaaa29eec65d80b19fc6ed4d2c408085217e2 Author: Joe Thornber Date: Tue Apr 13 09:11:53 2021 +0100 dm space map common: fix division bug in sm_ll_find_free_block() commit 5208692e80a1f3c8ce2063a22b675dd5589d1d80 upstream. This division bug meant the search for free metadata space could skip the final allocation bitmap's worth of entries. Fix affects DM thinp, cache and era targets. Cc: stable@vger.kernel.org Signed-off-by: Joe Thornber Tested-by: Ming-Hung Tsai Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit e9a972de2d22d030318ad468123f06c2d1fbb1c6 Author: Joe Thornber Date: Mon Mar 29 16:34:57 2021 +0100 dm persistent data: packed struct should have an aligned() attribute too commit a88b2358f1da2c9f9fcc432f2e0a79617fea397c upstream. Otherwise most non-x86 architectures (e.g. riscv, arm) will resort to byte-by-byte access. Cc: stable@vger.kernel.org Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit a50a50bfa29c761611f9e84ed4fd16ecd962b289 Author: Dean Anderson Date: Wed Mar 17 15:41:09 2021 -0700 usb: gadget/function/f_fs string table fix for multiple languages commit 55b74ce7d2ce0b0058f3e08cab185a0afacfe39e upstream. Fixes bug with the handling of more than one language in the string table in f_fs.c. str_count was not reset for subsequent language codes. str_count-- "rolls under" and processes u32 max strings on the processing of the second language entry. The existing bug can be reproduced by adding a second language table to the structure "strings" in tools/usb/ffs-test.c. Signed-off-by: Dean Anderson Link: https://lore.kernel.org/r/20210317224109.21534-1-dean@sensoray.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit b7b1a11d2c42fe6003b39491004c413bbdfb5d28 Author: Anirudh Rayabharam Date: Mon Apr 19 09:07:08 2021 +0530 usb: gadget: dummy_hcd: fix gpf in gadget_setup commit 4a5d797a9f9c4f18585544237216d7812686a71f upstream. Fix a general protection fault reported by syzbot due to a race between gadget_setup() and gadget_unbind() in raw_gadget. The gadget core is supposed to guarantee that there won't be any more callbacks to the gadget driver once the driver's unbind routine is called. That guarantee is enforced in usb_gadget_remove_driver as follows: usb_gadget_disconnect(udc->gadget); if (udc->gadget->irq) synchronize_irq(udc->gadget->irq); udc->driver->unbind(udc->gadget); usb_gadget_udc_stop(udc); usb_gadget_disconnect turns off the pullup resistor, telling the host that the gadget is no longer connected and preventing the transmission of any more USB packets. Any packets that have already been received are sure to processed by the UDC driver's interrupt handler by the time synchronize_irq returns. But this doesn't work with dummy_hcd, because dummy_hcd doesn't use interrupts; it uses a timer instead. It does have code to emulate the effect of synchronize_irq, but that code doesn't get invoked at the right time -- it currently runs in usb_gadget_udc_stop, after the unbind callback instead of before. Indeed, there's no way for usb_gadget_remove_driver to invoke this code before the unbind callback. To fix this, move the synchronize_irq() emulation code to dummy_pullup so that it runs before unbind. Also, add a comment explaining why it is necessary to have it there. Reported-by: syzbot+eb4674092e6cc8d9e0bd@syzkaller.appspotmail.com Suggested-by: Alan Stern Acked-by: Alan Stern Signed-off-by: Anirudh Rayabharam Link: https://lore.kernel.org/r/20210419033713.3021-1-mail@anirudhrb.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit a2a9862e59d11f7fd11bcefb89e3db5a8108578f Author: Fengnan Chang Date: Fri Apr 2 18:16:31 2021 +0800 ext4: fix error code in ext4_commit_super commit f88f1466e2a2e5ca17dfada436d3efa1b03a3972 upstream. We should set the error code when ext4_commit_super check argument failed. Found in code review. Fixes: c4be0c1dc4cdc ("filesystem freeze: add error handling of write_super_lockfs/unlockfs"). Cc: stable@kernel.org Signed-off-by: Fengnan Chang Reviewed-by: Andreas Dilger Link: https://lore.kernel.org/r/20210402101631.561-1-changfengnan@vivo.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 539ba4ebc467260225898e67ea53cbb73308f894 Author: Zhang Yi Date: Wed Mar 31 20:15:16 2021 +0800 ext4: fix check to prevent false positive report of incorrect used inodes commit a149d2a5cabbf6507a7832a1c4fd2593c55fd450 upstream. Commit <50122847007> ("ext4: fix check to prevent initializing reserved inodes") check the block group zero and prevent initializing reserved inodes. But in some special cases, the reserved inode may not all belong to the group zero, it may exist into the second group if we format filesystem below. mkfs.ext4 -b 4096 -g 8192 -N 1024 -I 4096 /dev/sda So, it will end up triggering a false positive report of a corrupted file system. This patch fix it by avoid check reserved inodes if no free inode blocks will be zeroed. Cc: stable@kernel.org Fixes: 50122847007 ("ext4: fix check to prevent initializing reserved inodes") Signed-off-by: Zhang Yi Suggested-by: Jan Kara Link: https://lore.kernel.org/r/20210331121516.2243099-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 24cd31752f47699b89b4b3471155c8e599a1a23a Author: Steven Rostedt (VMware) Date: Wed May 5 10:38:24 2021 -0400 ftrace: Handle commands when closing set_ftrace_filter file commit 8c9af478c06bb1ab1422f90d8ecbc53defd44bc3 upstream. # echo switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter will cause switch_mm to stop tracing by the traceoff command. # echo -n switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter does nothing. The reason is that the parsing in the write function only processes commands if it finished parsing (there is white space written after the command). That's to handle: write(fd, "switch_mm:", 10); write(fd, "traceoff", 8); cases, where the command is broken over multiple writes. The problem is if the file descriptor is closed, then the write call is not processed, and the command needs to be processed in the release code. The release code can handle matching of functions, but does not handle commands. Cc: stable@vger.kernel.org Fixes: eda1e32855656 ("tracing: handle broken names in ftrace filter") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit b846e5b7fafddea690d6a0d69b71adcaa5a2beab Author: Yang Yang Date: Thu Jan 28 02:55:35 2021 -0800 jffs2: check the validity of dstlen in jffs2_zlib_compress() commit 90ada91f4610c5ef11bc52576516d96c496fc3f1 upstream. KASAN reports a BUG when download file in jffs2 filesystem.It is because when dstlen == 1, cpage_out will write array out of bounds. Actually, data will not be compressed in jffs2_zlib_compress() if data's length less than 4. [ 393.799778] BUG: KASAN: slab-out-of-bounds in jffs2_rtime_compress+0x214/0x2f0 at addr ffff800062e3b281 [ 393.809166] Write of size 1 by task tftp/2918 [ 393.813526] CPU: 3 PID: 2918 Comm: tftp Tainted: G B 4.9.115-rt93-EMBSYS-CGEL-6.1.R6-dirty #1 [ 393.823173] Hardware name: LS1043A RDB Board (DT) [ 393.827870] Call trace: [ 393.830322] [] dump_backtrace+0x0/0x2f0 [ 393.835721] [] show_stack+0x14/0x20 [ 393.840774] [] dump_stack+0x90/0xb0 [ 393.845829] [] kasan_object_err+0x24/0x80 [ 393.851402] [] kasan_report_error+0x1b4/0x4d8 [ 393.857323] [] kasan_report+0x38/0x40 [ 393.862548] [] __asan_store1+0x4c/0x58 [ 393.867859] [] jffs2_rtime_compress+0x214/0x2f0 [ 393.873955] [] jffs2_selected_compress+0x178/0x2a0 [ 393.880308] [] jffs2_compress+0x58/0x478 [ 393.885796] [] jffs2_write_inode_range+0x13c/0x450 [ 393.892150] [] jffs2_write_end+0x2a8/0x4a0 [ 393.897811] [] generic_perform_write+0x1c0/0x280 [ 393.903990] [] __generic_file_write_iter+0x1c4/0x228 [ 393.910517] [] generic_file_write_iter+0x138/0x288 [ 393.916870] [] __vfs_write+0x1b4/0x238 [ 393.922181] [] vfs_write+0xd0/0x238 [ 393.927232] [] SyS_write+0xa0/0x110 [ 393.932283] [] __sys_trace_return+0x0/0x4 [ 393.937851] Object at ffff800062e3b280, in cache kmalloc-64 size: 64 [ 393.944197] Allocated: [ 393.946552] PID = 2918 [ 393.948913] save_stack_trace_tsk+0x0/0x220 [ 393.953096] save_stack_trace+0x18/0x20 [ 393.956932] kasan_kmalloc+0xd8/0x188 [ 393.960594] __kmalloc+0x144/0x238 [ 393.963994] jffs2_selected_compress+0x48/0x2a0 [ 393.968524] jffs2_compress+0x58/0x478 [ 393.972273] jffs2_write_inode_range+0x13c/0x450 [ 393.976889] jffs2_write_end+0x2a8/0x4a0 [ 393.980810] generic_perform_write+0x1c0/0x280 [ 393.985251] __generic_file_write_iter+0x1c4/0x228 [ 393.990040] generic_file_write_iter+0x138/0x288 [ 393.994655] __vfs_write+0x1b4/0x238 [ 393.998228] vfs_write+0xd0/0x238 [ 394.001543] SyS_write+0xa0/0x110 [ 394.004856] __sys_trace_return+0x0/0x4 [ 394.008684] Freed: [ 394.010691] PID = 2918 [ 394.013051] save_stack_trace_tsk+0x0/0x220 [ 394.017233] save_stack_trace+0x18/0x20 [ 394.021069] kasan_slab_free+0x88/0x188 [ 394.024902] kfree+0x6c/0x1d8 [ 394.027868] jffs2_sum_write_sumnode+0x2c4/0x880 [ 394.032486] jffs2_do_reserve_space+0x198/0x598 [ 394.037016] jffs2_reserve_space+0x3f8/0x4d8 [ 394.041286] jffs2_write_inode_range+0xf0/0x450 [ 394.045816] jffs2_write_end+0x2a8/0x4a0 [ 394.049737] generic_perform_write+0x1c0/0x280 [ 394.054179] __generic_file_write_iter+0x1c4/0x228 [ 394.058968] generic_file_write_iter+0x138/0x288 [ 394.063583] __vfs_write+0x1b4/0x238 [ 394.067157] vfs_write+0xd0/0x238 [ 394.070470] SyS_write+0xa0/0x110 [ 394.073783] __sys_trace_return+0x0/0x4 [ 394.077612] Memory state around the buggy address: [ 394.082404] ffff800062e3b180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ 394.089623] ffff800062e3b200: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ 394.096842] >ffff800062e3b280: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 394.104056] ^ [ 394.107283] ffff800062e3b300: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 394.114502] ffff800062e3b380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 394.121718] ================================================================== Signed-off-by: Yang Yang Cc: Joel Stanley Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 412b696c0f1e840dc99a36cff7c72156184755e5 Author: Tony Ambardar Date: Thu Sep 17 06:54:37 2020 -0700 powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h commit 7de21e679e6a789f3729e8402bc440b623a28eae upstream. A few archs like powerpc have different errno.h values for macros EDEADLOCK and EDEADLK. In code including both libc and linux versions of errno.h, this can result in multiple definitions of EDEADLOCK in the include chain. Definitions to the same value (e.g. seen with mips) do not raise warnings, but on powerpc there are redefinitions changing the value, which raise warnings and errors (if using "-Werror"). Guard against these redefinitions to avoid build errors like the following, first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with musl 1.1.24: In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5, from ../../include/linux/err.h:8, from libbpf.c:29: ../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined [-Werror] #define EDEADLOCK EDEADLK In file included from toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10, from libbpf.c:26: toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this is the location of the previous definition #define EDEADLOCK 58 cc1: all warnings being treated as errors Cc: Stable Reported-by: Rosen Penev Signed-off-by: Tony Ambardar Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200917135437.1238787-1-Tony.Ambardar@gmail.com Signed-off-by: Greg Kroah-Hartman commit f407f2090d394d97230d5cbbf27d3fdebd227b1e Author: Mahesh Salgaonkar Date: Mon Apr 12 13:22:50 2021 +0530 powerpc/eeh: Fix EEH handling for hugepages in ioremap space. commit 5ae5bc12d0728db60a0aa9b62160ffc038875f1a upstream. During the EEH MMIO error checking, the current implementation fails to map the (virtual) MMIO address back to the pci device on radix with hugepage mappings for I/O. This results into failure to dispatch EEH event with no recovery even when EEH capability has been enabled on the device. eeh_check_failure(token) # token = virtual MMIO address addr = eeh_token_to_phys(token); edev = eeh_addr_cache_get_dev(addr); if (!edev) return 0; eeh_dev_check_failure(edev); <= Dispatch the EEH event In case of hugepage mappings, eeh_token_to_phys() has a bug in virt -> phys translation that results in wrong physical address, which is then passed to eeh_addr_cache_get_dev() to match it against cached pci I/O address ranges to get to a PCI device. Hence, it fails to find a match and the EEH event never gets dispatched leaving the device in failed state. The commit 33439620680be ("powerpc/eeh: Handle hugepages in ioremap space") introduced following logic to translate virt to phys for hugepage mappings: eeh_token_to_phys(): + pa = pte_pfn(*ptep); + + /* On radix we can do hugepage mappings for io, so handle that */ + if (hugepage_shift) { + pa <<= hugepage_shift; <= This is wrong + pa |= token & ((1ul << hugepage_shift) - 1); + } This patch fixes the virt -> phys translation in eeh_token_to_phys() function. $ cat /sys/kernel/debug/powerpc/eeh_address_cache mem addr range [0x0000040080000000-0x00000400807fffff]: 0030:01:00.1 mem addr range [0x0000040080800000-0x0000040080ffffff]: 0030:01:00.1 mem addr range [0x0000040081000000-0x00000400817fffff]: 0030:01:00.0 mem addr range [0x0000040081800000-0x0000040081ffffff]: 0030:01:00.0 mem addr range [0x0000040082000000-0x000004008207ffff]: 0030:01:00.1 mem addr range [0x0000040082080000-0x00000400820fffff]: 0030:01:00.0 mem addr range [0x0000040082100000-0x000004008210ffff]: 0030:01:00.1 mem addr range [0x0000040082110000-0x000004008211ffff]: 0030:01:00.0 Above is the list of cached io address ranges of pci 0030:01:00.. Before this patch: Tracing 'arg1' of function eeh_addr_cache_get_dev() during error injection clearly shows that 'addr=' contains wrong physical address: kworker/u16:0-7 [001] .... 108.883775: eeh_addr_cache_get_dev: (eeh_addr_cache_get_dev+0xc/0xf0) addr=0x80103000a510 dmesg shows no EEH recovery messages: [ 108.563768] bnx2x: [bnx2x_timer:5801(eth2)]MFW seems hanged: drv_pulse (0x9ae) != mcp_pulse (0x7fff) [ 108.563788] bnx2x: [bnx2x_hw_stats_update:870(eth2)]NIG timer max (4294967295) [ 108.883788] bnx2x: [bnx2x_acquire_hw_lock:2013(eth1)]lock_status 0xffffffff resource_bit 0x1 [ 108.884407] bnx2x 0030:01:00.0 eth1: MDC/MDIO access timeout [ 108.884976] bnx2x 0030:01:00.0 eth1: MDC/MDIO access timeout <..> After this patch: eeh_addr_cache_get_dev() trace shows correct physical address: -0 [001] ..s. 1043.123828: eeh_addr_cache_get_dev: (eeh_addr_cache_get_dev+0xc/0xf0) addr=0x40080bc7cd8 dmesg logs shows EEH recovery getting triggerred: [ 964.323980] bnx2x: [bnx2x_timer:5801(eth2)]MFW seems hanged: drv_pulse (0x746f) != mcp_pulse (0x7fff) [ 964.323991] EEH: Recovering PHB#30-PE#10000 [ 964.324002] EEH: PE location: N/A, PHB location: N/A [ 964.324006] EEH: Frozen PHB#30-PE#10000 detected <..> Fixes: 33439620680b ("powerpc/eeh: Handle hugepages in ioremap space") Cc: stable@vger.kernel.org # v5.3+ Reported-by: Dominic DeMarco Signed-off-by: Mahesh Salgaonkar Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/161821396263.48361.2796709239866588652.stgit@jupiter Signed-off-by: Greg Kroah-Hartman commit 8a86df43fe1524e91c6df35d339962afa4ec53b9 Author: lizhe Date: Thu Mar 18 11:06:57 2021 +0800 jffs2: Fix kasan slab-out-of-bounds problem commit 960b9a8a7676b9054d8b46a2c7db52a0c8766b56 upstream. KASAN report a slab-out-of-bounds problem. The logs are listed below. It is because in function jffs2_scan_dirent_node, we alloc "checkedlen+1" bytes for fd->name and we check crc with length rd->nsize. If checkedlen is less than rd->nsize, it will cause the slab-out-of-bounds problem. jffs2: Dirent at *** has zeroes in name. Truncating to %d char ================================================================== BUG: KASAN: slab-out-of-bounds in crc32_le+0x1ce/0x260 at addr ffff8800842cf2d1 Read of size 1 by task test_JFFS2/915 ============================================================================= BUG kmalloc-64 (Tainted: G B O ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in jffs2_alloc_full_dirent+0x2a/0x40 age=0 cpu=1 pid=915 ___slab_alloc+0x580/0x5f0 __slab_alloc.isra.24+0x4e/0x64 __kmalloc+0x170/0x300 jffs2_alloc_full_dirent+0x2a/0x40 jffs2_scan_eraseblock+0x1ca4/0x3b64 jffs2_scan_medium+0x285/0xfe0 jffs2_do_mount_fs+0x5fb/0x1bbc jffs2_do_fill_super+0x245/0x6f0 jffs2_fill_super+0x287/0x2e0 mount_mtd_aux.isra.0+0x9a/0x144 mount_mtd+0x222/0x2f0 jffs2_mount+0x41/0x60 mount_fs+0x63/0x230 vfs_kern_mount.part.6+0x6c/0x1f4 do_mount+0xae8/0x1940 SyS_mount+0x105/0x1d0 INFO: Freed in jffs2_free_full_dirent+0x22/0x40 age=27 cpu=1 pid=915 __slab_free+0x372/0x4e4 kfree+0x1d4/0x20c jffs2_free_full_dirent+0x22/0x40 jffs2_build_remove_unlinked_inode+0x17a/0x1e4 jffs2_do_mount_fs+0x1646/0x1bbc jffs2_do_fill_super+0x245/0x6f0 jffs2_fill_super+0x287/0x2e0 mount_mtd_aux.isra.0+0x9a/0x144 mount_mtd+0x222/0x2f0 jffs2_mount+0x41/0x60 mount_fs+0x63/0x230 vfs_kern_mount.part.6+0x6c/0x1f4 do_mount+0xae8/0x1940 SyS_mount+0x105/0x1d0 entry_SYSCALL_64_fastpath+0x1e/0x97 Call Trace: [] dump_stack+0x59/0x7e [] print_trailer+0x125/0x1b0 [] object_err+0x34/0x40 [] kasan_report.part.1+0x21f/0x534 [] ? vprintk+0x2d/0x40 [] ? crc32_le+0x1ce/0x260 [] kasan_report+0x26/0x30 [] __asan_load1+0x3d/0x50 [] crc32_le+0x1ce/0x260 [] ? jffs2_alloc_full_dirent+0x2a/0x40 [] jffs2_scan_eraseblock+0x1d0c/0x3b64 [] ? jffs2_scan_medium+0xccf/0xfe0 [] ? jffs2_scan_make_ino_cache+0x14c/0x14c [] ? kasan_unpoison_shadow+0x35/0x50 [] ? kasan_unpoison_shadow+0x35/0x50 [] ? kasan_kmalloc+0x5e/0x70 [] ? kmem_cache_alloc_trace+0x10c/0x2cc [] ? mtd_point+0xf7/0x130 [] jffs2_scan_medium+0x285/0xfe0 [] ? jffs2_scan_eraseblock+0x3b64/0x3b64 [] ? kasan_unpoison_shadow+0x35/0x50 [] ? kasan_unpoison_shadow+0x35/0x50 [] ? kasan_kmalloc+0x5e/0x70 [] ? __kmalloc+0x12b/0x300 [] ? kasan_kmalloc+0x5e/0x70 [] ? jffs2_sum_init+0x9f/0x240 [] jffs2_do_mount_fs+0x5fb/0x1bbc [] ? jffs2_del_noinode_dirent+0x640/0x640 [] ? kasan_kmalloc+0x5e/0x70 [] ? __init_rwsem+0x97/0xac [] jffs2_do_fill_super+0x245/0x6f0 [] jffs2_fill_super+0x287/0x2e0 [] ? jffs2_parse_options+0x594/0x594 [] mount_mtd_aux.isra.0+0x9a/0x144 [] mount_mtd+0x222/0x2f0 [] ? jffs2_parse_options+0x594/0x594 [] ? mount_mtd_aux.isra.0+0x144/0x144 [] ? free_pages+0x13/0x1c [] ? selinux_sb_copy_data+0x278/0x2e0 [] jffs2_mount+0x41/0x60 [] mount_fs+0x63/0x230 [] ? alloc_vfsmnt+0x32f/0x3b0 [] vfs_kern_mount.part.6+0x6c/0x1f4 [] do_mount+0xae8/0x1940 [] ? audit_filter_rules.constprop.6+0x1d10/0x1d10 [] ? copy_mount_string+0x40/0x40 [] ? alloc_pages_current+0xa4/0x1bc [] ? __get_free_pages+0x25/0x50 [] ? copy_mount_options.part.17+0x183/0x264 [] SyS_mount+0x105/0x1d0 [] ? copy_mnt_ns+0x560/0x560 [] ? msa_space_switch_handler+0x13d/0x190 [] entry_SYSCALL_64_fastpath+0x1e/0x97 [] ? msa_space_switch+0xb0/0xe0 Memory state around the buggy address: ffff8800842cf180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800842cf200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8800842cf280: fc fc fc fc fc fc 00 00 00 00 01 fc fc fc fc fc ^ ffff8800842cf300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800842cf380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Cc: stable@vger.kernel.org Reported-by: Kunkun Xu Signed-off-by: lizhe Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit b1d7280f9ba1bfdbc3af5bdb82e51f014854f26f Author: Davide Caratti Date: Wed Apr 28 15:23:07 2021 +0200 openvswitch: fix stack OOB read while fragmenting IPv4 packets commit 7c0ea5930c1c211931819d83cfb157bff1539a4c upstream. running openvswitch on kernels built with KASAN, it's possible to see the following splat while testing fragmentation of IPv4 packets: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 The buggy address belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: ovs_fragment+0x0/0x840 [openvswitch] this frame has 2 objects: [32, 144) 'ovs_dst' [192, 424) 'ovs_rt' Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in ovs_fragment(), similarly to what is done for IPv6 few lines below. Fixes: d52e5a7e7ca4 ("ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmt") Cc: Acked-by: Eelco Chaudron Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 128f87f29f02f7b544a428f1990290b4b3586a38 Author: Bill Wendling Date: Fri Apr 23 13:51:59 2021 -0700 arm64/vdso: Discard .note.gnu.property sections in vDSO [ Upstream commit 388708028e6937f3fc5fc19aeeb847f8970f489c ] The arm64 assembler in binutils 2.32 and above generates a program property note in a note section, .note.gnu.property, to encode used x86 ISAs and features. But the kernel linker script only contains a single NOTE segment: PHDRS { text PT_LOAD FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */ dynamic PT_DYNAMIC FLAGS(4); /* PF_R */ note PT_NOTE FLAGS(4); /* PF_R */ } The NOTE segment generated by the vDSO linker script is aligned to 4 bytes. But the .note.gnu.property section must be aligned to 8 bytes on arm64. $ readelf -n vdso64.so Displaying notes found in: .note Owner Data size Description Linux 0x00000004 Unknown note type: (0x00000000) description data: 06 00 00 00 readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20 readelf: Warning: type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8 Since the note.gnu.property section in the vDSO is not checked by the dynamic linker, discard the .note.gnu.property sections in the vDSO. Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property sections in vDSO"), but for arm64. Signed-off-by: Bill Wendling Reviewed-by: Kees Cook Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20210423205159.830854-1-morbo@google.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 051f18d291e801f48199eab53abcaeb5511a6e2e Author: Lv Yunlong Date: Mon Apr 26 07:55:41 2021 -0700 ALSA: sb: Fix two use after free in snd_sb_qsound_build commit 4fb44dd2c1dda18606348acdfdb97e8759dde9df upstream. In snd_sb_qsound_build, snd_ctl_add(..,p->qsound_switch...) and snd_ctl_add(..,p->qsound_space..) are called. But the second arguments of snd_ctl_add() could be freed via snd_ctl_add_replace() ->snd_ctl_free_one(). After the error code is returned, snd_sb_qsound_destroy(p) is called in __error branch. But in snd_sb_qsound_destroy(), the freed p->qsound_switch and p->qsound_space are still used by snd_ctl_remove(). My patch set p->qsound_switch and p->qsound_space to NULL if snd_ctl_add() failed to avoid the uaf bugs. But these codes need to further be improved with the code style. Signed-off-by: Lv Yunlong Cc: Link: https://lore.kernel.org/r/20210426145541.8070-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit adcdc6e36fd07a27e6e4288b3881c70d900b0e46 Author: Lv Yunlong Date: Mon Apr 26 06:11:29 2021 -0700 ALSA: emu8000: Fix a use after free in snd_emu8000_create_mixer commit 1c98f574403dbcf2eb832d5535a10d967333ef2d upstream. Our code analyzer reported a uaf. In snd_emu8000_create_mixer, the callee snd_ctl_add(..,emu->controls[i]) calls snd_ctl_add_replace(.., kcontrol,..). Inside snd_ctl_add_replace(), if error happens, kcontrol will be freed by snd_ctl_free_one(kcontrol). Then emu->controls[i] points to a freed memory, and the execution comes to __error branch of snd_emu8000_create_mixer. The freed emu->controls[i] is used in snd_ctl_remove(card, emu->controls[i]). My patch set emu->controls[i] to NULL if snd_ctl_add() failed to avoid the uaf. Signed-off-by: Lv Yunlong Cc: Link: https://lore.kernel.org/r/20210426131129.4796-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d27ab1d6b07225bcbfa7d853e226d9ad7b7f42e0 Author: Bart Van Assche Date: Thu Apr 15 15:08:13 2021 -0700 scsi: libfc: Fix a format specifier [ Upstream commit 90d6697810f06aceea9de71ad836a8c7669789cd ] Since the 'mfs' member has been declared as 'u32' in include/scsi/libfc.h, use the %u format specifier instead of %hu. This patch fixes the following clang compiler warning: warning: format specifies type 'unsigned short' but the argument has type 'u32' (aka 'unsigned int') [-Wformat] "lport->mfs:%hu\n", mfs, lport->mfs); ~~~ ^~~~~~~~~~ %u Link: https://lore.kernel.org/r/20210415220826.29438-8-bvanassche@acm.org Cc: Hannes Reinecke Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 32eee2ab90f96ce953d277ae02d9cd24b8839f99 Author: James Smart Date: Sun Apr 11 18:31:13 2021 -0700 scsi: lpfc: Fix crash when a REG_RPI mailbox fails triggering a LOGO response [ Upstream commit fffd18ec6579c2d9c72b212169259062fe747888 ] Fix a crash caused by a double put on the node when the driver completed an ACC for an unsolicted abort on the same node. The second put was executed by lpfc_nlp_not_used() and is wrong because the completion routine executes the nlp_put when the iocbq was released. Additionally, the driver is issuing a LOGO then immediately calls lpfc_nlp_set_state to put the node into NPR. This call does nothing. Remove the lpfc_nlp_not_used call and additional set_state in the completion routine. Remove the lpfc_nlp_set_state post issue_logo. Isn't necessary. Link: https://lore.kernel.org/r/20210412013127.2387-3-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5cd5fd30c198e3b83c07b888140a93f6ff1c3343 Author: Guchun Chen Date: Tue Mar 30 17:52:18 2021 +0800 drm/amdgpu: fix NULL pointer dereference [ Upstream commit 3c3dc654333f6389803cdcaf03912e94173ae510 ] ttm->sg needs to be checked before accessing its child member. Call Trace: amdgpu_ttm_backend_destroy+0x12/0x70 [amdgpu] ttm_bo_cleanup_memtype_use+0x3a/0x60 [ttm] ttm_bo_release+0x17d/0x300 [ttm] amdgpu_bo_unref+0x1a/0x30 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x78b/0x8b0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x118/0x220 [amdgpu] kfd_ioctl+0x222/0x400 [amdgpu] ? kfd_dev_is_large_bar+0x90/0x90 [amdgpu] __x64_sys_ioctl+0x8e/0xd0 ? __context_tracking_exit+0x52/0x90 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f97f264d317 Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdb402c338 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f97f3cc63a0 RCX: 00007f97f264d317 RDX: 00007ffdb402c380 RSI: 00000000c0284b16 RDI: 0000000000000003 RBP: 00007ffdb402c380 R08: 00007ffdb402c428 R09: 00000000c4000004 R10: 00000000c4000004 R11: 0000000000000246 R12: 00000000c0284b16 R13: 0000000000000003 R14: 00007f97f3cc63a0 R15: 00007f8836200000 Signed-off-by: Guchun Chen Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 69bdad127926eb25bcd78a6a3ecd7e37782ba2ae Author: Marijn Suijten Date: Tue Apr 6 23:47:24 2021 +0200 drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal [ Upstream commit 2ad52bdb220de5ab348098e3482b01235d15a842 ] Leaving this at a close-to-maximum register value 0xFFF0 means it takes very long for the MDSS to generate a software vsync interrupt when the hardware TE interrupt doesn't arrive. Configuring this to double the vtotal (like some downstream kernels) leads to a frame to take at most twice before the vsync signal, until hardware TE comes up. In this case the hardware interrupt responsible for providing this signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at all. This solves severe panel update issues observed on at least the Xperia Loire and Tone series, until said gpio is properly hooked up to an irq. Suggested-by: AngeloGioacchino Del Regno Signed-off-by: Marijn Suijten Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20210406214726.131534-2-marijn.suijten@somainline.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 213c6ba76578a9a7f3a57116394a4d5f5fbd9bd6 Author: Hans Verkuil Date: Thu Apr 8 12:31:20 2021 +0200 media: gscpa/stv06xx: fix memory leak [ Upstream commit 4f4e6644cd876c844cdb3bea2dd7051787d5ae25 ] For two of the supported sensors the stv06xx driver allocates memory which is stored in sd->sensor_priv. This memory is freed on a disconnect, but if the probe() fails, then it isn't freed and so this leaks memory. Add a new probe_error() op that drivers can use to free any allocated memory in case there was a probe failure. Thanks to Pavel Skripkin for discovering the cause of the memory leak. Reported-and-tested-by: syzbot+e7f4c64a4248a0340c37@syzkaller.appspotmail.com Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 894a7af3a037ff134b1ba23e946ff5d321c53c30 Author: Pavel Skripkin Date: Sun Mar 28 21:32:19 2021 +0200 media: dvb-usb: fix memory leak in dvb_usb_adapter_init [ Upstream commit b7cd0da982e3043f2eec7235ac5530cb18d6af1d ] syzbot reported memory leak in dvb-usb. The problem was in invalid error handling in dvb_usb_adapter_init(). for (n = 0; n < d->props.num_adapters; n++) { .... if ((ret = dvb_usb_adapter_stream_init(adap)) || (ret = dvb_usb_adapter_dvb_init(adap, adapter_nrs)) || (ret = dvb_usb_adapter_frontend_init(adap))) { return ret; } ... d->num_adapters_initialized++; ... } In case of error in dvb_usb_adapter_dvb_init() or dvb_usb_adapter_dvb_init() d->num_adapters_initialized won't be incremented, but dvb_usb_adapter_exit() relies on it: for (n = 0; n < d->num_adapters_initialized; n++) So, allocated objects won't be freed. Signed-off-by: Pavel Skripkin Reported-by: syzbot+3c2be7424cea3b932b0e@syzkaller.appspotmail.com Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1a4e1d660a6e63ae19f8c7600a8753bfb9cb2f96 Author: Yang Yingliang Date: Tue Apr 6 15:48:12 2021 +0200 media: i2c: adv7511-v4l2: fix possible use-after-free in adv7511_remove() [ Upstream commit 2c9541720c66899adf6f3600984cf3ef151295ad ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5f49160ef68d01ce992ae951438f5df02d51cb6e Author: Yang Yingliang Date: Wed Apr 7 17:19:03 2021 +0800 power: supply: s3c_adc_battery: fix possible use-after-free in s3c_adc_bat_remove() [ Upstream commit 68ae256945d2abe9036a7b68af4cc65aff79d5b7 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Reviewed-by: Krzysztof Kozlowski Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 9f37aef7d422a0b31d710ab7bcb485d54d7fdd48 Author: Yang Yingliang Date: Wed Apr 7 17:17:06 2021 +0800 power: supply: generic-adc-battery: fix possible use-after-free in gab_remove() [ Upstream commit b6cfa007b3b229771d9588970adb4ab3e0487f49 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit cf7f3de0960db811e902901d9f82c6042c4893c5 Author: Colin Ian King Date: Tue Apr 6 18:01:15 2021 +0100 clk: socfpga: arria10: Fix memory leak of socfpga_clk on error return [ Upstream commit 657d4d1934f75a2d978c3cf2086495eaa542e7a9 ] There is an error return path that is not kfree'ing socfpga_clk leading to a memory leak. Fix this by adding in the missing kfree call. Addresses-Coverity: ("Resource leak") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210406170115.430990-1-colin.king@canonical.com Acked-by: Dinh Nguyen Reviewed-by: Krzysztof Kozlowski Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6a3b6b160cdfdf855799d1efcd3bd6066571a2c3 Author: Muhammad Usama Anjum Date: Wed Mar 24 19:07:53 2021 +0100 media: em28xx: fix memory leak [ Upstream commit 0ae10a7dc8992ee682ff0b1752ff7c83d472eef1 ] If some error occurs, URB buffers should also be freed. If they aren't freed with the dvb here, the em28xx_dvb_fini call doesn't frees the URB buffers as dvb is set to NULL. The function in which error occurs should do all the cleanup for the allocations it had done. Tested the patch with the reproducer provided by syzbot. This patch fixes the memleak. Reported-by: syzbot+889397c820fa56adf25d@syzkaller.appspotmail.com Signed-off-by: Muhammad Usama Anjum Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 73a708eac23907468539fca2213c352257dc224d Author: Hans Verkuil Date: Thu Mar 11 15:46:40 2021 +0100 media: gspca/sq905.c: fix uninitialized variable [ Upstream commit eaaea4681984c79d2b2b160387b297477f0c1aab ] act_len can be uninitialized if usb_bulk_msg() returns an error. Set it to 0 to avoid a KMSAN error. Signed-off-by: Hans Verkuil Reported-by: syzbot+a4e309017a5f3a24c7b3@syzkaller.appspotmail.com Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bc0cdc5845e30d227683bce0219284ae843ea842 Author: Daniel Niv Date: Thu Mar 11 03:53:00 2021 +0100 media: media/saa7164: fix saa7164_encoder_register() memory leak bugs [ Upstream commit c759b2970c561e3b56aa030deb13db104262adfe ] Add a fix for the memory leak bugs that can occur when the saa7164_encoder_register() function fails. The function allocates memory without explicitly freeing it when errors occur. Add a better error handling that deallocate the unused buffers before the function exits during a fail. Signed-off-by: Daniel Niv Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 44a03c91649e66999adb0f60f6f99fa8d9c1901a Author: Sean Young Date: Mon Feb 22 09:08:35 2021 +0100 media: ite-cir: check for receive overflow [ Upstream commit 28c7afb07ccfc0a939bb06ac1e7afe669901c65a ] It's best if this condition is reported. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 86105cc5eb28de22ff42d0be8bbb9161ac5ffd06 Author: Chaitanya Kulkarni Date: Sat Feb 27 21:56:26 2021 -0800 scsi: target: pscsi: Fix warning in pscsi_complete_cmd() [ Upstream commit fd48c056a32ed6e7754c7c475490f3bed54ed378 ] This fixes a compilation warning in pscsi_complete_cmd(): drivers/target/target_core_pscsi.c: In function ‘pscsi_complete_cmd’: drivers/target/target_core_pscsi.c:624:5: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ; /* XXX: TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE */ Link: https://lore.kernel.org/r/20210228055645.22253-5-chaitanya.kulkarni@wdc.com Reviewed-by: Mike Christie Reviewed-by: Johannes Thumshirn Signed-off-by: Chaitanya Kulkarni Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0474afbc9f749aeb2369c5ea5d436042b53eb32a Author: Josef Bacik Date: Fri Mar 12 15:25:21 2021 -0500 btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s [ Upstream commit 7a9213a93546e7eaef90e6e153af6b8fc7553f10 ] A few BUG_ON()'s in replace_path are purely to keep us from making logical mistakes, so replace them with ASSERT()'s. Reviewed-by: Qu Wenruo Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4d1b1d263d377b44873c2c0090cb7ddee5653145 Author: Yang Yingliang Date: Wed Apr 7 17:27:16 2021 +0800 phy: phy-twl4030-usb: Fix possible use-after-free in twl4030_usb_remove() [ Upstream commit e1723d8b87b73ab363256e7ca3af3ddb75855680 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210407092716.3270248-1-yangyingliang@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 79c5419abebd0d23411f15f49bea8afba9504ae3 Author: Pavel Machek Date: Wed Apr 14 20:12:49 2021 +0300 intel_th: Consistency and off-by-one fix [ Upstream commit 18ffbc47d45a1489b664dd68fb3a7610a6e1dea3 ] Consistently use "< ... +1" in for loops. Fix of-by-one in for_each_set_bit(). Signed-off-by: Pavel Machek Signed-off-by: Alexander Shishkin Link: https://lore.kernel.org/lkml/20190724095841.GA6952@amd/ Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210414171251.14672-6-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ec201e6f326e8d7eaa970c21fe25ac40131795e1 Author: Wei Yongjun Date: Fri Apr 9 08:29:54 2021 +0000 spi: omap-100k: Fix reference leak to master [ Upstream commit a23faea76d4cf5f75decb574491e66f9ecd707e7 ] Call spi_master_get() holds the reference count to master device, thus we need an additional spi_master_put() call to reduce the reference count, otherwise we will leak a reference to master. This commit fix it by removing the unnecessary spi_master_get(). Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210409082954.2906933-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2106b5c9df50ff9f0dcec09d4800dcecbb2720bd Author: Wei Yongjun Date: Fri Apr 9 08:29:55 2021 +0000 spi: dln2: Fix reference leak to master [ Upstream commit 9b844b087124c1538d05f40fda8a4fec75af55be ] Call spi_master_get() holds the reference count to master device, thus we need an additional spi_master_put() call to reduce the reference count, otherwise we will leak a reference to master. This commit fix it by removing the unnecessary spi_master_get(). Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20210409082955.2907950-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 95f98ee1b46d470554abdee020c0740bcfff44a1 Author: John Millikin Date: Thu Mar 25 17:04:33 2021 -0700 x86/build: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS) [ Upstream commit 8abe7fc26ad8f28bfdf78adbed56acd1fa93f82d ] When cross-compiling with Clang, the `$(CLANG_FLAGS)' variable contains additional flags needed to build C and assembly sources for the target platform. Normally this variable is automatically included in `$(KBUILD_CFLAGS)' via the top-level Makefile. The x86 real-mode makefile builds `$(REALMODE_CFLAGS)' from a plain assignment and therefore drops the Clang flags. This causes Clang to not recognize x86-specific assembler directives:   arch/x86/realmode/rm/header.S:36:1: error: unknown directive   .type real_mode_header STT_OBJECT ; .size real_mode_header, .-real_mode_header   ^ Explicit propagation of `$(CLANG_FLAGS)' to `$(REALMODE_CFLAGS)', which is inherited by real-mode make rules, fixes cross-compilation with Clang for x86 targets. Relevant flags: * `--target' sets the target architecture when cross-compiling. This   flag must be set for both compilation and assembly (`KBUILD_AFLAGS')   to support architecture-specific assembler directives. * `-no-integrated-as' tells clang to assemble with GNU Assembler   instead of its built-in LLVM assembler. This flag is set by default   unless `LLVM_IAS=1' is set, because the LLVM assembler can't yet   parse certain GNU extensions. Signed-off-by: John Millikin Signed-off-by: Nathan Chancellor Signed-off-by: Borislav Petkov Acked-by: Ard Biesheuvel Tested-by: Sedat Dilek Link: https://lkml.kernel.org/r/20210326000435.4785-2-nathan@kernel.org Signed-off-by: Sasha Levin commit 8e22771a3b142da0aac674671a55d7587aa0117f Author: Rafael J. Wysocki Date: Tue Mar 16 16:51:40 2021 +0100 PCI: PM: Do not read power state in pci_enable_device_flags() [ Upstream commit 4514d991d99211f225d83b7e640285f29f0755d0 ] It should not be necessary to update the current_state field of struct pci_dev in pci_enable_device_flags() before calling do_pci_enable_device() for the device, because none of the code between that point and the pci_set_power_state() call in do_pci_enable_device() invoked later depends on it. Moreover, doing that is actively harmful in some cases. For example, if the given PCI device depends on an ACPI power resource whose _STA method initially returns 0 ("off"), but the config space of the PCI device is accessible and the power state retrieved from the PCI_PM_CTRL register is D0, the current_state field in the struct pci_dev representing that device will get out of sync with the power.state of its ACPI companion object and that will lead to power management issues going forward. To avoid such issues it is better to leave the current_state value as is until it is changed to PCI_D0 by do_pci_enable_device() as appropriate. However, the power state of the device is not changed to PCI_D0 if it is already enabled when pci_enable_device_flags() gets called for it, so update its current_state in that case, but use pci_update_current_state() covering platform PM too for that. Link: https://lore.kernel.org/lkml/20210314000439.3138941-1-luzmaximilian@gmail.com/ Reported-by: Maximilian Luz Tested-by: Maximilian Luz Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Signed-off-by: Sasha Levin commit aae59ae834d3f5f190161b65fcdc98b1d5d327ee Author: Pawel Laszczak Date: Mon Mar 8 13:53:38 2021 +0100 usb: gadget: uvc: add bInterval checking for HS mode [ Upstream commit 26adde04acdff14a1f28d4a5dce46a8513a3038b ] Patch adds extra checking for bInterval passed by configfs. The 5.6.4 chapter of USB Specification (rev. 2.0) say: "A high-bandwidth endpoint must specify a period of 1x125 µs (i.e., a bInterval value of 1)." The issue was observed during testing UVC class on CV. I treat this change as improvement because we can control bInterval by configfs. Reviewed-by: Peter Chen Reviewed-by: Laurent Pinchart Signed-off-by: Pawel Laszczak Link: https://lore.kernel.org/r/20210308125338.4824-1-pawell@gli-login.cadence.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8dce22aee6ae6f1a10c95dde6f06f261d623adc7 Author: karthik alapati Date: Sun Feb 21 21:01:05 2021 +0530 staging: wimax/i2400m: fix byte-order issue [ Upstream commit 0c37baae130df39b19979bba88bde2ee70a33355 ] fix sparse byte-order warnings by converting host byte-order type to __le16 byte-order types before assigning to hdr.length Signed-off-by: karthik alapati Link: https://lore.kernel.org/r/0ae5c5c4c646506d8be871e7be5705542671a1d5.1613921277.git.mail@karthek.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 92194685fd958bca26578518465b4a5cc159be80 Author: Phillip Potter Date: Wed Mar 31 23:07:19 2021 +0100 fbdev: zero-fill colormap in fbcmap.c commit 19ab233989d0f7ab1de19a036e247afa4a0a1e9c upstream. Use kzalloc() rather than kmalloc() for the dynamically allocated parts of the colormap in fb_alloc_cmap_gfp, to prevent a leak of random kernel data to userspace under certain circumstances. Fixes a KMSAN-found infoleak bug reported by syzbot at: https://syzkaller.appspot.com/bug?id=741578659feabd108ad9e06696f0c1f2e69c4b6e Reported-by: syzbot+47fa9c9c648b765305b9@syzkaller.appspotmail.com Cc: stable Reviewed-by: Geert Uytterhoeven Signed-off-by: Phillip Potter Link: https://lore.kernel.org/r/20210331220719.1499743-1-phil@philpotter.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 458319b47133af9aaf86da0bb1a366846e61d913 Author: Seunghui Lee Date: Mon Feb 22 17:31:56 2021 +0900 mmc: core: Set read only for SD cards with permanent write protect bit commit 917a5336f2c27928be270226ab374ed0cbf3805d upstream. Some of SD cards sets permanent write protection bit in their CSD register, due to lifespan or internal problem. To avoid unnecessary I/O write operations, let's parse the bits in the CSD during initialization and mark the card as read only for this case. Signed-off-by: Seunghui Lee Link: https://lore.kernel.org/r/20210222083156.19158-1-sh043.lee@samsung.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit f9c694ebe3afd9a754b8c9a6592329cd89d0c174 Author: DooHyun Hwang Date: Wed Feb 10 13:59:36 2021 +0900 mmc: core: Do a power cycle when the CMD11 fails commit 147186f531ae49c18b7a9091a2c40e83b3d95649 upstream. A CMD11 is sent to the SD/SDIO card to start the voltage switch procedure into 1.8V I/O. According to the SD spec a power cycle is needed of the card, if it turns out that the CMD11 fails. Let's fix this, to allow a retry of the initialization without the voltage switch, to succeed. Note that, whether it makes sense to also retry with the voltage switch after the power cycle is a bit more difficult to know. At this point, we treat it like the CMD11 isn't supported and therefore we skip it when retrying. Signed-off-by: DooHyun Hwang Link: https://lore.kernel.org/r/20210210045936.7809-1-dh0421.hwang@samsung.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 038c6001dba71baaf5009861cfb044d5aef0ee71 Author: Jeffrey Mitchell Date: Fri Feb 26 15:00:23 2021 -0600 ecryptfs: fix kernel panic with null dev_name commit 9046625511ad8dfbc8c6c2de16b3532c43d68d48 upstream. When mounting eCryptfs, a null "dev_name" argument to ecryptfs_mount() causes a kernel panic if the parsed options are valid. The easiest way to reproduce this is to call mount() from userspace with an existing eCryptfs mount's options and a "source" argument of 0. Error out if "dev_name" is null in ecryptfs_mount() Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig") Cc: stable@vger.kernel.org Signed-off-by: Jeffrey Mitchell Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 3a0cadd433491b7277fc38d100fdce0fddddd983 Author: Mark Langsdorf Date: Tue Apr 27 13:54:33 2021 -0500 ACPI: custom_method: fix a possible memory leak commit 1cfd8956437f842836e8a066b40d1ec2fc01f13e upstream. In cm_write(), if the 'buf' is allocated memory but not fully consumed, it is possible to reallocate the buffer without freeing it by passing '*ppos' as 0 on a subsequent call. Add an explicit kfree() before kzalloc() to prevent the possible memory leak. Fixes: 526b4af47f44 ("ACPI: Split out custom_method functionality into an own driver") Signed-off-by: Mark Langsdorf Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 1d53ca5d131074c925ce38361fb0376d3bf7e394 Author: Mark Langsdorf Date: Fri Apr 23 10:28:17 2021 -0500 ACPI: custom_method: fix potential use-after-free issue commit e483bb9a991bdae29a0caa4b3a6d002c968f94aa upstream. In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function. Fixes: 03d1571d9513 ("ACPI: custom_method: fix memory leaks") Signed-off-by: Mark Langsdorf Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit adf1f8d208d0a4d1155add53adf5dde36495add9 Author: Vasily Gorbik Date: Tue Apr 20 11:04:10 2021 +0200 s390/disassembler: increase ebpf disasm buffer size commit 6f3353c2d2b3eb4de52e9704cb962712033db181 upstream. Current ebpf disassembly buffer size of 64 is too small. E.g. this line takes 65 bytes: 01fffff8005822e: ec8100ed8065\tclgrj\t%r8,%r1,8,001fffff80058408\n\0 Double the buffer size like it is done for the kernel disassembly buffer. Fixes the following KASAN finding: UG: KASAN: stack-out-of-bounds in print_fn_code+0x34c/0x380 Write of size 1 at addr 001fff800ad5f970 by task test_progs/853 CPU: 53 PID: 853 Comm: test_progs Not tainted 5.12.0-rc7-23786-g23457d86b1f0-dirty #19 Hardware name: IBM 3906 M04 704 (LPAR) Call Trace: [<0000000cd8e0538a>] show_stack+0x17a/0x1668 [<0000000cd8e2a5d8>] dump_stack+0x140/0x1b8 [<0000000cd8e16e74>] print_address_description.constprop.0+0x54/0x260 [<0000000cd75a8698>] kasan_report+0xc8/0x130 [<0000000cd6e26da4>] print_fn_code+0x34c/0x380 [<0000000cd6ea0f4e>] bpf_int_jit_compile+0xe3e/0xe58 [<0000000cd72c4c88>] bpf_prog_select_runtime+0x5b8/0x9c0 [<0000000cd72d1bf8>] bpf_prog_load+0xa78/0x19c0 [<0000000cd72d7ad6>] __do_sys_bpf.part.0+0x18e/0x768 [<0000000cd6e0f392>] do_syscall+0x12a/0x220 [<0000000cd8e333f8>] __do_syscall+0x98/0xc8 [<0000000cd8e54834>] system_call+0x6c/0x94 1 lock held by test_progs/853: #0: 0000000cd9bf7460 (report_lock){....}-{2:2}, at: kasan_report+0x96/0x130 addr 001fff800ad5f970 is located in stack of task test_progs/853 at offset 96 in frame: print_fn_code+0x0/0x380 this frame has 1 object: [32, 96) 'buffer' Memory state around the buggy address: 001fff800ad5f800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 001fff800ad5f880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >001fff800ad5f900: 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 f3 f3 ^ 001fff800ad5f980: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 001fff800ad5fa00: 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 Cc: Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 95942c6ecdeda8a431d7ee27f0a58e54a9eaee3b Author: Mark Pearson Date: Wed Apr 7 17:20:15 2021 -0400 platform/x86: thinkpad_acpi: Correct thermal sensor allocation commit 6759e18e5cd8745a5dfc5726e4a3db5281ec1639 upstream. On recent Thinkpad platforms it was reported that temp sensor 11 was always incorrectly displaying 66C. It turns out the reason for this is that this location in EC RAM is not a temperature sensor but is the power supply ID (offset 0xC2). Based on feedback from the Lenovo firmware team the EC RAM version can be determined and for the current version (3) only the 0x78 to 0x7F range is used for temp sensors. I don't have any details for earlier versions so I have left the implementation unaltered there. Note - in this block only 0x78 and 0x79 are officially designated (CPU & GPU sensors). The use of the other locations in the block will vary from platform to platform; but the existing logic to detect a sensor presence holds. Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 989a01fa9e3dafb0522cf6da8b9d8c11a3db85d1 Author: Chris Chiu Date: Wed Apr 21 01:46:51 2021 +0800 USB: Add reset-resume quirk for WD19's Realtek Hub commit ca91fd8c7643d93bfc18a6fec1a0d3972a46a18a upstream. Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work after the system resumes from suspend with remote wakeup enabled device connected: [ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71) [ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71) [ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71) [ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71) Information of this hub: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 5 D: Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=5487 Rev= 1.47 S: Manufacturer=Dell Inc. S: Product=Dell dock C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms The failure results from the ETIMEDOUT by chance when turning on the suspend feature for the specified port of the hub. The port seems to be in an unknown state so the hub_activate during resume fails the hub_port_status, then the hub will fail to work. The quirky hub needs the reset-resume quirk to function correctly. Acked-by: Alan Stern Signed-off-by: Chris Chiu Cc: stable Link: https://lore.kernel.org/r/20210420174651.6202-1-chris.chiu@canonical.com Signed-off-by: Greg Kroah-Hartman commit 0b72f28778d4886061c1b36d956568fbf20e8348 Author: Kai-Heng Feng Date: Mon Apr 12 21:54:53 2021 +0800 USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet commit 8f23fe35ff1e5491b4d279323a8209a31f03ae65 upstream. This is another branded 8153 device that doesn't work well with LPM enabled: [ 400.597506] r8152 5-1.1:1.0 enx482ae3a2a6f0: Tx status -71 So disable LPM to resolve the issue. Signed-off-by: Kai-Heng Feng BugLink: https://bugs.launchpad.net/bugs/1922651 Link: https://lore.kernel.org/r/20210412135455.791971-1-kai.heng.feng@canonical.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit a485fbcd6a36f80b57a71213e741a49d0aa87123 Author: Takashi Iwai Date: Wed Apr 7 16:45:49 2021 +0200 ALSA: usb-audio: Add MIDI quirk for Vox ToneLab EX commit 64f40f9be14106e7df0098c427cb60be645bddb7 upstream. ToneLab EX guitar pedal device requires the same quirk like ToneLab ST for supporting the MIDI. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212593 Cc: Link: https://lore.kernel.org/r/20210407144549.1530-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e96b8072f6405de71e1c8c50d43f22aed622fc3c Author: Jiri Kosina Date: Tue Mar 2 11:26:55 2021 +0100 iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd() commit 2800aadc18a64c96b051bcb7da8a7df7d505db3f upstream. It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs disabled (e.g. from LED core). We can't enable BHs in such a situation. Turn the unconditional BH-enable/BH-disable code into hardirq-disable/conditional-enable. This fixes the warning below. WARNING: CPU: 1 PID: 1139 at kernel/softirq.c:178 __local_bh_enable_ip+0xa5/0xf0 CPU: 1 PID: 1139 Comm: NetworkManager Not tainted 5.12.0-rc1-00004-gb4ded168af79 #7 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 RIP: 0010:__local_bh_enable_ip+0xa5/0xf0 Code: f7 69 e8 ee 23 14 00 fb 66 0f 1f 44 00 00 65 8b 05 f0 f4 f7 69 85 c0 74 3f 48 83 c4 08 5b c3 65 8b 05 9b fe f7 69 85 c0 75 8e <0f> 0b eb 8a 48 89 3c 24 e8 4e 20 14 00 48 8b 3c 24 eb 91 e8 13 4e RSP: 0018:ffffafd580b13298 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000201 RCX: 0000000000000000 RDX: 0000000000000003 RSI: 0000000000000201 RDI: ffffffffc1272389 RBP: ffff96517ae4c018 R08: 0000000000000001 R09: 0000000000000000 R10: ffffafd580b13178 R11: 0000000000000001 R12: ffff96517b060000 R13: 0000000000000000 R14: ffffffff80000000 R15: 0000000000000001 FS: 00007fc604ebefc0(0000) GS:ffff965267480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055fb3fef13b2 CR3: 0000000109112004 CR4: 00000000003706e0 Call Trace: ? _raw_spin_unlock_bh+0x1f/0x30 iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi] iwl_trans_txq_send_hcmd+0x6c/0x430 [iwlwifi] iwl_trans_send_cmd+0x88/0x170 [iwlwifi] ? lock_acquire+0x277/0x3d0 iwl_mvm_send_cmd+0x32/0x80 [iwlmvm] iwl_mvm_led_set+0xc2/0xe0 [iwlmvm] ? led_trigger_event+0x46/0x70 led_trigger_event+0x46/0x70 ieee80211_do_open+0x5c5/0xa20 [mac80211] ieee80211_open+0x67/0x90 [mac80211] __dev_open+0xd4/0x150 __dev_change_flags+0x19e/0x1f0 dev_change_flags+0x23/0x60 do_setlink+0x30d/0x1230 ? lock_is_held_type+0xb4/0x120 ? __nla_validate_parse.part.7+0x57/0xcb0 ? __lock_acquire+0x2e1/0x1a50 __rtnl_newlink+0x560/0x910 ? __lock_acquire+0x2e1/0x1a50 ? __lock_acquire+0x2e1/0x1a50 ? lock_acquire+0x277/0x3d0 ? sock_def_readable+0x5/0x290 ? lock_is_held_type+0xb4/0x120 ? find_held_lock+0x2d/0x90 ? sock_def_readable+0xb3/0x290 ? lock_release+0x166/0x2a0 ? lock_is_held_type+0x90/0x120 rtnl_newlink+0x47/0x70 rtnetlink_rcv_msg+0x25c/0x470 ? netlink_deliver_tap+0x97/0x3e0 ? validate_linkmsg+0x350/0x350 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1b2/0x280 netlink_sendmsg+0x336/0x450 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1ed/0x250 ? copy_msghdr_from_user+0x5c/0x90 ___sys_sendmsg+0x88/0xd0 ? lock_is_held_type+0xb4/0x120 ? find_held_lock+0x2d/0x90 ? lock_release+0x166/0x2a0 ? __fget_files+0xfe/0x1d0 ? __sys_sendmsg+0x5e/0xa0 __sys_sendmsg+0x5e/0xa0 ? lockdep_hardirqs_on_prepare+0xd9/0x170 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fc605c9572d Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 da ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 2e ef ff ff 48 RSP: 002b:00007fffc83789f0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055ef468570c0 RCX: 00007fc605c9572d RDX: 0000000000000000 RSI: 00007fffc8378a30 RDI: 000000000000000c RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007fffc8378b80 R14: 00007fffc8378b7c R15: 0000000000000000 irq event stamp: 170785 hardirqs last enabled at (170783): [] __local_bh_enable_ip+0x82/0xf0 hardirqs last disabled at (170784): [] _raw_read_lock_irqsave+0x8d/0x90 softirqs last enabled at (170782): [] iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi] softirqs last disabled at (170785): [] iwl_pcie_enqueue_hcmd+0x116/0xa00 [iwlwifi] Signed-off-by: Jiri Kosina Tested-by: Sedat Dilek # LLVM/Clang v12.0.0-rc3 Acked-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2103021125430.12405@cbobk.fhfr.pm Signed-off-by: Jari Ruusu Signed-off-by: Greg Kroah-Hartman commit 7891aeb6f188f0887eb3e6c34e8cc68239f8e20c Author: Phillip Potter Date: Thu Apr 1 23:36:07 2021 +0100 net: usb: ax88179_178a: initialize local variables before use commit bd78980be1a68d14524c51c4b4170782fada622b upstream. Use memset to initialize local array in drivers/net/usb/ax88179_178a.c, and also set a local u16 and u32 variable to 0. Fixes a KMSAN found uninit-value bug reported by syzbot at: https://syzkaller.appspot.com/bug?id=00371c73c72f72487c1d0bfe0cc9d00de339d5aa Reported-by: syzbot+4993e4a0e237f1b53747@syzkaller.appspotmail.com Signed-off-by: Phillip Potter Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c520dfc66f8bad5cd8534aeb3cf60178d3bb525d Author: Eric Caruso Date: Wed Jun 8 16:08:59 2016 -0700 timerfd: Reject ALARM timerfds without CAP_WAKE_ALARM commit 2895a5e5b3ae78d9923a91fce405d4a2f32c4309 upstream. timerfd gives processes a way to set wake alarms, but unlike timers made using timer_create, timerfds don't check whether the process has CAP_WAKE_ALARM before setting alarm-time timers. CAP_WAKE_ALARM is supposed to gate this behavior and so it makes sense that we should deny permission to create such timerfds if the process doesn't have this capability. Signed-off-by: Eric Caruso Cc: Todd Poynor Link: http://lkml.kernel.org/r/1465427339-96209-1-git-send-email-ejcaruso@chromium.org Signed-off-by: Thomas Gleixner Cc: Kasper Zwijsen Signed-off-by: Greg Kroah-Hartman