commit 711d99f845cdb587b7d7cf5e56c289c3d96d27c5 Author: Greg Kroah-Hartman Date: Sun Nov 17 14:59:40 2024 +0100 Linux 5.10.230 Link: https://lore.kernel.org/r/20241115063725.561151311@linuxfoundation.org Tested-by: Dominique Martinet Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Mark Brown Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Signed-off-by: Greg Kroah-Hartman commit 918326996932da6483dbb81c26f3f9f745a17b1d Author: Linus Torvalds Date: Mon Oct 21 11:57:38 2024 -0700 9p: fix slab cache name creation for real commit a360f311f57a36e96d88fa8086b749159714dcd2 upstream. This was attempted by using the dev_name in the slab cache name, but as Omar Sandoval pointed out, that can be an arbitrary string, eg something like "/dev/root". Which in turn trips verify_dirent_name(), which fails if a filename contains a slash. So just make it use a sequence counter, and make it an atomic_t to avoid any possible races or locking issues. Reported-and-tested-by: Omar Sandoval Link: https://lore.kernel.org/all/ZxafcO8KWMlXaeWE@telecaster.dhcp.thefacebook.com/ Fixes: 79efebae4afc ("9p: Avoid creating multiple slab caches with the same name") Acked-by: Vlastimil Babka Cc: Dominique Martinet Cc: Thorsten Leemhuis Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d02492863023431c31f85d570f718433c22b9311 Author: Qun-Wei Lin Date: Fri Oct 25 16:58:11 2024 +0800 mm: krealloc: Fix MTE false alarm in __do_krealloc commit 704573851b51808b45dae2d62059d1d8189138a2 upstream. This patch addresses an issue introduced by commit 1a83a716ec233 ("mm: krealloc: consider spare memory for __GFP_ZERO") which causes MTE (Memory Tagging Extension) to falsely report a slab-out-of-bounds error. The problem occurs when zeroing out spare memory in __do_krealloc. The original code only considered software-based KASAN and did not account for MTE. It does not reset the KASAN tag before calling memset, leading to a mismatch between the pointer tag and the memory tag, resulting in a false positive. Example of the error: ================================================================== swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188 swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1 swapper/0: Pointer tag: [f4], memory tag: [fe] swapper/0: swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12. swapper/0: Hardware name: MT6991(ENG) (DT) swapper/0: Call trace: swapper/0: dump_backtrace+0xfc/0x17c swapper/0: show_stack+0x18/0x28 swapper/0: dump_stack_lvl+0x40/0xa0 swapper/0: print_report+0x1b8/0x71c swapper/0: kasan_report+0xec/0x14c swapper/0: __do_kernel_fault+0x60/0x29c swapper/0: do_bad_area+0x30/0xdc swapper/0: do_tag_check_fault+0x20/0x34 swapper/0: do_mem_abort+0x58/0x104 swapper/0: el1_abort+0x3c/0x5c swapper/0: el1h_64_sync_handler+0x80/0xcc swapper/0: el1h_64_sync+0x68/0x6c swapper/0: __memset+0x84/0x188 swapper/0: btf_populate_kfunc_set+0x280/0x3d8 swapper/0: __register_btf_kfunc_id_set+0x43c/0x468 swapper/0: register_btf_kfunc_id_set+0x48/0x60 swapper/0: register_nf_nat_bpf+0x1c/0x40 swapper/0: nf_nat_init+0xc0/0x128 swapper/0: do_one_initcall+0x184/0x464 swapper/0: do_initcall_level+0xdc/0x1b0 swapper/0: do_initcalls+0x70/0xc0 swapper/0: do_basic_setup+0x1c/0x28 swapper/0: kernel_init_freeable+0x144/0x1b8 swapper/0: kernel_init+0x20/0x1a8 swapper/0: ret_from_fork+0x10/0x20 ================================================================== Fixes: 1a83a716ec233 ("mm: krealloc: consider spare memory for __GFP_ZERO") Signed-off-by: Qun-Wei Lin Acked-by: David Rientjes Signed-off-by: Vlastimil Babka Signed-off-by: Greg Kroah-Hartman commit b17397a0a5c56e111f61cb5b77d162664dc00de9 Author: Hagar Hemdan Date: Tue Jun 4 13:05:27 2024 +0000 io_uring: fix possible deadlock in io_register_iowq_max_workers() commit 73254a297c2dd094abec7c9efee32455ae875bdf upstream. The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock before acquiring sqd->lock"), this can lead to a potential deadlock situation. To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call. This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock. Suggested-by: Maximilian Heyne Signed-off-by: Hagar Hemdan Link: https://lore.kernel.org/r/20240604130527.3597-1-hagarhem@amazon.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dd7a728d5c0d543faddcd6a94bdf0198c144d5a1 Author: Li Nan Date: Sat May 27 15:22:16 2023 +0800 md/raid10: improve code of mrdev in raid10_sync_request commit 59f8f0b54c8ffb4521f6bbd1cb6f4dfa5022e75e upstream. 'need_recover' and 'mrdev' are equivalent in raid10_sync_request(), and inc mrdev->nr_pending is unreasonable if don't need recovery. Replace 'need_recover' with 'mrdev', and only inc nr_pending when needed. Signed-off-by: Li Nan Reviewed-by: Yu Kuai Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20230527072218.2365857-3-linan666@huaweicloud.com Cc: Hagar Gamal Halim Signed-off-by: Greg Kroah-Hartman commit 8ea0b8e32bed065df4c3e1b8a8dc49a5abb979cd Author: Reinhard Speyerer Date: Fri Oct 18 22:52:55 2024 +0200 net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition [ Upstream commit 64761c980cbf71fb7a532a8c7299907ea972a88c ] Add Fibocom FG132 0x0112 composition: T: Bus=03 Lev=02 Prnt=06 Port=01 Cnt=02 Dev#= 10 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2cb7 ProdID=0112 Rev= 5.15 S: Manufacturer=Fibocom Wireless Inc. S: Product=Fibocom Module S: SerialNumber=xxxxxxxx C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Signed-off-by: Reinhard Speyerer Link: https://patch.msgid.link/ZxLKp5YZDy-OM0-e@arcor.de Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9db25c2b41c34963c3ccf473b08171f87670652e Author: Alessandro Zanni Date: Thu Oct 17 14:05:51 2024 +0200 fs: Fix uninitialized value issue in from_kuid and from_kgid [ Upstream commit 15f34347481648a567db67fb473c23befb796af5 ] ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0. Reported-by: syzbot+6c55f725d1bdc8c52058@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6c55f725d1bdc8c52058 Signed-off-by: Alessandro Zanni Link: https://lore.kernel.org/r/20241017120553.55331-1-alessandro.zanni87@gmail.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 35b4795a7ebfe9c7a8f77c01936241d6bbf78c2d Author: Yuan Can Date: Thu Oct 17 09:38:12 2024 +0800 vDPA/ifcvf: Fix pci_read_config_byte() return code handling [ Upstream commit 7f8825b2a78ac392d3fbb3a2e65e56d9e39d75e9 ] ifcvf_init_hw() uses pci_read_config_byte() that returns PCIBIOS_* codes. The error handling, however, assumes the codes are normal errnos because it checks for < 0. Convert the error check to plain non-zero check. Fixes: 5a2414bc454e ("virtio: Intel IFC VF driver for VDPA") Signed-off-by: Yuan Can Message-Id: <20241017013812.129952-1-yuancan@huawei.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Acked-by: Zhu Lingshan Signed-off-by: Sasha Levin commit 7e222d2c7f9ab06280110edd3b0c4340ff9f2a29 Author: Michael Ellerman Date: Fri Sep 20 19:35:20 2024 +1000 powerpc/powernv: Free name on error in opal_event_init() [ Upstream commit cf8989d20d64ad702a6210c11a0347ebf3852aa7 ] In opal_event_init() if request_irq() fails name is not freed, leading to a memory leak. The code only runs at boot time, there's no way for a user to trigger it, so there's no security impact. Fix the leak by freeing name in the error path. Reported-by: 2639161967 <2639161967@qq.com> Closes: https://lore.kernel.org/linuxppc-dev/87wmjp3wig.fsf@mail.lhotse Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20240920093520.67997-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit b718f71747b7e4e9ed83230f9dcde38110a9cd1c Author: Julian Vetter Date: Thu Oct 10 14:46:01 2024 +0200 sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML [ Upstream commit ad6639f143a0b42d7fb110ad14f5949f7c218890 ] When building for the UM arch and neither INDIRECT_IOMEM=y, nor HAS_IOMEM=y is selected, it will fall back to the implementations from asm-generic/io.h for IO memcpy. But these fall-back functions just do a memcpy. So, instead of depending on UML, add dependency on 'HAS_IOMEM || INDIRECT_IOMEM'. Reviewed-by: Yann Sionneau Signed-off-by: Julian Vetter Link: https://patch.msgid.link/20241010124601.700528-1-jvetter@kalrayinc.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit dc834af641d75834f9fbc4247fa3a70d4fca5afb Author: Herbert Xu Date: Wed Oct 9 16:38:48 2024 +0800 crypto: marvell/cesa - Disable hash algorithms [ Upstream commit e845d2399a00f866f287e0cefbd4fc7d8ef0d2f7 ] Disable cesa hash algorithms by lowering the priority because they appear to be broken when invoked in parallel. This allows them to still be tested for debugging purposes. Reported-by: Klaus Kudielka Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4d8f6679b03ab39734af0cabc883cde5c9c95ff4 Author: Rik van Riel Date: Tue Oct 8 17:07:35 2024 -0400 bpf: use kvzmalloc to allocate BPF verifier environment [ Upstream commit 434247637c66e1be2bc71a9987d4c3f0d8672387 ] The kzmalloc call in bpf_check can fail when memory is very fragmented, which in turn can lead to an OOM kill. Use kvzmalloc to fall back to vmalloc when memory is too fragmented to allocate an order 3 sized bpf verifier environment. Admittedly this is not a very common case, and only happens on systems where memory has already been squeezed close to the limit, but this does not seem like much of a hot path, and it's a simple enough fix. Signed-off-by: Rik van Riel Reviewed-by: Shakeel Butt Link: https://lore.kernel.org/r/20241008170735.16766766@imladris.surriel.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 0bf6971b7d1e0b3fdc5e8bfa7e0f482b9beaf099 Author: WangYuli Date: Mon Oct 7 12:08:03 2024 +0800 HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad [ Upstream commit 7a5ab8071114344f62a8b1e64ed3452a77257d76 ] The behavior of HONOR MagicBook Art 14 touchpad is not consistent after reboots, as sometimes it reports itself as a touchpad, and sometimes as a mouse. Similarly to GLO-GXXX it is possible to call MT_QUIRK_FORCE_GET_FEATURE as a workaround to force set feature in mt_set_input_mode() for such special touchpad device. [jkosina@suse.com: reword changelog a little bit] Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/1040 Signed-off-by: Wentao Guan Signed-off-by: WangYuli Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 2bc339b00fbd4f9365171b4f8347f0800221b99d Author: Pedro Falcato Date: Wed Aug 7 10:47:25 2024 +0100 9p: Avoid creating multiple slab caches with the same name [ Upstream commit 79efebae4afc2221fa814c3cae001bede66ab259 ] In the spirit of [1], avoid creating multiple slab caches with the same name. Instead, add the dev_name into the mix. [1]: https://lore.kernel.org/all/20240807090746.2146479-1-pedro.falcato@gmail.com/ Signed-off-by: Pedro Falcato Reported-by: syzbot+3c5d43e97993e1fa612b@syzkaller.appspotmail.com Message-ID: <20240807094725.2193423-1-pedro.falcato@gmail.com> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 2f4bfcc4c5fa22d8b0a20262c63792d7180b8296 Author: Ioana Ciornei Date: Fri Feb 26 17:30:20 2021 +0200 net: phy: ti: take into account all possible interrupt sources commit 73f476aa1975bae6a792b340f5b26ffcfba869a6 upstream. The previous implementation of .handle_interrupt() did not take into account the fact that all the interrupt status registers should be acknowledged since multiple interrupt sources could be asserted. Fix this by reading all the status registers before exiting with IRQ_NONE or triggering the PHY state machine. Fixes: 1d1ae3c6ca3f ("net: phy: ti: implement generic .handle_interrupt() callback") Reported-by: Sven Schuchmann Signed-off-by: Ioana Ciornei Link: https://lore.kernel.org/r/20210226153020.867852-1-ciorneiioana@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 16a8ebc88fe20a776a298a13f6af0002eb286707 Author: Jan Schär Date: Tue Jul 5 15:57:46 2022 +0200 ALSA: usb-audio: Add endianness annotations commit 61c606a43b6c74556e35acc645c7a1b6a67c2af9 upstream. Fixes: 4b8ea38fabab ("ALSA: usb-audio: Support jack detection on Dell dock") Reported-by: kernel test robot Link: https://lore.kernel.org/r/202207051932.qUilU0am-lkp@intel.com Signed-off-by: Jan Schär Link: https://lore.kernel.org/r/20220705135746.13713-1-jan@jschaer.ch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit eb1bdcb7dfc30b24495ee4c5533af0ed135cb5f1 Author: Hyunwoo Kim Date: Tue Oct 22 09:32:56 2024 +0200 vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans commit 6ca575374dd9a507cdd16dfa0e78c2e9e20bd05f upstream. During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL. Cc: stable Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") Signed-off-by: Hyunwoo Kim Signed-off-by: Wongi Lee Signed-off-by: Greg Kroah-Hartman Message-Id: <2024102245-strive-crib-c8d3@gregkh> Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 414476c4fb11be070c09ab8f3e75c9ee324a108a Author: Hyunwoo Kim Date: Wed Nov 6 04:36:04 2024 -0500 hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer commit e629295bd60abf4da1db85b82819ca6a4f6c1e79 upstream. When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL. Signed-off-by: Hyunwoo Kim Reviewed-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/Zys4hCj61V+mQfX2@v4bel-B760M-AORUS-ELITE-AX Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0d71863c19be3f079f4c715da71b6efb9509a286 Author: Jan Schär Date: Tue Oct 29 23:12:49 2024 +0100 ALSA: usb-audio: Add quirks for Dell WD19 dock [ Upstream commit 4413665dd6c528b31284119e3571c25f371e1c36 ] The WD19 family of docks has the same audio chipset as the WD15. This change enables jack detection on the WD19. We don't need the dell_dock_mixer_init quirk for the WD19. It is only needed because of the dell_alc4020_map quirk for the WD15 in mixer_maps.c, which disables the volume controls. Even for the WD15, this quirk was apparently only needed when the dock firmware was not updated. Signed-off-by: Jan Schär Cc: Link: https://patch.msgid.link/20241029221249.15661-1-jan@jschaer.ch Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4dc9c1e83aeb812506bcbaf7f4d7526aac744bed Author: Jan Schär Date: Mon Jun 27 19:18:54 2022 +0200 ALSA: usb-audio: Support jack detection on Dell dock [ Upstream commit 4b8ea38fabab45ad911a32a336416062553dfe9c ] The Dell WD15 dock has a headset and a line out port. Add support for detecting if a jack is inserted into one of these ports. For the headset jack, additionally determine if a mic is present. The WD15 contains an ALC4020 USB audio controller and ALC3263 audio codec from Realtek. It is a UAC 1 device, and UAC 1 does not support jack detection. Instead, jack detection works by sending HD Audio commands over vendor-type USB messages. I found out how it works by looking at USB captures on Windows. The audio codec is very similar to the one supported by sound/soc/codecs/rt298.c / rt298.h, some constant names and the mic detection are adapted from there. The realtek_add_jack function is adapted from build_connector_control in sound/usb/mixer.c. I tested this on a WD15 dock with the latest firmware. Signed-off-by: Jan Schär Link: https://lore.kernel.org/r/20220627171855.42338-1-jan@jschaer.ch Signed-off-by: Takashi Iwai Stable-dep-of: 4413665dd6c5 ("ALSA: usb-audio: Add quirks for Dell WD19 dock") Signed-off-by: Sasha Levin commit 6a7e6dcf90fe7721d0863067b6ca9a9442134692 Author: Andrew Kanner Date: Sun Nov 3 20:38:45 2024 +0100 ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() commit 0b63c0e01fba40e3992bc627272ec7b618ccaef7 upstream. Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy. Link: https://lkml.kernel.org/r/20241103193845.2940988-1-andrew.kanner@gmail.com Fixes: 399ff3a748cf ("ocfs2: Handle errors while setting external xattr values.") Signed-off-by: Andrew Kanner Reported-by: syzbot+386ce9e60fa1b18aac5b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/671e13ab.050a0220.2b8c0f.01d0.GAE@google.com/T/ Tested-by: syzbot+386ce9e60fa1b18aac5b@syzkaller.appspotmail.com Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e068a87cf25e50d896a09b73b37841b6438fab50 Author: Marc Zyngier Date: Wed Nov 6 08:44:18 2024 +0000 irqchip/gic-v3: Force propagation of the active state with a read-back commit 464cb98f1c07298c4c10e714ae0c36338d18d316 upstream. Christoffer reports that on some implementations, writing to GICR_ISACTIVER0 (and similar GICD registers) can race badly with a guest issuing a deactivation of that interrupt via the system register interface. There are multiple reasons to this: - this uses an early write-acknoledgement memory type (nGnRE), meaning that the write may only have made it as far as some interconnect by the time the store is considered "done" - the GIC itself is allowed to buffer the write until it decides to take it into account (as long as it is in finite time) The effects are that the activation may not have taken effect by the time the kernel enters the guest, forcing an immediate exit, or that a guest deactivation occurs before the interrupt is active, doing nothing. In order to guarantee that the write to the ISACTIVER register has taken effect, read back from it, forcing the interconnect to propagate the write, and the GIC to process the write before returning the read. Reported-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Acked-by: Christoffer Dall Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20241106084418.3794612-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit bb17f42135f5a3410770eb8fcba684d132a2c5ca Author: Benoît Monin Date: Thu Oct 24 17:09:19 2024 +0200 USB: serial: option: add Quectel RG650V commit 3b05949ba39f305b585452d0e177470607842165 upstream. Add support for Quectel RG650V which is based on Qualcomm SDX65 chip. The composition is DIAG / NMEA / AT / AT / QMI. T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2c7c ProdID=0122 Rev=05.15 S: Manufacturer=Quectel S: Product=RG650V-EU S: SerialNumber=xxxxxxx C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=9ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=9ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=9ms Signed-off-by: Benoît Monin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 6d5bd4bc14d740a6b8d7d365e4d81001b9a64972 Author: Reinhard Speyerer Date: Fri Oct 18 23:07:06 2024 +0200 USB: serial: option: add Fibocom FG132 0x0112 composition commit 393c74ccbd847bacf18865a01b422586fc7341cf upstream. Add Fibocom FG132 0x0112 composition: T: Bus=03 Lev=02 Prnt=06 Port=01 Cnt=02 Dev#= 10 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2cb7 ProdID=0112 Rev= 5.15 S: Manufacturer=Fibocom Wireless Inc. S: Product=Fibocom Module S: SerialNumber=xxxxxxxx C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Signed-off-by: Reinhard Speyerer Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit c5748d95608c7933c6af9af2fa4737437965d801 Author: Jack Wu Date: Wed Nov 6 18:50:29 2024 +0800 USB: serial: qcserial: add support for Sierra Wireless EM86xx commit 25eb47eed52979c2f5eee3f37e6c67714e02c49c upstream. Add support for Sierra Wireless EM86xx with USB-id 0x1199:0x90e5 and 0x1199:0x90e4. 0x1199:0x90e5 T: Bus=03 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 14 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1199 ProdID=90e5 Rev= 5.15 S: Manufacturer=Sierra Wireless, Incorporated S: Product=Semtech EM8695 Mobile Broadband Adapter S: SerialNumber=004403161882339 C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=qcserial E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=qcserial E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0x1199:0x90e4 T: Bus=03 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 16 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1199 ProdID=90e4 Rev= 0.00 S: Manufacturer=Sierra Wireless, Incorporated S: SerialNumber=004403161882339 C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 2mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=qcserial E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Jack Wu Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit e567fc8f7a4460e486e52c9261b1e8b9f5dc42aa Author: Dan Carpenter Date: Thu Oct 31 12:48:30 2024 +0300 USB: serial: io_edgeport: fix use after free in debug printk commit 37bb5628379295c1254c113a407cab03a0f4d0b4 upstream. The "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb) is a use after free of the "urb" pointer. Store the "dev" pointer at the start of the function to avoid this issue. Fixes: 984f68683298 ("USB: serial: io_edgeport.c: remove dbg() usage") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d76923164705821aa1b01b8d9d1741f20c654ab4 Author: Dan Carpenter Date: Mon Nov 4 20:16:42 2024 +0300 usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() commit 7dd08a0b4193087976db6b3ee7807de7e8316f96 upstream. The "*cmd" variable can be controlled by the user via debugfs. That means "new_cam" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control() Fixes: 170a6726d0e2 ("usb: typec: ucsi: add support for separate DP altmode devices") Cc: stable Signed-off-by: Dan Carpenter Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/325102b3-eaa8-4918-a947-22aca1146586@stanley.mountain Signed-off-by: Greg Kroah-Hartman commit 6e2848d1c8c0139161e69ac0a94133e90e9988e8 Author: Zijun Hu Date: Tue Oct 29 23:13:38 2024 +0800 usb: musb: sunxi: Fix accessing an released usb phy commit 498dbd9aea205db9da674994b74c7bf8e18448bd upstream. Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit(). Fixes: 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20241029-sunxi_fix-v1-1-9431ed2ab826@quicinc.com Signed-off-by: Greg Kroah-Hartman commit 5dd3f5a9244a827b61a4d66c524045c06e06325d Author: Qi Xi Date: Fri Nov 1 11:48:03 2024 +0800 fs/proc: fix compile warning about variable 'vmcore_mmap_ops' commit b8ee299855f08539e04d6c1a6acb3dc9e5423c00 upstream. When build with !CONFIG_MMU, the variable 'vmcore_mmap_ops' is defined but not used: >> fs/proc/vmcore.c:458:42: warning: unused variable 'vmcore_mmap_ops' 458 | static const struct vm_operations_struct vmcore_mmap_ops = { Fix this by only defining it when CONFIG_MMU is enabled. Link: https://lkml.kernel.org/r/20241101034803.9298-1-xiqi2@huawei.com Fixes: 9cb218131de1 ("vmcore: introduce remap_oldmem_pfn_range()") Signed-off-by: Qi Xi Reported-by: kernel test robot Closes: https://lore.kernel.org/lkml/202410301936.GcE8yUos-lkp@intel.com/ Cc: Baoquan He Cc: Dave Young Cc: Michael Holzheu Cc: Vivek Goyal Cc: Wang ShaoBo Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit faff5bbb2762c44ec7426037b3000e77a11d6773 Author: Benoit Sevens Date: Thu Nov 7 14:22:02 2024 +0000 media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format commit ecf2b43018da9579842c774b7f35dbe11b5c38dd upstream. This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming. Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver") Signed-off-by: Benoit Sevens Cc: stable@vger.kernel.org Acked-by: Greg Kroah-Hartman Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 547087307bc19417b4f2bc85ba9664a3e8db5a6a Author: Eric Dumazet Date: Tue Oct 8 14:31:10 2024 +0000 net: do not delay dst_entries_add() in dst_release() commit ac888d58869bb99753e7652be19a151df9ecb35d upstream. dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels. Fixes: f88649721268 ("ipv4: fix dst race in sk_dst_get()") Closes: https://lore.kernel.org/lkml/CANn89iLCCGsP7SFn9HKpvnKu96Td4KD08xf7aGtiYgZnkjaL=w@mail.gmail.com/T/ Reported-by: Naresh Kamboju Tested-by: Linux Kernel Functional Testing Tested-by: Naresh Kamboju Signed-off-by: Eric Dumazet Cc: Xin Long Cc: Steffen Klassert Reviewed-by: Xin Long Link: https://patch.msgid.link/20241008143110.1064899-1-edumazet@google.com Signed-off-by: Paolo Abeni [ resolved conflict due to bc9d3a9f2afc ("net: dst: Switch to rcuref_t reference counting") is not in the tree ] Signed-off-by: Abdelkareem Abdelsaamad Signed-off-by: Greg Kroah-Hartman commit 83aa0c996417f0521caa5ccc1452ee6400043899 Author: Riccardo Mancini Date: Mon Nov 4 19:27:36 2024 +0800 perf session: Add missing evlist__delete when deleting a session commit cf96b8e45a9bf74d2a6f1e1f88a41b10e9357c6b upstream. ASan reports a memory leak caused by evlist not being deleted on exit in perf-report, perf-script and perf-data. The problem is caused by evlist->session not being deleted, which is allocated in perf_session__read_header, called in perf_session__new if perf_data is in read mode. In case of write mode, the session->evlist is filled by the caller. This patch solves the problem by calling evlist__delete in perf_session__delete if perf_data is in read mode. Changes in v2: - call evlist__delete from within perf_session__delete v1: https://lore.kernel.org/lkml/20210621234317.235545-1-rickyman7@gmail.com/ ASan report follows: $ ./perf script report flamegraph ================================================================= ==227640==ERROR: LeakSanitizer: detected memory leaks Indirect leak of 2704 byte(s) in 1 object(s) allocated from: #0 0x4f4137 in calloc (/home/user/linux/tools/perf/perf+0x4f4137) #1 0xbe3d56 in zalloc /home/user/linux/tools/lib/perf/../../lib/zalloc.c:8:9 #2 0x7f999e in evlist__new /home/user/linux/tools/perf/util/evlist.c:77:26 #3 0x8ad938 in perf_session__read_header /home/user/linux/tools/perf/util/header.c:3797:20 #4 0x8ec714 in perf_session__open /home/user/linux/tools/perf/util/session.c:109:6 #5 0x8ebe83 in perf_session__new /home/user/linux/tools/perf/util/session.c:213:10 #6 0x60c6de in cmd_script /home/user/linux/tools/perf/builtin-script.c:3856:12 #7 0x7b2930 in run_builtin /home/user/linux/tools/perf/perf.c:313:11 #8 0x7b120f in handle_internal_command /home/user/linux/tools/perf/perf.c:365:8 #9 0x7b2493 in run_argv /home/user/linux/tools/perf/perf.c:409:2 #10 0x7b0c89 in main /home/user/linux/tools/perf/perf.c:539:3 #11 0x7f5260654b74 (/lib64/libc.so.6+0x27b74) Indirect leak of 568 byte(s) in 1 object(s) allocated from: #0 0x4f4137 in calloc (/home/user/linux/tools/perf/perf+0x4f4137) #1 0xbe3d56 in zalloc /home/user/linux/tools/lib/perf/../../lib/zalloc.c:8:9 #2 0x80ce88 in evsel__new_idx /home/user/linux/tools/perf/util/evsel.c:268:24 #3 0x8aed93 in evsel__new /home/user/linux/tools/perf/util/evsel.h:210:9 #4 0x8ae07e in perf_session__read_header /home/user/linux/tools/perf/util/header.c:3853:11 #5 0x8ec714 in perf_session__open /home/user/linux/tools/perf/util/session.c:109:6 #6 0x8ebe83 in perf_session__new /home/user/linux/tools/perf/util/session.c:213:10 #7 0x60c6de in cmd_script /home/user/linux/tools/perf/builtin-script.c:3856:12 #8 0x7b2930 in run_builtin /home/user/linux/tools/perf/perf.c:313:11 #9 0x7b120f in handle_internal_command /home/user/linux/tools/perf/perf.c:365:8 #10 0x7b2493 in run_argv /home/user/linux/tools/perf/perf.c:409:2 #11 0x7b0c89 in main /home/user/linux/tools/perf/perf.c:539:3 #12 0x7f5260654b74 (/lib64/libc.so.6+0x27b74) Indirect leak of 264 byte(s) in 1 object(s) allocated from: #0 0x4f4137 in calloc (/home/user/linux/tools/perf/perf+0x4f4137) #1 0xbe3d56 in zalloc /home/user/linux/tools/lib/perf/../../lib/zalloc.c:8:9 #2 0xbe3e70 in xyarray__new /home/user/linux/tools/lib/perf/xyarray.c:10:23 #3 0xbd7754 in perf_evsel__alloc_id /home/user/linux/tools/lib/perf/evsel.c:361:21 #4 0x8ae201 in perf_session__read_header /home/user/linux/tools/perf/util/header.c:3871:7 #5 0x8ec714 in perf_session__open /home/user/linux/tools/perf/util/session.c:109:6 #6 0x8ebe83 in perf_session__new /home/user/linux/tools/perf/util/session.c:213:10 #7 0x60c6de in cmd_script /home/user/linux/tools/perf/builtin-script.c:3856:12 #8 0x7b2930 in run_builtin /home/user/linux/tools/perf/perf.c:313:11 #9 0x7b120f in handle_internal_command /home/user/linux/tools/perf/perf.c:365:8 #10 0x7b2493 in run_argv /home/user/linux/tools/perf/perf.c:409:2 #11 0x7b0c89 in main /home/user/linux/tools/perf/perf.c:539:3 #12 0x7f5260654b74 (/lib64/libc.so.6+0x27b74) Indirect leak of 32 byte(s) in 1 object(s) allocated from: #0 0x4f4137 in calloc (/home/user/linux/tools/perf/perf+0x4f4137) #1 0xbe3d56 in zalloc /home/user/linux/tools/lib/perf/../../lib/zalloc.c:8:9 #2 0xbd77e0 in perf_evsel__alloc_id /home/user/linux/tools/lib/perf/evsel.c:365:14 #3 0x8ae201 in perf_session__read_header /home/user/linux/tools/perf/util/header.c:3871:7 #4 0x8ec714 in perf_session__open /home/user/linux/tools/perf/util/session.c:109:6 #5 0x8ebe83 in perf_session__new /home/user/linux/tools/perf/util/session.c:213:10 #6 0x60c6de in cmd_script /home/user/linux/tools/perf/builtin-script.c:3856:12 #7 0x7b2930 in run_builtin /home/user/linux/tools/perf/perf.c:313:11 #8 0x7b120f in handle_internal_command /home/user/linux/tools/perf/perf.c:365:8 #9 0x7b2493 in run_argv /home/user/linux/tools/perf/perf.c:409:2 #10 0x7b0c89 in main /home/user/linux/tools/perf/perf.c:539:3 #11 0x7f5260654b74 (/lib64/libc.so.6+0x27b74) Indirect leak of 7 byte(s) in 1 object(s) allocated from: #0 0x4b8207 in strdup (/home/user/linux/tools/perf/perf+0x4b8207) #1 0x8b4459 in evlist__set_event_name /home/user/linux/tools/perf/util/header.c:2292:16 #2 0x89d862 in process_event_desc /home/user/linux/tools/perf/util/header.c:2313:3 #3 0x8af319 in perf_file_section__process /home/user/linux/tools/perf/util/header.c:3651:9 #4 0x8aa6e9 in perf_header__process_sections /home/user/linux/tools/perf/util/header.c:3427:9 #5 0x8ae3e7 in perf_session__read_header /home/user/linux/tools/perf/util/header.c:3886:2 #6 0x8ec714 in perf_session__open /home/user/linux/tools/perf/util/session.c:109:6 #7 0x8ebe83 in perf_session__new /home/user/linux/tools/perf/util/session.c:213:10 #8 0x60c6de in cmd_script /home/user/linux/tools/perf/builtin-script.c:3856:12 #9 0x7b2930 in run_builtin /home/user/linux/tools/perf/perf.c:313:11 #10 0x7b120f in handle_internal_command /home/user/linux/tools/perf/perf.c:365:8 #11 0x7b2493 in run_argv /home/user/linux/tools/perf/perf.c:409:2 #12 0x7b0c89 in main /home/user/linux/tools/perf/perf.c:539:3 #13 0x7f5260654b74 (/lib64/libc.so.6+0x27b74) SUMMARY: AddressSanitizer: 3728 byte(s) leaked in 7 allocation(s). Signed-off-by: Riccardo Mancini Acked-by: Ian Rogers Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Kan Liang Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210624231926.212208-1-rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Cc: stable@vger.kernel.org # 5.10.228 Signed-off-by: Shuai Xue Signed-off-by: Greg Kroah-Hartman commit 2297d80a13a6f4c828ff938acebd82a2bbc03bb0 Author: Shuai Xue Date: Mon Nov 4 19:27:35 2024 +0800 Revert "perf hist: Add missing puts to hist__account_cycles" Revert "perf hist: Add missing puts to hist__account_cycles" This reverts commit a83fc293acd5c5050a4828eced4a71d2b2fffdd3. On x86 platform, kernel v5.10.228, perf-report command aborts due to "free(): invalid pointer" when perf-record command is run with taken branch stack sampling enabled. This regression can be reproduced with the following steps: - sudo perf record -b - sudo perf report The root cause is that bi[i].to.ms.maps does not always point to thread->maps, which is a buffer dynamically allocated by maps_new(). Instead, it may point to &machine->kmaps, while kmaps is not a pointer but a variable. The original upstream commit c1149037f65b ("perf hist: Add missing puts to hist__account_cycles") worked well because machine->kmaps had been refactored to a pointer by the previous commit 1a97cee604dc ("perf maps: Use a pointer for kmaps"). To this end, just revert commit a83fc293acd5c5050a4828eced4a71d2b2fffdd3. It is worth noting that the memory leak issue, which the reverted patch intended to fix, has been solved by commit cf96b8e45a9b ("perf session: Add missing evlist__delete when deleting a session"). The root cause is that the evlist is not being deleted on exit in perf-report, perf-script, and perf-data. Consequently, the reference count of the thread increased by thread__get() in hist_entry__init() is not decremented in hist_entry__delete(). As a result, thread->maps is not properly freed. Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: K Prateek Nayak Cc: Ravi Bangoria Cc: Sandipan Das Cc: Anshuman Khandual Cc: German Gomez Cc: James Clark Cc: Nick Terrell Cc: Sean Christopherson Cc: Changbin Du Cc: liuwenyu Cc: Yang Jihong Cc: Masami Hiramatsu Cc: Miguel Ojeda Cc: Song Liu Cc: Leo Yan Cc: Kajol Jain Cc: Andi Kleen Cc: Kan Liang Cc: Athira Rajeev Cc: Yanteng Si Cc: Liam Howlett Cc: Paolo Bonzini Cc: stable@vger.kernel.org # 5.10.228 Signed-off-by: Shuai Xue Signed-off-by: Greg Kroah-Hartman commit 82090f94c723dab724b1c32db406091d40448a17 Author: Nikolay Aleksandrov Date: Mon May 13 13:34:19 2024 +0300 net: bridge: xmit: make sure we have at least eth header len bytes commit 8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc upstream. syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming. Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL [1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+a63a1f6a062033cf0f40@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a63a1f6a062033cf0f40 Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Randy MacLeod Signed-off-by: Greg Kroah-Hartman commit 11eab327a2a8bd36c38afbff920ae1bd45588dd4 Author: Michael Walle Date: Thu Nov 11 09:37:13 2021 +0100 spi: fix use-after-free of the add_lock mutex commit 6c53b45c71b4920b5e62f0ea8079a1da382b9434 upstream. Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on SPI buses") introduced a per-controller mutex. But mutex_unlock() of said lock is called after the controller is already freed: spi_unregister_controller(ctlr) -> put_device(&ctlr->dev) -> spi_controller_release(dev) -> mutex_unlock(&ctrl->add_lock) Move the put_device() after the mutex_unlock(). Fixes: 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on SPI buses") Signed-off-by: Michael Walle Reviewed-by: Uwe Kleine-König Reviewed-by: Lukas Wunner Cc: stable@vger.kernel.org # v5.15 Link: https://lore.kernel.org/r/20211111083713.3335171-1-michael@walle.cc Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c8dce228db6f81dbc897a018dfc5c418e917cf64 Author: Mark Brown Date: Fri Oct 8 14:31:57 2021 +0100 spi: Fix deadlock when adding SPI controllers on SPI buses commit 6098475d4cb48d821bdf453c61118c56e26294f0 upstream. Currently we have a global spi_add_lock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of doing so for the parent controller and hence already holding the global spi_add_lock. Since we only care about concurrency within a single SPI bus move the lock to be per controller, avoiding the deadlock. This can be easily triggered in the case of spi-mux. Reported-by: Uwe Kleine-König Signed-off-by: Mark Brown Signed-off-by: Hardik Gohil Signed-off-by: Greg Kroah-Hartman commit 982a2757e725e320a0b80453eb12edaba659832b Author: Pavel Begunkov Date: Sat Jan 9 16:02:57 2021 +0000 splice: don't generate zero-len segement bvecs commit 0f1d344feb534555a0dcd0beafb7211a37c5355e upstream. iter_file_splice_write() may spawn bvec segments with zero-length. In preparation for prohibiting them, filter out by hand at splice level. Reviewed-by: Christoph Hellwig Signed-off-by: Pavel Begunkov Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman commit bf0b0c6d159767c0d1c21f793950d78486690ee0 Author: Filipe Manana Date: Mon Nov 4 12:11:15 2024 +0000 btrfs: reinitialize delayed ref list after deleting it from the list commit c9a75ec45f1111ef530ab186c2a7684d0a0c9245 upstream. At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead. Fixes: 1d57ee941692 ("btrfs: improve delayed refs iterations") CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8fc5ea9231af9122d227c9c13f5e578fca48d2e3 Author: Roberto Sassu Date: Fri Oct 25 16:03:27 2024 +0200 nfs: Fix KMSAN warning in decode_getfattr_attrs() commit dc270d7159699ad6d11decadfce9633f0f71c1db upstream. Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init(). Cc: stable@vger.kernel.org # v3.5.x Fixes: 88034c3d88c2 ("NFSv4.1 mdsthreshold attribute xdr") Signed-off-by: Roberto Sassu Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 485d9232112b17f389b29497ff41b97b3189546b Author: Jens Axboe Date: Thu Oct 31 08:05:44 2024 -0600 io_uring/rw: fix missing NOWAIT check for O_DIRECT start write Commit 1d60d74e852647255bd8e76f5a22dc42531e4389 upstream. When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user. Cc: stable@vger.kernel.org # 5.10+ Reported-by: Peter Mann Link: https://lore.kernel.org/io-uring/38c94aec-81c9-4f62-b44e-1d87f5597644@sh.cz Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f336622838e595868da703c4de4f892a3320de57 Author: Amir Goldstein Date: Thu Aug 17 17:13:34 2023 +0300 io_uring: use kiocb_{start,end}_write() helpers Commit e484fd73f4bdcb00c2188100c2d84e9f3f5c9f7d upstream. Use helpers instead of the open coded dance to silence lockdep warnings. Suggested-by: Jan Kara Signed-off-by: Amir Goldstein Reviewed-by: Jan Kara Reviewed-by: Jens Axboe Message-Id: <20230817141337.1025891-5-amir73il@gmail.com> Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f83a32351efd6c6676fdabd5ab0e680500bc48e0 Author: Amir Goldstein Date: Thu Aug 17 17:13:33 2023 +0300 fs: create kiocb_{start,end}_write() helpers Commit ed0360bbab72b829437b67ebb2f9cfac19f59dfe upstream. aio, io_uring, cachefiles and overlayfs, all open code an ugly variant of file_{start,end}_write() to silence lockdep warnings. Create helpers for this lockdep dance so we can use the helpers in all the callers. Suggested-by: Jan Kara Signed-off-by: Amir Goldstein Reviewed-by: Jan Kara Reviewed-by: Jens Axboe Message-Id: <20230817141337.1025891-4-amir73il@gmail.com> Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 955089c2403c5c75755629517d235ad99650a03c Author: Amir Goldstein Date: Thu Aug 17 17:13:31 2023 +0300 io_uring: rename kiocb_end_write() local helper Commit a370167fe526123637965f60859a9f1f3e1a58b7 upstream. This helper does not take a kiocb as input and we want to create a common helper by that name that takes a kiocb as input. Signed-off-by: Amir Goldstein Reviewed-by: Jan Kara Reviewed-by: Jens Axboe Message-Id: <20230817141337.1025891-2-amir73il@gmail.com> Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 6f383f653d036a52b9482195e256941fe745d022 Author: Zichen Xie Date: Mon Oct 21 14:54:45 2024 -0500 dm-unstriped: cast an operand to sector_t to prevent potential uint32_t overflow commit 5a4510c762fc04c74cff264cd4d9e9f5bf364bae upstream. This was found by a static analyzer. There may be a potential integer overflow issue in unstripe_ctr(). uc->unstripe_offset and uc->unstripe_width are defined as "sector_t"(uint64_t), while uc->unstripe, uc->chunk_size and uc->stripes are all defined as "uint32_t". The result of the calculation will be limited to "uint32_t" without correct casting. So, we recommend adding an extra cast to prevent potential integer overflow. Fixes: 18a5bf270532 ("dm: add unstriped target") Signed-off-by: Zichen Xie Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 483b7261b35a9d369082ab298a6670912243f0be Author: Ming-Hung Tsai Date: Tue Oct 22 15:13:54 2024 +0800 dm cache: fix potential out-of-bounds access on the first resume commit c0ade5d98979585d4f5a93e4514c2e9a65afa08d upstream. Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume. Signed-off-by: Ming-Hung Tsai Fixes: f494a9c6b1b6 ("dm cache: cache shrinking support") Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Acked-by: Joe Thornber Signed-off-by: Greg Kroah-Hartman commit f136d8d3f26fd5113e80ba7c70f7e9a5932295b3 Author: Ming-Hung Tsai Date: Tue Oct 22 15:13:39 2024 +0800 dm cache: optimize dirty bit checking with find_next_bit when resizing commit f484697e619a83ecc370443a34746379ad99d204 upstream. When shrinking the fast device, dm-cache iteratively searches for a dirty bit among the cache blocks to be dropped, which is less efficient. Use find_next_bit instead, as it is twice as fast as the iterative approach with test_bit. Signed-off-by: Ming-Hung Tsai Fixes: f494a9c6b1b6 ("dm cache: cache shrinking support") Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Acked-by: Joe Thornber Signed-off-by: Greg Kroah-Hartman commit ee1f74925717ab36f6a091104c170639501ce818 Author: Ming-Hung Tsai Date: Tue Oct 22 15:13:16 2024 +0800 dm cache: fix out-of-bounds access to the dirty bitset when resizing commit 792227719725497ce10a8039803bec13f89f8910 upstream. dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented. Signed-off-by: Ming-Hung Tsai Fixes: f494a9c6b1b6 ("dm cache: cache shrinking support") Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Acked-by: Joe Thornber Signed-off-by: Greg Kroah-Hartman commit 5b975f146d827184fcf64ff506048c1ba87c5e98 Author: Ming-Hung Tsai Date: Tue Oct 22 15:12:22 2024 +0800 dm cache: correct the number of origin blocks to match the target length commit 235d2e739fcbe964c9ce179b4c991025662dcdb6 upstream. When creating a cache device, the actual size of the cache origin might be greater than the specified cache target length. In such case, the number of origin blocks should match the cache target length, not the full size of the origin device, since access beyond the cache target is not possible. This issue occurs when reducing the origin device size using lvm, as lvreduce preloads the new cache table before resuming the cache origin, which can result in incorrect sizes for the discard bitset and smq hotspot blocks. Reproduce steps: 1. create a cache device consists of 4096 origin blocks dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. reduce the cache origin to 2048 oblocks, in lvreduce's approach dmsetup reload corig --table "0 262144 linear /dev/sdc 262144" dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup suspend cache dmsetup suspend corig dmsetup suspend cdata dmsetup suspend cmeta dmsetup resume corig dmsetup resume cdata dmsetup resume cmeta dmsetup resume cache 3. shutdown the cache, and check the number of discard blocks in superblock. The value is expected to be 2048, but actually is 4096. dmsetup remove cache corig cdata cmeta dd if=/dev/sdc bs=1c count=8 skip=224 2>/dev/null | hexdump -e '1/8 "%u\n"' Fix by correcting the origin_blocks initialization in cache_create and removing the unused origin_sectors from struct cache_args accordingly. Signed-off-by: Ming-Hung Tsai Fixes: c6b4fcbad044 ("dm: add cache target") Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Acked-by: Joe Thornber Signed-off-by: Greg Kroah-Hartman commit 2ac7f253deada4d449559b65a1c1cd0a6f6f19b7 Author: Antonio Quartulli Date: Thu Oct 31 16:28:48 2024 +0100 drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported commit a6dd15981c03f2cdc9a351a278f09b5479d53d2e upstream. acpi_evaluate_object() may return AE_NOT_FOUND (failure), which would result in dereferencing buffer.pointer (obj) while being NULL. Although this case may be unrealistic for the current code, it is still better to protect against possible bugs. Bail out also when status is AE_NOT_FOUND. This fixes 1 FORWARD_NULL issue reported by Coverity Report: CID 1600951: Null pointer dereferences (FORWARD_NULL) Signed-off-by: Antonio Quartulli Fixes: c9b7c809b89f ("drm/amd: Guard against bad data for ATIF ACPI method") Reviewed-by: Mario Limonciello Link: https://lore.kernel.org/r/20241031152848.4716-1-antonio@mandelbit.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 17f5f18085acb5e9d8d13d84a4e12bb3aff2bd64 Author: Alex Deucher Date: Wed Oct 23 16:52:08 2024 -0400 drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() commit 4d75b9468021c73108b4439794d69e892b1d24e3 upstream. Avoid a possible buffer overflow if size is larger than 4K. Reviewed-by: Yang Wang Signed-off-by: Alex Deucher (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1829c36f93291e66328c017250713afd25b9903a Author: Erik Schumacher Date: Fri Oct 25 08:37:00 2024 +0000 pwm: imx-tpm: Use correct MODULO value for EPWM mode commit cc6a931d1f3b412263d515fd93b21fc0ca5147fe upstream. The modulo register defines the period of the edge-aligned PWM mode (which is the only mode implemented). The reference manual states: "The EPWM period is determined by (MOD + 0001h) ..." So the value that is written to the MOD register must therefore be one less than the calculated period length. Return -EINVAL if the calculated length is already zero. A correct MODULO value is particularly relevant if the PWM has to output a high frequency due to a low period value. Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support") Cc: stable@vger.kernel.org Signed-off-by: Erik Schumacher Link: https://lore.kernel.org/r/1a3890966d68b9f800d457cbf095746627495e18.camel@iris-sensing.com Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit 054931ca3cfcb8e8fa036e887d6f379942b02565 Author: Mauro Carvalho Chehab Date: Wed Oct 16 11:53:15 2024 +0200 media: v4l2-tpg: prevent the risk of a division by zero commit e6a3ea83fbe15d4818d01804e904cbb0e64e543b upstream. As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation. Fixes: 63881df94d3e ("[media] vivid: add the Test Pattern Generator") Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5a9bd375bf884d928d6f954d3ab328d2f84024a9 Author: Mauro Carvalho Chehab Date: Wed Oct 16 11:24:15 2024 +0200 media: pulse8-cec: fix data timestamp at pulse8_setup() commit ba9cf6b430433e57bfc8072364e944b7c0eca2a4 upstream. As pointed by Coverity, there is a hidden overflow condition there. As date is signed and u8 is unsigned, doing: date = (data[0] << 24) With a value bigger than 07f will make all upper bits of date 0xffffffff. This can be demonstrated with this small code: typedef int64_t time64_t; typedef uint8_t u8; int main(void) { u8 data[] = { 0xde ,0xad , 0xbe, 0xef }; time64_t date; date = (data[0] << 24) | (data[1] << 16) | (data[2] << 8) | data[3]; printf("Invalid data = 0x%08lx\n", date); date = ((unsigned)data[0] << 24) | (data[1] << 16) | (data[2] << 8) | data[3]; printf("Expected data = 0x%08lx\n", date); return 0; } Fix it by converting the upper bit calculation to unsigned. Fixes: cea28e7a55e7 ("media: pulse8-cec: reorganize function order") Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 828047c70f4716fde4b1316f7b610e97a4e83824 Author: Mauro Carvalho Chehab Date: Tue Oct 15 12:14:11 2024 +0200 media: cx24116: prevent overflows on SNR calculus commit 576a307a7650bd544fbb24df801b9b7863b85e2f upstream. as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that. Fixes: 8953db793d5b ("V4L/DVB (9178): cx24116: Add module parameter to return SNR as ESNO.") Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f54e8e1e39dacccebcfb9a9a36f0552a0a97e2ef Author: Mauro Carvalho Chehab Date: Tue Oct 15 11:10:31 2024 +0200 media: s5p-jpeg: prevent buffer overflows commit 14a22762c3daeac59a5a534e124acbb4d7a79b3a upstream. The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment. Fixes: 6c96dbbc2aa9 ("[media] s5p-jpeg: add support for 5433") Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jacek Anaszewski Signed-off-by: Greg Kroah-Hartman commit 3a977b554f668382dfba31fd62e4cce4fe5643db Author: Amelie Delaunay Date: Tue Nov 5 15:02:42 2024 +0100 ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove [ Upstream commit 9bb4af400c386374ab1047df44c508512c08c31f ] In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid. Fixes: 794df9448edb ("ASoC: stm32: spdifrx: manage rebind issue") Signed-off-by: Amelie Delaunay Signed-off-by: Olivier Moysan Link: https://patch.msgid.link/20241105140242.527279-1-olivier.moysan@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ac40b9dff2740010ae3fbe298dc10fdcd089b544 Author: Murad Masimov Date: Fri Nov 1 21:55:13 2024 +0300 ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init() [ Upstream commit 8abbf1f01d6a2ef9f911f793e30f7382154b5a3a ] If amdtp_stream_init() fails in amdtp_tscm_init(), the latter returns zero, though it's supposed to return error code, which is checked inside init_stream() in file tascam-stream.c. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 47faeea25ef3 ("ALSA: firewire-tascam: add data block processing layer") Signed-off-by: Murad Masimov Reviewed-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20241101185517.1819-1-m.masimov@maxima.ru Signed-off-by: Sasha Levin commit c1eba9f0e235aa119982f321fa1552149029e51d Author: Johannes Thumshirn Date: Wed Oct 30 12:02:53 2024 +0100 scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer [ Upstream commit 7ce3e6107103214d354a16729a472f588be60572 ] We have two reports of failed memory allocation in btrfs' code which is calling into report zones. Both of these reports have the following signature coming from __vmalloc_area_node(): kworker/u17:5: vmalloc error: size 0, failed to allocate pages, mode:0x10dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NORETRY|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 Further debugging showed these where allocations of one sector (512 bytes) and at least one of the reporter's systems where low on memory, so going through the overhead of allocating a vm area failed. Switching the allocation from __vmalloc() to kvzalloc() avoids the overhead of vmalloc() on small allocations and succeeds. Note: the buffer is already freed using kvfree() so there's no need to adjust the free path. Cc: Qu Wenru Cc: Naohiro Aota Link: https://github.com/kdave/btrfs-progs/issues/779 Link: https://github.com/kdave/btrfs-progs/issues/915 Fixes: 23a50861adda ("scsi: sd_zbc: Cleanup sd_zbc_alloc_report_buffer()") Signed-off-by: Johannes Thumshirn Link: https://lore.kernel.org/r/20241030110253.11718-1-jth@kernel.org Reviewed-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8e823ce93cc82807aa7cc7a349d2b7764f821686 Author: Mauro Carvalho Chehab Date: Tue Oct 15 12:25:09 2024 +0200 media: adv7604: prevent underflow condition when reporting colorspace [ Upstream commit 50b9fa751d1aef5d262bde871c70a7f44262f0bc ] Currently, adv76xx_log_status() reads some date using io_read() which may return negative values. The current logic doesn't check such errors, causing colorspace to be reported on a wrong way at adv76xx_log_status(), as reported by Coverity. If I/O error happens there, print a different message, instead of reporting bogus messages to userspace. Fixes: 54450f591c99 ("[media] adv7604: driver for the Analog Devices ADV7604 video decoder") Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Hans Verkuil Signed-off-by: Sasha Levin commit e351002b3a7aac22055385eb33acb5b4a1013733 Author: Mauro Carvalho Chehab Date: Tue Oct 15 16:05:16 2024 +0200 media: dvb_frontend: don't play tricks with underflow values [ Upstream commit 9883a4d41aba7612644e9bb807b971247cea9b9d ] fepriv->auto_sub_step is unsigned. Setting it to -1 is just a trick to avoid calling continue, as reported by Coverity. It relies to have this code just afterwards: if (!ready) fepriv->auto_sub_step++; Simplify the code by simply setting it to zero and use continue to return to the while loop. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a4a17210c03ade1c8d9a9f193a105654b7a05c11 Author: Mauro Carvalho Chehab Date: Tue Oct 15 15:23:01 2024 +0200 media: dvbdev: prevent the risk of out of memory access [ Upstream commit 972e63e895abbe8aa1ccbdbb4e6362abda7cd457 ] The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues. Fixes: 5dd3f3071070 ("V4L/DVB (9361): Dynamic DVB minor allocation") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ae6fd157eae4444623650ef2faa40ed5463e1c47 Author: Mauro Carvalho Chehab Date: Tue Oct 15 13:29:43 2024 +0200 media: stb0899_algo: initialize cfr before using it commit 2d861977e7314f00bf27d0db17c11ff5e85e609a upstream. The loop at stb0899_search_carrier() starts with a random value for cfr, as reported by Coverity. Initialize it to zero, just like stb0899_dvbs_algo() to ensure that carrier search won't bail out. Fixes: 8bd135bab91f ("V4L/DVB (9375): Add STB0899 support") Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 63b122f537937c9fa6433af56d30cc71620213ee Author: Jarosław Janik Date: Wed Oct 30 18:18:12 2024 +0100 Revert "ALSA: hda/conexant: Mute speakers at suspend / shutdown" commit c9363bbb0f68dd1ddb8be7bbfe958cdfcd38d851 upstream. Commit 4f61c8fe3520 ("ALSA: hda/conexant: Mute speakers at suspend / shutdown") mutes speakers on system shutdown or whenever HDA controller is suspended by PM; this however interacts badly with Thinkpad's ACPI firmware behavior which uses beeps to signal various events (enter/leave suspend or hibernation, AC power connect/disconnect, low battery, etc.); now those beeps are either muted altogether (for suspend/hibernate/ shutdown related events) or work more or less randomly (eg. AC plug/unplug is only audible when you are playing music at the moment, because HDA device is likely in suspend mode otherwise). Since the original bug report mentioned in 4f61c8fe3520 complained about Lenovo's Thinkpad laptop - revert this commit altogether. Fixes: 4f61c8fe3520 ("ALSA: hda/conexant: Mute speakers at suspend / shutdown") Signed-off-by: Jarosław Janik Link: https://patch.msgid.link/20241030171813.18941-2-jaroslaw.janik@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 30606ea3fae57f8e9f2467415389e988e3c53a18 Author: Johan Jonker Date: Mon Nov 4 21:01:38 2024 +0800 net: arc: fix the device for dma_map_single/dma_unmap_single [ Upstream commit 71803c1dfa29e0d13b99e48fda11107cc8caebc7 ] The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8 Fixes: f959dcd6ddfd ("dma-direct: Fix potential NULL pointer dereference") Signed-off-by: David Wu Signed-off-by: Johan Jonker Signed-off-by: Andy Yan Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 71d08334c2cb4132a2e6967130b9ae7bd1d6d16e Author: Diogo Silva Date: Sat Nov 2 16:15:05 2024 +0100 net: phy: ti: add PHY_RST_AFTER_CLK_EN flag [ Upstream commit 256748d5480bb3c4b731236c6d6fc86a8e2815d8 ] DP83848 datasheet (section 4.7.2) indicates that the reset pin should be toggled after the clocks are running. Add the PHY_RST_AFTER_CLK_EN to make sure that this indication is respected. In my experience not having this flag enabled would lead to, on some boots, the wrong MII mode being selected if the PHY was initialized on the bootloader and was receiving data during Linux boot. Signed-off-by: Diogo Silva Reviewed-by: Andrew Lunn Fixes: 34e45ad9378c ("net: phy: dp83848: Add TI DP83848 Ethernet PHY") Link: https://patch.msgid.link/20241102151504.811306-1-paissilva@ld-100007.ds1.internal Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d3f517f904df35383a9a4214a4b1d00ddd00c991 Author: Ioana Ciornei Date: Mon Nov 23 17:38:13 2020 +0200 net: phy: ti: implement generic .handle_interrupt() callback [ Upstream commit 1d1ae3c6ca3ff49843d73852bb2a8153ce16f432 ] In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Cc: Dan Murphy Signed-off-by: Ioana Ciornei Signed-off-by: Jakub Kicinski Stable-dep-of: 256748d5480b ("net: phy: ti: add PHY_RST_AFTER_CLK_EN flag") Signed-off-by: Sasha Levin commit f398d0a5b783cd161a07b33aa1ef356cb3251236 Author: Ioana Ciornei Date: Sun Nov 1 14:50:56 2020 +0200 net: phy: export phy_error and phy_trigger_machine [ Upstream commit 293e9a3d950dfebc76d9fa6931e6f91ef856b9ab ] These functions are currently used by phy_interrupt() to either signal an error condition or to trigger the link state machine. In an attempt to actually support shared PHY IRQs, export these two functions so that the actual PHY drivers can use them. Cc: Alexandru Ardelean Cc: Andre Edich Cc: Antoine Tenart Cc: Baruch Siach Cc: Christophe Leroy Cc: Dan Murphy Cc: Divya Koppera Cc: Florian Fainelli Cc: Hauke Mehrtens Cc: Heiner Kallweit Cc: Jerome Brunet Cc: Kavya Sree Kotagiri Cc: Linus Walleij Cc: Marco Felsch Cc: Marek Vasut Cc: Martin Blumenstingl Cc: Mathias Kresin Cc: Maxim Kochetkov Cc: Michael Walle Cc: Neil Armstrong Cc: Nisar Sayed Cc: Oleksij Rempel Cc: Philippe Schenker Cc: Willy Liu Cc: Yuiko Oshino Signed-off-by: Ioana Ciornei Signed-off-by: Jakub Kicinski Stable-dep-of: 256748d5480b ("net: phy: ti: add PHY_RST_AFTER_CLK_EN flag") Signed-off-by: Sasha Levin commit 590a4b2d4e0b73586e88bce9b8135b593355ec09 Author: Peiyang Wang Date: Fri Nov 1 17:15:07 2024 +0800 net: hns3: fix kernel crash when uninstalling driver [ Upstream commit df3dff8ab6d79edc942464999d06fbaedf8cdd18 ] When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store(). Fixes: 0dd8a25f355b ("net: hns3: disable sriov before unload hclge layer") Signed-off-by: Peiyang Wang Signed-off-by: Jijie Shao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20241101091507.3644584-1-shaojijie@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cf6bae33c5aa714200946ae3dd2aa97657713bbd Author: Dario Binacchi Date: Mon Oct 14 15:53:13 2024 +0200 can: c_can: fix {rx,tx}_errors statistics [ Upstream commit 4d6d26537940f3b3e17138987ed9e4a334780bf7 ] The c_can_handle_bus_err() function was incorrectly incrementing only the receive error counter, even in cases of bit or acknowledgment errors that occur during transmission. The patch fixes the issue by incrementing the appropriate counter based on the type of error. Fixes: 881ff67ad450 ("can: c_can: Added support for Bosch C_CAN controller") Signed-off-by: Dario Binacchi Link: https://patch.msgid.link/20241014135319.2009782-1-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 40b283ba76665437bc2ac72079c51b57b25bff9e Author: Xin Long Date: Tue Oct 29 13:46:21 2024 -0400 sctp: properly validate chunk size in sctp_sf_ootb() [ Upstream commit 0ead60804b64f5bd6999eec88e503c6a1a242d41 ] A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 Reported-by: syzbot+f0cbb34d39392f2746ca@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xin Long Link: https://patch.msgid.link/a29ebb6d8b9f8affd0f9abb296faafafe10c17d8.1730223981.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 22f4e2f86ad8f5cd12f4acb394db23eaad97fb8a Author: Wei Fang Date: Tue Oct 29 17:04:06 2024 +0800 net: enetc: set MAC address to the VF net_device [ Upstream commit badccd49b93bb945bf4e5cc8707db67cdc5e27e5 ] The MAC address of VF can be configured through the mailbox mechanism of ENETC, but the previous implementation forgot to set the MAC address in net_device, resulting in the SMAC of the sent frames still being the old MAC address. Since the MAC address in the hardware has been changed, Rx cannot receive frames with the DMAC address as the new MAC address. The most obvious phenomenon is that after changing the MAC address, we can see that the MAC address of eno0vf0 has not changed through the "ifconfig eno0vf0" command and the IP address cannot be obtained . root@ls1028ardb:~# ifconfig eno0vf0 down root@ls1028ardb:~# ifconfig eno0vf0 hw ether 00:04:9f:3a:4d:56 up root@ls1028ardb:~# ifconfig eno0vf0 eno0vf0: flags=4163 mtu 1500 ether 66:36:2c:3b:87:76 txqueuelen 1000 (Ethernet) RX packets 794 bytes 69239 (69.2 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 11 bytes 2226 (2.2 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Fixes: beb74ac878c8 ("enetc: Add vf to pf messaging support") Signed-off-by: Wei Fang Reviewed-by: Vladimir Oltean Reviewed-by: Claudiu Manoil Link: https://patch.msgid.link/20241029090406.841836-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1e4332581cd4eed75aea77af6f66cdcdda8b49b9 Author: Chen Ridong Date: Tue Oct 8 12:46:39 2024 +0000 security/keys: fix slab-out-of-bounds in key_task_permission [ Upstream commit 4a74da044ec9ec8679e6beccc4306b936b62873f ] KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.] Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") Reported-by: syzbot+5b415c07907a2990d1a3@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000cbb7860611f61147@google.com/T/ Signed-off-by: Chen Ridong Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit d7dc68d82ab3fcfc3f65322465da3d7031d4ab46 Author: Jiri Kosina Date: Tue Oct 29 15:44:35 2024 +0100 HID: core: zero-initialize the report buffer [ Upstream commit 177f25d1292c7e16e1199b39c85480f7f8815552 ] Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report. Fixes: 27ce405039bf ("HID: fix data access in implement()") Reported-by: Benoît Sevens Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 7830bfc3e7e73e3a42a28670252873c5540ecbb8 Author: Heiko Stuebner Date: Tue Oct 8 22:39:40 2024 +0200 ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin [ Upstream commit 77a9a7f2d3b94d29d13d71b851114d593a2147cf ] Both the node name as well as the compatible were not named according to the binding expectations, fix that. Fixes: 47bf3a5c9e2a ("ARM: dts: rockchip: add the sound setup for rk3036-kylin board") Cc: Caesar Wang Reviewed-by: Dragan Simic Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20241008203940.2573684-15-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 92f5b6978293a348f837b7fe68b8100695cffa31 Author: Heiko Stuebner Date: Tue Oct 8 22:39:39 2024 +0200 ARM: dts: rockchip: Fix the spi controller on rk3036 [ Upstream commit 8bade1ad1f0821aef31f6a8fb1027ae292566d85 ] Compatible and clock names did not match the existing binding. So set the correct values and re-order+rename the clocks. It looks like no rk3036 board did use the spi controller so far, so this was never detected on a running device yet. Fixes: f629fcfab2cd ("ARM: dts: rockchip: support the spi for rk3036") Cc: Caesar Wang Reviewed-by: Dragan Simic Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20241008203940.2573684-14-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit c34f7b9047480b738a418f3da16630ca21752075 Author: Heiko Stuebner Date: Tue Oct 8 22:39:38 2024 +0200 ARM: dts: rockchip: drop grf reference from rk3036 hdmi [ Upstream commit 1580ccb6ed9dc76b8ff3e2d8912e8215c8b0fa6d ] Neither the binding nor the driver implementation specify/use the grf reference provided in the rk3036. And neither does the newer rk3128 user of the hdmi controller. So drop the rockchip,grf property. Fixes: b7217cf19c63 ("ARM: dts: rockchip: add hdmi device node for rk3036") Cc: Caesar Wang Reviewed-by: Dragan Simic Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20241008203940.2573684-13-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit db87a9fb6a58c0b8f823e1edba90db8a9b754f69 Author: Heiko Stuebner Date: Tue Oct 8 22:39:37 2024 +0200 ARM: dts: rockchip: fix rk3036 acodec node [ Upstream commit c7206853cd7d31c52575fb1dc7616b4398f3bc8f ] The acodec node is not conformant to the binding. Set the correct nodename, use the correct compatible, add the needed #sound-dai-cells and sort the rockchip,grf below clocks properties as expected. Fixes: faea098e1808 ("ARM: dts: rockchip: add core rk3036 dtsi") Reviewed-by: Dragan Simic Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20241008203940.2573684-12-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 7ddbc813ba64107fc6830ebd4b9343083b2ebda5 Author: Peng Fan Date: Sat Oct 12 10:52:21 2024 +0800 arm64: dts: imx8mp: correct sdhc ipg clk [ Upstream commit eab6ba2aa3bbaf598a66e31f709bf84b7bb7dc8a ] The ipg clk for sdhc sources from IPG_CLK_ROOT per i.MX 8M Plus Applications Processor Reference Manual, Table 5-2. System Clocks. Fixes: 6d9b8d20431f ("arm64: dts: freescale: Add i.MX8MP dtsi support") Signed-off-by: Peng Fan Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit e38f91b78388dd82e47a9b9d3f9785942ed95562 Author: Heiko Stuebner Date: Tue Oct 8 22:39:33 2024 +0200 arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc [ Upstream commit 3a53a7187f41ec3db12cf4c2cb0db4ba87c2f3a1 ] There are two LEDs on the board, power and user events. Currently both are assigned undocumented IR(-remote) triggers that are probably only part of the vendor-kernel. To make dtbs check happier, assign the power-led to a generic default-on trigger and the user led to the documented rc-feedback trigger that should mostly match its current usage. Fixes: 4403e1237be3 ("arm64: dts: rockchip: Add devicetree for board roc-rk3308-cc") Cc: Andy Yan Reviewed-by: Dragan Simic Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20241008203940.2573684-8-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit fbccf9647f0f12bbd5036f7e4914b566b73f8019 Author: Heiko Stuebner Date: Tue Oct 8 22:39:32 2024 +0200 arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion [ Upstream commit 5ed96580568c4f79a0aff11a67f10b3e9229ba86 ] All Theobroma boards use a ti,amc6821 as fan controller. It normally runs in an automatically controlled way and while it may be possible to use it as part of a dt-based thermal management, this is not yet specified in the binding, nor implemented in any kernel. Newer boards already don't contain that #cooling-cells property, but older ones do. So remove them for now, they can be re-added if thermal integration gets implemented in the future. There are two further occurences in v6.12-rc in px30-ringneck and rk3399-puma, but those already get removed by the i2c-mux conversion scheduled for 6.13 . As the undocumented property is in the kernel so long, I opted for not causing extra merge conflicts between 6.12 and 6.13 Fixes: d99a02bcfa81 ("arm64: dts: rockchip: add RK3368-uQ7 (Lion) SoM") Cc: Quentin Schulz Cc: Klaus Goger Reviewed-by: Quentin Schulz Reviewed-by: Dragan Simic Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20241008203940.2573684-7-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 752c5bfb600f4e60aeab7a58baed599980c5427c Author: Heiko Stuebner Date: Tue Oct 8 22:39:30 2024 +0200 arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards [ Upstream commit ea74528aaea5a1dfc8e3de09ef2af37530eca526 ] The expected clock-name is different, and extclk also is deprecated in favor of txco for clocks that are not crystals. So fix it to match the binding. Fixes: c72235c288c8 ("arm64: dts: rockchip: Add on-board WiFi/BT support for Rock960 boards") Cc: Manivannan Sadhasivam Reviewed-by: Dragan Simic Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20241008203940.2573684-5-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit ebb427d5f270b9a4502857b6a6c62790b3903f3f Author: Diederik de Haas Date: Tue Oct 8 13:15:37 2024 +0200 arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328 [ Upstream commit de50a7e3681771c6b990238af82bf1dea9b11b21 ] The "synopsys,dw-hdmi.yaml" binding specifies that the interrupts property of the hdmi node has 'maxItems: 1', so the hdmi node in rk3328.dtsi having 2 is incorrect. Paragraph 1.3 ("System Interrupt connection") of the RK3328 TRM v1.1 page 16 and 17 define the following hdmi related interrupts: - 67 hdmi_intr - 103 hdmi_intr_wakeup The difference of 32 is due to a different base used in the TRM. The RK3399 (which uses the same binding) has '23: hdmi_irq' and '24: hdmi_wakeup_irq' according to its TRM (page 19). The RK3568 (also same binding) has '76: hdmi_wakeup' and '77: hdmi' according to page 17 of its TRM. In both cases the non-wakeup IRQ was used, so use that too for rk3328. Helped-by: Heiko Stuebner Fixes: 725e351c265a ("arm64: dts: rockchip: add rk3328 display nodes") Signed-off-by: Diederik de Haas Link: https://lore.kernel.org/r/20241008113344.23957-3-didi.debian@cknow.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 9d0d15f26b86fe0296f82c7979d0f3e07a763c42 Author: Geert Uytterhoeven Date: Thu Sep 26 15:48:41 2024 +0200 arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-excavator [ Upstream commit 577b5761679da90e691acc939ebbe7879fff5f31 ] There are no DT bindings and driver support for a "rockchip,rt5651" codec. Replace "rockchip,rt5651" by "realtek,rt5651", which matches the "simple-audio-card,name" property in the "rt5651-sound" node. Fixes: 0a3c78e251b3a266 ("arm64: dts: rockchip: Add support for rk3399 excavator main board") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/abc6c89811b3911785601d6d590483eacb145102.1727358193.git.geert+renesas@glider.be Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin