commit 2ced7518a03d002284999ed8336ffac462a358ec Author: Greg Kroah-Hartman Date: Thu Jul 11 12:49:22 2024 +0200 Linux 6.6.39 Link: https://lore.kernel.org/r/20240709110658.146853929@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Kelsey Steele Tested-by: Peter Schneider  Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: kernelci.org bot Tested-by: Pascal Ernster Tested-by: Harshit Mogalapalli Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Takeshi Ogasawara Signed-off-by: Greg Kroah-Hartman commit 95b1362540b70057acb1bdcf3e265f97ab156fec Author: Ryusuke Konishi Date: Sun Jun 23 14:11:35 2024 +0900 nilfs2: fix incorrect inode allocation from reserved inodes commit 93aef9eda1cea9e84ab2453fcceb8addad0e46f1 upstream. If the bitmap block that manages the inode allocation status is corrupted, nilfs_ifile_create_inode() may allocate a new inode from the reserved inode area where it should not be allocated. Previous fix commit d325dc6eb763 ("nilfs2: fix use-after-free bug of struct nilfs_root"), fixed the problem that reserved inodes with inode numbers less than NILFS_USER_INO (=11) were incorrectly reallocated due to bitmap corruption, but since the start number of non-reserved inodes is read from the super block and may change, in which case inode allocation may occur from the extended reserved inode area. If that happens, access to that inode will cause an IO error, causing the file system to degrade to an error state. Fix this potential issue by adding a wraparound option to the common metadata object allocation routine and by modifying nilfs_ifile_create_inode() to disable the option so that it only allocates inodes with inode numbers greater than or equal to the inode number read in "nilfs->ns_first_ino", regardless of the bitmap status of reserved inodes. Link: https://lkml.kernel.org/r/20240623051135.4180-4-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi Cc: Hillf Danton Cc: Jan Kara Cc: Matthew Wilcox (Oracle) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9ac895a881b2c18ee0538eea73c8aee9a86d5957 Author: Damien Le Moal Date: Thu May 30 14:40:32 2024 +0900 null_blk: Do not allow runt zone with zone capacity smaller then zone size [ Upstream commit b164316808ec5de391c3e7b0148ec937d32d280d ] A zoned device with a smaller last zone together with a zone capacity smaller than the zone size does make any sense as that does not correspond to any possible setup for a real device: 1) For ZNS and zoned UFS devices, all zones are always the same size. 2) For SMR HDDs, all zones always have the same capacity. In other words, if we have a smaller last runt zone, then this zone capacity should always be equal to the zone size. Add a check in null_init_zoned_dev() to prevent a configuration to have both a smaller zone size and a zone capacity smaller than the zone size. Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Reviewed-by: Bart Van Assche Link: https://lore.kernel.org/r/20240530054035.491497-2-dlemoal@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1ba66b121100862fc208848264821a788a79317f Author: Alex Deucher Date: Thu May 16 09:51:26 2024 -0400 drm/amdgpu: silence UBSAN warning [ Upstream commit 05d9e24ddb15160164ba6e917a88c00907dc2434 ] Convert a variable sized array from [1] to []. Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 49458c09755e05f6d706f6a2b8cb9ac6072f4994 Author: Takashi Iwai Date: Wed May 29 18:47:17 2024 +0200 ALSA: ump: Set default protocol when not given explicitly [ Upstream commit bc42ca002d5d211f9c57334b9b4c25ddb0b4ec35 ] When an inquiry of the current protocol via UMP Stream Configuration message fails by some reason, we may leave the current protocol undefined, which may lead to unexpected behavior. Better to assume a valid protocol found in the protocol capability bits instead. For a device that doesn't support the UMP v1.2 feature, it won't reach to this code path, and USB MIDI GTB descriptor would be used for determining the protocol, instead. Link: https://lore.kernel.org/r/20240529164723.18309-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d4b55b137965ab419da085b1790e0e86dcb2aa7b Author: Witold Sadowski Date: Wed May 29 00:40:32 2024 -0700 spi: cadence: Ensure data lines set to low during dummy-cycle period [ Upstream commit 4a69c1264ff41bc5bf7c03101ada0454fbf08868 ] During dummy-cycles xSPI will switch GPIO into Hi-Z mode. In that dummy period voltage on data lines will slowly drop, what can cause unintentional modebyte transmission. Value send to SPI memory chip will depend on last address, and clock frequency. To prevent unforeseen consequences of that behaviour, force send single modebyte(0x00). Modebyte will be send only if number of dummy-cycles is not equal to 0. Code must also reduce dummycycle byte count by one - as one byte is send as modebyte. Signed-off-by: Witold Sadowski Link: https://msgid.link/r/20240529074037.1345882-2-wsadowski@marvell.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 056478b4321b36ca33567089d39ac992f6c9c37a Author: Edward Adam Davis Date: Tue May 28 11:12:31 2024 +0800 nfc/nci: Add the inconsistency check between the input data length and count [ Upstream commit 068648aab72c9ba7b0597354ef4d81ffaac7b979 ] write$nci(r0, &(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf) Syzbot constructed a write() call with a data length of 3 bytes but a count value of 15, which passed too little data to meet the basic requirements of the function nci_rf_intf_activated_ntf_packet(). Therefore, increasing the comparison between data length and count value to avoid problems caused by inconsistent data length and count. Reported-and-tested-by: syzbot+71bfed2b2bcea46c98f2@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9db55f64386db843f02a484f06b9527b6ed36c47 Author: Masahiro Yamada Date: Mon May 20 21:42:11 2024 +0900 kbuild: fix short log for AS in link-vmlinux.sh [ Upstream commit 3430f65d6130ccbc86f0ff45642eeb9e2032a600 ] In convention, short logs print the output file, not the input file. Let's change the suffix for 'AS' since it assembles *.S into *.o. [Before] LD .tmp_vmlinux.kallsyms1 NM .tmp_vmlinux.kallsyms1.syms KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.S LD .tmp_vmlinux.kallsyms2 NM .tmp_vmlinux.kallsyms2.syms KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.S LD vmlinux [After] LD .tmp_vmlinux.kallsyms1 NM .tmp_vmlinux.kallsyms1.syms KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.o LD .tmp_vmlinux.kallsyms2 NM .tmp_vmlinux.kallsyms2.syms KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.o LD vmlinux Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 5502c1f1d0d7472706cc1f201aecf1c935d302d1 Author: Sagi Grimberg Date: Mon May 27 22:38:52 2024 +0300 nvmet: fix a possible leak when destroy a ctrl during qp establishment [ Upstream commit c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4 ] In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl. Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that. This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window. Reported-by: Alex Turin Signed-off-by: Sagi Grimberg Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit f61cea47ad6fc870b1f2850454c228bf12834fe7 Author: hmtheboy154 Date: Mon May 27 11:14:47 2024 +0200 platform/x86: touchscreen_dmi: Add info for the EZpad 6s Pro [ Upstream commit 3050052613790e75b5e4a8536930426b0a8b0774 ] The "EZpad 6s Pro" uses the same touchscreen as the "EZpad 6 Pro B", unlike the "Ezpad 6 Pro" which has its own touchscreen. Signed-off-by: hmtheboy154 Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20240527091447.248849-3-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 487dc376a83ca7e88022d84d321598323df7dd92 Author: hmtheboy154 Date: Mon May 27 11:14:46 2024 +0200 platform/x86: touchscreen_dmi: Add info for GlobalSpace SolT IVW 11.6" tablet [ Upstream commit 7c8639aa41343fd7b3dbe09baf6b0791fcc407a1 ] This is a tablet created by GlobalSpace Technologies Limited which uses an Intel Atom x5-Z8300, 4GB of RAM & 64GB of storage. Link: https://web.archive.org/web/20171102141952/http://globalspace.in/11.6-device.html Signed-off-by: hmtheboy154 Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20240527091447.248849-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit fc525ed8cb0fb35e568dd3ef815be443a6959993 Author: Jim Wylder Date: Thu May 23 16:14:36 2024 -0500 regmap-i2c: Subtract reg size from max_write [ Upstream commit 611b7eb19d0a305d4de00280e4a71a1b15c507fc ] Currently, when an adapter defines a max_write_len quirk, the data will be chunked into data sizes equal to the max_write_len quirk value. But the payload will be increased by the size of the register address before transmission. The resulting value always ends up larger than the limit set by the quirk. Avoid this error by setting regmap's max_write to the quirk's max_write_len minus the number of bytes for the register and padding. This allows the chunking to work correctly for this limited case without impacting other use-cases. Signed-off-by: Jim Wylder Link: https://msgid.link/r/20240523211437.2839942-1-jwylder@google.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b955b47905ed22e447b1958cfc0637ef8de7a657 Author: Kundan Kumar Date: Thu May 23 17:01:49 2024 +0530 nvme: adjust multiples of NVME_CTRL_PAGE_SIZE in offset [ Upstream commit 1bd293fcf3af84674e82ed022c049491f3768840 ] bio_vec start offset may be relatively large particularly when large folio gets added to the bio. A bigger offset will result in avoiding the single-segment mapping optimization and end up using expensive mempool_alloc further. Rather than using absolute value, adjust bv_offset by NVME_CTRL_PAGE_SIZE while checking if segment can be fitted into one/two PRP entries. Suggested-by: Christoph Hellwig Signed-off-by: Kundan Kumar Reviewed-by: Sagi Grimberg Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 9258d795978f398ecf2d222a8388cff81d37d34d Author: Matt Jan Date: Tue May 14 12:10:46 2024 +0800 connector: Fix invalid conversion in cn_proc.h [ Upstream commit 06e785aeb9ea8a43d0a3967c1ba6e69d758e82d4 ] The implicit conversion from unsigned int to enum proc_cn_event is invalid, so explicitly cast it for compilation in a C++ compiler. /usr/include/linux/cn_proc.h: In function 'proc_cn_event valid_event(proc_cn_event)': /usr/include/linux/cn_proc.h:72:17: error: invalid conversion from 'unsigned int' to 'proc_cn_event' [-fpermissive] 72 | ev_type &= PROC_EVENT_ALL; | ^ | | | unsigned int Signed-off-by: Matt Jan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 39d31edcf95a5d307024a2077740b2a0d0f28dab Author: Fedor Pchelkin Date: Sat May 4 14:47:02 2024 +0300 dma-mapping: benchmark: avoid needless copy_to_user if benchmark fails [ Upstream commit f7c9ccaadffd13066353332c13d7e9bf73b8f92d ] If do_map_benchmark() has failed, there is nothing useful to copy back to userspace. Suggested-by: Barry Song <21cnbao@gmail.com> Signed-off-by: Fedor Pchelkin Acked-by: Robin Murphy Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e6e1eda06b70d087230ffaa4a904c3e8d6ece87d Author: Nilay Shroff Date: Thu May 16 17:43:51 2024 +0530 nvme-multipath: find NUMA path only for online numa-node [ Upstream commit d3a043733f25d743f3aa617c7f82dbcb5ee2211a ] In current native multipath design when a shared namespace is created, we loop through each possible numa-node, calculate the NUMA distance of that node from each nvme controller and then cache the optimal IO path for future reference while sending IO. The issue with this design is that we may refer to the NUMA distance table for an offline node which may not be populated at the time and so we may inadvertently end up finding and caching a non-optimal path for IO. Then latter when the corresponding numa-node becomes online and hence the NUMA distance table entry for that node is created, ideally we should re-calculate the multipath node distance for the newly added node however that doesn't happen unless we rescan/reset the controller. So essentially, we may keep using non-optimal IO path for a node which is made online after namespace is created. This patch helps fix this issue ensuring that when a shared namespace is created, we calculate the multipath node distance for each online numa-node instead of each possible numa-node. Then latter when a node becomes online and we receive any IO on that newly added node, we would calculate the multipath node distance for newly added node but this time NUMA distance table would have been already populated for newly added node. Hence we would be able to correctly calculate the multipath node distance and choose the optimal path for the IO. Signed-off-by: Nilay Shroff Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 8f174c5db1e04a67a66b5535f5d0403ea823a44f Author: Mike Christie Date: Fri Mar 15 19:46:59 2024 -0500 vhost-scsi: Handle vhost_vq_work_queue failures for events [ Upstream commit b1b2ce58ed23c5d56e0ab299a5271ac01f95b75c ] Currently, we can try to queue an event's work before the vhost_task is created. When this happens we just drop it in vhost_scsi_do_plug before even calling vhost_vq_work_queue. During a device shutdown we do the same thing after vhost_scsi_clear_endpoint has cleared the backends. In the next patches we will be able to kill the vhost_task before we have cleared the endpoint. In that case, vhost_vq_work_queue can fail and we will leak the event's memory. This has handle the failure by just freeing the event. This is safe to do, because vhost_vq_work_queue will only return failure for us when the vhost_task is killed and so userspace will not be able to handle events if we sent them. Signed-off-by: Mike Christie Message-Id: <20240316004707.45557-2-michael.christie@oracle.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 4d1de71e630bbdce7d79d0dd61cecfe226bd20c4 Author: Jian-Hong Pan Date: Mon May 20 13:50:09 2024 +0800 ALSA: hda/realtek: Enable headset mic of JP-IK LEAP W502 with ALC897 [ Upstream commit 45e37f9ce28d248470bab4376df2687a215d1b22 ] JP-IK LEAP W502 laptop's headset mic is not enabled until ALC897_FIXUP_HEADSET_MIC_PIN3 quirk is applied. Here is the original pin node values: 0x11 0x40000000 0x12 0xb7a60130 0x14 0x90170110 0x15 0x411111f0 0x16 0x411111f0 0x17 0x411111f0 0x18 0x411111f0 0x19 0x411111f0 0x1a 0x411111f0 0x1b 0x03211020 0x1c 0x411111f0 0x1d 0x4026892d 0x1e 0x411111f0 0x1f 0x411111f0 Signed-off-by: Jian-Hong Pan Link: https://lore.kernel.org/r/20240520055008.7083-2-jhp@endlessos.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit aa8b1d6073c14b9dbf2dea2b3f11dc7d721a9e29 Author: Konstantin Komarov Date: Mon Apr 22 17:18:51 2024 +0300 fs/ntfs3: Mark volume as dirty if xattr is broken [ Upstream commit 24f6f5020b0b2c89c2cba5ec224547be95f753ee ] Mark a volume as corrupted if the name length exceeds the space occupied by ea. Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 92e494a7568b60ae80d57fc0deafcaf3a4029ab3 Author: Piotr Wojtaszczyk Date: Fri Jun 28 17:25:42 2024 +0200 i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr [ Upstream commit f63b94be6942ba82c55343e196bd09b53227618e ] When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether. Fixes: 41561f28e76a ("i2c: New Philips PNX bus driver") Signed-off-by: Piotr Wojtaszczyk Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit 3aeea9e1277c6e84c8edb9a328d1901234122d3e Author: Pin-yen Lin Date: Thu Jun 13 20:02:28 2024 +0800 clk: mediatek: mt8183: Only enable runtime PM on mt8183-mfgcfg [ Upstream commit 878e845d8db04df9ff3bbbaac09d335b24153704 ] Commit 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers during probe") enabled runtime PM for all mediatek clock controllers, but this introduced an issue on the resume path. If a device resumes earlier than the clock controller and calls clk_prepare() when runtime PM is enabled on the controller, it will end up calling clk_pm_runtime_get(). But the subsequent pm_runtime_resume_and_get() call will fail because the runtime PM is temporarily disabled during suspend. To workaround this, introduce a need_runtime_pm flag and only enable it on mt8183-mfgcfg, which is the driver that observed deadlock previously. Hopefully mt8183-cfgcfg won't run into the issue at the resume stage because the GPU should have stopped rendering before the system calls suspend. Fixes: 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers during probe") Signed-off-by: Pin-yen Lin Link: https://lore.kernel.org/r/20240613120357.1043342-1-treapking@chromium.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 66b6da0cc64c5b805f54a654dc29a732b092d2f0 Author: Gabor Juhos Date: Wed May 8 22:34:14 2024 +0200 clk: qcom: clk-alpha-pll: set ALPHA_EN bit for Stromer Plus PLLs [ Upstream commit 5a33a64524e6381c399e5e42571d9363ffc0bed4 ] The clk_alpha_pll_stromer_plus_set_rate() function does not sets the ALPHA_EN bit in the USER_CTL register, so setting rates which requires using alpha mode works only if the bit gets set already prior calling the function. Extend the function to set the ALPHA_EN bit in order to allow using fractional rates regardless whether the bit gets set previously or not. Fixes: 84da48921a97 ("clk: qcom: clk-alpha-pll: introduce stromer plus ops") Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/r/20240508-stromer-plus-alpha-en-v1-1-6639ce01ca5b@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0fcb94e0ee89770c794eb5405b13284e4bb72d91 Author: Luca Weiss Date: Wed May 8 10:12:53 2024 +0200 clk: qcom: gcc-sm6350: Fix gpll6* & gpll7 parents [ Upstream commit 3414f41a13eb41db15c558fbc695466203dca4fa ] Both gpll6 and gpll7 are parented to CXO at 19.2 MHz and not to GPLL0 which runs at 600 MHz. Also gpll6_out_even should have the parent gpll6 and not gpll0. Adjust the parents of these clocks to make Linux report the correct rate and not absurd numbers like gpll7 at ~25 GHz or gpll6 at 24 GHz. Corrected rates are the following: gpll7 807999902 Hz gpll6 768000000 Hz gpll6_out_even 384000000 Hz gpll0 600000000 Hz gpll0_out_odd 200000000 Hz gpll0_out_even 300000000 Hz And because gpll6 is the parent of gcc_sdcc2_apps_clk_src (at 202 MHz) that clock also reports the correct rate now and avoids this warning: [ 5.984062] mmc0: Card appears overclocked; req 202000000 Hz, actual 6312499237 Hz Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver") Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20240508-sm6350-gpll-fix-v1-1-e4ea34284a6d@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 583bea0902a90f664328b980ba09e35a718236ff Author: Mauro Carvalho Chehab Date: Mon Apr 29 15:15:05 2024 +0100 media: dw2102: fix a potential buffer overflow commit 1c73d0b29d04bf4082e7beb6a508895e118ee30d upstream. As pointed by smatch: drivers/media/usb/dvb-usb/dw2102.c:802 su3000_i2c_transfer() error: __builtin_memcpy() '&state->data[4]' too small (64 vs 67) That seemss to be due to a wrong copy-and-paste. Fixes: 0e148a522b84 ("media: dw2102: Don't translate i2c read into write") Reported-by: Hans Verkuil Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 28d0ecc52f6c927d0e9ba70a4f2c1ea15453ee88 Author: GUO Zihua Date: Tue May 7 01:25:41 2024 +0000 ima: Avoid blocking in RCU read-side critical section commit 9a95c5bfbf02a0a7f5983280fe284a0ff0836c34 upstream. A panic happens in ima_match_policy: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 42f873067 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: loaded Tainted: P Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ima_match_policy+0x84/0x450 Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f RSP: 0018:ff71570009e07a80 EFLAGS: 00010207 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200 RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739 R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970 R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001 FS: 00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ima_get_action+0x22/0x30 process_measurement+0xb0/0x830 ? page_add_file_rmap+0x15/0x170 ? alloc_set_pte+0x269/0x4c0 ? prep_new_page+0x81/0x140 ? simple_xattr_get+0x75/0xa0 ? selinux_file_open+0x9d/0xf0 ima_file_check+0x64/0x90 path_openat+0x571/0x1720 do_filp_open+0x9b/0x110 ? page_counter_try_charge+0x57/0xc0 ? files_cgroup_alloc_fd+0x38/0x60 ? __alloc_fd+0xd4/0x250 ? do_sys_open+0x1bd/0x250 do_sys_open+0x1bd/0x250 do_syscall_64+0x5d/0x1d0 entry_SYSCALL_64_after_hwframe+0x65/0xca Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a RCU read-side critical section which contains kmalloc with GFP_KERNEL. This implies a possible sleep and violates limitations of RCU read-side critical sections on non-PREEMPT systems. Sleeping within RCU read-side critical section might cause synchronize_rcu() returning early and break RCU protection, allowing a UAF to happen. The root cause of this issue could be described as follows: | Thread A | Thread B | | |ima_match_policy | | | rcu_read_lock | |ima_lsm_update_rule | | | synchronize_rcu | | | | kmalloc(GFP_KERNEL)| | | sleep | ==> synchronize_rcu returns early | kfree(entry) | | | | entry = entry->next| ==> UAF happens and entry now becomes NULL (or could be anything). | | entry->action | ==> Accessing entry might cause panic. To fix this issue, we are converting all kmalloc that is called within RCU read-side critical section to use GFP_ATOMIC. Fixes: c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()") Cc: stable@vger.kernel.org Signed-off-by: GUO Zihua Acked-by: John Johansen Reviewed-by: Mimi Zohar Reviewed-by: Casey Schaufler [PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case] Signed-off-by: Paul Moore Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit cecffd9e3c46c0e93917caa50286e2c57a5ece2a Author: Dragan Simic Date: Mon May 20 19:20:28 2024 +0200 arm64: dts: rockchip: Fix the DCDC_REG2 minimum voltage on Quartz64 Model B commit d201c92bff90f3d3d0b079fc955378c15c0483cc upstream. Correct the specified regulator-min-microvolt value for the buck DCDC_REG2 regulator, which is part of the Rockchip RK809 PMIC, in the Pine64 Quartz64 Model B board dts. According to the RK809 datasheet, version 1.01, this regulator is capable of producing voltages as low as 0.5 V on its output, instead of going down to 0.9 V only, which is additionally confirmed by the regulator-min-microvolt values found in the board dts files for the other supported boards that use the same RK809 PMIC. This allows the DVFS to clock the GPU on the Quartz64 Model B below 700 MHz, all the way down to 200 MHz, which saves some power and reduces the amount of generated heat a bit, improving the thermal headroom and possibly improving the bursty CPU and GPU performance on this board. This also eliminates the following warnings in the kernel log: core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (200000000) core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (300000000) core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (400000000) core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (600000000) Fixes: dcc8c66bef79 ("arm64: dts: rockchip: add Pine64 Quartz64-B device tree") Cc: stable@vger.kernel.org Reported-By: Diederik de Haas Signed-off-by: Dragan Simic Tested-by: Diederik de Haas Link: https://lore.kernel.org/r/e70742ea2df432bf57b3f7de542d81ca22b0da2f.1716225483.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit f1313ea92f82451923e28ab45a4aaa0e70e80b98 Author: Ghadi Elie Rahme Date: Thu Jun 27 14:14:05 2024 +0300 bnx2x: Fix multiple UBSAN array-index-out-of-bounds commit 134061163ee5ca4759de5c24ca3bd71608891ba7 upstream. Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter. Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array: struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX]; FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if it is not. This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FP_SB_MAX_E1x. Below is the part of this explanation that it important for this patch /* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. */ However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FP_SB_MAX_E2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "stats_query_entry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below. This patch increases the size of the "stats_query_entry query" array by replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle both types of NICs. Stack traces: UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11 index 20 is out of range for type 'stats_query_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 10/21/2019 Call Trace: dump_stack_lvl+0x76/0xa0 dump_stack+0x10/0x20 __ubsan_handle_out_of_bounds+0xcb/0x110 bnx2x_prep_fw_stats_req+0x2e1/0x310 [bnx2x] bnx2x_stats_init+0x156/0x320 [bnx2x] bnx2x_post_irq_nic_init+0x81/0x1a0 [bnx2x] bnx2x_nic_load+0x8e8/0x19e0 [bnx2x] bnx2x_open+0x16b/0x290 [bnx2x] __dev_open+0x10e/0x1d0 RIP: 0033:0x736223927a0a Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc0bb2ada8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000583df50f9c78 RCX: 0000736223927a0a RDX: 0000000000000020 RSI: 0000583df50ee510 RDI: 0000000000000003 RBP: 0000583df50d4940 R08: 00007ffc0bb2adb0 R09: 0000000000000080 R10: 0000000000000000 R11: 0000000000000246 R12: 0000583df5103ae0 R13: 000000000000035a R14: 0000583df50f9c30 R15: 0000583ddddddf00 ---[ end trace ]--- ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1546:11 index 28 is out of range for type 'stats_query_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 10/21/2019 Call Trace: dump_stack_lvl+0x76/0xa0 dump_stack+0x10/0x20 __ubsan_handle_out_of_bounds+0xcb/0x110 bnx2x_prep_fw_stats_req+0x2fd/0x310 [bnx2x] bnx2x_stats_init+0x156/0x320 [bnx2x] bnx2x_post_irq_nic_init+0x81/0x1a0 [bnx2x] bnx2x_nic_load+0x8e8/0x19e0 [bnx2x] bnx2x_open+0x16b/0x290 [bnx2x] __dev_open+0x10e/0x1d0 RIP: 0033:0x736223927a0a Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc0bb2ada8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000583df50f9c78 RCX: 0000736223927a0a RDX: 0000000000000020 RSI: 0000583df50ee510 RDI: 0000000000000003 RBP: 0000583df50d4940 R08: 00007ffc0bb2adb0 R09: 0000000000000080 R10: 0000000000000000 R11: 0000000000000246 R12: 0000583df5103ae0 R13: 000000000000035a R14: 0000583df50f9c30 R15: 0000583ddddddf00 ---[ end trace ]--- ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1895:8 index 29 is out of range for type 'stats_query_entry [19]' CPU: 13 PID: 163 Comm: kworker/u96:1 Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 10/21/2019 Workqueue: bnx2x bnx2x_sp_task [bnx2x] Call Trace: dump_stack_lvl+0x76/0xa0 dump_stack+0x10/0x20 __ubsan_handle_out_of_bounds+0xcb/0x110 bnx2x_iov_adjust_stats_req+0x3c4/0x3d0 [bnx2x] bnx2x_storm_stats_post.part.0+0x4a/0x330 [bnx2x] ? bnx2x_hw_stats_post+0x231/0x250 [bnx2x] bnx2x_stats_start+0x44/0x70 [bnx2x] bnx2x_stats_handle+0x149/0x350 [bnx2x] bnx2x_attn_int_asserted+0x998/0x9b0 [bnx2x] bnx2x_sp_task+0x491/0x5c0 [bnx2x] process_one_work+0x18d/0x3f0 ---[ end trace ]--- Fixes: 50f0a562f8cc ("bnx2x: add fcoe statistics") Signed-off-by: Ghadi Elie Rahme Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20240627111405.1037812-1-ghadi.rahme@canonical.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7a8b1cfcb25bfd7ff5ceca9759736356cee451de Author: Yijie Yang Date: Mon Jul 1 09:47:20 2024 +0800 net: stmmac: dwmac-qcom-ethqos: fix error array size commit b698ab56837bc9e666b7e7e12e9c28fe1d6a763c upstream. Correct member @num_por with size of right array @emac_v4_0_0_por for struct ethqos_emac_driver_data @emac_v4_0_0_data. Cc: stable@vger.kernel.org Fixes: 8c4d92e82d50 ("net: stmmac: dwmac-qcom-ethqos: add support for emac4 on sa8775p platforms") Signed-off-by: Yijie Yang Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20240701014720.2547856-1-quic_yijiyang@quicinc.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 45a4aef063551ed0c7e3fdfa1815c9b241bc2386 Author: Val Packett Date: Sun May 19 00:13:39 2024 -0300 mtd: rawnand: rockchip: ensure NVDDR timings are rejected commit b27d8946b5edd9827ee3c2f9ea1dd30022fb1ebe upstream. .setup_interface first gets called with a "target" value of NAND_DATA_IFACE_CHECK_ONLY, in which case an error is expected if the controller driver does not support the timing mode (NVDDR). Fixes: a9ecc8c814e9 ("mtd: rawnand: Choose the best timings, NV-DDR included") Signed-off-by: Val Packett Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240519031409.26464-1-val@packett.cool Signed-off-by: Greg Kroah-Hartman commit dbbc4cf0d5c1c7909fb70a263c111044e14a6a50 Author: Miquel Raynal Date: Thu May 16 15:13:20 2024 +0200 mtd: rawnand: Bypass a couple of sanity checks during NAND identification commit 8754d9835683e8fab9a8305acdb38a3aeb9d20bd upstream. Early during NAND identification, mtd_info fields have not yet been initialized (namely, writesize and oobsize) and thus cannot be used for sanity checks yet. Of course if there is a misuse of nand_change_read_column_op() so early we won't be warned, but there is anyway no actual check to perform at this stage as we do not yet know the NAND geometry. So, if the fields are empty, especially mtd->writesize which is *always* set quite rapidly after identification, let's skip the sanity checks. nand_change_read_column_op() is subject to be used early for ONFI/JEDEC identification in the very unlikely case of: - bitflips appearing in the parameter page, - the controller driver not supporting simple DATA_IN cycles. As nand_change_read_column_op() uses nand_fill_column_cycles() the logic explaind above also applies in this secondary helper. Fixes: c27842e7e11f ("mtd: rawnand: onfi: Adapt the parameter page read to constraint controllers") Fixes: daca31765e8b ("mtd: rawnand: jedec: Adapt the parameter page read to constraint controllers") Cc: stable@vger.kernel.org Reported-by: Alexander Dahl Closes: https://lore.kernel.org/linux-mtd/20240306-shaky-bunion-d28b65ea97d7@thorsis.com/ Reported-by: Steven Seeger Closes: https://lore.kernel.org/linux-mtd/DM6PR05MB4506554457CF95191A670BDEF7062@DM6PR05MB4506.namprd05.prod.outlook.com/ Signed-off-by: Miquel Raynal Tested-by: Sascha Hauer Link: https://lore.kernel.org/linux-mtd/20240516131320.579822-3-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 70bb95e034fd0dc1fdb4955fe5667181581d1ec9 Author: Miquel Raynal Date: Thu May 16 15:13:19 2024 +0200 mtd: rawnand: Fix the nand_read_data_op() early check commit 5da39530d19946f6241de84d1db69da2f5c61da7 upstream. The nand_read_data_op() operation, which only consists in DATA_IN cycles, is sadly not supported by all controllers despite being very basic. The core, for some time, supposed all drivers would support it. An improvement to this situation for supporting more constrained controller added a check to verify if the operation was supported before attempting it by running the function with the check_only boolean set first, and then possibly falling back to another (possibly slightly less optimized) alternative. An even newer addition moved that check very early and probe time, in order to perform the check only once. The content of the operation was not so important, as long as the controller driver would tell whether such operation on the NAND bus would be possible or not. In practice, no buffer was provided (no fake buffer or whatever) as it is anyway not relevant for the "check_only" condition. Unfortunately, early in the function, there is an if statement verifying that the input parameters are right for normal use, making the early check always unsuccessful. Fixes: 9f820fc0651c ("mtd: rawnand: Check the data only read pattern only once") Cc: stable@vger.kernel.org Reported-by: Alexander Dahl Closes: https://lore.kernel.org/linux-mtd/20240306-shaky-bunion-d28b65ea97d7@thorsis.com/ Reported-by: Steven Seeger Closes: https://lore.kernel.org/linux-mtd/DM6PR05MB4506554457CF95191A670BDEF7062@DM6PR05MB4506.namprd05.prod.outlook.com/ Signed-off-by: Miquel Raynal Reviewed-by: Alexander Dahl Link: https://lore.kernel.org/linux-mtd/20240516131320.579822-2-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 0fd8ce12f97ca9fbe32319ac921d001875080360 Author: Miquel Raynal Date: Tue May 7 10:58:42 2024 +0200 mtd: rawnand: Ensure ECC configuration is propagated to upper layers commit 3a1b777eb9fb75d09c45ae5dd1d007eddcbebf1f upstream. Until recently the "upper layer" was MTD. But following incremental reworks to bring spi-nand support and more recently generic ECC support, there is now an intermediate "generic NAND" layer that also needs to get access to some values. When using "converted" ECC engines, like the software ones, these values are already propagated correctly. But otherwise when using good old raw NAND controller drivers, we need to manually set these values ourselves at the end of the "scan" operation, once these values have been negotiated. Without this propagation, later (generic) checks like the one warning users that the ECC strength is not high enough might simply no longer work. Fixes: 8c126720fe10 ("mtd: rawnand: Use the ECC framework nand_ecc_is_strong_enough() helper") Cc: stable@vger.kernel.org Reported-by: Sascha Hauer Closes: https://lore.kernel.org/all/Zhe2JtvvN1M4Ompw@pengutronix.de/ Signed-off-by: Miquel Raynal Tested-by: Sascha Hauer Link: https://lore.kernel.org/linux-mtd/20240507085842.108844-1-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit c6036baea4ba5ff6f68dcbeee4c1664f32fa479b Author: Jinglin Wen Date: Thu Jun 20 10:41:50 2024 +0800 powerpc/64s: Fix unnecessary copy to 0 when kernel is booted at address 0 commit 13fc6c175924eaa953cf597ce28ffa4edc4554a6 upstream. According to the code logic, when the kernel is loaded at address 0, no copying operation should be performed, but it is currently being done. This patch fixes the issue where the kernel code was incorrectly duplicated to address 0 when booting from address 0. Fixes: b270bebd34e3 ("powerpc/64s: Run at the kernel virtual address earlier in boot") Cc: stable@vger.kernel.org # v6.4+ Signed-off-by: Jinglin Wen Suggested-by: Michael Ellerman Signed-off-by: Michael Ellerman Link: https://msgid.link/20240620024150.14857-1-jinglin.wen@shingroup.cn Signed-off-by: Greg Kroah-Hartman commit d10e3c39001e9194b9a1bfd6979bd3fa19dccdc5 Author: Nicholas Piggin Date: Tue Jun 25 23:40:47 2024 +1000 powerpc/pseries: Fix scv instruction crash with kexec commit 21a741eb75f80397e5f7d3739e24d7d75e619011 upstream. kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel. Change the kexec sequence to disable AIL after other CPUs have been brought down. As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all. Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions") Cc: stable@vger.kernel.org # v5.9+ Reported-by: Sourabh Jain Closes: https://lore.kernel.org/3b4b2943-49ad-4619-b195-bc416f1d1409@linux.ibm.com Signed-off-by: Nicholas Piggin Tested-by: Gautam Menghani Tested-by: Sourabh Jain Link: https://msgid.link/20240625134047.298759-1-npiggin@gmail.com Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 14c78d69dbca6a28af14095f639ec4318ec07fdc Author: Frank Oltmanns Date: Sun Jun 23 10:45:58 2024 +0200 clk: sunxi-ng: common: Don't call hw_to_ccu_common on hw without common commit ea977d742507e534d9fe4f4d74256f6b7f589338 upstream. In order to set the rate range of a hw sunxi_ccu_probe calls hw_to_ccu_common() assuming all entries in desc->ccu_clks are contained in a ccu_common struct. This assumption is incorrect and, in consequence, causes invalid pointer de-references. Remove the faulty call. Instead, add one more loop that iterates over the ccu_clks and sets the rate range, if required. Fixes: b914ec33b391 ("clk: sunxi-ng: common: Support minimum and maximum rate") Reported-by: Robert J. Pafford Closes: https://lore.kernel.org/lkml/DM6PR01MB58047C810DDD5D0AE397CADFF7C22@DM6PR01MB5804.prod.exchangelabs.com/ Cc: stable@vger.kernel.org Signed-off-by: Frank Oltmanns Tested-by: Robert J. Pafford Link: https://lore.kernel.org/r/20240623-sunxi-ng_fix_common_probe-v1-1-7c97e32824a1@oltmanns.dev Signed-off-by: Chen-Yu Tsai Signed-off-by: Greg Kroah-Hartman commit ba02424852d2ad380764f37d56bfb53de8305a2f Author: Md Sadre Alam Date: Thu May 9 16:24:05 2024 +0530 clk: qcom: gcc-ipq9574: Add BRANCH_HALT_VOTED flag commit 72ceafb587a56e26c905472418c7dc2033c294d3 upstream. The crypto_ahb and crypto_axi clks are hardware voteable. This means that the halt bit isn't reliable because some other voter in the system, e.g. TrustZone, could be keeping the clk enabled when the kernel turns it off from clk_disable(). Make these clks use voting mode by changing the halt check to BRANCH_HALT_VOTED and toggle the voting bit in the voting register instead of directly controlling the branch by writing to the branch register. This fixes stuck clk warnings seen on ipq9574 and saves power by actually turning the clk off. Also changes the CRYPTO_AHB_CLK_ENA & CRYPTO_AXI_CLK_ENA offset to 0xb004 from 0x16014. Cc: stable@vger.kernel.org Fixes: f6b2bd9cb29a ("clk: qcom: gcc-ipq9574: Enable crypto clocks") Signed-off-by: Md Sadre Alam Link: https://lore.kernel.org/r/20240509105405.1262369-1-quic_mdalam@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 33de7c47a19ab1165ee2404f197de4f7e4848f23 Author: John Schoenick Date: Fri Jun 28 13:58:21 2024 -0700 drm: panel-orientation-quirks: Add quirk for Valve Galileo commit 26746ed40bb0e4ebe2b2bd61c04eaaa54e263c14 upstream. Valve's Steam Deck Galileo revision has a 800x1280 OLED panel Cc: stable@vger.kernel.org # 6.1+ Signed-off-by: John Schoenick Signed-off-by: Matthew Schwartz Signed-off-by: Hamza Mahfooz Link: https://patchwork.freedesktop.org/patch/msgid/20240628205822.348402-2-mattschwartz@gwu.edu Signed-off-by: Greg Kroah-Hartman commit 004b7fe6ca8c709e8431b400c3082040b80e59cf Author: Alex Deucher Date: Mon Jul 1 12:50:10 2024 -0400 drm/amdgpu/atomfirmware: silence UBSAN warning commit d0417264437a8fa05f894cabba5a26715b32d78e upstream. This is a variable sized array. Link: https://lists.freedesktop.org/archives/amd-gfx/2024-June/110420.html Tested-by: Jeff Layton Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 744b229f09134ccd091427a6f9ea6d97302cfdd9 Author: Ma Ke Date: Thu Jun 27 15:42:04 2024 +0800 drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes commit 80bec6825b19d95ccdfd3393cf8ec15ff2a749b4 upstream. In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable@vger.kernel.org Fixes: 6ee738610f41 ("drm/nouveau: Add DRM driver for NVIDIA GPUs") Signed-off-by: Ma Ke Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20240627074204.3023776-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit f6620df12cb6bdcad671d269debbb23573502f9d Author: Jan Kara Date: Fri Jun 21 16:42:37 2024 +0200 Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again" commit 30139c702048f1097342a31302cbd3d478f50c63 upstream. Patch series "mm: Avoid possible overflows in dirty throttling". Dirty throttling logic assumes dirty limits in page units fit into 32-bits. This patch series makes sure this is true (see patch 2/2 for more details). This patch (of 2): This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78. The commit is broken in several ways. Firstly, the removed (u64) cast from the multiplication will introduce a multiplication overflow on 32-bit archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the default settings with 4GB of RAM will trigger this). Secondly, the div64_u64() is unnecessarily expensive on 32-bit archs. We have div64_ul() in case we want to be safe & cheap. Thirdly, if dirty thresholds are larger than 1<<32 pages, then dirty balancing is going to blow up in many other spectacular ways anyway so trying to fix one possible overflow is just moot. Link: https://lkml.kernel.org/r/20240621144017.30993-1-jack@suse.cz Link: https://lkml.kernel.org/r/20240621144246.11148-1-jack@suse.cz Fixes: 9319b647902c ("mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again") Signed-off-by: Jan Kara Reviewed-By: Zach O'Keefe Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit dd0aa13fda824520da3fd980c3ed5f0628671aac Author: Jan Kara Date: Mon Jun 17 18:23:00 2024 +0200 fsnotify: Do not generate events for O_PATH file descriptors commit 702eb71fd6501b3566283f8c96d7ccc6ddd662e9 upstream. Currently we will not generate FS_OPEN events for O_PATH file descriptors but we will generate FS_CLOSE events for them. This is asymmetry is confusing. Arguably no fsnotify events should be generated for O_PATH file descriptors as they cannot be used to access or modify file content, they are just convenient handles to file objects like paths. So fix the asymmetry by stopping to generate FS_CLOSE for O_PATH file descriptors. Cc: Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20240617162303.1596-1-jack@suse.cz Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 07ce8ad4eb60fbaff499975eae523ded51daeab4 Author: Jimmy Assarsson Date: Fri Jun 28 21:45:29 2024 +0200 can: kvaser_usb: Explicitly initialize family in leafimx driver_info struct commit 19d5b2698c35b2132a355c67b4d429053804f8cc upstream. Explicitly set the 'family' driver_info struct member for leafimx. Previously, the correct operation relied on KVASER_LEAF being the first defined value in enum kvaser_usb_leaf_family. Fixes: e6c80e601053 ("can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency regression") Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20240628194529.312968-1-extja@kvaser.com Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit e2d8aa4c763593704ac21e7591aed4f13e32f3b5 Author: Zijun Hu Date: Thu May 16 21:31:34 2024 +0800 Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot commit 88e72239ead9814b886db54fc4ee39ef3c2b8f26 upstream. Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") will cause below regression issue: BT can't be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390. The commit is to fix a use-after-free issue within qca_serdev_shutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot. Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote. Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of bluetooth-next tree. commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of linus mainline tree. Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") Cc: stable@vger.kernel.org Reported-by: Wren Turkal Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726 Signed-off-by: Zijun Hu Tested-by: Wren Turkal Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit a635d93ad99b9931117d8183247384f49a0da194 Author: Hector Martin Date: Wed May 15 18:15:04 2024 +0000 Bluetooth: hci_bcm4377: Fix msgid release commit 897e6120566f1c108b85fefe78d1c1bddfbd5988 upstream. We are releasing a single msgid, so the order argument to bitmap_release_region must be zero. Fixes: 8a06127602de ("Bluetooth: hci_bcm4377: Add new driver for BCM4377 PCIe boards") Cc: stable@vger.kernel.org Signed-off-by: Hector Martin Reviewed-by: Sven Peter Reviewed-by: Neal Gompa Signed-off-by: Sven Peter Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 155d9c9ed1292b5957d9b71a041957d63ea25ebc Author: Nathan Chancellor Date: Tue May 14 13:47:23 2024 -0700 scsi: mpi3mr: Use proper format specifier in mpi3mr_sas_port_add() commit 9f365cb8bbd0162963d6852651d7c9e30adcb7b5 upstream. When building for a 32-bit platform such as ARM or i386, for which size_t is unsigned int, there is a warning due to using an unsigned long format specifier: drivers/scsi/mpi3mr/mpi3mr_transport.c:1370:11: error: format specifies type 'unsigned long' but the argument has type 'unsigned int' [-Werror,-Wformat] 1369 | ioc_warn(mrioc, "skipping port %u, max allowed value is %lu\n", | ~~~ | %u 1370 | i, sizeof(mr_sas_port->phy_mask) * 8); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Use the proper format specifier for size_t, %zu, to resolve the warning for all platforms. Fixes: 3668651def2c ("scsi: mpi3mr: Sanitise num_phys") Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20240514-mpi3mr-fix-wformat-v1-1-f1ad49217e5e@kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 72aa369e4e624b6d4e92ec236f8bbf92d86fb903 Author: Nathan Chancellor Date: Mon May 13 08:40:27 2024 -0700 f2fs: Add inline to f2fs_build_fault_attr() stub commit 0d8968287a1cf7b03d07387dc871de3861b9f6b9 upstream. When building without CONFIG_F2FS_FAULT_INJECTION, there is a warning from each file that includes f2fs.h because the stub for f2fs_build_fault_attr() is missing inline: In file included from fs/f2fs/segment.c:21: fs/f2fs/f2fs.h:4605:12: warning: 'f2fs_build_fault_attr' defined but not used [-Wunused-function] 4605 | static int f2fs_build_fault_attr(struct f2fs_sb_info *sbi, unsigned long rate, | ^~~~~~~~~~~~~~~~~~~~~ Add the missing inline to resolve all of the warnings for this configuration. Fixes: 4ed886b187f4 ("f2fs: check validation of fault attrs in f2fs_build_fault_attr()") Signed-off-by: Nathan Chancellor Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit f8e960be923f74a273c62478c9cab9523936752b Author: Naohiro Aota Date: Fri Jun 28 13:32:24 2024 +0900 btrfs: fix adding block group to a reclaim list and the unused list during reclaim commit 48f091fd50b2eb33ae5eaea9ed3c4f81603acf38 upstream. There is a potential parallel list adding for retrying in btrfs_reclaim_bgs_work and adding to the unused list. Since the block group is removed from the reclaim list and it is on a relocation work, it can be added into the unused list in parallel. When that happens, adding it to the reclaim list will corrupt the list head and trigger list corruption like below. Fix it by taking fs_info->unused_bgs_lock. [177.504][T2585409] BTRFS error (device nullb1): error relocating ch= unk 2415919104 [177.514][T2585409] list_del corruption. next->prev should be ff1100= 0344b119c0, but was ff11000377e87c70. (next=3Dff110002390cd9c0) [177.529][T2585409] ------------[ cut here ]------------ [177.537][T2585409] kernel BUG at lib/list_debug.c:65! [177.545][T2585409] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Tainted: G W 6.10.0-rc5-kts #1 [177.568][T2585409] Hardware name: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 02/14/2022 [177.579][T2585409] Workqueue: events_unbound btrfs_reclaim_bgs_work[btrfs] [177.589][T2585409] RIP: 0010:__list_del_entry_valid_or_report.cold+0x70/0x72 [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286 [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000 [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI:ffe21c006efd0f40 [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08 [177.665][T2585409] R10: ff11000377e87847 R11: 0000000000000000 R12:ff110002390cd9c0 [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000 [177.687][T2585409] FS: 0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000 [177.700][T2585409] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4:0000000000771ef0 [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000 [177.731][T2585409] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400 [177.742][T2585409] PKRU: 55555554 [177.748][T2585409] Call Trace: [177.753][T2585409] [177.759][T2585409] ? __die_body.cold+0x19/0x27 [177.766][T2585409] ? die+0x2e/0x50 [177.772][T2585409] ? do_trap+0x1ea/0x2d0 [177.779][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.788][T2585409] ? do_error_trap+0xa3/0x160 [177.795][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.805][T2585409] ? handle_invalid_op+0x2c/0x40 [177.812][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.820][T2585409] ? exc_invalid_op+0x2d/0x40 [177.827][T2585409] ? asm_exc_invalid_op+0x1a/0x20 [177.834][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.843][T2585409] btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs] There is a similar retry_list code in btrfs_delete_unused_bgs(), but it is safe, AFAICS. Since the block group was in the unused list, the used bytes should be 0 when it was added to the unused list. Then, it checks block_group->{used,reserved,pinned} are still 0 under the block_group->lock. So, they should be still eligible for the unused list, not the reclaim list. The reason it is safe there it's because because we're holding space_info->groups_sem in write mode. That means no other task can allocate from the block group, so while we are at deleted_unused_bgs() it's not possible for other tasks to allocate and deallocate extents from the block group, so it can't be added to the unused list or the reclaim list by anyone else. The bug can be reproduced by btrfs/166 after a few rounds. In practice this can be hit when relocation cannot find more chunk space and ends with ENOSPC. Reported-by: Shinichiro Kawasaki Suggested-by: Johannes Thumshirn Fixes: 4eb4e85c4f81 ("btrfs: retry block group reclaim without infinite loop") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana Reviewed-by: Johannes Thumshirn Reviewed-by: Qu Wenruo Signed-off-by: Naohiro Aota Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit bd16a7ee339aef3ee4c90cb23902afb6af379ea0 Author: Jan Kara Date: Fri Jun 21 16:42:38 2024 +0200 mm: avoid overflows in dirty throttling logic commit 385d838df280eba6c8680f9777bfa0d0bfe7e8b2 upstream. The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINT_MAX. This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB. Link: https://lkml.kernel.org/r/20240621144246.11148-2-jack@suse.cz Signed-off-by: Jan Kara Reported-by: Zach O'Keefe Reviewed-By: Zach O'Keefe Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 79ad410c5b58473d15abd83e585af3555bc8da87 Author: Jinliang Zheng Date: Thu Jun 20 20:21:24 2024 +0800 mm: optimize the redundant loop of mm_update_owner_next() commit cf3f9a593dab87a032d2b6a6fb205e7f3de4f0a1 upstream. When mm_update_owner_next() is racing with swapoff (try_to_unuse()) or /proc or ptrace or page migration (get_task_mm()), it is impossible to find an appropriate task_struct in the loop whose mm_struct is the same as the target mm_struct. If the above race condition is combined with the stress-ng-zombie and stress-ng-dup tests, such a long loop can easily cause a Hard Lockup in write_lock_irq() for tasklist_lock. Recognize this situation in advance and exit early. Link: https://lkml.kernel.org/r/20240620122123.3877432-1-alexjlzheng@tencent.com Signed-off-by: Jinliang Zheng Acked-by: Michal Hocko Cc: Christian Brauner Cc: Jens Axboe Cc: Mateusz Guzik Cc: Matthew Wilcox (Oracle) Cc: Oleg Nesterov Cc: Tycho Andersen Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3ab40870edb883b9633dc5cd55f5a2a11afa618d Author: Ryusuke Konishi Date: Sun Jun 23 14:11:34 2024 +0900 nilfs2: add missing check for inode numbers on directory entries commit bb76c6c274683c8570ad788f79d4b875bde0e458 upstream. Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn(). As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case). The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking. Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages. Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis. Link: https://lkml.kernel.org/r/20240623051135.4180-3-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi Reported-by: syzbot+d79afb004be235636ee8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d79afb004be235636ee8 Reported-by: Jan Kara Closes: https://lkml.kernel.org/r/20240617075758.wewhukbrjod5fp5o@quack3 Tested-by: Ryusuke Konishi Cc: Hillf Danton Cc: Matthew Wilcox (Oracle) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9194f8ca57527958bee207919458e372d638d783 Author: Ryusuke Konishi Date: Sun Jun 23 14:11:33 2024 +0900 nilfs2: fix inode number range checks commit e2fec219a36e0993642844be0f345513507031f4 upstream. Patch series "nilfs2: fix potential issues related to reserved inodes". This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value. This patch (of 3): In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked. As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly. In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "ns_first_ino" is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment. Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros. Also, change the type of "ns_first_ino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time. Link: https://lkml.kernel.org/r/20240623051135.4180-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20240623051135.4180-2-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi Cc: Hillf Danton Cc: Jan Kara Cc: Matthew Wilcox (Oracle) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 991f036cabc3d13e886a37faeea1b6800181fdda Author: Sasha Neftin Date: Tue Jun 11 09:24:55 2024 -0700 Revert "igc: fix a log entry using uninitialized netdev" commit 8eef5c3cea65f248c99cd9dcb3f84c6509b78162 upstream. This reverts commit 86167183a17e03ec77198897975e9fdfbd53cb0b. igc_ptp_init() needs to be called before igc_reset(), otherwise kernel crash could be observed. Following the corresponding discussion [1] and [2] revert this commit. Link: https://lore.kernel.org/all/8fb634f8-7330-4cf4-a8ce-485af9c0a61a@intel.com/ [1] Link: https://lore.kernel.org/all/87o78rmkhu.fsf@intel.com/ [2] Fixes: 86167183a17e ("igc: fix a log entry using uninitialized netdev") Signed-off-by: Sasha Neftin Tested-by: Naama Meir Signed-off-by: Tony Nguyen Link: https://lore.kernel.org/r/20240611162456.961631-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9bdd0bf23ffed3115de3ba0c3c5769fb56e799f1 Author: Armin Wolf Date: Mon Jul 1 21:45:39 2024 +0200 platform/x86: toshiba_acpi: Fix quickstart quirk handling commit e527a6127223b644e0a27b44f4b16e16eb6c7f0a upstream. The global hci_hotkey_quickstart quirk flag is tested in toshiba_acpi_enable_hotkeys() before the quirk flag is properly initialized based on SMBIOS data. This causes the quirk to be applied to all models, some of which behave erratically as a result. Fix this by initializing the global quirk flags during module initialization before registering the ACPI driver. This also allows us to mark toshiba_dmi_quirks[] as __initconst. Fixes: 23f1d8b47d12 ("platform/x86: toshiba_acpi: Add quirk for buttons on Z830") Reported-by: kemal Closes: https://lore.kernel.org/platform-driver-x86/R4CYFS.TWB8QUU2SHWI1@cock.li/ Tested-by: kemal Cc: stable@vger.kernel.org Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20240701194539.348937-1-W_Armin@gmx.de Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 69787793e7f0673465c89714d1522fde978bbfa8 Author: Huacai Chen Date: Tue Jun 18 16:13:36 2024 +0800 cpu: Fix broken cmdline "nosmp" and "maxcpus=0" commit 6ef8eb5125722c241fd60d7b0c872d5c2e5dd4ca upstream. After the rework of "Parallel CPU bringup", the cmdline "nosmp" and "maxcpus=0" parameters are not working anymore. These parameters set setup_max_cpus to zero and that's handed to bringup_nonboot_cpus(). The code there does a decrement before checking for zero, which brings it into the negative space and brings up all CPUs. Add a zero check at the beginning of the function to prevent this. [ tglx: Massaged change log ] Fixes: 18415f33e2ac4ab382 ("cpu/hotplug: Allow "parallel" bringup up to CPUHP_BP_KICK_AP_STATE") Fixes: 06c6796e0304234da6 ("cpu/hotplug: Fix off by one in cpuhp_bringup_mask()") Signed-off-by: Huacai Chen Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240618081336.3996825-1-chenhuacai@loongson.cn Signed-off-by: Greg Kroah-Hartman commit b0a41715ed23a8cc738327504c656cad745b57da Author: Dmitry Torokhov Date: Wed Jul 3 11:26:09 2024 -0700 gpiolib: of: add polarity quirk for TSC2005 [ Upstream commit f8d76c2c313c56d5cb894a243dff4550f048278d ] DTS for Nokia N900 incorrectly specifies "active high" polarity for the reset line, while the chip documentation actually specifies it as "active low". In the past the driver fudged gpiod API and inverted the logic internally, but it was changed in d0d89493bff8. Fixes: d0d89493bff8 ("Input: tsc2004/5 - switch to using generic device properties") Signed-off-by: Dmitry Torokhov Acked-by: Linus Walleij Link: https://lore.kernel.org/r/ZoWXwYtwgJIxi-hD@google.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit f8b55a465b0e8a500179808166fe9420f5c091a1 Author: Aleksandr Mishin Date: Wed Jul 3 23:32:51 2024 +0300 mlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file [ Upstream commit 8ce34dccbe8fa7d2ef86f2d8e7db2a9b67cabfc3 ] In case of invalid INI file mlxsw_linecard_types_init() deallocates memory but doesn't reset pointer to NULL and returns 0. In case of any error occurred after mlxsw_linecard_types_init() call, mlxsw_linecards_init() calls mlxsw_linecard_types_fini() which performs memory deallocation again. Add pointer reset to NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: b217127e5e4e ("mlxsw: core_linecards: Add line card objects and implement provisioning") Signed-off-by: Aleksandr Mishin Reviewed-by: Przemek Kitszel Reviewed-by: Ido Schimmel Reviewed-by: Michal Kubiak Link: https://patch.msgid.link/20240703203251.8871-1-amishin@t-argos.ru Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 76965648fe6858db7c5f3c700fef7aa5f124ca1c Author: Shigeru Yoshida Date: Wed Jul 3 18:16:49 2024 +0900 inet_diag: Initialize pad field in struct inet_diag_req_v2 [ Upstream commit 61cf1c739f08190a4cbf047b9fbb192a94d87e3f ] KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw sockets uses the pad field in struct inet_diag_req_v2 for the underlying protocol. This field corresponds to the sdiag_raw_protocol field in struct inet_diag_req_raw. inet_diag_get_exact_compat() converts inet_diag_req to inet_diag_req_v2, but leaves the pad field uninitialized. So the issue occurs when raw_lookup() accesses the sdiag_raw_protocol field. Fix this by initializing the pad field in inet_diag_get_exact_compat(). Also, do the same fix in inet_diag_dump_compat() to avoid the similar issue in the future. [1] BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline] BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Fixes: 432490f9d455 ("net: ip, diag -- Add diag interface for raw sockets") Reported-by: syzkaller Signed-off-by: Shigeru Yoshida Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20240703091649.111773-1-syoshida@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4116ec648354efd40a1a591e51bd11b269502af0 Author: Zijian Zhang Date: Mon Jul 1 22:53:49 2024 +0000 selftests: make order checking verbose in msg_zerocopy selftest [ Upstream commit 7d6d8f0c8b700c9493f2839abccb6d29028b4219 ] We find that when lock debugging is on, notifications may not come in order. Thus, we have order checking outputs managed by cfg_verbose, to avoid too many outputs in this case. Fixes: 07b65c5b31ce ("test: add msg_zerocopy test") Signed-off-by: Zijian Zhang Signed-off-by: Xiaochun Lu Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20240701225349.3395580-3-zijianzhang@bytedance.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 946ba4e645b01074ddc9509dc4e7c1d563788a73 Author: Zijian Zhang Date: Mon Jul 1 22:53:48 2024 +0000 selftests: fix OOM in msg_zerocopy selftest [ Upstream commit af2b7e5b741aaae9ffbba2c660def434e07aa241 ] In selftests/net/msg_zerocopy.c, it has a while loop keeps calling sendmsg on a socket with MSG_ZEROCOPY flag, and it will recv the notifications until the socket is not writable. Typically, it will start the receiving process after around 30+ sendmsgs. However, as the introduction of commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale"), the sender is always writable and does not get any chance to run recv notifications. The selftest always exits with OUT_OF_MEMORY because the memory used by opt_skb exceeds the net.core.optmem_max. Meanwhile, it could be set to a different value to trigger OOM on older kernels too. Thus, we introduce "cfg_notification_limit" to force sender to receive notifications after some number of sendmsgs. Fixes: 07b65c5b31ce ("test: add msg_zerocopy test") Signed-off-by: Zijian Zhang Signed-off-by: Xiaochun Lu Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20240701225349.3395580-2-zijianzhang@bytedance.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b75e33eae8667084bd4a63e67657c6a5a0f8d1e8 Author: Sam Sun Date: Tue Jul 2 14:55:55 2024 +0100 bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set() [ Upstream commit e271ff53807e8f2c628758290f0e499dbe51cb3d ] In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read. BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]--- Fix it by adding a check of string length before using it. Fixes: f9de11a16594 ("bonding: add ip checks when store ip target") Signed-off-by: Yue Sun Signed-off-by: Simon Horman Acked-by: Jay Vosburgh Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20240702-bond-oob-v6-1-2dfdba195c19@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 55a40406aac555defe9bdd0adec9508116ce7cb1 Author: Florian Westphal Date: Tue Jul 2 16:08:14 2024 +0200 netfilter: nf_tables: unconditionally flush pending work before notifier [ Upstream commit 9f6958ba2e902f9820c594869bd710ba74b7c4c0 ] syzbot reports: KASAN: slab-uaf in nft_ctx_update include/net/netfilter/nf_tables.h:1831 KASAN: slab-uaf in nft_commit_release net/netfilter/nf_tables_api.c:9530 KASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Read of size 2 at addr ffff88802b0051c4 by task kworker/1:1/45 [..] Workqueue: events nf_tables_trans_destroy_work Call Trace: nft_ctx_update include/net/netfilter/nf_tables.h:1831 [inline] nft_commit_release net/netfilter/nf_tables_api.c:9530 [inline] nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Problem is that the notifier does a conditional flush, but its possible that the table-to-be-removed is still referenced by transactions being processed by the worker, so we need to flush unconditionally. We could make the flush_work depend on whether we found a table to delete in nf-next to avoid the flush for most cases. AFAICS this problem is only exposed in nf-next, with commit e169285f8c56 ("netfilter: nf_tables: do not store nft_ctx in transaction objects"), with this commit applied there is an unconditional fetch of table->family which is whats triggering the above splat. Fixes: 2c9f0293280e ("netfilter: nf_tables: flush pending destroy work before netlink notifier") Reported-and-tested-by: syzbot+4fd66a69358fc15ae2ad@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4fd66a69358fc15ae2ad Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7692c9b6baacdee378435f58f19baf0eb69e4155 Author: Song Shuai Date: Wed Jun 26 10:33:16 2024 +0800 riscv: kexec: Avoid deadlock in kexec crash path [ Upstream commit c562ba719df570c986caf0941fea2449150bcbc4 ] If the kexec crash code is called in the interrupt context, the machine_kexec_mask_interrupts() function will trigger a deadlock while trying to acquire the irqdesc spinlock and then deactivate irqchip in irq_set_irqchip_state() function. Unlike arm64, riscv only requires irq_eoi handler to complete EOI and keeping irq_set_irqchip_state() will only leave this possible deadlock without any use. So we simply remove it. Link: https://lore.kernel.org/linux-riscv/20231208111015.173237-1-songshuaishuai@tinylab.org/ Fixes: b17d19a5314a ("riscv: kexec: Fixup irq controller broken in kexec crash path") Signed-off-by: Song Shuai Reviewed-by: Ryo Takakura Link: https://lore.kernel.org/r/20240626023316.539971-1-songshuaishuai@tinylab.org Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 5ed821a8e9d33551f59d4588fcb5042b91b3f93b Author: Jozef Hopko Date: Mon Jul 1 18:23:20 2024 +0200 wifi: wilc1000: fix ies_len type in connect path [ Upstream commit 39ab8fff623053a50951b659e5f6b72343d7d78c ] Commit 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path") made sure that the IEs data was manipulated under the relevant RCU section. Unfortunately, while doing so, the commit brought a faulty implicit cast from int to u8 on the ies_len variable, making the parsing fail to be performed correctly if the IEs block is larger than 255 bytes. This failure can be observed with Access Points appending a lot of IEs TLVs in their beacon frames (reproduced with a Pixel phone acting as an Access Point, which brough 273 bytes of IE data in my testing environment). Fix IEs parsing by removing this undesired implicit cast. Fixes: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path") Signed-off-by: Jozef Hopko Signed-off-by: Alexis Lothoré Acked-by: Ajay Singh Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20240701-wilc_fix_ies_data-v1-1-7486cbacf98a@bootlin.com Signed-off-by: Sasha Levin commit dee87316b5f5f167a201491a774bbd6e10c8dd94 Author: Shiji Yang Date: Tue Jun 25 09:19:49 2024 +0800 gpio: mmio: do not calculate bgpio_bits via "ngpios" [ Upstream commit f07798d7bb9c46d17d80103fb772fd2c75d47919 ] bgpio_bits must be aligned with the data bus width. For example, on a 32 bit big endian system and we only have 16 GPIOs. If we only assume bgpio_bits=16 we can never control the GPIO because the base address is the lowest address. low address high address ------------------------------------------------- | byte3 | byte2 | byte1 | byte0 | ------------------------------------------------- | NaN | NaN | gpio8-15 | gpio0-7 | ------------------------------------------------- Fixes: 55b2395e4e92 ("gpio: mmio: handle "ngpios" properly in bgpio_init()") Fixes: https://github.com/openwrt/openwrt/issues/15739 Reported-by: Mark Mentovai Signed-off-by: Shiji Yang Suggested-By: Mark Mentovai Reviewed-by: Jonas Gorski Tested-by: Lóránd Horváth Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/TYCP286MB089577B47D70F0AB25ABA6F5BCD52@TYCP286MB0895.JPNP286.PROD.OUTLOOK.COM Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit e3af5b14e7632bf12058533d69055393e2d126c9 Author: Dave Jiang Date: Mon Jul 1 11:15:38 2024 -0700 net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx() [ Upstream commit e15a5d821e5192a3769d846079bc9aa380139baf ] The following is emitted when using idxd (DSA) dmanegine as the data mover for ntb_transport that ntb_netdev uses. [74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526 [74412.556784] caller is netif_rx_internal+0x42/0x130 [74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5 [74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024 [74412.581699] Call Trace: [74412.584514] [74412.586933] dump_stack_lvl+0x55/0x70 [74412.591129] check_preemption_disabled+0xc8/0xf0 [74412.596374] netif_rx_internal+0x42/0x130 [74412.600957] __netif_rx+0x20/0xd0 [74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev] [74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport] [74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport] [74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd] [74412.628963] idxd_wq_thread+0x1a6/0x2b0 [idxd] [74412.634046] irq_thread_fn+0x21/0x60 [74412.638134] ? irq_thread+0xa8/0x290 [74412.642218] irq_thread+0x1a0/0x290 [74412.646212] ? __pfx_irq_thread_fn+0x10/0x10 [74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10 [74412.656117] ? __pfx_irq_thread+0x10/0x10 [74412.660686] kthread+0x100/0x130 [74412.664384] ? __pfx_kthread+0x10/0x10 [74412.668639] ret_from_fork+0x31/0x50 [74412.672716] ? __pfx_kthread+0x10/0x10 [74412.676978] ret_from_fork_asm+0x1a/0x30 [74412.681457] The cause is due to the idxd driver interrupt completion handler uses threaded interrupt and the threaded handler is not hard or soft interrupt context. However __netif_rx() can only be called from interrupt context. Change the call to netif_rx() in order to allow completion via normal context for dmaengine drivers that utilize threaded irq handling. While the following commit changed from netif_rx() to __netif_rx(), baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."), the change should've been a noop instead. However, the code precedes this fix should've been using netif_rx_ni() or netif_rx_any_context(). Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Reported-by: Jerry Dai Tested-by: Jerry Dai Signed-off-by: Dave Jiang Link: https://patch.msgid.link/20240701181538.3799546-1-dave.jiang@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9edc7a83cd40ac96ff14fe3a17a38f7ace6611df Author: Jiawen Wu Date: Mon Jul 1 15:14:13 2024 +0800 net: txgbe: initialize num_q_vectors for MSI/INTx interrupts [ Upstream commit 7c36711a2cd8059c2d24f5e5c1d76e8ea2d5613c ] When using MSI/INTx interrupts, wx->num_q_vectors is uninitialized. Thus there will be kernel panic in wx_alloc_q_vectors() to allocate queue vectors. Fixes: 3f703186113f ("net: libwx: Add irq flow functions") Signed-off-by: Jiawen Wu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 702b17f72de289a6509f11a04514ee2cc65a5879 Author: Sagi Grimberg Date: Wed Jun 26 13:00:08 2024 +0300 net: allow skb_datagram_iter to be called from any context [ Upstream commit d2d30a376d9cc94c6fb730c58b3e5b7426ecb6de ] We only use the mapping in a single context, so kmap_local is sufficient and cheaper. Make sure to use skb_frag_foreach_page as skb frags may contain compound pages and we need to map page by page. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202406161539.b5ff7b20-oliver.sang@intel.com Fixes: 950fcaecd5cc ("datagram: consolidate datagram copy to iter helpers") Signed-off-by: Sagi Grimberg Link: https://patch.msgid.link/20240626100008.831849-1-sagi@grimberg.me Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 895f5633a0369c07fb2151f54c55d59720841082 Author: Dmitry Torokhov Date: Mon Jul 1 10:38:50 2024 -0700 gpiolib: of: fix lookup quirk for MIPS Lantiq [ Upstream commit 3645ffaf2b334abaf5f53e5ca0f47465d91e69d2 ] As it turns out, there is a large number of out-of-tree DTSes (in OpenWrt project) that used to specify incorrect (active high) polarity for the Lantiq reset GPIO, so to keep compatibility while they are being updated a quirk for force the polarity low is needed. Luckily these old DTSes used nonstandard name for the property ("gpio-reset" vs "reset-gpios") so the quirk will not hurt if there are any new devices that need inverted polarity as they can specify the right polarity in their DTS when using the standard "reset-gpios" property. Additionally the condition to enable the transition from standard to non-standard reset GPIO property name was inverted and the replacement name for the property was not correct. Fix this as well. Fixes: fbbbcd177a27 ("gpiolib: of: add quirk for locating reset lines with legacy bindings") Fixes: 90c2d2eb7ab5 ("MIPS: pci: lantiq: switch to using gpiod API") Reported-by: Martin Schiller Acked-by: Martin Schiller Signed-off-by: Dmitry Torokhov Link: https://lore.kernel.org/r/ZoLpqv1PN08xHioh@google.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit e536e6efa65f447a7611b4fb07ede1a9c895f8ea Author: Dima Ruinskiy Date: Fri Jun 28 13:17:53 2024 -0700 e1000e: Fix S0ix residency on corporate systems [ Upstream commit c93a6f62cb1bd097aef2e4588648a420d175eee2 ] On vPro systems, the configuration of the I219-LM to achieve power gating and S0ix residency is split between the driver and the CSME FW. It was discovered that in some scenarios, where the network cable is connected and then disconnected, S0ix residency is not always reached. This was root-caused to a subset of I219-LM register writes that are not performed by the CSME FW. Therefore, the driver should perform these register writes on corporate setups, regardless of the CSME FW state. This was discovered on Meteor Lake systems; however it is likely to appear on other platforms as well. Fixes: cc23f4f0b6b9 ("e1000e: Add support for Meteor Lake") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218589 Signed-off-by: Dima Ruinskiy Signed-off-by: Vitaly Lifshits Signed-off-by: Tony Nguyen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20240628201754.2744221-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4513867bae5da6ae24901ce6eb40435c379415e Author: Christian Borntraeger Date: Fri Jun 28 18:35:47 2024 +0200 KVM: s390: fix LPSWEY handling [ Upstream commit 4c6abb7f7b349f00c0f7ed5045bf67759c012892 ] in rare cases, e.g. for injecting a machine check we do intercept all load PSW instructions via ICTL_LPSW. With facility 193 a new variant LPSWEY was added. KVM needs to handle that as well. Fixes: a3efa8429266 ("KVM: s390: gen_facilities: allow facilities 165, 193, 194 and 196") Reported-by: Marc Hartmayer Reviewed-by: Sven Schnelle Reviewed-by: Claudio Imbrenda Signed-off-by: Christian Borntraeger Message-ID: <20240628163547.2314-1-borntraeger@linux.ibm.com> Signed-off-by: Sasha Levin commit 8c2debdd170e395934ac0e039748576dfde14e99 Author: Jakub Kicinski Date: Thu Jun 27 14:25:00 2024 -0700 tcp_metrics: validate source addr length [ Upstream commit 66be40e622e177316ae81717aa30057ba9e61dff ] I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated). Reviewed-by: Eric Dumazet Fixes: 3e7013ddf55a ("tcp: metrics: Allow selective get/del of tcp-metrics based on src IP") Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4970e48f83dbd21d2a6a7cdaaafc2a71f7f45dc4 Author: Pavel Skripkin Date: Thu Jun 20 22:27:47 2024 +0300 bluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX [ Upstream commit 1cc18c2ab2e8c54c355ea7c0423a636e415a0c23 ] Syzbot hit warning in hci_conn_del() caused by freeing handle that was not allocated using ida allocator. This is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by hci_le_big_sync_established_evt(), which makes code think it's unset connection. Add same check for handle upper bound as in hci_conn_set_handle() to prevent warning. Link: https://syzkaller.appspot.com/bug?extid=b2545b087a01a7319474 Reported-by: syzbot+b2545b087a01a7319474@syzkaller.appspotmail.com Fixes: 181a42edddf5 ("Bluetooth: Make handle of hci_conn be unique") Signed-off-by: Pavel Skripkin Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 045669710464a21c67e690ef14698fd71857cb11 Author: Iulia Tanasescu Date: Tue Jun 18 13:33:24 2024 +0300 Bluetooth: ISO: Check socket flag instead of hcon [ Upstream commit 596b6f081336e77764ca35cfeab66d0fcdbe544e ] This fixes the following Smatch static checker warning: net/bluetooth/iso.c:1364 iso_sock_recvmsg() error: we previously assumed 'pi->conn->hcon' could be null (line 1359) net/bluetooth/iso.c 1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg, 1348 size_t len, int flags) 1349 { 1350 struct sock *sk = sock->sk; 1351 struct iso_pinfo *pi = iso_pi(sk); 1352 1353 BT_DBG("sk %p", sk); 1354 1355 if (test_and_clear_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) { 1356 lock_sock(sk); 1357 switch (sk->sk_state) { 1358 case BT_CONNECT2: 1359 if (pi->conn->hcon && ^^^^^^^^^^^^^^ If ->hcon is NULL 1360 test_bit(HCI_CONN_PA_SYNC, &pi->conn->hcon->flags)) { 1361 iso_conn_big_sync(sk); 1362 sk->sk_state = BT_LISTEN; 1363 } else { --> 1364 iso_conn_defer_accept(pi->conn->hcon); ^^^^^^^^^^^^^^ then we're toast 1365 sk->sk_state = BT_CONFIG; 1366 } 1367 release_sock(sk); 1368 return 0; 1369 case BT_CONNECTED: 1370 if (test_bit(BT_SK_PA_SYNC, Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync") Signed-off-by: Iulia Tanasescu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 38263088b845abeeeb98dda5b87c0de3063b6dbb Author: Edward Adam Davis Date: Mon Jun 17 19:09:37 2024 +0800 Bluetooth: Ignore too large handle values in BIG [ Upstream commit 015d79c96d62cd8a4a359fcf5be40d58088c936b ] hci_le_big_sync_established_evt is necessary to filter out cases where the handle value is belonging to ida id range, otherwise ida will be erroneously released in hci_conn_cleanup. Fixes: 181a42edddf5 ("Bluetooth: Make handle of hci_conn be unique") Reported-by: syzbot+b2545b087a01a7319474@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b2545b087a01a7319474 Signed-off-by: Edward Adam Davis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1ae31b357a774d1b0567e8de7a4d972b58f54176 Author: Luiz Augusto von Dentz Date: Thu Jun 6 12:04:30 2024 -0400 Bluetooth: hci_event: Fix setting of unicast qos interval [ Upstream commit ac65ecccae802417ce42e857defacad60e4b8329 ] qos->ucast interval reffers to the SDU interval, and should not be set to the interval value reported by the LE CIS Established event since the latter reffers to the ISO interval. These two interval are not the same thing: BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 6, Part G Isochronous interval: The time between two consecutive BIS or CIS events (designated ISO_Interval in the Link Layer) SDU interval: The nominal time between two consecutive SDUs that are sent or received by the upper layer. So this instead uses the following formula from the spec to calculate the resulting SDU interface: BLUETOOTH CORE SPECIFICATION Version 5.4 | Vol 6, Part G page 3075: Transport_Latency_C_To_P = CIG_Sync_Delay + (FT_C_To_P) × ISO_Interval + SDU_Interval_C_To_P Transport_Latency_P_To_C = CIG_Sync_Delay + (FT_P_To_C) × ISO_Interval + SDU_Interval_P_To_C Link: https://github.com/bluez/bluez/issues/823 Fixes: 2be22f1941d5 ("Bluetooth: hci_event: Fix parsing of CIS Established Event") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a9f4a9b27fded3cc3ae630d0a4a88572e52e6eff Author: Jianbo Liu Date: Thu Jun 27 21:02:38 2024 +0300 net/mlx5e: Add mqprio_rl cleanup and free in mlx5e_priv_cleanup() [ Upstream commit 1da839eab6dbc26b95bfcd1ed1a4d1aaa5c144a3 ] In the cited commit, mqprio_rl cleanup and free are mistakenly removed in mlx5e_priv_cleanup(), and it causes the leakage of host memory and firmware SCHEDULING_ELEMENT objects while changing eswitch mode. So, add them back. Fixes: 0bb7228f7096 ("net/mlx5e: Fix mqprio_rl handling on devlink reload") Signed-off-by: Jianbo Liu Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3e3551f8702978cd2221d2614ca6d6727e785324 Author: Chris Mi Date: Thu Jun 27 21:02:37 2024 +0300 net/mlx5: E-switch, Create ingress ACL when needed [ Upstream commit b20c2fb45470d0c7a603613c9cfa5d45720e17f2 ] Currently, ingress acl is used for three features. It is created only when vport metadata match and prio tag are enabled. But active-backup lag mode also uses it. It is independent of vport metadata match and prio tag. And vport metadata match can be disabled using the following devlink command: # devlink dev param set pci/0000:08:00.0 name esw_port_metadata \ value false cmode runtime If ingress acl is not created, will hit panic when creating drop rule for active-backup lag mode. If always create it, there will be about 5% performance degradation. Fix it by creating ingress acl when needed. If esw_port_metadata is true, ingress acl exists, then create drop rule using existing ingress acl. If esw_port_metadata is false, create ingress acl and then create drop rule. Fixes: 1749c4c51c16 ("net/mlx5: E-switch, add drop rule support to ingress ACL") Signed-off-by: Chris Mi Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8a7fc2362d6d234befde681ea4fb6c45c1789ed5 Author: Neal Cardwell Date: Wed Jun 26 22:42:27 2024 -0400 UPSTREAM: tcp: fix DSACK undo in fast recovery to call tcp_try_to_open() [ Upstream commit a6458ab7fd4f427d4f6f54380453ad255b7fde83 ] In some production workloads we noticed that connections could sometimes close extremely prematurely with ETIMEDOUT after transmitting only 1 TLP and RTO retransmission (when we would normally expect roughly tcp_retries2 = TCP_RETR2 = 15 RTOs before a connection closes with ETIMEDOUT). From tracing we determined that these workloads can suffer from a scenario where in fast recovery, after some retransmits, a DSACK undo can happen at a point where the scoreboard is totally clear (we have retrans_out == sacked_out == lost_out == 0). In such cases, calling tcp_try_keep_open() means that we do not execute any code path that clears tp->retrans_stamp to 0. That means that tp->retrans_stamp can remain erroneously set to the start time of the undone fast recovery, even after the fast recovery is undone. If minutes or hours elapse, and then a TLP/RTO/RTO sequence occurs, then the start_ts value in retransmits_timed_out() (which is from tp->retrans_stamp) will be erroneously ancient (left over from the fast recovery undone via DSACKs). Thus this ancient tp->retrans_stamp value can cause the connection to die very prematurely with ETIMEDOUT via tcp_write_err(). The fix: we change DSACK undo in fast recovery (TCP_CA_Recovery) to call tcp_try_to_open() instead of tcp_try_keep_open(). This ensures that if no retransmits are in flight at the time of DSACK undo in fast recovery then we properly zero retrans_stamp. Note that calling tcp_try_to_open() is more consistent with other loss recovery behavior, since normal fast recovery (CA_Recovery) and RTO recovery (CA_Loss) both normally end when tp->snd_una meets or exceeds tp->high_seq and then in tcp_fastretrans_alert() the "default" switch case executes tcp_try_to_open(). Also note that by inspection this change to call tcp_try_to_open() implies at least one other nice bug fix, where now an ECE-marked DSACK that causes an undo will properly invoke tcp_enter_cwr() rather than ignoring the ECE mark. Fixes: c7d9d6a185a7 ("tcp: undo on DSACK during recovery") Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9e8f0c53a53568fd2f7f50b4f814f1f40a4abcac Author: Marek Vasut Date: Wed Jun 26 05:06:17 2024 +0200 net: phy: phy_device: Fix PHY LED blinking code comment [ Upstream commit d3dcb084c70727be4a2f61bd94796e66147cfa35 ] Fix copy-paste error in the code comment. The code refers to LED blinking configuration, not brightness configuration. It was likely copied from comment above this one which does refer to brightness configuration. Fixes: 4e901018432e ("net: phy: phy_device: Call into the PHY driver to set LED blinking") Signed-off-by: Marek Vasut Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20240626030638.512069-1-marex@denx.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 617075792b7c66d3c54c0f8dc59ac0669baf1f39 Author: Dmitry Antipov Date: Wed May 8 14:40:10 2024 +0300 mac802154: fix time calculation in ieee802154_configure_durations() [ Upstream commit 07aa33988ad92fef79056f5ec30b9a0e4364b616 ] Since 'symbol_duration' of 'struct wpan_phy' is in nanoseconds but 'lifs_period' and 'sifs_period' are both in microseconds, fix time calculation in 'ieee802154_configure_durations()' and use convenient 'NSEC_PER_USEC' in 'ieee802154_setup_wpan_phy_pib()' as well. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 781830c800dd ("net: mac802154: Set durations automatically") Signed-off-by: Dmitry Antipov Acked-by: Miquel Raynal Message-ID: <20240508114010.219527-1-dmantipov@yandex.ru> Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit abe067dc3a662eef7d5cddbbc41ed50a0b68b0af Author: Mike Christie Date: Fri Mar 15 19:47:06 2024 -0500 vhost_task: Handle SIGKILL by flushing work and exiting [ Upstream commit db5247d9bf5c6ade9fd70b4e4897441e0269b233 ] Instead of lingering until the device is closed, this has us handle SIGKILL by: 1. marking the worker as killed so we no longer try to use it with new virtqueues and new flush operations. 2. setting the virtqueue to worker mapping so no new works are queued. 3. running all the exiting works. Suggested-by: Edward Adam Davis Reported-and-tested-by: syzbot+98edc2df894917b3431f@syzkaller.appspotmail.com Message-Id: Signed-off-by: Mike Christie Message-Id: <20240316004707.45557-9-michael.christie@oracle.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit f5bb72196f4905f8c5470f2d9f26302c8616e2b6 Author: Mike Christie Date: Fri Mar 15 19:47:05 2024 -0500 vhost: Release worker mutex during flushes [ Upstream commit ba704ff4e142fd3cfaf3379dd3b3b946754e06e3 ] In the next patches where the worker can be killed while in use, we need to be able to take the worker mutex and kill queued works for new IO and flushes, and set some new flags to prevent new __vhost_vq_attach_worker calls from swapping in/out killed workers. If we are holding the worker mutex during a flush and the flush's work is still in the queue, the worker code that will handle the SIGKILL cleanup won't be able to take the mutex and perform it's cleanup. So this patch has us drop the worker mutex while waiting for the flush to complete. Signed-off-by: Mike Christie Message-Id: <20240316004707.45557-8-michael.christie@oracle.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit a86f9633f70a84a32694dcd8776e7f5df776ef22 Author: Mike Christie Date: Fri Mar 15 19:47:04 2024 -0500 vhost: Use virtqueue mutex for swapping worker [ Upstream commit 34cf9ba5f00a222dddd9fc71de7c68fdaac7fb97 ] __vhost_vq_attach_worker uses the vhost_dev mutex to serialize the swapping of a virtqueue's worker. This was done for simplicity because we are already holding that mutex. In the next patches where the worker can be killed while in use, we need finer grained locking because some drivers will hold the vhost_dev mutex while flushing. However in the SIGKILL handler in the next patches, we will need to be able to swap workers (set current one to NULL), kill queued works and stop new flushes while flushes are in progress. To prepare us, this has us use the virtqueue mutex for swapping workers instead of the vhost_dev one. Signed-off-by: Mike Christie Message-Id: <20240316004707.45557-7-michael.christie@oracle.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 76d7b869b3b9ccb9c8b91bac5533d690925110a0 Author: Len Brown Date: Sun Apr 21 11:56:48 2024 -0400 tools/power turbostat: Remember global max_die_id [ Upstream commit cda203388687aa075db6f8996c3c4549fa518ea8 ] This is necessary to gracefully handle sparse die_id's. no functional change Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 3ee21e14c8c329168a0b66bab00ecd18f5d0dee3 Author: Justin Stitt Date: Tue May 7 23:25:20 2024 +0100 cdrom: rearrange last_media_change check to avoid unintentional overflow [ Upstream commit efb905aeb44b0e99c0e6b07865b1885ae0471ebf ] When running syzkaller with the newly reintroduced signed integer wrap sanitizer we encounter this splat: [ 366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33 [ 366.021089] -9223372036854775808 - 346321 cannot be represented in type '__s64' (aka 'long long') [ 366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO [ 366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1 [ 366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 366.027518] Call Trace: [ 366.027523] [ 366.027533] dump_stack_lvl+0x93/0xd0 [ 366.027899] handle_overflow+0x171/0x1b0 [ 366.038787] ata1.00: invalid multi_count 32 ignored [ 366.043924] cdrom_ioctl+0x2c3f/0x2d10 [ 366.063932] ? __pm_runtime_resume+0xe6/0x130 [ 366.071923] sr_block_ioctl+0x15d/0x1d0 [ 366.074624] ? __pfx_sr_block_ioctl+0x10/0x10 [ 366.077642] blkdev_ioctl+0x419/0x500 [ 366.080231] ? __pfx_blkdev_ioctl+0x10/0x10 ... Historically, the signed integer overflow sanitizer did not work in the kernel due to its interaction with `-fwrapv` but this has since been changed [1] in the newest version of Clang. It was re-enabled in the kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow sanitizer"). Let's rearrange the check to not perform any arithmetic, thus not tripping the sanitizer. Link: https://github.com/llvm/llvm-project/pull/82432 [1] Closes: https://github.com/KSPP/linux/issues/354 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt Link: https://lore.kernel.org/lkml/20240507-b4-sio-ata1-v1-1-810ffac6080a@google.com Reviewed-by: Phillip Potter Link: https://lore.kernel.org/lkml/ZjqU0fbzHrlnad8D@equinox Signed-off-by: Phillip Potter Link: https://lore.kernel.org/r/20240507222520.1445-2-phil@philpotter.co.uk Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e130d4fc196bef35da3b5d988b2b7840e3bcc56e Author: Lu Yao Date: Tue May 7 10:34:17 2024 +0800 btrfs: scrub: initialize ret in scrub_simple_mirror() to fix compilation warning [ Upstream commit b4e585fffc1cf877112ed231a91f089e85688c2a ] The following error message is displayed: ../fs/btrfs/scrub.c:2152:9: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]" Compiler version: gcc version: (Debian 10.2.1-6) 10.2.1 20210110 Reviewed-by: Boris Burkov Signed-off-by: Lu Yao Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 90a01aefb84b09ccb6024d75d85bb8f620bd3487 Author: Holger Dengler Date: Tue May 7 17:03:18 2024 +0200 s390/pkey: Wipe sensitive data on failure [ Upstream commit 1d8c270de5eb74245d72325d285894a577a945d9 ] Wipe sensitive data from stack also if the copy_to_user() fails. Suggested-by: Heiko Carstens Reviewed-by: Harald Freudenberger Reviewed-by: Ingo Franzki Acked-by: Heiko Carstens Signed-off-by: Holger Dengler Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit d0bbbf31462a400bef4df33e22de91864f475455 Author: Wang Yong Date: Tue May 7 15:00:46 2024 +0800 jffs2: Fix potential illegal address access in jffs2_free_inode [ Upstream commit af9a8730ddb6a4b2edd779ccc0aceb994d616830 ] During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] address between user and kernel address ranges [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33 [ 2430.655008] Hardware name: linux,dummy-virt (DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2_free_inode+0x24/0x48 [ 2430.657051] sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19 [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14 [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302 [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342 [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000 [ 2430.664217] Call trace: [ 2430.664528] kfree+0x78/0x348 [ 2430.664855] jffs2_free_inode+0x24/0x48 [ 2430.665233] i_callback+0x24/0x50 [ 2430.665528] rcu_do_batch+0x1ac/0x448 [ 2430.665892] rcu_core+0x28c/0x3c8 [ 2430.666151] rcu_core_si+0x18/0x28 [ 2430.666473] __do_softirq+0x138/0x3cc [ 2430.666781] irq_exit+0xf0/0x110 [ 2430.667065] handle_domain_irq+0x6c/0x98 [ 2430.667447] gic_handle_irq+0xac/0xe8 [ 2430.667739] call_on_irq_stack+0x28/0x54 The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of the jffs_inode_info structure. It was found that all variables in the jffs_inode_info structure were 5a5a5a5a, except for the first member sem. It is suspected that these variables are not initialized because they were set to 5a5a5a5a during memory testing, which is meant to detect uninitialized memory.The sem variable is initialized in the function jffs2_i_init_once, while other members are initialized in the function jffs2_init_inode_info. The function jffs2_init_inode_info is called after iget_locked, but in the iget_locked function, the destroy_inode process is triggered, which releases the inode and consequently, the target member of the inode is not initialized.In concurrent high pressure scenarios, iget_locked may enter the destroy_inode branch as described in the code. Since the destroy_inode functionality of jffs2 only releases the target, the fix method is to set target to NULL in jffs2_i_init_once. Signed-off-by: Wang Yong Reviewed-by: Lu Zhongjun Reviewed-by: Yang Tao Cc: Xu Xin Cc: Yang Yang Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit b5f1844c05618b269097dc7d40f041e3f8784df0 Author: Matthias Schiffer Date: Wed May 8 15:37:44 2024 +0200 serial: imx: Raise TX trigger level to 8 [ Upstream commit a3d8728ab079951741efa11360df43dbfacba7ab ] At the default TX trigger level of 2 in non-DMA mode (meaning that an interrupt is generated when less than 2 characters are left in the FIFO), we have observed frequent buffer underruns at 115200 Baud on an i.MX8M Nano. This can cause communication issues if the receiving side expects a continuous transfer. Increasing the level to 8 makes the UART trigger an interrupt earlier, giving the kernel enough time to refill the FIFO, at the cost of triggering one interrupt per ~24 instead of ~30 bytes of transmitted data (as the i.MX UART has a 32 byte FIFO). Signed-off-by: Michael Krummsdorf Signed-off-by: Matthias Schiffer Link: https://lore.kernel.org/r/20240508133744.35858-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 586b41060113ae43032ec6c4a16d518cef5da6e0 Author: Tomas Henzl Date: Mon Feb 26 16:10:13 2024 +0100 scsi: mpi3mr: Sanitise num_phys [ Upstream commit 3668651def2c1622904e58b0280ee93121f2b10b ] Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed. Signed-off-by: Tomas Henzl Link: https://lore.kernel.org/r/20240226151013.8653-1-thenzl@redhat.com Acked-by: Sathya Prakash Veerichetty Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 44958ca9e400f57bd0478115519ffc350fcee61e Author: Chao Yu Date: Tue May 7 11:38:47 2024 +0800 f2fs: check validation of fault attrs in f2fs_build_fault_attr() [ Upstream commit 4ed886b187f47447ad559619c48c086f432d2b77 ] - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 7e5471b5efebc30dd0bc035cda86693a5c73d45f Author: Jose E. Marchesi Date: Wed May 8 12:13:13 2024 +0200 bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD [ Upstream commit 009367099eb61a4fc2af44d4eb06b6b4de7de6db ] [Changes from V1: - Use a default branch in the switch statement to initialize `val'.] GCC warns that `val' may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: [...] unsigned long long val; \ [...] \ switch (__CORE_RELO(s, field, BYTE_SIZE)) { \ case 1: val = *(const unsigned char *)p; break; \ case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ } \ [...] val; \ } \ This patch adds a default entry in the switch statement that sets `val' to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions. Signed-off-by: Jose E. Marchesi Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240508101313.16662-1-jose.marchesi@oracle.com Signed-off-by: Sasha Levin commit 92160970bfe8cd9af271255f33620cfca6ef7702 Author: Corinna Vinschen Date: Tue Apr 23 12:24:54 2024 +0200 igc: fix a log entry using uninitialized netdev [ Upstream commit 86167183a17e03ec77198897975e9fdfbd53cb0b ] During successful probe, igc logs this: [ 5.133667] igc 0000:01:00.0 (unnamed net_device) (uninitialized): PHC added ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The reason is that igc_ptp_init() is called very early, even before register_netdev() has been called. So the netdev_info() call works on a partially uninitialized netdev. Fix this by calling igc_ptp_init() after register_netdev(), right after the media autosense check, just as in igb. Add a comment, just as in igb. Now the log message is fine: [ 5.200987] igc 0000:01:00.0 eth0: PHC added Signed-off-by: Corinna Vinschen Reviewed-by: Hariprasad Kelam Acked-by: Vinicius Costa Gomes Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit c80d53c484e82457c3eda89a9e4b1a1002875b7b Author: John Hubbard Date: Mon May 6 12:02:04 2024 -0700 selftests/net: fix uninitialized variables [ Upstream commit eb709b5f6536636dfb87b85ded0b2af9bb6cd9e6 ] When building with clang, via: make LLVM=1 -C tools/testing/selftest ...clang warns about three variables that are not initialized in all cases: 1) The opt_ipproto_off variable is used uninitialized if "testname" is not "ip". Willem de Bruijn pointed out that this is an actual bug, and suggested the fix that I'm using here (thanks!). 2) The addr_len is used uninitialized, but only in the assert case, which bails out, so this is harmless. 3) The family variable in add_listener() is only used uninitialized in the error case (neither IPv4 nor IPv6 is specified), so it's also harmless. Fix by initializing each variable. Signed-off-by: John Hubbard Reviewed-by: Willem de Bruijn Acked-by: Mat Martineau Link: https://lore.kernel.org/r/20240506190204.28497-1-jhubbard@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ee123d5655f7e7b9b8744f8a47a56a987bb34d75 Author: Greg Kurz Date: Tue Mar 9 19:11:10 2021 +0100 powerpc/xmon: Check cpu id in commands "c#", "dp#" and "dx#" [ Upstream commit 8873aab8646194a4446117bb617cc71bddda2dee ] All these commands end up peeking into the PACA using the user originated cpu id as an index. Check the cpu id is valid in order to prevent xmon to crash. Instead of printing an error, this follows the same behavior as the "lp s #" command : ignore the buggy cpu id parameter and fall back to the #-less version of the command. Signed-off-by: Greg Kurz Reviewed-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://msgid.link/161531347060.252863.10490063933688958044.stgit@bahia.lan Signed-off-by: Sasha Levin commit 4e40bc50daae8ecf0cc5055c806579f09c31e8d3 Author: Mickaël Salaün Date: Mon Apr 8 09:46:21 2024 +0200 kunit: Fix timeout message [ Upstream commit 53026ff63bb07c04a0e962a74723eb10ff6f9dc7 ] The exit code is always checked, so let's properly handle the -ETIMEDOUT error code. Cc: Brendan Higgins Cc: Shuah Khan Reviewed-by: Kees Cook Reviewed-by: David Gow Reviewed-by: Rae Moar Signed-off-by: Mickaël Salaün Link: https://lore.kernel.org/r/20240408074625.65017-4-mic@digikod.net Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 6a3cacf6d3cf0278aa90392aef2fc3fe2717a047 Author: Mike Marshall Date: Wed May 1 16:20:36 2024 -0400 orangefs: fix out-of-bounds fsid access [ Upstream commit 53e4efa470d5fc6a96662d2d3322cfc925818517 ] Arnd Bergmann sent a patch to fsdevel, he says: "orangefs_statfs() copies two consecutive fields of the superblock into the statfs structure, which triggers a warning from the string fortification helpers" Jan Kara suggested an alternate way to do the patch to make it more readable. I ran both ideas through xfstests and both seem fine. This patch is based on Jan Kara's suggestion. Signed-off-by: Mike Marshall Signed-off-by: Sasha Levin commit 7c91479c6f83f34afd95285f86ae0a0b7c14739d Author: Michael Ellerman Date: Fri May 3 17:56:19 2024 +1000 powerpc/64: Set _IO_BASE to POISON_POINTER_DELTA not 0 for CONFIG_PCI=n [ Upstream commit be140f1732b523947425aaafbe2e37b41b622d96 ] There is code that builds with calls to IO accessors even when CONFIG_PCI=n, but the actual calls are guarded by runtime checks. If not those calls would be faulting, because the page at virtual address zero is (usually) not mapped into the kernel. As Arnd pointed out, it is possible a large port value could cause the address to be above mmap_min_addr which would then access userspace, which would be a bug. To avoid any such issues, set _IO_BASE to POISON_POINTER_DELTA. That is a value chosen to point into unmapped space between the kernel and userspace, so any access will always fault. Note that on 32-bit POISON_POINTER_DELTA is 0, so the patch only has an effect on 64-bit. Signed-off-by: Michael Ellerman Link: https://msgid.link/20240503075619.394467-2-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit e0cd887ad86eaa0d32e7261bf9c2f601dabf07cc Author: Heiner Kallweit Date: Fri Apr 12 12:21:58 2024 +0200 i2c: i801: Annotate apanel_addr as __ro_after_init [ Upstream commit 355b1513b1e97b6cef84b786c6480325dfd3753d ] Annotate this variable as __ro_after_init to protect it from being overwritten later. Signed-off-by: Heiner Kallweit Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit 8ac224e9371dc3c4eb666033e6b42d05cf5184a1 Author: Ricardo Ribalda Date: Mon Apr 29 16:05:04 2024 +0100 media: dvb-frontends: tda10048: Fix integer overflow [ Upstream commit 1aa1329a67cc214c3b7bd2a14d1301a795760b07 ] state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer when multiplied by pll_mfactor. Create a new 64 bit variable to hold the calculations. Link: https://lore.kernel.org/linux-media/20240429-fix-cocci-v3-25-3c4865f5a4b0@chromium.org Reported-by: Dan Carpenter Signed-off-by: Ricardo Ribalda Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 29ce81f9799166563c9548b4ab1614a7db3d9b89 Author: Ricardo Ribalda Date: Mon Apr 29 16:04:50 2024 +0100 media: s2255: Use refcount_t instead of atomic_t for num_channels [ Upstream commit 6cff72f6bcee89228a662435b7c47e21a391c8d0 ] Use an API that resembles more the actual use of num_channels. Found by cocci: drivers/media/usb/s2255/s2255drv.c:2362:5-24: WARNING: atomic_dec_and_test variation before object free at line 2363. drivers/media/usb/s2255/s2255drv.c:1557:5-24: WARNING: atomic_dec_and_test variation before object free at line 1558. Link: https://lore.kernel.org/linux-media/20240429-fix-cocci-v3-11-3c4865f5a4b0@chromium.org Signed-off-by: Ricardo Ribalda Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0f9d21eca4accc9ceaa09774051c5d827f36acff Author: Ricardo Ribalda Date: Mon Apr 29 16:04:47 2024 +0100 media: dvb-frontends: tda18271c2dd: Remove casting during div [ Upstream commit e9a844632630e18ed0671a7e3467431bd719952e ] do_div() divides 64 bits by 32. We were adding a casting to the divider to 64 bits, for a number that fits perfectly in 32 bits. Remove it. Found by cocci: drivers/media/dvb-frontends/tda18271c2dd.c:355:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead. drivers/media/dvb-frontends/tda18271c2dd.c:331:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead. Link: https://lore.kernel.org/linux-media/20240429-fix-cocci-v3-8-3c4865f5a4b0@chromium.org Signed-off-by: Ricardo Ribalda Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3f25b5f1635449036692a44b771f39f772190c1d Author: Simon Horman Date: Tue Apr 30 18:46:45 2024 +0100 net: dsa: mv88e6xxx: Correct check for empty list [ Upstream commit 4c7f3950a9fd53a62b156c0fe7c3a2c43b0ba19b ] Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only. Reviewed-by: Andrew Lunn Signed-off-by: Simon Horman Link: https://lore.kernel.org/r/20240430-mv88e6xx-list_empty-v3-1-c35c69d88d2e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 79ef1a5593fdb8aa4dbccf6085c48f1739338bc9 Author: Julien Panis Date: Thu May 2 15:46:03 2024 +0200 thermal/drivers/mediatek/lvts_thermal: Check NULL ptr on lvts_data [ Upstream commit a1191a77351e25ddf091bb1a231cae12ee598b5d ] Verify that lvts_data is not NULL before using it. Signed-off-by: Julien Panis Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240502-mtk-thermal-lvts-data-v1-1-65f1b0bfad37@baylibre.com Signed-off-by: Sasha Levin commit 547cb99314064648364a508f87e8c40a2b20cf0d Author: StanleyYP Wang Date: Wed Mar 20 19:09:16 2024 +0800 wifi: mt76: mt7996: add sanity checks for background radar trigger [ Upstream commit ec55d8e7dfea92daff87f5c01689633f8c4e6a62 ] Check if background radar is enabled or not before manually triggering it, and also add more checks in radar detected event. Signed-off-by: StanleyYP Wang Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ff6b26be13032c5fbd6b6a0b24358f8eaac4f3af Author: Felix Fietkau Date: Thu Mar 14 17:02:52 2024 +0100 wifi: mt76: replace skb_put with skb_put_zero [ Upstream commit 7f819a2f4fbc510e088b49c79addcf1734503578 ] Avoid potentially reusing uninitialized data Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9a24eb8010c2dc6a2eba56e3eb9fc07d14ffe00a Author: Niklas Neronin Date: Mon Apr 29 17:02:37 2024 +0300 usb: xhci: prevent potential failure in handle_tx_event() for Transfer events without TRB [ Upstream commit 66cb618bf0bb82859875b00eeffaf223557cb416 ] Some transfer events don't always point to a TRB, and consequently don't have a endpoint ring. In these cases, function handle_tx_event() should not proceed, because if 'ep->skip' is set, the pointer to the endpoint ring is used. To prevent a potential failure and make the code logical, return after checking the completion code for a Transfer event without TRBs. Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240429140245.3955523-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c727e46f0cc8bd81788bb29dac9a0a45f2dfa2eb Author: Erick Archer Date: Sat Apr 27 17:05:56 2024 +0200 Input: ff-core - prefer struct_size over open coded arithmetic [ Upstream commit a08b8f8557ad88ffdff8905e5da972afe52e3307 ] This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. As the "ff" variable is a pointer to "struct ff_device" and this structure ends in a flexible array: struct ff_device { [...] struct file *effect_owners[] __counted_by(max_effects); }; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the calculation "size + count * size" in the kzalloc() function. The struct_size() helper returns SIZE_MAX on overflow. So, refactor the comparison to take advantage of this. This way, the code is more readable and safer. This code was detected with the help of Coccinelle, and audited and modified manually. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Signed-off-by: Erick Archer Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/AS8PR02MB72371E646714BAE2E51A6A378B152@AS8PR02MB7237.eurprd02.prod.outlook.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 50c6c51972e9561b58bc814d5953e83c3159494e Author: Jean Delvare Date: Tue Apr 30 18:29:32 2024 +0200 firmware: dmi: Stop decoding on broken entry [ Upstream commit 0ef11f604503b1862a21597436283f158114d77e ] If a DMI table entry is shorter than 4 bytes, it is invalid. Due to how DMI table parsing works, it is impossible to safely recover from such an error, so we have to stop decoding the table. Signed-off-by: Jean Delvare Link: https://lore.kernel.org/linux-kernel/Zh2K3-HLXOesT_vZ@liuwe-devbox-debian-v2/T/ Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin commit 58405d6eff398bedb690174036e89e1a48b3dbab Author: Erick Archer Date: Sat Apr 27 19:23:36 2024 +0200 sctp: prefer struct_size over open coded arithmetic [ Upstream commit e5c5f3596de224422561d48eba6ece5210d967b3 ] This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. As the "ids" variable is a pointer to "struct sctp_assoc_ids" and this structure ends in a flexible array: struct sctp_assoc_ids { [...] sctp_assoc_t gaids_assoc_id[]; }; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the calculation "size + size * count" in the kmalloc() function. Also, refactor the code adding the "ids_size" variable to avoid sizing twice. This way, the code is more readable and safer. This code was detected with the help of Coccinelle, and audited and modified manually. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Signed-off-by: Erick Archer Acked-by: Xin Long Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/PAXPR02MB724871DB78375AB06B5171C88B152@PAXPR02MB7248.eurprd02.prod.outlook.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 864a02425045a6cf0d0700902d3192bfdfbff3fc Author: Samuel Holland Date: Tue Mar 26 21:49:48 2024 -0700 riscv: Apply SiFive CIP-1200 workaround to single-ASID sfence.vma [ Upstream commit 20e03d702e00a3e0269a1d6f9549c2e370492054 ] commit 3f1e782998cd ("riscv: add ASID-based tlbflushing methods") added calls to the sfence.vma instruction with rs2 != x0. These single-ASID instruction variants are also affected by SiFive errata CIP-1200. Until now, the errata workaround was not needed for the single-ASID sfence.vma variants, because they were only used when the ASID allocator was enabled, and the affected SiFive platforms do not support multiple ASIDs. However, we are going to start using those sfence.vma variants regardless of ASID support, so now we need alternatives covering them. Signed-off-by: Samuel Holland Link: https://lore.kernel.org/r/20240327045035.368512-8-samuel.holland@sifive.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit af19067bd58f0f6f90eb6c604babffb55c2d6a00 Author: Michael Bunk Date: Sun Jan 16 11:22:36 2022 +0000 media: dw2102: Don't translate i2c read into write [ Upstream commit 0e148a522b8453115038193e19ec7bea71403e4a ] The code ignored the I2C_M_RD flag on I2C messages. Instead it assumed an i2c transaction with a single message must be a write operation and a transaction with two messages would be a read operation. Though this works for the driver code, it leads to problems once the i2c device is exposed to code not knowing this convention. For example, I did "insmod i2c-dev" and issued read requests from userspace, which were translated into write requests and destroyed the EEPROM of my device. So, just check and respect the I2C_M_READ flag, which indicates a read when set on a message. If it is absent, it is a write message. Incidentally, changing from the case statement to a while loop allows the code to lift the limitation to two i2c messages per transaction. There are 4 more *_i2c_transfer functions affected by the same behaviour and limitation that should be fixed in the same way. Link: https://lore.kernel.org/linux-media/20220116112238.74171-2-micha@freedict.org Signed-off-by: Michael Bunk Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3fac5aecb59336c9ae808a2cf4733f9f185e3fa2 Author: Jesse Zhang Date: Thu Apr 25 15:16:40 2024 +0800 drm/amdgpu: fix the warning about the expression (int)size - len [ Upstream commit ea686fef5489ef7a2450a9fdbcc732b837fb46a8 ] Converting size from size_t to int may overflow. v2: keep reverse xmas tree order (Christian) Signed-off-by: Jesse Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7e0fbceae1e671af9d91e338cc8608c9bfb7d2f1 Author: Tim Huang Date: Tue Apr 23 14:06:28 2024 +0800 drm/amdgpu: fix uninitialized scalar variable warning [ Upstream commit 9a5f15d2a29d06ce5bd50919da7221cda92afb69 ] Clear warning that uses uninitialized value fw_size. Signed-off-by: Tim Huang Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8e5cbc820ab4a0029e0765b47cb2b38354b02527 Author: Alex Hung Date: Mon Apr 15 19:02:56 2024 -0600 drm/amd/display: Fix uninitialized variables in DM [ Upstream commit f95bcb041f213a5da3da5fcaf73269bd13dba945 ] This fixes 11 UNINIT issues reported by Coverity. Reviewed-by: Hersen Wu Acked-by: Wayne Lin Signed-off-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 95ad20ee3c4efbb91f9a4ab08e070aa3697f5879 Author: Alex Hung Date: Mon Apr 22 13:52:27 2024 -0600 drm/amd/display: Skip finding free audio for unknown engine_id [ Upstream commit 1357b2165d9ad94faa4c4a20d5e2ce29c2ff29c3 ] [WHY] ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio. [HOW] Skip and return NULL. This fixes 2 OVERRUN issues reported by Coverity. Reviewed-by: Rodrigo Siqueira Acked-by: Wayne Lin Signed-off-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 96bf81cc1bd058bb8af6e755a548e926e934dfd1 Author: Alex Hung Date: Mon Apr 22 18:07:17 2024 -0600 drm/amd/display: Check pipe offset before setting vblank [ Upstream commit 5396a70e8cf462ec5ccf2dc8de103c79de9489e6 ] pipe_ctx has a size of MAX_PIPES so checking its index before accessing the array. This fixes an OVERRUN issue reported by Coverity. Reviewed-by: Rodrigo Siqueira Acked-by: Wayne Lin Signed-off-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9933eca6ada0cd612e19522e7a319bcef464c0eb Author: Alex Hung Date: Thu Apr 18 13:27:43 2024 -0600 drm/amd/display: Check index msg_id before read or write [ Upstream commit 59d99deb330af206a4541db0c4da8f73880fba03 ] [WHAT] msg_id is used as an array index and it cannot be a negative value, and therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1). [HOW] Check whether msg_id is valid before reading and setting. This fixes 4 OVERRUN issues reported by Coverity. Reviewed-by: Rodrigo Siqueira Acked-by: Wayne Lin Signed-off-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e55077badb9054630856cbefc099ad148a446648 Author: Ma Jun Date: Mon Apr 22 10:07:51 2024 +0800 drm/amdgpu: Initialize timestamp for some legacy SOCs [ Upstream commit 2e55bcf3d742a4946d862b86e39e75a95cc6f1c0 ] Initialize the interrupt timestamp for some legacy SOCs to fix the coverity issue "Uninitialized scalar variable" Signed-off-by: Ma Jun Suggested-by: Christian König Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 855ae72c20310e5402b2317fc537d911e87537ef Author: Jesse Zhang Date: Wed Apr 24 17:10:46 2024 +0800 drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc [ Upstream commit 88a9a467c548d0b3c7761b4fd54a68e70f9c0944 ] Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian) Signed-off-by: Jesse Zhang Suggested-by: Christian König Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 646e13f0a65b1930a4fa838f31bf763dbb4307a3 Author: Ma Jun Date: Mon Apr 22 14:47:52 2024 +0800 drm/amdgpu: Fix uninitialized variable warnings [ Upstream commit 60c448439f3b5db9431e13f7f361b4074d0e8594 ] return 0 to avoid returning an uninitialized variable r Signed-off-by: Ma Jun Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5c217253c76c94f76d1df31d0bbdcb88dc07be91 Author: Fei Shao Date: Thu Dec 21 09:17:46 2023 +0000 media: mediatek: vcodec: Only free buffer VA that is not NULL [ Upstream commit eb005c801ec70ff4307727bd3bd6e8280169ef32 ] In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice. We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings. Signed-off-by: Fei Shao Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Sebastian Fricke Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b502d4a08875ea2b4ea5d5b28dc7c991c8b90cfb Author: Hailey Mothershead Date: Mon Apr 15 22:19:15 2024 +0000 crypto: aead,cipher - zeroize key buffer after use [ Upstream commit 23e4099bdc3c8381992f9eb975c79196d6755210 ] I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key. Signed-off-by: Hailey Mothershead Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1ee644460fe8373a6655df54ab653e7d304d82b6 Author: Atish Patra Date: Sat Apr 20 08:17:26 2024 -0700 RISC-V: KVM: Fix the initial sample period value [ Upstream commit 57990ab90ce31aadac0d5a6293f5582e24ff7521 ] The initial sample period value when counter value is not assigned should be set to maximum value supported by the counter width. Otherwise, it may result in spurious interrupts. Reviewed-by: Andrew Jones Signed-off-by: Atish Patra Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20240420151741.962500-11-atishp@rivosinc.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit e7d193073a223663612301c659e53795b991ca89 Author: Eduard Zingerman Date: Tue Apr 23 18:28:21 2024 -0700 selftests/bpf: dummy_st_ops should reject 0 for non-nullable params [ Upstream commit 6a2d30d3c5bf9f088dcfd5f3746b04d84f2fab83 ] Check if BPF_PROG_TEST_RUN for bpf_dummy_struct_ops programs rejects execution if NULL is passed for non-nullable parameter. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20240424012821.595216-6-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a1a629fc373c9179d34f5f86c1bc8222edfa0898 Author: Eduard Zingerman Date: Tue Apr 23 18:28:19 2024 -0700 selftests/bpf: do not pass NULL for non-nullable params in dummy_st_ops [ Upstream commit f612210d456a0b969a0adca91e68dbea0e0ea301 ] dummy_st_ops.test_2 and dummy_st_ops.test_sleepable do not have their 'state' parameter marked as nullable. Update dummy_st_ops.c to avoid passing NULL for such parameters, as the next patch would allow kernel to enforce this restriction. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20240424012821.595216-4-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 264451a364dba5ca6cb2878126a9798dfc0b1a06 Author: Eduard Zingerman Date: Tue Apr 23 18:28:18 2024 -0700 selftests/bpf: adjust dummy_st_ops_success to detect additional error [ Upstream commit 3b3b84aacb4420226576c9732e7b539ca7b79633 ] As reported by Jose E. Marchesi in off-list discussion, GCC and LLVM generate slightly different code for dummy_st_ops_success/test_1(): SEC("struct_ops/test_1") int BPF_PROG(test_1, struct bpf_dummy_ops_state *state) { int ret; if (!state) return 0xf2f3f4f5; ret = state->val; state->val = 0x5a; return ret; } GCC-generated LLVM-generated ---------------------------- --------------------------- 0: r1 = *(u64 *)(r1 + 0x0) 0: w0 = -0xd0c0b0b 1: if r1 == 0x0 goto 5f 1: r1 = *(u64 *)(r1 + 0x0) 2: r0 = *(s32 *)(r1 + 0x0) 2: if r1 == 0x0 goto 6f 3: *(u32 *)(r1 + 0x0) = 0x5a 3: r0 = *(u32 *)(r1 + 0x0) 4: exit 4: w2 = 0x5a 5: r0 = -0xd0c0b0b 5: *(u32 *)(r1 + 0x0) = r2 6: exit 6: exit If the 'state' argument is not marked as nullable in net/bpf/bpf_dummy_struct_ops.c, the verifier would assume that 'r1 == 0x0' is never true: - for the GCC version, this means that instructions #5-6 would be marked as dead and removed; - for the LLVM version, all instructions would be marked as live. The test dummy_st_ops/dummy_init_ret_value actually sets the 'state' parameter to NULL. Therefore, when the 'state' argument is not marked as nullable, the GCC-generated version of the code would trigger a NULL pointer dereference at instruction #3. This patch updates the test_1() test case to always follow a shape similar to the GCC-generated version above, in order to verify whether the 'state' nullability is marked correctly. Reported-by: Jose E. Marchesi Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20240424012821.595216-3-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b6ded5316ec56e973dcf5f9997945aad01a9f062 Author: John Meneghini Date: Wed Apr 3 11:01:55 2024 -0400 scsi: qedf: Make qedf_execute_tmf() non-preemptible [ Upstream commit 0d8b637c9c5eeaa1a4e3dfb336f3ff918eb64fec ] Stop calling smp_processor_id() from preemptible code in qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel. [ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646 [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf] Tested-by: Guangwu Zhang Cc: Saurav Kashyap Cc: Nilesh Javali Signed-off-by: John Meneghini Link: https://lore.kernel.org/r/20240403150155.412954-1-jmeneghi@redhat.com Acked-by: Saurav Kashyap Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b8c5f635997f49c625178d1a0cb32a80ed33abe6 Author: Michael Guralnik Date: Tue Apr 16 15:01:44 2024 +0300 IB/core: Implement a limit on UMAD receive List [ Upstream commit ca0b44e20a6f3032224599f02e7c8fb49525c894 ] The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full. Signed-off-by: Michael Guralnik Reviewed-by: Mark Zhang Link: https://lore.kernel.org/r/7197cb58a7d9e78399008f25036205ceab07fbd5.1713268818.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c15bb7c940be787b43fc2716b1cbd27286ef9cdf Author: Ricardo Ribalda Date: Thu Apr 11 21:17:56 2024 +0000 media: dvb-usb: dib0700_devices: Add missing release_firmware() [ Upstream commit 4b267c23ee064bd24c6933df0588ad1b6e111145 ] Add missing release_firmware on the error paths. drivers/media/usb/dvb-usb/dib0700_devices.c:2415 stk9090m_frontend_attach() warn: 'state->frontend_firmware' from request_firmware() not released on lines: 2415. drivers/media/usb/dvb-usb/dib0700_devices.c:2497 nim9090md_frontend_attach() warn: 'state->frontend_firmware' from request_firmware() not released on lines: 2489,2497. Signed-off-by: Ricardo Ribalda Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 47abb68e17349da3dde5c16ce10b8a724fcf5c54 Author: Ricardo Ribalda Date: Wed Apr 10 12:24:37 2024 +0000 media: dvb: as102-fe: Fix as10x_register_addr packing [ Upstream commit 309422d280748c74f57f471559980268ac27732a ] This structure is embedded in multiple other structures that are packed, which conflicts with it being aligned. drivers/media/usb/as102/as10x_cmd.h:379:30: warning: field reg_addr within 'struct as10x_dump_memory::(unnamed at drivers/media/usb/as102/as10x_cmd.h:373:2)' is less aligned than 'struct as10x_register_addr' and is usually due to 'struct as10x_dump_memory::(unnamed at drivers/media/usb/as102/as10x_cmd.h:373:2)' being packed, which can lead to unaligned accesses [-Wunaligned-access] Mark it as being packed. Marking the inner struct as 'packed' does not change the layout, since the whole struct is already packed, it just silences the clang warning. See also this llvm discussion: https://github.com/llvm/llvm-project/issues/55520 Signed-off-by: Ricardo Ribalda Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 0f37946c62c48a907625348cbc720a7a0c547d1e Author: Mahesh Salgaonkar Date: Wed Apr 10 10:00:06 2024 +0530 powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt. [ Upstream commit 0db880fc865ffb522141ced4bfa66c12ab1fbb70 ] nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area. Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area. With kernel command line "percpu_alloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early: [ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8 Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded. Reviewed-by: Christophe Leroy Tested-by: Shirisha Ganta Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Link: https://msgid.link/20240410043006.81577-1-mahesh@linux.ibm.com Signed-off-by: Sasha Levin commit 04d531b9a1875846d4f89953b469ad463aa7a770 Author: Erico Nunes Date: Tue Apr 2 00:43:28 2024 +0200 drm/lima: fix shared irq handling on driver remove [ Upstream commit a6683c690bbfd1f371510cb051e8fa49507f3f5e ] lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks. Signed-off-by: Erico Nunes Signed-off-by: Qiang Yu Link: https://patchwork.freedesktop.org/patch/msgid/20240401224329.1228468-2-nunes.erico@gmail.com Signed-off-by: Sasha Levin commit 7fc8d9a525b5c3f8dfa5ed50901e764d8ede7e1e Author: Chenghai Huang Date: Sun Apr 7 15:59:53 2024 +0800 crypto: hisilicon/debugfs - Fix debugfs uninit process issue [ Upstream commit 8be0913389718e8d27c4f1d4537b5e1b99ed7739 ] During the zip probe process, the debugfs failure does not stop the probe. When debugfs initialization fails, jumping to the error branch will also release regs, in addition to its own rollback operation. As a result, it may be released repeatedly during the regs uninit process. Therefore, the null check needs to be added to the regs uninit process. Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3ead19aa341de89a8c3d88a091d8093ebea622e8 Author: George Stark Date: Thu Apr 11 19:10:32 2024 +0300 leds: an30259a: Use devm_mutex_init() for mutex initialization [ Upstream commit c382e2e3eccb6b7ca8c7aff5092c1668428e7de6 ] In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead. Signed-off-by: George Stark Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240411161032.609544-9-gnstark@salutedevices.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 7d2a6abec028a4769ed8d3008a59e14df9cb7528 Author: George Stark Date: Thu Apr 11 19:10:25 2024 +0300 locking/mutex: Introduce devm_mutex_init() [ Upstream commit 4cd47222e435dec8e3787614924174f53fcfb5ae ] Using of devm API leads to a certain order of releasing resources. So all dependent resources which are not devm-wrapped should be deleted with respect to devm-release order. Mutex is one of such objects that often is bound to other resources and has no own devm wrapping. Since mutex_destroy() actually does nothing in non-debug builds frequently calling mutex_destroy() is just ignored which is safe for now but wrong formally and can lead to a problem if mutex_destroy() will be extended so introduce devm_mutex_init(). Suggested-by: Christophe Leroy Signed-off-by: George Stark Reviewed-by: Christophe Leroy Reviewed-by: Andy Shevchenko Reviewed-by: Marek Behún Acked-by: Waiman Long Link: https://lore.kernel.org/r/20240411161032.609544-2-gnstark@salutedevices.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin