commit a9756bf91f2dabb6dbb4292bb53636c167b0da12 Author: Greg Kroah-Hartman Date: Tue Jun 14 16:52:42 2022 +0200 Linux 4.9.318 Link: https://lore.kernel.org/r/20220613094840.720778945@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit 29e13f6b38f0816af2012e0725507754e8f4569c Author: Eric Dumazet Date: Fri May 27 14:28:29 2022 -0700 tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd commit 11825765291a93d8e7f44230da67b9f607c777bf upstream. syzbot got a new report [1] finally pointing to a very old bug, added in initial support for MTU probing. tcp_mtu_probe() has checks about starting an MTU probe if tcp_snd_cwnd(tp) >= 11. But nothing prevents tcp_snd_cwnd(tp) to be reduced later and before the MTU probe succeeds. This bug would lead to potential zero-divides. Debugging added in commit 40570375356c ("tcp: add accessors to read/set tp->snd_cwnd") has paid off :) While we are at it, address potential overflows in this code. [1] WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712 Modules linked in: CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline] RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712 Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287 RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000 RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520 R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50 R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000 FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356 tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861 tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973 tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x1d8/0x4c0 net/core/sock.c:2849 release_sock+0x5d/0x1c0 net/core/sock.c:3404 sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145 tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410 tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] __sys_sendto+0x439/0x5c0 net/socket.c:2119 __do_sys_sendto net/socket.c:2131 [inline] __se_sys_sendto net/socket.c:2127 [inline] __x64_sys_sendto+0xda/0xf0 net/socket.c:2127 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f6431289109 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109 RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000 Fixes: 5d424d5a674f ("[TCP]: MTU probing") Signed-off-by: Eric Dumazet Reported-by: syzbot Acked-by: Yuchung Cheng Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit faebc1a270273898199dfe209f387293a8d39eb5 Author: Johan Hovold Date: Fri Apr 1 15:38:54 2022 +0200 PCI: qcom: Fix unbalanced PHY init on probe errors commit 83013631f0f9961416abd812e228c8efbc2f6069 upstream. Undo the PHY initialisation (e.g. balance runtime PM) if host initialisation fails during probe. Link: https://lore.kernel.org/r/20220401133854.10421-3-johan+linaro@kernel.org Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Signed-off-by: Johan Hovold Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Acked-by: Stanimir Varbanov Cc: stable@vger.kernel.org # 4.5 Signed-off-by: Greg Kroah-Hartman commit 6630c79930c3139f0fd3435a09442dccd8f8d10f Author: Tokunori Ikegami Date: Thu Mar 24 02:04:56 2022 +0900 mtd: cfi_cmdset_0002: Use chip_ready() for write on S29GL064N commit 0a8e98305f63deaf0a799d5cf5532cc83af035d1 upstream. Since commit dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") buffered writes fail on S29GL064N. This is because, on S29GL064N, reads return 0xFF at the end of DQ polling for write completion, where as, chip_good() check expects actual data written to the last location to be returned post DQ polling completion. Fix is to revert to using chip_good() for S29GL064N which only checks for DQ lines to settle down to determine write completion. Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.de/ Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") Cc: stable@vger.kernel.org Signed-off-by: Tokunori Ikegami Acked-by: Vignesh Raghavendra Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-3-ikegami.t@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8b238288a8ed7e07fc6c3249d0e60a904f2bd210 Author: Tokunori Ikegami Date: Thu Mar 24 02:04:55 2022 +0900 mtd: cfi_cmdset_0002: Move and rename chip_check/chip_ready/chip_good_for_write commit 083084df578a8bdb18334f69e7b32d690aaa3247 upstream. This is a preparation patch for the S29GL064N buffer writes fix. There is no functional change. Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.de/ Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") Signed-off-by: Tokunori Ikegami Cc: stable@vger.kernel.org Acked-by: Vignesh Raghavendra Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-2-ikegami.t@gmail.com Signed-off-by: Greg Kroah-Hartman commit 89dda10b73b7ce184caf18754907126ce7ce3fad Author: Michael Ellerman Date: Tue Jun 7 00:34:56 2022 +1000 powerpc/32: Fix overread/overwrite of thread_struct via ptrace commit 8e1278444446fc97778a5e5c99bca1ce0bbc5ec9 upstream. The ptrace PEEKUSR/POKEUSR (aka PEEKUSER/POKEUSER) API allows a process to read/write registers of another process. To get/set a register, the API takes an index into an imaginary address space called the "USER area", where the registers of the process are laid out in some fashion. The kernel then maps that index to a particular register in its own data structures and gets/sets the value. The API only allows a single machine-word to be read/written at a time. So 4 bytes on 32-bit kernels and 8 bytes on 64-bit kernels. The way floating point registers (FPRs) are addressed is somewhat complicated, because double precision float values are 64-bit even on 32-bit CPUs. That means on 32-bit kernels each FPR occupies two word-sized locations in the USER area. On 64-bit kernels each FPR occupies one word-sized location in the USER area. Internally the kernel stores the FPRs in an array of u64s, or if VSX is enabled, an array of pairs of u64s where one half of each pair stores the FPR. Which half of the pair stores the FPR depends on the kernel's endianness. To handle the different layouts of the FPRs depending on VSX/no-VSX and big/little endian, the TS_FPR() macro was introduced. Unfortunately the TS_FPR() macro does not take into account the fact that the addressing of each FPR differs between 32-bit and 64-bit kernels. It just takes the index into the "USER area" passed from userspace and indexes into the fp_state.fpr array. On 32-bit there are 64 indexes that address FPRs, but only 32 entries in the fp_state.fpr array, meaning the user can read/write 256 bytes past the end of the array. Because the fp_state sits in the middle of the thread_struct there are various fields than can be overwritten, including some pointers. As such it may be exploitable. It has also been observed to cause systems to hang or otherwise misbehave when using gdbserver, and is probably the root cause of this report which could not be easily reproduced: https://lore.kernel.org/linuxppc-dev/dc38afe9-6b78-f3f5-666b-986939e40fc6@keymile.com/ Rather than trying to make the TS_FPR() macro even more complicated to fix the bug, or add more macros, instead add a special-case for 32-bit kernels. This is more obvious and hopefully avoids a similar bug happening again in future. Note that because 32-bit kernels never have VSX enabled the code doesn't need to consider TS_FPRWIDTH/OFFSET at all. Add a BUILD_BUG_ON() to ensure that 32-bit && VSX is never enabled. Fixes: 87fec0514f61 ("powerpc: PTRACE_PEEKUSR/PTRACE_POKEUSER of FPR registers in little endian builds") Cc: stable@vger.kernel.org # v3.13+ Reported-by: Ariel Miculas Tested-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220609133245.573565-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit 057b12ffd8318bbf706fce29dd0820dacd6e9120 Author: Mathias Nyman Date: Tue Jun 7 12:11:33 2022 -0700 Input: bcm5974 - set missing URB_NO_TRANSFER_DMA_MAP urb flag commit c42e65664390be7c1ef3838cd84956d3a2739d60 upstream. The bcm5974 driver does the allocation and dma mapping of the usb urb data buffer, but driver does not set the URB_NO_TRANSFER_DMA_MAP flag to let usb core know the buffer is already mapped. usb core tries to map the already mapped buffer, causing a warning: "xhci_hcd 0000:00:14.0: rejecting DMA map of vmalloc memory" Fix this by setting the URB_NO_TRANSFER_DMA_MAP, letting usb core know buffer is already mapped by bcm5974 driver Signed-off-by: Mathias Nyman Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=215890 Link: https://lore.kernel.org/r/20220606113636.588955-1-mathias.nyman@linux.intel.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 593773088d615a46a42c97e01a0550d192bb7f74 Author: Martin Faltesek Date: Mon Jun 6 21:57:28 2022 -0500 nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling commit 996419e0594abb311fb958553809f24f38e7abbe upstream. Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths. Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support") Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION") Cc: stable@vger.kernel.org Signed-off-by: Martin Faltesek Reviewed-by: Guenter Roeck Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e290f91d21ac6fff24f17b2f1fa24ea44b9f9418 Author: Martin Faltesek Date: Mon Jun 6 21:57:27 2022 -0500 nfc: st21nfca: fix incorrect validating logic in EVT_TRANSACTION commit 77e5fe8f176a525523ae091d6fd0fbb8834c156d upstream. The first validation check for EVT_TRANSACTION has two different checks tied together with logical AND. One is a check for minimum packet length, and the other is for a valid aid_tag. If either condition is true (fails), then an error should be triggered. The fix is to change && to ||. Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support") Cc: stable@vger.kernel.org Signed-off-by: Martin Faltesek Reviewed-by: Guenter Roeck Reviewed-by: Krzysztof Kozlowski Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 94ac2a94b72be6c7aaec855c8e6dade3da4d4aa8 Author: Sergey Shtylyov Date: Wed Jun 8 22:51:07 2022 +0300 ata: libata-transport: fix {dma|pio|xfer}_mode sysfs files commit 72aad489f992871e908ff6d9055b26c6366fb864 upstream. The {dma|pio}_mode sysfs files are incorrectly documented as having a list of the supported DMA/PIO transfer modes, while the corresponding fields of the *struct* ata_device hold the transfer mode IDs, not masks. To match these docs, the {dma|pio}_mode (and even xfer_mode!) sysfs files are handled by the ata_bitfield_name_match() macro which leads to reading such kind of nonsense from them: $ cat /sys/class/ata_device/dev3.0/pio_mode XFER_UDMA_7, XFER_UDMA_6, XFER_UDMA_5, XFER_UDMA_4, XFER_MW_DMA_4, XFER_PIO_6, XFER_PIO_5, XFER_PIO_4, XFER_PIO_3, XFER_PIO_2, XFER_PIO_1, XFER_PIO_0 Using the correct ata_bitfield_name_search() macro fixes that: $ cat /sys/class/ata_device/dev3.0/pio_mode XFER_PIO_4 While fixing the file documentation, somewhat reword the {dma|pio}_mode file doc and add a note about being mostly useful for PATA devices to the xfer_mode file doc... Fixes: d9027470b886 ("[libata] Add ATA transport class") Signed-off-by: Sergey Shtylyov Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 43d709352562693822f931dad1087ade1a014e25 Author: Shyam Prasad N Date: Tue May 31 12:31:05 2022 +0000 cifs: return errors during session setup during reconnects commit 8ea21823aa584b55ba4b861307093b78054b0c1b upstream. During reconnects, we check the return value from cifs_negotiate_protocol, and have handlers for both success and failures. But if that passes, and cifs_setup_session returns any errors other than -EACCES, we do not handle that. This fix adds a handler for that, so that we don't go ahead and try a tree_connect on a failed session. Signed-off-by: Shyam Prasad N Reviewed-by: Enzo Matsumiya Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit aeac3fd61922d7a87f633c8907e0e8a6871e8e23 Author: huangwenhui Date: Tue Jun 7 14:56:31 2022 +0800 ALSA: hda/conexant - Fix loopback issue with CX20632 commit d5ea7544c32ba27c2c5826248e4ff58bd50a2518 upstream. On a machine with CX20632, Alsamixer doesn't have 'Loopback Mixing' and 'Line'. Signed-off-by: huangwenhui Cc: Link: https://lore.kernel.org/r/20220607065631.10708-1-huangwenhuia@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 45984b3ae9d688a913d024551848d068b1c0ac4e Author: Xie Yongji Date: Thu May 5 18:09:10 2022 +0800 vringh: Fix loop descriptors check in the indirect cases [ Upstream commit dbd29e0752286af74243cf891accf472b2f3edd8 ] We should use size of descriptor chain to test loop condition in the indirect case. And another statistical count is also introduced for indirect descriptors to avoid conflict with the statistical count of direct descriptors. Fixes: f87d0fbb5798 ("vringh: host-side implementation of virtio rings.") Signed-off-by: Xie Yongji Signed-off-by: Fam Zheng Message-Id: <20220505100910.137-1-xieyongji@bytedance.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit 2811cda7d2ec8c77493b95a7d871e93f412a03a4 Author: Kees Cook Date: Wed May 18 13:52:23 2022 -0700 nodemask: Fix return values to be unsigned [ Upstream commit 0dfe54071d7c828a02917b595456bfde1afdddc9 ] The nodemask routines had mixed return values that provided potentially signed return values that could never happen. This was leading to the compiler getting confusing about the range of possible return values (it was thinking things could be negative where they could not be). Fix all the nodemask routines that should be returning unsigned (or bool) values. Silences: mm/swapfile.c: In function ‘setup_swap_info’: mm/swapfile.c:2291:47: error: array subscript -1 is below array bounds of ‘struct plist_node[]’ [-Werror=array-bounds] 2291 | p->avail_lists[i].prio = 1; | ~~~~~~~~~~~~~~^~~ In file included from mm/swapfile.c:16: ./include/linux/swap.h:292:27: note: while referencing ‘avail_lists’ 292 | struct plist_node avail_lists[]; /* | ^~~~~~~~~~~ Reported-by: Christophe de Dinechin Link: https://lore.kernel.org/lkml/20220414150855.2407137-3-dinechin@redhat.com/ Cc: Alexey Dobriyan Cc: Yury Norov Cc: Andy Shevchenko Cc: Rasmus Villemoes Cc: Andrew Morton Cc: Zhen Lei Signed-off-by: Kees Cook Signed-off-by: Yury Norov Signed-off-by: Sasha Levin commit 7aa910df07ae8e725756ce974d7c5ba174c8f847 Author: Masahiro Yamada Date: Tue May 24 01:46:22 2022 +0900 modpost: fix undefined behavior of is_arm_mapping_symbol() [ Upstream commit d6b732666a1bae0df3c3ae06925043bba34502b1 ] The return value of is_arm_mapping_symbol() is unpredictable when "$" is passed in. strchr(3) says: The strchr() and strrchr() functions return a pointer to the matched character or NULL if the character is not found. The terminating null byte is considered part of the string, so that if c is specified as '\0', these functions return a pointer to the terminator. When str[1] is '\0', strchr("axtd", str[1]) is not NULL, and str[2] is referenced (i.e. buffer overrun). Test code --------- char str1[] = "abc"; char str2[] = "ab"; strcpy(str1, "$"); strcpy(str2, "$"); printf("test1: %d\n", is_arm_mapping_symbol(str1)); printf("test2: %d\n", is_arm_mapping_symbol(str2)); Result ------ test1: 0 test2: 1 Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Signed-off-by: Sasha Levin commit b33f7d99c9226892c7794dc2500fae35966020c9 Author: Gong Yuanjun Date: Tue May 17 17:57:00 2022 +0800 drm/radeon: fix a possible null pointer dereference [ Upstream commit a2b28708b645c5632dc93669ab06e97874c8244f ] In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. The failure status of drm_cvt_mode() on the other path is checked too. Signed-off-by: Gong Yuanjun Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f048349930a10508b0d7e3f42ec9a0dc5628777f Author: Michal Kubecek Date: Mon May 23 22:05:24 2022 +0200 Revert "net: af_key: add check for pfkey_broadcast in function pfkey_process" [ Upstream commit 9c90c9b3e50e16d03c7f87d63e9db373974781e0 ] This reverts commit 4dc2a5a8f6754492180741facf2a8787f2c415d7. A non-zero return value from pfkey_broadcast() does not necessarily mean an error occurred as this function returns -ESRCH when no registered listener received the message. In particular, a call with BROADCAST_PROMISC_ONLY flag and null one_sk argument can never return zero so that this commit in fact prevents processing any PF_KEY message. One visible effect is that racoon daemon fails to find encryption algorithms like aes and refuses to start. Excluding -ESRCH return value would fix this but it's not obvious that we really want to bail out here and most other callers of pfkey_broadcast() also ignore the return value. Also, as pointed out by Steffen Klassert, PF_KEY is kind of deprecated and newer userspace code should use netlink instead so that we should only disturb the code for really important fixes. v2: add a comment explaining why is the return value ignored Signed-off-by: Michal Kubecek Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit ac8fd53fa022d57b16393e8cc3ab2f80ad315d4a Author: Guoqing Jiang Date: Fri Apr 29 16:49:09 2022 +0800 md: protect md_unregister_thread from reentrancy [ Upstream commit 1e267742283a4b5a8ca65755c44166be27e9aa0f ] Generally, the md_unregister_thread is called with reconfig_mutex, but raid_message in dm-raid doesn't hold reconfig_mutex to unregister thread, so md_unregister_thread can be called simulitaneously from two call sites in theory. Then after previous commit which remove the protection of reconfig_mutex for md_unregister_thread completely, the potential issue could be worse than before. Let's take pers_lock at the beginning of function to ensure reentrancy. Reported-by: Donald Buczek Signed-off-by: Guoqing Jiang Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 6ae96e638739f040959610d44c0a696d6a80542f Author: John Ogness Date: Fri May 6 23:39:24 2022 +0206 serial: msm_serial: disable interrupts in __msm_console_write() [ Upstream commit aabdbb1b7a5819e18c403334a31fb0cc2c06ad41 ] __msm_console_write() assumes that interrupts are disabled, but with threaded console printers it is possible that the write() callback of the console is called with interrupts enabled. Explicitly disable interrupts using local_irq_save() to preserve the assumed context. Reported-by: Marek Szyprowski Reviewed-by: Petr Mladek Signed-off-by: John Ogness Link: https://lore.kernel.org/r/20220506213324.470461-1-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0b7371a22489cbb2e8e826ca03fb5ce92afb04fe Author: Wang Cheng Date: Mon May 16 17:22:41 2022 +0800 staging: rtl8712: fix uninit-value in r871xu_drv_init() [ Upstream commit 0458e5428e5e959d201a40ffe71d762a79ecedc4 ] When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0, 'mac[6]' will not be initialized. BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5358 [inline] hub_port_connect_change drivers/usb/core/hub.c:5502 [inline] port_event drivers/usb/core/hub.c:5660 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307 worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454 kthread+0x3c7/0x500 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 Local variable mac created at: r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8 Reported-by: Tested-by: Reviewed-by: Dan Carpenter Signed-off-by: Wang Cheng Link: https://lore.kernel.org/r/14c3886173dfa4597f0704547c414cfdbcd11d16.1652618244.git.wanngchenng@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0fa78ad392bb84429d4f17080ab84b26dd637962 Author: Andre Przywara Date: Fri May 6 17:25:22 2022 +0100 clocksource/drivers/sp804: Avoid error on multiple instances [ Upstream commit a98399cbc1e05f7b977419f03905501d566cf54e ] When a machine sports more than one SP804 timer instance, we only bring up the first one, since multiple timers of the same kind are not useful to Linux. As this is intentional behaviour, we should not return an error message, as we do today: =============== [ 0.000800] Failed to initialize '/bus@8000000/motherboard-bus@8000000/iofpga-bus@300000000/timer@120000': -22 =============== Replace the -EINVAL return with a debug message and return 0 instead. Also we do not reach the init function anymore if the DT node is disabled (as this is now handled by OF_DECLARE), so remove the explicit check for that case. This fixes a long standing bogus error when booting ARM's fastmodels. Signed-off-by: Andre Przywara Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20220506162522.3675399-1-andre.przywara@arm.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit eeb7777f4771733ae730f447f98a2d47d9ed39f4 Author: Shuah Khan Date: Fri Apr 29 15:09:13 2022 -0600 misc: rtsx: set NULL intfdata when probe fails [ Upstream commit f861d36e021e1ac4a0a2a1f6411d623809975d63 ] rtsx_usb_probe() doesn't call usb_set_intfdata() to null out the interface pointer when probe fails. This leaves a stale pointer. Noticed the missing usb_set_intfdata() while debugging an unrelated invalid DMA mapping problem. Fix it with a call to usb_set_intfdata(..., NULL). Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/20220429210913.46804-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5127c0f365265bb69cd776ad6e4b872c309f3fa8 Author: Marek Szyprowski Date: Thu May 5 12:46:18 2022 +0200 usb: dwc2: gadget: don't reset gadget's driver->bus [ Upstream commit 3120aac6d0ecd9accf56894aeac0e265f74d3d5a ] UDC driver should not touch gadget's driver internals, especially it should not reset driver->bus. This wasn't harmful so far, but since commit fc274c1e9973 ("USB: gadget: Add a new bus for gadgets") gadget subsystem got it's own bus and messing with ->bus triggers the following NULL pointer dereference: dwc2 12480000.hsotg: bound driver g_ether 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 00000000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: ... CPU: 0 PID: 620 Comm: modprobe Not tainted 5.18.0-rc5-next-20220504 #11862 Hardware name: Samsung Exynos (Flattened Device Tree) PC is at module_add_driver+0x44/0xe8 LR is at sysfs_do_create_link_sd+0x84/0xe0 ... Process modprobe (pid: 620, stack limit = 0x(ptrval)) ... module_add_driver from bus_add_driver+0xf4/0x1e4 bus_add_driver from driver_register+0x78/0x10c driver_register from usb_gadget_register_driver_owner+0x40/0xb4 usb_gadget_register_driver_owner from do_one_initcall+0x44/0x1e0 do_one_initcall from do_init_module+0x44/0x1c8 do_init_module from load_module+0x19b8/0x1b9c load_module from sys_finit_module+0xdc/0xfc sys_finit_module from ret_fast_syscall+0x0/0x54 Exception stack(0xf1771fa8 to 0xf1771ff0) ... dwc2 12480000.hsotg: new device is high-speed ---[ end trace 0000000000000000 ]--- Fix this by removing driver->bus entry reset. Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20220505104618.22729-1-m.szyprowski@samsung.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6cade0a0b76f116ea0733dc62251376cf9d14984 Author: Evan Green Date: Thu Apr 21 10:39:27 2022 -0700 USB: hcd-pci: Fully suspend across freeze/thaw cycle [ Upstream commit 63acaa8e9c65dc34dc249440216f8e977f5d2748 ] The documentation for the freeze() method says that it "should quiesce the device so that it doesn't generate IRQs or DMA". The unspoken consequence of not doing this is that MSIs aimed at non-boot CPUs may get fully lost if they're sent during the period where the target CPU is offline. The current callbacks for USB HCD do not fully quiesce interrupts, specifically on XHCI. Change to use the full suspend/resume flow for freeze/thaw to ensure interrupts are fully quiesced. This fixes issues where USB devices fail to thaw during hibernation because XHCI misses its interrupt and cannot recover. Acked-by: Alan Stern Signed-off-by: Evan Green Link: https://lore.kernel.org/r/20220421103751.v3.2.I8226c7fdae88329ef70957b96a39b346c69a914e@changeid Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9b58d255f27b0ed6a2e43208960864d67579db58 Author: Duoming Zhou Date: Sun Apr 17 20:03:05 2022 +0800 drivers: usb: host: Fix deadlock in oxu_bus_suspend() [ Upstream commit 4d378f2ae58138d4c55684e1d274e7dd94aa6524 ] There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock. Signed-off-by: Duoming Zhou Link: https://lore.kernel.org/r/20220417120305.64577-1-duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0976808d0d171ec837d4bd3e9f4ad4a00ab703b8 Author: Duoming Zhou Date: Sun Apr 17 19:16:26 2022 +0800 drivers: tty: serial: Fix deadlock in sa1100_set_termios() [ Upstream commit 62b2caef400c1738b6d22f636c628d9f85cd4c4c ] There is a deadlock in sa1100_set_termios(), which is shown below: (Thread 1) | (Thread 2) | sa1100_enable_ms() sa1100_set_termios() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | sa1100_timeout() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold sport->port.lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need sport->port.lock in position (2) of thread 2. As a result, sa1100_set_termios() will block forever. This patch moves del_timer_sync() before spin_lock_irqsave() in order to prevent the deadlock. Signed-off-by: Duoming Zhou Link: https://lore.kernel.org/r/20220417111626.7802-1-duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 804de302ada3544699c5f48c5314b249af76faa3 Author: Zhen Ni Date: Wed Mar 2 11:37:16 2022 +0800 USB: host: isp116x: check return value after calling platform_get_resource() [ Upstream commit 134a3408c2d3f7e23eb0e4556e0a2d9f36c2614e ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Zhen Ni Link: https://lore.kernel.org/r/20220302033716.31272-1-nizhen@uniontech.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4681129fda9e8555392eaaadb239ec6a6e2b3e12 Author: Duoming Zhou Date: Sun Apr 17 22:16:41 2022 +0800 drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop() [ Upstream commit 9b6bdbd9337de3917945847bde262a34a87a6303 ] There is a deadlock in rtllib_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, rtllib_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock. Signed-off-by: Duoming Zhou Link: https://lore.kernel.org/r/20220417141641.124388-1-duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f4c836d90da1ece88905d62ce2ce39a962f25d1a Author: Huang Guobin Date: Thu Mar 31 17:10:05 2022 +0800 tty: Fix a possible resource leak in icom_probe [ Upstream commit ee157a79e7c82b01ae4c25de0ac75899801f322c ] When pci_read_config_dword failed, call pci_release_regions() and pci_disable_device() to recycle the resource previously allocated. Reviewed-by: Jiri Slaby Signed-off-by: Huang Guobin Link: https://lore.kernel.org/r/20220331091005.3290753-1-huangguobin4@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 50c341f9a2adc4c32a8ad5a39eb99d9c4a419e0d Author: Zheyu Ma Date: Sun Apr 10 19:48:14 2022 +0800 tty: synclink_gt: Fix null-pointer-dereference in slgt_clean() [ Upstream commit 689ca31c542687709ba21ec2195c1fbce34fd029 ] When the driver fails at alloc_hdlcdev(), and then we remove the driver module, we will get the following splat: [ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI [ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17] [ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0 [ 25.077709] Call Trace: [ 25.077924] [ 25.078108] unregister_hdlc_device+0x16/0x30 [ 25.078481] slgt_cleanup+0x157/0x9f0 [synclink_gt] Fix this by checking whether the 'info->netdev' is a null pointer first. Reviewed-by: Jiri Slaby Signed-off-by: Zheyu Ma Link: https://lore.kernel.org/r/20220410114814.3920474-1-zheyuma97@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f23b8a021d662beb0e231cd5c664e4fa3bc90a00 Author: Kees Cook Date: Wed Feb 16 12:15:03 2022 -0800 lkdtm/usercopy: Expand size of "out of frame" object [ Upstream commit f387e86d3a74407bdd9c5815820ac9d060962840 ] To be sufficiently out of range for the usercopy test to see the lifetime mismatch, expand the size of the "bad" buffer, which will let it be beyond current_stack_pointer regardless of stack growth direction. Paired with the recent addition of stack depth checking under CONFIG_HARDENED_USERCOPY=y, this will correctly start tripping again. Reported-by: Muhammad Usama Anjum Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Reviewed-by: Muhammad Usama Anjum Link: https://lore.kernel.org/lkml/762faf1b-0443-5ddf-4430-44a20cf2ec4d@collabora.com/ Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit c8a27ebd19932fe4ad732e6437f86d4101922098 Author: Xiaoke Wang Date: Sat Mar 5 11:14:05 2022 +0800 iio: dummy: iio_simple_dummy: check the return value of kstrdup() [ Upstream commit ba93642188a6fed754bf7447f638bc410e05a929 ] kstrdup() is also a memory allocation-related function, it returns NULL when some memory errors happen. So it is better to check the return value of it so to catch the memory error in time. Besides, there should have a kfree() to clear up the allocation if we get a failure later in this function to prevent memory leak. Signed-off-by: Xiaoke Wang Link: https://lore.kernel.org/r/tencent_C920CFCC33B9CC1C63141FE1334A39FF8508@qq.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a013fa884d8738ad8455aa1a843b8c9d80c6c833 Author: Miaoqian Lin Date: Tue Jun 7 08:11:43 2022 +0400 net: altera: Fix refcount leak in altera_tse_mdio_create [ Upstream commit 11ec18b1d8d92b9df307d31950dcba0b3dd7283c ] Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: bbd2190ce96d ("Altera TSE: Add main and header file for Altera Ethernet Driver") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220607041144.7553-1-linmq006@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c58d82a1264813e69119c13e9804e2e60b664ad5 Author: Masahiro Yamada Date: Mon Jun 6 13:53:54 2022 +0900 net: xfrm: unexport __init-annotated xfrm4_protocol_init() [ Upstream commit 4a388f08d8784af48f352193d2b72aaf167a57a1 ] EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, net/ipv4/xfrm4_policy.c is never compiled as modular. (CONFIG_XFRM is boolean) Fixes: 2f32b51b609f ("xfrm: Introduce xfrm_input_afinfo to access the the callbacks properly") Reported-by: Stephen Rothwell Signed-off-by: Masahiro Yamada Acked-by: Steffen Klassert Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b419808712fc4fb4edc72cb29cd4d8994a3eacb7 Author: Chuck Lever Date: Tue Jun 7 16:47:52 2022 -0400 SUNRPC: Fix the calculation of xdr->end in xdr_get_next_encode_buffer() [ Upstream commit 6c254bf3b637dd4ef4f78eb78c7447419c0161d7 ] I found that NFSD's new NFSv3 READDIRPLUS XDR encoder was screwing up right at the end of the page array. xdr_get_next_encode_buffer() does not compute the value of xdr->end correctly: * The check to see if we're on the final available page in xdr->buf needs to account for the space consumed by @nbytes. * The new xdr->end value needs to account for the portion of @nbytes that is to be encoded into the previous buffer. Fixes: 2825a7f90753 ("nfsd4: allow encoding across page boundaries") Signed-off-by: Chuck Lever Reviewed-by: NeilBrown Reviewed-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 4d0f47dc7df635787a5288478b32486e18e87063 Author: Gal Pressman Date: Mon Jun 6 14:57:18 2022 +0300 net/mlx4_en: Fix wrong return value on ioctl EEPROM query failure [ Upstream commit f5826c8c9d57210a17031af5527056eefdc2b7eb ] The ioctl EEPROM query wrongly returns success on read failures, fix that by returning the appropriate error code. Fixes: 7202da8b7f71 ("ethtool, net/mlx4_en: Cable info, get_module_info/eeprom ethtool support") Signed-off-by: Gal Pressman Signed-off-by: Tariq Toukan Link: https://lore.kernel.org/r/20220606115718.14233-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7bd85c5ba1687daf54e3b6907673c3604b1e75cf Author: Miaoqian Lin Date: Wed Jun 1 12:59:26 2022 +0400 ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe [ Upstream commit 10d6bdf532902be1d8aa5900b3c03c5671612aa2 ] of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() to avoid refcount leak. Fixes: 43f01da0f279 ("MIPS/OCTEON/ata: Convert pata_octeon_cf.c to use device tree.") Signed-off-by: Miaoqian Lin Reviewed-by: Sergey Shtylyov Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit f482637f73a073fb6cdbbe899533656f4072fe7f Author: Maciej Żenczykowski Date: Wed May 5 09:58:31 2021 -0700 net: fix nla_strcmp to handle more then one trailing null character [ Upstream commit 2c16db6c92b0ee4aa61e88366df82169e83c3f7e ] Android userspace has been using TCA_KIND with a char[IFNAMESIZ] many-null-terminated buffer containing the string 'bpf'. This works on 4.19 and ceases to work on 5.10. I'm not entirely sure what fixes tag to use, but I think the issue was likely introduced in the below mentioned 5.4 commit. Reported-by: Nucca Chen Cc: Cong Wang Cc: David Ahern Cc: David S. Miller Cc: Jakub Kicinski Cc: Jamal Hadi Salim Cc: Jiri Pirko Cc: Jiri Pirko Fixes: 62794fc4fbf5 ("net_sched: add max len check for TCA_KIND") Change-Id: I66dc281f165a2858fc29a44869a270a2d698a82b Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 235c477d492ce598db7f91efad9de9df78a2ee09 Author: Yang Yingliang Date: Fri May 13 18:05:41 2022 +0800 video: fbdev: pxa3xx-gcu: release the resources correctly in pxa3xx_gcu_probe/remove() [ Upstream commit d87ad457f7e1b8d2492ca5b1531eb35030a1cc8f ] In pxa3xx_gcu_probe(), the sequence of error lable is wrong, it will leads some resource leaked, so adjust the sequence to handle the error correctly, and if pxa3xx_gcu_add_buffer() fails, pxa3xx_gcu_free_buffers() need be called. In pxa3xx_gcu_remove(), add missing clk_disable_unpreprare(). Signed-off-by: Yang Yingliang Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 656d3c82e3831c85a4c5ab87ae668f3917c82677 Author: Greg Ungerer Date: Fri May 13 17:27:39 2022 +1000 m68knommu: fix undefined reference to `_init_sp' [ Upstream commit a71b9e66fee47c59b3ec34e652b5c23bc6550794 ] When configuring a nommu classic m68k system enabling the uboot parameter passing support (CONFIG_UBOOT) will produce the following compile error: m68k-linux-ld: arch/m68k/kernel/uboot.o: in function `process_uboot_commandline': uboot.c:(.init.text+0x32): undefined reference to `_init_sp' The logic to support this option is only used on ColdFire based platforms (in its head.S startup code). So make the selection of this option depend on building for a ColdFire based platform. Reported-by: kernel test robot Reviewed-by: Geert Uytterhoeven Acked-by: Geert Uytterhoeven Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 7a8c4ad74a0c8e7ddef0cca1a376d79a6330d147 Author: Greg Ungerer Date: Wed Apr 20 23:27:47 2022 +1000 m68knommu: set ZERO_PAGE() to the allocated zeroed page [ Upstream commit dc068f46217970d9516f16cd37972a01d50dc055 ] The non-MMU m68k pagetable ZERO_PAGE() macro is being set to the somewhat non-sensical value of "virt_to_page(0)". The zeroth page is not in any way guaranteed to be a page full of "0". So the result is that ZERO_PAGE() will almost certainly contain random values. We already allocate a real "empty_zero_page" in the mm setup code shared between MMU m68k and non-MMU m68k. It is just not hooked up to the ZERO_PAGE() macro for the non-MMU m68k case. Fix ZERO_PAGE() to use the allocated "empty_zero_page" pointer. I am not aware of any specific issues caused by the old code. Link: https://lore.kernel.org/linux-m68k/2a462b23-5b8e-bbf4-ec7d-778434a3b9d7@google.com/T/#t Reported-by: Hugh Dickens Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 631d7614792cb8c8cdc47ba27b93cf587d404b28 Author: Lucas Tanure Date: Wed Apr 13 10:14:10 2022 +0100 i2c: cadence: Increase timeout per message if necessary [ Upstream commit 96789dce043f5bff8b7d62aa28d52a7c59403a84 ] Timeout as 1 second sets an upper limit on the length of the transfer executed, but there is no maximum length of a write or read message set in i2c_adapter_quirks for this controller. This upper limit affects devices that require sending large firmware blobs over I2C. To remove that limitation, calculate the minimal time necessary, plus some wiggle room, for every message and use it instead of the default one second, if more than one second. Signed-off-by: Lucas Tanure Acked-by: Michal Simek Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 5b9cdc59475e86ee9ceddeefea33af1ab9d4f93b Author: Mark-PK Tsai Date: Tue Apr 26 20:24:06 2022 +0800 tracing: Avoid adding tracer option before update_tracer_options [ Upstream commit ef9188bcc6ca1d8a2ad83e826b548e6820721061 ] To prepare for support asynchronous tracer_init_tracefs initcall, avoid calling create_trace_option_files before __update_tracer_options. Otherwise, create_trace_option_files will show warning because some tracers in trace_types list are already in tr->topts. For example, hwlat_tracer call register_tracer in late_initcall, and global_trace.dir is already created in tracing_init_dentry, hwlat_tracer will be put into tr->topts. Then if the __update_tracer_options is executed after hwlat_tracer registered, create_trace_option_files find that hwlat_tracer is already in tr->topts. Link: https://lkml.kernel.org/r/20220426122407.17042-2-mark-pk.tsai@mediatek.com Link: https://lore.kernel.org/lkml/20220322133339.GA32582@xsang-OptiPlex-9020/ Reported-by: kernel test robot Signed-off-by: Mark-PK Tsai Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 3db889f883e65bbd3b1401279bfc1e9ed255c481 Author: Eric Dumazet Date: Mon May 30 14:37:13 2022 -0700 tcp: tcp_rtx_synack() can be called from process context [ Upstream commit 0a375c822497ed6ad6b5da0792a12a6f1af10c0b ] Laurent reported the enclosed report [1] This bug triggers with following coditions: 0) Kernel built with CONFIG_DEBUG_PREEMPT=y 1) A new passive FastOpen TCP socket is created. This FO socket waits for an ACK coming from client to be a complete ESTABLISHED one. 2) A socket operation on this socket goes through lock_sock() release_sock() dance. 3) While the socket is owned by the user in step 2), a retransmit of the SYN is received and stored in socket backlog. 4) At release_sock() time, the socket backlog is processed while in process context. 5) A SYNACK packet is cooked in response of the SYN retransmit. 6) -> tcp_rtx_synack() is called in process context. Before blamed commit, tcp_rtx_synack() was always called from BH handler, from a timer handler. Fix this by using TCP_INC_STATS() & NET_INC_STATS() which do not assume caller is in non preemptible context. [1] BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180 caller is tcp_rtx_synack.part.0+0x36/0xc0 CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1 Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021 Call Trace: dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path") Signed-off-by: Eric Dumazet Reported-by: Laurent Fasnacht Acked-by: Neal Cardwell Link: https://lore.kernel.org/r/20220530213713.601888-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4ba7bbeab8009faf3a726e565d98816593ddd5b0 Author: Baokun Li Date: Tue Apr 12 17:38:16 2022 +0800 jffs2: fix memory leak in jffs2_do_fill_super [ Upstream commit c14adb1cf70a984ed081c67e9d27bc3caad9537c ] If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns an error, we can observe the following kmemleak report: -------------------------------------------- unreferenced object 0xffff888105a65340 (size 64): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmem_cache_alloc_trace+0x475/0x8a0 [] jffs2_sum_init+0x96/0x1a0 [] jffs2_do_mount_fs+0x745/0x2120 [] jffs2_do_fill_super+0x35c/0x810 [] jffs2_fill_super+0x2b9/0x3b0 [...] unreferenced object 0xffff8881bd7f0000 (size 65536): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [] kmalloc_order+0xda/0x110 [] kmalloc_order_trace+0x21/0x130 [] __kmalloc+0x711/0x8a0 [] jffs2_sum_init+0xd9/0x1a0 [] jffs2_do_mount_fs+0x745/0x2120 [] jffs2_do_fill_super+0x35c/0x810 [] jffs2_fill_super+0x2b9/0x3b0 [...] -------------------------------------------- This is because the resources allocated in jffs2_sum_init() are not released. Call jffs2_sum_exit() to release these resources to solve the problem. Fixes: e631ddba5887 ("[JFFS2] Add erase block summary support (mount time improvement)") Signed-off-by: Baokun Li Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit c6f44c880ab47e691e88abf7a391b74d6c59269a Author: Alexander Lobakin Date: Tue May 24 17:27:18 2022 +0200 modpost: fix removing numeric suffixes [ Upstream commit b5beffa20d83c4e15306c991ffd00de0d8628338 ] With the `-z unique-symbol` linker flag or any similar mechanism, it is possible to trigger the following: ERROR: modpost: "param_set_uint.0" [vmlinux] is a static EXPORT_SYMBOL The reason is that for now the condition from remove_dot(): if (m && (s[n + m] == '.' || s[n + m] == 0)) which was designed to test if it's a dot or a '\0' after the suffix is never satisfied. This is due to that `s[n + m]` always points to the last digit of a numeric suffix, not on the symbol next to it (from a custom debug print added to modpost): param_set_uint.0, s[n + m] is '0', s[n + m + 1] is '\0' So it's off-by-one and was like that since 2014. Fix this for the sake of any potential upcoming features, but don't bother stable-backporting, as it's well hidden -- apart from that LD flag, it can be triggered only with GCC LTO which never landed upstream. Fixes: fcd38ed0ff26 ("scripts: modpost: fix compilation warning") Signed-off-by: Alexander Lobakin Reviewed-by: Petr Mladek Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit b4f0e57ea0d867aacffad7999527e48bd4ea9293 Author: Dan Carpenter Date: Thu May 26 11:02:42 2022 +0300 net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry() [ Upstream commit e7e7104e2d5ddf3806a28695670f21bef471f1e1 ] The "fsp->location" variable comes from user via ethtool_get_rxnfc(). Check that it is valid to prevent an out of bounds read. Fixes: 7aab747e5563 ("net: ethernet: mediatek: add ethtool functions to configure RX flows of HW LRO") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fb8be6c54f0059ea9c7617ac2ea9858d702f371f Author: Krzysztof Kozlowski Date: Fri Apr 22 12:41:01 2022 +0200 clocksource/drivers/oxnas-rps: Fix irq_of_parse_and_map() return value [ Upstream commit 9c04a8ff03def4df3f81219ffbe1ec9b44ff5348 ] The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO. Fixes: 89355274e1f7 ("clocksource/drivers/oxnas-rps: Add Oxford Semiconductor RPS Dual Timer") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20220422104101.55754-1-krzysztof.kozlowski@linaro.org Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit a9bfb37d6ba7c376b0d53337a4c5f5ff324bd725 Author: Miaoqian Lin Date: Wed May 11 11:14:19 2022 +0400 firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle [ Upstream commit 660ba678f9998aca6db74f2dd912fa5124f0fa31 ] kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by calling kobject_put(). Fixes: 948af1f0bbc8 ("firmware: Basic dmi-sysfs support") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220511071421.9769-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 87cdcaa2f2f34d4aeaeba657137b44f6877be75d Author: Ilpo Järvinen Date: Thu May 19 11:18:06 2022 +0300 serial: st-asc: Sanitize CSIZE and correct PARENB for CS7 [ Upstream commit 52bb1cb7118564166b04d52387bd8403632f5190 ] Only CS7 and CS8 seem supported but CSIZE is not sanitized from CS5 or CS6 to CS8. In addition, ASC_CTL_MODE_7BIT_PAR suggests that CS7 has to have parity, thus add PARENB. Incorrect CSIZE results in miscalculation of the frame bits in tty_get_char_size() or in its predecessor where the roughly the same code is directly within uart_update_timeout(). Fixes: c4b058560762 (serial:st-asc: Add ST ASC driver.) Cc: Srinivas Kandagatla Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20220519081808.3776-8-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 82b57890e82c9dac3fd2020541ede3ed6513ec1e Author: Ilpo Järvinen Date: Thu May 19 11:18:04 2022 +0300 serial: sh-sci: Don't allow CS5-6 [ Upstream commit 9b87162de8be26bf3156460b37deee6399fd0fcb ] Only CS7 and CS8 seem supported but CSIZE is not sanitized from CS5 or CS6 to CS8. Set CSIZE correctly so that userspace knows the effective value. Incorrect CSIZE also results in miscalculation of the frame bits in tty_get_char_size() or in its predecessor where the roughly the same code is directly within uart_update_timeout(). Fixes: 1da177e4c3f4 (Linux-2.6.12-rc2) Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20220519081808.3776-6-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 13cbbf6d2e8802d164c778d9b3700c3051a06f42 Author: Ilpo Järvinen Date: Thu May 19 11:18:03 2022 +0300 serial: txx9: Don't allow CS5-6 [ Upstream commit 79ac88655dc0551e3571ad16bdabdbe65d61553e ] Only CS7 and CS8 are supported but CSIZE is not sanitized with CS5 or CS6 to CS8. Set CSIZE correctly so that userspace knows the effective value. Incorrect CSIZE also results in miscalculation of the frame bits in tty_get_char_size() or in its predecessor where the roughly the same code is directly within uart_update_timeout(). Fixes: 1da177e4c3f4 (Linux-2.6.12-rc2) Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20220519081808.3776-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 566c075bd70ef0215d61ef2dd86a65f027a51dc3 Author: Ilpo Järvinen Date: Thu May 19 11:18:01 2022 +0300 serial: digicolor-usart: Don't allow CS5-6 [ Upstream commit fd63031b8c0763addcecdefe0e0c59d49646204e ] Only CS7 and CS8 seem supported but CSIZE is not sanitized to CS8 in the default: block. Set CSIZE correctly so that userspace knows the effective value. Incorrect CSIZE also results in miscalculation of the frame bits in tty_get_char_size() or in its predecessor where the roughly the same code is directly within uart_update_timeout(). Fixes: 5930cb3511df (serial: driver for Conexant Digicolor USART) Acked-by: Baruch Siach Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20220519081808.3776-3-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 574c89ce0aaec426c7efb2e4a8a8defa1dfc8397 Author: John Ogness Date: Sun May 8 12:41:47 2022 +0206 serial: meson: acquire port->lock in startup() [ Upstream commit 589f892ac8ef244e47c5a00ffd8605daa1eaef8e ] The uart_ops startup() callback is called without interrupts disabled and without port->lock locked, relatively late during the boot process (from the call path of console_on_rootfs()). If the device is a console, it was already previously registered and could be actively printing messages. Since the startup() callback is reading/writing registers used by the console write() callback (AML_UART_CONTROL), its access must be synchronized using the port->lock. Currently it is not. The startup() callback is the only function that explicitly enables interrupts. Without the synchronization, it is possible that interrupts become accidentally permanently disabled. CPU0 CPU1 meson_serial_console_write meson_uart_startup -------------------------- ------------------ spin_lock(port->lock) val = readl(AML_UART_CONTROL) uart_console_write() writel(INT_EN, AML_UART_CONTROL) writel(val, AML_UART_CONTROL) spin_unlock(port->lock) Add port->lock synchronization to meson_uart_startup() to avoid racing with meson_serial_console_write(). Also add detailed comments to meson_uart_reset() explaining why it is *not* using port->lock synchronization. Link: https://lore.kernel.org/lkml/2a82eae7-a256-f70c-fd82-4e510750906e@samsung.com Fixes: ff7693d079e5 ("ARM: meson: serial: add MesonX SoC on-chip uart driver") Reported-by: Marek Szyprowski Tested-by: Marek Szyprowski Reviewed-by: Petr Mladek Reviewed-by: Jiri Slaby Acked-by: Neil Armstrong Signed-off-by: John Ogness Link: https://lore.kernel.org/r/20220508103547.626355-1-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3867f0bbb94773d41e789257abec0d14f37da217 Author: Yang Yingliang Date: Thu May 5 20:50:43 2022 +0800 rtc: mt6397: check return value after calling platform_get_resource() [ Upstream commit d3b43eb505bffb8e4cdf6800c15660c001553fe6 ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Fixes: fc2979118f3f ("rtc: mediatek: Add MT6397 RTC driver") Signed-off-by: Yang Yingliang Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220505125043.1594771-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit 6c493fde4c5bcbd28e80e120bacbfe2633018f26 Author: Krzysztof Kozlowski Date: Fri Apr 22 12:53:26 2022 +0200 rpmsg: qcom_smd: Fix irq_of_parse_and_map() return value [ Upstream commit 1a358d35066487d228a68303d808bc4721c6b1b9 ] The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO. Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220422105326.78713-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit 1999e2c432beeea858f25771ccb0c3faf749ca35 Author: Uwe Kleine-König Date: Fri Apr 8 17:22:38 2022 +0200 pwm: lp3943: Fix duty calculation in case period was clamped [ Upstream commit 5e3b07ca5cc78cd4a987e78446849e41288d87cb ] The hardware only supports periods <= 1.6 ms and if a bigger period is requested it is clamped to 1.6 ms. In this case duty_cycle might be bigger than 1.6 ms and then the duty cycle register is written with a value bigger than LP3943_MAX_DUTY. So clamp duty_cycle accordingly. Fixes: af66b3c0934e ("pwm: Add LP3943 PWM driver") Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 1a46a4a13f3d6dec09aee9641bc0af0e4d73a6af Author: Lin Ma Date: Tue Apr 12 22:43:59 2022 +0800 USB: storage: karma: fix rio_karma_init return [ Upstream commit b92ffb1eddd9a66a90defc556dcbf65a43c196c7 ] The function rio_karam_init() should return -ENOMEM instead of value 0 (USB_STOR_TRANSPORT_GOOD) when allocation fails. Similarly, it should return -EIO when rio_karma_send_command() fails. Fixes: dfe0d3ba20e8 ("USB Storage: add rio karma eject support") Acked-by: Alan Stern Signed-off-by: Lin Ma Link: https://lore.kernel.org/r/20220412144359.28447-1-linma@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 86c1fc0d154c7f98413c51943c5fc95d8da43b64 Author: Niels Dossche Date: Tue Apr 12 18:50:55 2022 +0200 usb: usbip: add missing device lock on tweak configuration cmd [ Upstream commit d088fabace2ca337b275d1d4b36db4fe7771e44f ] The function documentation of usb_set_configuration says that its callers should hold the device lock. This lock is held for all callsites except tweak_set_configuration_cmd. The code path can be executed for example when attaching a remote USB device. The solution is to surround the call by the device lock. This bug was found using my experimental own-developed static analysis tool, which reported the missing lock on v5.17.2. I manually verified this bug report by doing code review as well. I runtime checked that the required lock is not held. I compiled and runtime tested this on x86_64 with a USB mouse. After applying this patch, my analyser no longer reports this potential bug. Fixes: 2c8c98158946 ("staging: usbip: let client choose device configuration") Reviewed-by: Shuah Khan Signed-off-by: Niels Dossche Link: https://lore.kernel.org/r/20220412165055.257113-1-dossche.niels@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6bafee2f18af5e5ac125e42960bc65496d0e56a0 Author: Hangyu Hua Date: Tue Apr 12 10:02:57 2022 +0800 usb: usbip: fix a refcount leak in stub_probe() [ Upstream commit 9ec4cbf1cc55d126759051acfe328d489c5d6e60 ] usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review. Fixes: 3ff67445750a ("usbip: fix error handling in stub_probe()") Reviewed-by: Shuah Khan Signed-off-by: Hangyu Hua Link: https://lore.kernel.org/r/20220412020257.9767-1-hbh25y@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 61ca94fab3a82ab8b2f608b4774a41beb0d3ca31 Author: Jakob Koschel Date: Mon Mar 21 13:36:26 2022 +0100 staging: greybus: codecs: fix type confusion of list iterator variable [ Upstream commit 84ef256550196bc06e6849a34224c998b45bd557 ] If the list does not exit early then data == NULL and 'module' does not point to a valid list element. Using 'module' in such a case is not valid and was therefore removed. Fixes: 6dd67645f22c ("greybus: audio: Use single codec driver registration") Reviewed-by: Dan Carpenter Reviewed-by: Vaibhav Agarwal Reviewed-by: Mark Greer Signed-off-by: Jakob Koschel Link: https://lore.kernel.org/r/20220321123626.3068639-1-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4063e2fecdac2885f2710a9f3736832bcd7bf9da Author: Randy Dunlap Date: Sun Jan 23 09:40:31 2022 -0800 pcmcia: db1xxx_ss: restrict to MIPS_DB1XXX boards [ Upstream commit 3928cf08334ed895a31458cbebd8d4ec6d84c080 ] When the MIPS_ALCHEMY board selection is MIPS_XXS1500 instead of MIPS_DB1XXX, the PCMCIA driver 'db1xxx_ss' has build errors due to missing DB1XXX symbols. The PCMCIA driver should be restricted to MIPS_DB1XXX instead of MIPS_ALCHEMY to fix this build error. ERROR: modpost: "bcsr_read" [drivers/pcmcia/db1xxx_ss.ko] undefined! ERROR: modpost: "bcsr_mod" [drivers/pcmcia/db1xxx_ss.ko] undefined! Fixes: 42a4f17dc356 ("MIPS: Alchemy: remove SOC_AU1X00 in favor of MIPS_ALCHEMY") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Arnd Bergmann Cc: Daniel Vetter Cc: Kees Cook Cc: Thomas Bogendoerfer Cc: linux-mips@vger.kernel.org Acked-by: Manuel Lauss Signed-off-by: Dominik Brodowski Signed-off-by: Sasha Levin commit 94e9b75919619ba8c4072abc4917011a7a888a79 Author: Pablo Neira Ayuso Date: Wed May 25 10:36:38 2022 +0200 netfilter: nf_tables: disallow non-stateful expression in sets earlier commit 520778042ccca019f3ffa136dd0ca565c486cedd upstream. Since 3e135cd499bf ("netfilter: nft_dynset: dynamic stateful expression instantiation"), it is possible to attach stateful expressions to set elements. cd5125d8f518 ("netfilter: nf_tables: split set destruction in deactivate and destroy phase") introduces conditional destruction on the object to accomodate transaction semantics. nft_expr_init() calls expr->ops->init() first, then check for NFT_STATEFUL_EXPR, this stills allows to initialize a non-stateful lookup expressions which points to a set, which might lead to UAF since the set is not properly detached from the set->binding for this case. Anyway, this combination is non-sense from nf_tables perspective. This patch fixes this problem by checking for NFT_STATEFUL_EXPR before expr->ops->init() is called. The reporter provides a KASAN splat and a poc reproducer (similar to those autogenerated by syzbot to report use-after-free errors). It is unknown to me if they are using syzbot or if they use similar automated tool to locate the bug that they are reporting. For the record, this is the KASAN splat. [ 85.431824] ================================================================== [ 85.432901] BUG: KASAN: use-after-free in nf_tables_bind_set+0x81b/0xa20 [ 85.433825] Write of size 8 at addr ffff8880286f0e98 by task poc/776 [ 85.434756] [ 85.434999] CPU: 1 PID: 776 Comm: poc Tainted: G W 5.18.0+ #2 [ 85.436023] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Fixes: 0b2d8a7b638b ("netfilter: nf_tables: add helper functions for expression handling") Reported-and-tested-by: Aaron Adams Signed-off-by: Pablo Neira Ayuso [Ajay: Regenerated the patch for v4.9.y] Signed-off-by: Ajay Kaher Signed-off-by: Greg Kroah-Hartman commit 0892e19f4b91367eef54663b75f075c8f42689d8 Author: Maciej W. Rozycki Date: Sun May 1 23:14:16 2022 +0100 MIPS: IP27: Remove incorrect `cpu_has_fpu' override commit 424c3781dd1cb401857585331eaaa425a13f2429 upstream. Remove unsupported forcing of `cpu_has_fpu' to 1, which makes the `nofpu' kernel parameter non-functional, and also causes a link error: ld: arch/mips/kernel/traps.o: in function `trap_init': ./arch/mips/include/asm/msa.h:(.init.text+0x348): undefined reference to `handle_fpe' ld: ./arch/mips/include/asm/msa.h:(.init.text+0x354): undefined reference to `handle_fpe' ld: ./arch/mips/include/asm/msa.h:(.init.text+0x360): undefined reference to `handle_fpe' where the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled. Signed-off-by: Maciej W. Rozycki Reported-by: Stephen Zhang Fixes: 0ebb2f4159af ("MIPS: IP27: Update/restructure CPU overrides") Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 6b6bd9e1f0855c7f717d90a657beebdb2213e679 Author: Xiao Yang Date: Sun Apr 10 19:35:13 2022 +0800 RDMA/rxe: Generate a completion for unsupported/invalid opcode commit 2f917af777011c88e977b9b9a5d00b280d3a59ce upstream. Current rxe_requester() doesn't generate a completion when processing an unsupported/invalid opcode. If rxe driver doesn't support a new opcode (e.g. RDMA Atomic Write) and RDMA library supports it, an application using the new opcode can reproduce this issue. Fix the issue by calling "goto err;". Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20220410113513.27537-1-yangx.jy@fujitsu.com Signed-off-by: Xiao Yang Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 9af670b08007d2dd1a4acbdf700bc93615f3d0c2 Author: Dinh Nguyen Date: Wed May 11 12:54:46 2022 -0500 dt-bindings: gpio: altera: correct interrupt-cells commit 3a21c3ac93aff7b4522b152399df8f6a041df56d upstream. update documentation to correctly state the interrupt-cells to be 2. Cc: stable@vger.kernel.org Fixes: 4fd9bbc6e071 ("drivers/gpio: Altera soft IP GPIO driver devicetree binding") Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit 7373dd32b0965e18c6714d38d90c853a241059e5 Author: Akira Yokosawa Date: Wed Jun 1 23:34:06 2022 +0900 docs/conf.py: Cope with removal of language=None in Sphinx 5.0.0 commit 627f01eab93d8671d4e4afee9b148f9998d20e7c upstream. One of the changes in Sphinx 5.0.0 [1] says [sic]: 5.0.0 final - #10474: language does not accept None as it value. The default value of language becomes to 'en' now. [1]: https://www.sphinx-doc.org/en/master/changes.html#release-5-0-0-released-may-30-2022 It results in a new warning from Sphinx 5.0.0 [sic]: WARNING: Invalid configuration value found: 'language = None'. Update your configuration to a valid langauge code. Falling back to 'en' (English). Silence the warning by using 'en'. It works with all the Sphinx versions required for building kernel documentation (1.7.9 or later). Signed-off-by: Akira Yokosawa Link: https://lore.kernel.org/r/bd0c2ddc-2401-03cb-4526-79ca664e1cbe@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman commit b71d97bf744c8aea3e1bcfb7dec5369600c1554b Author: Xiaomeng Tong Date: Sun Mar 27 13:20:28 2022 +0800 gma500: fix an incorrect NULL check on list iterator commit bdef417d84536715145f6dc9cc3275c46f26295a upstream. The bug is here: return crtc; The list iterator value 'crtc' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, return 'crtc' when found, otherwise return NULL. Cc: stable@vger.kernel.org fixes: 89c78134cc54d ("gma500: Add Poulsbo support") Signed-off-by: Xiaomeng Tong Signed-off-by: Patrik Jakobsson Link: https://patchwork.freedesktop.org/patch/msgid/20220327052028.2013-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5786262a4eac987253d4c224c30595235d341470 Author: Xiaomeng Tong Date: Mon Mar 28 20:28:20 2022 +0800 carl9170: tx: fix an incorrect use of list iterator commit 54a6f29522da3c914da30e50721dedf51046449a upstream. If the previous list_for_each_entry_continue_rcu() don't exit early (no goto hit inside the loop), the iterator 'cvif' after the loop will be a bogus pointer to an invalid structure object containing the HEAD (&ar->vif_list). As a result, the use of 'cvif' after that will lead to a invalid memory access (i.e., 'cvif->id': the invalid pointer dereference when return back to/after the callsite in the carl9170_update_beacon()). The original intention should have been to return the valid 'cvif' when found in list, NULL otherwise. So just return NULL when no entry found, to fix this bug. Cc: stable@vger.kernel.org Fixes: 1f1d9654e183c ("carl9170: refactor carl9170_update_beacon") Signed-off-by: Xiaomeng Tong Acked-by: Christian Lamparter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220328122820.1004-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman commit fb1cc5895c29b106adba38482e4089d50f756fd1 Author: Mark Brown Date: Thu Apr 28 17:24:44 2022 +0100 ASoC: rt5514: Fix event generation for "DSP Voice Wake Up" control commit 4213ff556740bb45e2d9ff0f50d056c4e7dd0921 upstream. The driver has a custom put function for "DSP Voice Wake Up" which does not generate event notifications on change, instead returning 0. Since we already exit early in the case that there is no change this can be fixed by unconditionally returning 1 at the end of the function. Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220428162444.3883147-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b5dca2cd3f0239512da808598b4e70557eb4c2a1 Author: Alexander Wetzel Date: Fri Apr 22 16:52:28 2022 +0200 rtl818x: Prevent using not initialized queues commit 746285cf81dc19502ab238249d75f5990bd2d231 upstream. Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html He also confirmed that this patch fixes the issue. In summary this happened: After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10. Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards. rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized. Cc: stable@vger.kernel.org Reported-by: pa@panix.com Tested-by: pa@panix.com Signed-off-by: Alexander Wetzel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220422145228.7567-1-alexander@wetzel-home.de Signed-off-by: Greg Kroah-Hartman commit 25719eba873c689e65e8f12e7ce8d3e86fd9f91f Author: Mike Kravetz Date: Tue May 24 13:50:03 2022 -0700 hugetlb: fix huge_pmd_unshare address update commit 48381273f8734d28ef56a5bdf1966dd8530111bc upstream. The routine huge_pmd_unshare() is passed a pointer to an address associated with an area which may be unshared. If unshare is successful this address is updated to 'optimize' callers iterating over huge page addresses. For the optimization to work correctly, address should be updated to the last huge page in the unmapped/unshared area. However, in the common case where the passed address is PUD_SIZE aligned, the address is incorrectly updated to the address of the preceding huge page. That wastes CPU cycles as the unmapped/unshared range is scanned twice. Link: https://lkml.kernel.org/r/20220524205003.126184-1-mike.kravetz@oracle.com Fixes: 39dde65c9940 ("shared page table for hugetlb page") Signed-off-by: Mike Kravetz Acked-by: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c763ba737af56565c4b9bdd7f7e4ccfc1d5619a0 Author: Christophe de Dinechin Date: Thu Apr 14 17:08:54 2022 +0200 nodemask.h: fix compilation error with GCC12 commit 37462a920392cb86541650a6f4121155f11f1199 upstream. With gcc version 12.0.1 20220401 (Red Hat 12.0.1-0), building with defconfig results in the following compilation error: | CC mm/swapfile.o | mm/swapfile.c: In function `setup_swap_info': | mm/swapfile.c:2291:47: error: array subscript -1 is below array bounds | of `struct plist_node[]' [-Werror=array-bounds] | 2291 | p->avail_lists[i].prio = 1; | | ~~~~~~~~~~~~~~^~~ | In file included from mm/swapfile.c:16: | ./include/linux/swap.h:292:27: note: while referencing `avail_lists' | 292 | struct plist_node avail_lists[]; /* | | ^~~~~~~~~~~ This is due to the compiler detecting that the mask in node_states[__state] could theoretically be zero, which would lead to first_node() returning -1 through find_first_bit. I believe that the warning/error is legitimate. I first tried adding a test to check that the node mask is not emtpy, since a similar test exists in the case where MAX_NUMNODES == 1. However, adding the if statement causes other warnings to appear in for_each_cpu_node_but, because it introduces a dangling else ambiguity. And unfortunately, GCC is not smart enough to detect that the added test makes the case where (node) == -1 impossible, so it still complains with the same message. This is why I settled on replacing that with a harmless, but relatively useless (node) >= 0 test. Based on the warning for the dangling else, I also decided to fix the case where MAX_NUMNODES == 1 by moving the condition inside the for loop. It will still only be tested once. This ensures that the meaning of an else following for_each_node_mask or derivatives would not silently have a different meaning depending on the configuration. Link: https://lkml.kernel.org/r/20220414150855.2407137-3-dinechin@redhat.com Signed-off-by: Christophe de Dinechin Signed-off-by: Christophe de Dinechin Reviewed-by: Andrew Morton Cc: Ben Segall Cc: "Michael S. Tsirkin" Cc: Steven Rostedt Cc: Ingo Molnar Cc: Mel Gorman Cc: Dietmar Eggemann Cc: Vincent Guittot Cc: Paolo Bonzini Cc: Daniel Bristot de Oliveira Cc: Jason Wang Cc: Zhen Lei Cc: Juri Lelli Cc: Peter Zijlstra Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5cca15036ff31966a299b3a90d99b7e38026db6b Author: Xiaomeng Tong Date: Sun May 1 21:28:23 2022 +0800 iommu/msm: Fix an incorrect NULL check on list iterator commit 8b9ad480bd1dd25f4ff4854af5685fa334a2f57a upstream. The bug is here: if (!iommu || iommu->dev->of_node != spec->np) { The list iterator value 'iommu' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found (in fact, it will point to a invalid structure object containing HEAD). To fix the bug, use a new value 'iter' as the list iterator, while use the old value 'iommu' as a dedicated variable to point to the found one, and remove the unneeded check for 'iommu->dev->of_node != spec->np' outside the loop. Cc: stable@vger.kernel.org Fixes: f78ebca8ff3d6 ("iommu/msm: Add support for generic master bindings") Signed-off-by: Xiaomeng Tong Link: https://lore.kernel.org/r/20220501132823.12714-1-xiam0nd.tong@gmail.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 668ca34a428d6ffc0f99a1a6a9b661a288d4183b Author: Vincent Whitchurch Date: Mon May 23 16:04:03 2022 +0200 um: Fix out-of-bounds read in LDT setup commit 2a4a62a14be1947fa945c5c11ebf67326381a568 upstream. syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ================================================================== Fixes: 858259cf7d1c443c83 ("uml: maintain own LDT entries") Signed-off-by: Vincent Whitchurch Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 8b28302e8a4bdb4332132f439a429e1161b8d4a4 Author: Johannes Berg Date: Fri May 20 19:45:36 2022 +0200 um: chan_user: Fix winch_tramp() return value commit 57ae0b67b747031bc41fb44643aa5344ab58607e upstream. The previous fix here was only partially correct, it did result in returning a proper error value in case of error, but it also clobbered the pid that we need to return from this function (not just zero for success). As a result, it returned 0 here, but later this is treated as a pid and used to kill the process, but since it's now 0 we kill(0, SIGKILL), which makes UML kill itself rather than just the helper thread. Fix that and make it more obvious by using a separate variable for the pid. Fixes: ccf1236ecac4 ("um: fix error return code in winch_tramp()") Reported-and-tested-by: Nathan Chancellor Signed-off-by: Johannes Berg Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 796aa10b96b99c7b4ecf802b79c0e8b023ee75c2 Author: Felix Fietkau Date: Wed Apr 20 12:49:07 2022 +0200 mac80211: upgrade passive scan to active scan on DFS channels after beacon rx commit b041b7b9de6e1d4362de855ab90f9d03ef323edd upstream. In client mode, we can't connect to hidden SSID APs or SSIDs not advertised in beacons on DFS channels, since we're forced to passive scan. Fix this by sending out a probe request immediately after the first beacon, if active scan was requested by the user. Cc: stable@vger.kernel.org Reported-by: Catrinel Catrinescu Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20220420104907.36275-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 6dbd0a54e50433d47558537c1c5c11f63be688b9 Author: Max Filippov Date: Tue Apr 26 09:01:18 2022 -0700 irqchip: irq-xtensa-mx: fix initial IRQ affinity commit a255ee29252066d621df5d6b420bf534c6ba5bc0 upstream. When irq-xtensa-mx chip is used in non-SMP configuration its irq_set_affinity callback is not called leaving IRQ affinity set empty. As a result IRQ delivery does not work in that configuration. Initialize IRQ affinity of the xtensa MX interrupt distributor to CPU 0 for all external IRQ lines. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit f8ea3356e4aab6a5f964784980e925bc44babdd7 Author: Pali Rohár Date: Mon Apr 25 13:37:05 2022 +0200 irqchip/armada-370-xp: Do not touch Performance Counter Overflow on A375, A38x, A39x commit a3d66a76348daf559873f19afc912a2a7c2ccdaf upstream. Register ARMADA_370_XP_INT_FABRIC_MASK_OFFS is Armada 370 and XP specific and on new Armada platforms it has different meaning. It does not configure Performance Counter Overflow interrupt masking. So do not touch this register on non-A370/XP platforms (A375, A38x and A39x). Signed-off-by: Pali Rohár Cc: stable@vger.kernel.org Fixes: 28da06dfd9e4 ("irqchip: armada-370-xp: Enable the PMU interrupts") Reviewed-by: Andrew Lunn Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220425113706.29310-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman commit 252f4afd4557a2e7075f793a5c80fe6dd9e9ee4a Author: Dennis Dalessandro Date: Fri May 20 14:37:12 2022 -0400 RDMA/hfi1: Fix potential integer multiplication overflow errors commit f93e91a0372c922c20d5bee260b0f43b4b8a1bee upstream. When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow. Cc: stable@vger.kernel.org Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20220520183712.48973.29855.stgit@awfm-01.cornelisnetworks.com Reviewed-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 61751cdcd33b544d9c21855a4375fd30af6cf4ed Author: Xiaomeng Tong Date: Fri Apr 8 16:47:15 2022 +0800 md: fix an incorrect NULL check in md_reload_sb commit 64c54d9244a4efe9bc6e9c98e13c4bbb8bb39083 upstream. The bug is here: if (!rdev || rdev->desc_nr != nr) { The list iterator value 'rdev' will *always* be set and non-NULL by rdev_for_each_rcu(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element found (In fact, it will be a bogus pointer to an invalid struct object containing the HEAD). Otherwise it will bypass the check and lead to invalid memory access passing the check. To fix the bug, use a new variable 'iter' as the list iterator, while using the original variable 'pdev' as a dedicated pointer to point to the found element. Cc: stable@vger.kernel.org Fixes: 70bcecdb1534 ("md-cluster: Improve md_reload_sb to be less error prone") Signed-off-by: Xiaomeng Tong Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 30da8cb0e506e71e901476b997a5acf79f80bf46 Author: Xiaomeng Tong Date: Fri Apr 8 16:37:28 2022 +0800 md: fix an incorrect NULL check in does_sb_need_changing commit fc8738343eefc4ea8afb6122826dea48eacde514 upstream. The bug is here: if (!rdev) The list iterator value 'rdev' will *always* be set and non-NULL by rdev_for_each(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element found. Otherwise it will bypass the NULL check and lead to invalid memory access passing the check. To fix the bug, use a new variable 'iter' as the list iterator, while using the original variable 'rdev' as a dedicated pointer to point to the found element. Cc: stable@vger.kernel.org Fixes: 2aa82191ac36 ("md-cluster: Perform a lazy update") Acked-by: Guoqing Jiang Signed-off-by: Xiaomeng Tong Acked-by: Goldwyn Rodrigues Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 29b62b06774c41d0a5a7bb505bf367120bc70ecd Author: Brian Norris Date: Tue Mar 1 18:11:38 2022 -0800 drm/bridge: analogix_dp: Grab runtime PM reference for DP-AUX commit 8fb6c44fe8468f92ac7b8bbfcca4404a4e88645f upstream. If the display is not enable()d, then we aren't holding a runtime PM reference here. Thus, it's easy to accidentally cause a hang, if user space is poking around at /dev/drm_dp_aux0 at the "wrong" time. Let's get a runtime PM reference, and check that we "see" the panel. Don't force any panel power-up, etc., because that can be intrusive, and that's not what other drivers do (see drivers/gpu/drm/bridge/ti-sn65dsi86.c and drivers/gpu/drm/bridge/parade-ps8640.c.) Fixes: 0d97ad03f422 ("drm/bridge: analogix_dp: Remove duplicated code") Cc: Cc: Tomeu Vizoso Signed-off-by: Brian Norris Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20220301181107.v4.1.I773a08785666ebb236917b0c8e6c05e3de471e75@changeid Signed-off-by: Greg Kroah-Hartman commit 8189f44270db1be78169e11eec51a3eeb980bc63 Author: Dave Airlie Date: Mon May 23 10:24:18 2022 +1000 drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. commit 31ab27b14daaa75541a415c6794d6f3567fea44a upstream. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018 Signed-off-by: Dave Airlie Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d6531993c638aad433a52be5b6eb1e3d88e253ec Author: Manivannan Sadhasivam Date: Wed May 4 14:12:10 2022 +0530 scsi: ufs: qcom: Add a readl() to make sure ref_clk gets enabled commit 8eecddfca30e1651dc1c74531ed5eef21dcce7e3 upstream. In ufs_qcom_dev_ref_clk_ctrl(), it was noted that the ref_clk needs to be stable for at least 1us. Even though there is wmb() to make sure the write gets "completed", there is no guarantee that the write actually reached the UFS device. There is a good chance that the write could be stored in a Write Buffer (WB). In that case, even though the CPU waits for 1us, the ref_clk might not be stable for that period. So lets do a readl() to make sure that the previous write has reached the UFS device before udelay(). Also, the wmb() after writel_relaxed() is not really needed. Both writel() and readl() are ordered on all architectures and the CPU won't speculate instructions after readl() due to the in-built control dependency with read value on weakly ordered architectures. So it can be safely removed. Link: https://lore.kernel.org/r/20220504084212.11605-4-manivannan.sadhasivam@linaro.org Fixes: f06fcc7155dc ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations") Cc: stable@vger.kernel.org Reviewed-by: Bjorn Andersson Signed-off-by: Manivannan Sadhasivam Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 08295d192ca1ebbdd8dfc66f0b944a936f7a2e19 Author: Xiaomeng Tong Date: Thu Apr 14 12:02:31 2022 +0800 scsi: dc395x: Fix a missing check on list iterator commit 036a45aa587a10fa2abbd50fbd0f6c4cfc44f69f upstream. The bug is here: p->target_id, p->target_lun); The list iterator 'p' will point to a bogus position containing HEAD if the list is empty or no element is found. This case must be checked before any use of the iterator, otherwise it will lead to an invalid memory access. To fix this bug, add a check. Use a new variable 'iter' as the list iterator, and use the original variable 'p' as a dedicated pointer to point to the found element. Link: https://lore.kernel.org/r/20220414040231.2662-1-xiam0nd.tong@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Xiaomeng Tong Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1434cd71ad9f3a6beda3036972983b6c4869207c Author: Junxiao Bi via Ocfs2-devel Date: Wed May 18 16:52:24 2022 -0700 ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock commit 863e0d81b6683c4cbc588ad831f560c90e494bef upstream. When user_dlm_destroy_lock failed, it didn't clean up the flags it set before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of lock is still in used, next time when unlink invokes this function, it will return succeed, and then unlink will remove inode and dentry if lock is not in used(file closed), but the dlm lock is still linked in dlm lock resource, then when bast come in, it will trigger a panic due to user-after-free. See the following panic call trace. To fix this, USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink fail. For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN, USER_LOCK_BUSY is also required to be cleared. Even though spin lock is released in between, but USER_LOCK_IN_TEARDOWN is still set, for USER_LOCK_BUSY, if before every place that waits on this flag, USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow waits on the busy flag set by user_dlm_destroy_lock(), then we can simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix user_dlm_cluster_lock() which is the only function not following this. [ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink 004fb0000060000b5a90b8c847b72e1, error -16 from destroy [ 989.757536] ------------[ cut here ]------------ [ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173! [ 989.757876] invalid opcode: 0000 [#1] SMP [ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O) ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE) mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si ipmi_msghandler [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ksplice_2zhuk2jr_ib_ipoib_old] [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE 4.1.12-124.57.1.el6uek.x86_64 #2 [ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021 [ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti: ffff88017f7c8000 [ 989.762848] RIP: e030:[] [] __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs] [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246 [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX: 0000000000000003 [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI: ffff880174d48170 [ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09: 0000000000000000 [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12: ffff880174d48008 [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15: ffff88021db7a000 [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000) knlGS:ffff880247480000 [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4: 0000000000042660 [ 989.765081] Stack: [ 989.765167] 0000000000000003 ffff880174d48040 ffff88017f7cbd18 ffffffffc07d455f [ 989.765442] ffff88017f7cbd88 ffffffff816fb639 ffff88017f7cbd38 ffff8800361b5600 [ 989.765717] ffff88021db7a000 ffff88021f429380 0000000000000003 ffffffffc0453020 [ 989.765991] Call Trace: [ 989.766093] [] user_bast+0x5f/0xf0 [ocfs2_dlmfs] [ 989.766287] [] ? schedule_timeout+0x169/0x2d0 [ 989.766475] [] ? o2dlm_lock_ast_wrapper+0x20/0x20 [ocfs2_stack_o2cb] [ 989.766738] [] o2dlm_blocking_ast_wrapper+0x1a/0x20 [ocfs2_stack_o2cb] [ 989.767010] [] dlm_do_local_bast+0x46/0xe0 [ocfs2_dlm] [ 989.767217] [] ? dlm_lockres_calc_usage+0x4c/0x60 [ocfs2_dlm] [ 989.767466] [] dlm_thread+0xa31/0x1140 [ocfs2_dlm] [ 989.767662] [] ? __schedule+0x24a/0x810 [ 989.767834] [] ? __schedule+0x23e/0x810 [ 989.768006] [] ? __schedule+0x24a/0x810 [ 989.768178] [] ? __schedule+0x23e/0x810 [ 989.768349] [] ? __schedule+0x24a/0x810 [ 989.768521] [] ? __schedule+0x23e/0x810 [ 989.768693] [] ? __schedule+0x24a/0x810 [ 989.768893] [] ? __schedule+0x23e/0x810 [ 989.769067] [] ? __schedule+0x24a/0x810 [ 989.769241] [] ? wait_woken+0x90/0x90 [ 989.769411] [] ? dlm_kick_thread+0x80/0x80 [ocfs2_dlm] [ 989.769617] [] kthread+0xcb/0xf0 [ 989.769774] [] ? __schedule+0x24a/0x810 [ 989.769945] [] ? __schedule+0x24a/0x810 [ 989.770117] [] ? kthread_create_on_node+0x180/0x180 [ 989.770321] [] ret_from_fork+0x61/0x90 [ 989.770492] [] ? kthread_create_on_node+0x180/0x180 [ 989.770689] Code: d0 00 00 00 f0 45 7d c0 bf 00 20 00 00 48 89 83 c0 00 00 00 48 89 83 c8 00 00 00 e8 55 c1 8c c0 83 4b 04 10 48 83 c4 08 5b 5d c3 <0f> 0b 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 55 41 54 53 48 83 [ 989.771892] RIP [] __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs] [ 989.772174] RSP [ 989.772704] ---[ end trace ebd1e38cebcc93a8 ]--- [ 989.772907] Kernel panic - not syncing: Fatal exception [ 989.773173] Kernel Offset: disabled Link: https://lkml.kernel.org/r/20220518235224.87100-2-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Joseph Qi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5c79f40e6e216403602e62d162bb7581085dddba Author: Alexander Aring Date: Fri Apr 29 11:06:51 2022 -0400 dlm: fix missing lkb refcount handling commit 1689c169134f4b5a39156122d799b7dca76d8ddb upstream. We always call hold_lkb(lkb) if we increment lkb->lkb_wait_count. So, we always need to call unhold_lkb(lkb) if we decrement lkb->lkb_wait_count. This patch will add missing unhold_lkb(lkb) if we decrement lkb->lkb_wait_count. In case of setting lkb->lkb_wait_count to zero we need to countdown until reaching zero and call unhold_lkb(lkb). The waiters list unhold_lkb(lkb) can be removed because it's done for the last lkb_wait_count decrement iteration as it's done in _remove_from_waiters(). This issue was discovered by a dlm gfs2 test case which use excessively dlm_unlock(LKF_CANCEL) feature. Probably the lkb->lkb_wait_count value never reached above 1 if this feature isn't used and so it was not discovered before. The testcase ended in a rsb on the rsb keep data structure with a refcount of 1 but no lkb was associated with it, which is itself an invalid behaviour. A side effect of that was a condition in which the dlm was sending remove messages in a looping behaviour. With this patch that has not been reproduced. Cc: stable@vger.kernel.org Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit 2c55155cc365861044d9e6e80e342693e8805e33 Author: Alexander Aring Date: Mon Apr 4 16:06:30 2022 -0400 dlm: fix plock invalid read commit 42252d0d2aa9b94d168241710a761588b3959019 upstream. This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plock_op" and a followed send_op() will append it to a global send_list data structure. In some cases a followed dev_read() moves it to recv_list and dev_write() will cast it to "struct plock_xop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields. To fix this issue the "callback" field is moved to "struct plock_op" to indicate that a cast to "plock_xop" is allowed and does the additional "plock_xop" handling if set. Example of the KASAN output which showed the invalid read: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 [dlm] [ 2064.399932] process_recv_sockets+0x32/0x40 [dlm] [ 2064.402180] process_one_work+0x9a8/0x16e0 [ 2064.404388] worker_thread+0x87/0xbf0 [ 2064.406124] kthread+0x3ac/0x490 [ 2064.408021] ret_from_fork+0x22/0x30 [ 2064.409834] [ 2064.410599] The buggy address belongs to the object at ffff88800ef22780 [ 2064.410599] which belongs to the cache kmalloc-96 of size 96 [ 2064.416495] The buggy address is located 88 bytes inside of [ 2064.416495] 96-byte region [ffff88800ef22780, ffff88800ef227e0) [ 2064.422045] The buggy address belongs to the page: [ 2064.424635] page:00000000b6bef8bc refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xef22 [ 2064.428970] flags: 0xfffffc0000200(slab|node=0|zone=1|lastcpupid=0x1fffff) [ 2064.432515] raw: 000fffffc0000200 ffffea0000d68b80 0000001400000014 ffff888001041780 [ 2064.436110] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 [ 2064.439813] page dumped because: kasan: bad access detected [ 2064.442548] [ 2064.443310] Memory state around the buggy address: [ 2064.445988] ffff88800ef22680: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 2064.449444] ffff88800ef22700: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 2064.452941] >ffff88800ef22780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc [ 2064.456383] ^ [ 2064.459386] ffff88800ef22800: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2064.462788] ffff88800ef22880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 2064.466239] ================================================================== reproducer in python: import argparse import struct import fcntl import os parser = argparse.ArgumentParser() parser.add_argument('-f', '--file', help='file to use fcntl, must be on dlm lock filesystem e.g. gfs2') args = parser.parse_args() f = open(args.file, 'wb+') lockdata = struct.pack('hhllhh', fcntl.F_WRLCK,0,0,0,0,0) fcntl.fcntl(f, fcntl.F_SETLK, lockdata) lockdata = struct.pack('hhllhh', fcntl.F_UNLCK,0,0,0,0,0) fcntl.fcntl(f, fcntl.F_SETLK, lockdata) Fixes: 586759f03e2e ("gfs2: nfs lock support for gfs2") Cc: stable@vger.kernel.org Signed-off-by: Andreas Gruenbacher Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit 93bbf0498ba20eadcd7132bd3cfdaff54eb72751 Author: Jan Kara Date: Wed May 18 11:33:28 2022 +0200 ext4: verify dir block before splitting it commit 46c116b920ebec58031f0a78c5ea9599b0d2a371 upstream. Before splitting a directory block verify its directory entries are sane so that the splitting code does not access memory it should not. Cc: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20220518093332.13986-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 19918ec7717d87d5ab825884a46b26b21375d7ce Author: Ye Bin Date: Mon May 16 20:26:34 2022 +0800 ext4: fix bug_on in ext4_writepages commit ef09ed5d37b84d18562b30cf7253e57062d0db05 upstream. we got issue as follows: EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls ------------[ cut here ]------------ kernel BUG at fs/ext4/inode.c:2708! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000 RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002 RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000 R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001 R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028 FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x83/0xa0 filemap_flush+0xab/0xe0 ext4_alloc_da_blocks+0x51/0x120 __ext4_ioctl+0x1534/0x3210 __x64_sys_ioctl+0x12c/0x170 do_syscall_64+0x3b/0x90 It may happen as follows: 1. write inline_data inode vfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin -> If inline data size too small will allocate block to write, then mapping will has dirty page ext4_da_convert_inline_data_to_extent ->clear EXT4_STATE_MAY_INLINE_DATA 2. fallocate do_vfs_ioctl ioctl_preallocate vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_map_blocks -> fail will goto restore data ext4_restore_inline_data ext4_create_inline_data ext4_write_inline_data ext4_set_inode_state -> set inode EXT4_STATE_MAY_INLINE_DATA 3. writepages __ext4_ioctl ext4_alloc_da_blocks filemap_flush filemap_fdatawrite_wbc do_writepages ext4_writepages if (ext4_has_inline_data(inode)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) The root cause of this issue is we destory inline data until call ext4_writepages under delay allocation mode. But there maybe already convert from inline to extent. To solve this issue, we call filemap_flush first.. Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220516122634.1690462-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 1a3a15bf6f9963d755270cbdb282863b84839195 Author: Ye Bin Date: Thu Apr 14 10:52:23 2022 +0800 ext4: fix use-after-free in ext4_rename_dir_prepare commit 0be698ecbe4471fcad80e81ec6a05001421041b3 upstream. We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 The buggy address belongs to the page: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'. To solve this issue, check directory entry in 'ext4_get_first_dir_block'. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ] Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220414025223.4113128-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit e52a9cc836ba6868bcc491dc600c80d02d05c559 Author: Zhihao Cheng Date: Tue May 10 21:38:05 2022 +0800 fs-writeback: writeback_sb_inodes:Recalculate 'wrote' according skipped pages commit 68f4c6eba70df70a720188bce95c85570ddfcc87 upstream. Commit 505a666ee3fc ("writeback: plug writeback in wb_writeback() and writeback_inodes_wb()") has us holding a plug during wb_writeback, which may cause a potential ABBA dead lock: wb_writeback fat_file_fsync blk_start_plug(&plug) for (;;) { iter i-1: some reqs have been added into plug->mq_list // LOCK A iter i: progress = __writeback_inodes_wb(wb, work) . writeback_sb_inodes // fat's bdev . __writeback_single_inode . . generic_writepages . . __block_write_full_page . . . . __generic_file_fsync . . . . sync_inode_metadata . . . . writeback_single_inode . . . . __writeback_single_inode . . . . fat_write_inode . . . . __fat_write_inode . . . . sync_dirty_buffer // fat's bdev . . . . lock_buffer(bh) // LOCK B . . . . submit_bh . . . . blk_mq_get_tag // LOCK A . . . trylock_buffer(bh) // LOCK B . . . redirty_page_for_writepage . . . wbc->pages_skipped++ . . --wbc->nr_to_write . wrote += write_chunk - wbc.nr_to_write // wrote > 0 . requeue_inode . redirty_tail_locked if (progress) // progress > 0 continue; iter i+1: queue_io // similar process with iter i, infinite for-loop ! } blk_finish_plug(&plug) // flush plug won't be called Above process triggers a hungtask like: [ 399.044861] INFO: task bb:2607 blocked for more than 30 seconds. [ 399.046824] Not tainted 5.18.0-rc1-00005-gefae4d9eb6a2-dirty [ 399.051539] task:bb state:D stack: 0 pid: 2607 ppid: 2426 flags:0x00004000 [ 399.051556] Call Trace: [ 399.051570] __schedule+0x480/0x1050 [ 399.051592] schedule+0x92/0x1a0 [ 399.051602] io_schedule+0x22/0x50 [ 399.051613] blk_mq_get_tag+0x1d3/0x3c0 [ 399.051640] __blk_mq_alloc_requests+0x21d/0x3f0 [ 399.051657] blk_mq_submit_bio+0x68d/0xca0 [ 399.051674] __submit_bio+0x1b5/0x2d0 [ 399.051708] submit_bio_noacct+0x34e/0x720 [ 399.051718] submit_bio+0x3b/0x150 [ 399.051725] submit_bh_wbc+0x161/0x230 [ 399.051734] __sync_dirty_buffer+0xd1/0x420 [ 399.051744] sync_dirty_buffer+0x17/0x20 [ 399.051750] __fat_write_inode+0x289/0x310 [ 399.051766] fat_write_inode+0x2a/0xa0 [ 399.051783] __writeback_single_inode+0x53c/0x6f0 [ 399.051795] writeback_single_inode+0x145/0x200 [ 399.051803] sync_inode_metadata+0x45/0x70 [ 399.051856] __generic_file_fsync+0xa3/0x150 [ 399.051880] fat_file_fsync+0x1d/0x80 [ 399.051895] vfs_fsync_range+0x40/0xb0 [ 399.051929] __x64_sys_fsync+0x18/0x30 In my test, 'need_resched()' (which is imported by 590dca3a71 "fs-writeback: unplug before cond_resched in writeback_sb_inodes") in function 'writeback_sb_inodes()' seldom comes true, unless cond_resched() is deleted from write_cache_pages(). Fix it by correcting wrote number according number of skipped pages in writeback_sb_inodes(). Goto Link to find a reproducer. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215837 Cc: stable@vger.kernel.org # v4.3 Signed-off-by: Zhihao Cheng Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220510133805.1988292-1-chengzhihao1@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ad22b63583ffbca6351f8c30465e777c81d2fee3 Author: Emmanuel Grumbach Date: Tue May 17 12:05:09 2022 +0300 iwlwifi: mvm: fix assert 1F04 upon reconfig commit 9d096e3d3061dbf4ee10e2b59fc2c06e05bdb997 upstream. When we reconfig we must not send the MAC_POWER command that relates to a MAC that was not yet added to the firmware. Ignore those in the iterator. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach Signed-off-by: Gregory Greenman Link: https://lore.kernel.org/r/20220517120044.ed2ffc8ce732.If786e19512d0da4334a6382ea6148703422c7d7b@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 88cc8f963febe192d6ded9df7217f92f380b449a Author: Johannes Berg Date: Wed Jun 1 09:19:36 2022 +0200 wifi: mac80211: fix use-after-free in chanctx code commit 2965c4cdf7ad9ce0796fac5e57debb9519ea721e upstream. In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx. Cc: stable@vger.kernel.org Fixes: 5bcae31d9cb1 ("mac80211: implement multi-vif in-place reservations") Signed-off-by: Johannes Berg Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220601091926.df419d91b165.I17a9b3894ff0b8323ce2afdb153b101124c821e5@changeid Signed-off-by: Greg Kroah-Hartman commit b7d7b1656c7d5034e792ae2597de3858afb97d4b Author: Joerg Roedel Date: Fri May 20 12:22:14 2022 +0200 iommu/amd: Increase timeout waiting for GA log enablement [ Upstream commit 42bb5aa043382f09bef2cc33b8431be867c70f8e ] On some systems it can take a long time for the hardware to enable the GA log of the AMD IOMMU. The current wait time is only 0.1ms, but testing showed that it can take up to 14ms for the GA log to enter running state after it has been enabled. Sometimes the long delay happens when booting the system, sometimes only on resume. Adjust the timeout accordingly to not print a warning when hardware takes a longer than usual. There has already been an attempt to fix this with commit 9b45a7738eec ("iommu/amd: Fix loop timeout issue in iommu_ga_log_enable()") But that commit was based on some wrong math and did not fix the issue in all cases. Cc: "D. Ziegfeld" Cc: Jörg-Volker Peetz Fixes: 8bda0cfbdc1a ("iommu/amd: Detect and initialize guest vAPIC log") Signed-off-by: Joerg Roedel Link: https://lore.kernel.org/r/20220520102214.12563-1-joro@8bytes.org Signed-off-by: Sasha Levin commit 6c92711db7c90f78e0b67ac2a8944d0fe7e12d83 Author: Miaoqian Lin Date: Thu May 12 15:59:08 2022 +0400 video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup [ Upstream commit b23789a59fa6f00e98a319291819f91fbba0deb8 ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: d10715be03bd ("video: ARM CLCD: Add DT support") Signed-off-by: Miaoqian Lin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 2f51db16cb740ff90086189a1ef2581eab665591 Author: Miaoqian Lin Date: Mon May 16 14:55:55 2022 -0700 Input: sparcspkr - fix refcount leak in bbc_beep_probe [ Upstream commit c8994b30d71d64d5dcc9bc0edbfdf367171aa96f ] of_find_node_by_path() calls of_find_node_opts_by_path(), which returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 9c1a5077fdca ("input: Rewrite sparcspkr device probing.") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220516081018.42728-1-linmq006@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 4af21b12a60ed2d3642284f4f85b42d7dc6ac246 Author: Qi Zheng Date: Thu May 12 20:38:37 2022 -0700 tty: fix deadlock caused by calling printk() under tty_port->lock [ Upstream commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3 ] pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner); vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023 vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 fail_dump lib/fault-inject.c:45 [inline] should_fail+0x67b/0x7c0 lib/fault-inject.c:144 __should_failslab+0x152/0x1c0 mm/failslab.c:33 should_failslab+0x5/0x10 mm/slab_common.c:1224 slab_pre_alloc_hook mm/slab.h:468 [inline] slab_alloc_node mm/slub.c:2723 [inline] slab_alloc mm/slub.c:2807 [inline] __kmalloc+0x72/0x300 mm/slub.c:3871 kmalloc include/linux/slab.h:582 [inline] tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175 __tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273 tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318 tty_insert_flip_string include/linux/tty_flip.h:37 [inline] pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock); n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356 do_tty_write drivers/tty/tty_io.c:961 [inline] tty_write+0x512/0x930 drivers/tty/tty_io.c:1045 __vfs_write+0x76/0x100 fs/read_write.c:494 [...] other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &port->lock Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com Fixes: b6da31b2c07c ("tty: Fix data race in tty_insert_flip_string_fixed_flag") Signed-off-by: Qi Zheng Acked-by: Jiri Slaby Acked-by: Greg Kroah-Hartman Cc: Akinobu Mita Cc: Vlastimil Babka Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8224b8f30eddaa64f61fb9c16a61c8bf0aae0e53 Author: Randy Dunlap Date: Mon May 2 12:29:41 2022 -0700 powerpc/4xx/cpm: Fix return value of __setup() handler [ Upstream commit 5bb99fd4090fe1acfdb90a97993fcda7f8f5a3d6 ] __setup() handlers should return 1 to obsolete_checksetup() in init/main.c to indicate that the boot option has been handled. A return of 0 causes the boot option/value to be listed as an Unknown kernel parameter and added to init's (limited) argument or environment strings. Also, error return codes don't mean anything to obsolete_checksetup() -- only non-zero (usually 1) or zero. So return 1 from cpm_powersave_off(). Fixes: d164f6d4f910 ("powerpc/4xx: Add suspend and idle support") Reported-by: Igor Zhbanov Signed-off-by: Randy Dunlap Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220502192941.20955-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 847e0f9f2dd735726800100f521d2f69f8446c02 Author: Randy Dunlap Date: Mon May 2 12:29:25 2022 -0700 powerpc/idle: Fix return value of __setup() handler [ Upstream commit b793a01000122d2bd133ba451a76cc135b5e162c ] __setup() handlers should return 1 to obsolete_checksetup() in init/main.c to indicate that the boot option has been handled. A return of 0 causes the boot option/value to be listed as an Unknown kernel parameter and added to init's (limited) argument or environment strings. Also, error return codes don't mean anything to obsolete_checksetup() -- only non-zero (usually 1) or zero. So return 1 from powersave_off(). Fixes: 302eca184fb8 ("[POWERPC] cell: use ppc_md->power_save instead of cbe_idle_loop") Reported-by: Igor Zhbanov Signed-off-by: Randy Dunlap Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220502192925.19954-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 2c7f4549265e4a0722516219f6ada2fbd7a88913 Author: Randy Dunlap Date: Thu Jan 21 17:08:19 2021 -0800 powerpc/8xx: export 'cpm_setbrg' for modules [ Upstream commit 22f8e625ebabd7ed3185b82b44b4f12fc0402113 ] Fix missing export for a loadable module build: ERROR: modpost: "cpm_setbrg" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined! Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc") Signed-off-by: Randy Dunlap Reported-by: kernel test robot [chleroy: Changed Fixes: tag] Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210122010819.30986-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 39642b0feddb9c39faa6de469a94bfeb4dc0d3a9 Author: Miaohe Lin Date: Thu Apr 28 23:16:06 2022 -0700 drivers/base/node.c: fix compaction sysfs file leak [ Upstream commit da63dc84befaa9e6079a0bc363ff0eaa975f9073 ] Compaction sysfs file is created via compaction_register_node in register_node. But we forgot to remove it in unregister_node. Thus compaction sysfs file is leaked. Using compaction_unregister_node to fix this issue. Link: https://lkml.kernel.org/r/20220401070905.43679-1-linmiaohe@huawei.com Fixes: ed4a6d7f0676 ("mm: compaction: add /sys trigger for per-node memory compaction") Signed-off-by: Miaohe Lin Cc: Greg Kroah-Hartman Cc: Rafael J. Wysocki Cc: Mel Gorman Cc: Minchan Kim Cc: KAMEZAWA Hiroyuki Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 58185fcadb072b398e676a940ba24e512268c058 Author: Gustavo A. R. Silva Date: Thu Mar 3 17:55:21 2022 -0600 scsi: fcoe: Fix Wstringop-overflow warnings in fcoe_wwn_from_mac() [ Upstream commit 54db804d5d7d36709d1ce70bde3b9a6c61b290b6 ] Fix the following Wstringop-overflow warnings when building with GCC-11: drivers/scsi/fcoe/fcoe.c: In function ‘fcoe_netdev_config’: drivers/scsi/fcoe/fcoe.c:744:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 744 | wwnn = fcoe_wwn_from_mac(ctlr->ctl_src_addr, 1, 0); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/fcoe/fcoe.c:744:32: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/fcoe/fcoe.c:36: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ drivers/scsi/fcoe/fcoe.c:747:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 747 | wwpn = fcoe_wwn_from_mac(ctlr->ctl_src_addr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 748 | 2, 0); | ~~~~~ drivers/scsi/fcoe/fcoe.c:747:32: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/fcoe/fcoe.c:36: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ CC drivers/scsi/bnx2fc/bnx2fc_io.o In function ‘bnx2fc_net_config’, inlined from ‘bnx2fc_if_create’ at drivers/scsi/bnx2fc/bnx2fc_fcoe.c:1543:7: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:833:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 833 | wwnn = fcoe_wwn_from_mac(ctlr->ctl_src_addr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 834 | 1, 0); | ~~~~~ drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function ‘bnx2fc_if_create’: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:833:32: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/bnx2fc/bnx2fc.h:53, from drivers/scsi/bnx2fc/bnx2fc_fcoe.c:17: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ In function ‘bnx2fc_net_config’, inlined from ‘bnx2fc_if_create’ at drivers/scsi/bnx2fc/bnx2fc_fcoe.c:1543:7: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:839:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 839 | wwpn = fcoe_wwn_from_mac(ctlr->ctl_src_addr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 840 | 2, 0); | ~~~~~ drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function ‘bnx2fc_if_create’: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:839:32: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/bnx2fc/bnx2fc.h:53, from drivers/scsi/bnx2fc/bnx2fc_fcoe.c:17: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ drivers/scsi/qedf/qedf_main.c: In function ‘__qedf_probe’: drivers/scsi/qedf/qedf_main.c:3520:30: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 3520 | qedf->wwnn = fcoe_wwn_from_mac(qedf->mac, 1, 0); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/qedf/qedf_main.c:3520:30: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/qedf/qedf.h:9, from drivers/scsi/qedf/qedf_main.c:23: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ drivers/scsi/qedf/qedf_main.c:3521:30: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 3521 | qedf->wwpn = fcoe_wwn_from_mac(qedf->mac, 2, 0); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/qedf/qedf_main.c:3521:30: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/qedf/qedf.h:9, from drivers/scsi/qedf/qedf_main.c:23: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ by changing the array size to the correct value of ETH_ALEN in the argument declaration. Also, fix a couple of checkpatch warnings: WARNING: function definition argument 'unsigned int' should also have an identifier name This helps with the ongoing efforts to globally enable -Wstringop-overflow. Link: https://github.com/KSPP/linux/issues/181 Fixes: 85b4aa4926a5 ("[SCSI] fcoe: Fibre Channel over Ethernet") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Sasha Levin commit 1b30ae7c79525bcdd529ccdd291d25810d6f8b60 Author: Lv Ruyi Date: Tue Apr 12 08:53:05 2022 +0000 mfd: ipaq-micro: Fix error check return value of platform_get_irq() [ Upstream commit 3b49ae380ce1a3054e0c505dd9a356b82a5b48e8 ] platform_get_irq() return negative value on failure, so null check of irq is incorrect. Fix it by comparing whether it is less than zero. Fixes: dcc21cc09e3c ("mfd: Add driver for Atmel Microcontroller on iPaq h3xxx") Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Reviewed-by: Linus Walleij Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220412085305.2533030-1-lv.ruyi@zte.com.cn Signed-off-by: Sasha Levin commit 8acfbe523381f7dac1af8c5391fbbe4fd02e80fc Author: Miaoqian Lin Date: Tue Mar 8 07:36:48 2022 +0000 soc: qcom: smsm: Fix missing of_node_put() in smsm_parse_ipc [ Upstream commit aad66a3c78da668f4506356c2fdb70b7a19ecc76 ] The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. Fixes: c97c4090ff72 ("soc: qcom: smsm: Add driver for Qualcomm SMSM") Signed-off-by: Miaoqian Lin Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220308073648.24634-1-linmq006@gmail.com Signed-off-by: Sasha Levin commit d9999fc918b828df2f414dfff8f79ac985d2cbb4 Author: Miaoqian Lin Date: Tue Mar 8 07:19:42 2022 +0000 soc: qcom: smp2p: Fix missing of_node_put() in smp2p_parse_ipc [ Upstream commit 8fd3f18ea31a398ecce4a6d3804433658678b0a3 ] The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. Fixes: 50e99641413e ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point") Signed-off-by: Miaoqian Lin Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220308071942.22942-1-linmq006@gmail.com Signed-off-by: Sasha Levin commit 46585a76949c61be303cd5b2d399e4f5c8186c8a Author: David Howells Date: Sat May 21 09:03:11 2022 +0100 rxrpc: Don't try to resend the request if we're receiving the reply [ Upstream commit 114af61f88fbe34d641b13922d098ffec4c1be1b ] rxrpc has a timer to trigger resending of unacked data packets in a call. This is not cancelled when a client call switches to the receive phase on the basis that most calls don't last long enough for it to ever expire. However, if it *does* expire after we've started to receive the reply, we shouldn't then go into trying to retransmit or pinging the server to find out if an ack got lost. Fix this by skipping the resend code if we're into receiving the reply to a client call. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: David Howells cc: linux-afs@lists.infradead.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 61fb38cfbb1d54d3dafd0c25752f684b3cd00b32 Author: David Howells Date: Sat May 21 09:03:04 2022 +0100 rxrpc: Fix listen() setting the bar too high for the prealloc rings [ Upstream commit 88e22159750b0d55793302eeed8ee603f5c1a95c ] AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump up the sysctl), but whilst the preallocation circular buffers have 32 slots in them, one of them has to be a dead slot because we're using CIRC_CNT(). This means that listen(rxrpc_sock, 32) will cause an oops when the socket is closed because rxrpc_service_prealloc_one() allocated one too many calls and rxrpc_discard_prealloc() won't then be able to get rid of them because it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries to abort them, but oopses because call->peer isn't yet set. Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match the ring capacity. BUG: kernel NULL pointer dereference, address: 0000000000000086 ... RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc] Call Trace: ? __wake_up_common_lock+0x7a/0x90 ? rxrpc_notify_socket+0x8e/0x140 [rxrpc] ? rxrpc_abort_call+0x4c/0x60 [rxrpc] rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc] rxrpc_release+0xc9/0x1c0 [rxrpc] __sock_release+0x37/0xa0 sock_close+0x11/0x20 __fput+0x89/0x240 task_work_run+0x59/0x90 do_exit+0x319/0xaa0 Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incoming service requests") Reported-by: Marc Dionne Signed-off-by: David Howells cc: linux-afs@lists.infradead.org Link: https://lists.infradead.org/pipermail/linux-afs/2022-March/005079.html Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c1e11b2c1c8bf403d7c92de212b92229c0d656b9 Author: Yang Yingliang Date: Sat May 14 17:10:53 2022 +0800 ASoC: wm2000: fix missing clk_disable_unprepare() on error in wm2000_anc_transition() [ Upstream commit be2af740e2a9c7134f2d8ab4f104006e110b13de ] Fix the missing clk_disable_unprepare() before return from wm2000_anc_transition() in the error handling case. Fixes: 514cfd6dd725 ("ASoC: wm2000: Integrate with clock API") Signed-off-by: Yang Yingliang Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20220514091053.686416-1-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b342a88bbcddcbfc83e50d712f332f2da1e4e89e Author: Eric Dumazet Date: Fri May 13 11:55:42 2022 -0700 sctp: read sk->sk_bound_dev_if once in sctp_rcv() [ Upstream commit a20ea298071f46effa3aaf965bf9bb34c901db3f ] sctp_rcv() reads sk->sk_bound_dev_if twice while the socket is not locked. Another cpu could change this field under us. Fixes: 0fd9a65a76e8 ("[SCTP] Support SO_BINDTODEVICE socket option on incoming packets.") Signed-off-by: Eric Dumazet Cc: Neil Horman Cc: Vlad Yasevich Cc: Marcelo Ricardo Leitner Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 34478387514bd85eb77d23f02a3a0dbd31c4ccf6 Author: Geert Uytterhoeven Date: Fri May 13 14:50:28 2022 +0200 m68k: math-emu: Fix dependencies of math emulation support [ Upstream commit ed6bc6bf0a7d75e80eb1df883c09975ebb74e590 ] If CONFIG_M54xx=y, CONFIG_MMU=y, and CONFIG_M68KFPU_EMU=y: {standard input}:272: Error: invalid instruction for this architecture; needs 68000 or higher (68000 [68ec000, 68hc000, 68hc001, 68008, 68302, 68306, 68307, 68322, 68356], 68010, 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360], fidoa [fido]) -- statement `sub.b %d1,%d3' ignored {standard input}:609: Error: invalid instruction for this architecture; needs 68020 or higher (68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060]) -- statement `bfextu 4(%a1){%d0,#8},%d0' ignored {standard input}:752: Error: operands mismatch -- statement `mulu.l 4(%a0),%d3:%d0' ignored {standard input}:1155: Error: operands mismatch -- statement `divu.l %d0,%d3:%d7' ignored The math emulation support code is intended for 68020 and higher, and uses several instructions or instruction modes not available on coldfire or 68000. Originally, the dependency of M68KFPU_EMU on MMU was fine, as MMU support was only available on 68020 or higher. But this assumption was broken by the introduction of MMU support for M547x and M548x. Drop the dependency on MMU, as the code should work fine on 68020 and up without MMU (which are not yet supported by Linux, though). Add dependencies on M68KCLASSIC (to rule out Coldfire) and FPU (kernel has some type of floating-point support --- be it hardware or software emulated, to rule out anything below 68020). Fixes: 1f7034b9616e6f14 ("m68k: allow ColdFire 547x and 548x CPUs to be built with MMU enabled") Reported-by: kernel test robot Signed-off-by: Geert Uytterhoeven Reviewed-by: Greg Ungerer Link: https://lore.kernel.org/r/18c34695b7c95107f60ccca82a4ff252f3edf477.1652446117.git.geert@linux-m68k.org Signed-off-by: Sasha Levin commit 9de3dc09e56f8deacd2bdbf4cecb71e11a312405 Author: Ying Hsu Date: Sat Mar 26 07:09:28 2022 +0000 Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout [ Upstream commit 7aa1e7d15f8a5b65f67bacb100d8fc033b21efa2 ] Connecting the same socket twice consecutively in sco_sock_connect() could lead to a race condition where two sco_conn objects are created but only one is associated with the socket. If the socket is closed before the SCO connection is established, the timer associated with the dangling sco_conn object won't be canceled. As the sock object is being freed, the use-after-free problem happens when the timer callback function sco_sock_timeout() accesses the socket. Here's the call trace: dump_stack+0x107/0x163 ? refcount_inc+0x1c/ print_address_description.constprop.0+0x1c/0x47e ? refcount_inc+0x1c/0x7b kasan_report+0x13a/0x173 ? refcount_inc+0x1c/0x7b check_memory_region+0x132/0x139 refcount_inc+0x1c/0x7b sco_sock_timeout+0xb2/0x1ba process_one_work+0x739/0xbd1 ? cancel_delayed_work+0x13f/0x13f ? __raw_spin_lock_init+0xf0/0xf0 ? to_kthread+0x59/0x85 worker_thread+0x593/0x70e kthread+0x346/0x35a ? drain_workqueue+0x31a/0x31a ? kthread_bind+0x4b/0x4b ret_from_fork+0x1f/0x30 Link: https://syzkaller.appspot.com/bug?extid=2bef95d3ab4daa10155b Reported-by: syzbot+2bef95d3ab4daa10155b@syzkaller.appspotmail.com Fixes: e1dee2c1de2b ("Bluetooth: fix repeated calls to sco_sock_kill") Signed-off-by: Ying Hsu Reviewed-by: Joseph Hwang Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 4351bfe36aba9fa7dc9d68d498d25d41a0f45e67 Author: Pavel Skripkin Date: Fri Apr 15 23:24:48 2022 +0200 media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init [ Upstream commit 471bec68457aaf981add77b4f590d65dd7da1059 ] Syzbot reported that -1 is used as array index. The problem was in missing validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work. Reported-and-tested-by: syzbot+1a247e36149ffd709a9b@syzkaller.appspotmail.com Fixes: d855497edbfb ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18") Signed-off-by: Pavel Skripkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 483c126612d02c59cef606d024f2b1225ff31cc8 Author: Miaoqian Lin Date: Fri Mar 18 12:01:01 2022 +0100 media: exynos4-is: Change clk_disable to clk_disable_unprepare [ Upstream commit 9fadab72a6916c7507d7fedcd644859eef995078 ] The corresponding API for clk_prepare_enable is clk_disable_unprepare, other than clk_disable. Fix this by changing clk_disable to clk_disable_unprepare. Fixes: b4155d7d5b2c ("[media] exynos4-is: Ensure fimc-is clocks are not enabled until properly configured") Signed-off-by: Miaoqian Lin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b74c0dd9179d21b7260260e075d597b23970100c Author: Miaoqian Lin Date: Wed May 11 15:35:05 2022 +0400 regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt [ Upstream commit afaa7b933ef00a2d3262f4d1252087613fb5c06d ] of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore. Fixes: 3784b6d64dc5 ("regulator: pfuze100: add pfuze100 regulator driver") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220511113506.45185-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c933829cbf3338b684869e6c4c8931abf5d68fbd Author: Miaoqian Lin Date: Wed May 11 17:37:22 2022 +0400 ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe [ Upstream commit 2be84f73785fa9ed6443e3c5b158730266f1c2ee ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Fixes: 08641c7c74dd ("ASoC: mxs: add device tree support for mxs-saif") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220511133725.39039-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b06ee88cfa41a78dd22e5d9d14d3190e1670f209 Author: Xiaomeng Tong Date: Sat Mar 19 11:22:22 2022 +0100 media: uvcvideo: Fix missing check to determine if element is found in list [ Upstream commit 261f33388c29f6f3c12a724e6d89172b7f6d5996 ] The list iterator will point to a bogus position containing HEAD if the list is empty or the element is not found in list. This case should be checked before any use of the iterator, otherwise it will lead to a invalid memory access. The missing check here is before "pin = iterm->id;", just add check here to fix the security bug. In addition, the list iterator value will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the element is not found in list, considering the (mis)use here: "if (iterm == NULL". Use a new value 'it' as the list iterator, while use the old value 'iterm' as a dedicated pointer to point to the found element, which 1. can fix this bug, due to 'iterm' is NULL only if it's not found. 2. do not need to change all the uses of 'iterm' after the loop. 3. can also limit the scope of the list iterator 'it' *only inside* the traversal loop by simply declaring 'it' inside the loop in the future, as usage of the iterator outside of the list_for_each_entry is considered harmful. https://lkml.org/lkml/2022/2/17/1032 Fixes: d5e90b7a6cd1c ("[media] uvcvideo: Move to video_ioctl2") Signed-off-by: Xiaomeng Tong Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e9561fccb62e3f0d84663a5d53d587541280f257 Author: Dan Carpenter Date: Thu May 5 13:28:05 2022 +0300 drm/msm: return an error pointer in msm_gem_prime_get_sg_table() [ Upstream commit cf575e31611eb6dccf08fad02e57e35b2187704d ] The msm_gem_prime_get_sg_table() needs to return error pointers on error. This is called from drm_gem_map_dma_buf() and returning a NULL will lead to a crash in that function. Fixes: ac45146733b0 ("drm/msm: fix msm_gem_prime_get_sg_table()") Signed-off-by: Dan Carpenter Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/485023/ Link: https://lore.kernel.org/r/YnOmtS5tfENywR9m@kili Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0110d41971f8a8c6bea5d39cd92437a8e68be16f Author: Randy Dunlap Date: Mon Mar 14 17:10:45 2022 -0700 x86/mm: Cleanup the control_va_addr_alignment() __setup handler [ Upstream commit 1ef64b1e89e6d4018da46e08ffc32779a31160c7 ] Clean up control_va_addr_alignment(): a. Make '=' required instead of optional (as documented). b. Print a warning if an invalid option value is used. c. Return 1 from the __setup handler when an invalid option value is used. This prevents the kernel from polluting init's (limited) environment space with the entire string. Fixes: dfb09f9b7ab0 ("x86, amd: Avoid cache aliasing penalties on AMD family 15h") Reported-by: Igor Zhbanov Signed-off-by: Randy Dunlap Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru Link: https://lore.kernel.org/r/20220315001045.7680-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 452922955df215a417c80d09dab72bbc667a1861 Author: Yang Yingliang Date: Fri Apr 22 11:28:54 2022 +0800 drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() [ Upstream commit f8c242908ad15bbd604d3bcb54961b7d454c43f8 ] It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. Fixes: 2048e3286f34 ("drm: rockchip: Add basic drm driver") Signed-off-by: Yang Yingliang Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422032854.2995175-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit 9cb1ee33efccb8b107ee04b7b3441820de3fd2da Author: Yang Yingliang Date: Fri Apr 22 11:22:27 2022 +0800 drm/msm/hdmi: check return value after calling platform_get_resource_byname() [ Upstream commit a36e506711548df923ceb7ec9f6001375be799a5 ] It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Fixes: c6a57a50ad56 ("drm/msm/hdmi: add hdmi hdcp support (V3)") Signed-off-by: Yang Yingliang Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/482992/ Link: https://lore.kernel.org/r/20220422032227.2991553-1-yangyingliang@huawei.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 6ebf77be4ce66570d1670623d64c9465e7384a6d Author: Dmitry Baryshkov Date: Sat Apr 2 02:11:04 2022 +0300 drm/msm/dsi: fix error checks and return values for DSI xmit functions [ Upstream commit f0e7e9ed379c012c4d6b09a09b868accc426223c ] As noticed by Dan ([1] an the followup thread) there are multiple issues with the return values for MSM DSI command transmission callback. In the error case it can easily return a positive value when it should have returned a proper error code. This commits attempts to fix these issues both in TX and in RX paths. [1]: https://lore.kernel.org/linux-arm-msm/20211001123617.GH2283@kili/ Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support") Reported-by: Dan Carpenter Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Tested-by: Marijn Suijten Patchwork: https://patchwork.freedesktop.org/patch/480501/ Link: https://lore.kernel.org/r/20220401231104.967193-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit f0e5dce9e2decf8962942d031a29c50b471bb38e Author: Matthieu Baerts Date: Sat Apr 23 20:24:10 2022 +0200 x86/pm: Fix false positive kmemleak report in msr_build_context() [ Upstream commit b0b592cf08367719e1d1ef07c9f136e8c17f7ec3 ] Since e2a1256b17b1 ("x86/speculation: Restore speculation related MSRs during S3 resume") kmemleak reports this issue: unreferenced object 0xffff888009cedc00 (size 256): comm "swapper/0", pid 1, jiffies 4294693823 (age 73.764s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 48 00 00 00 00 00 00 00 ........H....... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: msr_build_context (include/linux/slab.h:621) pm_check_save_msr (arch/x86/power/cpu.c:520) do_one_initcall (init/main.c:1298) kernel_init_freeable (init/main.c:1370) kernel_init (init/main.c:1504) ret_from_fork (arch/x86/entry/entry_64.S:304) Reproducer: - boot the VM with a debug kernel config (see https://github.com/multipath-tcp/mptcp_net-next/issues/268) - wait ~1 minute - start a kmemleak scan The root cause here is alignment within the packed struct saved_context (from suspend_64.h). Kmemleak only searches for pointers that are aligned (see how pointers are scanned in kmemleak.c), but pahole shows that the saved_msrs struct member and all members after it in the structure are unaligned: struct saved_context { struct pt_regs regs; /* 0 168 */ /* --- cacheline 2 boundary (128 bytes) was 40 bytes ago --- */ u16 ds; /* 168 2 */ ... u64 misc_enable; /* 232 8 */ bool misc_enable_saved; /* 240 1 */ /* Note below odd offset values for the remainder of this struct */ struct saved_msrs saved_msrs; /* 241 16 */ /* --- cacheline 4 boundary (256 bytes) was 1 bytes ago --- */ long unsigned int efer; /* 257 8 */ u16 gdt_pad; /* 265 2 */ struct desc_ptr gdt_desc; /* 267 10 */ u16 idt_pad; /* 277 2 */ struct desc_ptr idt; /* 279 10 */ u16 ldt; /* 289 2 */ u16 tss; /* 291 2 */ long unsigned int tr; /* 293 8 */ long unsigned int safety; /* 301 8 */ long unsigned int return_address; /* 309 8 */ /* size: 317, cachelines: 5, members: 25 */ /* last cacheline: 61 bytes */ } __attribute__((__packed__)); Move misc_enable_saved to the end of the struct declaration so that saved_msrs fits in before the cacheline 4 boundary. The comment above the saved_context declaration says to fix wakeup_64.S file and __save/__restore_processor_state() if the struct is modified: it looks like all the accesses in wakeup_64.S are done through offsets which are computed at build-time. Update that comment accordingly. At the end, the false positive kmemleak report is due to a limitation from kmemleak but it is always good to avoid unaligned members for optimisation purposes. Please note that it looks like this issue is not new, e.g. https://lore.kernel.org/all/9f1bb619-c4ee-21c4-a251-870bd4db04fa@lwfinger.net/ https://lore.kernel.org/all/94e48fcd-1dbd-ebd2-4c91-f39941735909@molgen.mpg.de/ [ bp: Massage + cleanup commit message. ] Fixes: 7a9c2dd08ead ("x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume") Suggested-by: Mat Martineau Signed-off-by: Matthieu Baerts Signed-off-by: Borislav Petkov Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20220426202138.498310-1-matthieu.baerts@tessares.net Signed-off-by: Sasha Levin commit 90dc375033506f22cef785d97b508d2d5a947d48 Author: Amir Goldstein Date: Fri Apr 22 15:03:12 2022 +0300 inotify: show inotify mask flags in proc fdinfo [ Upstream commit a32e697cda27679a0327ae2cafdad8c7170f548f ] The inotify mask flags IN_ONESHOT and IN_EXCL_UNLINK are not "internal to kernel" and should be exposed in procfs fdinfo so CRIU can restore them. Fixes: 6933599697c9 ("inotify: hide internal kernel bits from fdinfo") Link: https://lore.kernel.org/r/20220422120327.3459282-2-amir73il@gmail.com Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 0bcb528402cd5e1a6e1833e956fd58a12d509e8e Author: Dan Carpenter Date: Sat Apr 9 09:12:25 2022 +0300 ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix [ Upstream commit 2dc509305cf956381532792cb8dceef2b1504765 ] The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' Fixes: 4ed1a8d4a257 ("ath9k_htc: use ath9k_cmn_rx_accept") Signed-off-by: Dan Carpenter Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220409061225.GA5447@kili Signed-off-by: Sasha Levin commit 48711a93604ad5995fee2cb9e50b39655252bbc1 Author: Zheng Yongjun Date: Fri Apr 22 06:26:41 2022 +0000 spi: img-spfi: Fix pm_runtime_get_sync() error checking [ Upstream commit cc470d55343056d6b2a5c32e10e0aad06f324078 ] If the device is already in a runtime PM enabled state pm_runtime_get_sync() will return 1, so a test for negative value should be used to check for errors. Fixes: deba25800a12b ("spi: Add driver for IMG SPFI controller") Signed-off-by: Zheng Yongjun Link: https://lore.kernel.org/r/20220422062641.10486-1-zhengyongjun3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dce87f324348c4e5883ee2d0363aeb964e4fedfc Author: Jonathan Teh Date: Sun Mar 13 19:48:18 2022 +0000 HID: hid-led: fix maximum brightness for Dream Cheeky [ Upstream commit 116c3f4a78ebe478d5ad5a038baf931e93e7d748 ] Increase maximum brightness for Dream Cheeky to 63. Emperically determined based on testing in kernel 4.4 on this device: Bus 003 Device 002: ID 1d34:0004 Dream Cheeky Webmail Notifier Fixes: 6c7ad07e9e05 ("HID: migrate USB LED driver from usb misc to hid") Signed-off-by: Jonathan Teh Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a8e03bcad52dc9afabf650fdbad84f739cec9efa Author: Lin Ma Date: Tue Apr 12 13:32:08 2022 +0800 NFC: NULL out the dev->rfkill to prevent UAF [ Upstream commit 1b0e81416a24d6e9b8c2341e22e8bf48f8b8bfc9 ] Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device") assumes the device_is_registered() in function nfc_dev_up() will help to check when the rfkill is unregistered. However, this check only take effect when device_del(&dev->dev) is done in nfc_unregister_device(). Hence, the rfkill object is still possible be dereferenced. The crash trace in latest kernel (5.18-rc2): [ 68.760105] ================================================================== [ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750 [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313 [ 68.760756] [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4 [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 68.760756] Call Trace: [ 68.760756] [ 68.760756] dump_stack_lvl+0x57/0x7d [ 68.760756] print_report.cold+0x5e/0x5db [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] kasan_report+0xbe/0x1c0 [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] __lock_acquire+0x3ec1/0x6750 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? register_lock_class+0x18d0/0x18d0 [ 68.760756] lock_acquire+0x1ac/0x4f0 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0 [ 68.760756] ? nla_get_range_signed+0x540/0x540 [ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50 [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] rfkill_blocked+0xe/0x60 [ 68.760756] nfc_dev_up+0x84/0x260 [ 68.760756] nfc_genl_dev_up+0x90/0xe0 [ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0 [ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230 [ 68.760756] ? security_capable+0x51/0x90 [ 68.760756] genl_rcv_msg+0x280/0x500 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? lock_acquire+0x1ac/0x4f0 [ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] netlink_rcv_skb+0x11b/0x340 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? netlink_ack+0x9c0/0x9c0 [ 68.760756] ? netlink_deliver_tap+0x136/0xb00 [ 68.760756] genl_rcv+0x1f/0x30 [ 68.760756] netlink_unicast+0x430/0x710 [ 68.760756] ? memset+0x20/0x40 [ 68.760756] ? netlink_attachskb+0x740/0x740 [ 68.760756] ? __build_skb_around+0x1f4/0x2a0 [ 68.760756] netlink_sendmsg+0x75d/0xc00 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] sock_sendmsg+0xdf/0x110 [ 68.760756] __sys_sendto+0x19e/0x270 [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0 [ 68.760756] ? fd_install+0x178/0x4c0 [ 68.760756] ? fd_install+0x195/0x4c0 [ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0 [ 68.760756] __x64_sys_sendto+0xd8/0x1b0 [ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130 [ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50 [ 68.760756] do_syscall_64+0x3b/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 68.760756] RIP: 0033:0x7f67fb50e6b3 ... [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3 [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003 [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003 [ 68.760756] [ 68.760756] [ 68.760756] Allocated by task 279: [ 68.760756] kasan_save_stack+0x1e/0x40 [ 68.760756] __kasan_kmalloc+0x81/0xa0 [ 68.760756] rfkill_alloc+0x7f/0x280 [ 68.760756] nfc_register_device+0xa3/0x1a0 [ 68.760756] nci_register_device+0x77a/0xad0 [ 68.760756] nfcmrvl_nci_register_dev+0x20b/0x2c0 [ 68.760756] nfcmrvl_nci_uart_open+0xf2/0x1dd [ 68.760756] nci_uart_tty_ioctl+0x2c3/0x4a0 [ 68.760756] tty_ioctl+0x764/0x1310 [ 68.760756] __x64_sys_ioctl+0x122/0x190 [ 68.760756] do_syscall_64+0x3b/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 68.760756] [ 68.760756] Freed by task 314: [ 68.760756] kasan_save_stack+0x1e/0x40 [ 68.760756] kasan_set_track+0x21/0x30 [ 68.760756] kasan_set_free_info+0x20/0x30 [ 68.760756] __kasan_slab_free+0x108/0x170 [ 68.760756] kfree+0xb0/0x330 [ 68.760756] device_release+0x96/0x200 [ 68.760756] kobject_put+0xf9/0x1d0 [ 68.760756] nfc_unregister_device+0x77/0x190 [ 68.760756] nfcmrvl_nci_unregister_dev+0x88/0xd0 [ 68.760756] nci_uart_tty_close+0xdf/0x180 [ 68.760756] tty_ldisc_kill+0x73/0x110 [ 68.760756] tty_ldisc_hangup+0x281/0x5b0 [ 68.760756] __tty_hangup.part.0+0x431/0x890 [ 68.760756] tty_release+0x3a8/0xc80 [ 68.760756] __fput+0x1f0/0x8c0 [ 68.760756] task_work_run+0xc9/0x170 [ 68.760756] exit_to_user_mode_prepare+0x194/0x1a0 [ 68.760756] syscall_exit_to_user_mode+0x19/0x50 [ 68.760756] do_syscall_64+0x48/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae This patch just add the null out of dev->rfkill to make sure such dereference cannot happen. This is safe since the device_lock() already protect the check/write from data race. Fixes: 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device") Signed-off-by: Lin Ma Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 92373244618d0faaa20743c2e0a889122fa77983 Author: Miaoqian Lin Date: Mon Apr 11 11:10:33 2022 +0000 spi: spi-ti-qspi: Fix return value handling of wait_for_completion_timeout [ Upstream commit 8b1ea69a63eb62f97cef63e6d816b64ed84e8760 ] wait_for_completion_timeout() returns unsigned long not int. It returns 0 if timed out, and positive if completed. The check for <= 0 is ambiguous and should be == 0 here indicating timeout which is the only error case. Fixes: 5720ec0a6d26 ("spi: spi-ti-qspi: Add DMA support for QSPI mmap read") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220411111034.24447-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2c19a69ab2ec16f22820f5d2a24c166794bf0fd3 Author: Miles Chen Date: Wed Mar 16 07:23:00 2022 +0800 drm/mediatek: Fix mtk_cec_mask() [ Upstream commit 2c5d69b0a141e1e98febe3111e6f4fd8420493a5 ] In current implementation, mtk_cec_mask() writes val into target register and ignores the mask. After talking to our hdmi experts, mtk_cec_mask() should read a register, clean only mask bits, and update (val | mask) bits to the register. Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220315232301.2434-1-miles.chen@mediatek.com/ Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support") Signed-off-by: Miles Chen Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger Cc: Zhiqiang Lin Cc: CK Hu Cc: Matthias Brugger Cc: AngeloGioacchino Del Regno Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 55bd0545d2792cb512559ba493c29b45f49e20f4 Author: Ammar Faizi Date: Tue Mar 29 17:47:04 2022 +0700 x86/delay: Fix the wrong asm constraint in delay_loop() [ Upstream commit b86eb74098a92afd789da02699b4b0dd3f73b889 ] The asm constraint does not reflect the fact that the asm statement can modify the value of the local variable loops. Which it does. Specifying the wrong constraint may lead to undefined behavior, it may clobber random stuff (e.g. local variable, important temporary value in regs, etc.). This is especially dangerous when the compiler decides to inline the function and since it doesn't know that the value gets modified, it might decide to use it from a register directly without reloading it. Change the constraint to "+a" to denote that the first argument is an input and an output argument. [ bp: Fix typo, massage commit message. ] Fixes: e01b70ef3eb3 ("x86: fix bug in arch/i386/lib/delay.c file, delay_loop function") Signed-off-by: Ammar Faizi Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220329104705.65256-2-ammarfaizi2@gnuweeb.org Signed-off-by: Sasha Levin commit 0a1901f34f775b83ea4b8dbb5ed992147b9b8531 Author: Miaoqian Lin Date: Mon Apr 4 09:29:01 2022 +0000 ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe [ Upstream commit 4f4e0454e226de3bf4efd7e7924d1edc571c52d5 ] Call of_node_put(platform_node) to avoid refcount leak in the error path. Fixes: 94319ba10eca ("ASoC: mediatek: Use platform_of_node for machine drivers") Fixes: 493433785df0 ("ASoC: mediatek: mt8173: fix device_node leak") Signed-off-by: Miaoqian Lin Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220404092903.26725-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4188758b5313d3b1193dbbb9fe3a3a942e27a7c8 Author: Linus Torvalds Date: Sat May 28 11:08:48 2022 -0700 drm: fix EDID struct for old ARM OABI format [ Upstream commit 47f15561b69e226bfc034e94ff6dbec51a4662af ] When building the kernel for arm with the "-mabi=apcs-gnu" option, gcc will force alignment of all structures and unions to a word boundary (see also STRUCTURE_SIZE_BOUNDARY and the "-mstructure-size-boundary=XX" option if you're a gcc person), even when the members of said structures do not want or need said alignment. This completely messes up the structure alignment of 'struct edid' on those targets, because even though all the embedded structures are marked with "__attribute__((packed))", the unions that contain them are not. This was exposed by commit f1e4c916f97f ("drm/edid: add EDID block count and size helpers"), but the bug is pre-existing. That commit just made the structure layout problem cause a build failure due to the addition of the BUILD_BUG_ON(sizeof(*edid) != EDID_LENGTH); sanity check in drivers/gpu/drm/drm_edid.c:edid_block_data(). This legacy union alignment should probably not be used in the first place, but we can fix the layout by adding the packed attribute to the union entries even when each member is already packed and it shouldn't matter in a sane build environment. You can see this issue with a trivial test program: union { struct { char c[5]; }; struct { char d; unsigned e; } __attribute__((packed)); } a = { "1234" }; where building this with a normal "gcc -S" will result in the expected 5-byte size of said union: .type a, @object .size a, 5 but with an ARM compiler and the old ABI: arm-linux-gnu-gcc -mabi=apcs-gnu -mfloat-abi=soft -S t.c you get .type a, %object .size a, 8 instead, because even though each member of the union is packed, the union itself still gets aligned. This was reported by Sudip for the spear3xx_defconfig target. Link: https://lore.kernel.org/lkml/YpCUzStDnSgQLNFN@debian/ Reported-by: Sudip Mukherjee Acked-by: Arnd Bergmann Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9f29a4e6ef8fc0991087cd52c8ea4663e050e25d Author: Finn Thain Date: Thu Apr 7 20:11:32 2022 +1000 macintosh/via-pmu: Fix build failure when CONFIG_INPUT is disabled [ Upstream commit 86ce436e30d86327c9f5260f718104ae7b21f506 ] drivers/macintosh/via-pmu-event.o: In function `via_pmu_event': via-pmu-event.c:(.text+0x44): undefined reference to `input_event' via-pmu-event.c:(.text+0x68): undefined reference to `input_event' via-pmu-event.c:(.text+0x94): undefined reference to `input_event' via-pmu-event.c:(.text+0xb8): undefined reference to `input_event' drivers/macintosh/via-pmu-event.o: In function `via_pmu_event_init': via-pmu-event.c:(.init.text+0x20): undefined reference to `input_allocate_device' via-pmu-event.c:(.init.text+0xc4): undefined reference to `input_register_device' via-pmu-event.c:(.init.text+0xd4): undefined reference to `input_free_device' make[1]: *** [Makefile:1155: vmlinux] Error 1 make: *** [Makefile:350: __build_one_by_one] Error 2 Don't call into the input subsystem unless CONFIG_INPUT is built-in. Reported-by: kernel test robot Signed-off-by: Finn Thain Tested-by: Randy Dunlap Reviewed-by: Christophe Leroy Acked-by: Randy Dunlap Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/5edbe76ce68227f71e09af4614cc4c1bd61c7ec8.1649326292.git.fthain@linux-m68k.org Signed-off-by: Sasha Levin commit 977dbc81d0f866ef63b93c127b7404f07734b3cc Author: Lv Ruyi Date: Sat Apr 2 01:34:19 2022 +0000 powerpc/xics: fix refcount leak in icp_opal_init() [ Upstream commit 5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9 ] The of_find_compatible_node() function returns a node pointer with refcount incremented, use of_node_put() on it when done. Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.ruyi@zte.com.cn Signed-off-by: Sasha Levin commit da9792920ab525b8a932aa9aeee34529ad7b83f7 Author: Yicong Yang Date: Mon Apr 4 14:25:39 2022 +0800 PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() [ Upstream commit a91ee0e9fca9d7501286cfbced9b30a33e52740a ] The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0 Previously, pci_dev_lock() acquired the config space access lock before the device lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4). Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path. [bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com] Link: https://lore.kernel.org/linux-pci/1583489997-17156-1-git-send-email-yangyicong@hisilicon.com/ Also-posted-by: Jay Zhou Signed-off-by: Yicong Yang Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 46cb7868811d025c3d29c10d18b3422db1cf20d5 Author: Peng Wu Date: Thu Apr 28 10:43:06 2022 +0000 ARM: hisi: Add missing of_node_put after of_find_compatible_node [ Upstream commit 9bc72e47d4630d58a840a66a869c56b29554cfe4 ] of_find_compatible_node will increment the refcount of the returned device_node. Calling of_node_put() to avoid the refcount leak Signed-off-by: Peng Wu Signed-off-by: Wei Xu Signed-off-by: Sasha Levin commit 48a65f958d9c4505e1f2aafc5399e235b0c53aed Author: Krzysztof Kozlowski Date: Tue Apr 26 20:34:43 2022 +0200 ARM: dts: exynos: add atmel,24c128 fallback to Samsung EEPROM [ Upstream commit f038e8186fbc5723d7d38c6fa1d342945107347e ] The Samsung s524ad0xd1 EEPROM should use atmel,24c128 fallback, according to the AT24 EEPROM bindings. Reported-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220426183443.243113-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit 2d7b23db35254b7d46e852967090c64cdccf24da Author: Peng Wu Date: Fri Apr 29 01:03:56 2022 +0200 ARM: versatile: Add missing of_node_put in dcscb_init [ Upstream commit 23b44f9c649bbef10b45fa33080cd8b4166800ae ] The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use of_node_put() to avoid the refcount leak. Signed-off-by: Peng Wu Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220428230356.69418-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 6d830edf3dfbe23ff90cb5be658aaebad1193049 Author: OGAWA Hirofumi Date: Fri Apr 29 14:38:02 2022 -0700 fat: add ratelimit to fat*_ent_bread() [ Upstream commit 183c3237c928109d2008c0456dff508baf692b20 ] fat*_ent_bread() can be the cause of too many report on I/O error path. So use fat_msg_ratelimit() instead. Link: https://lkml.kernel.org/r/87bkxogfeq.fsf@mail.parknet.co.jp Signed-off-by: OGAWA Hirofumi Reported-by: qianfan Tested-by: qianfan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 232a8059d1e081d351ca6a71884ee39d4b2ddd8c Author: Janusz Krzysztofik Date: Sun Apr 10 15:07:54 2022 +0200 ARM: OMAP1: clock: Fix UART rate reporting algorithm [ Upstream commit 338d5d476cde853dfd97378d20496baabc2ce3c0 ] Since its introduction to the mainline kernel, omap1_uart_recalc() helper makes incorrect use of clk->enable_bit as a ready to use bitmap mask while it only provides the bit number. Fix it. Signed-off-by: Janusz Krzysztofik Acked-by: Tony Lindgren Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 6c4ad94011e20f4134b0606d9b68d5db564828e1 Author: Zixuan Fu Date: Mon Apr 11 18:45:34 2022 +0800 fs: jfs: fix possible NULL pointer dereference in dbFree() [ Upstream commit 0d4837fdb796f99369cf7691d33de1b856bcaf1f ] In our fault-injection testing, the variable "nblocks" in dbFree() can be zero when kmalloc_array() fails in dtSearch(). In this case, the variable "mp" in dbFree() would be NULL and then it is dereferenced in "write_metapage(mp)". The failure log is listed as follows: [ 13.824137] BUG: kernel NULL pointer dereference, address: 0000000000000020 ... [ 13.827416] RIP: 0010:dbFree+0x5f7/0x910 [jfs] [ 13.834341] Call Trace: [ 13.834540] [ 13.834713] txFreeMap+0x7b4/0xb10 [jfs] [ 13.835038] txUpdateMap+0x311/0x650 [jfs] [ 13.835375] jfs_lazycommit+0x5f2/0xc70 [jfs] [ 13.835726] ? sched_dynamic_update+0x1b0/0x1b0 [ 13.836092] kthread+0x3c2/0x4a0 [ 13.836355] ? txLockFree+0x160/0x160 [jfs] [ 13.836763] ? kthread_unuse_mm+0x160/0x160 [ 13.837106] ret_from_fork+0x1f/0x30 [ 13.837402] ... This patch adds a NULL check of "mp" before "write_metapage(mp)" is called. Reported-by: TOTE Robot Signed-off-by: Zixuan Fu Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit aaf44c1cbe61c5d426c2ac7d044b87b490828aeb Author: Jakub Kicinski Date: Fri May 20 12:56:05 2022 -0700 eth: tg3: silence the GCC 12 array-bounds warning [ Upstream commit 9dec850fd7c210a04b4707df8e6c95bfafdd6a4b ] GCC 12 currently generates a rather inconsistent warning: drivers/net/ethernet/broadcom/tg3.c:17795:51: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Warray-bounds] 17795 | struct tg3_napi *tnapi = &tp->napi[i]; | ~~~~~~~~^~~ i is guaranteed < tp->irq_max which in turn is either 1 or 5. There are more loops like this one in the driver, but strangely GCC 12 dislikes only this single one. Silence this silliness for now. Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 019ed251b532c834a6d600d98da11c1028233bfd Author: David Howells Date: Sat May 21 08:45:41 2022 +0100 rxrpc: Return an error to sendmsg if call failed [ Upstream commit 4ba68c5192554876bd8c3afd904e3064d2915341 ] If at the end of rxrpc sendmsg() or rxrpc_kernel_send_data() the call that was being given data was aborted remotely or otherwise failed, return an error rather than returning the amount of data buffered for transmission. The call (presumably) did not complete, so there's not much point continuing with it. AF_RXRPC considers it "complete" and so will be unwilling to do anything else with it - and won't send a notification for it, deeming the return from sendmsg sufficient. Not returning an error causes afs to incorrectly handle a StoreData operation that gets interrupted by a change of address due to NAT reconfiguration. This doesn't normally affect most operations since their request parameters tend to fit into a single UDP packet and afs_make_call() returns before the server responds; StoreData is different as it involves transmission of a lot of data. This can be triggered on a client by doing something like: dd if=/dev/zero of=/afs/example.com/foo bs=1M count=512 at one prompt, and then changing the network address at another prompt, e.g.: ifconfig enp6s0 inet 192.168.6.2 && route add 192.168.6.1 dev enp6s0 Tracing packets on an Auristor fileserver looks something like: 192.168.6.1 -> 192.168.6.3 RX 107 ACK Idle Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.3 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(64538) (64538) 192.168.6.3 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(64538) (64538) 192.168.6.1 -> 192.168.6.3 RX 107 ACK Idle Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.2 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(0) (0) 192.168.6.2 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(0) (0) 192.168.6.1 -> 192.168.6.2 RX 107 ACK Exceeds Window Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.1 -> 192.168.6.2 RX 74 ABORT Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.1 -> 192.168.6.2 RX 74 ABORT Seq: 29321 Call: 4 Source Port: 7000 Destination Port: 7001 The Auristor fileserver logs code -453 (RXGEN_SS_UNMARSHAL), but the abort code received by kafs is -5 (RX_PROTOCOL_ERROR) as the rx layer sees the condition and generates an abort first and the unmarshal error is a consequence of that at the application layer. Reported-by: Marc Dionne Signed-off-by: David Howells cc: linux-afs@lists.infradead.org Link: http://lists.infradead.org/pipermail/linux-afs/2021-December/004810.html # v1 Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2aa9343f78150c181c7ec4c9b2eb058f4af5789c Author: Kwanghoon Son Date: Wed Apr 27 03:16:45 2022 +0200 media: exynos4-is: Fix compile warning [ Upstream commit e080f5c1f2b6d02c02ee5d674e0e392ccf63bbaf ] Declare static on function 'fimc_isp_video_device_unregister'. When VIDEO_EXYNOS4_ISP_DMA_CAPTURE=n, compiler warns about warning: no previous prototype for function [-Wmissing-prototypes] Reported-by: kernel test robot Signed-off-by: Kwanghoon Son Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7d801e807536a9a9c2146c5f4a5836f154517ed3 Author: Lin Ma Date: Mon May 16 17:20:35 2022 +0800 ASoC: rt5645: Fix errorenous cleanup order [ Upstream commit 2def44d3aec59e38d2701c568d65540783f90f2f ] There is a logic error when removing rt5645 device as the function rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and delete the &rt5645->btn_check_timer latter. However, since the timer handler rt5645_btn_check_callback() will re-queue the jack_detect_work, this cleanup order is buggy. That is, once the del_timer_sync in rt5645_i2c_remove is concurrently run with the rt5645_btn_check_callback, the canceled jack_detect_work will be rescheduled again, leading to possible use-after-free. This patch fix the issue by placing the del_timer_sync function before the cancel_delayed_work_sync. Signed-off-by: Lin Ma Link: https://lore.kernel.org/r/20220516092035.28283-1-linma@zju.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8321b17789f614414206af07e17ce4751c95dc76 Author: Smith, Kyle Miller (Nimble Kernel) Date: Fri Apr 22 14:40:32 2022 +0000 nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags [ Upstream commit da42761181627e9bdc37d18368b827948a583929 ] In nvme_alloc_admin_tags, the admin_q can be set to an error (typically -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which is checked immediately after the call. However, when we return the error message up the stack, to nvme_reset_work the error takes us to nvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]). Here, we only check that the admin_q is non-NULL, rather than not an error or NULL, and begin quiescing a queue that never existed, leading to bad / NULL pointer dereference. Signed-off-by: Kyle Smith Reviewed-by: Chaitanya Kulkarni Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit aac03878d956aa076308d94c70ab4b56e0814195 Author: Jason A. Donenfeld Date: Sat Apr 23 21:11:41 2022 +0200 openrisc: start CPU timer early in boot [ Upstream commit 516dd4aacd67a0f27da94f3fe63fe0f4dbab6e2b ] In order to measure the boot process, the timer should be switched on as early in boot as possible. As well, the commit defines the get_cycles macro, like the previous patches in this series, so that generic code is aware that it's implemented by the platform, as is done on other archs. Cc: Thomas Gleixner Cc: Arnd Bergmann Cc: Jonas Bonn Cc: Stefan Kristiansson Acked-by: Stafford Horne Reported-by: Guenter Roeck Signed-off-by: Jason A. Donenfeld Signed-off-by: Sasha Levin commit d1e960ce5f60a9351860c8696d46a09d5f3cd29d Author: Corey Minyard Date: Fri Apr 1 07:44:53 2022 -0500 ipmi:ssif: Check for NULL msg when handling events and messages [ Upstream commit 7602b957e2404e5f98d9a40b68f1fd27f0028712 ] Even though it's not possible to get into the SSIF_GETTING_MESSAGES and SSIF_GETTING_EVENTS states without a valid message in the msg field, it's probably best to be defensive here and check and print a log, since that means something else went wrong. Also add a default clause to that switch statement to release the lock and print a log, in case the state variable gets messed up somehow. Reported-by: Haowen Bai Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit fb8067f18b1fbaab51c4ea8919adebb2ed43b83e Author: Mikulas Patocka Date: Tue May 10 13:17:32 2022 -0400 dma-debug: change allocation mode from GFP_NOWAIT to GFP_ATIOMIC [ Upstream commit 84bc4f1dbbbb5f8aa68706a96711dccb28b518e5 ] We observed the error "cacheline tracking ENOMEM, dma-debug disabled" during a light system load (copying some files). The reason for this error is that the dma_active_cacheline radix tree uses GFP_NOWAIT allocation - so it can't access the emergency memory reserves and it fails as soon as anybody reaches the watermark. This patch changes GFP_NOWAIT to GFP_ATOMIC, so that it can access the emergency memory reserves. Signed-off-by: Mikulas Patocka Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e476befc1144b17c0b6d4ea8ad5cae610d4b2b07 Author: Mark Brown Date: Thu Apr 28 17:18:32 2022 +0100 ASoC: dapm: Don't fold register value changes into notifications [ Upstream commit ad685980469b9f9b99d4d6ea05f4cb8f57cb2234 ] DAPM tracks and reports the value presented to the user from DAPM controls separately to the register value, these may diverge during initialisation or when an autodisable control is in use. When writing DAPM controls we currently report that a change has occurred if either the DAPM value or the value stored in the register has changed, meaning that if the two are out of sync we may appear to report a spurious event to userspace. Since we use this folded in value for nothing other than the value reported to userspace simply drop the folding in of the register change. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220428161833.3690050-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b0caa4967dd2d87023124b33f8998827f653872c Author: jianghaoran Date: Fri Apr 29 13:38:02 2022 +0800 ipv6: Don't send rs packets to the interface of ARPHRD_TUNNEL [ Upstream commit b52e1cce31ca721e937d517411179f9196ee6135 ] ARPHRD_TUNNEL interface can't process rs packets and will generate TX errors ex: ip tunnel add ethn mode ipip local 192.168.1.1 remote 192.168.1.2 ifconfig ethn x.x.x.x ethn: flags=209 mtu 1480 inet x.x.x.x netmask 255.255.255.255 destination x.x.x.x inet6 fe80::5efe:ac1e:3cdb prefixlen 64 scopeid 0x20 tunnel txqueuelen 1000 (IPIP Tunnel) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 3 dropped 0 overruns 0 carrier 0 collisions 0 Signed-off-by: jianghaoran Link: https://lore.kernel.org/r/20220429053802.246681-1-jianghaoran@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit af30beed949855c0933905e30c4728b5cdcd9297 Author: Evan Quan Date: Mon Apr 25 10:16:46 2022 +0800 drm/amd/pm: fix the compile warning [ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ] Fix the compile warning below: drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641 kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >= 0) => (0-u32max >= 0)' Reported-by: kernel test robot CC: Alex Deucher Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0e0eafe47face137e3023505e2892e515916d1af Author: Lv Ruyi Date: Mon Apr 18 10:57:55 2022 +0000 scsi: megaraid: Fix error check return value of register_chrdev() [ Upstream commit c5acd61dbb32b6bda0f3a354108f2b8dcb788985 ] If major equals 0, register_chrdev() returns an error code when it fails. This function dynamically allocates a major and returns its number on success, so we should use "< 0" to check it instead of "!". Link: https://lore.kernel.org/r/20220418105755.2558828-1-lv.ruyi@zte.com.cn Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4d6295b6d986476232332fffd08575b185f90d81 Author: Zheyu Ma Date: Sun Apr 10 08:44:09 2022 +0100 media: cx25821: Fix the warning when removing the module [ Upstream commit 2203436a4d24302871617373a7eb21bc17e38762 ] When removing the module, we will get the following warning: [ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]' [ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0 [ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0 [ 14.759589] Call Trace: [ 14.759792] [ 14.759975] unregister_irq_proc+0x14c/0x170 [ 14.760340] irq_free_descs+0x94/0xe0 [ 14.760640] mp_unmap_irq+0xb6/0x100 [ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40 [ 14.761334] acpi_pci_irq_disable+0x1d3/0x320 [ 14.761688] pci_disable_device+0x1ad/0x380 [ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60 [ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821] [ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821] [ 14.763242] pci_device_remove+0x92/0x240 Fix this by freeing the irq before call pci_disable_device(). Signed-off-by: Zheyu Ma Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1d57be6b5dee2082fa101904990b789ace73b113 Author: Thibaut VARÈNE Date: Sun Apr 17 16:51:45 2022 +0200 ath9k: fix QCA9561 PA bias level [ Upstream commit e999a5da28a0e0f7de242d841ef7d5e48f4646ae ] This patch fixes an invalid TX PA DC bias level on QCA9561, which results in a very low output power and very low throughput as devices are further away from the AP (compared to other 2.4GHz APs). This patch was suggested by Felix Fietkau, who noted[1]: "The value written to that register is wrong, because while the mask definition AR_CH0_TOP2_XPABIASLVL uses a different value for 9561, the shift definition AR_CH0_TOP2_XPABIASLVL_S is hardcoded to 12, which is wrong for 9561." In real life testing, without this patch the 2.4GHz throughput on Yuncore XD3200 is around 10Mbps sitting next to the AP, and closer to practical maximum with the patch applied. [1] https://lore.kernel.org/all/91c58969-c60e-2f41-00ac-737786d435ae@nbd.name Signed-off-by: Thibaut VARÈNE Acked-by: Felix Fietkau Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220417145145.1847-1-hacks+kernel@slashdirt.org Signed-off-by: Sasha Levin commit 2615464854505188f909d0c07c37a6623693b5c7 Author: Keita Suzuki Date: Tue Apr 19 10:37:19 2022 +0000 drm/amd/pm: fix double free in si_parse_power_table() [ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ] In function si_parse_power_table(), array adev->pm.dpm.ps and its member is allocated. If the allocation of each member fails, the array itself is freed and returned with an error code. However, the array is later freed again in si_dpm_fini() function which is called when the function returns an error. This leads to potential double free of the array adev->pm.dpm.ps, as well as leak of its array members, since the members are not freed in the allocation function and the array is not nulled when freed. In addition adev->pm.dpm.num_ps, which keeps track of the allocated array member, is not updated until the member allocation is successfully finished, this could also lead to either use after free, or uninitialized variable access in si_dpm_fini(). Fix this by postponing the free of the array until si_dpm_fini() and increment adev->pm.dpm.num_ps everytime the array member is allocated. Signed-off-by: Keita Suzuki Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 74bab3bcf422593c582e47130aa8eb41ebb2dc09 Author: Amadeusz Sławiński Date: Tue Apr 12 11:16:28 2022 +0200 ALSA: jack: Access input_dev under mutex [ Upstream commit 1b6a6fc5280e97559287b61eade2d4b363e836f2 ] It is possible when using ASoC that input_dev is unregistered while calling snd_jack_report, which causes NULL pointer dereference. In order to prevent this serialize access to input_dev using mutex lock. Signed-off-by: Amadeusz Sławiński Reviewed-by: Cezary Rojewski Link: https://lore.kernel.org/r/20220412091628.3056922-1-amadeuszx.slawinski@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9da7c9e920a00e81c532b9a0b7edb7aa83fafdfd Author: Kirill A. Shutemov Date: Wed Apr 6 02:29:38 2022 +0300 ACPICA: Avoid cache flush inside virtual machines [ Upstream commit e2efb6359e620521d1e13f69b2257de8ceaa9475 ] While running inside virtual machine, the kernel can bypass cache flushing. Changing sleep state in a virtual machine doesn't affect the host system sleep state and cannot lead to data loss. Before entering sleep states, the ACPI code flushes caches to prevent data loss using the WBINVD instruction. This mechanism is required on bare metal. But, any use WBINVD inside of a guest is worthless. Changing sleep state in a virtual machine doesn't affect the host system sleep state and cannot lead to data loss, so most hypervisors simply ignore it. Despite this, the ACPI code calls WBINVD unconditionally anyway. It's useless, but also normally harmless. In TDX guests, though, WBINVD stops being harmless; it triggers a virtualization exception (#VE). If the ACPI cache-flushing WBINVD were left in place, TDX guests would need handling to recover from the exception. Avoid using WBINVD whenever running under a hypervisor. This both removes the useless WBINVDs and saves TDX from implementing WBINVD handling. Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Reviewed-by: Dave Hansen Reviewed-by: Dan Williams Reviewed-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20220405232939.73860-30-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin commit 1ff6b0727c8988f25eeb670b6c038c1120bb58dd Author: Haowen Bai Date: Fri Apr 1 15:10:54 2022 +0800 ipw2x00: Fix potential NULL dereference in libipw_xmit() [ Upstream commit e8366bbabe1d207cf7c5b11ae50e223ae6fc278b ] crypt and crypt->ops could be null, so we need to checking null before dereference Signed-off-by: Haowen Bai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1648797055-25730-1-git-send-email-baihaowen@meizu.com Signed-off-by: Sasha Levin commit cadee8777efb6b34a10dbbbcfab7023b9b0e8d1d Author: Haowen Bai Date: Fri Mar 25 18:15:15 2022 +0800 b43: Fix assigning negative value to unsigned variable [ Upstream commit 11800d893b38e0e12d636c170c1abc19c43c730c ] fix warning reported by smatch: drivers/net/wireless/broadcom/b43/phy_n.c:585 b43_nphy_adjust_lna_gain_table() warn: assigning (-2) to unsigned variable '*(lna_gain[0])' Signed-off-by: Haowen Bai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1648203315-28093-1-git-send-email-baihaowen@meizu.com Signed-off-by: Sasha Levin commit a1871f5a9c5f73c9aee71071c30e0cc367685baf Author: Haowen Bai Date: Fri Mar 25 18:17:13 2022 +0800 b43legacy: Fix assigning negative value to unsigned variable [ Upstream commit 3f6b867559b3d43a7ce1b4799b755e812fc0d503 ] fix warning reported by smatch: drivers/net/wireless/broadcom/b43legacy/phy.c:1181 b43legacy_phy_lo_b_measure() warn: assigning (-772) to unsigned variable 'fval' Signed-off-by: Haowen Bai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1648203433-8736-1-git-send-email-baihaowen@meizu.com Signed-off-by: Sasha Levin commit c79b41dca00cc54d2c9c1c9a26da1061c61fed68 Author: Niels Dossche Date: Mon Mar 21 23:55:16 2022 +0100 mwifiex: add mutex lock for call in mwifiex_dfs_chan_sw_work_queue [ Upstream commit 3e12968f6d12a34b540c39cbd696a760cc4616f0 ] cfg80211_ch_switch_notify uses ASSERT_WDEV_LOCK to assert that net_device->ieee80211_ptr->mtx (which is the same as priv->wdev.mtx) is held during the function's execution. mwifiex_dfs_chan_sw_work_queue is one of its callers, which does not hold that lock, therefore violating the assertion. Add a lock around the call. Disclaimer: I am currently working on a static analyser to detect missing locks. This was a reported case. I manually verified the report by looking at the code, so that I do not send wrong information or patches. After concluding that this seems to be a true positive, I created this patch. However, as I do not in fact have this particular hardware, I was unable to test it. Reviewed-by: Brian Norris Signed-off-by: Niels Dossche Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220321225515.32113-1-dossche.niels@gmail.com Signed-off-by: Sasha Levin commit e0828456578cc8ba0a69147f7ae3428392eec287 Author: Liu Zixian Date: Tue Mar 22 17:17:30 2022 +0800 drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes [ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ] drm_cvt_mode may return NULL and we should check it. This bug is found by syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218 Signed-off-by: Liu Zixian Link: http://patchwork.freedesktop.org/patch/msgid/20220322091730.1653-1-liuzixian4@huawei.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit b32304f17aa281b4f697df4ee64ea74984bf0e93 Author: Qu Wenruo Date: Tue May 10 15:10:18 2022 +0800 btrfs: add "0x" prefix for unsupported optional features commit d5321a0fa8bc49f11bea0b470800962c17d92d8f upstream. The following error message lack the "0x" obviously: cannot mount because of unsupported optional features (4000) Add the prefix to make it less confusing. This can happen on older kernels that try to mount a filesystem with newer features so it makes sense to backport to older trees. CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Nikolay Borisov Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8d910899b3037e9a4b20e0497c0a4a8a7e357914 Author: Eric W. Biederman Date: Fri Apr 29 09:23:55 2022 -0500 ptrace: Reimplement PTRACE_KILL by always sending SIGKILL commit 6a2d90ba027adba528509ffa27097cffd3879257 upstream. The current implementation of PTRACE_KILL is buggy and has been for many years as it assumes it's target has stopped in ptrace_stop. At a quick skim it looks like this assumption has existed since ptrace support was added in linux v1.0. While PTRACE_KILL has been deprecated we can not remove it as a quick search with google code search reveals many existing programs calling it. When the ptracee is not stopped at ptrace_stop some fields would be set that are ignored except in ptrace_stop. Making the userspace visible behavior of PTRACE_KILL a noop in those case. As the usual rules are not obeyed it is not clear what the consequences are of calling PTRACE_KILL on a running process. Presumably userspace does not do this as it achieves nothing. Replace the implementation of PTRACE_KILL with a simple send_sig_info(SIGKILL) followed by a return 0. This changes the observable user space behavior only in that PTRACE_KILL on a process not stopped in ptrace_stop will also kill it. As that has always been the intent of the code this seems like a reasonable change. Cc: stable@vger.kernel.org Reported-by: Al Viro Suggested-by: Al Viro Tested-by: Kees Cook Reviewed-by: Oleg Nesterov Link: https://lkml.kernel.org/r/20220505182645.497868-7-ebiederm@xmission.com Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 74a17e0f9bfedcaa73cc23a26ff30bf26c41a749 Author: Eric W. Biederman Date: Tue Apr 26 16:45:37 2022 -0500 ptrace/xtensa: Replace PT_SINGLESTEP with TIF_SINGLESTEP commit 4a3d2717d140401df7501a95e454180831a0c5af upstream. xtensa is the last user of the PT_SINGLESTEP flag. Changing tsk->ptrace in user_enable_single_step and user_disable_single_step without locking could potentiallly cause problems. So use a thread info flag instead of a flag in tsk->ptrace. Use TIF_SINGLESTEP that xtensa already had defined but unused. Remove the definitions of PT_SINGLESTEP and PT_BLOCKSTEP as they have no more users. Cc: stable@vger.kernel.org Acked-by: Max Filippov Tested-by: Kees Cook Reviewed-by: Oleg Nesterov Link: https://lkml.kernel.org/r/20220505182645.497868-4-ebiederm@xmission.com Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit f5c5f3671e40cb70a56a9ede3a3f0afae4f0ace1 Author: Monish Kumar R Date: Fri May 20 18:30:44 2022 +0530 USB: new quirk for Dell Gen 2 devices commit 97fa5887cf283bb75ffff5f6b2c0e71794c02400 upstream. Add USB_QUIRK_NO_LPM and USB_QUIRK_RESET_RESUME quirks for Dell usb gen 2 device to not fail during enumeration. Found this bug on own testing Signed-off-by: Monish Kumar R Cc: stable Link: https://lore.kernel.org/r/20220520130044.17303-1-monish.kumar.r@intel.com Signed-off-by: Greg Kroah-Hartman