commit d27334b2888c10d2b60c954c59b186182d833107 Author: Greg Kroah-Hartman Date: Sun Aug 9 20:22:05 2026 +0200 Linux 6.6.151 Link: https://lore.kernel.org/r/20260807143415.358597922@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Brett A C Sheffield Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5b75a6e292b82f266051a58783204014025db01a Author: Andrei Kuchynski Date: Fri Jul 17 10:46:14 2026 +0000 usb: typec: ucsi: Correct teardown ordering in ucsi_init() error path commit fb0bf289f5d529336ef490c8273e88a8a8b29f69 upstream. The commit 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") consolidated port teardown into the ucsi_unregister_port() helper. However, it introduced an ordering problem in the ucsi_init() error path. Fix this by ensuring ucsi_unregister_port() is called before we unregister their corresponding lockdep keys. Cc: stable@vger.kernel.org Fixes: 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") Reported-by: "Borah, Chaitanya Kumar" Closes: https://lore.kernel.org/all/22064276-6c56-411a-9f20-6917ceeb865f@intel.com/ Signed-off-by: Andrei Kuchynski Tested-by: Chaitanya Kumar Borah Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260717104614.325250-1-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit da302460e1516e9e5ec6367a9871c88fd0901758 Author: Thomas Zimmermann Date: Tue Apr 21 09:29:05 2026 +0200 drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info commit d23bd83f3e47a928e783c0d6a004737519dc77dc upstream. That field already contains the value being assigned. No need to do this twice. Signed-off-by: Thomas Zimmermann Fixes: 63c971af4036 ("drm/fb-helper: Allocate and release fb_info in single place") Cc: linux-tegra@vger.kernel.org Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260421073646.144712-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit dcaba7b281724c692ea76b944daae595ce43be23 Author: Kai Vehmanen Date: Thu Aug 6 13:02:03 2026 -0400 ALSA: hda: codecs: hdmi: disable keep-alive before audio format change [ Upstream commit a3d6d3cedfe87bbd5a677d52b22ac20d28e59cf8 ] When a keep-alive (KAE) silent stream is active on an Intel HDMI/DP codec, opening a real PCM stream reprograms the converter format and the audio infoframe in snd_hda_hdmi_generic_pcm_prepare(). Part of that reprogramming - the converter channel count and the channel mapping in snd_hda_hdmi_setup_audio_infoframe() - is not safe to do while a keep-alive stream is active. This is most visible when switching to a multichannel PCM configuration, where the active channel count actually changes. In that case the newly opened PCM stream plays no sound. Add an optional hdmi_ops .prepare hook, called at the start of the PCM prepare sequence (before the format and infoframe are touched), and implement it for HSW+ to release keep-alive. Keep-alive is then re-enabled as before once the new stream has been set up, in the setup_stream op. Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2") Reported-by: Alexander Kaplan Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8412 Tested-by: Alexander Kaplan Cc: Signed-off-by: Kai Vehmanen Link: https://patch.msgid.link/20260715180610.1371243-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai [ adapted three hunks from the post-6.12 split files (hdmi.c/hdmi_local.h/intelhdmi.c) back into the monolithic sound/pci/hda/patch_hdmi.c, with the prepare hook un-indented one level since 6.12 uses plain mutex_lock() instead of scoped_guard() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84351f12390349ba010920fc247e1a0b12e41eb3 Author: Jani Nikula Date: Mon Aug 3 16:26:58 2026 -0400 drm/i915/hdcp: check streams[] bounds before overflow [ Upstream commit bbb15a6b042d02e5508a02b4847e02d2579ee7bc ] The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: e03187e12cae ("drm/i915/hdcp: MST streams support in hdcp port_data") Cc: stable@vger.kernel.org # v5.12+ Cc: Anshuman Gupta Cc: Suraj Kandpal Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260625170304.1104723-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d7bec2276b6069cf29ddbf0a224dfe461a79d8a3 Author: Jani Nikula Date: Sat Aug 1 23:25:22 2026 -0400 drm/i915/hdcp: require monotonically increasing seq_num_v [ Upstream commit db9e64c983dcb07ff256bd455f258c44aa530ff8 ] The HDCP 2.2 specification requires the seq_num_v to be monotonically increasing, and repeated seq_num_v needs to be treated as an integrity failure. Make it so. For the first message, seq_num_v must be zero, and is already checked. We can only check for less-than-or-equal for the subsequent messages, where hdcp2_encrypted is true. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: d849178e2c9e ("drm/i915: Implement HDCP2.2 repeater authentication") Cc: stable@vger.kernel.org # v5.2+ Cc: Suraj Kandpal Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260625104407.1025614-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit 58a224375c81179b52558c53d8857b93196d2687) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 214b63a6df022660a200d659479cb713dc3f1fd2 Author: Suraj Kandpal Date: Sat Aug 1 23:25:21 2026 -0400 drm/i915/hdcp: Move to using intel_display in intel_hdcp [ Upstream commit e35bf8f6a0ff06ceeff15bb032351cd5d006f92b ] Move to using intel_display wherever possible in intel_hdcp.c as a part of code refactor. --v2 -Move intel_display to the first line wherever possible [Jani] -use the closest reference when using to_intel_display [Jani] Signed-off-by: Suraj Kandpal Reviewed-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20240911090540.643155-2-suraj.kandpal@intel.com Stable-dep-of: db9e64c983dc ("drm/i915/hdcp: require monotonically increasing seq_num_v") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d1ba0459d8d0c62998bbabe2e1dff2dd82a8e53e Author: Jani Nikula Date: Sat Aug 1 23:25:20 2026 -0400 drm/i915/hdcp: migrate away from kdev_to_i915() in bind/unbind [ Upstream commit 3eac4684ecb5ea696bd283bd7f35e4829973f4f8 ] Use to_intel_display() instead of kdev_to_i915() in the HDCP component API hooks. Avoid further drive-by changes at this point, and just convert the display pointer to i915, and leave the struct intel_display conversion for later. Reviewed-by: Gustavo Sousa Link: https://patchwork.freedesktop.org/patch/msgid/0beedaa438e912828b48d9980f017807e079d7ab.1724942754.git.jani.nikula@intel.com Signed-off-by: Jani Nikula Stable-dep-of: db9e64c983dc ("drm/i915/hdcp: require monotonically increasing seq_num_v") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b02ed4c9099a603e25170d3e922e5fc8351bac39 Author: Ville Syrjälä Date: Sat Aug 1 23:25:19 2026 -0400 drm/i915/fbc: Extract intel_fbc_has_fences() [ Upstream commit bc34d310b578952d37b5200a7fa7475ab2a2bd5e ] Pull the "do we have fences?" check into a single helper in the FBC code. Avoids having to call to outside the display code in multiple places for this. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20240705145254.3355-2-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi Stable-dep-of: db9e64c983dc ("drm/i915/hdcp: require monotonically increasing seq_num_v") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c6eb2d615210b80339548ab07c0230edaab9a6c7 Author: Zhiling Zou Date: Fri Aug 7 07:48:23 2026 -0400 sctp: close UDP tunnel sockets during netns teardown [ Upstream commit ffb2bd7ade36ec4da32c46a6eddbf4515316d08c ] proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed. Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/b9f1f02b0780ad6a719e2413f5f0bb8eb7702d94.1782585631.git.roxy520tt%40gmail.com Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Xin Long Link: https://patch.msgid.link/6dab75f22855cb219e2e30a5497cab03b970ab91.1784033357.git.roxy520tt@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d2c3760b45f2f481a4dd4c5adef4a29dfabd948f Author: Geliang Tang Date: Fri Aug 7 07:48:13 2026 -0400 mptcp: pm: userspace: fix use-after-free in get_local_id [ Upstream commit 9bc6d5e4ca9f3cbb41d43400b3a31cb0403796c9 ] In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a "not found" sentinel. Fixes: f012d796a6de ("mptcp: check addrs list in userspace_pm_get_local_id") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang Tested-by: Xuanqiang Luo Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-2-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6b6dcc679df1970c59a81af4fe3f6d8a8b8c4b32 Author: Geliang Tang Date: Fri Aug 7 07:48:12 2026 -0400 mptcp: pm: use addr entry for get_local_id [ Upstream commit 7462fe22cc74321eb663768848976d42eba3ddbb ] The following code in mptcp_userspace_pm_get_local_id() that assigns "skc" to "new_entry" is not allowed in BPF if we use the same code to implement the get_local_id() interface of a BFP path manager: memset(&new_entry, 0, sizeof(struct mptcp_pm_addr_entry)); new_entry.addr = *skc; new_entry.addr.id = 0; new_entry.flags = MPTCP_PM_ADDR_FLAG_IMPLICIT; To solve the issue, this patch moves this assignment to "new_entry" forward to mptcp_pm_get_local_id(), and then passing "new_entry" as a parameter to both mptcp_pm_nl_get_local_id() and mptcp_userspace_pm_get_local_id(). No behavioural changes intended. Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-1-abef20ada03b@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 9bc6d5e4ca9f ("mptcp: pm: userspace: fix use-after-free in get_local_id") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 19b0ae625755db449e79a4fc4dc9feb5deabf84a Author: Geliang Tang Date: Fri Aug 7 07:48:11 2026 -0400 mptcp: add mptcp_userspace_pm_lookup_addr helper [ Upstream commit e7b4083b90b7213902124d13fd1ed808360e32b1 ] Like __lookup_addr() helper in pm_netlink.c, a new helper mptcp_userspace_pm_lookup_addr() is also defined in pm_userspace.c. It looks up the corresponding mptcp_pm_addr_entry address in userspace_pm_local_addr_list through the passed "addr" parameter and returns the found address entry. This helper can be used in mptcp_userspace_pm_delete_local_addr(), mptcp_userspace_pm_set_flags(), mptcp_userspace_pm_get_local_id() and mptcp_userspace_pm_is_backup() to simplify the code. Please note that with this change now list_for_each_entry() is used in mptcp_userspace_pm_append_new_local_addr(), not list_for_each_entry_safe(), but that's OK to do so because mptcp_userspace_pm_lookup_addr() only returns an entry from the list, the list hasn't been modified here. Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20241213-net-next-mptcp-pm-misc-cleanup-v1-1-ddb6d00109a8@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 9bc6d5e4ca9f ("mptcp: pm: userspace: fix use-after-free in get_local_id") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 805b79892a92f03a1ec1db13b3c43558ceb64353 Author: Geliang Tang Date: Fri Aug 7 07:48:10 2026 -0400 mptcp: pm: avoid code duplication to lookup endp [ Upstream commit 1d7fa6ceb91fddbe38cae3521d5d1075bce6a00e ] The helper __lookup_addr() can be used in mptcp_pm_nl_get_local_id() and mptcp_pm_nl_is_backup() to simplify the code, and avoid code duplication. Co-developed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20241115-net-next-mptcp-pm-lockless-dump-v1-2-f4a1bcb4ca2c@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 9bc6d5e4ca9f ("mptcp: pm: userspace: fix use-after-free in get_local_id") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cb9c9ec479e0bc9a5d5cdc5c723cbc3c33c62109 Author: WenTao Liang Date: Fri Aug 7 07:48:08 2026 -0400 ceph: fix refcount leak in ceph_readdir() [ Upstream commit c3e64079d8b9663e3998d0caac9aba915b6b93ae ] The ceph_readdir() function allocates a ceph_mds_request via ceph_mdsc_create_request() and stores it in dfi->last_readdir. In the directory entry processing loop, if the entry's offset is less than ctx->pos or if the inode pointer is unexpectedly NULL, the function returns -EIO without releasing the reference held by dfi->last_readdir, causing a refcount leak. Fix this by adding ceph_mdsc_put_request(dfi->last_readdir) before returning on these error paths. Also set dfi->last_readdir to NULL for safety, matching the cleanup done at the normal exit. Cc: stable@vger.kernel.org Fixes: af9ffa6df7e3 ("ceph: add support to readdir for encrypted names") Signed-off-by: WenTao Liang Reviewed-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2cda8a74c91de7158ee141cf9d10de45da0f9e75 Author: Xiubo Li Date: Fri Aug 7 07:48:07 2026 -0400 ceph: print cluster fsid and client global_id in all debug logs [ Upstream commit 38d46409c4639a1d659ebfa70e27a8bed6b8ee1d ] Multiple CephFS mounts on a host is increasingly common so disambiguating messages like this is necessary and will make it easier to debug issues. At the same this will improve the debug logs to make them easier to troubleshooting issues, such as print the ino# instead only printing the memory addresses of the corresponding inodes and print the dentry names instead of the corresponding memory addresses for the dentry,etc. Link: https://tracker.ceph.com/issues/61590 Signed-off-by: Xiubo Li Reviewed-by: Patrick Donnelly Reviewed-by: Milind Changire Signed-off-by: Ilya Dryomov Stable-dep-of: c3e64079d8b9 ("ceph: fix refcount leak in ceph_readdir()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c30406c39a665cb1deb3fdd196cf3c4ab20fa434 Author: Xiubo Li Date: Fri Aug 7 07:48:06 2026 -0400 libceph: add doutc and *_client debug macros support [ Upstream commit 5c5f0d2b5f92c47baf82b9b211e27edd7d195158 ] This will help print the fsid and client's global_id in debug logs, and also print the function names. [ idryomov: %lld -> %llu, leading space for doutc(), don't include __func__ in pr_*() variants ] Link: https://tracker.ceph.com/issues/61590 Signed-off-by: Xiubo Li Reviewed-by: Patrick Donnelly Reviewed-by: Milind Changire Signed-off-by: Ilya Dryomov Stable-dep-of: c3e64079d8b9 ("ceph: fix refcount leak in ceph_readdir()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bf5c4a8b24acb12739ebb9aea5510b007e4f5239 Author: Oliver Hartkopp Date: Fri Aug 7 09:47:57 2026 +0200 can: isotp: fix timer drain order, wakeup handling and tx_gen ordering commit 050f010f920da17c1044a4f174766ad553e770b6 upstream. This patch is a follow-up to commit cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator. Fixes: cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260724181525.43556-1-socketcan@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Greg Kroah-Hartman commit 1107f5959c03571c68794569246600d61b831f91 Author: Oliver Hartkopp Date: Fri Aug 7 09:47:56 2026 +0200 can: use skb hash instead of private variable in headroom commit d4fb6514ff8ed6912a71294e6b66a5d59ee88007 upstream. The can_skb_priv::skbcnt variable is used to identify CAN skbs in the RX path analogue to the skb->hash. As the skb hash is not filled in CAN skbs move the private skbcnt value to skb->hash and set skb->sw_hash accordingly. The skb->hash is a value used for RPS to identify skbs. Use it as intended. Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260201-can_skb_ext-v8-1-3635d790fe8b@hartkopp.net Signed-off-by: Paolo Abeni Signed-off-by: Oliver Hartkopp Signed-off-by: Greg Kroah-Hartman commit 66700c0719675e0e118ae83b2d7168dacd69dd3d Author: Zhiling Zou Date: Thu Aug 6 22:35:56 2026 -0400 sctp: avoid auth_enable sysctl UAF during netns teardown [ Upstream commit f8d5e7846025f4ab15a461235f8ebae9094a361a ] proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper. Fixes: 15649fd5415e ("sctp: sysctl: auth_enable: avoid using current->nsproxy") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Co-developed-by: Qi Tang Signed-off-by: Qi Tang Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Xin Long Link: https://patch.msgid.link/390cd5e91ed60eea27b0b64d0468301a9e73b808.1784033357.git.roxy520tt@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ac649bd51e7fc3c1bbc249ca1d06c59972ddcdca Author: Thomas Weißschuh Date: Thu Aug 6 22:35:55 2026 -0400 sysctl: treewide: constify ctl_table_header::ctl_table_arg [ Upstream commit bfa858f220ab8c950dd3e1310fee61950d0ecdae ] To be able to constify instances of struct ctl_tables it is necessary to remove ways through which non-const versions are exposed from the sysctl core. One of these is the ctl_table_arg member of struct ctl_table_header. Constify this reference as a prerequisite for the full constification of struct ctl_table instances. No functional change. Signed-off-by: Thomas Weißschuh Reviewed-by: Kees Cook Signed-off-by: David S. Miller Stable-dep-of: f8d5e7846025 ("sctp: avoid auth_enable sysctl UAF during netns teardown") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c268331845ee00dbdbccb000826bb612dff2bee7 Author: Fan Wu Date: Thu Aug 6 10:01:39 2026 -0400 wifi: brcmfmac: drain bus_reset work on device removal [ Upstream commit 43b25879f004c98defa2776bedc6ca4763c51945 ] brcmf_fw_crashed() and the debugfs "reset" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs "reset" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. This issue was found by an in-house static analysis tool. Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Assisted-by: Codex:gpt-5.6 Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260718024353.3147201-3-fanwu01@zju.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1335161f85026f09fe5f6859e713bdaa2072f547 Author: LiangCheng Wang Date: Thu Aug 6 09:57:57 2026 -0400 wifi: brcmfmac: set F2 blocksize to 256 for BCM43752 [ Upstream commit 29ab31f3f27157648f2f7e6d5e1fd9792fdf0614 ] The BCM43752 is not reliable with the default 512-byte SDIO function 2 block size: on an i.MX8MP board with an AMPAK AP6275S module at SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds: mmc_submit_one: CMD53 sg block write failed -84 brcmf_sdio_dpc: failed backplane access over SDIO, halting operation Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization") set up the 43752 like the 4373 for the F2 watermark but missed the F2 block size, which the 4373 limits to 256 bytes. The vendor driver (bcmdhd) also programs a 256-byte F2 block size for this chip and runs the same hardware without errors. Group the 43752 with the 4373, matching the F2 watermark handling. With this change a 10-minute bidirectional iperf3 soak completes with zero SDIO errors at ~270 Mbit/s in each direction. Backporting note: kernels before v6.18 name this id SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752, so on those trees the case label added by this patch must be adjusted to that name. Cherry-picking the rename commit 74e2ef72bd4b ("wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress (CYW)") first is not a clean alternative: on trees before v6.17 its context collides with the 43751 additions, and trees before v6.2 lack the FWVID framework it touches. Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization") Cc: stable@vger.kernel.org # see patch description, needs adjustments for <= 6.17 Signed-off-by: LiangCheng Wang Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260715-b43752-f2-blksz-v2-1-f9be49856050@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b516ac892bcb348c0b58ccc2d309ff8f37eafb17 Author: Gokul Sivakumar Date: Thu Aug 6 09:57:56 2026 -0400 wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress (CYW) [ Upstream commit 74e2ef72bd4b25ce21c8f309d4f5b91b5df9ff5b ] Cypress(Infineon) is not the vendor for this 43752 SDIO WLAN chip, and so has not officially released any firmware binary for it. It is incorrect to maintain this WLAN chip with firmware vendor ID as "CYW". So relabel the chip's firmware Vendor ID as "WCC" as suggested by the maintainer. Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization") Fixes: f74f1ec22dc2 ("wifi: brcmfmac: add support for Cypress firmware api") Signed-off-by: Gokul Sivakumar Acked-by: Arend van Spriel Link: https://patch.msgid.link/20250724101136.6691-1-gokulkumar.sivakumar@infineon.com Signed-off-by: Johannes Berg Stable-dep-of: 29ab31f3f271 ("wifi: brcmfmac: set F2 blocksize to 256 for BCM43752") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 64af6534a085f49d6ed33338a19ab9cf0d0523c9 Author: Daniel Hodges Date: Thu Aug 6 09:50:25 2026 -0400 wifi: ath6kl: fix use-after-free in aggr_reset_state() [ Upstream commit ba7debb4dd6427386862220e8335a53a4bfc235d ] The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Cc: stable@vger.kernel.org Signed-off-by: Daniel Hodges Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260206185207.30098-1-git@danielhodges.dev Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 47ef04cd13d38010b580056a9d8840aaab944841 Author: Mirela Rabulea Date: Thu Aug 6 09:36:15 2026 -0400 media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() [ Upstream commit 06cb687a5132fcffe624c0070576ab852ac6b568 ] The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal. Fixes: aef69d54755d ("media: v4l: fwnode: Add a convenience function for registering sensors") Cc: stable@vger.kernel.org Suggested-by: Frank Li Link: https://lore.kernel.org/linux-media/20240315073125.275501-2-sakari.ailus@linux.intel.com/ Signed-off-by: Mirela Rabulea Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fa00d8070d85db0d199855cab8e74a6ded700302 Author: Sakari Ailus Date: Thu Aug 6 09:36:14 2026 -0400 media: v4l: async: Set owner for async sub-devices [ Upstream commit 8a718752f5c339137c5b05e54f116cd26d5a4143 ] Set the owner field of the async sub-devices by making v4l2_async_register_subdev() a macro and obtaining THIS_MODULE that way. Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Stable-dep-of: 06cb687a5132 ("media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e38f054f0af98224003e600545726fbd96379cfb Author: Pablo Neira Ayuso Date: Thu Aug 6 09:06:52 2026 -0400 netfilter: nf_tables: clone set on flush only [ Upstream commit fb7fb4016300ac622c964069e286dc83166a5d52 ] Syzbot with fault injection triggered a failing memory allocation with GFP_KERNEL which results in a WARN splat: iter.err WARNING: net/netfilter/nf_tables_api.c:845 at nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845, CPU#0: syz.0.17/5992 Modules linked in: CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 RIP: 0010:nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845 Code: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 <0f> 0b 90 43 +80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9 RSP: 0018:ffffc900045af780 EFLAGS: 00010293 RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40 RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000 RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0 R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920 FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0 Call Trace: __nft_release_table+0xceb/0x11f0 net/netfilter/nf_tables_api.c:12115 nft_rcv_nl_event+0xc25/0xdb0 net/netfilter/nf_tables_api.c:12187 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380 netlink_release+0x123b/0x1ad0 net/netlink/af_netlink.c:761 __sock_release net/socket.c:662 [inline] sock_close+0xc3/0x240 net/socket.c:1455 Restrict set clone to the flush set command in the preparation phase. Add NFT_ITER_UPDATE_CLONE and use it for this purpose, update the rbtree and pipapo backends to only clone the set when this iteration type is used. As for the existing NFT_ITER_UPDATE type, update the pipapo backend to use the existing set clone if available, otherwise use the existing set representation. After this update, there is no need to clone a set that is being deleted, this includes bound anonymous set. An alternative approach to NFT_ITER_UPDATE_CLONE is to add a .clone interface and call it from the flush set path. Reported-by: syzbot+4924a0edc148e8b4b342@syzkaller.appspotmail.com Fixes: 3f1d886cc7c3 ("netfilter: nft_set_pipapo: move cloning of match info to insert/removal path") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d94b82d452ca27a200cd67660dc48476386651d8 Author: David Howells Date: Thu Aug 6 08:46:13 2026 -0400 rxrpc: Fix irq-disabled in local_bh_enable() [ Upstream commit e4d2878369d590bf8455e3678a644e503172eafa ] The rxrpc_assess_MTU_size() function calls down into the IP layer to find out the MTU size for a route. When accepting an incoming call, this is called from rxrpc_new_incoming_call() which holds interrupts disabled across the code that calls down to it. Unfortunately, the IP layer uses local_bh_enable() which, config dependent, throws a warning if IRQs are enabled: WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0 ... RIP: 0010:__local_bh_enable_ip+0x43/0xd0 ... Call Trace: rt_cache_route+0x7e/0xa0 rt_set_nexthop.isra.0+0x3b3/0x3f0 __mkroute_output+0x43a/0x460 ip_route_output_key_hash+0xf7/0x140 ip_route_output_flow+0x1b/0x90 rxrpc_assess_MTU_size.isra.0+0x2a0/0x590 rxrpc_new_incoming_peer+0x46/0x120 rxrpc_alloc_incoming_call+0x1b1/0x400 rxrpc_new_incoming_call+0x1da/0x5e0 rxrpc_input_packet+0x827/0x900 rxrpc_io_thread+0x403/0xb60 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 ... hardirqs last enabled at (23): _raw_spin_unlock_irq+0x24/0x50 hardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70 softirqs last enabled at (0): copy_process+0xc61/0x2730 softirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90 Fix this by moving the call to rxrpc_assess_MTU_size() out of rxrpc_init_peer() and further up the stack where it can be done without interrupts disabled. It shouldn't be a problem for rxrpc_new_incoming_call() to do it after the locks are dropped as pmtud is going to be performed by the I/O thread - and we're in the I/O thread at this point. Fixes: a2ea9a907260 ("rxrpc: Use irq-disabling spinlocks between app and I/O thread") Signed-off-by: David Howells Reviewed-by: Jeffrey Altman cc: Marc Dionne cc: Junvyyang, Tencent Zhuque Lab cc: LePremierHomme cc: Simon Horman cc: linux-afs@lists.infradead.org Link: https://patch.msgid.link/20250717074350.3767366-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski [ moved `peer->mtu`/`peer->maxdata` derivation into `rxrpc_assess_MTU_size()` at both exits since 6.12 predates the `max_data` rework ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f9fa11cdd5bf27b52be6482e3b1be31188ba31b1 Author: Sakari Ailus Date: Tue Aug 4 06:47:37 2026 -0400 media: imx219: Fix maximum frame length in lines [ Upstream commit 2c4f1ba7354312ad2d6e34e70a518a51a9344715 ] The driver used the maximum frame length in lines value of 0xffff, but the maximum appears to be 0xfffe instead. Fix it. Fixes: 1283b3b8f82b ("media: i2c: Add driver for Sony IMX219 sensor") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Dave Stevenson Reviewed-by: Laurent Pinchart Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit af4fd77d3430f1f2594b2721469421d230d66de5 Author: Jai Luthra Date: Tue Aug 4 06:47:36 2026 -0400 media: i2c: imx219: Rename VTS to FRM_LENGTH [ Upstream commit 04f78503f99ae7e9887c7fe5e4bc54a7cfb10fe0 ] The IMX219 datasheet refers to the vertical length + blanking as FRM_LENGTH instead of VTS. Reviewed-by: Dave Stevenson Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 2c4f1ba73543 ("media: imx219: Fix maximum frame length in lines") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b0f5471b0a69ab741274a025722c7648a112fba3 Author: Laurent Pinchart Date: Tue Aug 4 06:47:35 2026 -0400 media: i2c: imx219: Calculate crop rectangle dynamically [ Upstream commit 0af46fbc333d1a52c72823d935590410357bab47 ] Calculate the crop rectangle size and location dynamically when setting the format, instead of storing it in the imx219_mode structure. This removes duplicated information from the mode, to guarantee consistency. Signed-off-by: Laurent Pinchart Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 2c4f1ba73543 ("media: imx219: Fix maximum frame length in lines") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cdeb114ed964c750aa81188e13f0d550ba2ab6a4 Author: Laurent Pinchart Date: Tue Aug 4 06:47:34 2026 -0400 media: i2c: imx219: Group functions by purpose [ Upstream commit d03dfb7d4c5fae0d3f297536063e00ea2c1129d5 ] Move functions around to group them by purpose, in order to improve readability. No functional change is intended. Signed-off-by: Laurent Pinchart Reviewed-by: Dave Stevenson Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 2c4f1ba73543 ("media: imx219: Fix maximum frame length in lines") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f2f85e5ff17e3debb1ce4568837822a703ca7540 Author: Laurent Pinchart Date: Tue Aug 4 06:47:33 2026 -0400 media: i2c: imx219: Drop IMX219_VTS_* macros [ Upstream commit 5ebbdd7aab3321e60a8be23aac1fee4f16644021 ] The IMX219_VTS_* macros define default VTS values for the modes supported by the driver. They are used in a single place, and hinder readability compared to using the value directly as a decimal number. Drop them. Signed-off-by: Laurent Pinchart Reviewed-by: Dave Stevenson Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 2c4f1ba73543 ("media: imx219: Fix maximum frame length in lines") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bc24c30f403a252b30459b39e15df70cce0cbcf0 Author: Laurent Pinchart Date: Tue Aug 4 06:47:32 2026 -0400 media: i2c: imx219: Don't store the current mode in the imx219 structure [ Upstream commit e3e5d172d5fce9151bc101427554a158d4759856 ] The mode field of the imx219 structure is only used in imx219_init_controls(), after the probe function sets it to point to the default mode. Use the default mode directly when initializing controls, and drop the mode field from the imx219 structure. Signed-off-by: Laurent Pinchart Reviewed-by: Jacopo Mondi Reviewed-by: Dave Stevenson Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 2c4f1ba73543 ("media: imx219: Fix maximum frame length in lines") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 912762e93e6d26fae9b474a59b4d714b9363f2e5 Author: Laurent Pinchart Date: Tue Aug 4 06:47:31 2026 -0400 media: i2c: imx219: Access height from active format in imx219_set_ctrl [ Upstream commit aa86ac42eec4dd7e987c12390a0a487187e2d9ae ] Use the active format height instead of the mode height in imx219_set_ctrl(). This prepares for dropping the mode field from the imx219 structure. The state is retrieved using v4l2_subdev_get_locked_active_state() as the subdev active state and the control handler share the same lock. Signed-off-by: Laurent Pinchart Reviewed-by: Jacopo Mondi Reviewed-by: Dave Stevenson Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 2c4f1ba73543 ("media: imx219: Fix maximum frame length in lines") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6598ac1721c3a5543efdbcab579a8561268d7ce1 Author: Jani Nikula Date: Sat Aug 1 23:42:45 2026 -0400 drm/i915/vrr: require valid min/max vfreq for VRR [ Upstream commit f8a9262c7a6fc2de9802e14b0228114f0333869e ] Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: 117cd09ba528 ("drm/i915/display/dp: Compute VRR state in atomic_check") Cc: stable@vger.kernel.org # v5.12+ Cc: Ankit Nautiyal Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/20260625131040.1051272-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c8420f048c15298b134fe469a5f14244bd62c304 Author: Ville Syrjälä Date: Sat Aug 1 23:42:44 2026 -0400 drm/i915/vrr: Check HAS_VRR() first in intel_vrr_is_capable() [ Upstream commit 4b274b0b61ab2a529e5c22e9aa033f3028e639fc ] There's no point in doing all the other checks in intel_vrr_is_capable() if the platform doesn't support VRR at all Check HAS_VRR() before wasting time on the other checks. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-23-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal Stable-dep-of: f8a9262c7a6f ("drm/i915/vrr: require valid min/max vfreq for VRR") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aa31b60d6c4ec28fdbc34c6ed6264300890ab977 Author: Timur Kristóf Date: Fri Jul 31 12:57:01 2026 -0400 drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions [ Upstream commit 8882f8897e554053af9e72f4c2da8b1e2cce56c7 ] When testing intersection and compatibility, respect the actual placement requirements. This is a pre-requisite for ensuring that UVD CS BOs do not cross 256M segments. Fixes: ded910f368a5 ("drm/amdgpu: Implement intersect/compatible functions") Suggested-by: Christian König Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit bc06579ca29dee9c245a41b12e39c7bb6938af5d) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 926a4e2301060d2d2b844c78d55ef3c48678359f Author: Thomas Zimmermann Date: Fri Jul 31 11:50:20 2026 -0400 drm/tegra: fbdev: Remove offset into framebuffer memory [ Upstream commit a18b6e30ecd69096beda4a0c96d2570900c3879a ] The screen_buffer field in struct fb_info contains the kernel address of the first byte of framebuffer memory. Do not add the display offset. This offset only describes scrolling during scanout. Signed-off-by: Thomas Zimmermann Fixes: de2ba664c30f ("gpu: host1x: drm: Add memory manager and fb") Cc: dri-devel@lists.freedesktop.org Cc: linux-tegra@vger.kernel.org Cc: # v3.10+ Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260421073646.144712-3-tzimmermann@suse.de Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d6c50b6605db0fbdcb10a239fd73f6017ba2eb03 Author: Thomas Zimmermann Date: Fri Jul 31 11:50:19 2026 -0400 drm/fb-helper: Allocate and release fb_info in single place [ Upstream commit 63c971af40365ee706c7e24f6a7900d693518f09 ] Move the calls to drm_fb_helper_alloc_info() from drivers into a single place in fbdev helpers. Allocates struct fb_info for a new framebuffer device. Then call drm_fb_helper_single_fb_probe() to create an fbdev screen buffer. Also release the instance on errors by calling drm_fb_helper_release_info(). Simplifies the code and fixes the error cleanup for some of the drivers. Regular release of the struct fb_info instance still happens in drm_fb_helper_fini() as before. v2: - remove error rollback in driver implementations (kernel test robot) - initialize info in TTM implementation (kernel test robot) Signed-off-by: Thomas Zimmermann Acked-by: Christian König # radeon Acked-by: Dmitry Baryshkov # msm Acked-by: Javier Martinez Canillas Link: https://patch.msgid.link/20251027081245.80262-1-tzimmermann@suse.de Stable-dep-of: a18b6e30ecd6 ("drm/tegra: fbdev: Remove offset into framebuffer memory") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 07f8aaffee705e552c1f723ac8bf7eb137ad59c2 Author: Andrei Kuchynski Date: Thu Jul 30 22:40:57 2026 -0400 usb: typec: ucsi: Fix race condition and ordering in port unregistration [ Upstream commit 7aa7d4bf9d3fa9a6a47b640ad103ab433b7ff261 ] A synchronization issue exists during port unregistration where pending partner work items can race against workqueue destruction, leading to use-after-free conditions: cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:__queue_work+0x83/0x4a0 Call Trace: __cfi_delayed_work_timer_fn+0x10/0x10 run_timer_softirq+0x3b6/0xbd0 sched_clock_cpu+0xc/0x110 irq_exit_rcu+0x18d/0x330 fred_sysvec_apic_timer_interrupt+0x5e/0x80 Fix this by ensuring strict ordering and proper serialization during teardown: 1. Move ucsi_unregister_partner() to the beginning of the teardown sequence and protect it under the connector mutex lock. 2. Ensure all pending partner tasks are explicitly flushed and finished before the workqueue is destroyed. 3. Switch from mod_delayed_work() to a cancel_delayed_work() and queue_delayed_work() sequence. This guarantees that items currently marked as pending won't be scheduled an additional time, preventing a double release of resources which leads to the following crash: Oops: general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP NOPTI Workqueue: cros_ec_ucsi.3.auto-con2 ucsi_poll_worker RIP: 0010:ucsi_poll_worker+0x65/0x1e0 Call Trace: process_scheduled_works+0x218/0x6d0 worker_thread+0x188/0x3f0 __cfi_worker_thread+0x10/0x10 kthread+0x226/0x2a0 To ensure these rules are applied identically across both the normal teardown and the ucsi_init() error paths, consolidate the cleanup logic into a new helper, ucsi_unregister_port(). Cc: stable Fixes: b9aa02ca39a4 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking") Fixes: b13abcb7ddd8 ("usb: typec: ucsi: Fix NULL pointer access") Fixes: fac4b8633fd6 ("usb: ucsi: Ensure connector delayed work items are flushed") Signed-off-by: Andrei Kuchynski Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260707141736.1635698-1-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c888e052a09efbb231f794377ed7a70c735c211f Author: Sergey Senozhatsky Date: Thu Jul 30 22:40:56 2026 -0400 usb: typec: ucsi: split connector lock classes [ Upstream commit 8c22256bbafad3dc5fdbe9f684d045b67ff06a68 ] Lockdep detects a possible recursive locking scenario during ucsi init: [ 5.418616] ============================================ [ 5.418634] WARNING: possible recursive locking detected [ 5.418706] -------------------------------------------- [ 5.418725] kworker/4:1/82 is trying to acquire lock: [ 5.418759] ffff888119a34648 (&con->lock){+.+.}-{3:3}, at: ucsi_init_work+0x1a78/0x2eb0 [typec_ucsi] [ 5.418801] but task is already holding lock: [ 5.418835] ffff888119a34080 (&con->lock){+.+.}-{3:3}, at: ucsi_init_work+0x1a78/0x2eb0 [typec_ucsi] [ 5.418884] other info that might help us debug this: [ 5.418904] Possible unsafe locking scenario: [ 5.418937] CPU0 [ 5.418956] ---- [ 5.418991] lock(&con->lock); [ 5.419013] lock(&con->lock); [ 5.419033] *** DEADLOCK *** [ 5.419387] Call Trace: [ 5.419406] [ 5.419425] dump_stack_lvl+0x61/0xa0 [ 5.419448] print_deadlock_bug+0x4a6/0x650 [ 5.419483] __lock_acquire+0x62b6/0x7f50 [ 5.419507] lock_acquire+0x11b/0x390 [ 5.419654] __mutex_lock+0xbc/0xcd0 [ 5.419741] ucsi_init_work+0x1a78/0x2eb0 [ 5.419785] ? worker_thread+0xf53/0x2bc0 [ 5.419819] worker_thread+0xff4/0x2bc0 [ 5.419842] kthread+0x2a7/0x330 [ 5.419863] ? __pfx_worker_thread+0x10/0x10 [ 5.419896] ? __pfx_kthread+0x10/0x10 [ 5.419916] ret_from_fork+0x38/0x70 [ 5.419936] ? __pfx_kthread+0x10/0x10 [ 5.419969] ret_from_fork_asm+0x1b/0x30 [ 5.419991] [ 5.420009] ---[ end trace 0000000000000000 ]--- The problem is that all connector locks belong to the same lockdep lock class, so the following loop: for (i = 0; i < ucsi->cap.num_connectors; i++) ucsi_register_port(connector[i]) mutex_lock(&connector[i]->lock) looks like a recursive acquire of the same mutex. Put each connector lock into a dedicated lock class so that lockdep doesn't see it as a possible recursion. Signed-off-by: Sergey Senozhatsky Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260515060042.136083-1-senozhatsky@chromium.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3a9e3344d1e51bc2dc8f2499f98cc2ae03ea083f Author: Diogo Ivo Date: Thu Jul 30 22:40:55 2026 -0400 usb: typec: ucsi: Only enable supported notifications [ Upstream commit 27ffe4ff0b33b3dcc97fd448fd1e38d31ade575b ] The UCSI specification defines some notifications to be optional for the PPM to support. From these only enable the ones the PPM informs us are actually supported. Signed-off-by: Diogo Ivo Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/yhz7nq622mbg3rqsyvqz632pc756niagpfbnzayfswhzo7esho@vrdtx5c3hjgx Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3118bb872c7dff653294f193d5328a476619e04d Author: Cen Zhang Date: Thu Jul 30 15:39:02 2026 -0400 usb: gadget: f_tcm: synchronize delayed set_alt with teardown [ Upstream commit 79e2d75725c85607f8a9d87ae9cace62a19f767d ] The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT") Cc: stable Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260627104153.3822495-1-zzzccc427@gmail.com Signed-off-by: Greg Kroah-Hartman [ adjusted context for 6.12's scalar `struct usbg_cdb cmd` and missing `stream_hash`, dropping the `hash_init()` context line ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f5307073303ad947c5f0a15de46e17d8a76dab4b Author: Biju Das Date: Thu Jul 30 15:29:55 2026 -0400 drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay [ Upstream commit 7cbba8a8ba0219a267844d3116dbc77cecb4fcf8 ] The RZ/G2L hardware manual (Rev. 1.50, May 2025), Section 34.4.2.1, requires waiting at least 1 msec after deasserting the CMN_RSTB signal before the DSI-Tx module is ready. Increase the delay from 1 usec to 1 msec by replacing udelay(1) with fsleep(1000) for RZ/G2L SoCs. Fixes: 7a043f978ed1 ("drm: rcar-du: Add RZ/G2L DSI driver") Cc: stable@vger.kernel.org Reviewed-by: Tommaso Merciai Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260330104450.128512-3-biju.das.jz@bp.renesas.com Signed-off-by: Biju Das Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4c37112f1af9090e97175cac908dcf671d3e8e6f Author: Lad Prabhakar Date: Thu Jul 30 15:29:54 2026 -0400 drm: renesas: Move RZ/G2L MIPI DSI driver to rz-du [ Upstream commit 1b5dfd1881dbe303536d4167500b94549ff2f6a7 ] All the RZ/G2L DU specific components are located under the rz-du folder, so it makes sense to move the RZ/G2L MIPI DSI driver there instead of keeping it in the rcar-du folder. This change improves the organization and modularity of the driver configuration by grouping related settings together. Signed-off-by: Lad Prabhakar Acked-by: Biju Das Reviewed-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20240625123244.200533-1-prabhakar.mahadev-lad.rj@bp.renesas.com Stable-dep-of: 7cbba8a8ba02 ("drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit eed56f105a7f70cbcfceb4df6deb6870fc58214d Author: Guangshuo Li Date: Thu Jul 30 09:13:36 2026 -0400 usb: musb: omap2430: Do not put borrowed of_node in probe [ Upstream commit c947360ae63eee1c9eacc030dd6f5a53f717addf ] omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately. Fixes: ffbe2feac59b ("usb: musb: omap2430: Fix probe regression for missing resources") Cc: stable Reviewed-by: Johan Hovold Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260713114711.955253-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e56ccb286bc484fa142b9a9d2c679a246a527198 Author: Johan Hovold Date: Thu Jul 30 09:13:35 2026 -0400 usb: musb: omap2430: clean up probe error handling [ Upstream commit 51d4b0a44c82e5eff056ef76acd2c3c605a8eb74 ] Using numbered error labels is discouraged (e.g. as it requires renumbering them when adding a new intermediate error path). Rename the error labels after what they do. While at it, drop the redundant platform allocation failure dev_err() as the error would already have been logged by the allocator. Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20250724091910.21092-6-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: c947360ae63e ("usb: musb: omap2430: Do not put borrowed of_node in probe") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bbd2a25bbb415af9b014757267efee44d25d2754 Author: Frank Scheiner Date: Tue Aug 4 15:48:08 2026 +0200 Revert "ia64: Make acpi_cpufreq_cpu_exit return void" Commit b4b1ddc9dfe9 ("cpufreq: Make cpufreq_driver->exit() return void") was part of v6.6.145-rc1. But as it was derived from a later Linux version w/o support for ia64 it didn't touch all relevant parts in linux-6.6.y. Which now required an extra fix to build correctly for ia64. But b4b1ddc9dfe9 was then not part of the release v6.6.145. So the extra fix can go now, too. This reverts commit bb51b626b5a8ef349b11876572540f19ad4d5030. Signed-off-by: Frank Scheiner Signed-off-by: Greg Kroah-Hartman commit 16da33cb36e663b6967112185e11d00ce8ff957c Author: Junjie Cao Date: Thu Aug 6 10:19:34 2026 +0800 gpio: pch: use raw_spinlock_t for the register lock [ Upstream commit a02b8950d619123da64f69b70fe1dadef217dfe4 ] pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 ("gpio: sch: use raw_spinlock_t in the irq startup path") and commit 90f0109019e6 ("gpio: eic-sprd: use raw_spinlock_t in the irq startup path"). Fixes: 38eb18a6f92d ("gpio-pch: Support interrupt function") Cc: stable@vger.kernel.org Signed-off-by: Junjie Cao Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260723014129.1129730-1-junjie.cao@intel.com Signed-off-by: Bartosz Golaszewski (cherry picked from commit a02b8950d619123da64f69b70fe1dadef217dfe4) Signed-off-by: Sasha Levin commit 95f702e372964aff486338783f49e28a40a53127 Author: Tze Yee Ng Date: Thu Aug 6 03:24:58 2026 -0700 firmware: stratix10-svc: fix memory leaks and list corruption bugs [ Upstream commit 9119ceb76e987c2ec2b549ea100e3268ce3a1c7c ] Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups. Fixes: 7ca5ce896524 ("firmware: add Intel Stratix10 service layer driver") Cc: stable@vger.kernel.org#5.0+ Signed-off-by: Tze Yee Ng Signed-off-by: Dinh Nguyen (cherry picked from commit 9119ceb76e987c2ec2b549ea100e3268ce3a1c7c) Signed-off-by: Sasha Levin commit be106f7855f03d3128ed0ce70ba74b484a90b473 Author: Kiryl Shutsemau (Meta) Date: Wed Aug 5 14:45:19 2026 +0100 mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios [ Upstream commit e923bd21058ea02fd0dcd3549d151d143fd036e5 ] __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked. Link: https://lore.kernel.org/20260716095424.471052-1-kirill@shutemov.name Fixes: baa355fd3314 ("thp: file pages support for split_huge_page()") Signed-off-by: Kiryl Shutsemau (Meta) Reported-by: Hao Zhang Closes: https://lore.kernel.org/linux-mm/20260710071344.GA106129@zh-pc Co-developed-by: Hao Zhang Signed-off-by: Hao Zhang Acked-by: David Hildenbrand (Arm) Reviewed-by: Zi Yan Reviewed-by: Baolin Wang Reviewed-by: Miaohe Lin Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Signed-off-by: Andrew Morton (cherry picked from commit e923bd21058ea02fd0dcd3549d151d143fd036e5) [ kas: adapt to the __split_huge_page()/split_huge_page_to_list() two-function split: pass @mapping into __split_huge_page() and drop it there, before the loop that frees the after-split subpages while the head is still locked; the caller then skips its own i_mmap unlock ] Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Sasha Levin commit 69cb5825d9988c7944bc9f1dc08cb233655405a7 Author: Kiryl Shutsemau (Meta) Date: Wed Aug 5 14:43:38 2026 +0100 mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork() [ Upstream commit 83abe2fd5b3aeb3123b5408a5a91709c5538fb23 ] copy_hugetlb_page_range() clears the uffd-wp bit of migration and hwpoison entries with huge_pte_clear_uffd_wp(), which operates on the present-PTE bit position. Swap entries keep the uffd-wp state elsewhere -- the migration branch reads and sets it with pte_swp_uffd_wp() and pte_swp_mkuffd_wp() -- and the present-PTE position falls into the swap payload. On x86-64 it lands in the inverted swap offset, where a naturally-aligned hugetlb PFN always has the affected bit set, so the clear advances the encoded PFN by two pages. No userfaultfd needs to be involved: the clear is guarded only by the child VMA not being uffd-wp registered, so a plain fork() with an in-flight hugetlb migration entry (or a poisoned hugetlb page) corrupts the entry copied into the child. Instrumenting the clear and forking after MADV_HWPOISON on a 2MB anon hugetlb page shows: offset before=120e00 offset after =120e02 The fallout is mostly latent: rmap walks match migration entries by folio range and remove_migration_pte() rebuilds the PTE from the folio, so a within-folio PFN skew heals once migration completes. But any path that re-encodes the corrupted offset -- e.g. hugetlb_change_protection() rewriting a writable migration entry via make_readable_migration_entry(swp_offset(entry)) -- propagates it. Migration entries legitimately carry uffd-wp, so clear it with pte_swp_clear_uffd_wp(), matching copy_nonpresent_pte() and move_huge_pte(). A hwpoison entry, on the other hand, never carries the uffd-wp bit: it is installed fresh by make_hwpoison_entry() (try_to_unmap_one() does not preserve uffd-wp on the hwpoison path) and hugetlb_change_protection() leaves hwpoison entries untouched. There was nothing to clear there, only the corruption, so drop the clear entirely. Link: https://lore.kernel.org/20260708090110.136162-1-kirill@shutemov.name Fixes: bc70fbf269fd ("mm/hugetlb: handle uffd-wp during fork()") Signed-off-by: Kiryl Shutsemau Reported-by: Sashiko AI review Closes: https://lore.kernel.org/all/20260703140011.99E601F000E9@smtp.kernel.org/ Suggested-by: David Hildenbrand Acked-by: David Hildenbrand (Arm) Assisted-by: Claude:claude-fable-5 Cc: Muchun Song Cc: Oscar Salvador Cc: Peter Xu Cc: Signed-off-by: Andrew Morton (cherry picked from commit 83abe2fd5b3aeb3123b5408a5a91709c5538fb23) [ kas: adapt to the pre-softleaf idiom ] Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Sasha Levin commit 6277e85777710a34c98a4ef4904e0c331497c081 Author: Wei Yang Date: Mon Aug 3 19:40:39 2026 +0800 iommu/sva: move x86 disable check before allocation Backport of commit 72f98ef9a4be ("iommu: disable SVA when CONFIG_X86 is set") placed the IS_ENABLED(CONFIG_X86) early-return in iommu_sva_bind_device() after iommu_sva_alloc_pasid() and kzalloc(handle), while upstream puts it at the function start. On x86 this leaks the kzalloc'd struct iommu_sva (early return skips kfree) and a globally allocated PASID (mm->pasid wrongly set, never unbound). Move the check before any allocation/side effect. Fixes: 240cd7f2812c ("iommu: disable SVA when CONFIG_X86 is set") Signed-off-by: Wei Yang Acked-by: Lu Baolu Signed-off-by: Sasha Levin commit 9de51b5dbcdfd8e04844638d1c0c960029e64e16 Author: Niklas Cassel Date: Tue Feb 25 15:16:12 2025 +0100 ata: ahci: Make ahci_ignore_port() handle empty mask_port_map commit 130ff5c8b78e6fd05270a04985c50bce6a3de6c1 upstream. Commit 8c87215dd3a2 ("ata: libahci_platform: support non-consecutive port numbers") added a skip to ahci_platform_enable_phys() for ports that are not in mask_port_map. The code in ahci_platform_get_resources(), will currently set mask_port_map for each child "port" node it finds in the device tree. However, device trees that do not have any child "port" nodes will not have mask_port_map set, and for non-device tree platforms mask_port_map will only exist as a quirk for specific PCI device + vendor IDs, or as a kernel module parameter, but will not be set by default. Therefore, the common thing is that mask_port_map is only set if you do not want to use all ports (as defined by Offset 0Ch: PI – Ports Implemented register), but instead only want to use the ports in mask_port_map. If mask_port_map is not set, all ports are available. Thus, ahci_ignore_port() must be able to handle an empty mask_port_map. Fixes: 8c87215dd3a2 ("ata: libahci_platform: support non-consecutive port numbers") Fixes: 2c202e6c4f4d ("ata: libahci_platform: Do not set mask_port_map when not needed") Fixes: c9b5be909e65 ("ahci: Introduce ahci_ignore_port() helper") Reported-by: Marek Szyprowski Closes: https://lore.kernel.org/linux-ide/10b31dd0-d0bb-4f76-9305-2195c3e17670@samsung.com/ Tested-by: Marek Szyprowski Co-developed-by: Damien Le Moal Signed-off-by: Damien Le Moal Link: https://lore.kernel.org/r/20250225141612.942170-2-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 0158829969820f169c8c55e7df7f82f12ddaf251 Author: Damien Le Moal Date: Sat Feb 8 08:29:15 2025 +0900 ata: libahci_platform: Do not set mask_port_map when not needed commit 2c202e6c4f4dd19d2e8c1dfac9df05170aa3934f upstream. Commit 8c87215dd3a2 ("ata: libahci_platform: support non-consecutive port numbers") modified ahci_platform_get_resources() to allow identifying the ports of a controller that are defined as child nodes of the controller node in order to support non-consecutive port numbers (as defined by the platform device tree). However, this commit also erroneously sets bit 0 of hpriv->mask_port_map when the platform devices tree does not define port child nodes, to match the fact that the temporary default number of ports used in that case is 1 (which is also consistent with the fact that only index 0 of hpriv->phys[] is initialized with the call to ahci_platform_get_phy(). But doing so causes ahci_platform_init_host() to initialize and probe only the first port, even if this function determines that the controller has in fact multiple ports using the capability register of the controller (through a call to ahci_nr_ports()). This can be seen with the ahci_mvebu driver (Armada 385 SoC) with the second port declared as "dummy": ahci-mvebu f10a8000.sata: masking port_map 0x3 -> 0x1 ahci-mvebu f10a8000.sata: AHCI vers 0001.0000, 32 command slots, 6 Gbps, platform mode ahci-mvebu f10a8000.sata: 1/2 ports implemented (port mask 0x1) ahci-mvebu f10a8000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs scsi host0: ahci-mvebu scsi host1: ahci-mvebu ata1: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x100 irq 40 lpm-pol 0 ata2: DUMMY Fix this issue by removing setting bit 0 of hpriv->mask_port_map when the platform device tree does not define port child nodes. Reported-by: Klaus Kudielka Fixes: 8c87215dd3a2 ("ata: libahci_platform: support non-consecutive port numbers") Tested-by: Klaus Kudielka Signed-off-by: Damien Le Moal Acked-by: Josua Mayer Link: https://lore.kernel.org/r/20250207232915.1439174-1-dlemoal@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 95b3f23d632490b5eb285b9fcf7284f2ac8f9872 Author: HyeongJun An Date: Thu Jun 18 15:37:37 2026 +0900 HID: logitech-dj: Fix maxfield check in DJ short report validation commit 590cc4d782487632a52f37c2171bee1eeea29627 upstream. Commit b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write") added validation for the DJ short output report, but the error path dereferences rep->field[0] even when rep->maxfield is zero. Commit 8b9a097eb2fc ("HID: logitech-dj: fix wrong detection of bad DJ_SHORT output report") made the check conditional on rep being present, but a crafted descriptor can still create report ID 0x20 with only padding output items. hid-core registers the report, ignores the padding field, and leaves rep->maxfield as zero. In that case the validation enters the rep->maxfield < 1 branch and then dereferences rep->field[0]->report_count while printing the error message, causing a NULL pointer dereference during probe. This is reproducible with uhid by emulating a Logitech receiver with a padding-only DJ short output report: BUG: KASAN: null-ptr-deref in logi_dj_probe+0xb1/0x754 [hid_logitech_dj] Read of size 4 at addr 0000000000000028 by task kworker/4:1/129 ... Call Trace: logi_dj_probe+0xb1/0x754 [hid_logitech_dj] hid_device_probe+0x329/0x3f0 [hid] really_probe+0x162/0x570 __device_attach+0x137/0x2c0 bus_probe_device+0x38/0xc0 device_add+0xa56/0xce0 hid_add_device+0x19c/0x280 [hid] uhid_device_add_worker+0x2c/0xb0 [uhid] Reject the zero-field report before printing the field report_count. Fixes: b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b517ca5c6346f89446b351101b2d4679596265c8 Author: Jun Guo Date: Thu Jan 15 17:19:24 2026 +0800 spi: spi-cadence: enable SPI_CONTROLLER_MUST_TX commit f6b625639e39bc384a7bddbf134a698d40258b3b upstream. During an SPI read operation, even if the xspi->txbuf passed to the cdns_spi_writerinterface is empty, it is still necessary to call cdns_spi_write(xspi, CDNS_SPI_TXD, txw); otherwise, the read operation will fail to obtain data correctly due to a lack of clocks. Fixes: 4e00135b2dd1 ("spi: spi-cadence: supports transmission with bits_per_word of 16 and 32") Reported-by: Rodrigo Alencar <455.rodrigo.alencar@gmail.com> Closes: https://lore.kernel.org/all/lbijvnnwsnddonmm5pveqzap6iibxhl4maneq43x4j6w64dev6@u75qhm5cwiob/ Signed-off-by: Jun Guo Link: https://patch.msgid.link/20260115091924.844179-1-jun.guo@cixtech.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4e0f669e2951b742239c6fe847fcc406fe78748d Author: Zack Rusin Date: Tue May 5 18:22:33 2026 -0400 drm/vmwgfx: validate external BO copy bounds for both stride paths commit 706c93c5813caabbb0d0a576c017d15aeec2c113 upstream. vmw_external_bo_copy() trusts caller-supplied offsets, strides, and heights and operates on imported dma-buf vmaps: - The equal-stride memcpy() bound was clamped after subtracting the offsets from dst_size and src_size; an offset larger than the BO size wraps the unsigned subtraction to a huge value and the resulting memcpy() runs off the end of the vmap. dst_stride * height is also a u32 multiplication that can overflow. - The non-equal-stride row-by-row path had no bound at all. The loop touches bytes through offset + (height - 1) * stride + width_in_bytes, with only a WARN_ON(dst_stride < width_in_bytes), and could likewise step past the end of either mapping. The offsets and strides are derived from STDU/SOU plane state, so a configured CRTC submitting a crafted atomic commit on an imported framebuffer can reach this path. Validate the exact row-copy endpoint against each BO's size up front using check_mul_overflow() and check_add_overflow(). Use the bulk memcpy() path only when width_in_bytes covers the whole stride; otherwise copy one row at a time so partial-row updates near the bottom of a framebuffer remain valid. Also reject zero strides and stride < width_in_bytes, both of which the row-by-row path cannot represent safely. Fixes: 50f119925091 ("drm/vmwgfx: Fix prime with external buffers") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-13-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 1bbe7751f5ebac383405ef29a66622d65bd505d3 Author: Zack Rusin Date: Tue May 5 18:22:32 2026 -0400 drm/vmwgfx: use check_add_overflow for shader size+offset bound commit 54d56d5b42d2e4c72ba6e365e9774da90698aa22 upstream. vmw_shader_define() validates the user-supplied shader window against its backing buffer with (u64)buffer->tbo.base.size < (u64)size + (u64)offset drm_vmw_shader_create_arg::offset is __u64 in the uapi; when it is near U64_MAX the unsigned addition wraps and the resulting tiny value passes the check. The unbounded offset is then stored in res->guest_memory_offset and forwarded to host SVGA shader-create commands. Use check_add_overflow() to detect the wrap and compare the resulting endpoint against the buffer size. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-12-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 036e16ada95389bdc30f41068af04c1d0872fad0 Author: Zack Rusin Date: Tue May 5 18:22:28 2026 -0400 drm/vmwgfx: bound DMA command body size against suffix pointer commit f4f1db96bfd68b81053693ba53405b6f510ac16c upstream. vmw_cmd_dma() locates the DMA suffix at (unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit. Fixes: 4e4ddd477743 ("drm/vmwgfx: Fix queries if no dma buffer thrashing is occuring.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-8-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 2666cddf0dd218aa9bd1f99db688d1b532eac21a Author: Zack Rusin Date: Tue May 5 18:22:27 2026 -0400 drm/vmwgfx: validate DRAW_PRIMITIVES header size before division commit 85891d174707d8bddcec7a888fb4e1d17def34f3 upstream. vmw_cmd_draw() computes maxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front. Fixes: 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-7-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit c1c22fca0a0896a452a7cb92422d67babd65b4be Author: Zack Rusin Date: Tue May 5 18:22:26 2026 -0400 drm/vmwgfx: drop dma_buf reference on foreign-fd prime import commit f739416dc555fa205a785e5135d73fa39b26f35d upstream. ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped. Fixes: 65981f7681ab ("drm/ttm: Add a minimal prime implementation for ttm base objects") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-6-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 7eae011829f94a76470ec76f016805f508437755 Author: Zack Rusin Date: Tue May 5 18:22:23 2026 -0400 drm/vmwgfx: reject DX_BIND_QUERY without a DX context commit 55ec09c9ce10b1272802c7ab6c1be2ea0dbc68db upstream. vmw_cmd_dx_bind_query() unconditionally dereferences sw_context->dx_ctx_node->ctx. Userspace can trigger a NULL pointer dereference from any render-node fd by submitting an execbuf with dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY opcode in the command stream: dx_ctx_node is left NULL and the kernel oopses on the assignment. The same NULL is then re-read in vmw_resources_reserve() via vmw_context_get_dx_query_mob(). All sibling DX handlers fail-close on a missing dx_ctx_node using VMW_GET_CTX_NODE(). Use the same pattern here, returning -EINVAL up front before any relocation state is published. Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-3-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 21bbe38faee4a195d33a93e3908e307807f7745d Author: Zack Rusin Date: Tue May 5 18:22:22 2026 -0400 drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size commit 83195b778f2d109a3a4f3ffaba4dce7e4cdb58aa upstream. Two sites in vmwgfx_resource.c assign boolean literals to res->guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res->guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource's MOB allocation size: - vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true). Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated. Rename both assignments to guest_memory_dirty. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-2-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 2040b7e39027cb83bb8c7b84a4c95c2f6053c32f Author: William Palacek Date: Wed Jul 22 11:20:56 2026 -0400 drm/amdkfd: hold event_mutex while checkpointing CRIU events commit ff8bc5a68a9a70bdc38d61a72c7a49c56063f9d2 upstream. kfd_criu_checkpoint_events() counts the entries in p->event_idr via kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it. Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex, so a second thread in the same process can insert or remove events between the count and the walk. If an event is inserted, the walk iterates more entries than were counted and writes past the end of the ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted and no deadlock is introduced. Fixes: 40e8a766a761 ("drm/amdkfd: CRIU checkpoint and restore events") Signed-off-by: William Palacek Reviewed-by: Alysa Liu Signed-off-by: Alex Deucher (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit dec688cfa18c3ea631287839f39d6eb9ea860ea3 Author: David Francis Date: Tue Jul 21 09:30:07 2026 -0400 drm/amdkfd: Handle invalid event type in CRIU event restore commit a9cdc85839e4fe2c760aa4ca6cc341c31ad1918a upstream. In kfd_criu_restore_event, there was no handling for the event priv data having an invalid event type. The priv data here is untrusted and can be invalid. In that case, fail with EINVAL. Signed-off-by: David Francis Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 2e8e9963cd5c41aa14fd5316bf9ec92e7a0e3097) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8924e2594a15bdbd07f8696770864366d787ab70 Author: Vladimir Marioukhine Date: Mon Jul 20 11:53:30 2026 -0400 drm/amdkfd: fix QID bit leak in pqm_create_queue() commit 38b73293f38658a4685ffcea666462024f858ad9 upstream. When MES is enabled and amdgpu_amdkfd_alloc_kernel_mem() fails during the first queue creation for a process, pqm_create_queue() returns early via 'return retval' without going through the err_create_queue cleanup label. This means clear_bit(*qid, pqm->queue_slot_bitmap) is never called, leaving the reserved QID bit permanently set in queue_slot_bitmap. Over time this leaks QID slots, potentially exhausting all available queue slots. Fix this by replacing 'return retval' with 'goto err_allocate_pqn' so that clear_bit() is always called on the error path without touching the uninitialized pqn pointer. AILIKFD-813 Reported-by: Deucher, Alexander Signed-off-by: Vladimir Marioukhine Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit a107f74c38edbb80d6ab64dcaeeb292c14e9779f) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ce813614f63b020a826071276a92f2cfae7cba79 Author: Gang Ba Date: Tue Jul 14 15:08:57 2026 -0400 drm/amdkfd: Fix missing authorization check in KFD_IOC_DBG_TRAP_DISABLE commit 99b2fe4f19e3be0a8d0a0b5ea98d855970889653 upstream. Prevent unauthorized termination of active GPU debug sessions. Previously, users with /dev/kfd access could terminate another process's debug session without proper ownership or ptrace authorization. Signed-off-by: Gang Ba Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 4db4c5ffd5585b72622ecf6ffedf2da258ee23f5) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 668441cff9e05b04eed3c0e8af05c957fb1f3b8a Author: Harkirat Gill Date: Mon Jul 27 14:37:56 2026 -0400 drm/amdgpu: cap GTT size to physical RAM on APUs commit 5e70f6804b4d6256058c360b10e044ee04ea4a4e upstream. On APUs, the GTT pool is backed by system RAM, but its size is not bound to the non-carveout memory that actually backs it. A user can end up with GTT + VRAM exceeding total physical memory through the following sequence: - Have a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS by increasing the UMA Frame Buffer Size (VRAM) to 64GB. - The previously set GTT value (~100GB) persists, even though the new non-carveout space (64GB) can no longer back it. This leads to a case where kernel reports GTT (100GB) + VRAM (64GB) despite the sum being greater than total physical memory (128GB). Cap the GTT size to totalram_pages() on APUs. totalram_pages() already excludes the VRAM carveout, so the resulting GTT can never exceed the system RAM that actually backs it. Signed-off-by: Harkirat Gill Reviewed-by: David Francis Assisted-by: Claude:claude-opus-4 Signed-off-by: Alex Deucher (cherry picked from commit 5dafdd649280c7dc6c22c8f877da3f54fcc441e1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ef3fa445edc0319a2c3d027e8610cfcb02629967 Author: Candice Li Date: Tue Jul 21 21:38:58 2026 +0800 drm/amdgpu: restore UMD profile pstate after runtime resume commit f931c54b241ce2f36bfc34955aec43a188276b8d upstream. Runtime suspend runs GFX hw_fini and clears perfmon clock gating while the UMD profile DPM level remains set in software. Re-apply stable pstate after a successful runtime resume when a profile mode is active. Signed-off-by: Candice Li Reviewed-by: Hawking Zhang Reviewed-by: Yang Wang Signed-off-by: Alex Deucher (cherry picked from commit 138531c8850cc247aa12b104bb29ea387bcdcbb1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8112f0a9396e39983ab7aebd7c8536acae4ba441 Author: Myeonghun Pak Date: Wed Jul 22 00:22:42 2026 +0900 drm/mediatek: ovl_adaptor: balance component registrations commit 533e3469a57996905cdb95f178e7efe38c21aeb2 upstream. The OVL adaptor registers both an aggregate driver for its child devices and a component for the main DRM aggregate. Probe currently ignores an error from registering the child aggregate and leaves that aggregate registered if registering the DRM component fails. The remove callback also leaves the DRM component registered. These imbalances can leave component framework entries referring to a device whose probe failed or whose driver has been detached. The aggregate unbind callback also fails to undo component_bind_all(), leaving its child components marked as bound when the aggregate is removed. Check the aggregate registration result, unwind it when the component registration fails, and unregister the component before the aggregate on remove. Keep runtime PM enabled until both framework registrations have been removed, and unbind all child components from the aggregate unbind callback. Fixes: 453c3364632a ("drm/mediatek: Add ovl_adaptor support for MT8195") Cc: stable@vger.kernel.org # 6.4+ Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260721152242.47138-1-mhun512@gmail.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit f5802be65535f8818af7191159cf8c11f48ab2a2 Author: Maíra Canal Date: Mon Jul 27 11:32:29 2026 -0300 drm/vc4: Zero the tile state data array before each BIN job commit 48a570c964d8e37d353381e4195106277e17f5cb upstream. The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the "Auto-initialise Tile State Data Array" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool. Link: https://github.com/raspberrypi/linux/issues/3221 [1] Link: https://github.com/raspberrypi/linux/issues/5780 [2] Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.") Cc: stable@vger.kernel.org Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260727-vc4-bin-oom-fixes-v2-2-0d8a5eddc7c9@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 2f2291a119e9a8b696ae8bb36e86b75d272ceaea Author: Jose Maria Casanova Crespo Date: Mon Jul 27 11:32:28 2026 -0300 drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size commit 6395789e4739aa5177bbec0fa0f07ccc38d249b0 upstream. vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB binner BO, but writes the size of the whole BO to BPOS. On every binner out-of-memory event the PTB is therefore authorized to write tile lists across all the other slots (which may hold the tile state, tile alloc and overflow memory of in-flight jobs) and, for any slot but the first, past the end of the binner BO into unrelated CMA memory. Since CMA pages are recycled into page cache and user allocations, this is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU hangs with corrupted control list pointers, userspace heap corruption, a GPU that stays permanently wedged after the first hang, and occasional full system crashes, whenever a job overflows the initial binner slot. The bug dates back to the conversion from a dedicated overflow BO (where writing the full BO size was correct) to the slotted binner BO. Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Jose Maria Casanova Crespo Reviewed-by: Maíra Canal Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260727-vc4-bin-oom-fixes-v2-1-0d8a5eddc7c9@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 13bd7cf63610ac1216253e6fc2fdb01e55cb3d5f Author: Alexander Kaplan Date: Wed Jun 10 21:38:25 2026 +0200 drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs commit e40e20ac089e32f1d910636155dc82e61e61dcf3 upstream. The PCON max FRL bandwidth field lives in byte 2 of the DFP Detailed Capability Info (DPCD 0x82 for the first DFP). The DP standard defines the meaning of descriptor bytes 1-3 strictly per DFP type, and for a DisplayPort type DFP all of them are reserved, with "read all 0s" semantics (DP v2.0, section 2.12.3, Table 2-183). The FRL bandwidth field is an HDMI DFP extension added by the VESA DP-to-HDMI PCON specification. drm_dp_get_pcon_max_frl_bw() however parses the byte without checking the DFP type, the branch presence or DETAILED_CAP_INFO_AVAILABLE. Without the latter the port descriptors are one byte wide and port_cap[2] is not even the right register. All neighbouring helpers parsing the same descriptor are scoped by the DFP type already, see for instance drm_dp_downstream_max_bpc() reading the same byte and returning 0 for a DP type DFP. amdgpu's DC parses the field only for HDMI(/DP++) detailed types as well. This is not theoretical. A Synaptics VMM7100 based USB-C to HDMI adapter with a macOS targeted firmware advertises a DisplayPort type DFP with the type byte replicated across the whole descriptor (08 08 08 08). i915 decodes that as "PCON limited to 18 Gbps FRL" and prunes every mode above ~750 MHz dotclock, including all the 4k@100/120 modes the sink EDID offers, while macOS drives 4k@120 through the same adapter just fine via DP DSC (and amdgpu's type-scoped parser would ignore the bogus field as well). Only parse the field for an HDMI DFP behind a DPCD 1.1+ branch device that reports detailed cap info, matching the type-scoped field layout of the spec and the rest of the helpers. Fixes: ce32a6239de6 ("drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON") Cc: Ankit Nautiyal Cc: Uma Shankar (v2) Cc: Jani Nikula Cc: Maarten Lankhorst Cc: dri-devel@lists.freedesktop.org Cc: # v5.12+ Signed-off-by: Alexander Kaplan Reviewed-by: Ankit Nautiyal Signed-off-by: Ankit Nautiyal Link: https://patch.msgid.link/20260610193825.2933-1-alexander.kaplan@sms-medipool.de Signed-off-by: Greg Kroah-Hartman commit 3c9d12561601f358bfb7544123caca5f65bb3315 Author: Avi Weiss Date: Thu Jul 23 18:55:43 2026 +0300 can: ctucanfd: mark error-active controller status valid commit 4e735cbe3affe88001428fdd9cae8e685ce92f21 upstream. In the CAN_STATE_ERROR_ACTIVE case, cf->data[1] is set to CAN_ERR_CRTL_ACTIVE, but cf->can_id is not set with CAN_ERR_CRTL in that path. Set CAN_ERR_CRTL so consumers know the controller-status information in cf->data[1] is valid. Fixes: 9bd24927e3ee ("can: ctucanfd: handle skb allocation failure") Signed-off-by: Avi Weiss Link: https://patch.msgid.link/20260723155543.318414-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 4c453560d3c299956a22c7799298769d65442db8 Author: Avi Weiss Date: Thu Jul 23 10:44:03 2026 +0300 can: ctucanfd: handle bus error interrupts commit e74bae899529f49c0f375307983d12e8ecad7d4b upstream. Include REG_INT_STAT_BEI in the top-level error interrupt condition. BEI is enabled when CAN_CTRLMODE_BERR_REPORTING is requested and ctucan_err_interrupt() already handles it. Without checking and clearing BEI in the top-level handler, bus error interrupts are not handled or acknowledged. Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.") Signed-off-by: Avi Weiss Acked-by: Pavel Pisa Link: https://patch.msgid.link/20260723074403.131575-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 4a666e648c6bd5a6697a273ae39714fc0595803b Author: Avi Weiss Date: Thu Jul 23 12:59:34 2026 +0300 can: ctucanfd: unmap BAR0 using base address commit a6873910f983096746d1a2e0af94f36b8003e839 upstream. BAR0 is mapped into bar0_base, while cra_addr points to an offset within that mapping and is used for other purposes. Pass bar0_base to pci_iounmap(), instead of cra_addr, on the probe error path so the address returned by pci_iomap() is used for unmapping. Fixes: 792a5b678e81 ("can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.") Signed-off-by: Avi Weiss Acked-by: Pavel Pisa Link: https://patch.msgid.link/20260723095934.181042-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit bfc20e429de9b29762fccf68c7a367cf8a8b3895 Author: Avi Weiss Date: Wed Jul 22 22:27:26 2026 +0300 can: ctucanfd: use self-test mode for PRESUME_ACK commit c31a435933f18be0f874302161333e9f16e200a0 upstream. Use self-test mode for CAN_CTRLMODE_PRESUME_ACK so transmitted frames can complete without receiving an ACK. ACK forbidden mode prevents the controller from acknowledging received frames and does not implement the presume-ack behavior. Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.") Signed-off-by: Avi Weiss Acked-by: Pavel Pisa Link: https://patch.msgid.link/20260722192726.230729-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 5bdd69e8301b1c2cc80c15c68b7ee8d32c47608b Author: Pengpeng Hou Date: Sat Jul 4 23:19:57 2026 +0800 can: ctucanfd: add missing MODULE_DEVICE_TABLE() commit d937bdb244a751fe5967052ea2d64a7b2c476cc0 upstream. The driver has a match table for the pci bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Acked-by: Pavel Pisa Link: https://patch.msgid.link/20260704151957.48194-1-pengpeng@iscas.ac.cn Fixes: 792a5b678e81 ("can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.") Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 6067c878e38d02a3d5c43497347e143f85c9064a Author: Pengpeng Hou Date: Mon Jul 6 17:28:36 2026 +0800 can: peak_usb: validate uCAN receive record lengths commit 93fcab2c6968446316bbb49548848df604d6346f upstream. pcan_usb_fd_decode_buf() walks uCAN records packed in one USB receive buffer. Require each record to contain the fixed header for its type, and verify CAN payload bytes before copying them into the skb. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706092836.79754-1-pengpeng@iscas.ac.cn Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters") Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 525640b93d3e5f82f4ebea4730f4e0cf799522ba Author: Maoyi Xie Date: Wed Jun 17 02:15:31 2026 +0800 can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error commit 9b3d5a6d952c38bbcf07f903cbeadefdb56b9bc9 upstream. In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 ("net: usb: lan78xx: Fix double free issue with interrupt buffer allocation"). Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core") Closes: https://lore.kernel.org/linux-can/178159320216.2154888.16953451793788581739@maoyixie.com/T/#u Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/178163373110.2507866.216458825145756798@maoyixie.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 825c903ca3c98cd0cf0e3de8ab8f2604a5339b3f Author: James Gao Date: Wed May 20 13:40:03 2026 +0800 can: peak_usb: add bounds check for USB channel index commit 39132f166ca8ce00ae60d8a9068e06a60943cc4b upstream. The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error(). Fixes: d8a199355f8f ("can: usb: PEAK-System Technik PCAN-USB Pro specific part") Signed-off-by: James Gao Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/TYWPR01MB8559DBAAAA6A7F410400329CF0012@TYWPR01MB8559.jpnprd01.prod.outlook.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit ae588e5b9cc268de1aabf30f939f0870717ca164 Author: Pengpeng Hou Date: Wed Jul 22 12:43:47 2026 +0800 can: softing: fw_parse(): validate firmware record spans commit 856d6cb04e5407523566b075841dcd6423757d1c upstream. fw_parse() reads a fixed record header, a firmware-provided payload, and a trailing checksum without knowing the end of the firmware blob. A truncated record can therefore make those reads exceed the blob. The same record also supplies addresses and lengths for writes into DPRAM. The generic loader uses wrap-prone mixed signed arithmetic for its bounds check, while the application loader does not bound the staging copy at all. Pass the firmware end to the parser and validate the full source record. Use a signed wide offset for generic DPRAM records and validate the application staging span against the mapped DPRAM before copying. Fixes: 03fd3cf5a179 ("can: add driver for Softing card") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260722044347.2708-1-pengpeng@iscas.ac.cn Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 695aea154bb2d453e6daada1510972fafd075285 Author: Pengpeng Hou Date: Wed Jul 22 12:22:21 2026 +0800 can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents commit 0293dd153f9dbc1ddf5dacdccc76b363bce4a8ee upstream. The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260722042221.44066-1-pengpeng@iscas.ac.cn Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit b954b108891e595b385b3d402497832072ef42c1 Author: Abdun Nihaal Date: Wed Jul 22 16:09:03 2026 +0530 can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in kvaser_usb_hydra_get_busparams() commit 941eaf9a6d3b33dea49f2c0a1da7546a03b6ff71 upstream. The memory allocated for cmd is not freed after the call to kvaser_usb_send_cmd() in both the normal and error paths. Fix that by adding a kfree() immediately after the call. Fixes: 39d3df6b0ea8 ("can: kvaser_usb: Compare requested bittiming parameters with actual parameters in do_set_{,data}_bittiming") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260722103906.108571-1-nihaal@cse.iitm.ac.in Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 30b0b76918834984ce12d1d062da197400576cd9 Author: Tetsuo Handa Date: Tue Jul 28 07:58:34 2026 +0200 can: j1939: use netdevice_tracker for j1939_{priv,session,ecu} tracking commit d2fb981384b3a45f690616d550b29046e8ad16a4 upstream. syzbot is still reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem. A debug printk() patch in linux-next-20260508 identified that there is dev_hold()/dev_put() imbalance in j1939_priv management. Call trace for vcan0[26] +4 at __dev_hold include/linux/netdevice.h:4470 [inline] netdev_hold include/linux/netdevice.h:4513 [inline] dev_hold include/linux/netdevice.h:4536 [inline] j1939_priv_create net/can/j1939/main.c:140 [inline] j1939_netdev_start+0x36b/0xc10 net/can/j1939/main.c:268 j1939_sk_bind+0x853/0xb30 net/can/j1939/socket.c:506 __sys_bind_socket net/socket.c:1948 [inline] __sys_bind+0x2e9/0x410 net/socket.c:1979 Call trace for vcan0[28] -3 at __dev_put include/linux/netdevice.h:4456 [inline] netdev_put include/linux/netdevice.h:4523 [inline] dev_put include/linux/netdevice.h:4548 [inline] __j1939_priv_release net/can/j1939/main.c:166 [inline] kref_put include/linux/kref.h:65 [inline] j1939_priv_put+0x128/0x270 net/can/j1939/main.c:172 j1939_sk_sock_destruct+0x52/0x90 net/can/j1939/socket.c:388 __sk_destruct+0x8d/0x9d0 net/core/sock.c:2352 rcu_do_batch kernel/rcu/tree.c:2617 [inline] rcu_core kernel/rcu/tree.c:2869 [inline] rcu_cpu_kthread+0x99e/0x1470 kernel/rcu/tree.c:2957 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 This refcount leak in j1939_priv might be caused by a refcount leak in j1939_{session,ecu} because j1939_{session,ecu} holds a ref on j1939_priv. For further investigation using upstream kernels, enable netdevice_tracker in j1939_{priv,session,ecu} management. Signed-off-by: Tetsuo Handa Acked-by: Oleksij Rempel Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260728055835.1151785-2-o.rempel@pengutronix.de Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 194d67e92197eb820f4c2c6605d9721333b3eba0 Author: Oleksij Rempel Date: Tue Jul 28 07:58:35 2026 +0200 can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer commit eb96c58907922546e415e545fe9a14ea63b02719 upstream. Zero the allocated buffer in j1939_session_fresh_new() to ensure it contains no residual data. While there is a potential performance impact if users allocate maximum sized ETP buffers, most real-world use cases are not noticeably affected since the maximum known buffer size is typically around 65K. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Reported-by: Ji'an Zhou Message-ID: Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260728055835.1151785-3-o.rempel@pengutronix.de Cc: stable@kernel.org [mkl: add Message-ID] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 5e2fd705c92e9faab39879d8dbf3847ee4771ca1 Author: Marc Kleine-Budde Date: Thu Jul 9 09:54:26 2026 +0200 can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb allocation failure commit 68c5724ecd159992f76edb7b57dc508a44c8b7da upstream. If the allocation of the SKB in gs_usb_receive_bulk_callback() fails, the driver returns from the callback without resubmitting the URB in order to receive further USB in URBs. This results in a silent performance degradation which, if it occurs repeatedly, results in starvation of USB in traffic. Instead of returning immediately, try to resend the URB. If this also fails, this is logged as an info message. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Fixes: 26949ac935e3 ("can: gs_usb: add CAN-FD support") Link: https://patch.msgid.link/20260709-gs_usb-resubmit-urb-v1-1-4dd40030cc84@pengutronix.de Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 0ef136ba052101243ba117a1aca6f4a4c3a81142 Author: Guangshuo Li Date: Mon Jul 6 09:46:01 2026 +0800 can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure commit 7a0cf2b2497c757c3cb1286eddf2986abb0d387b upstream. es58x_read_bulk_callback() resubmits the RX URB after processing a received packet. If the resubmit succeeds, the URB remains anchored and will be handled by the normal RX path or by teardown. However, if usb_submit_urb() fails, the callback unanchors the URB and then returns directly. This skips the existing free_urb path, so the coherent transfer buffer allocated with usb_alloc_coherent() is not released. Reuse the existing free_urb path after a resubmit failure so that the RX coherent buffer is freed before leaving the callback. Fixes: 5eaad4f76826 ("can: usb: etas_es58x: correctly anchor the urb in the read bulk callback") Signed-off-by: Guangshuo Li Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20260706014601.415445-1-lgs201920130244@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit ce8125566b1d0b0f16449407e014addf451804ea Author: Pengpeng Hou Date: Mon Jul 6 17:27:52 2026 +0800 can: ems_usb: validate CPC message lengths commit 02925f51377f2a42a6724f00549167499c9302e5 upstream. ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706092752.79600-1-pengpeng@iscas.ac.cn Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 29bc050802ded3ce2464c3f9bdf9a89fb7fe80c0 Author: Lucas Martins Alves Date: Tue Jul 14 16:48:57 2026 +0000 can: c_can: c_can_chip_config(): keep controller in init mode until bittiming is configured commit 26504844613fb44c7cab1c5f6fcff77861709baa upstream. c_can_chip_config() was programming C_CAN_CTRL_REG without CONTROL_INIT, which may allow the controller to become active before c_can_set_bittiming() finishes. That creates a short timing window where the peripheral can interact with the bus using a different/default bitrate, potentially generating bus errors and corrupting traffic. Set CONTROL_INIT together with the control-mode writes in c_can_chip_config() (normal, loopback and listen-only paths), so the controller stays halted until bit timing is fully programmed. This prevents transient bus disturbance during startup when the configured bitrate differs from the active bus bitrate. Signed-off-by: Lucas Martins Alves Link: https://patch.msgid.link/20260714164839.771123-1-lucas.alves@lumal21.com.br Fixes: 881ff67ad450 ("can: c_can: Added support for Bosch C_CAN controller") Cc: stable@kernel.org [mkl: remove space before close parenthesis] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit a8a1f9ac3d763e721586f15479ef9140b216ddf3 Author: Liem Date: Mon Jun 29 10:38:29 2026 +0800 i2c: imx: Cancel hrtimer before clearing slave pointer commit 6ac7702b6cc2b94aaed9ef2d95bfbefcdc90061f upstream. In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer. Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver") Signed-off-by: Liem Cc: # v5.11+ Acked-by: Carlos Song Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260629023829.152651-3-liem16213@gmail.com Signed-off-by: Greg Kroah-Hartman commit b9f6f4883b9ac86654e75899d0dbf8a7a96ad5d8 Author: Liem Date: Mon Jun 29 10:38:28 2026 +0800 i2c: imx: Fix slave registration race and error handling commit d64ec362c369bbc33833f7936d5f3a706b0d5c45 upstream. In i2c_imx_reg_slave(), the slave pointer was assigned before pm_runtime_resume_and_get(). If pm_runtime_resume_and_get() failed, the error path returned without clearing i2c_imx->slave, leaving it non-NULL and causing all subsequent registration attempts to fail with -EBUSY. Additionally, because this driver uses a shared IRQ, the interrupt handler i2c_imx_isr() can execute concurrently and, after acquiring slave_lock, dereference i2c_imx->slave. The previous fix attempt added a lockless i2c_imx->slave = NULL on the error path, but that could race with the ISR under the lock and still cause a NULL pointer dereference. Fix both issues by deferring the assignment of i2c_imx->slave and i2c_imx->last_slave_event to after a successful resume, and by performing the assignment inside the slave_lock critical section. This guarantees that the slave pointer is never left stale on the error path and is always valid when observed by the interrupt handler. Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver") Signed-off-by: Liem Cc: # v5.11+ Reviewed-by: Frank Li Acked-by: Carlos Song Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260629023829.152651-2-liem16213@gmail.com Signed-off-by: Greg Kroah-Hartman commit 14429dc1c756c35e106f01ff09cadccb82f5531d Author: H. Nikolaus Schaller Date: Sun Jul 19 22:19:43 2026 +0200 i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock commit d99607c888f26e8a4e9fe9772860cef4aff86bb4 upstream. Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message). Fixes: ba92222ed63a12 ("i2c: jz4780: Add i2c bus controller driver for Ingenic JZ4780") Signed-off-by: H. Nikolaus Schaller Cc: # v4.1+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/2db6fd233aceb7238474e4833f4d25ca681c3ffb.1784492382.git.hns@goldelico.com Signed-off-by: Greg Kroah-Hartman commit 2b760e8f0ead09e1664e056eae16493abf1f1890 Author: Dawei Feng Date: Tue Jun 16 23:57:42 2026 +0800 ice: fix memory leak in ice_lbtest_prepare_rings() commit 3a9de5590da4ffd9e9c541c4c4d492aa2b54cf6e upstream. ice_lbtest_prepare_rings() frees Rx rings only when ice_vsi_start_all_rx_rings() fails. If ice_vsi_setup_rx_rings() fails after allocating some descriptors, or if ice_vsi_cfg_lan() fails after the Rx rings were prepared, the function reaches the Tx cleanup path without releasing the initialized Rx resources. Fix this by adding separate unwind paths for Rx setup failure and LAN configuration failure. The Rx setup failure path releases the partially prepared Rx rings before freeing Tx rings, while later failures first undo the LAN Tx configuration and then release the Rx rings in reverse setup order. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an Intel E800 Series adapter available to run the ethtool offline loopback selftest, no runtime testing was able to be performed. Fixes: 0e674aeb0b77 ("ice: Add handler for ethtool selftest") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Reviewed-by: Jacob Keller Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 5dd5485189c0747d0950dad0ea7bacf9f0e6598f Author: Aaron Ma Date: Wed Apr 29 11:48:49 2026 +0800 ice: wait for reset completion in ice_resume() commit c2816d613f388814d27bc9fd6dbd931a88056e19 upstream. ice_resume() schedules an asynchronous PF reset and returns immediately. The reset runs later in ice_service_task(). If userspace tries to bring up the net device before the reset finishes, ice_open() fails with -EBUSY: ice_resume() ice_schedule_reset() # sets ICE_PFR_REQ, returns ... ice_open() ice_is_reset_in_progress() # ICE_PFR_REQ still set, -EBUSY ... ice_service_task() ice_do_reset() ice_rebuild() # clears ICE_PFR_REQ, too late Reproduced on E800 series NICs during suspend/resume with irdma enabled, where the aux device probe widens the race window. ice 0000:81:00.0: can't open net device while reset is in progress Add a best-effort wait (10s timeout, matching ice_devlink_info_get()) for the reset to complete before returning from ice_resume(). In practice the reset completes in ~300ms. Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL") Cc: stable@vger.kernel.org Reviewed-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Signed-off-by: Aaron Ma Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 736e972f3f8a304158345223ac6e816166a467ce Author: Ilya Maximets Date: Mon Jul 27 20:18:31 2026 +0200 net: openvswitch: fix skb leak on flow key update failure during ct commit bc62e843bc48f933da765ce47079fd992e535794 upstream. ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko. Fixes: ec0d043d05e6 ("openvswitch: Ensure flow is valid before executing ct") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260727181851.306076-3-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 27b3eb4fc407e4034716e399d570f62ebc6f78a2 Author: Ilya Maximets Date: Mon Jul 27 20:18:30 2026 +0200 net: openvswitch: fix skb leak on flow key update failure during recirculation commit e1cf066244dad576221b7123a0e5005967f25a20 upstream. do_execute_actions() returns right away when execute_recirc() fails on the last action as it assumes this function always takes ownership of the skb when 'last' is true. But when the flow key update fails, the function doesn't free the skb and it ends up leaked. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko. Fixes: 971427f353f3 ("openvswitch: Add recirc and hash action.") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260727181851.306076-2-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0310d1fa7f9debd0d89629e9f14c7975a47eaa9a Author: Ilya Maximets Date: Mon Jul 27 14:10:21 2026 +0200 net: openvswitch: fix potential UAF on meter attach failure commit a58a2b0ce354df531ebc71fc870058c2feb59f6b upstream. While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the "hash" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642. Fixes: c7c4c44c9a95 ("net: openvswitch: expand the meters supported number") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Eelco Chaudron Link: https://patch.msgid.link/20260727121022.198461-1-i.maximets@ovn.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 1f1a8ca58641bd7c48d9b998ba955aa45c0ba84a Author: Nava kishore Manne Date: Sat Jun 27 21:22:29 2026 +0530 phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB commit 7eb61caf45607e1e1270f51f8f93f0ded53146da upstream. USB Gen1 requires scrambling and 8b/10b encoding to be performed in the physical layer. Do not bypass PHY-side scrambler or encoder/decoder for USB operation, as mandated by the USB 3.x specification. Scrambler and 8b/10b bypass remain restricted to SATA and SGMII modes, where encoding is handled in the controller. Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver") Cc: stable@vger.kernel.org Signed-off-by: Nava kishore Manne Signed-off-by: Radhey Shyam Pandey Acked-by: Michal Simek Link: https://patch.msgid.link/20260627155229.2791113-4-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit bf3985016cc09e256bb8b808abaa8adb0bad706d Author: Nava kishore Manne Date: Sat Jun 27 21:22:28 2026 +0530 phy: zynqmp: use read-modify-write for SERDES scrambler bypass commit 21e0749f931702765b9d52d05740092bc87fcd8d upstream. xpsgtr_bypass_scrambler_8b10b() used xpsgtr_write_phy() which performs a full register write, silently clearing any bits beyond the intended bypass control fields. Switch to xpsgtr_clr_set_phy() with clr=mask, set=mask to set only the bypass bits while preserving the remaining bits in each register. Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver") Cc: stable@vger.kernel.org Signed-off-by: Nava kishore Manne Signed-off-by: Radhey Shyam Pandey Acked-by: Michal Simek Link: https://patch.msgid.link/20260627155229.2791113-3-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 9a83affa2fa14de554894ed43dbead79f03064b3 Author: Nava kishore Manne Date: Sat Jun 27 21:22:27 2026 +0530 phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask commit 6cb22477929489a412df8d153e550e77a012e701 upstream. The L0_TX_DIG_61 register bit 2 is a reserved read-only field. The previous mask value 0x0f incorrectly included bit 2, causing unintended writes to a reserved bit on every scrambler bypass operation. Correct the mask to (BIT(3) | GENMASK(1, 0)) to cover only the valid scramble bypass control bits. Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver") Cc: stable@vger.kernel.org Signed-off-by: Nava kishore Manne Signed-off-by: Radhey Shyam Pandey Acked-by: Michal Simek Link: https://patch.msgid.link/20260627155229.2791113-2-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit dd25bd9b0f36849808bd7625dcc59dd4c1aeef3e Author: Holger Dengler Date: Wed Jul 29 11:36:16 2026 +0200 s390/zcrypt: Validate length for CCA ECC private key requests commit a9ae0f6dd45c3ccc1d69363f7aea8af179122730 upstream. cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 406b317ea2b501f6f5eca1264293c9399a73a778 Author: Holger Dengler Date: Wed Jul 29 11:36:15 2026 +0200 s390/zcrypt: Validate length for CCA AES cipher key requests commit 06afe425d5283b9764303de47f554da5a808ce8a upstream. cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block. Fixes: 4bc123b18ce6 ("s390/zcrypt: Add low level functions for CCA AES cipher keys") Signed-off-by: Holger Dengler Cc: stable@vger.kernel.org # 5.4+ Reviewed-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit b505dcc8307d64468b463dfad45a03bf865c637e Author: Harald Freudenberger Date: Thu Jul 23 11:54:52 2026 +0200 s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs commit 983279d7f86ade73db86f886e09172dd567031b5 upstream. There is a wrong upper limit check for the domain value when an EP11 CPRB is processed for sending to a crypto card. This check is only active on custom device nodes but may lead to access heap memory behind perms->adm when an administrative CPRB is sent. Add correct limit (AP_DOMAINS = 256) checking to fix this. Fixes: cfd68b33094e ("s390/zcrypt: Filter admin CPRBs on custom devices") Cc: stable@vger.kernel.org Reviewed-by: Finn Callies Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit aca18289c86f22d3fc2f3f6ff615286e7b1702f6 Author: Stefan Haberland Date: Mon Jul 27 16:28:40 2026 +0200 s390/dasd: Fix undersized format-check buffer commit 7f40b346462f563a0d6e841a77b5163d2a882a04 upstream. fmt_buffer_size in dasd_eckd_check_device_format() is declared as int, even though one of the multiplicands, sizeof(struct eckd_count), is a size_t. The expression trkcount * rpt_max * sizeof(struct eckd_count) is therefore correctly evaluated at 64-bit width, but the result is silently truncated when it is stored back into the 32-bit fmt_buffer_size variable. For a sufficiently large track range (start_unit/stop_unit are caller-controlled) this truncation yields a buffer size far smaller than the number of tracks actually requested. kzalloc() then succeeds with an undersized allocation, while the subsequent channel program build still operates on the untruncated track count and writes past the end of that buffer. Compute the buffer size with check_mul_overflow() and keep it in a size_t, so that a value that no longer fits results in -EINVAL instead of a silently truncated allocation size. Fixes: 8fd575200db5 ("s390/dasd: Add new ioctl BIODASDCHECKFMT") Cc: stable@vger.kernel.org #4.7 Reviewed-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260727142840.567286-4-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e156c70c505c6c9adce3b7be5a82025f00544709 Author: Jan Höppner Date: Mon Jul 27 16:28:39 2026 +0200 s390/dasd: Fix potential NULL pointer dereference commit 9973026f572db6b67570cadc30942f3014e41079 upstream. dasd_release_space() checks the implementation of the is_ese() discipline function before calling it to determine if a given device is an ESE DASD. The current usage of the logical AND operator will lead to a NULL pointer dereference as the function is called even if the function pointer is NULL. Fix this by using the logical OR operator. Fixes: 91dc4a197569 ("s390/dasd: Add new ioctl to release space") Cc: stable@vger.kernel.org # v5.3+ Reported-by: Vasily Gorbik Acked-by: Eduard Shishkin Reviewed-by: Stefan Haberland Signed-off-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260727142840.567286-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4e48168825818bf4a13c743582227d15f1d30d04 Author: Aswin Karuvally Date: Thu Jul 23 16:00:50 2026 +0200 s390/qeth: Check CAP_NET_ADMIN for private ioctls commit d211028bac1bd0fff0026bfa2a8328e5b78cd0e6 upstream. Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL, SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN capable check to ensure unprivileged users cannot invoke them. Fixes: 18787eeebd71 ("qeth: use ndo_siocdevprivate") Cc: stable@vger.kernel.org Suggested-by: Christian Borntraeger Reviewed-by: Christian Borntraeger Reviewed-by: Alexandra Winter Signed-off-by: Aswin Karuvally Link: https://patch.msgid.link/20260723140050.762991-1-aswin@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a92df2b3d7a33d171a73dfab0e61caaa596e182e Author: Xu Rao Date: Thu Jul 23 14:54:44 2026 +0800 power: supply: bq25890: fix the -10 C NTC lookup entry commit 160a783aa65b74782bc17cb874af1a6d3f5fba3c upstream. The TSPCT lookup table is monotonically decreasing except for ADC code 121, where the sequence reads -9.0 C, -1.0 C, -12.0 C. This makes the reported battery temperature jump upward by eight degrees for one code and then downward by eleven degrees for the next code. The entry is a missing zero: use -10.0 C so the sequence remains monotonic between -9.0 C and -12.0 C. Fixes: 9652c02428f3 ("power: bq25890: add POWER_SUPPLY_PROP_TEMP") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Link: https://patch.msgid.link/0619C8BF15F43B7C+20260723065444.1796002-1-raoxu@uniontech.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit a57082657fa5b5641f7793e7f93023addfee414e Author: Abdun Nihaal Date: Mon Jul 27 15:05:51 2026 +0530 cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init() commit d5f8e5f6040d052d44fcbf4f31dd35145c0c8d7d upstream. The memory allocated for data->powernow_table inside powernow_k8_cpu_init_acpi() or find_psb_table() is not freed in one of the error paths in powernowk8_cpu_init(). Fix that by adding a kfree(). Fixes: 1ff6e97f1d99 ("[CPUFREQ] cpumask: avoid playing with cpus_allowed in powernow-k8.c") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Acked-by: Viresh Kumar Reviewed-by: Zhongqiu Han Link: https://patch.msgid.link/20260727093553.98246-1-nihaal@cse.iitm.ac.in Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 83467180e05795a416cf8c9cb3828c5f2820edfc Author: bui duc phuc Date: Mon Jul 27 15:02:05 2026 +0700 gpio: pca953x: fix cache_only and IRQ state on restore_context() failure commit d233087c19f6607ef926ac3f47d776e2406ffd1f upstream. When pca953x_restore_context() fails, cache_only is left disabled and the IRQ left enabled, even though register synchronization may not have completed successfully. Restore cache_only and disable the IRQ again on failure, matching the state set by pca953x_save_context(). Fixes: ec5bde62019b ("gpio: pca953x: Split pca953x_restore_context() and pca953x_save_context()") Fixes: 3e38f946062b ("gpio: pca953x: fix IRQ storm on system wake up") Cc: stable@vger.kernel.org Reviewed-by: Linus Walleij Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260727080205.16353-1-phucduc.bui@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit b7c2c5c8868737926410b93d1223ada17625ead3 Author: Myeonghun Pak Date: Tue Jul 21 23:41:47 2026 +0900 i2c: amd-mp2: Unregister callback on adapter add failure commit 82048795242f04275a3f49ffc66ad851b6120954 upstream. amd_mp2_register_cb() stores the platform I2C context in the MP2 PCI driver's callback table before the adapter is registered. If i2c_add_adapter() fails, probe returns and devres frees the context, but the PCI driver can still dereference the stale pointer from its IRQ and system-sleep callbacks. Unregister the callback before returning the adapter registration error. Fixes: 529766e0a011 ("i2c: Add drivers for the AMD PCIe MP2 I2C controller") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Cc: # v5.2+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260721144147.31150-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit d20f04fb30bdf28635852df88e8fbdb5bc3205d5 Author: Vincent Jardin Date: Thu Jul 23 17:44:56 2026 +0200 hwmon: (pmbus/core) notify on the hwmon device, not the i2c client commit a64a7e8a0b012ba81b0eadbd7afc84ab0dbfd70c upstream. pmbus_notify() calls sysfs_notify() and kobject_uevent() on the i2c client's kobject, but the alarm attributes live on the hwmon class device registered by pmbus_do_probe(). Notifying the parent i2c device is a no-op for both poll(POLLPRI) waiters and udev listeners: the named attribute does not exist on that kobject. Notify the hwmon device instead, so poll() wakes up and "change" uevents fire on the inX_alarm/tempX_alarm attributes when SMBALERT# reports a fault. Fixes: f469bde9afd1 ("hwmon: (pmbus/core) Notify hwmon events") Cc: stable@vger.kernel.org # v6.4+ Signed-off-by: Vincent Jardin Link: https://lore.kernel.org/r/20260723-fix_hwmon_notify_v1-v1-1-5a24c528686d@free.fr Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit c985e96fa3e3ad1ef47caf7ed47ffde41c8dbb81 Author: Hongyan Xu Date: Wed Jul 29 18:01:16 2026 +0800 hwmon: (npcm750-pwm-fan): stop fan timer on device detach commit f27f6976ea269219c1259a7c2f8c6dfe782540a3 upstream. When a fan tach channel is present, npcm7xx_pwm_fan_probe() starts fan_timer. The timer callback polls tach state and rearms the timer, but the driver has no remove callback or devm cleanup action to stop it. On device detach, the devm-managed driver data and I/O mappings can be released while the timer is still pending or running. Register a devm cleanup action before starting the timer and shut the timer down synchronously from that action. This issue was found by a static analysis tool. Fixes: f1fd4a4db777 ("hwmon: Add NPCM7xx PWM and Fan driver") Cc: stable@vger.kernel.org Signed-off-by: Hongyan Xu Link: https://lore.kernel.org/r/20260729100116.790-1-getshell@seu.edu.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 546221b86ceeba0d8fec92d46a0604bb7b62be07 Author: Asim Viladi Oglu Manizada Date: Sat Jul 25 03:21:06 2026 +0000 sctp: prevent peer transport count overflow commit bd0e9289e2642f6a5c54faad304ce0f41e926d22 upstream. sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit. Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Cc: stable@vger.kernel.org Signed-off-by: Asim Viladi Oglu Manizada Acked-by: Xin Long Link: https://patch.msgid.link/20260725032053.521705-1-manizada@pm.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 61baa5020b0afb41bfd97f8f6ce5e336c4a4546e Author: Yuxiang Yang Date: Thu Jul 23 22:56:23 2026 +0000 sctp: reject stale cookies with mismatched verification tags commit 9d8da8e0a9bce4a340af60dd0446bc7eb8d07587 upstream. sctp_unpack_cookie() skips cookie expiration checks whenever an association already exists. This is broader than the exception in RFC 9260 Section 5.2.4. For an existing association, Section 5.2.4 permits an expired State Cookie only when both Verification Tags in the cookie match the current association. Otherwise, the packet SHOULD be discarded and a Stale Cookie ERROR MUST be sent. The broad check lets an expired Action A restart cookie reach sctp_sf_do_dupcook_a(). In a runtime test with the default 60 second cookie lifetime, replaying such a cookie after 65 seconds returned a COOKIE-ACK and restarted the association. Check cookie expiration unless both Verification Tags match. This preserves the Action D exception for a lost COOKIE ACK while rejecting expired cookies in all other cases. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Yuxiang Yang Acked-by: Xin Long Link: https://patch.msgid.link/20260723225623.2658868-1-yangyx22@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 49e5b25a0b74dbac595f122e5608fdce2918cc4e Author: Ibrahim Hashimov Date: Sun Jul 12 20:37:39 2026 +0200 scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write commit 93dde0bf2f39a0f9f57fd610aa3201ce5b753433 upstream. resp_report_zones() sizes the reply buffer from the CDB allocation length. The v3 fix rounds alloc_len up with ALIGN() before deriving the descriptor count: rep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD); arr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1); For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which passes the !arr check, and desc = arr + 64 is then dereferenced in the loop -> out-of-bounds write / panic. Clamp rep_max_zones to devip->nr_zones. The loop already stops at sdebug_capacity (after nr_zones zones), so a report can never hold more than nr_zones descriptors; the clamp does not change the report, it only bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device property that can never reach 0x100000000. Fixes: 7db0e0c8190a ("scsi: scsi_debug: Fix buffer size of REPORT ZONES command") Suggested-by: Damien Le Moal Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Reviewed-by: Damien Le Moal Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260712183739.83915-1-security@auditcode.ai Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 03bfd969f2f72534091457fbe57114d126a525ce Author: Chris Gellermann Date: Wed Jul 22 15:02:45 2026 +0200 selftests/clone3: fix wild pointer access of getline due to missing init commit 8f6f9fd93cd7a5dd607ad5cd910476dd68fff3ed upstream. Patch series "selftests: Add missing initalization of pointer passed to getline", v2. This patch (of 2): Clone3_set_tid uses getline(&line, ...) in a loop to read the child's process status. The code expects that getline allocates the buffer for the line on the first loop iteration. According to the Open Group Spec[1], char *line has to be null pointer for this: > ssize_t getline(char **restrict lineptr, ...); > If *lineptr is a null pointer or if the object pointed to by *lineptr > is of insufficient size, an object shall be allocated as if by malloc() > or the object shall be reallocated as if by realloc()[...]. However, char *line is only declared, leading to an undefined value that is potentially non-null. In an example run with Musl v1.2.6, the realloc call[2] of getdelim, which implements getline, triggers a segfault: ./run_kselftest.sh --test clone3:clone3_set_tid [ 1366.165898] kselftest: Running tests in clone3 ... [ 1367.799244] clone3_set_tid[811]: unhandled signal 11 code 0x1 at 0x0000000000000000 in libc.so[68184,3fbf69f000+4c000] [ 1367.802808] CPU: 0 UID: 0 PID: 811 Comm: clone3_set_tid Not tainted .. [ 1367.804188] epc: 0x0000003fbf6b0184 [ 1367.804188] ra : 0x0000003fbf6d4664 [ 1367.804188] sp : 0x0000003fce5f2e40 [ 1367.805314] gp : 0x0000002aaab0dfb8 [ 1367.805314] tp : 0x0000003fbf6f14a8 [ 1367.805314] t0 : 0x0000003fbf63d000 ... Looking at the realloc implementation, Musl mallocs for a null pointer memory. But for a non-null pointer, it assumes it's passed a valid pointer to the heap and tries to access its meta-data. This leads to the segfault we see: void *realloc(void *p, size_t n) { if (!p) return malloc(n); if (size_overflows(n)) return 0; struct meta *g = get_meta(p); ... } Fix this by properly initializing the line pointer to NULL. Link: https://lore.kernel.org/20260722130246.2135563-1-christian.gellermann@codasip.com Link: https://lore.kernel.org/20260722130246.2135563-2-christian.gellermann@codasip.com Link: https://pubs.opengroup.org/onlinepubs/9799919799/functions/getline.html [1] Link: https://git.musl-libc.org/cgit/musl/tree/src/stdio/getdelim.c#n38 [2] Fixes: 41585bbeeef9 ("selftests: add tests for clone3() with *set_tid") Signed-off-by: Chris Gellermann Acked-by: David Hildenbrand (arm) Reviewed-by: Lorenzo Stoakes Cc: Christian Brauner Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7ecb40609362c1877ba56fa2c9acc987c47ec10e Author: Chris Gellermann Date: Wed Jul 22 15:02:46 2026 +0200 selftests/mm: fix potential wild pointer access of getline due to missing init commit 9f1d75a4ce04095afdb63d8e540092ff8151dacf upstream. This is another occurrence of using getline where the code assumes that getline allocates memory to store the line, but the pointer passed to it is uninitialized and potentially a non-null pointer. This violates the Open Group Spec[1] and caused a segfault in a similar situation in selftest/clone3/clone3_set_tid. Fix it by initializing the line pointer to NULL. The issue has been found by simply grepping through the selftest code after running into the issue in clone3_set_tid. Whether it segfaults in its current state is unknown to me. But it's good to be addressed due to defensive reasons. Link: https://lore.kernel.org/20260722130246.2135563-3-christian.gellermann@codasip.com Link: https://pubs.opengroup.org/onlinepubs/9799919799/functions/getline.html [1] Fixes: 26b4224d9961 ("selftests: expanding more mlock selftest") Signed-off-by: Chris Gellermann Acked-by: David Hildenbrand (arm) Reviewed-by: Lorenzo Stoakes Cc: Christian Brauner Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit fc673c4eb23dd558e3763ba136304c2fc99d7694 Author: Vijaya Krishna Nivarthi Date: Wed Jul 22 14:53:58 2026 +0530 spi: qcom-qspi: Correct max DMA length to avoid 64K boundary failure commit 90ef2f2961c2dc55957dafe2f53b3efdb4675efc upstream. The maximum size for a DMA data descriptor is 64KB-1 because the size field in HW is 16 bits wide. For this reason, transfers fail at 64KB and beyond. Lower max_dma_len to 60KB so larger transfers are split into multiple DMA blocks and do not hit the failing 64KB boundary. 60KB is chosen as a safe round number below the 64KB-1 hardware limit while satisfying alignment requirements. Tested on x1e80100 (Hamoa) with SPI-NOR flash (/dev/mtd0): Without patch: dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=32768 count=2 # works dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=65536 count=1 # fails With patch: dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=65536 count=1 # works Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support") Cc: stable@vger.kernel.org Signed-off-by: Vijaya Krishna Nivarthi Link: https://patch.msgid.link/20260722092358.459943-1-vnivarth@qti.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 47cef9b4445d217679fd496167cd9d44e6da890f Author: Masami Hiramatsu (Google) Date: Wed Jul 29 09:28:07 2026 +0900 tracing/filters: Fix false positive match in regex_match_full() commit c22c7b735f9810ad276014f788f9aa5c879ec238 upstream. regex_match_full() calls strncmp(str, r->pattern, len) where len is the target field buffer size. When len is smaller than r->len (the filter pattern length), strncmp() checks only len bytes of r->pattern against str. If those len bytes match, strncmp() returns 0, resulting in a false-positive match where a shorter string in a fixed-size field matches a longer filter pattern. For example, a 4-byte static string field containing "abcd" matched the filter pattern "abcdefgh" because strncmp("abcd", "abcdefgh", 4) returned 0. In this case, @len does NOT include '\0' because it is fixed-size array. Fix this by returning 0 (no match) early when len < r->len. Fixes: 1889d20922d1 ("tracing/filters: Provide basic regex support") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/178528488779.124250.5571741156199253769.stgit@devnote2 Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit d61ee2a27dfd5eb43ddc18af40168f5b9eb1cea5 Author: Masami Hiramatsu (Google) Date: Wed Jul 29 09:27:58 2026 +0900 tracing: Check return value of __register_event() in trace_module_add_events() commit ac8719969e6c3c54e939834df812bc41f25453cf upstream. trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded. Fixes: ae63b31e4d0e ("tracing: Separate out trace events from global variables") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/178528487878.124250.14170824576025743236.stgit@devnote2 Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit ee41b00858ca65b4428e99efe39a4277c1f043d2 Author: Ming Lei Date: Sun Jul 26 09:50:25 2026 -0500 ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev() commit e65848e4ce352bac9e3465099354c8b8f845391f upstream. ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into ub->dev_info and then fixes up the fields the driver owns, but misses ->state and ->ublksrv_pid. A device added with ->state = UBLK_S_DEV_LIVE passes the "->state != UBLK_S_DEV_DEAD" test that ublk_stop_dev_unlocked() uses as its proxy for "a disk is attached", while ->ub_disk is still NULL, so DEL_DEV right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A poisoned ->state also gets START_USER_RECOVERY and the char device read/write path onto a device that was never started, and wedges START_DEV at -EEXIST. A poisoned ->ublksrv_pid just makes GET_DEV_INFO report an unrelated task as the ublk server. Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only ever reads these back, so correcting them silently breaks nothing. ADD_DEV has copied ->state in unsanitized since ublk was merged, but back then it was harmless: the gendisk was allocated during ADD_DEV, and both teardown and the START_DEV -EEXIST check keyed off disk_live() rather than ->state. The oops became reachable once the disk allocation moved to START_DEV and those checks switched to ->state. Fixes: 6d9e6dfdf3b2 ("ublk: defer disk allocation") Cc: stable@vger.kernel.org Signed-off-by: Ming Lei Reviewed-by: Caleb Sander Mateos Link: https://patch.msgid.link/20260726145025.1507383-1-tom.leiming@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 42887be7c4cf283cce02cd0fb6411221167c8b6c Author: Eric Dumazet Date: Thu Jul 23 14:42:48 2026 +0000 vxlan: use pskb_network_may_pull() in route_shortcircuit() commit 26bb2dd0a8839617e2c79ffbbe1923f8e4bab9fb upstream. route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer. Fixes: e4f67addf158 ("add DOVE extensions for VXLAN") Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260723144249.759100-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d08e8ac13f2e228cc7fc3c70b5ebe71557b624a0 Author: Eric Dumazet Date: Thu Jul 23 14:42:47 2026 +0000 vxlan: use neigh_ha_snapshot() in route_shortcircuit() commit 8eca411347e1d38964f9ed2c8d3b6ab0e7e4473d upstream. The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches. Fixes: e4f67addf158 ("add DOVE extensions for VXLAN") Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260723144249.759100-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cbb154b2d71ef6fb37ad93e9973504a6bc6b8060 Author: Eric Dumazet Date: Thu Jul 23 14:42:46 2026 +0000 vxlan: unclone skb head before modifying eth header in route_shortcircuit() commit 760d36e737f2b3867762f42af36c663f55babcc4 upstream. When route_shortcircuit() performs L3 short-circuit routing, it modifies the Ethernet header of the skb in-place: memcpy(eth_hdr(skb)->h_source, eth_hdr(skb)->h_dest, dev->addr_len); memcpy(eth_hdr(skb)->h_dest, n->ha, dev->addr_len); If the incoming skb is cloned (for example by packet sockets, tcpdump, or dev_queue_xmit), modifying the Ethernet header without uncloning can corrupt the packet header for other readers holding a reference to the cloned skb. Ensure the skb header is writable and unshared by calling skb_cow_head(skb, 0) prior to updating the Ethernet header. If skb_cow_head() fails, abort short-circuiting and return false to allow standard packet processing fallback. Fixes: e4f67addf158 ("add DOVE extensions for VXLAN") Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260723144249.759100-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2355c8c26d2aa1b4385b369e67202e47d460d555 Author: Eric Dumazet Date: Thu Jul 23 14:42:45 2026 +0000 vxlan: re-fetch eth header after route_shortcircuit() commit 1395a676ec15a0a02a2a6d86602324f2d5fd41d5 upstream. Before route_shortcircuit(), the eth header pointer is cached from eth_hdr(skb). Inside route_shortcircuit(), pskb_may_pull() can be called, which may reallocate skb->head. In this case, returning to vxlan_xmit() leaves the cached eth pointer pointing to freed memory, leading to a use-after-free when dereferencing eth->h_dest. Fix this by updating eth = eth_hdr(skb) after calling route_shortcircuit(). Fixes: ae8840825605 ("VXLAN: Allow L2 redirection with L3 switching") Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260723144249.759100-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4b9601595e8b6b5d18878cac0aeabc687d241111 Author: Michael Bommarito Date: Mon Jun 22 08:47:22 2026 -0400 um: vector: fix use-after-free in vector_mmsg_rx() commit af421e9aed3920c7ac88c24daa48606c7112feca upstream. When vector_mmsg_rx() discards a packet whose overlay header fails verify_header(), it frees the skb and continues the loop: if (header_check < 0) { dev_kfree_skb_irq(skb); vp->estats.rx_encaps_errors++; continue; } The normal and short-packet paths fall through to the bottom of the loop body, which clears the consumed slot and advances the cursors: (*skbuff_vector) = NULL; mmsg_vector++; skbuff_vector++; The verify_header() < 0 path skips that via continue, so the freed skb is left in skbuff_vector[] and the cursors do not advance. The next iteration reads the same slot, gets the freed skb, and frees it again, producing a refcount underflow / use-after-free in the RX path. Discard the slot the same way the other paths do before continuing. Only transports whose verify_header() can return negative are affected: GRE and L2TPv3 do so on a cookie/session-id mismatch (raw/tap do not), so any peer on such a transport can trigger it without authentication. Fixes: 49da7e64f33e ("High Performance UML Vector Network Driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit f020d756b3139627a986b220c0cf050a4bb2de22 Author: Thorsten Blum Date: Sat Jul 11 15:09:32 2026 +0200 powerpc/ps3: Fix map failure path in dma_ioc0_map_pages() commit 0bb024f11d120abff3e8db9144a585b9d7fb8459 upstream. If lv1_put_iopte() fails in dma_ioc0_map_pages(), the error path decrements iopage but keeps using the failed mapping's offset. As a result, it repeatedly tries to invalidate the failed IOPTE slot and leaves the already installed IOPTEs valid. Recompute offset and invalidate the installed IOPTEs instead. Fixes: 6bb5cf102541 ("[POWERPC] PS3: System-bus rework") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Geert Uytterhoeven Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260711130931.740719-3-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman commit 6d98c70fe0ba8c7708bfd5b2a5174d2086775daa Author: Zhiling Zou Date: Fri Jul 24 00:48:52 2026 +0800 net: ipv6: clear suppressed fib6 rule result commit 6aea62e433fe1b586202a5fee8b5807ce635e1d7 upstream. fib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(), but leaves res->rt6 pointing at the released rt6_info. If no later rule supplies a replacement, fib6_rule_lookup() still sees res.rt6 and returns that stale dst to its caller. A suppressing rule can therefore leak a released route back to rt6_lookup(), and the next put hits rcuref_put_slowpath() from dst_release(). Clear res->rt6 when suppressing the route so suppressed lookups fall through to the null dst instead of reusing the released one. Fixes: cdef485217d3 ("ipv6: fix memory leak in fib6_rule_suppress") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/4b8acb7787d54e440155585dd32ebdf0bef7d122.1784710966.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 159ad90cb929c033308bb39a2c5f8fbf393b77aa Author: Zhiling Zou Date: Fri Jul 24 00:52:48 2026 +0800 net: bridge: stop fast-leave after deleting a port group commit a39789f211b8a4125f0c70e05b30cf715f4f187d upstream. br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry. Fixes: 6db6f0eae605 ("bridge: multicast to unicast") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/1cf0898872ef7c72d5f4c0304414a192c6dac591.1784707712.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f978048326570047e8216e81a67f9c71ef2bb1b1 Author: Link Lin Date: Tue Jul 21 00:55:33 2026 +0000 mm/page_reporting: use system_freezable_wq to fix UAF during suspend commit 0b45f6927a14914ff685fe0e6f9d11232a1e03df upstream. During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible. Link: https://lore.kernel.org/20260721005603.1710551-1-linkl@google.com Fixes: 36e66c554b5c ("mm: introduce Reported pages") Signed-off-by: Link Lin Suggested-by: David Hildenbrand (Arm) Suggested-by: Michael S. Tsirkin Acked-by: David Rientjes Acked-by: David Hildenbrand (Arm) Acked-by: Michael S. Tsirkin Cc: Alexander Duyck Cc: Greg Thelen Cc: James Houghton Cc: Jason Wang Cc: Jiaqi Yan Cc: Vlastimil Babka Cc: Xuan Zhuo Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 1819f82dee766c58295ecaacdac02cdf6837d7a4 Author: Christian Brauner Date: Fri Jul 10 11:33:04 2026 +0200 binfmt_misc: reject a flag character as the field delimiter commit 8e85d50ba1117fd446bf9a250bd8a97d48384bdc upstream. The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: memset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering PaPEPPxPPiP with 'P' as the delimiter (name "a", type extension, magic "x", interpreter "i", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-3-a162f7cb58d6@kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 25e5a3fe4f15e30f74eca42cbf3bcc3a3fbeda79 Author: Zhao Li Date: Tue Jul 28 19:53:25 2026 +0800 wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames commit 99a948382af8a225e2d5e54a7052158cd6281cc6 upstream. mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each subframe it passes the subframe data pointer to mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the length of the A-MSDU parent, instead of rx_skb->len: rx_skb = __skb_dequeue(&list); rx_hdr = (struct rx_packet_hdr *)rx_skb->data; if (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) && ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) { mwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr, skb->len); } The parent is not a valid description of that buffer, and may not be valid memory at all. ieee80211_amsdu_to_8023s() ends with if (!reuse_skb) dev_kfree_skb(skb); and it only sets reuse_skb when the parent is linear, is not a head_frag, and is being consumed as the *last* subframe. So when the parent does not qualify for reuse it has already been freed, and the read of skb->len is a use-after-free. When it is reused, skb->len is the length of the last subframe, applied to every earlier subframe, which over-states the buffer whenever an earlier subframe is shorter. The callee cannot absorb a wrong length, because it derives its own ceiling from the value it is given. Each frame type computes ies_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN; and the element walk is then bounded entirely against that ceiling, for (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) { u8 ie_len = pos[1]; if (pos + 2 + ie_len > end) break; so a too-large len moves end past the end of the subframe and the walk reads and copies beyond it. The A-MSDU layout is chosen by the sender, which makes the difference between the last subframe and a shorter earlier one remotely selectable. Reaching this requires TDLS support in firmware and the TDLS ethertype on the subframe. The other caller, mwifiex_process_rx_packet(), is correct: it passes a pointer and a length that describe the same region of the RX buffer. Pass rx_skb->len, the length of the subframe actually being parsed. Fixes: 776f742040ca ("mwifiex: fix AMPDU not setup on TDLS link problem") Assisted-by: Codex:gpt-5.6-sol Assisted-by: Kimi:K3 Cc: stable@vger.kernel.org Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260728115325.19128-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d7940bb6a8e7ab28f972c2875cb05783216312dc Author: Zihan Xi Date: Fri Jul 24 00:38:41 2026 +0800 tipc: avoid use-after-free in poll trace queue dumps commit b4f1719dfea023220e0e6bd892b087d76b2a6a49 upstream. TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context. Fixes: b4b9771bcbbd ("tipc: enable tracepoints in tipc") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zihan Xi Signed-off-by: Ren Wei Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/f8119abd5e5ecc400597de667ae9d39656de56d0.1784794294.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 661ff9c0cfbe07f8eed920dde9f7781491738207 Author: David Lee Date: Mon Jul 13 09:59:15 2026 +0000 netfilter: ipset: do not update comments from kernel-side hash adds commit f30415929be8aeb002d557c8d3f7ab2d2188003a upstream. mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer. If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer. Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy. Fixes: f66ee0410b1c ("netfilter: ipset: Fix "INFO: rcu detected stall in hash_xxx" reports") Cc: stable@vger.kernel.org Signed-off-by: David Lee Assisted-by: Codex:gpt-5.5 Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 5a42f162b857019a4c10ff687dc3bcdf51831865 Author: Xuanqiang Luo Date: Thu Jul 23 18:54:54 2026 +0800 net/smc: fix socket use-after-free during link group termination commit f621d6ebeebb6374342571e4ddf45fdbc420f6cd upstream. __smc_lgr_terminate() drops conns_lock after finding a connection in lgr->conns_all, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree. A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sock_hold(). The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported: BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] The socket was allocated by smc_create(), freed through slab_free_after_rcu_debug(), and was followed by: refcount_t: addition on 0; use-after-free. __smc_lgr_terminate.part.0 [smc] Take the socket reference while conns_lock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket. Fixes: 69318b5215f2 ("net/smc: improve abnormal termination locking") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Reviewed-by: Mahanta Jambigi Link: https://patch.msgid.link/20260723105454.87016-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 44af98cc7d5ef8e730488d5df1eecd5deeaa5947 Author: Zhiling Zou Date: Mon Jul 13 19:52:32 2026 +0800 ipvs: do not propagate one-packet flag to synced conns commit a63d2dbaeb50a85d4c976b15a36e6b0c7113db5b upstream. Synced connections can be created before their destination exists. When the destination is later added, ip_vs_bind_dest() copies connection flags from the destination into cp->flags. IP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced connection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conn_tab node, leaving stale hash nodes pointing at a freed struct ip_vs_conn. Drop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced connections. Fixes: 26ec037f9841 ("IPVS: one-packet scheduling") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Suggested-by: Julian Anastasov Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 31089f4eab42e0fc248ec80c26f9b0bad59ba4cc Author: Matt Vollrath Date: Thu Apr 16 23:34:52 2026 -0400 igbvf: Fix leak in TX DMA error cleanup commit 0565052b7e2f436b7f1541f4849da96dc0aa7a0e upstream. If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed. Fixes: c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-4-7-opus Signed-off-by: Matt Vollrath Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 5c477b7a205fb1cf1e09cd427e053d3dbad22e26 Author: Dawei Feng Date: Sun Jun 7 22:57:06 2026 +0800 e1000: fix memory leak in e1000_probe() commit 816419dfea5c88126f35eb7a1b429a1bf546665e upstream. In the e1000_probe() path, e1000_sw_init() allocates adapter->tx_ring and adapter->rx_ring. If the subsequent CE4100-specific MDIO BAR mapping fails, the error handling jumps past the ring cleanup code, leaking both allocations. Fix this leak by moving the err_mdio_ioremap label above the ring deallocation logic. This guarantees the proper release of these resources and prevents the memory leak. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc6. An x86_64 allyesconfig build showed no new warnings. As we do not have a CE4100 reference platform to test with, no runtime testing was able to be performed. Fixes: 5377a4160bb65 ("e1000: Add support for the CE4100 reference platform") Cc: stable@vger.kernel.org Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Reviewed-by: Dima Ruinskiy Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit dc390138a0a319e2b020e807834840b6019af8ca Author: Md Sadre Alam Date: Mon Jun 15 11:39:08 2026 +0530 dmaengine: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+ commit 867621ba203027338b525af6729719c544135336 upstream. BAM version 1.6.0 and later changed the behavior of the mask field in command elements for read operations. In older BAM versions, or prior implementation assumptions, the mask field was effectively ignored for read commands. However, starting from BAM v1.6.0, the mask field for read commands is repurposed to carry the upper 4 bits of the destination address, enabling support for 36-bit addressing. For write commands, the mask field continues to function as a traditional write mask. The current driver sets mask = 0xffffffff for all command elements. While this works for write operations, it breaks read operations on BAM v1.6.0+ hardware. In such cases, the hardware interprets the upper address bits as 0xf, resulting in an invalid destination address (0xf_xxxxxxxx instead of 0x0_xxxxxxxx). This leads to failures such as NAND enumeration issues observed on platforms like IPQ5424. Fix this by assigning the mask field based on command type: - For read commands: set mask = 0 (upper address bits = 0) - For write commands: retain mask = 0xffffffff Also update the bam_cmd_element structure documentation to reflect the dual purpose of the mask field across BAM versions. This ensures correct behavior on BAM v1.6.0+ while maintaining backward compatibility with older hardware. Fixes: dfebb055f73a2 ("dmaengine: qcom: bam_dma: wrapper functions for command descriptor") Tested-by: Lakshmi Sowjanya D Signed-off-by: Md Sadre Alam Reviewed-by: Frank Li Reviewed-by: Dmitry Baryshkov Cc: stable@vger.kernel.org Signed-off-by: Varadarajan Narayanan Link: https://patch.msgid.link/20260615060908.1263171-1-varadarajan.narayanan@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 56ac3e7c90f6b45969c3fd07a98fad760ffd6901 Author: Sonali Pradhan Date: Tue Jul 28 20:24:32 2026 +0000 ALSA: usb-audio: Clamp frame size in implicit-feedback mode commit 8d7a30c50c2e58a6839634ed0acde14466d1dc61 upstream. snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue. Fixes: 28acb12014fb ("ALSA: usb-audio: use sender stride for implicit feedback") Cc: stable@vger.kernel.org Assisted-by: Jetski:Gemini-3.6-Flash Signed-off-by: Sonali Pradhan Link: https://patch.msgid.link/20260728202432.2354994-1-sonalipradhan@google.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3852974608f53e530e27c21d0c6c7d79c17b3f5a Author: Sonali Pradhan Date: Tue Jul 28 20:17:16 2026 +0000 ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set commit d0199ae1666ff9ae2d1d568d64c3430d4c47f0e5 upstream. When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value. Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory. Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size. [ changed to reassign maxsize only when ep->fill_max is set -- tiwai ] Fixes: 8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model") Cc: stable@vger.kernel.org Assisted-by: Jetski:Gemini-3.6-Flash Signed-off-by: Sonali Pradhan Link: https://patch.msgid.link/20260728201716.2347726-1-sonalipradhan@google.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 29a4c29943631301e85f5e9d10f25741bd78e7ba Author: Baul Lee Date: Sun Jul 26 16:45:00 2026 +0900 ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output() commit 0970274613fb463d376211450cab066d34ebfe6a upstream. snd_usbmidi_akai_output() computes its fill-loop bound buf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1; as a signed int, so a small device-advertised bulk-OUT max_transfer makes buf_end negative. The loop guard then compares the u32 urb->transfer_buffer_length against that negative int: the usual arithmetic conversion turns buf_end into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only max_transfer bytes long. A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiC*D* node. Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running. Discovered by XBOW, triaged by Baul Lee Fixes: 4434ade8c933 ("ALSA: usb-audio: add support for Akai MPD16") Suggested-by: Takashi Iwai Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260726074500.50145-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 49eccef6d6e1c00dac6fb2e7eb6f9206c33e1c37 Author: Baul Lee Date: Sun Jul 26 14:13:37 2026 +0900 ALSA: usb-audio: fix use-after-free in ump_to_endpoint() commit 4a05b2d1b4642df74f30b6f54843e825c4a2bfd3 upstream. create_midi2_ump() registers a card-owned snd_ump_endpoint and stores a back-pointer to its per-interface snd_usb_midi2_ump object in ump->private_data, but it never installs an ump->private_free hook and never clears that pointer. If a later step of snd_usb_midi_v2_create() fails, its error path calls free_all_midi2_umps(), which kfree()s the snd_usb_midi2_ump object while the already-registered endpoint keeps pointing at it. The created /dev/snd/umpC*D* node stays exposed, so the first operation of any UMP open, ump_to_endpoint(), dereferences the dangling ump->private_data and reads rmidi->eps[dir] out of freed memory. A malicious USB MIDI 2.0 device that makes creation fail after the endpoint is registered can thus trigger a slab use-after-free read on a subsequent open of the UMP node. Clear the endpoint's back-pointer before freeing the object, and let ump_to_endpoint() tolerate a NULL private_data so the open/close/trigger callbacks fail cleanly (their callers already handle a NULL endpoint) instead of dereferencing a stale pointer. Discovered by XBOW, triaged by Baul Lee Fixes: ff49d1df79ae ("ALSA: usb-audio: USB MIDI 2.0 UMP support") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260726051337.41124-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3d3339f71807b0d7b7ab8d1469e1388a6ddc1431 Author: Matt Vollrath Date: Fri Jul 24 03:39:42 2026 -0400 ata: libata-eh: Increase STANDBY IMMEDIATE timeout commit 1e024d2b41ee32bc06818f7f09a3562c58842cf9 upstream. Correct a previous change (see Fixes) which reduced the standby timeout from 30 to 5 seconds. Increase it to 15 seconds. I was troubleshooting an error spotted during system suspend: [ 1217.152867] ata1.00: Entering standby power mode [ 1222.322948] ata1.00: qc timeout after 5000 msecs (cmd 0xe0) [ 1222.324010] ata1.00: STANDBY IMMEDIATE failed (err_mask=0x4) This drive is a Samsung 870 EVO SSD in good SMART standing, and I wasn't aware of any reason it should be taking so long to standby. The issue is intermittent, but I observed it sometimes taking 7 seconds to manually standby. I assume this was interruption of background maintenance after a power outage. As a desktop user, I would prefer to wait the extra 2 seconds at suspend to let the drive finish its business rather than drop the rails from under it. The change from 30 to 5 seconds was implicit when switching suspend from START STOP UNIT to an internal command with no timeout table entry. No reason was stated for the change. Fixes: aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop") Cc: stable@vger.kernel.org Signed-off-by: Matt Vollrath Assisted-by: Claude:claude-5-fable Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 2f840c7980bcfb7baa3d3eae07c6261d35187e20 Author: Haidar Lee Date: Wed Jul 15 14:04:41 2026 +0800 ASoC: tas2562: fix broken entries in the volume lookup table commit bdb0fd6de403fcea7b85dc9d38f0a571583ebe80 upstream. The float_vol_db_lookup table is supposed to hold round(10^(dB/20) * 2^30) for every 2 dB step from -110 dB to 0 dB, which is 56 entries, but it only has 55: the -90 dB entry duplicates the -92 dB value (0x0000695b) and the -20 dB entry (0x06666666) is missing altogether. As a result every step between -90 dB and -22 dB is off by 2 dB, and the control's maximum raw value of 110 indexes one element past the end of the array. Replace the duplicated -90 dB entry with the correct value 0x000084a3 and add the missing -20 dB entry, bringing the table to the full 56 entries so index 55 (raw value 110, 0 dB) is in range again. Fixes: bf726b1c86f2 ("ASoC: tas2562: Add support for digital volume control") Cc: stable@vger.kernel.org Signed-off-by: Haidar Lee Link: https://patch.msgid.link/20260715-tas2562-dvc-fix-v1-2-072b13901b20@adlinktech.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f56d1aac72394a4238f81ce762de6b859c6ebb16 Author: Haidar Lee Date: Wed Jul 15 14:04:40 2026 +0800 ASoC: tas2562: fix DVC coefficient write order commit 8e957e4907c58e9ca944f98799524f2bbb9cf68a upstream. The TAS2562 applies the 32-bit digital volume coefficient to the playback path when the last byte, DVC_CFG4 (book 0 page 2 reg 0x0F), is written. tas2562_volume_control_put() wrote DVC_CFG4 first and DVC_CFG1 (the MSB) last, so every volume change latched a value made of the previous coefficient's upper three bytes combined with the new LSB; the remaining bytes only took effect on the next volume change. In practice the control was unusable: the first setting after power-on always played at roughly 0 dB no matter what value was requested (the chip's default upper bytes were still latched), and most subsequent changes muted the output entirely or produced a distorted, over-unity gain. Verified on a TAS2562 (ADLINK OSM-520 / MT8189 board) by tracing the I2C writes with ftrace and by writing the same coefficients manually in both byte orders: written MSB-first the register block behaves exactly as the driver expects, LSB-first reproduces the broken behaviour. Write the bytes MSB first with DVC_CFG4 last so the complete new coefficient is latched atomically. Fixes: bf726b1c86f2 ("ASoC: tas2562: Add support for digital volume control") Cc: stable@vger.kernel.org Signed-off-by: Haidar Lee Link: https://patch.msgid.link/20260715-tas2562-dvc-fix-v1-1-072b13901b20@adlinktech.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e84d2e53a05c78a04d1343eeb0f31a79456e79fc Author: Baul Lee Date: Sun Jul 26 14:16:33 2026 +0900 ALSA: ump: fix double free of out_cvts on rawmidi error commit 70c977815af0d997feb2d0c5d284d55689bf7051 upstream. snd_ump_attach_legacy_rawmidi() allocates the legacy conversion array ump->out_cvts and, on the snd_rawmidi_new() error path, frees it with kfree() but leaves ump->out_cvts pointing at the freed memory. When the endpoint is later torn down, snd_ump_endpoint_free() frees ump->out_cvts a second time, resulting in a double free. The host snd-usb-audio driver attaches the legacy rawmidi for any USB MIDI 2.0 (UMP) device, so a device that makes snd_rawmidi_new() fail reaches this path on enumeration. Clear ump->out_cvts after freeing it on the error path so it is not freed again during teardown. Discovered by XBOW, triaged by Baul Lee Fixes: 33cd7630782d ("ALSA: ump: Export MIDI1 / UMP conversion helpers") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260726051633.41206-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e8b784a3f4fba3ea9c4d05138ecfa784a069627f Author: Norbert Szetei Date: Tue Jul 28 14:50:01 2026 +0200 ALSA: pcm: wake linked drain waiters on unlink commit f495b6c4c8594122918552c9be2b51eb71647cd9 upstream. snd_pcm_drain() on a linked stream parks an on-stack wait entry on the drained peer's runtime->sleep, and after schedule_timeout() removes it only if that peer is still found in the caller's group. If group membership changes during the wait and the sleep ends by signal or timeout (so autoremove_wake_function() does not run), finish_wait() is skipped and snd_pcm_drain() returns with the entry still queued on that stream's sleep list; a later wake_up() then walks a freed stack frame. This is reachable by unlinking either the drained or the draining stream. Unlike the close path (snd_pcm_drop() -> snd_pcm_post_stop()), snd_pcm_unlink() never wakes the sleep queues. Wake every group member under the group lock before the membership change, so a linked drainer is released and drops its entry while the streams are still grouped. The window was opened when snd_pcm_link_rwsem stopped being held across the wait and the removal became conditional on group membership (see Fixes). The later switch to finish_wait() kept that conditional removal, so the signal/timeout case remained. Fixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/A0705100-D10B-4286-9980-0142ABEEAD51@doyensec.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 20aad5c443848a62895035fc7d9cdb95f78de1ae Author: Xu Rao Date: Thu Jul 23 16:57:10 2026 +0800 ALSA: lx6464es: fix period byte count for 16-bit streams commit 6437033bffe8bd2af174d139af552d90d40c7ac6 upstream. The lx6464es driver advertises both 16-bit and packed 24-bit PCM formats, but lx_trigger_start() and lx_interrupt_request_new_buffer() calculate the DMA period size as runtime->period_size * runtime->channels * 3. That is only correct for the packed 24-bit formats. For 16-bit streams the driver submits buffers that are 50% larger than the actual ALSA period and advances the DMA address by the same wrong amount. For example, with 2 channels, 256 frames and 4 periods, the third buffer already extends beyond the ALSA buffer and the fourth buffer starts outside it. Use snd_pcm_lib_period_bytes() so the byte count matches the runtime format, channel count and period size. Fixes: 02bec4904508 ("ALSA: lx6464es - driver for the digigram lx6464es interface") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Link: https://patch.msgid.link/8BB12E8D92A7CDBA+20260723085710.2567463-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 49bc7741cd2761c703a292dc69245041ae8a67bd Author: Takashi Iwai Date: Sun Jul 26 09:48:19 2026 +0200 ALSA: 6fire: Fix UAF at error handling during probe commit a54bf16965f896415c3337bc4fbb40fb11941d99 upstream. Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path. Reported-and-tested-by: Shuangpeng Bai Closes: https://lore.kernel.org/20260724030900.1984491-1-shuangpeng.kernel@gmail.com Cc: Link: https://patch.msgid.link/20260726074821.2288158-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 487e437b8f0922badbe239140e22858538869e40 Author: Xuanqiang Luo Date: Thu Jul 23 14:04:45 2026 +0800 bpf: lwt: Fix dst reference leak on reroute failure commit 88c17de85ddb459c3fe1e3c65d61fa366b1cf0a8 upstream. bpf_lwt_xmit_reroute() obtains a referenced dst from the route lookup. When skb_cow_head() fails before that dst is installed on the skb, the error path only frees the skb. The skb still owns its previous dst, so the newly looked up dst reference is leaked. Release the new dst reference before freeing the skb on this error path. Fixes: 3bd0b15281af ("bpf: add handling of BPF_LWT_REROUTE to lwt_bpf.c") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260723060445.21926-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit b7ad105d46acd828e424454815e4cd31069e047a Author: Sangho Lee Date: Thu Jul 23 12:28:07 2026 +0900 Bluetooth: HIDP: validate numbered report payloads commit 34f53d27b81a16a02828c8fdfa4e02badc326f17 upstream. When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload. Fixes: 0ff1731a1ae5 ("HID: bt: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE") Cc: stable@vger.kernel.org Signed-off-by: Sangho Lee Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 46ca5ab39737d7c6f9ca77ecf714cdcfa6caaeec Author: Sangho Lee Date: Thu Jul 23 12:28:06 2026 +0900 Bluetooth: HIDP: reject frames without a transaction header commit 47778d2c2087b5d192398f6fddf692d16a5431cf upstream. hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Sangho Lee Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 86ed4dd6548ccf277bc691bc912ca06e76b9d80c Author: Zihan Xi Date: Tue Jul 21 22:36:07 2026 +0800 Bluetooth: mgmt: fix UAF in pair command cancellation commit d0a7b48ad0921bd88effaee10bf970ab1d5d0ddd upstream. The pairing completion and authentication failure callbacks look up the pending MGMT_OP_PAIR_DEVICE command by walking hdev->mgmt_pending. The lookup returned a command that was still linked on the shared pending list, without keeping mgmt_pending_lock held for the later dereference and removal. A concurrent MGMT_OP_CANCEL_PAIR_DEVICE request can remove and free the same pending command before the callback uses it. The reverse race is also possible when cancel_pair_device() gets a command from pending_find() and a callback removes it before the cancel path dereferences it. This can lead to a use-after-free and a second list_del(). Make the pairing lookup helpers transfer ownership of the pending command by removing it from hdev->mgmt_pending while holding mgmt_pending_lock. The callbacks and cancel path then complete the command and free it directly, so racing paths cannot find or free the same command again. Take a temporary hci_conn reference in cancel_pair_device() because the command completion drops the reference stored in the pending command. Fixes: e9a416b5ce0c ("Bluetooth: Add mgmt_pair_device command") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi Reviewed-by: Ren Wei Reported-by: Vega Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit a9e7c2609b0cb3fb4b4ba9f66dd8727d33205967 Author: Zihan Xi Date: Fri Jul 24 00:43:46 2026 +0800 Bluetooth: mgmt: fix pending command UAF in EIR updates commit 8f2f62855a41d1730fb9e8122912bd2c8d6bed5d upstream. MGMT_OP_SET_LOCAL_NAME is handled asynchronously on powered controllers and can run set_name_sync(). When the controller is BR/EDR capable, set_name_sync() updates the local name and then rebuilds EIR data through eir_create(). The EIR builder walks hdev->uuids, but the UUID list can be changed and entries can be freed by MGMT_OP_ADD_UUID and MGMT_OP_REMOVE_UUID. pending_eir_or_class() is meant to serialize management commands that can change EIR or the class of device, but it did not include MGMT_OP_SET_LOCAL_NAME. In addition, it walked hdev->mgmt_pending without hdev->mgmt_pending_lock even though pending commands are added and removed under that mutex. A racing command completion can therefore remove and free a pending command while pending_eir_or_class() is still inspecting it, leading to a use-after-free in the pending-command list or allowing a local name update to rebuild EIR while UUID entries are being removed. Take hdev->mgmt_pending_lock while scanning hdev->mgmt_pending and treat MGMT_OP_SET_LOCAL_NAME as an EIR/class-affecting pending command on the powered asynchronous path. Check for a conflicting pending command before copying the new short name so a rejected SET_LOCAL_NAME request does not modify hdev->short_name. Fixes: 6fe26f694c82 ("Bluetooth: MGMT: Protect mgmt_pending list with its own lock") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi Signed-off-by: Ren Wei Reported-by: Vega Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c348057dc706648b03567a64ee1b6d4ec71f3efe Author: Greg Kroah-Hartman Date: Mon Jul 27 17:57:32 2026 +0200 Bluetooth: btmtk: Fix short read errors in btmtk_usb_uhw_reg_read() commit b186c18c4843dd58adc29443369bddc71cb626a3 upstream. If btmtk_usb_uhw_reg_read() gets a "short" read from a device, it will accidentally treat that as a "real" read and populate the returned value with some unknown and probably totally invalid data. Fix this logic error up by calling usb_control_msg_recv() which guarantees a "full" read happens, and then simplify the error checking for when btmtk_usb_uhw_reg_read() is called. Note, one caller of btmtk_usb_uhw_reg_read() does not check the return value, but as we pre-initialize the return value as 0, an incorrect read will not do anything wrong. Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 45bf3df5b32e5a49953e7ceabc55f7dd85380e46 Author: Luxiao Xu Date: Tue Jul 21 23:37:41 2026 +0800 audit: fix potential use-after-free in audit_del_rule() commit 246df90b5f1a8a6e6abbd2f058b029558720adec upstream. `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. Fix this by unlinking the rule from the RCU-visible lists and invoking `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other rule removal helpers). This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed. Cc: stable@vger.kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 17099fad5ef925ae78e787598b80d14270e3358b Author: Zhan Xusheng Date: Sat Jul 18 13:09:22 2026 +0800 audit: fix potential integer overflow in audit_log_n_string() commit f865c143629d4094866a811dba5f329250bad486 upstream. audit_log_n_string() computes new_len as "slen + 3" (enclosing quotes plus the NUL terminator) and stores it into an int, while slen is a size_t. For a sufficiently large slen the addition can overflow and/or the result be truncated when assigned to the int new_len, so the "new_len > avail" check can be bypassed and the subsequent memcpy(ptr, string, slen) can write past the skb tail. This is the same class of bug that was fixed for the hex sibling in commit 65dfde57d1e2 ("audit: fix potential integer overflow in audit_log_n_hex()"); both helpers are reached through audit_log_n_untrustedstring() with the same length source. Make new_len a size_t and use check_add_overflow() to catch the overflow, mirroring the audit_log_n_hex() fix. No functional change for the in-tree callers, which all pass bounded lengths. Cc: stable@vger.kernel.org Fixes: 168b7173959f ("AUDIT: Clean up logging of untrusted strings") Signed-off-by: Zhan Xusheng Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 93942b5772e0eee4147d4799cc1b936ae12fa615 Author: Charles Vosburgh Date: Mon Jul 27 19:17:30 2026 -0400 sctp: validate Adaptation Indication parameter length commit 74b21f52c5c5a71a05c0ff70e513f4f04ff28b17 upstream. The Adaptation Layer Indication parameter contains a fixed 32-bit Adaptation Code Point after its parameter header. However, sctp_verify_param() accepts a header-only parameter because the generic parameter walker only requires the header to be present. sctp_process_param() then reads adaptation_ind beyond the declared parameter. When the malformed parameter is last in an INIT, the read starts at the receive skb tail, and the value is copied into the state cookie returned in the INIT ACK. This may disclose four receive-buffer tail bytes. Require the declared parameter length to match the fixed structure size and abort the association through the existing invalid parameter length path otherwise. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Charles Vosburgh Acked-by: Xin Long Link: https://patch.msgid.link/20260727-sctp-adaptation-length-v1-1-0ab58b2810a5@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f00ef8efd41440129ccd88f4a1ebebf8d61d297f Author: Farhan Ali Date: Thu Jul 23 15:14:09 2026 -0700 KVM: s390: pci: Validate AIBV and AISB before pinning guest pages commit 868d32ac72cba21c5c6d8a66a814b7c25a3a5c01 upstream. The AIBV holds one bit per MSI-X vector for a given function. The size of the bit vector is derived from the NOI and the AIBVO. If the size of the AIBV exceeds a single page boundary, then reject the request as we cannot safely pin the guest AIBV. Similarly reject the request if the AISB address is not 8-byte aligned as the architecture requires doubleword alignment for the summary bit address. Since the AISBO can address up to 64 bits, the size of the AISB can only be 8 bytes for the function. This also ensures the AISB doesn't exceed a single page boundary. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Signed-off-by: Farhan Ali Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 0a95abe964400771ad82b027d7b84a0d183cd0db Author: Farhan Ali Date: Thu Jul 23 15:14:07 2026 -0700 KVM: s390: pci: Fix NULL dereference on AIBV allocation failure commit 8bf09b9b7d3232806df95f409581f8a9fd99a3fa upstream. The airq_iv_create() can return NULL on failure, but the return value was never checked. If it fails, zdev->aibv will be NULL and fail when dereferenced in kvm_zpci_set_airq(). Add a NULL check and free the previously allocated AISB bit and zdev->aisb on failure. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Signed-off-by: Farhan Ali Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 78d9648e7e960546d5b72504a0b0358cd8bb1e9d Author: Farhan Ali Date: Thu Jul 23 15:14:04 2026 -0700 KVM: s390: pci: Reject adapter interrupt forwarding if already enabled commit 8fa01be5a6149404adb82c0979a78f6347edd3ef upstream. The MPCIFC instruction doesn't allow registering adapter interrupts without first unregistering. So reject any request to enable interrupt forwarding if its already enabled for the zPCI device. This also fixes overwriting and thus leaking resources when the ioctl is called multiple times for the same device. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Signed-off-by: Farhan Ali Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 6664a5aea45318f4ec156a729949b474dd6e3159 Author: Sean Christopherson Date: Fri Jul 10 09:20:51 2026 -0700 KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is active commit 7d3aae206663c4e006b25a1c7a20a4029e67da76 upstream. Always update x2APIC MSR intercepts for L1 when AVIC is deactivated, even if L2 is active and KVM is using a separate MSR bitmap to run L2. If AVIC is fully enabled prior to running L2, and is then inhibited while L2 is active (for a VM-scoped inhibit), then KVM will run L1 with AVIC disabled, but with x2APIC MSR intercepts disabled, i.e. will allow L1 to read most of the host's APIC state, send arbitrary interrupts, change task priority, and ultimately trivially DoS the host. E.g. sending a self-IPI in L1 on HYPERV_REENLIGHTENMENT_VECTOR, 0xee, with CONFIG_HYPERV=n in the host kernel as a "safe" PoC, yields: Spurious interrupt (vector 0xee) on CPU#425. Acked And hacking KVM to abuse kvm_set_posted_intr_wakeup_handler() to register a handler and WARN on POSTED_INTR_WAKEUP_VECTOR yields: ------------[ cut here ]------------ WARNING: arch/x86/kvm/svm/svm.c:5594 at pi_wakeup_handler+0x9/0x10 [kvm_amd], CPU#156: nested_x2apic_t/316940 CPU: 156 UID: 0 PID: 316940 Comm: nested_x2apic_t Tainted: G S U Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20260209.0-0 02/09/2026 RIP: 0010:pi_wakeup_handler+0x9/0x10 [kvm_amd] Call Trace: sysvec_kvm_posted_intr_wakeup_ipi+0x64/0x80 asm_sysvec_kvm_posted_intr_wakeup_ipi+0x1a/0x20 RIP: 0010:vcpu_run+0x1430/0x1e40 [kvm] kvm_arch_vcpu_ioctl_run+0x2c1/0x600 [kvm] kvm_vcpu_ioctl+0x580/0x6b0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46ff4b ---[ end trace 0000000000000000 ]--- Fixes: 091abbf578f9 ("KVM: x86: nSVM: optimize svm_set_x2apic_msr_interception") Cc: stable@vger.kernel.org Cc: Yosry Ahmed Signed-off-by: Sean Christopherson Link: https://patch.msgid.link/20260729213558.639074-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 451ee0f9ca1e1205500b51b036ce82b543efdc2a Author: Raushan Patel Date: Fri Jul 24 11:14:35 2026 +0530 tracing/probes: Reject $arg0 in meta argument expansion commit 00a8ce2a2a9fa17674e1feec4d9105c1a5d6a419 upstream. traceprobe_expand_meta_args() parses $argN with simple_strtoul() and calls sprint_nth_btf_arg(n - 1, ...). For $arg0, n is 0 so the index is -1. Because ctx->nr_params is signed, the "idx >= nr_params" guard in sprint_nth_btf_arg() does not catch the negative index, and ctx->params[-1].name_off is read out of bounds. The normal per-argument path (parse_probe_vars()) already rejects $arg0 via its argument-number check, but meta-argument expansion runs before per-argument parsing and substitutes the value first, bypassing that check. Reject $arg0 explicitly during expansion. Link: https://lore.kernel.org/all/20260724054435.146279-1-raushan.jhon@gmail.com/ Fixes: 18b1e870a496 ("tracing/probes: Add $arg* meta argument for all function args") Cc: stable@vger.kernel.org Signed-off-by: Raushan Patel Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 421e447b53c70f3a897a5d9da775eda1da84fb22 Author: Gregory Price Date: Sat Jun 27 16:22:43 2026 -0400 mm/vmstat: fold stranded per-cpu node stats when a node comes online commit ea3034b2b00fa50c8d2518d0804c9d427bbafa86 upstream. A per-node vmstat counter is pgdat->vm_stat[] plus per-cpu deltas. A balanced counter can sit split as global=+N / per-cpu=-N. The folds reconciling the split only walk online nodes, so when try_offline_node() marks a node offline the per-cpu deltas are stranded. A subsequent online resets the per-cpu area but not pgdat->vm_stat[], orphaning the +N permanently. All NR_VM_NODE_STAT_ITEMS are affected. The existing code zeroes the per-cpu counters and causes a permanent skew. Fold the stranded deltas instead, before the node rejoins the online set. The node is not online yet and the hotplug lock is held, so the remote access to per-cpu values is safe. Discovered when node compaction hung for a nearly empty node, as the math to determine throttling broke. Reproduced by repeated memory hotplug/unplug cycles on a node under pressure: NR_ISOLATED_ANON ratchets up and never returns to zero. Link: https://lore.kernel.org/20260627202243.758289-1-gourry@gourry.net Fixes: 75ef71840539 ("mm, vmstat: add infrastructure for per-node vmstats") Signed-off-by: Gregory Price Cc: Johannes Weiner Cc: Mel Gorman Cc: Mike Rapoport Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 62e1c2741a4d923d9854efd5927a6212aad7a187 Author: Xiangfeng Cai Date: Tue Jul 14 01:14:55 2026 +0800 mm/hugetlb: fix list corruption in allocate_file_region_entries() commit dd9623f58ec702a07b2d67179d6fcea79c52231a upstream. allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe. Link: https://lore.kernel.org/20260713171456.300518-2-caixiangfeng@bytedance.com Fixes: d3ec7b6e09e5 ("mm/hugetlb: use list_splice to merge two list at once") Signed-off-by: Xiangfeng Cai Reviewed-by: Muchun Song Cc: Baoquan He Cc: David Hildenbrand Cc: Oscar Salvador Cc: Shuah Khan Cc: Wei Yang Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 01504da375f5b19df195cb1cb1cf1dd184318f97 Author: Zi Yan Date: Thu Jul 9 15:12:01 2026 -0400 mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk() commit 89b1b79c308818a715e75f28744b70d8940a07c9 upstream. In pcpu_create_chunk(), nr_pages is the total contiguous backing allocation, i.e., nr_units * pcpu_unit_pages, but pcpu_chunk_populated() uses it to set chunk->populated, whose size is pcpu_unit_pages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nr_units > 1, the function writes beyond chunk->populated. Fix it by using chunk->nr_pages. It also fixes the global pcpu_nr_empty_pop_pages accounting, since pcpu_balance_free() only iterates up to chunk->nr_pages. Commit a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") introduced the bitmap overflow issue. Later, commit b539b87fed37f ("percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated") added pcpu_nr_empty_pop_pages and caused the accounting issue. Link: https://lore.kernel.org/20260709-fix-pcpu_create_chunk-in-percpu-km-v1-1-1f64745a84cc@nvidia.com Fixes: a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260703-keep-subpage-private-zero-at-free-v2-0-2970fe777dd6%40nvidia.com?part=1 Assisted-by: Codex:GPT-5 Signed-off-by: Zi Yan Acked-by: Dennis Zhou Cc: Christoph Lameter Cc: Tejun Heo Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a583806ae9697edde7087b054008ab80381fdbce Author: Benjamin Boortz Date: Mon Jul 20 19:51:04 2026 +0200 pinctrl: bm1880: add missing select GENERIC_PINCONF commit dad6e107b3cd9d20514e7799b7ad8674f81e3f30 upstream. drivers/pinctrl/pinctrl-bm1880.c initialises its pinconf_ops with .is_generic = true, but that field is only present when CONFIG_GENERIC_PINCONF is enabled (guarded by #ifdef in pinconf.h). The Kconfig entry for PINCTRL_BM1880 never selects GENERIC_PINCONF, so any config that enables CONFIG_PINCTRL_BM1880=y without CONFIG_GENERIC_PINCONF=y fails to compile: drivers/pinctrl/pinctrl-bm1880.c:1288:10: error: 'const struct pinconf_ops' has no member named 'is_generic' Found by randconfig testing on arm64; tinyconfig reproducer below. Add the missing select to fix the build. Fixes: 49bd61ebce5f ("pinctrl: Add pinconf support for BM1880 SoC") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Boortz Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit e8b3d09aa8889dda9be9cbb3d2f0218c4b9acde4 Author: Michael Bommarito Date: Tue Jul 14 07:47:29 2026 -0400 erofs: cap LZMA stream pool size commit c9b47e6b23114e939b17f818471c7a46e59006e7 upstream. fs/erofs/decompressor_lzma.c sizes the module-global MicroLZMA stream pool from num_possible_cpus() when the lzma_streams module parameter is unset, then z_erofs_load_lzma_config() preallocates one image-supplied dictionary per stream, accepting dictionaries up to 8 MiB. On high-CPU systems, a small EROFS image can pin hundreds of MiB of vmalloc-backed decoder state until the erofs module is unloaded. Impact: An EROFS image mounted by the system can pin up to 8 MiB of vmalloc memory per LZMA stream, either as intended or unexpectedly. Bound the default stream count by a new CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS option, default 16, so the worst-case default preallocation is 128 MiB if the number of CPUs is no less than 16 while preserving the existing per-image dictionary limit. An explicit lzma_streams module parameter is still honoured as-is, so administrators who deliberately size the pool are not affected. Fixes: 622ceaddb764 ("erofs: lzma compression support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 929f6396baade89999ec8a1281232c101cbc727d Author: Karl Mehltretter Date: Sun Jul 19 14:11:40 2026 +0200 pinctrl: devicetree: don't free uninitialized dev_name on error path commit 015b5bcbcb622b32317642be91a7f79aa5413649 upstream. dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure. Fixes: be4c60b563ed ("pinctrl: devicetree: Avoid taking direct reference to device name string") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 9d5de82acf28987d2bb31b1aff1da68be71e3c43 Author: Benjamin Boortz Date: Sun Jul 19 11:41:46 2026 +0200 pinctrl: microchip-sgpio: add missing select REGMAP_MMIO commit 25cb6e9a13123d1039cdc75b446ac52e1ebdc26d upstream. The driver calls ocelot_regmap_from_resource() via , which internally uses devm_regmap_init_mmio() and requires REGMAP_MMIO. The Kconfig entry does not select REGMAP_MMIO, causing a build failure when no other driver in the config happens to pull in REGMAP_MMIO: include/linux/mfd/ocelot.h:34:24: error: implicit declaration of function 'devm_regmap_init_mmio' Found by randconfig testing on arm64; tinyconfig reproducer below. Fixes: 2afbbab45c26 ("pinctrl: microchip-sgpio: update to support regmap") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Boortz Reviewed-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit c39643ad99fea749be50615550e8f0e6d6e60694 Author: Cen Zhang (Microsoft) Date: Tue Jul 7 12:41:15 2026 -0400 rhashtable: clear stale iter->p on table restart [ Upstream commit 8173f7e2ce67e6ca1d4763f3da14e5b01ce77456 ] rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0 Fixes: 5d240a8936f6 ("rhashtable: improve rhashtable_walk stability when stop/start used.") Cc: Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Yuan Tan Closes: https://lore.kernel.org/linux-crypto/CAB8m9Wh559e+=n8z51gB8DrbEyCc2mc0MgGjrRR6_VXBmU=2AQ@mail.gmail.com Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: NeilBrown Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 27210d433a8c5fe6bf7278a04bbaeb49a81d0290 Author: Pengfei Zhang Date: Tue Aug 4 19:46:54 2026 +0800 ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump commit 9facb861dc6b9b9ea9793ef5032a9a826f7a4229 upstream. inet6_dump_fib() saves its progress in cb->args[1] as a positional index within the current hash chain. Between batches, a concurrent fib6_new_table() can insert a new table at the chain head, shifting all existing entries. The saved index then lands on a different table, causing fib6_dump_table() to set w->root to the wrong table while w->node still points into the previous one. fib6_walk_continue() dereferences w->node->parent (NULL) and panics: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:fib6_walk_continue+0x6e/0x170 Call Trace: fib6_dump_table.isra.0+0xc5/0x240 inet6_dump_fib+0xf6/0x420 rtnl_dumpit+0x30/0xa0 netlink_dump+0x15b/0x460 netlink_recvmsg+0x1d6/0x2a0 ____sys_recvmsg+0x17a/0x190 Fix by storing tb->tb6_id in cb->args[1] instead of a positional index. On resume, skip entries until the id matches; a concurrent head-insert can never match the saved id, so the walker always resumes on the correct table. Fixes: 1b43af5480c3 ("[IPV6]: Increase number of possible routing tables to 2^32") Signed-off-by: Pengfei Zhang Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260625070517.965597-1-zhangfeionline@gmail.com Signed-off-by: Jakub Kicinski [Adapted to 5.10/6.1/6.6: inet6_dump_fib() there predates 22e36ea9f5d7 and 5fc68320c1fb, so the return variable is "res" not "err" and the RCU-protected hash walk exits via "out_unlock" instead of "unlock". Context-only change; the fix itself is identical.] Signed-off-by: Pengfei Zhang Signed-off-by: Sasha Levin commit 67aaec2a1fdce3e1dde46c45b5d1ef8cf22f65cd Author: Namjae Jeon Date: Wed Jul 22 10:04:19 2026 +0900 ksmbd: fix use-after-free in __close_file_table_ids() [ Upstream commit e7188199eff46a636f3436356f0aae039be6dd66 ] A ksmbd_file can remain alive after logical close while another session holds a temporary reference obtained through ksmbd_lookup_fd_inode(). ksmbd_close_fd() currently marks the file closed and drops the idr-owned reference, but leaves the pointer published in the closing session's idr until the final reference is dropped. If the foreign holder performs the final ksmbd_fd_put(), __put_fd_final() supplies the foreign session's file table to __ksmbd_close_fd(). The object is then freed without being removed from its owner's idr, and the owner session later dereferences the stale pointer during file-table teardown. Remove the volatile id from the owner's idr while ksmbd_close_fd() still holds that table's lock, and clear volatile_id before dropping the idr-owned reference. A later foreign final put then only performs physical destruction and cannot remove the object from the wrong table. Fixes: 8510a043d334 ("ksmbd: increment reference count of parent fp") Reported-by: Yunseong Kim Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit fb27b7b7b7bb4ddd95aa44d9904cb11273c3f8f6 Author: Namjae Jeon Date: Sun Jun 21 19:41:08 2026 +0900 ksmbd: return success for deferred final close [ Upstream commit c5db4de8988f1a621556ca5c4537f77b766ca07d ] ksmbd_close_fd() marks an open file as FP_CLOSED and drops the file table reference. If another in-flight request still holds a reference, the final close is deferred until that request drops its reference. The function currently returns -EINVAL in that deferred-final-close case because fp is cleared when the reference count does not reach zero. That turns a valid close into STATUS_FILE_CLOSED. smb2.compound_find.compound_find_close sends QUERY_DIRECTORY and then closes the same directory handle before receiving the find response. The query holds a reference while it builds the response, so close must mark the handle closed and return success even though final teardown is delayed. Track whether the handle was successfully transitioned to FP_CLOSED and return success when only the final close is deferred. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: e7188199eff4 ("ksmbd: fix use-after-free in __close_file_table_ids()") Signed-off-by: Sasha Levin commit e382a4efeeae6555b95d9ff336cf3094ee7d336b Author: Denis V. Lunev Date: Sun Jul 26 12:43:11 2026 +0200 qede: sync udp_tunnel ports outside qede_lock in the recovery path [ Upstream commit 451c9075d6c53f2438d110addbeeeea6fac18567 ] A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them. Fixes: 8cd160a29415 ("qede: convert to new udp_tunnel_nic infra") Signed-off-by: Denis V. Lunev CC: Andrew Lunn CC: "David S. Miller" CC: Eric Dumazet CC: Jakub Kicinski CC: Paolo Abeni Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260726104311.1782900-1-den@openvz.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 228757a2988c63ca9731e0203fe0a23a2632f4e3 Author: Suman Ghosh Date: Fri Jul 24 12:58:31 2026 +0530 octeontx2-pf: Set correct sequence for carrier off and tx queue stop [ Upstream commit 16809472409d998afcda402e32b8229b389337c4 ] During link down event, we were doing netif_tx_stop_all_queues() first and then netif_carrier_off(). This can cause a potential race since carrier is still on during down event. This patch reverse the calling order to fix the issue. Fixes: 50fe6c02e5ad ("octeontx2-pf: Register and handle link notifications") Signed-off-by: Suman Ghosh Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260724072831.2415281-1-rkannoth@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 272eafaf16258230504e5b284e3d61e8c778194c Author: Daniel Golle Date: Tue Jul 28 05:52:29 2026 +0100 net: dsa: mt7530: error out on failed reads in MT7531 PHY polling [ Upstream commit 77a9ebe8818cf6dd1699bd6728cb5d66307801d7 ] The MT7531 indirect PHY access functions poll MT7531_PHY_IAC through a helper which returns 0 when the underlying read fails, so a failed bus transaction clears MT7531_PHY_ACS_ST and the access carries on, returning garbage PHY register data to phylib. Poll using regmap_read_poll_timeout(), which stops on read errors and propagates them. These functions hold the MDIO bus lock across the whole sequence, so the unlocked regmap accesses remain correct. Remove the now-unused _mt7530_unlocked_read(). Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch") Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/79e85d68d210cc37342978171aa6432aa2954333.1785213071.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aecd00c33b509382e167be7690fd76d4b5b173eb Author: Muhammad Bilal Date: Thu Jun 18 02:25:20 2026 +0500 accel/qaic: use sizeof(*trans_hdr) for transaction length check [ Upstream commit d6c075f797a672a6e3bd2fd44aee713801698ec2 ] In encode_message() the per-transaction lower-bound check compares trans_hdr->len against sizeof(trans_hdr), i.e. the size of the pointer, instead of sizeof(*trans_hdr), the size of struct qaic_manage_trans_hdr. Every other length check in this file (encode_message() at the loop guard, decode_message(), etc.) correctly uses sizeof(*trans_hdr), so this is an inconsistency. On 64-bit builds the pointer and the struct are both 8 bytes, so the check is correct by coincidence and there is no behavioural change. On 32-bit builds the pointer is 4 bytes, which weakens the minimum-length check below the 8-byte header size. Use sizeof(*trans_hdr) so the check validates against the actual transaction header size on all builds. Fixes: ea33cb6fc278 ("accel/qaic: tighten bounds checking in encode_message()") Signed-off-by: Muhammad Bilal Reviewed-by: Jeff Hugo Signed-off-by: Jeff Hugo Link: https://patch.msgid.link/20260617212520.59801-1-meatuni001@gmail.com Signed-off-by: Sasha Levin commit 481737704eee053db49c6a28347b1fa50d0cd1c1 Author: Masami Hiramatsu (Google) Date: Tue Jul 28 21:49:51 2026 +0900 tracing/mmiotrace: Reset dropped_count in mmio_reset_data() [ Upstream commit c786d2bdf1f3964deee192ad942dee2a741c1e2c ] mmio_reset_data() is called during tracer initialization, reset, and start. While it resets overrun_detected and prev_overruns, it neglects to reset dropped_count. Consequently, dropped event counts from prior tracing sessions persist in dropped_count and corrupt overrun reports in subsequent runs. Fix this by explicitly calling atomic_set(&dropped_count, 0) in mmio_reset_data(). Link: https://patch.msgid.link/178524299122.56416.16277704230639425172.stgit@devnote2 Fixes: 173ed24ee2d6 ("mmiotrace: count events lost due to not recording") Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 2ba4c5cc3031328c2882c2d38f3d25136d0152e4 Author: Minhong He Date: Wed Jul 29 16:56:56 2026 +0800 can: isotp: check register_netdevice_notifier() error in module init [ Upstream commit ef09a13c5afac41a3c4b5f22b8572820d9e7518c ] Register the netdevice notifier before can_proto_register() and check the return value. If protocol registration fails, unregister the notifier before returning the error. Align isotp_module_init() with the reordering already done for raw.c (commit c28b3bffe49e ("can: raw: process optimization in raw_init()")) and bcm.c (commit edd1a7e42f1d ("can: bcm: registration process optimization in bcm_module_init()")). Fixes: 8d0caedb7596 ("can: bcm/raw/isotp: use per module netdevice notifier") Signed-off-by: Minhong He Link: https://patch.msgid.link/20260729085656.134523-1-heminhong@kylinos.cn Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 128fe7596adcd6a307d51a3a6a591c68b3aa4f5a Author: Chenguang Zhao Date: Thu Jul 23 10:18:20 2026 +0800 net: sxgbe: check descriptor ring allocation failures [ Upstream commit 51b093a7ba27476e1f639455f005e8d2e75390e4 ] sxgbe_open() ignores the return value of init_dma_desc_rings() and continues to program DMA with invalid ring addresses when allocation fails. Check the return value and disconnect the PHY on failure. Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") Signed-off-by: Chenguang Zhao Reviewed-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3563e2486dcd50a751dbcbc1de37e5186646dce6 Author: Chenguang Zhao Date: Thu Jul 23 10:18:19 2026 +0800 net: sxgbe: free TX rings on RX allocation failure [ Upstream commit c870f7e2890b9f78ac84515a9809cc5c183c975e ] When RX descriptor ring allocation fails, init_dma_desc_rings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked. Rearrange error labels to clean up TX rings upon RX failures. Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") Signed-off-by: Chenguang Zhao Reviewed-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8f7812821ed7ae31393ba7521bc9817967bf8cab Author: Leon Romanovsky Date: Wed Jul 22 09:30:10 2026 +0300 scsi: target: Clear cmd_cnt when initial counter enrollment fails [ Upstream commit a8ddfd2425bbbafadae8700d63ed8a61a4109878 ] When target_get_sess_cmd() fails during session shutdown because percpu_ref_tryget_live() returns false, the command keeps the se_cmd->cmd_cnt pointer that __target_init_cmd() assigned earlier without owning a reference. Final release through target_release_cmd_kref() then issues an unmatched percpu_ref_put(). Commit 8e288be8606a ("scsi: target: Pass in cmd counter to use during cmd setup") moved the cmd_cnt assignment ahead of the reference acquisition. Clear se_cmd->cmd_cnt whenever the initial target_get_sess_cmd() fails in target_init_cmd() and target_submit_tmr(), so release performs exactly one matching put per acquired reference. Fixes: 8e288be8606a ("scsi: target: Pass in cmd counter to use during cmd setup") Signed-off-by: Leon Romanovsky Reviewed-by: Mike Christie Link: https://patch.msgid.link/20260722-reference-count-underflow-in-target-v1-1-63ab664f12fd@nvidia.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1b42d05f1c59047f242aa316733199921d948a03 Author: Benjamin Block Date: Mon Jul 20 09:27:36 2026 +0200 scsi: zfcp: Fix memory leak during adapter release by destroying gid_pn_req [ Upstream commit b601fa590e667bd9643feed8c869b6b3e418480d ] When releasing an adapter we don't free the mempool 'gid_pn_req' that is allocated during the enqueue. This leaks memory: unreferenced object 0xd8d29297de700 (size 256): comm "(udev-worker)", pid 2105, jiffies 4294945794 hex dump (first 32 bytes): 00 00 00 00 de ad 4e ad ff ff ff ff 00 00 00 00 ......N......... ff ff ff ff ff ff ff ff 00 0d c4 5f 67 9d 99 e0 ..........._g... backtrace (crc 4a5b5da2): [<000dc45f64da418c>] kmemleak_alloc+0x6c/0xa0 [<000dc45f62b430aa>] __kmalloc_cache_node_noprof+0x36a/0x4d0 [<000dc45f629a535a>] mempool_create_node_noprof+0xaa/0x150 [<000dc45ee2c065e6>] zfcp_allocate_low_mem_buffers+0x96/0x370 [zfcp] [<000dc45ee2c070f8>] zfcp_adapter_enqueue+0x598/0xd40 [zfcp] [<000dc45ee2c08eb0>] zfcp_ccw_set_online+0x160/0x210 [zfcp] [<000dc45f643d4762>] ccw_device_set_online+0x232/0xd80 [<000dc45f643d53d4>] online_store_recog_and_online+0x124/0x390 [<000dc45f643d8238>] online_store+0x298/0x5b0 [<000dc45f62eb0a04>] kernfs_fop_write_iter+0x2c4/0x480 [<000dc45f62c81150>] new_sync_write+0x370/0x4b0 [<000dc45f62c87abe>] vfs_write+0x43e/0x5b0 [<000dc45f62c87ff4>] ksys_write+0x114/0x1f0 [<000dc45f621c4a16>] do_syscall+0x2f6/0x430 [<000dc45f64d9d5d8>] __do_syscall+0xc8/0x1c0 [<000dc45f64dc2224>] system_call+0x74/0xa0 Fix this by destroying the mempool during the adapter's release. Fixes: 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") Signed-off-by: Benjamin Block Tested-by: M Nikhil Acked-by: M Nikhil Reviewed-by: Chinmaya Kajagar Reviewed-by: Nihar Panda Link: https://patch.msgid.link/20260720072736.3381816-2-niharp@linux.ibm.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 107d3d6c179108270922cc937f226fdbb8a3e60d Author: Guangshuo Li Date: Wed Jul 15 01:27:26 2026 +0800 scsi: ufs: core: Cancel RTC work in active-active suspend [ Upstream commit f71b4a30983b846b4075bf544e835121e70e6a43 ] UFS RTC support schedules ufs_rtc_update_work to periodically update the device RTC. The work can issue query commands and access the UFS host controller. A previous change moved the RTC work cancellation before the PRE_CHANGE vendor suspend callback to close a race in the common suspend path. However, the active-active path jumps directly to vops_suspend after flushing exception handling work and therefore bypasses the cancellation. If the RTC work runs while the vendor suspend callback is gating or otherwise changing hardware state, it can access the controller during suspend and trigger an SError. Cancel the RTC work before entering the vendor suspend callback in the active-active path. Since this path now cancels the work, move the RTC work scheduling outside the device and link state restoration block in the resume path. This restarts RTC updates after an active-active suspend and resume cycle. Fixes: b0bd84c39289 ("scsi: ufs: core: Fix SError in ufshcd_rtc_work() during UFS suspend") Signed-off-by: Guangshuo Li Reviewed-by: Peter Wang Reviewed-by: Bean Huo Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260714172726.1736967-1-lgs201920130244@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3c60a8b4037dc35e365658fcbcb349a5d742ff49 Author: TanZheng Date: Fri Jul 24 15:58:50 2026 +0800 scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE [ Upstream commit 9c33222bd387312874fbe36ca8002e5c945b9653 ] In the iblock_execute_pr_out() function, PRO_PREEMPT, PRO_PREEMPT_AND_ABORT, and PRO_RELEASE all perform callback capability checks through ops->pr_clear. The error check allows unimplemented hooks to pass through the gate, resulting dereferencing a NULL function pointer. Check whether the hooks that need to be called are supported. Fixes: 394f81184882 ("scsi: target: Add block PR support to iblock") Signed-off-by: TanZheng Reviewed-by: Mike Christie Link: https://patch.msgid.link/20260724075850.280699-1-kensanya@163.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ba99aed7bad80f158513a466777352e35b2b27f4 Author: Christian Marangi Date: Sun Jul 26 17:08:05 2026 +0200 net: phylink: put link_gpio if phylink_create fails [ Upstream commit 0fe1e3e8f3380d7862296a73b528d164e96c76b8 ] In phylink_create() if phylink_register_sfp() returns an error, link_gpio obtained by phylink_parse_fixedlink() is never released. While this is a very unlikely scenario, it's worth to fix/handle this. This was present from the very first implementation of phylink but got relevant only with the introduction of ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") where additional function were added after phylink_parse_fixedlink() making the release of link_gpio needed if such additional function errored out. While at it, restructure the exit condition of phylink_create() with the goto pattern to reduce code duplication on handling error conditions. Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") Signed-off-by: Christian Marangi Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260726150806.2437-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 716d47531e74036a9acf0d5e101131d07c613a98 Author: Pauli Virtanen Date: Sat Jul 25 12:59:22 2026 +0300 Bluetooth: hci_sync: fix hci_conn_del() use in hci_le_create_conn_sync [ Upstream commit 2c1e4e00613dfd105f978be2276e5e265801ec9f ] hci_conn_del() caller must hold hdev->lock, check the conn was not concurrently deleted, and usually inform socket the conn is going to be deleted. Use hci_abort_conn_sync() instead of calling hci_conn_del() without locks etc. Fixes: 8e8b92ee60de5 ("Bluetooth: hci_sync: Add hci_le_create_conn_sync") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 64d1645f26aa49b5a86ba2fccd0bb6749ea725a6 Author: Pauli Virtanen Date: Sat Jul 25 12:59:17 2026 +0300 Bluetooth: hci_conn: hold conn reference in abort_conn_sync() [ Upstream commit 5761d003daa987ac81463f570713ce9c9dd204e5 ] There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that. Fixes: 227a0cdf4a02 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 759303b0012cc26ea4e8964412acc3dbd081ed26 Author: Pauli Virtanen Date: Wed Mar 25 21:07:45 2026 +0200 Bluetooth: hci_sync: make hci_cmd_sync_run_once return -EEXIST if exists [ Upstream commit d288f4db0909c22342eb50cd1632b4d850517281 ] hci_cmd_sync_run_once() needs to indicate whether a queue item was added, so caller can know if callbacks are called, so it can avoid leaking resources. Change the function to return -EEXIST if queue item already exists. Modify all callsites vs. the changes. The only callsite is hci_abort_conn(). Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 5761d003daa9 ("Bluetooth: hci_conn: hold conn reference in abort_conn_sync()") Signed-off-by: Sasha Levin commit c31be902ccbbb0b2c23159a1481dce80d1f9753d Author: Zijun Hu Date: Sat Jul 25 01:54:40 2026 -0700 Bluetooth: btintel: Validate length before parsing diagnostics TLV [ Upstream commit b640ff9af3c809ff5ea2077fbba17df1594ec1e4 ] btintel_diagnostics() accesses tlv->val[0] without first validating that the diagnostics VSE is long enough to contain that field, so may cause reading data beyond the received frame. Fix by validating the length before access. Fixes: af395330abed ("Bluetooth: btintel: Add Intel devcoredump support") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 38a9a30614cc7123a647506449af4c07619c3d4a Author: Pauli Virtanen Date: Fri Jul 24 23:20:27 2026 +0300 Bluetooth: ISO: fix timeout vs sync_timeout typo in check_bcast_qos [ Upstream commit e9cb51813d79fc9aae4a2098aab3ab6ebd7fb6c8 ] In iso.c check_bcast_qos(), missing bcast.timeout is not set to its default value, and appears typoed as bcast.sync_timeout. Fix the typo. Fixes: b37cab587aa3 ("Bluetooth: ISO: Don't reject BT_ISO_QOS if parameters are unset") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit fd4c1e301bdec60a40728ea37de531cbccda501a Author: Jiale Yao Date: Thu Jul 23 14:48:45 2026 +0800 Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp [ Upstream commit c4740e7f23ff9a8210198d8b4703259e21b9f69d ] l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers. Fixes: f1496dee9cbd ("Bluetooth: Add initial code for LE L2CAP Connect Request") Assisted-by: Claude:deepseek-v4-pro Signed-off-by: Jiale Yao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit cc1d39946d62bc568551dfb81149724de1e91338 Author: Pauli Virtanen Date: Mon Jul 20 17:53:33 2026 +0300 Bluetooth: ISO: clear iso_data always when detaching conn from hcon [ Upstream commit d57e506f6a1e3929611340fae87c1e4823f4d85c ] When setting conn->hcon = NULL, also conn->hcon->iso_data = NULL is necessary, otherwise later iso_conn_free() will UAF. Fix clearing of iso_data in iso_sock_disconn() Fixes KASAN: slab-use-after-free in iso_conn_hold_unless_zero on iso_sock_release() followed by hci_abort_conn_sync(). Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 68c5b240dba9644cb55160316ef4d8cea08b4630 Author: Guenter Roeck Date: Tue Jul 28 08:41:40 2026 -0700 hwmon: (pmbus) Fix return value from pmbus_update_byte_data() [ Upstream commit a19038a200f18d9e74ac30081797917d0886e16b ] pmbus_update_byte_data() is supposed to return a negative error code or 0. However, if no change is made to the register, it actually returns the register value. This can result in problems if the calling code explicitly expects to see an error code or 0. Fix it to return 0 on success or the error code as expected. Fixes: 11c119986f270 ("hwmon: (pmbus) add helpers for byte write and read modify write") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ff558072d199c1d641d1561da622e67f780514de Author: Zhao Li Date: Thu Jul 23 09:09:28 2026 +0800 wifi: mac80211: validate individual TWT params before driver setup [ Upstream commit 0502d5077e419427d80f4d46ba95d0067f5fb916 ] ieee80211_process_rx_twt_action() only partially validates a received S1G TWT setup frame before queueing it. An individual agreement can therefore reach ieee80211_s1g_rx_twt_setup() with twt->length too short for the full struct ieee80211_twt_params. The individual path passes twt to drv_add_twt_setup(). Both the tracepoint and the driver callback consume the complete parameters block, not merely req_type. Do not pass a short individual agreement to the driver. Broadcast agreements remain unchanged because they are rejected locally after accessing only req_type. Fixes: f5a4c24e689f ("mac80211: introduce individual TWT support in AP mode") Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260723010928.76551-1-enderaoelyther@gmail.com [edit commit message to not overclaim lack of validation nor understate driver impact] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 961d80c6389d9d0573bb50a10c64ab785bb8a806 Author: Thorsten Blum Date: Thu Jul 2 23:15:57 2026 +0200 powerpc/boot: Fix treeboot-akebono CPU node lookup check [ Upstream commit b24fc8278b70a9d27ec801a427ab4de9b769d69a ] fdt_node_offset_by_prop_value() returns a negative error code on failure - fix the check accordingly. Fixes: 2a2c74b2efcb ("IBM Akebono: Add the Akebono platform") Signed-off-by: Thorsten Blum Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260702211554.56923-6-thorsten.blum@linux.dev Signed-off-by: Sasha Levin commit 1792fcda01785decfc9fde0763bba787b0791762 Author: Thorsten Blum Date: Thu Jul 2 23:15:56 2026 +0200 powerpc/boot: Fix treeboot-currituck CPU node lookup check [ Upstream commit 43863f6575d2211e8c5157fefb83ad0ad046aab4 ] fdt_node_offset_by_prop_value() returns a negative error code on failure - fix the check accordingly. Fixes: 228d55053397 ("powerpc/47x: Add support for the new IBM currituck platform") Signed-off-by: Thorsten Blum Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260702211554.56923-5-thorsten.blum@linux.dev Signed-off-by: Sasha Levin commit 3382cf66522df9327122b8639c116aca026c2084 Author: Thorsten Blum Date: Thu Jul 2 23:15:55 2026 +0200 powerpc/boot: Fix simpleboot CPU node lookup check [ Upstream commit c824ab65685bb119c6c6a3a200b3428c72862d5a ] fdt_node_offset_by_prop_value() returns a negative error code on failure - fix the check accordingly. Fixes: d2477b5cc8ca ("[POWERPC] bootwrapper: Add a firmware-independent simpleboot target.") Signed-off-by: Thorsten Blum Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260702211554.56923-4-thorsten.blum@linux.dev Signed-off-by: Sasha Levin commit ab8549d5b8f0232aef350f3cb2d734f3831f70a4 Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:24 2026 -0300 hwmon: (adt7470) Fix PWM auto temp state array and bounds check [ Upstream commit 92413f439d1ec5e55b73ede8d66a7b971cbd1ced ] In pwm_auto_temp_store(), the parsed user input was missing bounds checks, allowing values > 0xF to overflow into the adjacent channel's bits. Furthermore, the value was being incorrectly written to the pwm_automatic state array instead of pwm_auto_temp. Fix this by rejecting values > 0xF with -EINVAL, and assigning the value to the correct array only after a successful I2C write. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260727034932.0B7C41F000E9@smtp.kernel.org/#t Fixes: 6f9703d0be16 ("hwmon: add support for adt7470") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-8-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit d328175045176f85c15c369bd21dc551351e7935 Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:23 2026 -0300 hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read [ Upstream commit 1b46fe9dc8f8de59310f37e6c5e5c0e05ded46c3 ] If the fan data becomes 0 between the FAN_DATA_VALID() check and the FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash due to a race with a concurrent update of the cached fan value. Fix a TOCTOU issue by reading fan data once. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/r/20260727034929.E29B71F000E9@smtp.kernel.org/ Fixes: fc958a61ff6d ("hwmon: (adt7470) Convert to devm_hwmon_device_register_with_info API") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-7-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c11d1bc785f2a97d71249881761a5995d6928161 Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:22 2026 -0300 hwmon: (adt7470) Use cached PWM frequency value [ Upstream commit 60677cd4c28f44d5b307d3029dccece38fcce90f ] adt7470_pwm_read() currently ignores failures returned by pwm1_freq_get(). If the register read fails, the negative error code is returned through *val while the function itself reports success, potentially exposing a negative PWM frequency through sysfs. Fix this by using the cached PWM frequency maintained by the driver, eliminating the register access from the read path. Apart from the corrected error propagation and using the cached value, no functional change is intended. Fixes: ef67959c4253 ("hwmon: (adt7470) Convert to use regmap") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-6-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 97fac8440c9ae93f0da9a7169008d06b3154b4a3 Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:20 2026 -0300 hwmon: (adt7470) Fix swapped PWM3 and PWM4 auto mode masks [ Upstream commit a3850231521b06bbbb18c8ebea100320c14a08be ] The ADT7470_PWM3_AUTO_MASK and ADT7470_PWM4_AUTO_MASK macros are currently defined with swapped bit values. According to Table 22 of the ADT7470 datasheet, the Fan Control Mode Configuration for register 0x69 follows the exact same bit position layout as register 0x68: - 0x68 Bit[7] corresponds to BHVR1 (PWM1) -> 0x80 - 0x68 Bit[6] corresponds to BHVR2 (PWM2) -> 0x40 - 0x69 Bit[7] corresponds to BHVR3 (PWM3) -> 0x80 - 0x69 Bit[6] corresponds to BHVR4 (PWM4) -> 0x40 Consequently, PWM3 should use mask 0x80 and PWM4 should use 0x40. This typo did not cause any functional bugs because these specific macros are never referenced in the driver code. Instead, the driver correctly applies the configuration by relying on the modulo parity of the channel index (e.g., `channel % 2`) to selectively apply either ADT7470_PWM1_AUTO_MASK (0x80) or ADT7470_PWM2_AUTO_MASK (0x40). Since the bit layout is identical between the two configuration registers, the hardware is currently configured correctly. Fix the macro definitions to reflect the datasheet accurately and prevent future bugs or confusion during code review and refactoring. As this is a purely cosmetic fix with no functional impact, a backport to stable kernels is not necessary. Fixes: 6f9703d0be16 ("hwmon: add support for adt7470") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-4-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 40a3117650f9d8c36cf2c835062ae961f1d37fcf Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:21 2026 -0300 hwmon: (adt7470) Fix temperature alarm logic in hwmon_temp_read() [ Upstream commit 1a18c79c4bc44cc5349c60e16b0b744dc6ec5f77 ] During the conversion the alarm callback started interpreting the channel index as an alarm bitmask, resulting in incorrect alarm reporting. Compute the proper alarm bit instead. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/r/20260717211224.B9E291F000E9@smtp.kernel.org Fixes: fc958a61ff6d ("hwmon: (adt7470) Convert to devm_hwmon_device_register_with_info API") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-5-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 1a42bd72a66205e439db1d1142442b62d393408a Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:19 2026 -0300 hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread [ Upstream commit cb0b7f9c43b0abbd422a7e4c2c85e91db429207c ] When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/r/20260716213252.EACA71F000E9@smtp.kernel.org Fixes: 89fac11cb3e7 ("adt7470: make automatic fan control really work") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-3-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 0c89e5ae2655f0b1a969f55654aa0c42e2a98304 Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:18 2026 -0300 hwmon: (adt7470) Fix cache updated before hardware write on I2C error [ Upstream commit 05270bd38d9bf88a2f4c212246a8fa29f4032078 ] adt7470_temp_write() and adt7470_pwm_write() update the driver's cached values (temp_min, temp_max, pwm_input, pwm_enable) before issuing the corresponding regmap_write(), and never check whether the write succeeded before committing that update. If the I2C transaction fails, the function correctly propagates the error to the caller, but the cache silently keeps the new value, which was never actually applied to the hardware. Subsequent reads then report a value that does not match the device state. Reorder both write paths to update the cache only after a successful regmap_write(), so the cache always reflects what was actually written to the hardware. Fixes: ef67959c4253 ("hwmon: (adt7470) Convert to use regmap") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-2-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f114a8aa7905a27fe204b29797c2288a503af9a8 Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:17 2026 -0300 hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors [ Upstream commit 625a2c02a1c04571232a746fe188b4d9a8d63edd ] During adt7470_read_temperatures(), the driver temporarily switches the PWM channels to manual mode, performs the temperature collection, and then restores the original configuration registers. However, if an I2C transaction fails at any point after entering manual mode, the function aborts and returns immediately. This leaves the configuration registers un-restored, permanently trapping the fans in manual mode. Introduce a recovery path to ensure that the original PWM configuration registers are always restored, even when intermediate I2C operations fail. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/r/20260716213252.EACA71F000E9@smtp.kernel.org Fixes: ef67959c4253 ("hwmon: (adt7470) Convert to use regmap") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-1-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit cf2dcde2284562ff87830ca0b7fa2b06e95aef1e Author: Chenguang Zhao Date: Thu Jul 23 17:26:37 2026 +0800 forcedeth: fix UAF of txrx_stats in nv_remove [ Upstream commit 22666ba1420164753d7b0f5a841986b25ace5435 ] nv_remove() frees the per-CPU txrx_stats before unregister_netdev(). Until unregister completes, ndo_get_stats64, the NAPI/xmit data path, and nv_close()/drain may still access txrx_stats, leading to a use-after-free. Free the stats only after unregister_netdev(). Fixes: f4b633b911fd ("forcedeth: use per cpu to collect xmit/recv statistics") Signed-off-by: Chenguang Zhao Reviewed-by: Vadim Fedorenko Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/20260723092637.2135095-1-chenguang.zhao@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b60702104b45db980c0e31c176df006b7367040e Author: David Corvaglia Date: Sun Jul 26 06:26:05 2026 +0000 net: bridge: mrp: fix Option TLV length in MRP_Test frames [ Upstream commit 5546da86894d5906f131b05890705a7abf949d84 ] oui is a pointer, so sizeof(oui) is the pointer size. The MRA Option TLV thus advertises a wrong length (15 vs 10 on x86_64), causing misparsing of the frame on peers. Fix is to replace with sizeof(*oui). Fixes: f7458934b079 ("net: bridge: mrp: Update the Test frames for MRA") Signed-off-by: David Corvaglia Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260726062605.2746-1-david@corvaglia.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 25b528816f5d83be5236dc182692369e8c9402b0 Author: Guenter Roeck Date: Mon Jul 27 13:35:37 2026 -0700 hwmon: (nct6775-core) Prevent access to unsupported weight registers [ Upstream commit d0b704e569ac3b8416d8e02270cdc9bf830ed395 ] Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers. Reported-by: Sashiko Fixes: 29c7cb485b32 ("hwmon: (nct6775) Integrate new model nct6116") Cc: Björn Gerhart Cc: Florian Bezdeka Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f5ecaa7ea7686fa7ecdb6affc9d3a9a42e4524b1 Author: Eric Dumazet Date: Fri Jul 24 07:29:01 2026 +0000 net: do not send ICMP/NDISC Redirects when peer allocation fails [ Upstream commit dbc3791e3b2472e1ccc08947e0f83b443470ff4f ] When inet_getpeer_v4() or inet_getpeer_v6() fails to allocate a peer entry under memory pressure or tree size caps, redirect handlers previously fell back to sending un-rate-limited ICMP/NDISC Redirect messages. In IPv4, ip_rt_send_redirect() called icmp_send() directly when peer == NULL. In IPv6, ip6_forward() and ndisc_send_redirect() passed a NULL peer into inet_peer_xrlim_allow(), which returned true when peer == NULL. Because ICMP/NDISC Redirects are not part of the default global rate limit mask (sysctl_icmp_ratemask), sending redirects when peer == NULL creates an un-rate-limited ICMP packet storm. Fix this by failing closed in ip_rt_send_redirect(), ip6_forward(), and ndisc_send_redirect() when peer is NULL. Fixes: 92d868292634 ("inetpeer: Move ICMP rate limiting state into inet_peer entries.") Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260724072901.1633601-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 70ad543ce81f368411b6c721265a3b2d7ab4fda4 Author: Guenter Roeck Date: Mon Jul 27 09:54:23 2026 -0700 hwmon: (nzxt-smart2) DMA-align output buffer [ Upstream commit 080bbf42faf77e6489ab30d5114c5f8f6ccbb1b8 ] Sashiko reports: When send_output_report() calls hid_hw_output_report(), the underlying USB HID core calls usb_interrupt_msg() which maps this buffer directly for DMA. When the DMA mapping flushes or invalidates the cacheline, it will corrupt the adjacent variables (mutex, update_interval) that were modified concurrently by the CPU. This causes memory corruption due to cacheline sharing on non-coherent CPU architectures (such as ARM or MIPS). The DMA API debugging tool (CONFIG_DMA_API_DEBUG) will trigger runtime warnings for this violation. Any operation that triggers send_output_report() (like setting a fan speed or updating the interval) causes the USB DMA mapping. On systems with non-coherent caches, this structural bug causes immediate and deterministic memory corruption. Align the output buffer to ARCH_DMA_MINALIGN to fix the problem. Reported-by: Sashiko Fixes: 53e68c20aeb1 ("hwmon: add driver for NZXT RGB&Fan Controller/Smart Device v2.") Cc: Aleksandr Mezin Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 4eed33c7db5c0c573928d28d8a2c003642c679b8 Author: Guenter Roeck Date: Sat Jul 25 15:27:28 2026 -0700 hwmon: (lm90) Only report alarms if driver is ready [ Upstream commit aa9429edf9fc0e90d6f4da19ea4b5495a54ab117 ] Userspace can read sysfs attributes before driver registration is complete, immediately after devm_hwmon_device_register_with_info() has been called. At that time, data->hwmon_dev is not yet initialized. This can trigger a NULL pointer access since lm90_update_device() and with it lm90_update_alarms_locked() will be called. This call schedules report_work and lm90_report_alarms(), which passes the still-NULL data->hwmon_dev to hwmon_notify_event() and triggers a NULL pointer dereference. Fix the problem by only scheduling the report and alert workers data->hwmon_dev is set. Reported-by: Sashiko Fixes: f6d0775119fb9 ("hwmon: (lm90) Rework alarm/status handling") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9a87dfaa05c3c9d3a4cdb7eafc1ab4abc84f6eef Author: Guenter Roeck Date: Wed Jul 22 07:14:36 2026 -0700 hwmon: (nct6775-core) Fix number of temperature registers for NCT6116 [ Upstream commit b0e8adb2ccb43009796897ced09f91636685c9d3 ] Unlike NCT6106, NCT6116 only has three temperature registers, and with it only three temperature source and temperature source configuration registers. The register addresses match those of NCT6106 and can be re-used. The code used a separate array to list the temperature source registers for NCT6116, but used the size of the NCT6106 register array to set the number of registers. The NCT6106 register array provides six addresses, while the temperature source register array for NCT6116 only provides three addresses. This causes a KASAN report. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x936/0x46f0 [nct6775] Read of size 2 at addr ffffffffc19561a6 by task modprobe/954 ... Call Trace: dump_stack+0x7d/0xa7 print_address_description.constprop.0+0x1c/0x220 ? __kasan_kmalloc.constprop.0+0xc9/0xd0 ? __kmalloc_node_track_caller+0x194/0x5b0 ? nct6775_probe+0x936/0x46f0 [nct6775] ? nct6775_probe+0x936/0x46f0 [nct6775] ... Fix the problem by hard-coding the number of temperature and temperature configuration registers to three for NCT6116. Drop the unnecessary NCT6116_REG_TEMP_SOURCE array and re-use NCT6106_REG_TEMP_SOURCE. Reported-by: Florian Bezdeka Closes: https://lore.kernel.org/linux-hwmon/57cfc3fa-d4e9-4c10-8aa7-4ad0af7ebebe@roeck-us.net/T/#t Fixes: 29c7cb485b32 ("hwmon: (nct6775) Integrate new model nct6116") Cc: Björn Gerhart Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit a7b05d5eefc3730ea3c35123086679c37e10053f Author: Srikanth Boyapally Date: Mon Jul 20 18:25:10 2026 +0530 spi: spi-cadence: Move TX FIFO full busy-wait into FIFO [ Upstream commit d9eadfce2fac49445db40808fe4d8259f20a9d2b ] SPI host transfers could intermittently stall with spi_transfer timeouts. The TXFULL condition was checked only once in cdns_transfer_one() before cdns_spi_process_fifo(), so if the FIFO became full again during refill, writes could be dropped and the transfer would never complete. Move the TXFULL busy-wait into the TX path of cdns_spi_process_fifo() so the 10µs back-off is applied per FIFO entry during filling, ensuring forward progress and eliminating spurious timeouts. Restrict the delay to host mode using spi_controller_is_target(), the controller is passed into cdns_spi_process_fifo() so the check is made at the point of use. In target mode this delay must not run as it causes the target to miss its transfer window and corrupt data. Fixes: 49530e641178 ("spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()") Signed-off-by: Srikanth Boyapally Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260720125510.60166-1-srikanth.boyapally@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6b0fbc3fb7b71163393246f8ce774c7d2dc82c2c Author: Jun Guo Date: Fri Oct 31 15:30:02 2025 +0800 spi: spi-cadence: supports transmission with bits_per_word of 16 and 32 [ Upstream commit 4e00135b2dd1d7924a58bffa551b6ceb3bd836f2 ] The default FIFO data width of the Cadence SPI IP is 8 bits, but the hardware supports configurations of 16 bits and 32 bits. This patch enhances the driver to support communication with both 16-bits and 32-bits FIFO data widths. Signed-off-by: Jun Guo Link: https://patch.msgid.link/20251031073003.3289573-3-jun.guo@cixtech.com Signed-off-by: Mark Brown Stable-dep-of: d9eadfce2fac ("spi: spi-cadence: Move TX FIFO full busy-wait into FIFO") Signed-off-by: Sasha Levin commit 593636dcdf20eb072607217cafcb2ea1c5b40c3e Author: Dawei Feng Date: Sun Jun 28 14:59:09 2026 +0800 smb: client: fix buffer leaks in SMB1 read and write [ Upstream commit 6a3e16d60e81a4aa3056ab15617036cfbea2e07d ] CIFSSMBRead(), CIFSSMBWrite() and CIFSSMBWrite2() allocate a request buffer before checking whether tcon->ses->server is NULL. If that defensive check ever fails, the helper returns -ECONNABORTED without releasing the request buffer. Fix these leaks by releasing the allocated request buffer before returning from these error paths. Use cifs_small_buf_release() for the buffers allocated by small_smb_init() and cifs_buf_release() for the buffer allocated by smb_init(). The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. Runtime validation used a temporary fault-injection hook to force tcon->ses->server to NULL after request-buffer initialization. On the unfixed kernel, the harness observed two leaked small request buffers and one leaked large request buffer, with directed kmemleak dumps confirming the CIFS buffer allocation stacks. After the fix, no CIFS request-buffer deltas remained. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Dawei Feng Signed-off-by: Steve French Signed-off-by: Sasha Levin commit e50a6523a603594a6d92cdecfe11997d639410a3 Author: Xingui Yang Date: Thu Jul 16 16:11:45 2026 +0800 scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race [ Upstream commit 3dbbbf656b850c9c8de05df6ad4a1dfc6ff02845 ] Commit fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas returns from resume before all PHY UP work and libsas discovery work finish. The controller may then autosuspend while disks are still waking up. The disks issue IO to a suspended controller, the IO fails, and the disks get disabled. Fix the deadlock at its source by moving the PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in resume, any I/O to a timed-out phy's disk is immediately rejected by the LLDD before reaching hardware: isci returns SAS_DEVICE_UNKNOWN (mapped to DID_BAD_TARGET), and pm8001 returns SAS_PHY_DOWN (mapped to DID_NO_CONNECT). Both complete directly via scsi_done() without entering SCSI EH. This is identical in both the old and new ordering since lldd_dev_gone runs during suspend, before resume. The reorder only affects when the PHYE_RESUME_TIMEOUT handler runs (synchronized by sas_drain_work() vs. asynchronous after resume returns), not whether I/O can reach the device. aic94xx and mvsas do not register any PM ops and never reach this code path. Fixes: fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume") Signed-off-by: Xingui Yang Reviewed-by: John Garry Link: https://patch.msgid.link/20260716081145.3950172-1-yangxingui@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c97b5265cc47775f77fd2a23d6bde0426997b233 Author: HyeongJun An Date: Thu Jul 16 15:58:48 2026 +0900 scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer [ Upstream commit c1dea15f819cded9b3faf58f8bec72323568b6e6 ] iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check. Fixes: a081c13e39b5 ("[SCSI] iscsi_tcp: split module into lib and lld") Suggested-by: Chris Leech Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Acked-by: Chris Leech Link: https://patch.msgid.link/20260716065848.1653431-1-sammiee5311@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7567f06abdefb1caf2d836107c4d08c5185c650e Author: HyeongJun An Date: Tue Jul 14 19:49:34 2026 +0900 scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer [ Upstream commit 98b87885de4b7f605533a2860685f5689fce8e82 ] iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: senselen = get_unaligned_be16(data); if (datalen < senselen) goto invalid_datalen; memcpy(sc->sense_buffer, data + 2, min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check. Fixes: 7996a778ff8c ("[SCSI] iscsi: add libiscsi") Suggested-by: Sashiko AI Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Acked-by: Chris Leech Link: https://patch.msgid.link/20260714104934.1404423-1-sammiee5311@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 870b4535f958a7d18558d6188e828963274ed526 Author: Mario Limonciello Date: Mon Jul 20 11:28:44 2026 -0500 pinctrl-amd: Don't clear S4 wake bits at probe [ Upstream commit ffe8a0c6b55285ceaf2f42fc20c3a0594d14f1e9 ] commit 6bc3462a0f5e ("pinctrl: amd: Mask wake bits on probe again") introduced a regression where Wake-on-LAN no longer works after suspend or shutdown on some AMD platforms. Firmware-programmed S4 wake bits for devices like PCIe NICs using PCI PME are cleared at probe, but nothing restores them. Unlike S0i3/S3 wake sources that use enable_irq_wake() -> amd_gpio_irq_set_wake(), PCIe PME does not use GPIO IRQ infrastructure and relies on firmware configuration. The original intent of commit 6bc3462a0f5e ("pinctrl: amd: Mask wake bits on probe again") was to clear spurious wake bits left by firmware to prevent unwanted wakeups. However, S4 wake bits are used for hardware-level wake sources like WoL that bypass the kernel's IRQ wake API. Fix by preserving S4 wake bits at probe and only clearing S0i3/S3 bits: - Firmware-configured S4 wake sources (WoL) continue working - Kernel maintains control of S3/S0i3 wake policy via set_wake() - S3-only wake sources work correctly per commit f31f33dbb3ba ("pinctrl: amd: Take suspend type into consideration which pins are non-wake") The trade-off is that firmware-programmed spurious S4 wake bits remain set, but this is less problematic than breaking WoL. Fixes: 6bc3462a0f5e ("pinctrl: amd: Mask wake bits on probe again") Signed-off-by: Mario Limonciello Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 76dd48886eeeb5fcf2b837d2f4c3d17eebeac9ef Author: Xiang Mei Date: Wed Jul 22 14:02:03 2026 -0700 rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() [ Upstream commit 78f75d632f74b8de0f081a128588f7c37d0d1164 ] rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fixes: eee2fa6ab322 ("rds: Changing IP address internal representation to struct in6_addr") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260722210203.565803-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8e48d7ab1e01936a172ff31531904b003895fd8c Author: Ilia Gavrilov Date: Thu Jul 9 16:27:54 2026 +0000 rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled [ Upstream commit 9c805e592a29be9e4e61ff1bd567da04aa8fd6f9 ] When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: eee2fa6ab322 ("rds: Changing IP address internal representation to struct in6_addr") Fixes: 1e2b44e78eea ("rds: Enable RDS IPv6 support") Signed-off-by: Ilia Gavrilov Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260709162723.367523-1-Ilia.Gavrilov@infotecs.ru Signed-off-by: Jakub Kicinski Stable-dep-of: 78f75d632f74 ("rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check()") Signed-off-by: Sasha Levin commit b19b5d2e042c294e2cc1c908dc598f9d64015396 Author: Xiang Mei (Microsoft) Date: Sun Jul 19 22:15:23 2026 +0000 netfilter: nft_payload: fix mask build for partial field offload [ Upstream commit 39e88f28fb32bf02bd4b525c24c842c9cff5663d ] nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes. Fixes: a5d45bc0dc50 ("netfilter: nftables_offload: build mask based from the matching bytes") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 35c53f9b7839a1ddc930bb18a986dee217b0a407 Author: Julian Anastasov Date: Wed Jul 22 13:15:17 2026 +0300 ipvs: do not mangle ICMP replies for non-first fragments [ Upstream commit 342e24a339b90e8e339a0f8c151ca479b8565661 ] Sashiko warns that ip_vs_nat_icmp() unconditionally mangles the payload for embedded non-first IPv4 fragments. The problem is in the very old inverted pp->dont_defrag check which should not continue when embedded is a non-first TCP/UDP/SCTP fragment. Check for embedded non-first fragment is also missing from ip_vs_out_icmp_v6(), it is needed before any connection lookups that expect ports after the network headers. Drop the blocking code from ip_vs_in_icmp_v6() which prevents ICMPv6 from local clients to use non-MASQ forwarding. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://sashiko.dev/#/patchset/20260720201122.79882-1-ja%40ssi.bg Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit cdc55d6ca3a8fc96417905c80ad9149ef0c60579 Author: Julian Anastasov Date: Wed Jul 22 13:15:16 2026 +0300 ipvs: fix places with wrong packet offsets [ Upstream commit 15cab31a3730e05f0767b922a7450e5d784b2607 ] The offsets we use to packet headers and payloads should be based on skb->data. We even already respect non-zero network offset in ip_vs_fill_iph_skb() but some places do it wrongly and support only zero offset which is expected for the IP layer where IPVS has hooks. Change all places that instead of skb->data use offsets based on the network header (skb_network_header, ip_hdr, etc) because this doubles the network offset as noted by Sashiko. For ip_vs_nat_icmp_v6() we can even rely on the IPv6 header parsing done by the caller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://sashiko.dev/#/patchset/20260710143733.29741-2-fw%40strlen.de Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit b3869d9b54e76dff64118dee4c8fd9302fcd5171 Author: Julian Anastasov Date: Wed Jul 22 13:15:15 2026 +0300 ipvs: fix the checksum validations [ Upstream commit e876b75b9020a97bbdc79721e7fc749024891c65 ] ip_vs_in_icmp_v6() is missing checksum validation for ICMPv6 packets from clients. In fact, as for TCP/UDP we should validate the checksum for ICMP packets only when we mangle the packets on MASQ or on reply for tunnel. Also, Sashiko points out that handle_response_icmp() being common for IPv4 and IPv6 is missing the pseudo-header calculation while validating ICMPv6 messages from real servers which is a problem if checksum is not validated by the hardware. Fix the problems by creating ip_vs_checksum_common_check() helper and use it for TCP/UDP/ICMP both for IPv4 and IPv6. Rely on the nf_checksum() for validating the ICMP messages but use it also for TCP and UDP. Use correct IP offset for IP_VS_DBG_RL_PKT for TCP/UDP/SCTP. IPVS packets (TCP/UDP/SCTP/ICMP) do not need checksum validation on LOCAL_OUT (local clients or local real servers) and on FORWARD (traffic from servers on LAN). Do it only on LOCAL_IN, in case nf_checksum() is not called on PRE_ROUTING. Also, ip_vs_checksum_complete() can be marked static. Fixes: 2a3b791e6e11 ("IPVS: Add/adjust Netfilter hook functions and helpers for v6") Link: https://sashiko.dev/#/patchset/20260708180315.77413-1-ja%40ssi.bg Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d1c4acc119ea008a31cc1bb7e0b833a925156d32 Author: Kent Overstreet Date: Wed Oct 16 15:03:50 2019 -0400 sched: Add task_struct->faults_disabled_mapping [ Upstream commit 2b69987be575b92adb6c177679f3c559134f0d8f ] There has been a long standing page cache coherence bug with direct IO. This provides part of a mechanism to fix it, currently just used by bcachefs but potentially worth promoting to the VFS. Direct IO evicts the range of the pagecache being read or written to. For reads, we need dirty pages to be written to disk, so that the read doesn't return stale data. For writes, we need to evict that range of the pagecache so that it's not stale after the write completes. However, without a locking mechanism to prevent those pages from being re-added to the pagecache - by a buffered read or page fault - page cache inconsistency is still possible. This isn't necessarily just an issue for userspace when they're playing games; filesystems may hang arbitrary state off the pagecache, and so page cache inconsistency may cause real filesystem bugs, depending on the filesystem. This is less of an issue for iomap based filesystems, but e.g. buffer heads caches disk block mappings (!) and attaches them to the pagecache, and bcachefs attaches disk reservations to pagecache pages. This issue has been hard to fix, because - we need to add a lock (henceforth called pagecache_add_lock), which would be held for the duration of the direct IO - page faults add pages to the page cache, thus need to take the same lock - dio -> gup -> page fault thus can deadlock And we cannot enforce a lock ordering with this lock, since userspace will be controlling the lock ordering (via the fd and buffer arguments to direct IOs), so we need a different method of deadlock avoidance. We need to tell the page fault handler that we're already holding a pagecache_add_lock, and since plumbing it through the entire gup() path would be highly impractical this adds a field to task_struct. Then the full method is: - in the dio path, when we first take the pagecache_add_lock, note the mapping in the current task_struct - in the page fault handler, if faults_disabled_mapping is set, we check if it's the same mapping as the one we're taking a page fault for, and if so return an error. Then we check lock ordering: if there's a lock ordering violation and trylock fails, we'll have to cycle the locks and return an error that tells the DIO path to retry: faults_disabled_mapping is also used for signalling "locks were dropped, please retry". Also relevant to this patch: mapping->invalidate_lock. mapping->invalidate_lock provides most of the required semantics - it's used by truncate/fallocate to block pages being added to the pagecache. However, since it's a rwsem, direct IOs would need to take the write side in order to block page cache adds, and would then be exclusive with each other - we'll need a new type of lock to pair with this approach. Signed-off-by: Kent Overstreet Cc: Jan Kara Cc: Darrick J. Wong Cc: linux-fsdevel@vger.kernel.org Cc: Andreas Grünbacher Stable-dep-of: e876b75b9020 ("ipvs: fix the checksum validations") Signed-off-by: Sasha Levin commit 24683fea1f06bd3bd2707b99460e859bc6464c22 Author: Pablo Neira Ayuso Date: Tue Jul 21 22:02:46 2026 +0200 netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH [ Upstream commit 305b63e1402267459fdabb183af4527f6799eebf ] The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too. Fixes: bea74641e378 ("netfilter: xt_hashlimit: add rate match mode") Reported-and-tested-by: Talha Berk Arslan Link: https://patch.msgid.link/20260721074629.668-1-talha.anything.info@gmail.com/ Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 55fb23f8bd7445264ceeb2c2ebe06f82e7fcb4bc Author: Michael Bommarito Date: Sun Jul 19 12:15:05 2026 -0400 assoc_array: trim the final shortcut word using the current chunk end [ Upstream commit a82c8a05e86f3f84e09698f65b4515b5d04633f6 ] assoc_array_walk() masks off the bits past shortcut->skip_to_level in the word that contains skip_to_level, gated on round_up(sc_level, ASSOC_ARRAY_KEY_CHUNK_SIZE) > skip_to_level. That guard is wrong in two opposite ways: - When sc_level is word-aligned (every word after the first) round_up() is a no-op, so the guard is sc_level > skip_to_level and never fires for the word that holds skip_to_level. A shortcut that spans more than one word and ends in the middle of its last word leaves that word untrimmed, and its stale high bits leak into the dissimilarity word and can steer the walk down the wrong descendant. - When sc_level is unaligned (the first word) and skip_to_level sits on the next chunk boundary, sc_level + CHUNK would exceed skip_to_level and fire the trim with shift = skip_to_level & CHUNK_MASK == 0, which clears the whole dissimilarity word and makes a differing shortcut compare equal. Use the end of the chunk that contains sc_level instead: skip_to_level < round_down(sc_level, CHUNK) + CHUNK For an aligned sc_level whose word holds skip_to_level this now fires (the first bug); for an unaligned sc_level with skip_to_level on the following boundary it does not, so shift is never 0 when the branch runs and the trim never clears the whole word. Fixes: 3cb989501c26 ("Add a generic associative array implementation.") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260719161505.2423935-4-michael.bommarito@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit bd0f976ef89dce6db458bf75bc2cf51127becc41 Author: Michael Bommarito Date: Sun Jul 19 12:15:04 2026 -0400 keys: make keyring key-chunk byte order agree with keyring_diff_objects() [ Upstream commit 58565eef0f8d861aae92abfb7658458d661cee17 ] keyring_get_key_chunk() loads description bytes into the index chunk low address first, while keyring_diff_objects() numbers the first differing bit from the low end and folds the absolute byte index into the level without removing the inline-prefix offset the level already carries. The two disagree on byte order and bit position, so the array can be told two keys first differ at a bit that does not differ in the chunk the walker uses, letting crafted descriptions collide into one node. Load the chunk in the order keyring_diff_objects() assumes and drop the inline-prefix length when folding the byte index into the level. This only changes the in-memory ordering used to place keys within a keyring; add, search and read of non-colliding keys are unaffected. Fixes: f771fde82051 ("keys: Simplify key description management") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260719161505.2423935-3-michael.bommarito@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit d1933e03e8c74a018550c31a393b79c4d95bff40 Author: Michael Bommarito Date: Sun Jul 19 12:15:03 2026 -0400 keys: fix out-of-bounds read in keyring_get_key_chunk() [ Upstream commit 63918731f9ae25b5deb022f118e941e6dddfcef4 ] For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read. Fixes: f771fde82051 ("keys: Simplify key description management") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260719161505.2423935-2-michael.bommarito@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit c28d2ae71b7069bf0664c1bce5f8350ccc7c7166 Author: Ruoyu Wang Date: Tue Jul 7 23:05:28 2026 +0800 drm/mediatek: Check CRTC state before freeing [ Upstream commit 233a4d3a39fc1585f5e271b2adab43c6af025ae0 ] mtk_crtc_reset() destroys the current CRTC state only when crtc->state is non-NULL, but it always converts crtc->state to struct mtk_crtc_state and passes the result to kfree(). When reset is called without an existing state, container_of(NULL, ...) does not produce NULL. Keep the mtk state free in the same crtc->state guard as the helper state destruction. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 2d267b81898e ("drm/mtk: Use __drm_atomic_helper_crtc_reset") Signed-off-by: Ruoyu Wang Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260707150528.2270739-1-ruoyuw560@gmail.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 63eea41759fd682229c14e0a2205802b46d106f3 Author: Xiang Mei Date: Sun Jul 12 16:42:01 2026 -0700 netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() [ Upstream commit db3d0e0e5d4bc5ab4fe445b9f413d1b486508ca5 ] sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and "datalen = datalen + diff - msglen" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ... Fixes: f5b321bd37fb ("netfilter: nf_conntrack_sip: add TCP support") Reported-by: Weiming Shi Link: https://patch.msgid.link/netfilter-devel/20260712234201.3213635-1-xmei5@asu.edu Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8bba4129dc5c0488453c09bc437ac1463d30275f Author: Radhey Shyam Pandey Date: Mon Jul 20 21:08:31 2026 +0530 phy: zynqmp: fix runtime PM leak on probe allocation failure [ Upstream commit f3506e15cf72e94f62d5f2d173e5b7008f644cde ] Allocate saved_regs before pm_runtime_resume_and_get() so a devm_kmalloc() failure does not leave an unreleased runtime PM usage counter. Fixes: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume") Signed-off-by: Radhey Shyam Pandey Reviewed-by: Michal Simek Link: https://patch.msgid.link/20260720153832.1130006-3-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 599516163bb3341fb338eb33501dddd063651a99 Author: Radhey Shyam Pandey Date: Mon Jul 20 21:08:30 2026 +0530 phy: zynqmp: fix clock error handling in xpsgtr_phy_init() [ Upstream commit e4779e2a16d600892aaf743438f6ce8cc4eb3c4c ] Propagate clk_prepare_enable() failures to the caller instead of returning success, and disable the reference clock on initialization error paths to avoid leaking clock references when phy_exit() is not called. Fixes: 25d700833513 ("phy: xilinx: phy-zynqmp: dynamic clock support for power-save") Signed-off-by: Radhey Shyam Pandey Reviewed-by: Michal Simek Link: https://patch.msgid.link/20260720153832.1130006-2-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit badff0ff5b20a07246ac729e2803ba333eaedd9f Author: Mike Looijmans Date: Mon Apr 28 08:35:47 2025 +0200 phy-zynqmp: Postpone getting clock rate until actually needed [ Upstream commit 065d5885f6180c534b7b176847b3e008f4e11850 ] At probe time the driver would display the following error and abort: xilinx-psgtr fd400000.phy: Invalid rate 0 for reference clock 0 At probe time, the associated GTR driver (e.g. SATA or PCIe) hasn't initialized the clock yet, so clk_get_rate() likely returns 0 if the clock is programmable. So this driver only works if the clock is fixed. The PHY driver doesn't need to know the clock frequency at probe yet, so wait until the associated driver initializes the lane before requesting the clock rate setting. In addition to allowing the driver to be used with programmable clocks, this also reduces the driver's runtime memory footprint by removing an array of pointers from struct xpsgtr_phy. Signed-off-by: Mike Looijmans Acked-by: Michal Simek Link: https://lore.kernel.org/r/20250428063648.22034-1-mike.looijmans@topic.nl Signed-off-by: Vinod Koul Stable-dep-of: e4779e2a16d6 ("phy: zynqmp: fix clock error handling in xpsgtr_phy_init()") Signed-off-by: Sasha Levin commit 18577e77c2c8adaadf1f7c6e9bcd1c0b14e5dcdd Author: Johannes Thumshirn Date: Fri Jul 3 07:54:40 2026 +0200 btrfs: zoned: fix deadlock between metadata writeback and transaction commit [ Upstream commit 1ebe51c29fa9755d5b2fea28727c051117907cf8 ] When writing out metadata extent buffers in a zoned filesystem, btree_writepages() holds fs_info->zoned_meta_io_lock across the whole writeback loop, including the call to btrfs_check_meta_write_pointer() -> check_bg_is_active(). For the tree-log block group, check_bg_is_active() may fail to activate the zone and fall back to btrfs_zone_finish_one_bg() to free an active zone. That path waits for the running transaction to commit while still holding zoned_meta_io_lock, but the committer needs that same lock to write out the tree extents, so the two tasks deadlock: Task A (kworker, metadata writeback) Task B (fsstress, transaction commit) ------------------------------------ ------------------------------------- wb_workfn() btrfs_commit_transaction(T) btree_writepages() btrfs_write_and_wait_transaction() btrfs_zoned_meta_io_lock() btrfs_write_marked_extents() btrfs_check_meta_write_pointer() btree_writepages() check_bg_is_active() [treelog_bg] btrfs_zoned_meta_io_lock() btrfs_zone_finish_one_bg() do_zone_finish() btrfs_inc_block_group_ro() btrfs_wait_for_commit() The sibling branch in check_bg_is_active() already drops zoned_meta_io_lock around do_zone_finish() for this exact reason. Do the same in the tree-log branch: release the lock around btrfs_zone_finish_one_bg() and re-acquire it afterwards. The lock only protects fs_info->active_{meta,system}_bg, which this branch does not touch, and ctx->zoned_bg keeps a reference to the block group across the unlock, so nothing is lost while the lock is dropped. This hang occasionally reproduces with fstests generic/475 on a zoned btrfs filesystem. Fixes: 13bb483d32ab ("btrfs: zoned: activate metadata block group on write time") Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c031ef8093f41cb3c1de929981454b99f34bdc34 Author: Uday Khare Date: Mon Jul 20 16:12:54 2026 +0530 ASoC: max98090: fix missing IS_ERR() before PTR_ERR() on mclk lookup [ Upstream commit a792ce0fad61a70793ec565743f11d6ca534de59 ] In max98090_probe(), the -EPROBE_DEFER check after devm_clk_get() is broken due to a missing IS_ERR() guard. The code intends to return -EPROBE_DEFER only when the clock lookup fails with that specific error. However, without IS_ERR() the check: if (PTR_ERR(max98090->mclk) == -EPROBE_DEFER) is called unconditionally, including when devm_clk_get() succeeds and returns a valid pointer. Calling PTR_ERR() on a valid pointer reinterprets its address as a signed long; the result is arbitrary and is almost never equal to -EPROBE_DEFER, so the check silently does nothing in the success case. When devm_clk_get() fails with any error other than -EPROBE_DEFER the check is also skipped, leaving max98090->mclk holding an error pointer with no indication to the caller. This means a deferred probe will never actually be triggered for this device, and any non-EPROBE_DEFER clock error is silently swallowed with the error pointer left in the mclk field. Fix this by adding the missing IS_ERR() guard around the PTR_ERR() call, matching the pattern already used in the sibling max98088 and wm8960 drivers. Fixes: b10ab7b838bd ("ASoC: max98090: Add master clock handling") Signed-off-by: Uday Khare Link: https://patch.msgid.link/20260720104254.14948-1-udaykhare77@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b6f1706afb59f92c44131d351b8de2516ceb1115 Author: Uday Khare Date: Mon Jul 20 16:09:50 2026 +0530 ASoC: max98095: fix missing IS_ERR() before PTR_ERR() on mclk lookup [ Upstream commit 317e21532e6ffa1de026bdbce5ba98e1b70ca5c6 ] In max98095_probe(), the -EPROBE_DEFER check after devm_clk_get() is broken due to a missing IS_ERR() guard. The code intends to return -EPROBE_DEFER only when the clock lookup fails with that specific error. However, without IS_ERR() the check: if (PTR_ERR(max98095->mclk) == -EPROBE_DEFER) is called unconditionally, including when devm_clk_get() succeeds and returns a valid pointer. Calling PTR_ERR() on a valid pointer reinterprets its address as a signed long; the result is arbitrary and is almost never equal to -EPROBE_DEFER, so the check silently does nothing in the success case. When devm_clk_get() fails with any error other than -EPROBE_DEFER the check is also skipped, leaving max98095->mclk holding an error pointer with no indication to the caller. This means a deferred probe will never actually be triggered for this device, and any non-EPROBE_DEFER clock error is silently swallowed with the error pointer left in the mclk field. Fix this by adding the missing IS_ERR() guard around the PTR_ERR() call, matching the pattern already used in the sibling max98088 and wm8960 drivers. Fixes: e3048c3d2be5 ("ASoC: max98095: Add master clock handling") Signed-off-by: Uday Khare Link: https://patch.msgid.link/20260720103950.14474-1-udaykhare77@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c1fadd611cc588a7f4ca49111dbb317b42ff30f9 Author: Radhey Shyam Pandey Date: Fri Jul 17 23:55:26 2026 +0530 ata: ahci_ceva: fix error paths in ceva_ahci_platform_enable_resources() [ Upstream commit 4d99a91574c420decab56cc880fad0dc15b8a7a3 ] On phy_init() failure the error path fallsthrough to disable_rsts, which deasserts the controller reset and then enters disable_phys calling phy_power_off() on PHYs that were never powered on. That corrupts the PHY power_count and triggers an extra runtime PM put. Use a separate exit_phys path that unwinds with phy_exit() only and falls through to disable_clks while the controller remains in reset. Reserve phy_power_off() for the phy_power_on() failure path only, and skip masked-out ports in both unwind loops. On phy_power_on() failure re-assert the controller reset before disabling clocks and regulators, matching the teardown order used by ahci_platform_enable_resources() and ahci_platform_disable_resources(). Fixes: 26c8404e162b ("ata: ahci_ceva: fix error handling for Xilinx GT PHY support") Signed-off-by: Radhey Shyam Pandey Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 55f3fc9c544c76c7b44cd5b1e03e853ea138dc8f Author: Damien Le Moal Date: Mon Jan 6 14:14:47 2025 +0900 ahci: Introduce ahci_ignore_port() helper [ Upstream commit c9b5be909e6595547ed5d45aef39fd65948aa342 ] libahci and AHCI drivers may ignore some ports if the port is invalid (its ID does not correspond to a valid physical port) or if the user explicitly requested the port to be ignored with the mask_port_map ahci module parameter. Such port that shall be ignored can be identified by checking that the bit corresponding to the port ID is not set in the mask_port_map field of struct ahci_host_priv. E.g. code such as: "if (!(hpriv->mask_port_map & (1 << portid)))". Replace all direct use of the mask_port_map field to detect such port with the new helper inline function ahci_ignore_port() to make the code more readable/easier to understand. The comment describing the mask_port_map field of struct ahci_host_priv is also updated to be more accurate. Signed-off-by: Damien Le Moal Reviewed-by: Niklas Cassel Stable-dep-of: 4d99a91574c4 ("ata: ahci_ceva: fix error paths in ceva_ahci_platform_enable_resources()") Signed-off-by: Sasha Levin commit e43eb5d7cedf3f2a829e708ab8fc6112f67f5b47 Author: Josua Mayer Date: Wed Jan 1 13:13:33 2025 +0100 ata: libahci_platform: support non-consecutive port numbers [ Upstream commit 8c87215dd3a2c814dcffc0bafe8c80c8f98f2574 ] So far ahci_platform relied on number of child nodes in firmware to allocate arrays and expected port numbers to start from 0 without holes. This number of ports is then set in private structure for use when configuring phys and regulators. Some platforms may not use every port of an ahci controller. E.g. SolidRUN CN9130 Clearfog uses only port 1 but not port 0, leading to the following errors during boot: [ 1.719476] ahci f2540000.sata: invalid port number 1 [ 1.724562] ahci f2540000.sata: No port enabled Update all accessesors of ahci_host_priv phys and target_pwrs arrays to support holes. Access is gated by hpriv->mask_port_map which has a bit set for each enabled port. Update ahci_platform_get_resources to ignore holes in the port numbers and enable ports defined in firmware by their reg property only. When firmware does not define children it is assumed that there is exactly one port, using index 0. Signed-off-by: Josua Mayer Reviewed-by: Hans de Goede Signed-off-by: Damien Le Moal Stable-dep-of: 4d99a91574c4 ("ata: ahci_ceva: fix error paths in ceva_ahci_platform_enable_resources()") Signed-off-by: Sasha Levin commit ee53aae5d7d319f8cb3ee37bd2a1c8eb83f13264 Author: Rosen Penev Date: Sun Jul 12 15:31:37 2026 -0700 ata: sata_mv: accept 1 or 2 resources in platform probe [ Upstream commit ef19a9cf037957fe3a35df8355c76ff0a63a0436 ] Board files in arch/arm/plat-orion, arch/arm/mach-dove, arch/arm/mach-mv78xx0 and arch/arm/mach-orion5x still register the "sata_mv" device with two resources (IORESOURCE_MEM plus IORESOURCE_IRQ). Those devices are rejected with -EINVAL, so SATA no longer probes on legacy Marvell Orion/Kirkwood-style boards. Accept both 1 resource (DT, IRQ fetched via platform_get_irq()) and 2 resources (legacy, IRQ supplied as a second resource) so both probing paths work. Fixes: b3b2bec9646e ("ata: sata_mv: Fixes expected number of resources now IRQs are gone") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 778ccbded2c8749c5be7f0dfa04fc9977a36fb7e Author: Yuho Choi Date: Mon May 25 10:15:50 2026 -0400 dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open() [ Upstream commit ee1d7274102285d78a53161fc705a8d8cd40b066 ] The failed_dev_add and failed_dev_name paths drop the file-device reference while wq->wq_lock is still held. If put_device(fdev) drops the last reference, idxd_file_dev_release() runs synchronously and tries to take wq->wq_lock again, deadlocking. Those paths also fall through into the later ctx cleanup labels even though idxd_file_dev_release() owns that cleanup and frees ctx. This can make idxd_xa_pasid_remove(ctx) and kfree(ctx) operate on a freed context. Move idxd_wq_get() before file-device setup can fail, since the release callback always calls idxd_wq_put(). Then unlock wq->wq_lock before put_device(fdev) and return directly from the file-device setup failure path, leaving ctx cleanup to the release callback. Fixes: e6fd6d7e5f0fe ("dmaengine: idxd: add a device to represent the file opened") Signed-off-by: Yuho Choi Reviewed-by: Dave Jiang Acked-by: Vinicius Costa Gomes Link: https://patch.msgid.link/20260525141550.1385581-1-dbgh9129@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 27806fe7b9701af0963dcd510e30e7d0cc314c43 Author: Hongling Zeng Date: Wed Jul 1 12:57:33 2026 +0800 dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA [ Upstream commit ab1150115e68a46b687eb38c1ab92782018c9f2c ] When terminating DMA transfers, active descriptors are not properly reclaimed. Only cyclic descriptors were handled, leaving non-cyclic descriptors and their LLI chains to be permanently leaked. Fix by using vchan_terminate_vdesc() which handles both cyclic and non-cyclic descriptors by adding them to desc_terminated queue for proper cleanup. Add pchan->desc != pchan->done check to prevent double-adding completed descriptors, which would corrupt the list. Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller") Signed-off-by: Hongling Zeng Acked-by: Jernej Skrabec Suggested-by: Frank Li Reviewed-by: Frank Li Link: https://patch.msgid.link/20260701045733.33654-1-zenghongling@kylinos.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9ae18a4b22ac398bff7124302a7bc5cacef32b33 Author: Konrad Dybcio Date: Fri Jun 26 15:08:05 2026 +0200 pinctrl: qcom: sc8280xp: Add missing wakeup entries for GPIO143/151 [ Upstream commit 437a8d2aa1aa442c4a176fdf4700a9b3bb0c8794 ] Pins 143 and 151 were not included in the PDC wakeup map. They are normally used for PCIe2A and PCIe3a PERST# respectively, so they're unlikely to be excercised in practice, but still add them for the sake of completeness. Fixes: c0e4c71a9e7c ("pinctrl: qcom: Introduce sc8280xp TLMM driver") Signed-off-by: Konrad Dybcio Link: https://patch.msgid.link/20260626-topic-8280_pinctrl_wakeup-v1-1-2ccb267148f5@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 91b40862a02000f490b63f1d315be3ee31e83871 Author: Michael Bommarito Date: Wed May 27 07:46:04 2026 -0400 thunderbolt: Prevent XDomain delayed work use-after-free on disconnect [ Upstream commit 2c5d2d3c3f70cde2565d7b279b544893a2035842 ] tb_xdp_handle_request() runs on system_wq and queues xd->state_work via queue_delayed_work() in three request handlers: PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake), and LINK_STATE_CHANGE_REQUEST. Similarly, update_xdomain() queues xd->properties_changed_work when local properties change. Concurrently, tb_xdomain_remove() calls stop_handshake() which does cancel_delayed_work_sync() on both delayed works. Later, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain. Since commit 559c1e1e0134 ("thunderbolt: Run tb_xdp_handle_request() in system workqueue") moved the request handler off tb->wq, the handler and the remove path are no longer serialized. If queue_delayed_work() executes after cancel_delayed_work_sync() but before the xdomain is freed, the delayed work fires on a freed object. Add xd->removing that tb_xdomain_remove() sets under xd->lock before calling stop_handshake(). Each external queue site holds the same lock and checks removing before calling queue_delayed_work(). This provides the mutual exclusion needed: either the queue site acquires the lock first and queues work that the subsequent cancel will see, or the remove path acquires the lock first and the queue site observes removing == true and skips the queue. Fixes: 559c1e1e0134 ("thunderbolt: Run tb_xdp_handle_request() in system workqueue") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 35283a7b3468cf24aa73c3f6193d5ecd39aaeb34 Author: Harshal Dev Date: Thu Apr 16 17:29:19 2026 +0530 soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE [ Upstream commit 0d5dc5818191b55e4364d04b1b898a14a2ccac38 ] Since Qualcomm inline-crypto engine (ICE) is now a dedicated driver de-coupled from the QCOM UFS driver, it explicitly votes for its required clocks during probe. For scenarios where the 'clk_ignore_unused' flag is not passed on the kernel command line, to avoid potential unclocked ICE hardware register access during probe the ICE driver should additionally vote on the 'iface' clock. Also update the suspend and resume callbacks to handle un-voting and voting on the 'iface' clock. Fixes: 2afbf43a4aec6 ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver") Reviewed-by: Manivannan Sadhasivam Reviewed-by: Kuldeep Singh Reviewed-by: Konrad Dybcio Signed-off-by: Harshal Dev Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-2-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1c8c6ac4d9f7d7419b55a1501e3852e3c7bae885 Author: Benjamin Tissoires Date: Fri Apr 10 16:03:07 2026 +0200 HID: logitech-dj: fix wrong detection of bad DJ_SHORT output report [ Upstream commit 8b9a097eb2fc37b486afd81388c693bf3ab44466 ] commit b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write") assumed that all HID devices attached to the logitech-dj driver was having an output report of DJ_SHORT. However, on the receiver itself, we have 2 other HID device we attach here: the mouse emulation and the keyboard emulation. For those devices the value of rep is NULL and we are triggered a segfault here. This is doubly required because logitech-dj also handles non DJ devices that might not have the DJ collection. Fixes: b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write") Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 968e84f5c0dca4960580d174500e4bbf0c45dc15 Author: Lee Jones Date: Tue Mar 24 14:36:44 2026 +0000 HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write [ Upstream commit b6a57912854e7ea36f3b270032661140cc4209cd ] logi_dj_recv_send_report() assumes that all incoming REPORT_ID_DJ_SHORT reports are 14 Bytes (DJREPORT_SHORT_LENGTH - 1) long. It uses that assumption to load the associated field's 'value' array with 14 Bytes of data. However, if a malicious user only sends say 1 Byte of data, 'report_count' will be 1 and only 1 Byte of memory will be allocated to the 'value' Byte array. When we come to populate 'value[1-13]' we will experience an OOB write. Signed-off-by: Lee Jones Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b802ff2a0467dbcff6d2513e8fc14fe2bd5ec76e Author: Lee Jones Date: Tue Mar 24 14:36:43 2026 +0000 HID: logitech-dj: Standardise hid_report_enum variable nomenclature [ Upstream commit a940aee176437046598dfc786b719bd96db3c74c ] Since we will need to differentiate between the two report_enum types soon, let's unify the naming conventions now to save confusion and/or unnecessary/unrelated changes in upcoming commits. {input,output}_report_enum is used in other places to let's conform. Signed-off-by: Lee Jones Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 299d5728a7312fdd02059b074aebbe4ebbd391e4 Author: Eddie Phillips Date: Fri Jul 31 08:59:25 2026 -0700 gve: fix Rx queue stall on alloc failure commit b65352a1bac64442ad95e64f385b40ccb9f1b0db upstream. When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet. Cc: stable@vger.kernel.org Fixes: 9b8dd5e5ea48 ("gve: DQO: Add RX path") Reviewed-by: Jordan Rhee Signed-off-by: Eddie Phillips Signed-off-by: Harshitha Ramamurthy Reviewed-by: Przemek Kitszel Link: https://patch.msgid.link/20260709211906.3322883-1-hramamurthy@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 95651461cf77cc6590fa08c87667717e5dcfa55d Author: Yehyeong Lee Date: Thu Jul 23 10:08:29 2026 +0900 net: mpls: initialize rtm_tos in mpls_getroute() [ Upstream commit 295dd295e2137e10e9a5b1891d97e0f08de76f03 ] mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos: r = nlmsg_data(nlh); r->rtm_family = AF_MPLS; r->rtm_dst_len = 20; r->rtm_src_len = 0; r->rtm_table = RT_TABLE_MAIN; r->rtm_type = RTN_UNICAST; r->rtm_scope = RT_SCOPE_UNIVERSE; r->rtm_protocol = rt->rt_protocol; r->rtm_flags = 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized (byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos) Fixes: 397fc9e5cefe ("mpls: route get support") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260723010830.289917-1-yhlee@isslab.korea.ac.kr Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 06a1273ce72138fbfa1685b9637d6e5440cec443 Author: Lorenzo Bianconi Date: Thu May 14 16:46:38 2026 +0200 netfilter: br_netfilter: Reallocate headroom if necessary in neigh_hh_bridge() [ Upstream commit b2870fc21601db9133bc70c48c603b487614fa3b ] neigh_hh_bridge() assumes the skb always has sufficient headroom to copy the aligned L2 header. This assumption can trigger the crash reported below using the following netfilter setup: $modprobe br_netfilter $sysctl -w net.bridge.bridge-nf-call-iptables=1 $root@OpenWrt:~# nft list ruleset table ip nat { chain prerouting { type nat hook prerouting priority dstnat; policy accept; ip daddr 192.168.83.123 dnat to 192.168.83.120 } } - iperf3 client (192.168.83.119) --> bridge (192.168.83.118) --> iperf3 server (192.168.83.120) the iperf3 client is sending packet for 192.168.83.123 to the bridge device. [ 1579.036575] Unable to handle kernel write to read-only memory at virtual address ffffff8004d76ffe [ 1579.045482] Mem abort info: [ 1579.048273] ESR = 0x000000009600004f [ 1579.052024] EC = 0x25: DABT (current EL), IL = 32 bits [ 1579.057363] SET = 0, FnV = 0 [ 1579.060417] EA = 0, S1PTW = 0 [ 1579.063550] FSC = 0x0f: level 3 permission fault [ 1579.068345] Data abort info: [ 1579.071224] ISV = 0, ISS = 0x0000004f, ISS2 = 0x00000000 [ 1579.076720] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 1579.081770] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1579.087092] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080dc4000 [ 1579.093794] [ffffff8004d76ffe] pgd=180000009ffff003, p4d=180000009ffff003, pud=180000009ffff003, pmd=180000009ffe3003, pte=0060000084d76787 [ 1579.106343] Internal error: Oops: 000000009600004f [#1] SMP [ 1579.193824] CPU: 0 UID: 0 PID: 235 Comm: napi/qdma_eth-3 Tainted: G O 6.12.57 #0 [ 1579.202614] Tainted: [O]=OOT_MODULE [ 1579.206102] Hardware name: Airoha AN7581 Evaluation Board (DT) [ 1579.211929] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1579.218889] pc : br_nf_pre_routing_finish_bridge+0x1ac/0xcc8 [br_netfilter] [ 1579.225859] lr : br_nf_pre_routing_finish_bridge+0x18c/0xcc8 [br_netfilter] [ 1579.232822] sp : ffffffc0817cba20 [ 1579.236128] x29: ffffffc0817cba20 x28: 0000000000000000 x27: ffffff8002b89000 [ 1579.243273] x26: ffffff8004d7700e x25: 0000000000000008 x24: 0000000000000000 [ 1579.250416] x23: ffffffc08179d4c0 x22: 0000000000000000 x21: ffffffc08179d4c0 [ 1579.257561] x20: ffffff8004d9b800 x19: ffffff8015010000 x18: 0000000000000014 [ 1579.264704] x17: ffffffbf9e930000 x16: ffffffc0817c8000 x15: 0000000000000070 [ 1579.271848] x14: 0000000000000080 x13: 0000000000000001 x12: 0000000000000000 [ 1579.278993] x11: ffffffc0798caae0 x10: ffffff8014db6fd8 x9 : 0000000000000000 [ 1579.286136] x8 : 0000000000000003 x7 : ffffffc08171f628 x6 : 000000001a3b83d3 [ 1579.293281] x5 : 0000000000000000 x4 : 1beb76f22fee0000 x3 : ffffff8004d7700e [ 1579.300425] x2 : 0000000000000000 x1 : ffffff8004d9b8bc x0 : ffffff80026ed000 [ 1579.307570] Call trace: [ 1579.310018] br_nf_pre_routing_finish_bridge+0x1ac/0xcc8 [br_netfilter] [ 1579.316632] br_nf_hook_thresh+0xd4/0x14bc [br_netfilter] [ 1579.322032] br_nf_hook_thresh+0x250/0x14bc [br_netfilter] [ 1579.327517] br_nf_hook_thresh+0x76c/0x14bc [br_netfilter] [ 1579.333003] br_handle_frame+0x180/0x480 [ 1579.336935] __netif_receive_skb_core.constprop.0+0x540/0xf40 [ 1579.342682] __netif_receive_skb_one_core+0x28/0x50 [ 1579.347561] process_backlog+0x98/0x1e0 [ 1579.351398] __napi_poll+0x34/0x1c4 [ 1579.354887] net_rx_action+0x178/0x330 [ 1579.358638] handle_softirqs+0x108/0x2d4 [ 1579.362560] __do_softirq+0x10/0x18 [ 1579.366051] ____do_softirq+0xc/0x20 [ 1579.369627] call_on_irq_stack+0x30/0x4c [ 1579.373550] do_softirq_own_stack+0x18/0x20 [ 1579.377734] do_softirq+0x4c/0x60 [ 1579.381050] __local_bh_enable_ip+0x88/0x98 [ 1579.385234] napi_threaded_poll_loop+0x188/0x21c [ 1579.389853] napi_threaded_poll+0x70/0x80 [ 1579.393863] kthread+0xd8/0xdc [ 1579.396918] ret_from_fork+0x10/0x20 [ 1579.400499] Code: 88dffc22 3707ffc2 f9406663 f9406684 (f81f0064) [ 1579.406589] ---[ end trace 0000000000000000 ]--- [ 1579.411209] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 1579.418083] SMP: stopping secondary CPUs [ 1579.422012] Kernel Offset: disabled Fix the issue reallocating the skb headroom if necessary in neigh_hh_bridge routine. Fixes: e179e6322ac33 ("netfilter: bridge-netfilter: Fix MAC header handling with IP DNAT") Reviewed-by: Ido Schimmel Signed-off-by: Lorenzo Bianconi Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit da1f7306c8f2806a8dd909896900025b6215491b Author: Pablo Neira Ayuso Date: Thu May 7 13:00:28 2026 +0200 netfilter: nf_conntrack_expect: restore helper propagation via expectation [ Upstream commit dcb0f9aefdd604d36710fda53c25bd7cf4a3e37a ] A recent series to fix expectations broke helper propagation via expectation, this mechanism is used by the sip and h323 helper. This also propagates the conntrack helper to expected connections. I changed semantics of exp->helper which now tells us the actual helper that created the expectation. Add an explicit assign_helper field to expectations for this purpose and update helpers to use it. Restore this feature for userspace conntrack helper via ctnetlink nfqueue integration so it is again possible to attach a helper to an expectation, where it makes sense. This is not restored via ctnetlink expectation creation as there is no client for such feature. Use the expectation layer 4 protocol number for the helper lookup for consistency. Make sure the expectation using this helper propagation mechanism also go away when the helper is unregistered. Fixes: 9c42bc9db90a ("netfilter: nf_conntrack_expect: honor expectation helper field") Fixes: 917b61fa2042 ("netfilter: ctnetlink: ignore explicit helper on new expectations") Reported-by: Ilya Maximets Tested-by: Ilya Maximets Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin