commit d235c2b1f470f012bda26844aabf26321b1c446a Author: Greg Kroah-Hartman Date: Sat Oct 15 08:01:46 2022 +0200 Linux 5.19.16 Link: https://lore.kernel.org/r/20221013175145.236739253@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Justin M. Forbes Tested-by: Slade Watkins Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 279116cb0bc5cd8af65d6a00ffe074bd09842f88 Author: Shunsuke Mie Date: Wed Sep 7 11:01:00 2022 +0900 misc: pci_endpoint_test: Fix pci_endpoint_test_{copy,write,read}() panic commit 8e30538eca016de8e252bef174beadecd64239f0 upstream. The dma_map_single() doesn't permit zero length mapping. It causes a follow panic. A panic was reported on arm64: [ 60.137988] ------------[ cut here ]------------ [ 60.142630] kernel BUG at kernel/dma/swiotlb.c:624! [ 60.147508] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 60.152992] Modules linked in: dw_hdmi_cec crct10dif_ce simple_bridge rcar_fdp1 vsp1 rcar_vin videobuf2_vmalloc rcar_csi2 v4l 2_mem2mem videobuf2_dma_contig videobuf2_memops pci_endpoint_test videobuf2_v4l2 videobuf2_common rcar_fcp v4l2_fwnode v4l2_asyn c videodev mc gpio_bd9571mwv max9611 pwm_rcar ccree at24 authenc libdes phy_rcar_gen3_usb3 usb_dmac display_connector pwm_bl [ 60.186252] CPU: 0 PID: 508 Comm: pcitest Not tainted 6.0.0-rc1rpci-dev+ #237 [ 60.193387] Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT) [ 60.201302] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 60.208263] pc : swiotlb_tbl_map_single+0x2c0/0x590 [ 60.213149] lr : swiotlb_map+0x88/0x1f0 [ 60.216982] sp : ffff80000a883bc0 [ 60.220292] x29: ffff80000a883bc0 x28: 0000000000000000 x27: 0000000000000000 [ 60.227430] x26: 0000000000000000 x25: ffff0004c0da20d0 x24: ffff80000a1f77c0 [ 60.234567] x23: 0000000000000002 x22: 0001000040000010 x21: 000000007a000000 [ 60.241703] x20: 0000000000200000 x19: 0000000000000000 x18: 0000000000000000 [ 60.248840] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0006ff7b9180 [ 60.255977] x14: ffff0006ff7b9180 x13: 0000000000000000 x12: 0000000000000000 [ 60.263113] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 60.270249] x8 : 0001000000000010 x7 : ffff0004c6754b20 x6 : 0000000000000000 [ 60.277385] x5 : ffff0004c0da2090 x4 : 0000000000000000 x3 : 0000000000000001 [ 60.284521] x2 : 0000000040000000 x1 : 0000000000000000 x0 : 0000000040000010 [ 60.291658] Call trace: [ 60.294100] swiotlb_tbl_map_single+0x2c0/0x590 [ 60.298629] swiotlb_map+0x88/0x1f0 [ 60.302115] dma_map_page_attrs+0x188/0x230 [ 60.306299] pci_endpoint_test_ioctl+0x5e4/0xd90 [pci_endpoint_test] [ 60.312660] __arm64_sys_ioctl+0xa8/0xf0 [ 60.316583] invoke_syscall+0x44/0x108 [ 60.320334] el0_svc_common.constprop.0+0xcc/0xf0 [ 60.325038] do_el0_svc+0x2c/0xb8 [ 60.328351] el0_svc+0x2c/0x88 [ 60.331406] el0t_64_sync_handler+0xb8/0xc0 [ 60.335587] el0t_64_sync+0x18c/0x190 [ 60.339251] Code: 52800013 d2e00414 35fff45c d503201f (d4210000) [ 60.345344] ---[ end trace 0000000000000000 ]--- To fix it, this patch adds a checking the payload length if it is zero. Fixes: 343dc693f7b7 ("misc: pci_endpoint_test: Prevent some integer overflows") Cc: stable Signed-off-by: Shunsuke Mie Link: https://lore.kernel.org/r/20220907020100.122588-2-mie@igel.co.jp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d472808756b305213ec7e4559a51eea4f08e24ca Author: Shunsuke Mie Date: Wed Sep 7 11:00:59 2022 +0900 misc: pci_endpoint_test: Aggregate params checking for xfer commit 3e42deaac06567c7e86d287c305ccda24db4ae3d upstream. Each transfer test functions have same parameter checking code. This patch unites those to an introduced function. Signed-off-by: Shunsuke Mie Cc: stable Link: https://lore.kernel.org/r/20220907020100.122588-1-mie@igel.co.jp Signed-off-by: Greg Kroah-Hartman commit d0ecbd70f08072d545982d4cc9d42b376171a999 Author: Cameron Gutman Date: Thu Aug 18 17:44:09 2022 +0200 Input: xpad - fix wireless 360 controller breaking after suspend commit a17b9841152e7f4621619902b347e2cc39c32996 upstream. Suspending and resuming the system can sometimes cause the out URB to get hung after a reset_resume. This causes LED setting and force feedback to break on resume. To avoid this, just drop the reset_resume callback so the USB core rebinds xpad to the wireless pads on resume if a reset happened. A nice side effect of this change is the LED ring on wireless controllers is now set correctly on system resume. Cc: stable@vger.kernel.org Fixes: 4220f7db1e42 ("Input: xpad - workaround dead irq_out after suspend/ resume") Signed-off-by: Cameron Gutman Signed-off-by: Pavel Rojtberg Link: https://lore.kernel.org/r/20220818154411.510308-3-rojtberg@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d1a1dbe71f73b98a4c89af13ec716e5630a8ca80 Author: Pavel Rojtberg Date: Thu Aug 18 17:44:08 2022 +0200 Input: xpad - add supported devices as contributed on github commit b382c5e37344883dc97525d05f1f6b788f549985 upstream. This is based on multiple commits at https://github.com/paroj/xpad Cc: stable@vger.kernel.org Signed-off-by: Jasper Poppe Signed-off-by: Jeremy Palmer Signed-off-by: Ruineka Signed-off-by: Cleber de Mattos Casali Signed-off-by: Kyle Gospodnetich Signed-off-by: Pavel Rojtberg Link: https://lore.kernel.org/r/20220818154411.510308-2-rojtberg@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ac719db96b23279deb64df9bdacd660d55ed40ce Author: Jeremy Kerr Date: Wed Oct 12 10:08:51 2022 +0800 mctp: prevent double key removal and unref commit 3a732b46736cd8a29092e4b0b1a9ba83e672bf89 upstream. Currently, we have a bug where a simultaneous DROPTAG ioctl and socket close may race, as we attempt to remove a key from lists twice, and perform an unref for each removal operation. This may result in a uaf when we attempt the second unref. This change fixes the race by making __mctp_key_remove tolerant to being called on a key that has already been removed from the socket/net lists, and only performs the unref when we do the actual remove. We also need to hold the list lock on the ioctl cleanup path. This fix is based on a bug report and comprehensive analysis from butt3rflyh4ck , found via syzkaller. Cc: stable@vger.kernel.org Fixes: 63ed1aab3d40 ("mctp: Add SIOCMCTP{ALLOC,DROP}TAG ioctls for tag control") Reported-by: butt3rflyh4ck Signed-off-by: Jeremy Kerr Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3aecb0895aacdda81c520a4dc43d1216dbf38dfa Author: Johannes Berg Date: Wed Oct 5 23:11:43 2022 +0200 wifi: cfg80211: update hidden BSSes to avoid WARN_ON commit c90b93b5b782891ebfda49d4e5da36632fefd5d1 upstream. When updating beacon elements in a non-transmitted BSS, also update the hidden sub-entries to the same beacon elements, so that a future update through other paths won't trigger a WARN_ON(). The warning is triggered because the beacon elements in the hidden BSSes that are children of the BSS should always be the same as in the parent. Reported-by: Sönke Huster Tested-by: Sönke Huster Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit fa63b5f6f8853ace755d9a23fb75817d5ba20df5 Author: Johannes Berg Date: Wed Oct 5 21:24:10 2022 +0200 wifi: mac80211: fix crash in beacon protection for P2P-device commit b2d03cabe2b2e150ff5a381731ea0355459be09f upstream. If beacon protection is active but the beacon cannot be decrypted or is otherwise malformed, we call the cfg80211 API to report this to userspace, but that uses a netdev pointer, which isn't present for P2P-Device. Fix this to call it only conditionally to ensure cfg80211 won't crash in the case of P2P-Device. This fixes CVE-2022-42722. Reported-by: Sönke Huster Fixes: 9eaf183af741 ("mac80211: Report beacon protection failures to user space") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 2bee6f75e3c64097d1d11bc36f1e54a500060acc Author: Johannes Berg Date: Wed Oct 5 15:10:09 2022 +0200 wifi: mac80211_hwsim: avoid mac80211 warning on bad rate commit 1833b6f46d7e2830251a063935ab464256defe22 upstream. If the tool on the other side (e.g. wmediumd) gets confused about the rate, we hit a warning in mac80211. Silence that by effectively duplicating the check here and dropping the frame silently (in mac80211 it's dropped with the warning). Reported-by: Sönke Huster Tested-by: Sönke Huster Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 1d73c990e9bafc2754b1ced71345f73f5beb1781 Author: Johannes Berg Date: Sat Oct 1 00:01:44 2022 +0200 wifi: cfg80211: avoid nontransmitted BSS list corruption commit bcca852027e5878aec911a347407ecc88d6fff7f upstream. If a non-transmitted BSS shares enough information (both SSID and BSSID!) with another non-transmitted BSS of a different AP, then we can find and update it, and then try to add it to the non-transmitted BSS list. We do a search for it on the transmitted BSS, but if it's not there (but belongs to another transmitted BSS), the list gets corrupted. Since this is an erroneous situation, simply fail the list insertion in this case and free the non-transmitted BSS. This fixes CVE-2022-42721. Reported-by: Sönke Huster Tested-by: Sönke Huster Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 46b23a9559580a72d8cc5811b1bce8db099806d6 Author: Johannes Berg Date: Fri Sep 30 23:44:23 2022 +0200 wifi: cfg80211: fix BSS refcounting bugs commit 0b7808818cb9df6680f98996b8e9a439fa7bcc2f upstream. There are multiple refcounting bugs related to multi-BSSID: - In bss_ref_get(), if the BSS has a hidden_beacon_bss, then the bss pointer is overwritten before checking for the transmitted BSS, which is clearly wrong. Fix this by using the bss_from_pub() macro. - In cfg80211_bss_update() we copy the transmitted_bss pointer from tmp into new, but then if we release new, we'll unref it erroneously. We already set the pointer and ref it, but need to NULL it since it was copied from the tmp data. - In cfg80211_inform_single_bss_data(), if adding to the non- transmitted list fails, we unlink the BSS and yet still we return it, but this results in returning an entry without a reference. We shouldn't return it anyway if it was broken enough to not get added there. This fixes CVE-2022-42720. Reported-by: Sönke Huster Tested-by: Sönke Huster Fixes: a3584f56de1c ("cfg80211: Properly track transmitting and non-transmitting BSS") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 867184200c057a9efdd815dfacefe85e5f2586a7 Author: Johannes Berg Date: Thu Sep 29 21:50:44 2022 +0200 wifi: cfg80211: ensure length byte is present before access commit 567e14e39e8f8c6997a1378bc3be615afca86063 upstream. When iterating the elements here, ensure the length byte is present before checking it to see if the entire element will fit into the buffer. Longer term, we should rewrite this code using the type-safe element iteration macros that check all of this. Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning") Reported-by: Soenke Huster Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e6d77ac0132da7e73fdcc4a38dd4c40ac0226466 Author: Johannes Berg Date: Wed Sep 28 22:07:15 2022 +0200 wifi: mac80211: fix MBSSID parsing use-after-free commit ff05d4b45dd89b922578dac497dcabf57cf771c6 upstream. When we parse a multi-BSSID element, we might point some element pointers into the allocated nontransmitted_profile. However, we free this before returning, causing UAF when the relevant pointers in the parsed elements are accessed. Fix this by not allocating the scratch buffer separately but as part of the returned structure instead, that way, there are no lifetime issues with it. The scratch buffer introduction as part of the returned data here is taken from MLO feature work done by Ilan. This fixes CVE-2022-42719. Fixes: 5023b14cf4df ("mac80211: support profile split between elements") Co-developed-by: Ilan Peer Signed-off-by: Ilan Peer Reviewed-by: Kees Cook Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 74abb1952a03ba935602c38ce9fa0c33adbfbb55 Author: Johannes Berg Date: Wed Sep 28 22:01:37 2022 +0200 wifi: cfg80211/mac80211: reject bad MBSSID elements commit 8f033d2becc24aa6bfd2a5c104407963560caabc upstream. Per spec, the maximum value for the MaxBSSID ('n') indicator is 8, and the minimum is 1 since a multiple BSSID set with just one BSSID doesn't make sense (the # of BSSIDs is limited by 2^n). Limit this in the parsing in both cfg80211 and mac80211, rejecting any elements with an invalid value. This fixes potentially bad shifts in the processing of these inside the cfg80211_gen_new_bssid() function later. I found this during the investigation of CVE-2022-41674 fixed by the previous patch. Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning") Fixes: 78ac51f81532 ("mac80211: support multi-bssid") Reviewed-by: Kees Cook Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 42ea11a81ac853c3e870c70d61ab435d0b09b851 Author: Johannes Berg Date: Wed Sep 28 21:56:15 2022 +0200 wifi: cfg80211: fix u8 overflow in cfg80211_update_notlisted_nontrans() commit aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d upstream. In the copy code of the elements, we do the following calculation to reach the end of the MBSSID element: /* copy the IEs after MBSSID */ cpy_len = mbssid[1] + 2; This looks fine, however, cpy_len is a u8, the same as mbssid[1], so the addition of two can overflow. In this case the subsequent memcpy() will overflow the allocated buffer, since it copies 256 bytes too much due to the way the allocation and memcpy() sizes are calculated. Fix this by using size_t for the cpy_len variable. This fixes CVE-2022-41674. Reported-by: Soenke Huster Tested-by: Soenke Huster Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning") Reviewed-by: Kees Cook Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 848bb8517e41a7655e6a840f8adca7ec5e4b9959 Author: Jason A. Donenfeld Date: Thu Sep 22 18:46:04 2022 +0200 random: use expired timer rather than wq for mixing fast pool commit 748bc4dd9e663f23448d8ad7e58c011a67ea1eca upstream. Previously, the fast pool was dumped into the main pool periodically in the fast pool's hard IRQ handler. This worked fine and there weren't problems with it, until RT came around. Since RT converts spinlocks into sleeping locks, problems cropped up. Rather than switching to raw spinlocks, the RT developers preferred we make the transformation from originally doing: do_some_stuff() spin_lock() do_some_other_stuff() spin_unlock() to doing: do_some_stuff() queue_work_on(some_other_stuff_worker) This is an ordinary pattern done all over the kernel. However, Sherry noticed a 10% performance regression in qperf TCP over a 40gbps InfiniBand card. Quoting her message: > MT27500 Family [ConnectX-3] cards: > Infiniband device 'mlx4_0' port 1 status: > default gid: fe80:0000:0000:0000:0010:e000:0178:9eb1 > base lid: 0x6 > sm lid: 0x1 > state: 4: ACTIVE > phys state: 5: LinkUp > rate: 40 Gb/sec (4X QDR) > link_layer: InfiniBand > > Cards are configured with IP addresses on private subnet for IPoIB > performance testing. > Regression identified in this bug is in TCP latency in this stack as reported > by qperf tcp_lat metric: > > We have one system listen as a qperf server: > [root@yourQperfServer ~]# qperf > > Have the other system connect to qperf server as a client (in this > case, it’s X7 server with Mellanox card): > [root@yourQperfClient ~]# numactl -m0 -N0 qperf 20.20.20.101 -v -uu -ub --time 60 --wait_server 20 -oo msg_size:4K:1024K:*2 tcp_lat Rather than incur the scheduling latency from queue_work_on, we can instead switch to running on the next timer tick, on the same core. This also batches things a bit more -- once per jiffy -- which is okay now that mix_interrupt_randomness() can credit multiple bits at once. Reported-by: Sherry Yang Tested-by: Paul Webb Cc: Sherry Yang Cc: Phillip Goerl Cc: Jack Vogel Cc: Nicky Veitch Cc: Colm Harrington Cc: Ramanan Govindarajan Cc: Sebastian Andrzej Siewior Cc: Dominik Brodowski Cc: Tejun Heo Cc: Sultan Alsawaf Cc: stable@vger.kernel.org Fixes: 58340f8e952b ("random: defer fast pool mixing to worker") Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman commit 111824744645736c4dd6b2100c530e6375a0f542 Author: Jason A. Donenfeld Date: Thu Sep 22 18:46:04 2022 +0200 random: avoid reading two cache lines on irq randomness commit 9ee0507e896b45af6d65408c77815800bce30008 upstream. In order to avoid reading and dirtying two cache lines on every IRQ, move the work_struct to the bottom of the fast_pool struct. add_ interrupt_randomness() always touches .pool and .count, which are currently split, because .mix pushes everything down. Instead, move .mix to the bottom, so that .pool and .count are always in the first cache line, since .mix is only accessed when the pool is full. Fixes: 58340f8e952b ("random: defer fast pool mixing to worker") Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman commit ee42204c1cd543ce48dfd93fee2751c037a7d053 Author: Giovanni Cabiddu Date: Fri Sep 9 11:49:13 2022 +0100 Revert "crypto: qat - reduce size of mapped region" commit 9c5f21b198d259bfe1191b1fedf08e2eab15b33b upstream. This reverts commit e48767c17718067ba21fb2ef461779ec2506f845. In an attempt to resolve a set of warnings reported by the static analyzer Smatch, the reverted commit improperly reduced the sizes of the DMA mappings used for the input and output parameters for both RSA and DH creating a mismatch (map size=8 bytes, unmap size=64 bytes). This issue is reported when CONFIG_DMA_API_DEBUG is selected, when the crypto self test is run. The function dma_unmap_single() reports a warning similar to the one below, saying that the `device driver frees DMA memory with different size`. DMA-API: 4xxx 0000:06:00.0: device driver frees DMA memory with different size [device address=0x0000000123206c80] [map size=8 bytes] [unmap size=64 bytes] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:973 check_unmap+0x3d0/0x8c0\ ... Call Trace: debug_dma_unmap_page+0x5c/0x60 qat_dh_cb+0xd7/0x110 [intel_qat] qat_alg_asym_callback+0x1a/0x30 [intel_qat] adf_response_handler+0xbd/0x1a0 [intel_qat] tasklet_action_common.constprop.0+0xcd/0xe0 __do_softirq+0xf8/0x30c __irq_exit_rcu+0xbf/0x140 common_interrupt+0xb9/0xd0 The original commit was correct. Cc: Reported-by: Herbert Xu Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3a8f93f3779e831ce74ce3fd3cf488066ca1c488 Author: Nathan Lynch Date: Wed Sep 7 17:01:11 2022 -0500 Revert "powerpc/rtas: Implement reentrant rtas call" commit f88aabad33ea22be2ce1c60d8901942e4e2a9edb upstream. At the time this was submitted by Leonardo, I confirmed -- or thought I had confirmed -- with PowerVM partition firmware development that the following RTAS functions: - ibm,get-xive - ibm,int-off - ibm,int-on - ibm,set-xive were safe to call on multiple CPUs simultaneously, not only with respect to themselves as indicated by PAPR, but with arbitrary other RTAS calls: https://lore.kernel.org/linuxppc-dev/875zcy2v8o.fsf@linux.ibm.com/ Recent discussion with firmware development makes it clear that this is not true, and that the code in commit b664db8e3f97 ("powerpc/rtas: Implement reentrant rtas call") is unsafe, likely explaining several strange bugs we've seen in internal testing involving DLPAR and LPM. These scenarios use ibm,configure-connector, whose internal state can be corrupted by the concurrent use of the "reentrant" functions, leading to symptoms like endless busy statuses from RTAS. Fixes: b664db8e3f97 ("powerpc/rtas: Implement reentrant rtas call") Cc: stable@vger.kernel.org # v5.8+ Signed-off-by: Nathan Lynch Reviewed-by: Laurent Dufour Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220907220111.223267-1-nathanl@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit bd9c917efcf88b21aec640de8f0717beb20c7987 Author: Andy Shevchenko Date: Tue Sep 27 18:53:32 2022 +0300 Revert "usb: dwc3: Don't switch OTG -> peripheral if extcon is present" commit 7a84e7353e23202d4f82b05093af4db2b26e6768 upstream. This reverts commit 0f01017191384e3962fa31520a9fd9846c3d352f. As pointed out by Ferry this breaks Dual Role support on Intel Merrifield platforms. Fixes: 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present") Reported-by: Ferry Toth Cc: stable@vger.kernel.org Signed-off-by: Andy Shevchenko Tested-by: Ferry Toth # for Merrifield Reviewed-by: Sven Peter Link: https://lore.kernel.org/r/20220927155332.10762-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit d42228fc2cad15a3f1e18abba15b7a3bf7b24e75 Author: Andy Shevchenko Date: Tue Sep 27 18:53:31 2022 +0300 Revert "USB: fixup for merge issue with "usb: dwc3: Don't switch OTG -> peripheral if extcon is present"" commit 2adc960ce79d3231b02f820daeee434542fe2911 upstream. This reverts commit 8bd6b8c4b1009d7d2662138d6bdc6fe58a9274c5. Prerequisite revert for the reverting of the original commit 0f0101719138. Fixes: 8bd6b8c4b100 ("USB: fixup for merge issue with "usb: dwc3: Don't switch OTG -> peripheral if extcon is present"") Fixes: 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present") Reported-by: Ferry Toth Cc: stable@vger.kernel.org Signed-off-by: Andy Shevchenko Tested-by: Ferry Toth # for Merrifield Link: https://lore.kernel.org/r/20220927155332.10762-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 5857b9cd9b9172700d6322e66ab57815daa97d2d Author: Frank Wunderlich Date: Mon Sep 26 17:07:39 2022 +0200 USB: serial: qcserial: add new usb-id for Dell branded EM7455 commit eee48781ea199e32c1d0c4732641c494833788ca upstream. Add support for Dell 5811e (EM7455) with USB-id 0x413c:0x81c2. Signed-off-by: Frank Wunderlich Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 6ae8aa5dcf0d7ada07964c8638e55d3af5896a86 Author: Linus Torvalds Date: Fri Sep 9 08:54:47 2022 +0200 scsi: stex: Properly zero out the passthrough command structure commit 6022f210461fef67e6e676fd8544ca02d1bcfa7a upstream. The passthrough structure is declared off of the stack, so it needs to be set to zero before copied back to userspace to prevent any unintentional data leakage. Switch things to be statically allocated which will fill the unused fields with 0 automatically. Link: https://lore.kernel.org/r/YxrjN3OOw2HHl9tx@kroah.com Cc: stable@kernel.org Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: Dan Carpenter Reported-by: hdthky Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 55e19a4c111e986cbff49431efc15201d126dca0 Author: Orlando Chamberlain Date: Thu Sep 29 11:49:56 2022 +0000 efi: Correct Macmini DMI match in uefi cert quirk commit bab715bdaa9ebf28d99a6d1efb2704a30125e96d upstream. It turns out Apple doesn't capitalise the "mini" in "Macmini" in DMI, which is inconsistent with other model line names. Correct the capitalisation of Macmini in the quirk for skipping loading platform certs on T2 Macs. Currently users get: ------------[ cut here ]------------ [Firmware Bug]: Page fault caused by firmware at PA: 0xffffa30640054000 WARNING: CPU: 1 PID: 8 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x55/0xe0 Modules linked in: CPU: 1 PID: 8 Comm: kworker/u12:0 Not tainted 5.18.14-arch1-2-t2 #1 4535eb3fc40fd08edab32a509fbf4c9bc52d111e Hardware name: Apple Inc. Macmini8,1/Mac-7BA5B2DFE22DDD8C, BIOS 1731.120.10.0.0 (iBridge: 19.16.15071.0.0,0) 04/24/2022 Workqueue: efi_rts_wq efi_call_rts ... ---[ end trace 0000000000000000 ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list Fixes: 155ca952c7ca ("efi: Do not import certificates from UEFI Secure Boot for T2 Macs") Cc: stable@vger.kernel.org Cc: Aditya Garg Tested-by: Samuel Jiang Signed-off-by: Orlando Chamberlain Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit a0d53923bf91f0d787a062b6c8c7c9c4349e5ebc Author: Takashi Iwai Date: Thu Sep 29 08:14:55 2022 +0200 ALSA: hda/realtek: Add quirk for HP Zbook Firefly 14 G9 model commit 225f6e1bc151978041595c7d2acaded3aac41f54 upstream. HP Zbook Firefly 14 G9 model (103c:8abb) requires yet another binding with CS35L41 codec, but with a slightly different configuration. It's over spi1 instead of spi0. Create a new fixup entry for that. Cc: Link: https://lore.kernel.org/r/20220929061455.13355-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 59ac9fa0e33f9b3381665a8b17c6dd4c59d0f029 Author: Takashi Iwai Date: Sat Oct 1 16:21:24 2022 +0200 ALSA: hda: Fix position reporting on Poulsbo commit 56e696c0f0c71b77fff921fc94b58a02f0445b2c upstream. Hans reported that his Sony VAIO VPX11S1E showed the broken sound behavior at the start of the stream for a couple of seconds, and it turned out that the position_fix=1 option fixes the issue. It implies that the position reporting is inaccurate, and very likely hitting on all Poulsbo devices. The patch applies the workaround for Poulsbo generically to switch to LPIB mode instead of the default position buffer. Reported-and-tested-by: Hans de Goede Cc: Link: https://lore.kernel.org/r/3e8697e1-87c6-7a7b-d2e8-b21f1d2f181b@redhat.com Link: https://lore.kernel.org/r/20221001142124.7241-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b42a64428abe1e3e5fe323e941e5c60399a27e1e Author: Jason A. Donenfeld Date: Fri Sep 23 02:42:51 2022 +0200 random: clamp credited irq bits to maximum mixed commit e78a802a7b4febf53f2a92842f494b01062d85a8 upstream. Since the most that's mixed into the pool is sizeof(long)*2, don't credit more than that many bytes of entropy. Fixes: e3e33fc2ea7f ("random: do not use input pool from hard IRQs") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman commit e1f8820bf83f2bd0ad490a5bf4a81297551d464f Author: Jason A. Donenfeld Date: Thu Sep 8 16:14:00 2022 +0200 random: restore O_NONBLOCK support commit cd4f24ae9404fd31fc461066e57889be3b68641b upstream. Prior to 5.6, when /dev/random was opened with O_NONBLOCK, it would return -EAGAIN if there was no entropy. When the pools were unified in 5.6, this was lost. The post 5.6 behavior of blocking until the pool is initialized, and ignoring O_NONBLOCK in the process, went unnoticed, with no reports about the regression received for two and a half years. However, eventually this indeed did break somebody's userspace. So we restore the old behavior, by returning -EAGAIN if the pool is not initialized. Unlike the old /dev/random, this can only occur during early boot, after which it never blocks again. In order to make this O_NONBLOCK behavior consistent with other expectations, also respect users reading with preadv2(RWF_NOWAIT) and similar. Fixes: 30c08efec888 ("random: make /dev/random be almost like /dev/urandom") Reported-by: Guozihua Reported-by: Zhongguohua Cc: Al Viro Cc: Theodore Ts'o Cc: Andrew Lutomirski Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman commit ae2e80078145c943ae5f22ada001d76864c13283 Author: Rishabh Bhatnagar Date: Tue Sep 20 19:19:32 2022 +0000 nvme-pci: set min_align_mask before calculating max_hw_sectors commit 61ce339f19fabbc3e51237148a7ef6f2270e44fa upstream. If swiotlb is force enabled dma_max_mapping_size ends up calling swiotlb_max_mapping_size which takes into account the min align mask for the device. Set the min align mask for nvme driver before calling dma_max_mapping_size while calculating max hw sectors. Signed-off-by: Rishabh Bhatnagar Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 6c58865f1acdbe460798ea78931fc868632eef88 Author: Hu Weiwen Date: Fri Jul 1 10:52:27 2022 +0800 ceph: don't truncate file in atomic_open commit 7cb9994754f8a36ae9e5ec4597c5c4c2d6c03832 upstream. Clear O_TRUNC from the flags sent in the MDS create request. `atomic_open' is called before permission check. We should not do any modification to the file here. The caller will do the truncation afterward. Fixes: 124e68e74099 ("ceph: file operations") Signed-off-by: Hu Weiwen Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov [Xiubo: fixed a trivial conflict for 5.19 backport] Signed-off-by: Xiubo Li Signed-off-by: Greg Kroah-Hartman commit 090fcfb6edeb9367a915b2749e2bd1f8b48d8898 Author: Ryusuke Konishi Date: Thu Sep 29 21:33:30 2022 +0900 nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failure commit 723ac751208f6d6540191689cfbf6c77135a7a1b upstream. If creation or finalization of a checkpoint fails due to anomalies in the checkpoint metadata on disk, a kernel warning is generated. This patch replaces the WARN_ONs by nilfs_error, so that a kernel, booted with panic_on_warn, does not panic. A nilfs_error is appropriate here to handle the abnormal filesystem condition. This also replaces the detected error codes with an I/O error so that neither of the internal error codes is returned to callers. Link: https://lkml.kernel.org/r/20220929123330.19658-1-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi Reported-by: syzbot+fbb3e0b24e8dae5a16ee@syzkaller.appspotmail.com Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4755fcd844240857b525f6e8d8b65ee140fe9570 Author: Ryusuke Konishi Date: Fri Oct 7 17:52:26 2022 +0900 nilfs2: fix leak of nilfs_root in case of writer thread creation failure commit d0d51a97063db4704a5ef6bc978dddab1636a306 upstream. If nilfs_attach_log_writer() failed to create a log writer thread, it frees a data structure of the log writer without any cleanup. After commit e912a5b66837 ("nilfs2: use root object to get ifile"), this causes a leak of struct nilfs_root, which started to leak an ifile metadata inode and a kobject on that struct. In addition, if the kernel is booted with panic_on_warn, the above ifile metadata inode leak will cause the following panic when the nilfs2 kernel module is removed: kmem_cache_destroy nilfs2_inode_cache: Slab cache still has objects when called from nilfs_destroy_cachep+0x16/0x3a [nilfs2] WARNING: CPU: 8 PID: 1464 at mm/slab_common.c:494 kmem_cache_destroy+0x138/0x140 ... RIP: 0010:kmem_cache_destroy+0x138/0x140 Code: 00 20 00 00 e8 a9 55 d8 ff e9 76 ff ff ff 48 8b 53 60 48 c7 c6 20 70 65 86 48 c7 c7 d8 69 9c 86 48 8b 4c 24 28 e8 ef 71 c7 00 <0f> 0b e9 53 ff ff ff c3 48 81 ff ff 0f 00 00 77 03 31 c0 c3 53 48 ... Call Trace: ? nilfs_palloc_freev.cold.24+0x58/0x58 [nilfs2] nilfs_destroy_cachep+0x16/0x3a [nilfs2] exit_nilfs_fs+0xa/0x1b [nilfs2] __x64_sys_delete_module+0x1d9/0x3a0 ? __sanitizer_cov_trace_pc+0x1a/0x50 ? syscall_trace_enter.isra.19+0x119/0x190 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... Kernel panic - not syncing: panic_on_warn set ... This patch fixes these issues by calling nilfs_detach_log_writer() cleanup function if spawning the log writer thread fails. Link: https://lkml.kernel.org/r/20221007085226.57667-1-konishi.ryusuke@gmail.com Fixes: e912a5b66837 ("nilfs2: use root object to get ifile") Signed-off-by: Ryusuke Konishi Reported-by: syzbot+7381dc4ad60658ca4c05@syzkaller.appspotmail.com Tested-by: Ryusuke Konishi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 394b2571e9a74ddaed55aa9c4d0f5772f81c21e4 Author: Ryusuke Konishi Date: Tue Oct 4 00:05:19 2022 +0900 nilfs2: fix use-after-free bug of struct nilfs_root commit d325dc6eb763c10f591c239550b8c7e5466a5d09 upstream. If the beginning of the inode bitmap area is corrupted on disk, an inode with the same inode number as the root inode can be allocated and fail soon after. In this case, the subsequent call to nilfs_clear_inode() on that bogus root inode will wrongly decrement the reference counter of struct nilfs_root, and this will erroneously free struct nilfs_root, causing kernel oopses. This fixes the problem by changing nilfs_new_inode() to skip reserved inode numbers while repairing the inode bitmap. Link: https://lkml.kernel.org/r/20221003150519.39789-1-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi Reported-by: syzbot+b8c672b0e22615c80fe0@syzkaller.appspotmail.com Reported-by: Khalid Masum Tested-by: Ryusuke Konishi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit caf2c6b580433b3d3e413a3d54b8414a94725dcd Author: Ryusuke Konishi Date: Sun Oct 2 12:08:04 2022 +0900 nilfs2: fix NULL pointer dereference at nilfs_bmap_lookup_at_level() commit 21a87d88c2253350e115029f14fe2a10a7e6c856 upstream. If the i_mode field in inode of metadata files is corrupted on disk, it can cause the initialization of bmap structure, which should have been called from nilfs_read_inode_common(), not to be called. This causes a lockdep warning followed by a NULL pointer dereference at nilfs_bmap_lookup_at_level(). This patch fixes these issues by adding a missing sanitiy check for the i_mode field of metadata file's inode. Link: https://lkml.kernel.org/r/20221002030804.29978-1-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi Reported-by: syzbot+2b32eb36c1a825b7a74c@syzkaller.appspotmail.com Reported-by: Tetsuo Handa Tested-by: Ryusuke Konishi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman