commit 7e98da22115d049ca74373caddd43e0952becfef Author: Greg Kroah-Hartman Date: Sat May 23 13:09:44 2026 +0200 Linux 7.0.10 Link: https://lore.kernel.org/r/20260520162148.390695140@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Brett A C Sheffield Tested-by: Salvatore Bonaccorso Tested-by: Justin M. Forbes Tested-by: Takeshi Ogasawara Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Luna Jernberg Tested-by: Barry K. Nathan Tested-by: Ron Economos Tested-by: Jeffrin Jose T Signed-off-by: Greg Kroah-Hartman commit e35cb8f4e8e9b6366a54d3e8ade0c03dfe0c0f0e Author: David Howells Date: Tue May 12 13:33:45 2026 +0100 netfs: Fix potential uninitialised var in netfs_extract_user_iter() commit 7e3d8db899d54af39fafb2eb3392b0cdae9973b5 upstream. In netfs_extract_user_iter(), if it's given a zero-length iterator, it will fall through the loop without setting ret, and so the error handling behaviour will be undefined, depending on whether ret happens to be negative. The value of ret then propagates back up the callstack. Fix this by presetting ret to 0. Fixes: 85dd2c8ff368 ("netfs: Add a function to extract a UBUF or IOVEC into a BVEC iterator") Closes: https://sashiko.dev/#/patchset/20260414082004.3756080-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-9-dhowells@redhat.com cc: Paulo Alcantara cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 968bccf387ba2b2d9d1b58b8937025a85576701b Author: Venkat Rao Bagalkote Date: Fri Apr 10 16:24:04 2026 +0530 selftests/bpf: Remove test_access_variable_array commit aacee214d57636fa1f63007c65f333b5ea75a7a0 upstream. test_access_variable_array relied on accessing struct sched_domain::span to validate variable-length array handling via BTF. Recent scheduler refactoring removed or hid this field, causing the test to fail to build. Given that this test depends on internal scheduler structures that are subject to refactoring, and equivalent variable-length array coverage already exists via bpf_testmod-based tests, remove test_access_variable_array entirely. Link: https://lore.kernel.org/all/177434340048.1647592.8586759362906719839.tip-bot2@tip-bot2/ Signed-off-by: Venkat Rao Bagalkote Tested-by: Naveen Kumar Thummalapenta Link: https://lore.kernel.org/r/20260410105404.91126-1-venkat88@linux.ibm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 9bc9d6d6967a2239aa57af2aa53554eddd640d20 Author: Hyunwoo Kim Date: Sat May 16 07:28:53 2026 +0900 net: skbuff: propagate shared-frag marker through frag-transfer helpers commit 48f6a5356a33dd78e7144ae1faef95ffc990aae0 upstream. Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to ' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently. The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker. Fixes: cef401de7be8 ("net: fix possible wrong checksum generation") Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Suggested-by: Sabrina Dubroca Suggested-by: Sultan Alsawaf Suggested-by: Ben Hutchings Suggested-by: Lin Ma Suggested-by: Jingguo Tan Suggested-by: Aaron Esau Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Tested-by: Rajat Gupta Link: https://patch.msgid.link/ageeJfJHwgzmKXbh@v4bel Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 3884358a9286b17f389a72b1426fc4547c23c111 Author: William Bowling Date: Wed May 13 04:16:35 2026 +0000 net: skbuff: preserve shared-frag marker during coalescing commit f84eca5817390257cef78013d0112481c503b4a3 upstream. skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors. Fixes: cef401de7be8 ("net: fix possible wrong checksum generation") Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Signed-off-by: William Bowling Reviewed-by: Eric Dumazet Tested-by: Jiayuan Chen Link: https://patch.msgid.link/20260513041635.1289541-1-vakzz@zellic.io Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0b765f7e3c703b8be10ce21304d1dd49acf6045d Author: Tejun Heo Date: Wed Apr 29 09:44:16 2026 -1000 workqueue: Annotate alloc_workqueue_va() with __printf(1, 0) commit 20e81c64c905bd765e69ef07920d2b1130dc79b6 upstream. alloc_workqueue_va() forwards its va_list to __alloc_workqueue() which ultimately feeds vsnprintf(). __alloc_workqueue() already carries __printf(1, 0); the new wrapper needs the same annotation so format string checking propagates through the forwarding. Fixes: 0de4cb473aed ("workqueue: fix devm_alloc_workqueue() va_list misuse") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604300347.2LgXyteh-lkp@intel.com/ Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 661b296ac50b45e8828423208b711f5bdae78570 Author: Steven Rostedt Date: Tue Apr 14 11:03:44 2026 -0400 tracefs: Removed unused 'ret' variable in eventfs_iterate() commit 43cec30c44764c4b1401fdeb48bfd18c3fc7eff8 upstream. Moving to guard() usage removed the need of using the 'ret' variable but it wasn't removed. As it was set to zero, the compiler in use didn't warn (although some compilers do). Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Link: https://patch.msgid.link/20260414110344.75c0663f@robin Fixes: 4d9b262031f ("eventfs: Simplify code using guard()s") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604100111.AAlbQKmK-lkp@intel.com/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 290e833d1acb1093bc121fcdc97f5e6161157479 Author: Allison Henderson Date: Tue May 5 16:43:36 2026 -0700 net/rds: reset op_nents when zerocopy page pin fails commit e174929793195e0cd6a4adb0cad731b39f9019b4 upstream. When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(), the pinned pages are released with put_page(), and rm->data.op_mmp_znotifier is cleared. But we fail to properly clear rm->data.op_nents. Later when rds_message_purge() is called from rds_sendmsg() the cleanup loop iterates over the incorrectly non zero number of op_nents and frees them again. Fix this by properly resetting op_nents when it should be in rds_message_zcopy_from_user(). Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.") Signed-off-by: Allison Henderson Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260505234336.2132721-1-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5b4d735be19e4528c6dbcaa0cc05b375108f8d05 Author: Johan Hovold Date: Wed May 20 08:55:41 2026 -0400 spi: sifive: fix controller deregistration [ Upstream commit 0f25236694a2854627c1597465a071e6bb6fe572 ] Make sure to deregister the controller before disabling underlying resources like interrupts during driver unbind. Note that clocks were also disabled before the recent commit 140039c23aca ("spi: sifive: Simplify clock handling with devm_clk_get_enabled()"). Fixes: 484a9a68d669 ("spi: sifive: Add driver for the SiFive SPI controller") Cc: stable@vger.kernel.org # 5.1 Cc: Yash Shah Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260410081757.503099-15-johan@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ee554b0b03df92c28e197cb96bc3acb21522158c Author: Pei Xiao Date: Wed May 20 08:55:40 2026 -0400 spi: sifive: Simplify clock handling with devm_clk_get_enabled() [ Upstream commit 140039c23aca067b9ff0242e3c0ce96276bb95f3 ] Replace devm_clk_get() followed by clk_prepare_enable() with devm_clk_get_enabled() for the bus clock. This reduces boilerplate code and error handling, as the managed API automatically disables the clock when the device is removed or if probe fails. Remove the now-unnecessary clk_disable_unprepare() calls from the probe error path and the remove callback. Adjust the error handling to use the existing put_host label. Signed-off-by: Pei Xiao Link: https://patch.msgid.link/73d0d8ecb4e1af5a558d6a7866c0f886d94fe3d1.1773885292.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Stable-dep-of: 0f25236694a2 ("spi: sifive: fix controller deregistration") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ae6b193493ee87a63dc3617977b1c44301a9d2de Author: Piyush Sachdeva Date: Fri May 15 12:16:50 2026 -0400 smb: client: Use FullSessionKey for AES-256 encryption key derivation [ Upstream commit 5be7a0cef3229fb3b63a07c0d289daf752545424 ] When Kerberos authentication is used with AES-256 encryption (AES-256-CCM or AES-256-GCM), the SMB3 encryption and decryption keys must be derived using the full session key (Session.FullSessionKey) rather than just the first 16 bytes (Session.SessionKey). Per MS-SMB2 section 3.2.5.3.1, when Connection.Dialect is "3.1.1" and Connection.CipherId is AES-256-CCM or AES-256-GCM, Session.FullSessionKey must be set to the full cryptographic key from the GSS authentication context. The encryption and decryption key derivation (SMBC2SCipherKey, SMBS2CCipherKey) must use this FullSessionKey as the KDF input. The signing key derivation continues to use Session.SessionKey (first 16 bytes) in all cases. Previously, generate_key() hardcoded SMB2_NTLMV2_SESSKEY_SIZE (16) as the HMAC-SHA256 key input length for all derivations. When Kerberos with AES-256 provides a 32-byte session key, the KDF for encryption/decryption was using only the first 16 bytes, producing keys that did not match the server's, causing mount failures with sec=krb5 and require_gcm_256=1. Add a full_key_size parameter to generate_key() and pass the appropriate size from generate_smb3signingkey(): - Signing: always SMB2_NTLMV2_SESSKEY_SIZE (16 bytes) - Encryption/Decryption: ses->auth_key.len when AES-256, otherwise 16 Also fix cifs_dump_full_key() to report the actual session key length for AES-256 instead of hardcoded CIFS_SESS_KEY_SIZE, so that userspace tools like Wireshark receive the correct key for decryption. Cc: Reviewed-by: Bharath SM Signed-off-by: Piyush Sachdeva Signed-off-by: Piyush Sachdeva Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 286d151c45ef2ed40e9e017628d3cb828ba26622 Author: David Carlier Date: Fri May 15 11:07:00 2026 -0400 eventfs: Use list_add_tail_rcu() for SRCU-protected children list [ Upstream commit f67950b2887fa10df50c4317a1fe98a65bc6875b ] Commit d2603279c7d6 ("eventfs: Use list_del_rcu() for SRCU protected list variable") converted the removal side to pair with the list_for_each_entry_srcu() walker in eventfs_iterate(). The insertion in eventfs_create_dir() was left as a plain list_add_tail(), which on weakly-ordered architectures can expose a new entry to the SRCU reader before its list pointers and fields are observable. Use list_add_tail_rcu() so the publication pairs with the existing list_del_rcu() and list_for_each_entry_srcu(). Fixes: 43aa6f97c2d0 ("eventfs: Get rid of dentry pointers without refcounts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260418152251.199343-1-devnexen@gmail.com Signed-off-by: David Carlier Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 000742ef517930db6280a46e1f8637fe98781c38 Author: Steven Rostedt Date: Fri May 15 11:06:59 2026 -0400 eventfs: Simplify code using guard()s [ Upstream commit 4d9b262031ffef203243e53577a90ae6e1090e67 ] Use guard(mutex), scoped_guard(mutex) and guard(src) to simplify the code and remove a lot of the jumps to "out:" labels. Cc: Mathieu Desnoyers Link: https://lore.kernel.org/20250604151625.250d13e1@gandalf.local.home Signed-off-by: Steven Rostedt (Google) Reviewed-by: Masami Hiramatsu (Google) Stable-dep-of: f67950b2887f ("eventfs: Use list_add_tail_rcu() for SRCU-protected children list") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8eb6dc76eeae5302c0d885906a0e469ef9630a59 Author: James Morse Date: Fri May 8 17:23:39 2026 +0100 arm_mpam: Check whether the config array is allocated before destroying it commit 6ccbb613b42a1f1ba7bfd547a148f644a902a25c upstream. __destroy_component_cfg() is called to free the configuration array. It uses the embedded 'garbage' structure, which means the array has to be allocated. If __destroy_component_cfg() is called from mpam_disable() before the configuration was ever allocated, then a NULL pointer is dereferenced. Check for this case and return early if the configuration is not allocated. __destroy_component_cfg() also frees the mbwu_state as this is allocated by __allocate_component_cfg(). As the mbwu_state is allocated after comp->cfg is set, and is also under mpam_list_lock, only the first pointer needs checking. Fixes: 3bd04fe7d807 ("arm_mpam: Extend reset logic to allow devices to be reset any time") Cc: Signed-off-by: James Morse Reviewed-by: Ben Horgan Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit ad75f1883796d780f6c1c75de39ce5ffe0a5b750 Author: James Morse Date: Fri May 8 17:23:38 2026 +0100 arm_mpam: Fix false positive assert failure during mpam_disable() commit f1caff3335ea6eab88cdc84ec8f2e3c45ca05486 upstream. mpam_assert_partid_sizes_fixed() is used to document that the caller doesn't expect the discovered PARTID size to change while it is walking a list sized by PARTID. Typically the MSC state is not written to until all the MSC have been discovered and this value is set. However, if discovering the MSC fails and schedules mpam_disable(), then the MSC state is written to reset it. In this case the discovered PARTID size may be become smaller - but only PARTID 0 will be used once resctrl_exit() has been called. Skip the WARN_ON_ONCE() if mpam_disable_reason has been set. Fixes: 3bd04fe7d807 ("arm_mpam: Extend reset logic to allow devices to be reset any time") Cc: Signed-off-by: James Morse Reviewed-by: Ben Horgan Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 3a2cbb6792066195ca9d509456f57c7c3feb41ea Author: Ben Horgan Date: Thu May 7 16:28:14 2026 +0100 arm_mpam: Improve check for whether or not NRDY is hardware managed commit ccad6001be5c38426ccf45790c411467ad3c03c6 upstream. mpam_ris_hw_probe_csu_nrdy() sets and clears MSMON_CSU.NRDY and checks whether it's configuration sticks. However, hardware isn't given a chance to disagree. Based on rule LRTGP, in MPAM specification IHI0099 version B.b, the hardware will set NRDY if it needs time to establish a count after a configuration change. Enable the monitor so that NRDY becomes relevant and change the configuration after clearing NRDY to try and coax the hardware into setting it. Fixes: 8c90dc68a5de ("arm_mpam: Probe the hardware features resctrl supports") Cc: Signed-off-by: Ben Horgan Reviewed-by: James Morse Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit dd061aca2085e5a5333a01dbb154f935e298cef3 Author: Ben Horgan Date: Thu May 7 16:28:13 2026 +0100 arm_mpam: Pretend that NRDY is always hardware managed commit 4387970bbd84fd14e0c49c3089c5061ccd86b98a upstream. Rule ZTXDS of the MPAM specification, IHI009 version B.b, states: "If a monitor does not support automatic updates of NRDY, software can use that bit for any purpose." As software is not reliably informed whether or not the monitor supports automatic updates of NRDY always assume that hardware may manage NRDY but don't rely on it. When NRDY is truly untouched by hardware then, as it is written to 0 on configuration, it will always read 0. At probe it's checked if MSMON_CSU.NRDY and MSMON_MBWU.NRDY are hardware managed but not MSMON_MBWU_L.NDRY. Specialize the checking for hardware managed NRDY to CSU counters as this is the only case where hardware management makes sense. Continue to inform the user if MSMON_CSU.NRDY appears to be hardware managed but the firmware doesn't provide the associated time limit for the automatic clearing of NRDY. Remove the NRDY feature flags as they are now unused. Fixes: 8c90dc68a5de ("arm_mpam: Probe the hardware features resctrl supports") Cc: Signed-off-by: Ben Horgan Reviewed-by: James Morse Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 1a3d777ff442be3e5fe7b0dfec3b51f1ad024e1b Author: Ben Horgan Date: Thu May 7 16:28:12 2026 +0100 arm_mpam: Fix monitor instance selection when checking for hardware NRDY commit 1ef2a89584b7b788b2603590d886db076b2f24cc upstream. In _mpam_ris_hw_probe_hw_nrdy() a new register value to select the first monitor and relevant RIS is prepared in mon_sel. However, it is written to the monitor value register, e.g. MSMON_CSU, rather than MSMON_CFG_MON_SEL. As MSMON_CFG_MON_SEL is a 32 bit register update the type of mon_sel to u32. Write mon_sel to the intended register, MSMON_CFG_MON_SEL. Fixes: 8c90dc68a5de ("arm_mpam: Probe the hardware features resctrl supports") Cc: Signed-off-by: Ben Horgan Reviewed-by: James Morse Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit c96c3d62ac177653a97b6dd0b6210f041447c147 Author: Johan Hovold Date: Fri May 8 16:44:46 2026 +0200 drm/gma500/oaktrail_lvds: fix i2c adapter leaks on init commit 84d1c9b416d54afe760ca4c378bd95c89261254c upstream. The LVDS init code looks up an I2C adapter using i2c_get_adapter() and tries to read the EDID before falling back to allocating and registering its own adapter. Make sure to drop the references taken by i2c_get_adapter() when falling back to allocating an adapter as well as on late errors to allow the looked up adapter to be deregistered. Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support") Cc: stable@vger.kernel.org # 3.3 Signed-off-by: Johan Hovold Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260508144446.59722-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit f6fc44af3bbd5ab0fb6bdec6f47decca11b38425 Author: Johan Hovold Date: Fri May 8 16:44:45 2026 +0200 drm/gma500/oaktrail_lvds: fix hang on init failure commit 657a091ab6d01d0091b77660c75cfed573c9a53e upstream. The LVDS init code looks up an I2C adapter using i2c_get_adapter() and tries to read the EDID before falling back to allocating and registering its own adapter. The error handling does not separate these cases so on a late init failure it will try to deregister and free also an adapter that had previously been registered. Since i2c_get_adapter() takes another reference to the adapter, deregistration hangs indefinitely while waiting for the reference to be released. Fix this by only destroying adapters allocated during LVDS init on errors. Fixes: a57ebfc0b4da ("drm/gma500: Make oaktrail lvds use ddc adapter from drm_connector") Cc: stable@vger.kernel.org # 6.0 Cc: Patrik Jakobsson Signed-off-by: Johan Hovold Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260508144446.59722-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5558d0ee783726ad71cb4c488b052c111335dd86 Author: Johan Hovold Date: Fri May 8 16:44:44 2026 +0200 drm/gma500/oaktrail_hdmi: fix i2c adapter leak on setup commit 950953f774b3f69da6f413e045ef075e1f3da2df upstream. Make sure to drop the reference taken to the I2C adapter (and its module) when setting up HDMI to allow the adapter to be deregistered. Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support") Cc: stable@vger.kernel.org # 3.3 Signed-off-by: Johan Hovold Signed-off-by: Patrik Jakobsson Link: https://patch.msgid.link/20260508144446.59722-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2b0dc7277b09bec0b2d44cba27f770845247996a Author: Thomas Hellström Date: Fri May 8 18:09:20 2026 +0200 drm/ttm: Convert -EAGAIN from dmem_cgroup_try_charge to -ENOSPC commit 591711b32681a04b57d00c2a404658f8419a081c upstream. dmem_cgroup_try_charge() returns -EAGAIN when the cgroup limit is hit and the charge fails. TTM has no concept of -EAGAIN from resource allocation; -ENOSPC is the canonical error meaning "no space, try eviction". Convert at the source in ttm_resource_alloc() so no caller needs to handle an unexpected error code, and clean up the now-redundant -EAGAIN check in ttm_bo_alloc_resource(). Without this, -EAGAIN escaping ttm_resource_alloc() during an eviction walk causes the walk to terminate early instead of continuing to the next candidate. Cc: Friedrich Vock Cc: Maarten Lankhorst Cc: Tejun Heo Cc: Maxime Ripard Cc: Christian Koenig Cc: dri-devel@lists.freedesktop.org Cc: # v6.14+ Fixes: 2b624a2c1865 ("drm/ttm: Handle cgroup based eviction in TTM") Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Maarten Lankhorst Link: https://patch.msgid.link/20260508160920.230339-1-thomas.hellstrom@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 9402ad98a047dd9894ec868a7df5ad9bd03327d3 Author: Thomas Hellström Date: Mon May 11 18:24:43 2026 +0200 drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure commit 1d59f36e95f7f7134db0e313c9d787cb0adb2153 upstream. Apply the same fix as b2ed01e7ad ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") to the ttm_bo_shrink() path. Move del_bulk_move from before the backup to after success only, using ttm_resource_del_bulk_move_unevictable() since the resource is now unevictable once fully backed up. Fixes: 70d645deac98 ("drm/ttm: Add helpers for shrinking") Cc: Christian König Cc: Huang Rui Cc: Matthew Auld Cc: Matthew Brost Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org # v6.15+ Assisted-by: GitHub_Copilot:claude-opus-4.6 Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260511162443.24352-1-thomas.hellstrom@linux.intel.com Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 827062952ed9bdf4220466c1f05ce452d04bdedf Author: Matthew Auld Date: Fri May 8 11:26:37 2026 +0100 drm/xe/dma-buf: fix UAF with retry loop commit 155a372a1cc50fa93387c5d3cdfd614a61e1afd1 upstream. Retry doesn't work here, since bo will be freed on error, leading to UAF. However, now that we do the alloc & init before the attach, we can now combine this as one unit and have the init do the alloc for us. This should make the retry safe. Reported by Sashiko. v2: Fix up the error unwind (CI) Closes: https://sashiko.dev/#/patchset/20260506184332.86743-2-matthew.auld%40intel.com Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: # v6.18+ Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260508102635.149172-4-matthew.auld@intel.com (cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit c473ae25421fddc3dde247ba7b85225b10641d09 Author: Matthew Auld Date: Fri May 8 11:26:36 2026 +0100 drm/xe/dma-buf: handle empty bo and UAF races commit 981bedbbe61364fcc3a3b87ebaf648a66cd07108 upstream. There look to be some nasty races here when triggering the invalidate_mappings hook: 1) We do xe_bo_alloc() followed by the attach, before the actual full bo init step in xe_dma_buf_init_obj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidate_mappings hook, with an empty/bogus bo, leading to potential bugs/crashes. 2) Similar to 1) but here we get a UAF, when the invalidate_mappings hook is triggered. For example, we get as far as xe_bo_init_locked() but this fails in some way. But here the bo will be freed on error, but we still have it attached from dma-buf pov, so if the invalidate_mappings is now triggered then the bo we access is gone and we trigger UAF and more bugs/crashes. To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to. We have at least two different customers reporting hitting a NULL ptr deref in evict_flags when importing something from amdgpu, followed by triggering the evict flow. Hit rate is also pretty low, which would hint at some kind of race, so something like 1) or 2) might explain this. v2: - Shuffle the order of the ops slightly (no functional change) - Improve the comment to better explain the ordering (Matt B) Assisted-by: Gemini:gemini-3 #debug Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7903 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/4055 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: # v6.8+ Reviewed-by: Matthew Brost Acked-by: Thomas Hellström Link: https://patch.msgid.link/20260508102635.149172-3-matthew.auld@intel.com (cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit df889676134efe980a89a95b271daf6221eb6d28 Author: Gyeyoung Baek Date: Sun Apr 19 16:17:16 2026 +0900 drm/panfrost: Fix wait_bo ioctl leaking positive return from dma_resv_wait_timeout() commit 459d75523b71c0ec254d153d8850d0b7008af396 upstream. dma_resv_wait_timeout() returns a positive 'remaining jiffies' value on success, 0 on timeout, and -errno on failure. panfrost_ioctl_wait_bo() returns this 'long' result from an int-typed ioctl handler, so positive values reach userspace as bogus errors. Explicitly set ret to 0 on the success path. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: stable@vger.kernel.org Signed-off-by: Gyeyoung Baek Reviewed-by: Adrián Larumbe Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patch.msgid.link/fe33f82fded7be1c18e2e0eb2db451d5a738cf39.1776581974.git.gye976@gmail.com Signed-off-by: Steven Price Signed-off-by: Greg Kroah-Hartman commit 6cffee18c86bf0cde264c69bb60ff0f82b08d1c2 Author: Sebastian Brzezinka Date: Thu Apr 16 13:31:18 2026 +0200 drm/i915: skip __i915_request_skip() for already signaled requests commit 4cfe4c0efbdcde742a47813180cc69b132d7598e upstream. After a GPU reset the HWSP is zeroed, so previously completed requests appear incomplete. If such a request is picked up during reset_rewind() and marked guilty, i915_request_set_error_once() returns early (fence already signaled), leaving fence.error without a fatal error code. The subsequent __i915_request_skip() then hits: ``` GEM_BUG_ON(!fatal_error(rq->fence.error)) ``` Fixes a kernel BUG observed on Sandy Bridge (Gen6) during heartbeat-triggered engine resets. ``` kernel BUG at drivers/gpu/drm/i915/i915_request.c:556! RIP: __i915_request_skip+0x15e/0x1d0 [i915] ... __i915_request_reset+0x212/0xa70 [i915] reset_rewind+0xe4/0x280 [i915] intel_gt_reset+0x30d/0x5b0 [i915] heartbeat+0x516/0x530 [i915] ``` Guard __i915_request_skip() with i915_request_signaled(), if the fence is already signaled, the ring content is committed and there is nothing left to skip. Fixes: 36e191f0644b ("drm/i915: Apply i915_request_skip() on submission") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/13729 Signed-off-by: Sebastian Brzezinka Cc: stable@vger.kernel.org # v5.7+ Reviewed-by: Krzysztof Karas Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/fe76921d35b6ae85aa651822726d0d9815aa5362.1776339012.git.sebastian.brzezinka@intel.com (cherry picked from commit 5ba54393dcd7adf75a9f39f5a933b1538349cad5) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit fbf8000538d870b0df50fdcff2bb9b33ae94b592 Author: Nicolin Chen Date: Fri Apr 24 18:15:25 2026 -0700 iommu: Fix ATS invalidation timeouts during __iommu_remove_group_pasid() commit fc3523b16d2b4b88e61e69504b0ae0b18b869c8f upstream. If a device is blocked, its PASID domains are already detached. Repeating iommu_remove_dev_pasid() is unnecessary and might trigger ATS invalidation timeouts. Skip the iommu_remove_dev_pasid() call upon gdev->blocked. Fixes: c279e83953d9 ("iommu: Introduce pci_dev_reset_iommu_prepare/done()") Cc: stable@vger.kernel.org Closes: https://sashiko.dev/#/patchset/20260407194644.171304-1-nicolinc%40nvidia.com Reviewed-by: Kevin Tian Signed-off-by: Nicolin Chen Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 81e579ba9489fff3a22b6f2a5b8d72f7b77ab4c0 Author: Nicolin Chen Date: Fri Apr 24 18:15:24 2026 -0700 iommu: Fix nested pci_dev_reset_iommu_prepare/done() commit 0d5fd7a9323ce6bedd170e21e1e90b8904917c75 upstream. Shuai found that cxl_reset_bus_function() calls pci_reset_bus_function() internally while both are calling pci_dev_reset_iommu_prepare/done(). As pci_dev_reset_iommu_prepare() doesn't support re-entry, the inner call will trigger a WARN_ON and return -EBUSY, resulting in failing the entire device reset. On the other hand, removing the outer calls in the PCI callers is unsafe. As pointed out by Kevin, device-specific quirks like reset_hinic_vf_dev() execute custom firmware waits after their inner pcie_flr() completes. If the IOMMU protection relies solely on the inner reset, the IOMMU will be unblocked prematurely while the device is still resetting. Instead, fix this by making pci_dev_reset_iommu_prepare/done() reentrant. Introduce gdev->reset_depth to handle the re-entries on the same device. Fixes: c279e83953d9 ("iommu: Introduce pci_dev_reset_iommu_prepare/done()") Cc: stable@vger.kernel.org Reported-by: Shuai Xue Closes: https://lore.kernel.org/all/absKsk7qQOwzhpzv@Asurada-Nvidia/ Suggested-by: Kevin Tian Reviewed-by: Shuai Xue Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Reviewed-by: Lu Baolu Signed-off-by: Nicolin Chen Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 6358b61b7a80e0053fdd3809485a60f35f0cea34 Author: Nicolin Chen Date: Fri Apr 24 18:15:23 2026 -0700 iommu: Fix pasid attach in pci_dev_reset_iommu_prepare/done() commit 1615e8896a8f6d7b2adf6495e538a81bf6cea3e0 upstream. Now the helpers handle per-gdev resets. Replace __iommu_set_group_pasid() with set_dev_pasid() accordingly, in the pci_dev_reset_iommu_done(). Also add max_pasids check as other callers. Fixes: c279e83953d9 ("iommu: Introduce pci_dev_reset_iommu_prepare/done()") Cc: stable@vger.kernel.org Reported-by: Shuai Xue Closes: https://lore.kernel.org/all/ad858513-09fc-455e-bbc5-fe38a225cc78@linux.alibaba.com/ Reviewed-by: Shuai Xue Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Signed-off-by: Nicolin Chen Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 8fc289e809f3eb7e36cadc4684ab6fad747a5a93 Author: Nicolin Chen Date: Fri Apr 24 18:15:26 2026 -0700 iommu: Fix WARN_ON in __iommu_group_set_domain_nofail() due to reset commit 5474e6e17a262db45c60575c73f70210f5c7001f upstream. In __iommu_group_set_domain_internal(), concurrent domain attachments are rejected when any device in the group is recovering. This is necessary to fence concurrent attachments to a multi-device group where devices might share the same RID due to PCI DMA alias quirks, but triggers the WARN_ON in __iommu_group_set_domain_nofail(). Other IOMMU_SET_DOMAIN_MUST_SUCCEED callers in detach/teardown paths, such as __iommu_group_set_core_domain and __iommu_release_dma_ownership, should not be rejected, as the domain would be freed anyway in these nofail paths while group->domain is still pointing to it. So pci_dev_reset_iommu_done() could trigger a UAF when re-attaching group->domain. Honor the IOMMU_SET_DOMAIN_MUST_SUCCEED flag, allowing the callers through the group->recovery_cnt fence, so as to update the group->domain pointer. Instead add a gdev->blocked check in the device iteration loop, to prevent any concurrent per-device detachment. Fixes: c279e83953d9 ("iommu: Introduce pci_dev_reset_iommu_prepare/done()") Cc: stable@vger.kernel.org Closes: https://sashiko.dev/#/patchset/20260407194644.171304-1-nicolinc%40nvidia.com Reviewed-by: Kevin Tian Reviewed-by: Lu Baolu Signed-off-by: Nicolin Chen Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 90f0ae77681881a24ecd9494286d9d4522dd7ab8 Author: Nicolin Chen Date: Fri Apr 24 18:15:22 2026 -0700 iommu: Replace per-group resetting_domain with per-gdev blocked flag commit b296ca1fb43aa435edd86131f5230f70c03b2829 upstream. The core tracks device resetting states with a per-group resetting_domain, while a reset is actually per group-device. Such a mismatch might lead to confusion and even difficulty to untangle per-gdev handling requirement. Shuai found that cxl_reset_bus_function() calls pci_reset_bus_function() internally while both are calling pci_dev_reset_iommu_prepare/done(). And the solution requires the core to track at the group_device level as well. Introduce a 'blocked' flag to struct group_device, to allow a multi-device group to isolate concurrent device resets independently. As the reset routine is per gdev, it cannot clear group->resetting_domain without iterating over the device list to ensure no other device is being reset. Simplify it by replacing the resetting_domain with a 'recovery_cnt' in the struct iommu_group. No functional change. But this is essential to apply following bug fixes. Fixes: c279e83953d9 ("iommu: Introduce pci_dev_reset_iommu_prepare/done()") Cc: stable@vger.kernel.org Reported-by: Shuai Xue Closes: https://lore.kernel.org/all/absKsk7qQOwzhpzv@Asurada-Nvidia/ Reviewed-by: Shuai Xue Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Reviewed-by: Lu Baolu Signed-off-by: Nicolin Chen Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 17194cd0dd236e732d116d50840d795ca50ef196 Author: Nicolin Chen Date: Fri Apr 24 18:15:20 2026 -0700 iommu: Fix NULL group->domain dereference in pci_dev_reset_iommu_done() commit d769711fcddd005f1e654b3bde547140917fe696 upstream. Local sashiko review pointed it out that group->domain could be NULL when a default domain fails to allocate during the first probe, which can crash at domain->ops->attach_dev dereference in __iommu_attach_device() invoked by pci_dev_reset_iommu_done(). pci_dev_reset_iommu_prepare() is fine as an old_domain pointer can be NULL. Skip the re-attach in pci_dev_reset_iommu_done() to fix the bug. Fixes: c279e83953d9 ("iommu: Introduce pci_dev_reset_iommu_prepare/done()") Cc: stable@vger.kernel.org Signed-off-by: Nicolin Chen Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit cdfe3c9f2c9e28a8651ee463c88ad191ced2f840 Author: Zhenzhong Duan Date: Sat May 9 10:43:46 2026 +0800 iommu/vt-d: Avoid NULL pointer dereference or refcount corruption commit 79ea2feb917b05366b49d85573c9c5331f043b2c upstream. Commit 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") fixed a NULL pointer dereference in an unlikely situation partly. If dev_pasid is not found in the dev_pasids list, it remains NULL. However, the teardown operations are executed unconditionally, this lead to a NULL pointer dereference or refcount corruption. If the domain was never attached to this IOMMU, info will be NULL, which would cause an immediate dereference when checking --info->refcnt. Even if info is not NULL, decrementing the refcount without having removed a valid PASID might unbalance the count. This could lead to premature dropping of the refcount to 0, potentially causing a use-after-free for the remaining active devices sharing the domain. Fix it by returning early if dev_pasid is NULL, before executing the teardown operations. Issue found by AI review and suggested by Kevin Tian. https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com Fixes: 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") Cc: stable@vger.kernel.org Suggested-by: Kevin Tian Signed-off-by: Zhenzhong Duan Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260422033538.95000-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 1e659db468476733d217c1314c1e0d9244356d6c Author: Zhenzhong Duan Date: Sat May 9 10:43:45 2026 +0800 iommu/vt-d: Fix oops due to out of scope access commit a6dea58d8625c06b9654c0555f101742481335c3 upstream. Below oops triggers when kill QEMU process: Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI Call Trace: do_raw_spin_lock+0xaa/0xc0 _raw_spin_lock_irqsave+0x21/0x40 domain_remove_dev_pasid+0x52/0x160 intel_nested_set_dev_pasid+0x1b9/0x1e0 __iommu_set_group_pasid+0x56/0x120 pci_dev_reset_iommu_done+0xe3/0x180 pcie_flr+0x65/0x160 __pci_reset_function_locked+0x5b/0x120 vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core] vfio_df_close+0x4f/0xa0 vfio_df_unbind_iommufd+0x2d/0x60 vfio_device_fops_release+0x3e/0x40 __fput+0xe5/0x2c0 task_work_run+0x58/0xa0 do_exit+0x2c8/0x600 do_group_exit+0x2f/0xa0 get_signal+0x863/0x8c0 arch_do_signal_or_restart+0x24/0x100 exit_to_user_mode_loop+0x87/0x380 do_syscall_64+0x2ff/0x11e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The global static blocked domain is a dummy domain without corresponding dmar_domain structure, accessing beyond iommu_domain structure triggers oops easily. Fix it by return early in domain_remove_dev_pasid() like identity domain. Fixes: 7d0c9da6c150 ("iommu/vt-d: Add set_dev_pasid callback for dma domain") Cc: stable@vger.kernel.org Signed-off-by: Zhenzhong Duan Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260421031347.1408890-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit f1d5d12c98b81c24a5ce8baabe68af685e65efb8 Author: Naval Alcalá Date: Sat May 9 10:43:44 2026 +0800 iommu/vt-d: Disable DMAR for Intel Q35 IGFX commit 2cda2e10dc8343ae01eae9e999a876b7e7d37861 upstream. Intel Q35 integrated graphics (8086:29b2) exhibits broken DMAR behaviour similar to other G4x/GM45 devices for which DMAR is already disabled via quirks. When DMAR is enabled, the system may hard lock up during boot or early device initialization, requiring a reset. Add the missing PCI ID to the existing quirk list to disable DMAR for this device. Fixes: 1f76249cc3be ("iommu/vt-d: Declare Broadwell igfx dmar support snafu") Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=201185 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216064 Signed-off-by: Naval Alcalá Link: https://lore.kernel.org/r/20260410161622.13549-1-ari@naval.cat Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 0a1265a9ab875f92b6a3ffb497404f46cf9d76a3 Author: Raphael Zimmer Date: Tue May 12 09:29:30 2026 +0200 libceph: handle rbtree insertion error in decode_choose_args() commit d289478cfc0bcf81c7914200d6abdcb78bd04ded upstream. A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). In this function, num_choose_arg_maps is read from the message, and a corresponding number of crush_choose_arg_maps gets decoded afterwards. Each crush_choose_arg_map has a choose_args_index, which serves as the key when inserting it into the choose_args rbtree of the decoded crush_map. If a (potentially corrupted) message contains two crush_choose_arg_maps with the same index, the assertion in insert_choose_arg_map() triggers a kernel BUG when trying to insert the second crush_choose_arg_map. This patch fixes the issue by switching to the non-asserting rbtree insertion function and rejecting the message if the insertion fails. [ idryomov: changelog ] Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit fb176a99e4c1a5a8448a83d83d3606203ba81faa Author: Raphael Zimmer Date: Wed Apr 22 10:47:13 2026 +0200 libceph: Fix potential out-of-bounds access in crush_decode() commit 4c79fc2d598694bda845b46229c9d48b65042970 upstream. A message of type CEPH_MSG_OSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing. This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crush_destroy_bucket functions to the generic crush_destroy_bucket(). Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit c7e9b53aebe401970f1b5f5a01b4e021b18e8bb2 Author: Raphael Zimmer Date: Tue Apr 28 14:15:46 2026 +0200 libceph: Fix potential out-of-bounds access in __ceph_x_decrypt() commit 821365487aa58d06bda65c676ba215d506ba9768 upstream. In __ceph_x_decrypt(), a part of the buffer p is interpreted as a ceph_x_encrypt_header, and the magic field of this struct is accessed. This happens without any guarantee that the buffer is large enough to hold this struct. The function parameter ciphertext_len represents the length of the ciphertext to decrypt and is guaranteed to be at most the remaining size of the allocated buffer p. However, this value is not necessarily greater than sizeof(ceph_x_encrypt_header). E.g., a message frame of type FRAME_TAG_AUTH_REPLY_MORE, that is just as long to hold the ciphertext at its end with a ciphertext_len of 8 or less, can trigger an out-of-bounds memory access when accessing hdr->magic. This patch fixes the issue by adding a check to ensure that the decrypted plaintext in the buffer is large enough to represent at least the ceph_x_encrypt_header. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit a20e16ebfe2fa65348eb4b2dc7deac330ce03e9c Author: Raphael Zimmer Date: Tue May 12 18:16:40 2026 +0200 libceph: Fix potential null-ptr-deref in decode_choose_args() commit 28b0a2ab8c82d0bbdeb8013029c67c978ce6e4bf upstream. A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. When decoding this CRUSH map in crush_decode(), an array of max_buckets CRUSH buckets is decoded, where some indices may not refer to actual buckets and are therefore set to NULL. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). When decoding a crush_choose_arg_map, a series of choose_args for different buckets is decoded, with the bucket_index being read from the incoming message. It is only checked that the bucket index does not exceed max_buckets, but not that it doesn't point to an index with a NULL bucket. If a (potentially corrupted) message contains a crush_choose_arg_map including such a bucket_index, a null pointer dereference may occur in the subsequent processing when attempting to access the bucket with the given index. This patch fixes the issue by extending the affected check. Now, it is only attempted to access the bucket if it is not NULL. Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit ee933694645dac062d65fc2743f92bc06fa0db6b Author: Raphael Zimmer Date: Tue May 5 11:08:12 2026 +0200 libceph: Fix potential out-of-bounds access in osdmap_decode() commit 35d0ed82d03e5ee77ea4f31f20e29562a7721649 upstream. When decoding osd_state and osd_weight from an incoming osdmap in osdmap_decode(), both are decoded for each osd, i.e., map->max_osd times. The ceph_decode_need() check only accounts for sizeof(*map->osd_weight) once. This can potentially result in an out-of-bounds memory access if the incoming message is corrupted such that the max_osd value exceeds the actual content of the osdmap message. This patch fixes the issue by changing the corresponding part in the ceph_decode_need() check to account for map->max_osd*sizeof(*map->osd_weight). Cc: stable@vger.kernel.org Fixes: dcbc919a5dc8 ("libceph: switch osdmap decoding to use ceph_decode_entity_addr") Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit a2581ea139da03c5a13fbd2ffd08a0c1b7d9bde5 Author: Sascha Bischoff Date: Wed May 6 09:37:43 2026 +0000 irqchip/gic-v5: Allocate ITS parent LPIs as a range commit a7c7e42654b6a8676610ee09d22901432c4851af upstream. The ITS MSI domain no longer manages LPI allocation directly. LPIs are allocated and freed by the parent LPI domain, which can now handle a full range of interrupts and unwind partial allocations internally. Make the ITS domain request and release the parent IRQs as a single range instead of iterating over each interrupt. The ITS allocation path then only needs to reserve EventIDs, allocate the parent range, and fill in the ITS irq_data for each MSI. Since no operation in the per-MSI loop can fail, the partial parent-free unwind becomes unnecessary. On teardown, reset the ITS irq_data for the range and then release the parent range in one call, leaving LPI teardown to the LPI domain. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Reviewed-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260506093634.382062-4-sascha.bischoff@arm.com Signed-off-by: Greg Kroah-Hartman commit 23c94a53386a17787d0e756f529544fa6236ea50 Author: Sascha Bischoff Date: Wed May 6 09:37:23 2026 +0000 irqchip/gic-v5: Support range allocation for LPIs commit eb6f6d523813ead9dc2799194a2839d42c049734 upstream. The per-IPI parent allocation loop returns immediately on failure and leaks any parent interrupts allocated by earlier iterations. The GICv5 LPI domain now owns LPI allocation and teardown internally, but its irq_domain callbacks still reject requests where nr_irqs is greater than one. This forces child domains to allocate and free LPIs one at a time even when the interrupt core requests a contiguous range. Handle multi-interrupt allocation and teardown in the LPI domain by iterating over the requested range and unwinding any partially allocated state on failure. Allocate the parent LPIs for the IPI domain with a single range request as well, which cures the leakage problem. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Reviewed-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260506093634.382062-3-sascha.bischoff@arm.com Signed-off-by: Greg Kroah-Hartman commit abbf41c459c39439fbae0004bd274b210ee32f4e Author: Sascha Bischoff Date: Wed May 6 09:37:02 2026 +0000 irqchip/gic-v5: Move LPI allocation into the LPI domain commit dec85d2fbd20de3711a71e65397dfdb40c3fa953 upstream. The IPI and ITS MSI domains currently allocate and release LPIs directly, then pass the selected LPI ID to the parent LPI domain. This leaks the LPI domain's allocation policy into its child domains and forces each child to duplicate part of the parent domain's teardown. Make the LPI domain allocate LPIs in its .alloc() callback and release them in a matching .free() callback. Child domains can then request a parent interrupt without passing an implementation-specific LPI ID, and the LPI lifetime is tied to the domain that owns the LPI namespace. Remove the gicv5_alloc_lpi() and gicv5_free_lpi() wrappers now that no external caller needs to manage LPIs directly. This is a preparatory change for an actual leakage problem in the allocation code and therefore tagged with the same Fixes tag. Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support") Signed-off-by: Sascha Bischoff Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Reviewed-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260506093634.382062-2-sascha.bischoff@arm.com Signed-off-by: Greg Kroah-Hartman commit ee0e4ba8799b125afae6e8c2af00eb93e5d0c0f0 Author: Xianwei Zhao Date: Fri May 8 07:36:54 2026 +0000 irqchip/meson-gpio: Use the correct register in meson_s4_gpio_irq_set_type() commit 5363b67ac8ebcc3e227dbf59fc8061949109841d upstream. meson_s4_gpio_irq_set_type() uses the both-edge trigger register for configuring level type and single edge mode interrupts, which is not correct. Use REG_EDGE_POL instead. Fixes: bbd6fcc76b39 ("irqchip: Add support for Amlogic A4 and A5 SoCs") Signed-off-by: Xianwei Zhao Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260508-a9-gpio-irqchip-v1-1-9dc5f3e022e0@amlogic.com Signed-off-by: Greg Kroah-Hartman commit 1d13e48b1b0dc7f5d7a7e861cf8b28e55578eb14 Author: Yong-Xuan Wang Date: Fri May 8 02:31:21 2026 -0700 irqchip/riscv-imsic: Clear interrupt move state during CPU offlining commit cefafbd561402b0fe6447449364a30315b9b1570 upstream. Affinity changes of IMSIC interrupts have to be careful to not lose an interrupt in the process. Each vector keeps track of an affinity change in progress with two pointers in struct imsic_vector. imsic_vector::move_prev points to the previous CPU target data and imsic_vector::move_next to the designated new CPU target data. imsic_vector::move_prev on the new CPU can only be cleared after the previous CPU has cleared imsic_vector::move_next, which ususally happens in __imsic_remote_sync(). In case of CPU hot-unplug __imsic_remote_sync() is not invoked because the CPU is already marked offline. That means imsic_vector::move_prev becomes stale until the CPU is onlined again. The stale pointer prevents further affinity changes for the affected interrupts. Solve this by clearing the imsic_vector::move_prev pointers in the CPU hotplug offline path. [ tglx: Replace word salad in change log ] Fixes: 0f67911e821c ("irqchip/riscv-imsic: Separate next and previous pointers in IMSIC vector") Signed-off-by: Yong-Xuan Wang Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260508-imsic-v2-1-e9f08dd46cf5@sifive.com Signed-off-by: Greg Kroah-Hartman commit cde3aaba01721da7fbb5f5b84849f13c01b58042 Author: Olga Kornievskaia Date: Fri Apr 10 12:09:20 2026 -0400 nfsd: update mtime/ctime on COPY in presence of delegated attributes commit 4183cf383b6faec17a0882b84cd2d901dba62b16 upstream. When delegated attributes are given on open, the file is opened with NOCMTIME and modifying operations do not update mtime/ctime as to not get out-of-sync with the client's delegated view. However, for COPY operation, the server should update its view of mtime/ctime and reflect that in any GETATTR queries. Fixes: e5e9b24ab8fa ("nfsd: freeze c/mtime updates with outstanding WRITE_ATTRS delegation") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 4c3bd1f14f075d37ccde27abc8f7499c3b87294c Author: Olga Kornievskaia Date: Fri Apr 10 12:09:19 2026 -0400 nfsd: update mtime/ctime on CLONE in presense of delegated attributes commit 2863bac7f49c4acd80a048ce52506a2b9c8db015 upstream. When delegated attributes are given on open, the file is opened with NOCMTIME and modifying operations do not update mtime/ctime as to not get out-of-sync with the client's delegated view. However, for CLONE operation, the server should update its view of mtime/ctime and reflect that in any GETATTR queries. Fixes: e5e9b24ab8fa ("nfsd: freeze c/mtime updates with outstanding WRITE_ATTRS delegation") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit fca11a1cc40c3ea9bc06a197e0f9653ce453d236 Author: Scott Mayhew Date: Tue Apr 7 18:08:57 2026 -0400 nfsd: fix file change detection in CB_GETATTR commit 304d81a2fbf2b454def4debcb38ea173911b72cd upstream. RFC 8881, section 10.4.3 doesn't say anything about caching the file size in the delegation record, nor does it say anything about comparing a cached file size with the size reported by the client in the CB_GETATTR reply for the purpose of determining if the client holds modified data for the file. What section 10.4.3 of RFC 8881 does say is that the server should compare the *current* file size with the size reported by the client holding the delegation in the CB_GETATTR reply, and if they differ to treat it as a modification regardless of the change attribute retrieved via the CB_GETATTR. Doing otherwise would cause the server to believe the client holding the delegation has a modified version of the file, even if the client flushed the modifications to the server prior to the CB_GETATTR. This would have the added side effect of subsequent CB_GETATTRs causing updates to the mtime, ctime, and change attribute even if the client holding the delegation makes no further updates to the file. Modify nfsd4_deleg_getattr_conflict() to obtain the current file size via i_size_read(). Retain the ncf_cur_fsize field, since it's a convenient way to return the file size back to nfsd4_encode_fattr4(), but don't use it for the purpose of detecting file changes. Remove the unnecessary initialization of ncf_cur_fsize in nfs4_open_delegation(). Also, if we recall the delegation (because the client didn't respond to the CB_GETATTR), then skip the logic that checks the nfs4_cb_fattr fields. Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation") Cc: stable@vger.kernel.org Signed-off-by: Scott Mayhew Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit e7dd3b25d6c695c80d8e57a9a9337e9386f9f922 Author: Olga Kornievskaia Date: Fri Apr 3 11:20:55 2026 -0400 nfsd: fix GET_DIR_DELEGATION when VFS leases are disabled commit b0bf14546bcefa4ea49f5efcd7db2a99f0cabde9 upstream. When leases are disabled on the server, running xfstest generic/309 leads to an error because GET_DIR_DELEGATION returns EINVAL. nfsd_get_dir_deleg() can fail in several ways: like memory allocation and unable to get a lease because either leases are disable or it's already held. Currently only the condition "already held" is translated to returning directory-delegation-is-unavailable error. However, other failure conditions are likely temporary and thus should result in the same kind of error. Fixes: 8b99f6a8c116 ("nfsd: wire up GET_DIR_DELEGATION handling") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit cdfad9022fd833a8f564ca776d9e971714bee444 Author: Paulo Alcantara Date: Tue May 12 13:33:46 2026 +0100 netfs: fix error handling in netfs_extract_user_iter() commit 0aad5704c6b4d14007d4eab15883e8524e4310f4 upstream. In netfs_extract_user_iter(), if iov_iter_extract_pages() failed to extract user pages, bail out on -ENOMEM, otherwise return the error code only if @npages == 0, allowing short DIO reads and writes to be issued. This fixes mmapstress02 from LTP tests against CIFS. Fixes: 85dd2c8ff368 ("netfs: Add a function to extract a UBUF or IOVEC into a BVEC iterator") Reported-by: Xiaoli Feng Signed-off-by: Paulo Alcantara (Red Hat) Signed-off-by: David Howells Link: https://patch.msgid.link/20260512123404.719402-10-dhowells@redhat.com Cc: netfs@lists.linux.dev Cc: stable@vger.kernel.org Cc: linux-cifs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 7b6ae258fe89c35cbb94ffcb7b8f087378a01d49 Author: Ma Ke Date: Sun Nov 16 10:44:11 2025 +0800 powerpc/warp: Fix error handling in pika_dtm_thread commit 108d7f951271cbd36ca36efc5e5d106966f5180c upstream. pika_dtm_thread() acquires client through of_find_i2c_device_by_node() but fails to release it in error handling path. This could result in a reference count leak, preventing proper cleanup and potentially leading to resource exhaustion. Add put_device() to release the reference in the error handling path. Found by code review. Cc: stable@vger.kernel.org Fixes: 3984114f0562 ("powerpc/warp: Platform fix for i2c change") Signed-off-by: Ma Ke Reviewed-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20251116024411.21968-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 9e48b4f813d2c3db75d522aa82ab705ce04b7e2d Author: Carlos López Date: Tue May 12 12:00:41 2026 +0200 virt: sev-guest: Do not use host-controlled page order in cleanup path commit 23e6a1ca04ae44806439a5a446e62e4d42e80bb4 upstream. When issuing an extended guest request (SVM_VMGEXIT_EXT_GUEST_REQUEST), get_ext_report() allocates a buffer to retrieve a certificate blob from the host, keeping track of its size in report_req->certs_len. However, the host may return SNP_GUEST_VMM_ERR_INVALID_LEN, indicating an invalid buffer size, as well as the expected length of such buffer. get_ext_report() subsequently updates report_req->certs_len with the host-controlled value, and cleans up the buffer by computing a page order from such value. This is incorrect, as the host-provided length may not match the page order of the original allocation, potentially resulting in corruption in the page allocator. Fix this by using alloc_pages_exact() instead, and reusing @npages to compute the size passed to free_pages_exact(). For consistency, also use @npages to compute the size when allocating the pages, even though this last change has no functional effect. Fixes: 3e385c0d6ce8 ("virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex") Signed-off-by: Carlos López Signed-off-by: Borislav Petkov (AMD) Tested-by: Michael Roth Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8aff7bd1b5590be7236c30138c79f1e1618884c7 Author: Wilfred Mallawa Date: Wed Apr 15 09:45:14 2026 +1000 xfs: fix memory leak on error in xfs_alloc_zone_info() commit 592975da8c3ca87b043077e6eafa37665eae7936 upstream. Currently, the 0th index of the zi_used_bucket_bitmap array is not freed on error due to the pre-decrement then evaluate semantic of the while loop used in xfs_alloc_zone_info(). Fix it by allowing for the i == 0 case to be covered. Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection") Cc: stable@vger.kernel.org # v6.15 Reviewed-by: Damien Le Moal Reviewed-by: Carlos Maiolino Signed-off-by: Wilfred Mallawa Reviewed-by: Hans Holmberg Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 7dba9631faa2ee0785e8c2bf0e3d90a05f26dd8c Author: David Woodhouse Date: Tue Apr 28 21:59:52 2026 +0100 x86/kexec: Push kjump return address even for non-kjump kexec commit 786a45757dcdf8f2beb9d4a6db605db16c18b2b4 upstream. The version of purgatory code shipped by kexec-tools attempts to look above the top of its stack to find a return address for a kjump, even in a non-kjump kexec. After the commit in Fixes: the word above the stack might not be there, leading to a fault (which is at least now caught by my exception-handling code in kexec). That commit fixed things for the actual kjump path, but no longer "gratuitously" pushes the unused return address to the stack in the non-kjump path. Put that *back* in the non-kjump path, to prevent purgatory from crashing when trying to access it. Fixes: 2cacf7f23a02 ("x86/kexec: Fix stack and handling of re-entry point for ::preserve_context") Reported-by: Rohan Kakulawaram Signed-off-by: David Woodhouse Signed-off-by: Borislav Petkov (AMD) Acked-by: Dave Hansen Tested-by: Rohan Kakulawaram Cc: Link: https://patch.msgid.link/32d627134143ffd957891cb697138e839c623211.camel@infradead.org Signed-off-by: Greg Kroah-Hartman commit 79db4cbab81f07ce69a93d379ebd40d3709ecfb2 Author: Jose Fernandez (Anthropic) Date: Tue Apr 21 19:26:13 2026 +0000 iommu/amd: Bounds-check devid in __rlookup_amd_iommu() commit 07d0f496fe7ec5abe3bee7e38be709521567bb33 upstream. iommu_device_register() walks every device on the PCI bus via bus_for_each_dev() and calls amd_iommu_probe_device() for each. The inlined check_device() path computes the device's sbdf, calls rlookup_amd_iommu() to find the owning IOMMU, and only afterwards verifies devid <= pci_seg->last_bdf. __rlookup_amd_iommu() indexes rlookup_table[devid] with no bounds check of its own, so for a PCI device whose BDF is not described by the IVRS, the lookup reads past the end of the allocation before the caller's bounds check can run. This was harmless before commit e874c666b15b ("iommu/amd: Change rlookup, irq_lookup, and alias to use kvalloc()"): the table was a zeroed page-order allocation, so the over-read returned NULL and the caller's NULL check skipped the device. After that commit the table is a tight kvcalloc() and the over-read returns adjacent slab contents, which check_device() then dereferences as a struct amd_iommu *, causing a boot-time GPF. Seen on Google Compute Engine ct6e VMs, where the virtualized IVRS describes only the four TPU endpoints 00:04.0-07.0; the gVNIC at 00:08.0 (devid 0x40) indexes 56 bytes past the 456-byte allocation, into the adjacent kmalloc-512 slab object: pci 0000:00:04.0: Adding to iommu group 0 pci 0000:00:05.0: Adding to iommu group 1 pci 0000:00:06.0: Adding to iommu group 2 pci 0000:00:07.0: Adding to iommu group 3 Oops: general protection fault, probably for non-canonical address 0x3a64695f78746382: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.22 #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025 RIP: 0010:amd_iommu_probe_device+0x54/0x3a0 Call Trace: __iommu_probe_device+0x107/0x520 probe_iommu_group+0x29/0x50 bus_for_each_dev+0x7e/0xe0 iommu_device_register+0xc9/0x240 iommu_go_to_state+0x9c0/0x1c60 amd_iommu_init+0x14/0x40 pci_iommu_init+0x16/0x60 do_one_initcall+0x47/0x2f0 Guard the array access in __rlookup_amd_iommu(). With the fix applied on 6.18.22, the gVNIC at 00:08.0 is skipped cleanly and the VM boots. Fixes: e874c666b15b ("iommu/amd: Change rlookup, irq_lookup, and alias to use kvalloc()") Cc: stable@vger.kernel.org Reported-by: Ziyuan Chen Tested-by: Ziyuan Chen Reviewed-by: Josef Bacik Assisted-by: Claude:unspecified Signed-off-by: Jose Fernandez (Anthropic) Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit d376c131af7c7739a87ff037ed2fdb67c2542c8a Author: Nicholas Carlini Date: Mon May 11 18:02:16 2026 +0000 io-wq: check that the predecessor is hashed in io_wq_remove_pending() commit d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc upstream. io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot. Cc: stable@vger.kernel.org Fixes: 204361a77f40 ("io-wq: fix hang after cancelling pending hashed work") Signed-off-by: Nicholas Carlini Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 86921e890fe1dea9791fb70bec552516fd47716a Author: Hristo Venev Date: Mon May 4 18:54:45 2026 +0300 ceph: put folios not suitable for writeback commit 544576f0f05c4a759806acddfaaeb686f14fb4b0 upstream. The batch holds references to the folios (see `filemap_get_folios`, `folio_batch_release`), so we need to `folio_put` the folios we remove. Tested on v6.18. Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/74156 Signed-off-by: Hristo Venev Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 368d21ae9081c93497b1c8163bed3eddcb2443ff Author: Viacheslav Dubeyko Date: Thu Apr 9 12:43:40 2026 -0700 ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size commit 0c22d9511cbde746622f8e4c11aaa63fe76d45f9 upstream. The generic/642 test-case can reproduce the kernel crash: [40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr ceph_con_workfn [40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839] [40243.628188] __prep_cap+0x3fd/0x4a0 [40243.628789] ? do_raw_spin_unlock+0x4e/0xe0 [40243.629474] ceph_check_caps+0x46a/0xc80 [40243.630094] ? __lock_acquire+0x4a2/0x2650 [40243.630773] ? find_held_lock+0x31/0x90 [40243.631347] ? handle_cap_grant+0x79f/0x1060 [40243.632068] ? lock_release+0xd9/0x300 [40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340 [40243.633429] ? lock_release+0xd9/0x300 [40243.634052] handle_cap_grant+0xcf6/0x1060 [40243.634745] ceph_handle_caps+0x122b/0x2110 [40243.635415] mds_dispatch+0x5bd/0x2160 [40243.636034] ? ceph_con_process_message+0x65/0x190 [40243.636828] ? lock_release+0xd9/0x300 [40243.637431] ceph_con_process_message+0x7a/0x190 [40243.638184] ? kfree+0x311/0x4f0 [40243.638749] ? kfree+0x311/0x4f0 [40243.639268] process_message+0x16/0x1a0 [40243.639915] ? sg_free_table+0x39/0x90 [40243.640572] ceph_con_v2_try_read+0xf58/0x2120 [40243.641255] ? lock_acquire+0xc8/0x300 [40243.641863] ceph_con_workfn+0x151/0x820 [40243.642493] process_one_work+0x22f/0x630 [40243.643093] ? process_one_work+0x254/0x630 [40243.643770] worker_thread+0x1e2/0x400 [40243.644332] ? __pfx_worker_thread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ? __pfx_kthread+0x10/0x10 [40243.646125] ret_from_fork+0x3f8/0x480 [40243.646752] ? __pfx_kthread+0x10/0x10 [40243.647316] ? __pfx_kthread+0x10/0x10 [40243.647919] ret_from_fork_asm+0x1a/0x30 [40243.648556] [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore [40243.654766] ---[ end trace 0000000000000000 ]--- Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the required_blob_size computation to before the __build_xattrs() call, introducing a race. __build_xattrs() releases and reacquires i_ceph_lock during execution. In that window, handle_cap_grant() may update i_xattrs.blob with a newer MDS-provided blob and bump i_xattrs.version. When __build_xattrs() detects that index_version < version, it destroys and rebuilds the entire xattr rb-tree from the new blob, potentially increasing count, names_size, and vals_size. The prealloc_blob size check that follows still uses the stale required_blob_size computed before the rebuild, so it passes even when prealloc_blob is too small for the now-larger tree. After __set_xattr() adds one more xattr on top, __ceph_build_xattrs_blob() is called from the cap flush path and hits: BUG_ON(need > ci->i_xattrs.prealloc_blob->alloc_len); Fix this by recomputing required_blob_size after __build_xattrs() returns, using the current tree state. Also re-validate against m_max_xattr_size to fall back to the sync path if the rebuilt tree now exceeds the MDS limit. Cc: stable@vger.kernel.org Fixes: d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") Signed-off-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit bc7abce4460e490dcb579eec770f175b150b685f Author: Viacheslav Dubeyko Date: Thu Apr 9 12:26:02 2026 -0700 ceph: fix a buffer leak in __ceph_setxattr() commit 5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e upstream. The old_blob in __ceph_setxattr() can store ci->i_xattrs.prealloc_blob value during the retry. However, it is never called the ceph_buffer_put() for the old_blob object. This patch fixes the issue of the buffer leak. Cc: stable@vger.kernel.org Signed-off-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit df03d67dc63722845cb9fe59d815d1225b04fd54 Author: Qu Wenruo Date: Thu Apr 30 10:37:22 2026 +0930 btrfs: only release the dirty pages io tree after successful writes commit 4066c55e109475a06d18a1f127c939d551211956 upstream. [WARNING] With extra warning on dirty extent buffers at umount (aka, the next patch in the series), test case generic/388 can trigger the following warning about dirty extent buffers at unmount time: BTRFS critical (device dm-2 state E): emergency shutdown BTRFS error (device dm-2 state E): error while writing out transaction: -30 BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction. BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30) BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem BTRFS info (device dm-2 state EA): forced readonly BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c ------------[ cut here ]------------ WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368 CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G OE 7.1.0-rc1-custom+ #372 PREEMPT(full) 2de38db8d1deae71fde295430a0ff3ab98ccf596 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs] Call Trace: close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] generic_shutdown_super+0x89/0x1a0 kill_anon_super+0x16/0x40 btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] deactivate_locked_super+0x2d/0xb0 cleanup_mnt+0xdc/0x140 task_work_run+0x5a/0xa0 exit_to_user_mode_loop+0x123/0x4b0 do_syscall_64+0x243/0x7c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7 I'm using a stripped down version, which seems to trigger the warning more reliably: _fsstress_pid="" workload() { dmesg -C mkfs.btrfs -f -K $dev > /dev/null echo 1 > /sys/kernel/debug/clear_warn_once mount $dev $mnt $fsstress -w -n 1024 -p 4 -d $mnt & _fsstress_pid=$! sleep 0 $godown $mnt pkill --echo -PIPE fsstress > /dev/null wait $_fsstress_pid unset _fsstress_pid umount $mnt if dmesg | grep -q "WARNING"; then fail fi } for (( i = 0; i < $runtime; i++ )); do echo "=== $i/$runtime ===" workload done [CAUSE] Inside btrfs_write_and_wait_transaction(), we first try to write all dirty ebs, then wait for them to finish. After that we call btrfs_extent_io_tree_release() to free all extent states from dirty_pages io tree. However if we hit an error from btrfs_write_marked_extent(), then we still call btrfs_extent_io_tree_release() to clear that dirty_pages io tree, which may contain dirty records that we haven't yet submitted. Furthermore, the later transaction cleanup path will utilize that dirty_pages io tree to properly cleanup those dirty ebs, but since it's already empty, no dirty ebs are properly cleaned up, thus will later trigger the warnings inside invalidate_btree_folios(). [FIX] Normally such dirty ebs won't cause problems, as when the iput() is called on the btree inode, the dirty ebs will be forcibly written back, and since the fs is already in an error status, such writeback will not reach disk and finish immediately. But it's still better to get rid of such dirty ebs, if we ended up with dirty ebs but the fs is not in an error status, then such writeback at iput() time will be too late, as all workers are already stopped but writeback will utilize workers, which will lead to NULL pointer dereferences. Instead of unconditionally calling btrfs_extent_io_tree_release(), only call it if btrfs_write_and_wait_transaction() finished successfully, so that @dirty_pages extent io tree is kept untouched for transaction cleanup. CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 940bfe359f87d36b7763aa10d120942dbd7f8a36 Author: Cássio Gabriel Date: Mon May 11 01:36:37 2026 -0300 ALSA: usb-audio: qcom: Check offload mapping failures commit 814b2c9b30e56074e11fc0a6e5419b3fee0639bc upstream. uaudio_transfer_buffer_setup() calls dma_get_sgtable() and then passes the sg_table to uaudio_iommu_map_xfer_buf() without checking whether sg table construction succeeded. If dma_get_sgtable() fails, the sg_table contents are not valid. uaudio_iommu_map_pa() also ignores iommu_map() failures for the event and transfer rings and still returns the allocated IOVA to the QMI response. That can expose an unmapped IOVA to the audio DSP. For transfer rings, the failed mapping also leaves the IOVA allocator state marked in use. Check both operations. Free the coherent transfer buffer when sg table construction fails, free the sg table when transfer-buffer IOMMU mapping fails, and release the transfer-ring IOVA if iommu_map() fails. Also return the existing event-ring IOVA when the event ring is already mapped, matching the pre-split helper behavior. Fixes: 326bbc348298 ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Fixes: 44499ecb4f28 ("ALSA: usb: qcom: Fix false-positive address space check") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260511-alsa-usb-qcom-offload-map-errors-v1-1-6502695e58bc@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c59159ce10e75b568cd0d4b29efcb0fb0ddecc94 Author: Cássio Gabriel Date: Thu May 7 00:40:51 2026 -0300 ALSA: usb-audio: Bound MIDI endpoint descriptor scans commit d6854daa67be623860f4e1873fd3d3c275aba4ed upstream. snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint descriptor size before using baAssocJackID[], but the descriptor walker can still return a class-specific endpoint descriptor whose bLength exceeds the remaining bytes in the endpoint-extra scan. That leaves later flexible-array reads bounded by bLength, but not by the remaining bytes in the endpoint-extra scan. Stop walking when bLength is zero or extends past the remaining endpoint-extra scan. Fixes: 5c6cd7021a05 ("ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-1-329d7348160e@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 17e76b19de1aff5ff4de64d269290bd1b07a01d3 Author: Cássio Gabriel Date: Thu May 7 00:40:52 2026 -0300 ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans commit 918be519c7876329e1b6e2ea1c59f0b75e792dca upstream. The USB MIDI 2.0 endpoint parser has the same descriptor walking pattern as the legacy MIDI parser. It validates bLength against bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the remaining bytes in the endpoint-extra scan. A malformed device can therefore make later baAssoGrpTrmBlkID[] reads consume bytes past the walked descriptor. Reject zero-length and overlong descriptors while walking endpoint extras. Fixes: ff49d1df79ae ("ALSA: usb-audio: USB MIDI 2.0 UMP support") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-2-329d7348160e@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5264be829073c3e5a2f232e24ff41ed9aada6b07 Author: Markus Kramer Date: Thu May 14 00:28:18 2026 +0200 ALSA: hda/realtek: Add quirk for Samsung Galaxy Book5 360 headphone commit fd87b510f5f543125ecf51e7c706a9f4bc3352be upstream. The Samsung Galaxy Book5 360 (NP750QHA, PCI subsystem ID 0x144d:0xc902) has severe audio distortion on the 3.5mm headphone jack. Applying ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET corrects the output path configuration, consistent with fixes already applied to other Samsung Galaxy Book models using the same ALC256 codec. Cc: stable@vger.kernel.org Link: https://github.com/thesofproject/linux/issues/5648 Signed-off-by: Markus Kramer Link: https://patch.msgid.link/20260513222818.14351-1-linux@markus-kramer.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a8c1139170c6e0b0432582922d649308f3f96dc6 Author: Adrien Burnett Date: Thu May 14 18:59:05 2026 +0200 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion Laptop 16-ag0xxx commit 7d1051ad68df3d584b5f24bfa1fb19f3a24db278 upstream. Add a SND_PCI_QUIRK entry for the HP Pavilion Laptop 16-ag0xxx (subsystem 0x103c:0x8cbc, Realtek ALC245). The ALC245_FIXUP_HP_X360_MUTE_LEDS fixup is already used by the neighbouring HP Pavilion Aero Laptop 13-bg0xxx (0x103c:0x8cbd); it chains the master-mute COEF handler with the GPIO mic-mute LED handler, which is what this machine needs. Tested on the affected hardware: both the mute and mic-mute key LEDs respond correctly to the keyboard hotkeys after this change. Cc: Signed-off-by: Adrien Burnett Link: https://patch.msgid.link/20260514165905.21175-1-an.arctic.pigeon@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e9cfa42b15fa6167e7410799d01fa211e35f0a58 Author: Gyeyoung Baek Date: Sun Apr 19 16:17:15 2026 +0900 accel/rocket: Fix prep_bo ioctl leaking positive return from dma_resv_wait_timeout() commit 74570e12b4705ea11dcdfbfbd0a0b0fdaeff3059 upstream. dma_resv_wait_timeout() returns a positive 'remaining jiffies' value on success, 0 on timeout, and -errno on failure. rocket_ioctl_prep_bo() returns this 'long' result from an int-typed ioctl handler, so positive values reach userspace as bogus errors. Explicitly set ret to 0 on the success path. Fixes: 525ad89dd904 ("accel/rocket: Add IOCTLs for synchronizing memory accesses") Cc: stable@vger.kernel.org Signed-off-by: Gyeyoung Baek Reviewed-by: Tomeu Vizoso Link: https://patch.msgid.link/c0ebf83b345721701b22d8f5bc41c52c0ecf5e16.1776581974.git.gye976@gmail.com Signed-off-by: Steven Price Signed-off-by: Greg Kroah-Hartman commit 78f19bd974045a8da6f6455eabf0f896c6ff7825 Author: Derek J. Clark Date: Sun May 10 04:25:39 2026 +0000 platform/x86: lenovo-wmi-other: Limit adding attributes to supported devices commit 03bb5147da083cb91e5c8c2599fcb2f8fd05cb8f upstream. Adds lwmi_is_attr_01_supported, and only creates the attribute subfolder if the attribute is supported by the hardware. Due to some poorly implemented BIOS this is a multi-step sequence of events. This is because: - Some BIOS support getting the capability data from custom mode (0xff), while others only support it in no-mode (0x00). - Some BIOS support get/set for the current value from custom mode (0xff), while others only support it in no-mode (0x00). - Some BIOS report capability data for a method that is not fully implemented. - Some BIOS have methods fully implemented, but no complimentary capability data. To ensure we only expose fully implemented methods with corresponding capability data, we check each outcome before reporting that an attribute can be supported. Checking for lwmi_is_attr_01_supported during remove is not done to ensure that we don't attempt to call cd01 or send WMI events if one of the interfaces being removed was the cause of the driver unloading. Fixes: edc4b183b794 ("platform/x86: Add Lenovo Other Mode WMI Driver") Reported-by: Kurt Borja Closes: https://lore.kernel.org/platform-driver-x86/DG60P3SHXR8H.3NSEHMZ6J7XRC@gmail.com/ Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang Tested-by: Rong Zhang Reviewed-by: Mark Pearson Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-10-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 1fd8574fccec72da59412644599fd73b254d8995 Author: Derek J. Clark Date: Sun May 10 04:25:38 2026 +0000 platform/x86: lenovo-wmi-other: Add Attribute ID helper functions commit 30a4ad208a7f7bdb790cd31d368595890045334f upstream. Adds lwmi_attr_id() function. In the same vein as LWMI_ATTR_ID_FAN_RPM(), but as a generic, to de-duplicate attribute_id assignment boilerplate. Adds tunable_attr_01_id() function that breaks out the members of a tunable_attr_01 struct and passes them to lwmi_attr_id(). No functional change intended. Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang Tested-by: Rong Zhang Reviewed-by: Mark Pearson Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-9-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 5d2b5e83c3f01d41a200fc0e918079189744f4e1 Author: Derek J. Clark Date: Sun May 10 04:25:35 2026 +0000 platform/x86: lenovo-wmi-other: Fix tunable_attr_01 struct members commit 71f3843e0f81e3c097a088c1121154bb9a44da0a upstream. In struct tunable_attr_01 the capdata pointer is unused and the size of the id members is u32 when it should be u8. Fix these prior to adding additional members. No functional change intended. Reviewed-by: Mark Pearson Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang Tested-by: Rong Zhang Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-6-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 9de8953276a64823dd374e7c3630ebe18922607b Author: Derek J. Clark Date: Sun May 10 04:25:34 2026 +0000 platform/x86: lenovo-wmi-other: Zero initialize WMI arguments commit 816fbd5dacee977ca56bab79bf97f71f2f7ac24e upstream. Adds explicit initialization of wmi_method_args_32 declarations with zero values to prevent uninitialized data from being sent to the device BIOS when passed. No functional change intended. Reviewed-by: Mark Pearson Fixes: 22024ac5366f ("platform/x86: Add Lenovo Gamezone WMI Driver") Fixes: edc4b183b794 ("platform/x86: Add Lenovo Other Mode WMI Driver") Reported-by: Rong Zhang Closes: https://lore.kernel.org/platform-driver-x86/95c7e7b539dd0af41189c754fcd35cec5b6fe182.camel@rong.moe/ Cc: stable@vger.kernel.org Reviewed-by: Rong Zhang Tested-by: Rong Zhang Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-5-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit d9d404cfdfe184d4fbbcbfa4cbf9221ad51f8a5a Author: Rong Zhang Date: Sun May 10 04:25:33 2026 +0000 platform/x86: lenovo-wmi-other: Balance component bind and unbind commit 2fe2504abcfa4f82a4208e8d0c21ec0f22baca43 upstream. When lwmi_om_master_bind() fails, the master device's components are left bound, with the aggregate device destroyed due to the failure (found by sashiko.dev [1]). Balance calls to component_bind_all() and component_unbind_all() when an error is propagated to the component framework. No functional change intended. Reviewed-by: Mark Pearson Reviewed-by: Ilpo Järvinen Fixes: edc4b183b794 ("platform/x86: Add Lenovo Other Mode WMI Driver") Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260331181208.421552-1-derekjohn.clark%40gmail.com [1] Signed-off-by: Rong Zhang Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-4-derekjohn.clark@gmail.com Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit af75c40f62216ee2a08585acc7f7e7b9713b3b4f Author: Rong Zhang Date: Sun May 10 04:25:32 2026 +0000 platform/x86: lenovo-wmi-other: Balance IDA id allocation and free commit 55a279ae819adaea99a94c609f31970b70e0ec0c upstream. Currently, the IDA id is only freed on wmi-other device removal or failure to create firmware-attributes device, kset, or attributes. It leaks IDA ids if the wmi-other device is bound multiple times, as the unbind callback never frees the previously allocated IDA id. Additionally, if the wmi-other device has failed to create a firmware-attributes device before it gets removed, the wmi-device removal callback double frees the same IDA id. These bugs were found by sashiko.dev [1]. Fix them by moving ida_free() into lwmi_om_fw_attr_remove() so it is balanced with ida_alloc() in lwmi_om_fw_attr_add(). With them fixed, properly set and utilize the validity of priv->ida_id to balance firmware-attributes registration and removal, without relying on propagating the registration error to the component framework, which is more reliable and aligns with the hwmon device registration and removal sequences. No functional change intended. Reviewed-by: Mark Pearson Fixes: edc4b183b794 ("platform/x86: Add Lenovo Other Mode WMI Driver") Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260331181208.421552-1-derekjohn.clark%40gmail.com [1] Signed-off-by: Rong Zhang Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-3-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 40a984dd0602e238ad893b167751620e751d1199 Author: Rong Zhang Date: Sun May 10 04:25:31 2026 +0000 platform/x86: lenovo-wmi-helpers: Fix memory leak in lwmi_dev_evaluate_int() commit 0c3887a134f191723b53e2a47e501b534c8723ee upstream. lwmi_dev_evaluate_int() leaks output.pointer when retval == NULL (found by sashiko.dev [1]). Fix it by moving `ret_obj = output.pointer' outside of the `if (retval)' block so that it is always freed by the __free cleanup callback. No functional change intended. Reviewed-by: Mark Pearson Fixes: e521d16e76cd ("platform/x86: Add lenovo-wmi-helpers") Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260331181208.421552-1-derekjohn.clark%40gmail.com [1] Signed-off-by: Rong Zhang Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-2-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit d692b303e4543d4fb62360f902f3fb08740163c3 Author: Derek J. Clark Date: Sun May 10 04:25:37 2026 +0000 platform/x86: lenovo-wmi-helpers: Move gamezone enums to wmi-helpers commit 7e27896e16a1c450085c3fe020eeb1b223880f37 upstream. In a later patch in the series the thermal mode enum will be accessed across three separate drivers (wmi-capdata, wmi-gamezonem and wmi-other). An additional patch in the series will also add a function prototype that needs to reference this enum in wmi-helpers.h. To avoid having all these drivers begin to import each others headers, and to avoid declaring an opaque enum to hande the second case, move the thermal mode enum to helpers where it can be safely accessed by everything that needs it from a single import. While at it, since the gamezone_events_type enum is the only remaining item in the header, move that as well and remove the gamezone header entirely. Cc: stable@vger.kernel.org Reviewed-by: Mark Pearson Reviewed-by: Rong Zhang Tested-by: Rong Zhang Signed-off-by: Derek J. Clark Link: https://patch.msgid.link/20260510042546.436874-8-derekjohn.clark@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit da0c758f3bd477a72ffe5044a6f4902d156756f4 Author: Srinivas Pandruvada Date: Thu Apr 30 08:11:01 2026 -0700 platform/x86: intel: Move debugfs register before creating devices commit ad3bff944c0f4f2e913298a9664391af32f87491 upstream. It is possible that the driver handling device is enumerated before registering debugfs. If the driver wants to access debugfs by calling tpmi_get_debugfs_dir(), this will return error in this case. Hence register debugfs before creating devices. Fixes: 811f67c51636 ("platform/x86/intel/tpmi: Add new auxiliary driver for performance limits") Signed-off-by: Srinivas Pandruvada Cc: Stable@vger.kernel.org Link: https://patch.msgid.link/20260430151103.1549733-2-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 0124a09e3e5f5f6080efe9663b27af27933f8382 Author: Thomas Hellström Date: Tue Apr 28 11:44:42 2026 +0200 drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure commit b2ed01e7ad3de80333e9b962a44024b094bc0b2b upstream. When ttm_tt_swapout() fails, the current code calls ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail() to restore the resource's bulk_move membership. However, ttm_resource_move_to_lru_tail() places the resource at the tail of the LRU list which, relative to the walk cursor's hitch node (placed immediately after the resource when it was yielded), puts the resource *in front of the* the hitch. The next list_for_each_entry_continue() from the hitch finds the same resource again, causing an infinite loop. Fix by deferring del_bulk_move to the success path only. On the success path, TTM_TT_FLAG_SWAPPED has just been set by ttm_tt_swapout() but the resource is still tracked in the bulk_move range, so ttm_resource_del_bulk_move()'s !ttm_resource_unevictable() guard would incorrectly skip the removal. Introduce ttm_resource_del_bulk_move_unevictable() which bypasses that guard. Reported-by: Jatin Kataria Fixes: fc5d96670eb2 ("drm/ttm: Move swapped objects off the manager's LRU list") Cc: Christian König Cc: Matthew Brost Cc: Cc: # v6.13+ Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Christian König Tested-by: Boqun Feng Link: https://patch.msgid.link/20260428094442.16985-1-thomas.hellstrom@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 30bb2ec6695d62f63db4aa6179c4626834ed0cd6 Author: Mikhail Gavrilov Date: Tue May 5 09:05:37 2026 +0800 drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED commit 183182235f6d53bac62c6c39014738a54a68dfa6 upstream. [Why] dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(), which disables local softirqs. The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path, which calls BUG_ON(in_interrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash. [How] Wrap the dc_state_create_phantom_plane() call with the DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during this memory allocation. Fixes: 235c67634230 ("drm/amd/display: add DCN32/321 specific files for Display Core") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/4470 Reviewed-by: Aurabindo Pillai Signed-off-by: Mikhail Gavrilov Signed-off-by: James Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b15dda81ae9d21278e370305f0d91cd2a62127fa Author: Chaitanya Kumar Borah Date: Tue May 5 14:39:20 2026 +0530 drm/i915/dp: Fix VSC dynamic range signaling for RGB formats commit 1ae15b6c7965d137eef21f2cc7d367b29cb88369 upstream. For RGB, set dynamic_range to CTA or VESA based on crtc_state->limited_color_range so sinks apply correct quantization. YCbCr remains limited (CTA) range. (DP v1.4, Table 5-1) v2: - Added Reported-by and Tested-by tags v3: - Add back YCbCr comment(Suraj) Cc: stable@vger.kernel.org #v5.8+ Reported-by: DeepChirp Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15874 Tested-by: DeepChirp Fixes: 9799c4c3b76e ("drm/i915/dp: Add compute routine for DP VSC SDP") Assisted-by: GitHub-Copilot:GPT-5.4 Signed-off-by: Chaitanya Kumar Borah Reviewed-by: Suraj Kandpal Signed-off-by: Suraj Kandpal Link: https://patch.msgid.link/20260505090920.2479112-1-chaitanya.kumar.borah@intel.com (cherry picked from commit 38e10ddae6f8d42a2e8437fcd25a1cac51106c64) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 88e9ced738a5882fa42bb9ad7bb27d0396d098c7 Author: Guangshuo Li Date: Thu May 7 18:06:03 2026 +0800 drm/bridge: imx8qxp-pxl2dpi: avoid ERR_PTR with device_node cleanup commit 53597deca0e38c30e6cd4ba2114fa42d2bcd85bb upstream. imx8qxp_pxl2dpi_get_available_ep_from_port() returns ERR_PTR() on errors. imx8qxp_pxl2dpi_find_next_bridge() stores its return value in a __free(device_node) variable before checking IS_ERR(). When the function returns on the error path, the cleanup action calls of_node_put() on the ERR_PTR() value. Do not let a device_node cleanup variable hold error pointers. Change imx8qxp_pxl2dpi_get_available_ep_from_port() to return an int and pass the endpoint node through an output argument. Initialize the output argument to NULL so callers hold either NULL on error paths or a valid device_node pointer on successful path. Fixes: ceea3f7806a10 ("drm/bridge: imx8qxp-pxl2dpi: simplify put of device_node pointers") Cc: stable@vger.kernel.org Reviewed-by: Liu Ying Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260507100604.667731-1-lgs201920130244@gmail.com Signed-off-by: Liu Ying Signed-off-by: Greg Kroah-Hartman commit 38f12d0e10d83b66fa1466400d876a3a8da31542 Author: Edward Adam Davis Date: Wed May 13 12:30:50 2026 +0800 drm: Replace old pointer to new idr commit dc366607c41c45fd0ae6f3db090f31dd611b644a upstream. Commit 5e28b7b94408 introduced a logical error by failing to replace the newly generated IDR pointer to old id's pointer at the correct location within the "change handle" logic; this resulted in the issue reported by syzbot [1]. Specifically, the new IDR object pointer is intended to replace the original id's pointer during the normal execution flow. Additionally, an unnecessary conditional check for the ret exit path has been removed. [1] !RB_EMPTY_ROOT(&prime_fpriv->dmabufs) WARNING: drivers/gpu/drm/drm_prime.c:224 at drm_prime_destroy_file_private+0x48/0x60 drivers/gpu/drm/drm_prime.c:224, CPU#0: syz.0.17/5833 Call Trace: drm_file_free.part.0+0x7e6/0xcc0 drivers/gpu/drm/drm_file.c:269 drm_file_free drivers/gpu/drm/drm_file.c:237 [inline] drm_close_helper.isra.0+0x186/0x200 drivers/gpu/drm/drm_file.c:290 drm_release+0x1ab/0x360 drivers/gpu/drm/drm_file.c:438 Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") Reported-by: syzbot+d7c9eed171647e421013@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d7c9eed171647e421013 Cc: stable@vger.kernel.org Tested-by: syzbot+d7c9eed171647e421013@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: Dave Airlie Link: https://patch.msgid.link/tencent_C267296443AAA4567771176886DFF364A305@qq.com Signed-off-by: Greg Kroah-Hartman commit aadc67032d35609303d6eb60e9179a3a2cef17db Author: Myeonghun Pak Date: Wed May 13 15:57:00 2026 +0900 drm/loongson: Use managed KMS polling commit 0a9c56dd387605d17dabeedd9fdd2c4c1d0bab7b upstream. lsdc_pci_probe() initializes KMS polling before setting up vblank support, requesting the IRQ and registering the DRM device. If any of those later steps fails, probe returns without finalizing polling. The driver also never finalizes polling on regular removal. Use drmm_kms_helper_poll_init() so polling is tied to the DRM device lifetime and automatically finalized on probe failure and device removal. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: f39db26c5428 ("drm: Add kms driver for loongson display controller") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Reviewed-by: Thomas Zimmermann Acked-by: Jianmin Lv Reviewed-by: Huacai Chen Signed-off-by: Myeonghun Pak Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260513065706.23803-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1b9331b16b0ed9414dcf7583d8134bdfeb117aae Author: Ye Bin Date: Thu May 14 21:14:18 2026 +0800 smb/client: fix possible infinite loop and oob read in symlink_data() commit 7d9a7f1f96cd617ee9e75bb22217c709038e26b8 upstream. On 32-bit architectures, the infinite loop is as follows: len = p->ErrorDataLength == 0xfffffff8 u8 *next = p->ErrorContextData + len next == p On 32-bit architectures, the out-of-bounds read is as follows: len = p->ErrorDataLength == 0xfffffff0 u8 *next = p->ErrorContextData + len next == (u8 *)p - 8 Reported-by: ChenXiaoSong Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+") Cc: stable@vger.kernel.org Signed-off-by: Ye Bin Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5b848c029e3475a6b9933dc7ddfe0d150831a158 Author: Nick Chan Date: Thu May 14 21:16:01 2026 +0800 nvme-apple: Reset q->sq_tail during queue init commit a6ab75639e23169a741b0b2e12191fd8acb32c73 upstream. Fixes a "duplicate tag error for tag 0" firmware crash during controller reset while setting up a queue on Apple A11 / T8015 caused by stale entries in the submission queue due to an invalid sq_tail offset after reset. Fixes: 04d8ecf37b5e ("nvme: apple: Add Apple A11 support") Cc: stable@vger.kernel.org Suggested-by: Yuriy Havrylyuk Reviewed-by: Sven Peter Signed-off-by: Nick Chan Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit e193447ac6c9de528e4776161041aea37c7d17ca Author: Pauli Virtanen Date: Fri Apr 24 22:24:29 2026 +0300 Bluetooth: btmtk: accept too short WMT FUNC_CTRL events commit e3ac0d9f1a205f33a43fba3b79ef74d2f604c78b upstream. MT7925 (USB ID 0e8d:e025) on fw version 20260106153314 sends WMT FUNC_CTRL events that are missing the status field. Prior to commit 006b9943b982 ("Bluetooth: btmtk: validate WMT event SKB length before struct access") the status was read from out-of-bounds of SKB data, which usually would result to success with BTMTK_WMT_ON_UNDONE, although I don't know the intent here. The bounds check added in that commit returns with error instead, producing "Bluetooth: hci0: Failed to send wmt func ctrl (-22)" and makes the device unusable. Fix the regression by interpreting too short packet as status BTMTK_WMT_ON_UNDONE, which makes the device work normally again. Fixes: 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length before struct access") Signed-off-by: Pauli Virtanen Tested-by: Mikhail Gavrilov # MT7922 (0489:e0e2) Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 0e2253b942be7668a26b70631e30a8d5eaf1ea69 Author: Michael Tretter Date: Fri Nov 7 11:34:34 2025 +0100 media: staging: imx: configure src_mux in csi_start [ Upstream commit ebeec2b000a90cd8aae86d1931ff5ef23af8284e ] After media_pipeline_start() was called, the media graph is assumed to be validated. It won't be validated again if a second stream starts. The imx-media-csi driver, however, changes hardware configuration in the link_validate() callback. This can result in started streams with misconfigured hardware. In the concrete example, the ipu2_csi1 is driven by a parallel video input. After the media pipeline has been started with this configuration, a second stream is configured to use ipu1_csi0 with MIPI-CSI input from imx6-mipi-csi2. This may require the reconfiguration of ipu1_csi0 with ipu_set_csi_src_mux(). Since the media pipeline is already running, link_validate won't be called, and the ipu1_csi0 won't be reconfigured. The resulting video is broken, because the ipu1_csi0 is misconfigured, but no error is reported. Move ipu_set_csi_src_mux from csi_link_validate to csi_start to ensure that input to ipu1_csi0 is configured correctly when starting the stream. This is a local reconfiguration in ipu1_csi0 and is possible while the media pipeline is running. Since csi_start() is called with priv->lock already locked, csi_set_src() must not lock priv->lock again. Thus, the mutex_lock() is dropped. Signed-off-by: Michael Tretter Fixes: 4a34ec8e470c ("[media] media: imx: Add CSI subdev driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Reviewed-by: Philipp Zabel Signed-off-by: Frank Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 6f123b59e30f03b42ecb2d379d2eab36f56b0bd3 Author: Igor Pylypiv Date: Sun Apr 12 08:36:37 2026 -0700 ata: libata-scsi: fix requeue of deferred ATA PASS-THROUGH commands [ Upstream commit 8ebf408e7d463eee02c348a3c8277b95587b710d ] Commit 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") introduced ata_scsi_requeue_deferred_qc() to handle commands deferred during resets or NCQ failures. This deferral logic completed commands with DID_SOFT_ERROR to trigger a retry in the SCSI mid-layer. However, DID_SOFT_ERROR is subject to scsi_cmd_retry_allowed() checks. ATA PASS-THROUGH commands sent via SG_IO ioctl have scmd->allowed set to zero. This causes the mid-layer to fail the command immediately instead of retrying, even though the command was never actually issued to the hardware. Switch to DID_REQUEUE to ensure these commands are inserted back into the request queue regardless of retry limits. Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Reviewed-by: Damien Le Moal Signed-off-by: Igor Pylypiv Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit 074d60a49e54cbc2c988046092c5a87e6dcf6e7a Author: Nathan Chancellor Date: Sun May 17 13:51:01 2026 +0900 HID: core: Fix size_t specifier in hid_report_raw_event() [ Upstream commit 4d3a2a466b8d68d852a1f3bbf11204b718428dc4 ] When building for 32-bit platforms, for which 'size_t' is 'unsigned int', there are warnings around using the incorrect format specifier to print bsize in hid_report_raw_event(): drivers/hid/hid-core.c:2054:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat] 2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n", | ~~~ | %zu 2054 | report->id, csize, bsize); | ^~~~~ drivers/hid/hid-core.c:2076:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat] 2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n", | ~~~ | %zu 2076 | report->id, rsize, bsize); | ^~~~~ Use the proper 'size_t' format specifier, '%zu', to clear up the warnings. Cc: stable@vger.kernel.org Fixes: 2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event") Reported-by: Miguel Ojeda Closes: https://lore.kernel.org/20260516020430.110135-1-ojeda@kernel.org/ Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit fb742945d61a05de8598f73f9788514a642546a4 Author: Thomas Gleixner Date: Sat May 16 18:04:01 2026 +0200 rseq: Reenable performance optimizations conditionally commit 99428157dcf32fdac97355aa1cc1364dbc9e073c upstream. Due to the incompatibility with TCMalloc the RSEQ optimizations and extended features (time slice extensions) have been disabled and made run-time conditional. The original RSEQ implementation, which TCMalloc depends on, registers a 32 byte region (ORIG_RSEG_SIZE). This region has a 32 byte alignment requirement. The extension safe newer variant exposes the kernel RSEQ feature size via getauxval(AT_RSEQ_FEATURE_SIZE) and the alignment requirement via getauxval(AT_RSEQ_ALIGN). The alignment requirement is that the registered RSEQ region is aligned to the next power of two of the feature size. The kernel currently has a feature size of 33 bytes, which means the alignment requirement is 64 bytes. The TCMalloc RSEQ region is embedded into a cache line aligned data structure starting at offset 32 bytes so that bytes 28-31 and the cpu_id_start field at bytes 32-35 form a 64-bit little endian pointer with the top-most bit (63 set) to check whether the kernel has overwritten cpu_id_start with an actual CPU id value, which is guaranteed to not have the top most bit set. As this is part of their performance tuned magic, it's a pretty safe assumption, that TCMalloc won't use a larger RSEQ size. This allows the kernel to declare that registrations with a size greater than the original size of 32 bytes, which is the cases since time slice extensions got introduced, as RSEQ ABI v2 with the following differences to the original behaviour: 1) Unconditional updates of the user read only fields (CPU, node, MMCID) are removed. Those fields are only updated on registration, task migration and MMCID changes. 2) Unconditional evaluation of the criticial section pointer is removed. It's only evaluated when user space was interrupted and was scheduled out or before delivering a signal in the interrupted context. 3) The read/only requirement of the ID fields is enforced. When the kernel detects that userspace manipulated the fields, the process is terminated. This ensures that multiple entities (libraries) can utilize RSEQ without interfering. 4) Todays extended RSEQ feature (time slice extensions) and future extensions are only enabled in the v2 enabled mode. Registrations with the original size of 32 bytes operate in backwards compatible legacy mode without performance improvements and extended features. Unfortunately that also affects users of older GLIBC versions which register the original size of 32 bytes and do not evaluate the kernel required size in the auxiliary vector AT_RSEQ_FEATURE_SIZE. That's the result of the lack of enforcement in the original implementation and the unwillingness of a single entity to cooperate with the larger ecosystem for many years. Implement the required registration changes by restructuring the spaghetti code and adding the size/version check. Also add documentation about the differences of legacy and optimized RSEQ V2 mode. Thanks to Mathieu for pointing out the ORIG_RSEQ_SIZE constraints! Fixes: d6200245c75e ("rseq: Allow registering RSEQ with slice extension") Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Reviewed-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Link: https://patch.msgid.link/20260428224427.927160119%40kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d242126fd21ab8f1631fdbc8589e43a9d4229f3b Author: Thomas Gleixner Date: Sat May 16 18:03:56 2026 +0200 rseq: Implement read only ABI enforcement for optimized RSEQ V2 mode commit 82f572449cfe75f12ea985986da60e11f308f77d upstream. The optimized RSEQ V2 mode requires that user space adheres to the ABI specification and does not modify the read-only fields cpu_id_start, cpu_id, node_id and mm_cid behind the kernel's back. While the kernel does not rely on these fields, the adherence to this is a fundamental prerequisite to allow multiple entities, e.g. libraries, in an application to utilize the full potential of RSEQ without stepping on each other toes. Validate this adherence on every update of these fields. If the kernel detects that user space modified the fields, the application is force terminated. Fixes: d6200245c75e ("rseq: Allow registering RSEQ with slice extension") Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Reviewed-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Link: https://patch.msgid.link/20260428224427.845230956%40kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 663121edad54bd1a3eada42022b20fb4f00e9ec0 Author: Thomas Gleixner Date: Sat May 16 18:03:50 2026 +0200 rseq: Revert to historical performance killing behaviour commit b9eac6a9d93c952c4b7775a24d5c7a1bbf4c3c00 upstream. The recent RSEQ optimization work broke the TCMalloc abuse of the RSEQ ABI as it not longer unconditionally updates the CPU, node, mm_cid fields, which are documented as read only for user space. Due to the observed behavior of the kernel it was possible for TCMalloc to overwrite the cpu_id_start field for their own purposes and rely on the kernel to update it unconditionally after each context switch and before signal delivery. The RSEQ ABI only guarantees that these fields are updated when the data changes, i.e. the task is migrated or the MMCID of the task changes due to switching from or to per CPU ownership mode. The optimization work eliminated the unconditional updates and reduced them to the documented ABI guarantees, which results in a massive performance win for syscall, scheduling heavy work loads, which in turn breaks the TCMalloc expectations. There have been several options discussed to restore the TCMalloc functionality while preserving the optimization benefits. They all end up in a series of hard to maintain workarounds, which in the worst case introduce overhead for everyone, e.g. in the scheduler. The requirements of TCMalloc and the optimization work are diametral and the required work arounds are a maintainence burden. They end up as fragile constructs, which are blocking further optimization work and are pretty much guaranteed to cause more subtle issues down the road. The optimization work heavily depends on the generic entry code, which is not used by all architectures yet. So the rework preserved the original mechanism moslty unmodified to keep the support for architectures, which handle rseq in their own exit to user space loop. That code is currently optimized out by the compiler on architectures which use the generic entry code. This allows to revert back to the original behaviour by replacing the compile time constant conditions with a runtime condition where required, which disables the optimization and the dependend time slice extension feature until the run-time condition can be enabled in the RSEQ registration code on a per task basis again. The following changes are required to restore the original behavior, which makes TCMalloc work again: 1) Replace the compile time constant conditionals with runtime conditionals where appropriate to prevent the compiler from optimizing the legacy mode out 2) Enforce unconditional update of IDs on context switch for the non-optimized v1 mode 3) Enforce update of IDs in the pre signal delivery path for the non-optimized v1 mode 4) Enforce update of IDs in the membarrier(RSEQ) IPI for the non-optimized v1 mode 5) Make time slice and future extensions depend on optimized v2 mode This brings back the full performance problems, but preserves the v2 optimization code and for generic entry code using architectures also the TIF_RSEQ optimization which avoids a full evaluation of the exit to user mode loop in many cases. Fixes: 566d8015f7ee ("rseq: Avoid CPU/MM CID updates when no event pending") Reported-by: Mathias Stearn Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Reviewed-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Closes: https://lore.kernel.org/CAHnCjA25b+nO2n5CeifknSKHssJpPrjnf+dtr7UgzRw4Zgu=oA@mail.gmail.com Link: https://patch.msgid.link/20260428224427.517051752%40kernel.org Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit a0bf0fc174372df94b5fd94440825d2ebcf06de9 Author: Benjamin Tissoires Date: Mon May 4 10:47:23 2026 +0200 HID: core: introduce hid_safe_input_report() [ Upstream commit 206342541fc887ae919774a43942dc883161fece ] hid_input_report() is used in too many places to have a commit that doesn't cross subsystem borders. Instead of changing the API, introduce a new one when things matters in the transport layers: - usbhid - i2chid This effectively revert to the old behavior for those two transport layers. Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 710a946b1aa2c35dc56f86621f436938f31ba1a5 Author: Benjamin Tissoires Date: Mon May 4 10:47:22 2026 +0200 HID: pass the buffer size to hid_report_raw_event [ Upstream commit 2c85c61d1332e1e16f020d76951baf167dcb6f7a ] commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") enforced the provided data to be at least the size of the declared buffer in the report descriptor to prevent a buffer overflow. However, we can try to be smarter by providing both the buffer size and the data size, meaning that hid_report_raw_event() can make better decision whether we should plaining reject the buffer (buffer overflow attempt) or if we can safely memset it to 0 and pass it to the rest of the stack. Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires Acked-by: Johan Hovold Reviewed-by: Greg Kroah-Hartman Signed-off-by: Jiri Kosina Stable-dep-of: 206342541fc8 ("HID: core: introduce hid_safe_input_report()") Signed-off-by: Sasha Levin commit 19f3c8eebbdd7f7867f278b64ed4cab1b9b72dc5 Author: Qiang Ma Date: Tue May 12 09:53:13 2026 +0800 KVM: x86: Fix Xen hypercall tracepoint argument assignment commit 2b72f1674e427c56e3772c5ccf785fdda2138820 upstream. TRACE_EVENT(kvm_xen_hypercall) stores a5 in __entry->a4 instead of __entry->a5. That overwrites the recorded a4 argument and leaves a5 unset in the trace entry. Fix the typo so both arguments are captured correctly. Signed-off-by: Qiang Ma Link: https://patch.msgid.link/20260512015313.1685784-1-maqianga@uniontech.com/ Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit e7216651b94e92e5433fb2f54b77864642b4ea48 Author: Junrui Luo Date: Wed Apr 15 17:26:55 2026 +0800 KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic commit 16d990a15491cf76cd6eef0846e1b4100e63261a upstream. kvm_s390_pci_aif_enable(), kvm_s390_pci_aif_disable(), and aen_host_forward() index the GAIT by manually multiplying the index with sizeof(struct zpci_gaite). Since aift->gait is already a struct zpci_gaite pointer, this double-scales the offset, accessing element aisb*16 instead of aisb. This causes out-of-bounds accesses when aisb >= 32 (with ZPCI_NR_DEVICES=512) Fix by removing the erroneous sizeof multiplication. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Fixes: 73f91b004321 ("KVM: s390: pci: enable host forwarding of Adapter Event Notifications") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit ecf9b3ea7847fe14f34b8c41f00de1eb95c747da Author: Aaron Sacks Date: Tue May 12 02:07:42 2026 -0400 KVM: Reject wrapped offset in kvm_reset_dirty_gfn() commit 577a8d3bae0531f0e5ccfac919cd8192f920a804 upstream. kvm_reset_dirty_gfn() guards the gfn range with if (!memslot || (offset + __fls(mask)) >= memslot->npages) return; but offset is u64 and the addition is unchecked. The check can be silently bypassed by a u64 wrap. The dirty ring backing those entries is MAP_SHARED at KVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the slot and offset fields of any entry between when the kernel pushes them and when KVM_RESET_DIRTY_RINGS consumes them. On reset, kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds them straight back into this check; only the flags handshake is treated as the handover, the slot/offset payload is taken on trust. Crafting two entries entry[i].offset = 0xffffffffffffffc1 entry[i+1].offset = 0 makes the coalescing loop in kvm_dirty_ring_reset() compute delta = (s64)(0 - 0xffffffffffffffc1) = 63 which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the existing mask by setting bit 63. The trailing kvm_reset_dirty_gfn() call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63; the sum is 0 in u64 and the bounds check passes. That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked() unchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() == true, i.e. shadow paging, any VM that has allocated shadow roots, or a write-tracked slot -- it reaches gfn_to_rmap(), which indexes slot->arch.rmap[0][] with a near-U64_MAX gfn. That is an out-of-bounds load of a kvm_rmap_head, followed by a conditional clear of PT_WRITABLE_MASK in whatever the loaded pointer points at. The path is reachable from any process holding /dev/kvm. Range-check offset on its own first, so the addition cannot wrap. memslot->npages is bounded well below U64_MAX, so once offset < npages holds, offset + __fls(mask) (with __fls(mask) < BITS_PER_LONG) stays in range. Fixes: fb04a1eddb1a ("KVM: X86: Implement ring-based dirty memory tracking") Cc: stable@vger.kernel.org Signed-off-by: Aaron Sacks Link: https://patch.msgid.link/20260512060742.1628959-1-contact@xchglabs.com/ Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 7ca49630383589873c9a03d6d9edec7c07a81f0f Author: Sean Christopherson Date: Wed May 6 14:35:14 2026 -0700 KVM: x86: Swap the dst and src operand for MOVNTDQA commit 3098c076c83ea2913245cb915cdcba98eb24214c upstream. Swap the MOVNTDQA operands, as MOVNTDQA does NOT in fact have "the same characteristics as 0F E7 (MOVNTDQ)"; MOVNTDQA loads from memory and stores to registers, while MOVNTDQ loads from registers and stores to memory. Per the SDM: MOVNTDQ - Move packed integer values in xmm1 to m128 using non-temporal hint. MOVNTDQA - Move double quadword from m128 to xmm1 using non-temporal hint if WC memory type. Reported-by: Josh Eads Fixes: c57d9bafbd0b ("KVM: x86: Add support for emulating MOVNTDQA") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260506213514.2781948-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 60d154dcdacc16ac2bdc4d49f1039f25418d1479 Author: sunshaojie Date: Wed May 13 18:37:38 2026 +0800 cgroup/cpuset: Return only actually allocated CPUs during partition invalidation commit 345f40166694e60db6d5cf02233814bb27ac5dec upstream. In update_parent_effective_cpumask() with partcmd_invalidate, the CPUs to return to the parent are computed as: adding = cpumask_and(tmp->addmask, xcpus, parent->effective_xcpus); where xcpus = user_xcpus(cs) which returns cs->exclusive_cpus (if set) or cs->cpus_allowed. When exclusive_cpus is not set, user_xcpus(cs) can contain CPUs that were never actually granted to the partition due to sibling exclusion in compute_excpus(). Consequently, the invalidation may return CPUs to the parent that remain in use by sibling partitions, causing overlapping effective_cpus and triggering the WARN_ON_ONCE(1) in generate_sched_domains(). Use cs->effective_xcpus instead, which reflects the CPUs actually granted to this partition. Reproducer (on a 4-CPU machine): cd /sys/fs/cgroup mkdir a1 b1 # a1 becomes partition root with CPUs 0-1 echo "0-1" > a1/cpuset.cpus echo "root" > a1/cpuset.cpus.partition # b1 becomes partition root with CPUs 1-2, but sibling exclusion # reduces its effective_xcpus to CPU 2 only echo "1-2" > b1/cpuset.cpus echo "root" > b1/cpuset.cpus.partition # b1 changes cpus_allowed to 0-1 -> partition invalidation echo "0-1" > b1/cpuset.cpus # Expected: CPUs 2-3 (only CPU 2 returned from b1) # Actual: CPUs 1-3 (CPU 0-1 returned, overlapping with a1) cat cpuset.cpus.effective dmesg will also show a WARNING from generate_sched_domains() reporting overlapping partition root effective_cpus. Fixes: 2a3602030d80 ("cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict") Cc: stable@vger.kernel.org # v7.0+ Signed-off-by: sunshaojie Tested-by: Chen Ridong Reviewed-by: Chen Ridong Reviewed-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit df89f0593f5a3598b76d5db13faac85ebeadd783 Author: Sergio Correia Date: Tue May 12 14:28:59 2026 +0100 audit: enforce AUDIT_LOCKED for AUDIT_TRIM and AUDIT_MAKE_EQUIV commit f9e1c1324b4d98d591a6f7568fdebf5cf456dfc2 upstream. AUDIT_ADD_RULE and AUDIT_DEL_RULE correctly check for AUDIT_LOCKED and return -EPERM, but AUDIT_TRIM and AUDIT_MAKE_EQUIV do not. This allows a process with CAP_AUDIT_CONTROL to modify directory tree watches and equivalence mappings even when the audit configuration has been locked, undermining the purpose of the lock. Add AUDIT_LOCKED checks to both commands. Cc: stable@vger.kernel.org Reviewed-by: Ricardo Robaina Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Sergio Correia Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 722a871e8c9ddaa28bbde1b82a72ddd70e43fdc7 Author: Zoran Ilievski Date: Mon May 11 08:40:02 2026 +0200 net: atlantic: preserve PCI wake-from-D3 on shutdown when WOL enabled commit 2c308cf34284420963607d677d576a2b4124d8bd upstream. The shutdown handler aq_pci_shutdown() unconditionally calls pci_wake_from_d3(pdev, false), clearing the PCI PME_En bit even when wake-on-LAN has been configured. While aq_nic_shutdown() correctly programs the NIC firmware via aq_nic_set_power() to listen for magic packets, the PCI subsystem will not propagate the resulting PME wake event from D3, so the system never wakes after poweroff. WOL from suspend (S3) is unaffected because aq_suspend_common() does not touch pci_wake_from_d3() and relies on the PM core's wake configuration via device_may_wakeup(). This affects all atlantic-supported NICs (AQC107/108/111/112/113); users have reported that WOL works if the atlantic driver is never loaded, but breaks once it has run its shutdown path. Pass the configured WOL state to pci_wake_from_d3() instead of a literal false, so the PCI PME_En bit is preserved when the user has armed WOL via ethtool. Fixes: 90869ddfefeb ("net: aquantia: Implement pci shutdown callback") Cc: stable@vger.kernel.org Signed-off-by: Zoran Ilievski Reviewed-by: Sukhdeep Singh Link: https://patch.msgid.link/20260511064002.1857-1-goodboy@rexbytes.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 84c422cea5a45fe56be839f25880f21fd33940cd Author: Li Xiasong Date: Thu May 7 22:04:23 2026 +0800 netfilter: nft_ct: fix missing expect put in obj eval commit 19f94b6fee75b3ef7fbc06f3745b9a771a8a19a4 upstream. nft_ct_expect_obj_eval() allocates an expectation and may call nf_ct_expect_related(), but never drops its local reference. Add nf_ct_expect_put(exp) before return to balance allocation. Fixes: 857b46027d6f ("netfilter: nft_ct: add ct expectations support") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 0e258d765d3640cfc9c9217f73b904fb5ca488ad Author: Mario Limonciello Date: Mon May 4 18:01:37 2026 -0500 Revert "ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn" commit db5dadb562cabb6da49959b473ed0d9645b6f2da upstream. Some older systems don't support CPPC in the firmware and this just makes noise for them when booting. Drop back to debug. This reverts commit 21fb59ab4b9767085f4fe1edbdbe3177fbb9ec97. Fixes: 21fb59ab4b976 ("ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn") Suggested-by: Kim Phillips Signed-off-by: Mario Limonciello Tested-by: Kim Phillips Cc: All applicable Link: https://patch.msgid.link/20260504230141.484743-2-mario.limonciello@amd.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9087128a8c1115b2129554d68edd41eb6a6b2859 Author: Guopeng Zhang Date: Sat May 9 18:20:31 2026 +0800 cgroup/cpuset: Reserve DL bandwidth only for root-domain moves commit 5dd74441cbf42c22e874450eb6a6bbb19390a216 upstream. cpuset_can_attach() currently adds the bandwidth of all migrating SCHED_DEADLINE tasks to sum_migrate_dl_bw. If the source and destination cpuset effective CPU masks do not overlap, the whole sum is then reserved in the destination root domain. set_cpus_allowed_dl(), however, subtracts bandwidth from the source root domain only when the affinity change really moves the task between root domains. A DL task can move between cpusets that are still in the same root domain, so including that task in sum_migrate_dl_bw can reserve destination bandwidth without a matching source-side subtraction. Share the root-domain move test with set_cpus_allowed_dl(). Keep nr_migrate_dl_tasks counting all migrating deadline tasks for cpuset DL task accounting, but add to sum_migrate_dl_bw only for tasks that need a root-domain bandwidth move. Keep using the destination cpuset effective CPU mask and leave the broader can_attach()/attach() transaction model unchanged. Fixes: 2ef269ef1ac0 ("cgroup/cpuset: Free DL BW in case can_attach() fails") Cc: stable@vger.kernel.org # v6.10+ Signed-off-by: Guopeng Zhang Reviewed-by: Waiman Long Acked-by: Juri Lelli Tested-by: Juri Lelli Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit f319de7074e1728a9f9ff7134257360c694ec2b2 Author: Greg Kroah-Hartman Date: Wed May 6 14:48:13 2026 -0700 idpf: fix double free and use-after-free in aux device error paths commit 6c77b9510829a424d1b74409b7db9456e3522871 upstream. When auxiliary_device_add() fails in idpf_plug_vport_aux_dev() or idpf_plug_core_aux_dev(), the err_aux_dev_add label calls auxiliary_device_uninit() and falls through to err_aux_dev_init. The uninit call will trigger put_device(), which invokes the release callback (idpf_vport_adev_release / idpf_core_adev_release) that frees iadev. The fall-through then reads adev->id from the freed iadev for ida_free() and double-frees iadev with kfree(). Free the IDA slot and clear the back-pointer before uninit, while adev is still valid, then return immediately. Commit 65637c3a1811 ("idpf: fix UAF in RDMA core aux dev deinitialization") fixed the same use-after-free in the matching unplug path in this file but missed both probe error paths. Cc: Tony Nguyen Cc: Przemek Kitszel Cc: Andrew Lunn Cc: stable@kernel.org Fixes: be91128c579c ("idpf: implement RDMA vport auxiliary dev create, init, and destroy") Fixes: f4312e6bfa2a ("idpf: implement core RDMA auxiliary dev create, init, and destroy") Signed-off-by: Greg Kroah-Hartman Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-4-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 614bc4da2c70f92e221512753049c7520eaebf00 Author: Guopeng Zhang Date: Mon May 11 09:31:50 2026 +0800 cgroup/dmem: Return -ENOMEM on failed pool preallocation commit 796ad622040f7f955ccc3973085e953415920496 upstream. get_cg_pool_unlocked() handles allocation failures under dmemcg_lock by dropping the lock, preallocating a pool with GFP_KERNEL, and retrying the locked lookup and creation path. If the fallback allocation fails too, pool remains NULL. Since the loop condition is while (!pool), the function can keep retrying instead of propagating the allocation failure to the caller. Set pool to ERR_PTR(-ENOMEM) when the fallback allocation fails so the loop exits through the existing common return path. The callers already handle ERR_PTR() from get_cg_pool_unlocked(), so this restores the expected error path. Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup") Cc: stable@vger.kernel.org # v6.14+ Signed-off-by: Guopeng Zhang Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit edcb049d836e175e7b3d5e0d05657104545b5e65 Author: Arthur Kiyanovski Date: Thu May 7 00:35:15 2026 +0000 net: ena: PHC: Check return code before setting timestamp output commit 24a08d7d6218d60c033015cf4870b6096446e734 upstream. ena_phc_gettimex64() is setting the output parameter regardless of whether ena_com_phc_get_timestamp() succeeded or failed. When ena_com_phc_get_timestamp() returns an error, the timestamp parameter may contain uninitialized stack memory (e.g., when PHC is disabled or in blocked state) or invalid hardware values. Passing these to userspace via the PTP ioctl is both a security issue (information leak) and a correctness bug. Fix by checking the return code after releasing the lock and only setting the output timestamp on success. Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver") Cc: stable@vger.kernel.org Signed-off-by: Arthur Kiyanovski Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260507003518.22554-1-akiyano@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d782e4d200cd9036ef353eeb29525bfbfd13a14e Author: Sergio Correia Date: Tue May 12 14:28:33 2026 +0100 audit: fix incorrect inheritable capability in CAPSET records commit e4a640475e43f406fdfd56d370b1f34b0cbbc18d upstream. __audit_log_capset() records the effective capability set into the inheritable field due to a copy-paste error. Every CAPSET audit record therefore reports cap_pi (process inheritable) with the value of cap_effective instead of cap_inheritable. This silently corrupts audit data used for compliance and forensic analysis: an attacker who modifies inheritable capabilities to prepare for a privilege-escalating exec would have the change masked in the audit trail. The bug has been present since the original introduction of CAPSET audit records in 2008. Cc: stable@vger.kernel.org Fixes: e68b75a027bb ("When the capset syscall is used it is not possible for audit to record the actual capbilities being added/removed. This patch adds a new record type which emits the target pid and the eff, inh, and perm cap sets.") Reviewed-by: Ricardo Robaina Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Sergio Correia Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit ac10ff1c3ca18242f1608800dea4d359ac2247c6 Author: Li Xiasong Date: Thu May 7 22:04:22 2026 +0800 netfilter: nf_conntrack_sip: get helper before allocating expectation commit eb6317739b1ea3ab28791e1f91b24781905fa815 upstream. process_register_request() allocates an expectation and then checks whether a conntrack helper is available. If helper lookup fails, the function returns early and the allocated expectation is left behind. Reorder the code to fetch and validate helper before calling nf_ct_expect_alloc(). This keeps the logic simpler and removes the leak path while preserving existing behavior. Fixes: e14575fa7529 ("netfilter: nf_conntrack: use rcu accessors where needed") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit d0a9062fae4536bdb8e8a88936e5cc807fbfc59b Author: Guopeng Zhang Date: Sat May 9 18:20:30 2026 +0800 cgroup/cpuset: Reset DL migration state on can_attach() failure commit 4a39eda5fdd867fc39f3c039714dd432cee00268 upstream. cpuset_can_attach() accumulates temporary SCHED_DEADLINE migration state in the destination cpuset while walking the taskset. If a later task_can_attach() or security_task_setscheduler() check fails, cgroup_migrate_execute() treats cpuset as the failing subsystem and does not call cpuset_cancel_attach() for it. The partially accumulated state is then left behind and can be consumed by a later attach, corrupting cpuset DL task accounting and pending DL bandwidth accounting. Reset the pending DL migration state from the common error exit when ret is non-zero. Successful can_attach() keeps the state for cpuset_attach() or cpuset_cancel_attach(). Fixes: 2ef269ef1ac0 ("cgroup/cpuset: Free DL BW in case can_attach() fails") Cc: stable@vger.kernel.org # v6.10+ Signed-off-by: Guopeng Zhang Signed-off-by: Tejun Heo Reviewed-by: Chen Ridong Reviewed-by: Waiman Long Signed-off-by: Greg Kroah-Hartman commit ca9ed40f28949353911dcb524ff8fff2f3409c97 Author: Arthur Kiyanovski Date: Fri May 8 06:21:21 2026 +0000 net: ena: PHC: Fix potential use-after-free in get_timestamp commit e42c755582f0960e684298762f0ab927b3778376 upstream. Move the phc->active check and resp pointer assignment to after acquiring the spinlock. Previously, phc->active was checked without holding the lock, and resp was cached from ena_dev->phc.virt_addr before the lock was acquired. If ena_com_phc_destroy() runs between the lockless active check and the lock acquisition, it sets active=false, releases the lock, frees the DMA memory, and sets virt_addr=NULL. The get_timestamp path would then read a NULL virt_addr and dereference it. With both the active check and the pointer read under the lock, destroy cannot free the memory while get_timestamp is using it. Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver") Cc: stable@vger.kernel.org Signed-off-by: Arthur Kiyanovski Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260508062126.7273-1-akiyano@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit db0157e789c0f7015441ab85653110400fd9abca Author: Breno Leitao Date: Fri May 8 09:22:03 2026 -0700 workqueue: Fix wq->cpu_pwq leak in alloc_and_link_pwqs() WQ_UNBOUND path commit 0143033dc22cdff912cfc13419f5db92fea3b4cb upstream. For WQ_UNBOUND workqueues, alloc_and_link_pwqs() allocates wq->cpu_pwq via alloc_percpu() and then calls apply_workqueue_attrs_locked(). On failure it returns the error directly, bypassing the enomem: label which holds the only free_percpu(wq->cpu_pwq) in this function. The caller's error path kfree()s wq without touching wq->cpu_pwq, leaking one percpu pointer table (nr_cpu_ids * sizeof(void *) bytes) per failed call. If kmemleak is enabled, we can see: unreferenced object (percpu) 0xc0fffa5b121048 (size 8): comm "insmod", pid 776, jiffies 4294682844 backtrace (crc 0): pcpu_alloc_noprof+0x665/0xac0 __alloc_workqueue+0x33f/0xa20 alloc_workqueue_noprof+0x60/0x100 Route the error through the existing enomem: cleanup and any error before this one. Cc: stable@kernel.org Fixes: 636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu pool_workqueues") Signed-off-by: Breno Leitao Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 020299c1db712812bb65db9cadb4b5ab251c49ff Author: Matt Vollrath Date: Wed May 6 14:48:11 2026 -0700 i40e: Cleanup PTP pins on probe failure commit 678b713ece1e853f11e670a84cb887c35e1381b7 upstream. PTP pin structs are allocated early in probe, but never cleaned up. Fix this by calling i40e_ptp_free_pins in the error path. To support this, i40e_ptp_free_pins is added to the header and pin_config is correctly nullified after being freed. This has been an issue since i40e_ptp_alloc_pins was introduced. Fixes: 1050713026a08 ("i40e: add support for PTP external synchronization clock") Reported-by: Kohei Enju Cc: stable@vger.kernel.org Signed-off-by: Matt Vollrath Reviewed-by: Paul Menzel Reviewed-by: Aleksandr Loktionov Reviewed-by: Kohei Enju Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-2-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 97948906dc8e0ea84775e03e35b60a2063c70193 Author: Herbert Xu Date: Tue May 5 17:02:45 2026 +0800 crypto: af_alg - Cap AEAD AD length to 0x80000000 commit e4c06479d7059888adf2f22bc1ebcf053bf691a2 upstream. In order to prevent arithmetic overflows when checking the TX buffer size, cap the associated data length to 0x80000000. Reported-by: Yiming Qian Fixes: 400c40cf78da ("crypto: algif - add AEAD support") Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3b2d95f25cd9a87cd2d16625c7b3bb113042e61a Author: Vincent Guittot Date: Sun May 3 12:45:03 2026 +0200 sched/fair: Fix wakeup_preempt_fair() for not waking up task [ Upstream commit 9f6d929ee2c6f0266edb564bcd2bd47fd6e884a8 ] Make sure to only call pick_next_entity() on an non-empty cfs_rq. The assumption that p is always enqueued and not delayed, is only true for wakeup. If p was moved while delayed, pick_next_entity() will dequeue it and the cfs might become empty. Test if there are still queued tasks before trying again to determine if p could be the next one to be picked. There are at least 2 cases: When cfs becomes idle, it tries to pull tasks but if those pulled tasks are delayed, they will be dequeued when attached to cfs. attach_tasks() -> attach_task() -> wakeup_preempt(rq, p, 0); A misfit task running on cfs A triggers a load balance to be pulled on a better cpu, the load balance on cfs B starts an active load balance to pulled the running misfit task. If there is a delayed dequeue task on cfs A, it can be pulled instead of the previously running misfit task. attach_one_task() -> attach_task() -> wakeup_preempt(rq, p, 0); Fixes: ac8e69e69363 ("sched/fair: Fix wakeup_preempt_fair() vs delayed dequeue") Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260503104503.1732682-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit c1ab9de784f158e18e688ad81de4e05e96f9f831 Author: Eric Dumazet Date: Thu Apr 30 08:00:56 2026 +0000 net/sched: sch_pie: annotate more data-races in pie_dump_stats() [ Upstream commit 6d4106e8df94c0c52cf3ca6a6a0d01567fb3844e ] My prior patch missed few READ_ONCE()/WRITE_ONCE() annotations. Fixes: 5154561d9b11 ("net/sched: sch_pie: annotate data-races in pie_dump_stats()") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260430080056.35104-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ca0871348058f00d145eb17ceeec7d70f798a849 Author: Breno Leitao Date: Tue Apr 28 08:10:43 2026 -0700 workqueue: fix devm_alloc_workqueue() va_list misuse [ Upstream commit 0de4cb473aed57ee4ba7e0551ad27bddc19fc519 ] devm_alloc_workqueue() built a va_list and passed it as a single positional argument to the variadic alloc_workqueue() macro: va_start(args, max_active); wq = alloc_workqueue(fmt, flags, max_active, args); va_end(args); C does not allow forwarding a va_list through a ... parameter. alloc_workqueue() expands to alloc_workqueue_noprof(), which runs its own va_start() over its ... params, so the inner vsnprintf(wq->name, sizeof(wq->name), fmt, args) in __alloc_workqueue() received the outer va_list object as the first variadic slot rather than the caller's actual format arguments. Add a new static helper alloc_workqueue_va() that wraps __alloc_workqueue() and runs wq_init_lockdep() on success, and fold both alloc_workqueue_noprof() and devm_alloc_workqueue_noprof() onto it as suggested by Tejun. The wq_init_lockdep() step is required on the devm path too, otherwise __flush_workqueue()'s on-stack COMPLETION_INITIALIZER_ONSTACK_MAP would NULL-deref wq->lockdep_map. No caller changes are required. devm_alloc_ordered_workqueue() is a macro forwarding to devm_alloc_workqueue() and inherits the fix. Two in-tree callers actively trigger the broken path on every probe: drivers/power/supply/mt6370-charger.c:889 drivers/power/supply/max77705_charger.c:649 both of which use devm_alloc_ordered_workqueue(dev, "%s", 0, dev_name(dev)). A standalone reproducer module is available at[1]. Link: https://github.com/leitao/debug/blob/main/workqueue/valist/wq_va_test.c [1] Fixes: 1dfc9d60a69e ("workqueue: devres: Add device-managed allocate workqueue") Signed-off-by: Breno Leitao Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit bdb527ec591ff0f70377efd3f5d1f8bd13f6361d Author: Samiullah Khawaja Date: Tue May 5 23:43:27 2026 +0000 PCI: Initialize temporary device in new_id_store() [ Upstream commit f45a49a2380a47332817b7248c61a0ebbc6f0d00 ] When setting new_id of a PCI device driver using sysfs a lockdep splat occurs. This is because new_id_store() builds a temporary pci_dev for pci_match_device(), which calls device_match_driver_override(). That depends on the driver_override.lock added by cb3d1049f4ea ("driver core: generalize driver_override in struct device"). The new driver_override.lock was not initialized in the temporary pci_dev, resulting in this lockdep splat. Initialize the temporary pci_dev to fix this. Repro: Build with CONFIG_LOCKDEP=y, boot with QEMU, and add a new ID: # echo "8086 10f5" > /sys/bus/pci/drivers/e1000e/new_id INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 2 UID: 0 PID: 177 Comm: liveupdate-iomm Not tainted 7.0.0+ #9 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 register_lock_class+0x77e/0x790 lock_acquire+0xbf/0x2e0 pci_match_device+0x24/0x180 new_id_store+0x189/0x1d0 kernfs_fop_write_iter+0x14f/0x210 vfs_write+0x263/0x5e0 ksys_write+0x79/0xf0 do_syscall_64+0x117/0xf80 Fixes: 10a4206a2401 ("PCI: use generic driver_override infrastructure") Fixes: 8895d3bcb8ba ("PCI: Fail new_id for vendor/device values already built into driver") Signed-off-by: Samiullah Khawaja [bhelgaas: add commit log details and repro, trim backtrace] Signed-off-by: Bjorn Helgaas Reviewed-by: Danilo Krummrich Link: https://patch.msgid.link/20260505234327.716630-1-skhawaja@google.com Signed-off-by: Sasha Levin commit 974ac49a9a068b0591a59f65c63eb06579a13091 Author: Davidlohr Bueso Date: Fri May 1 12:41:23 2026 -0700 futex: Drop CLONE_THREAD requirement for private default hash alloc [ Upstream commit ee9dce44362b2d8132c32964656ab6dff7dfbc6a ] Currently need_futex_hash_allocate_default() depends on strict pthread semantics, abusing CLONE_THREAD. This breaks the non-concurrency assumptions when doing the mm->futex_ref pcpu allocations, leading to bugs[0] when sharing the mm in other ways; ie: BUG: KASAN: slab-use-after-free in futex_hash_put ... where the +1 bias can end up on a percpu counter that mm->futex_ref no longer points at. Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding vfork keeps the existing paths untouched (no overhead), and we can't race in the first place: either the parent is suspended and the child runs alone, or mm->futex_ref is already allocated from an earlier CLONE_VM. Link: https://lore.kernel.org/all/CAL_bE8LsmCQ-FAtYDuwbJhOkt9p2wwYQwAbMh=PifC=VsiBM6A@mail.gmail.com/ [0] Fixes: d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()") Reported-by: Yiming Qian Signed-off-by: Davidlohr Bueso Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9fe9e3acaa14921b0cf0d6cc2de5b562499bf721 Author: Zhaoyang Huang Date: Thu Apr 30 16:58:08 2026 +0800 arm64: Reserve an extra page for early kernel mapping [ Upstream commit 4d8e74ad4585672489da6145b3328d415f50db82 ] The final part of [data, end) segment may overflow into the next page of init_pg_end[1] which is the gap page before early_init_stack[2]: [1] crash_arm64_v9.0.1> vtop ffffffed00601000 VIRTUAL PHYSICAL ffffffed00601000 83401000 PAGE DIRECTORY: ffffffecffd62000 PGD: ffffffecffd62da0 => 10000000833fb003 PMD: ffffff80033fb018 => 10000000833fe003 PTE: ffffff80033fe008 => 68000083401f03 PAGE: 83401000 PTE PHYSICAL FLAGS 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN) PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffec00d0040 83401000 0 0 1 4000 reserved [2] ffffffed002c8000 (r) __pi__data ffffffed0054e000 (d) __pi___bss_start ffffffed005f5000 (b) __pi_init_pg_dir ffffffed005fe000 (b) __pi_init_pg_end ffffffed005ff000 (B) early_init_stack ffffffed00608000 (b) __pi__end For 4K pages, the early kernel mapping may use 2MB block entries but the kernel segments are only 64KB aligned. Segment boundaries that fall within a 2MB block therefore require a PTE table so that different attributes can be applied on either side of the boundary. KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel VMAs registered by declare_kernel_vmas(). However, since commit 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only"), the early mapper also maps [_text, _stext) separately from [_stext, _etext). This adds one more early-only split and can require one more page-table page than the existing EARLY_SEGMENT_EXTRA_PAGES allowance reserves. Increase the 4K-page early mapping allowance by one page to cover that additional split. Fixes: 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only") Assisted-by: TRAE:GLM-5.1 Suggested-by: Ard Biesheuvel Signed-off-by: Zhaoyang Huang [catalin.marinas@arm.com: rewrote part of the commit log] [catalin.marinas@arm.com: expanded the code comment] Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 509f5ffa27cbaf70abb723a205ab92d2ad5c889d Author: Leo Yan Date: Wed Apr 29 15:30:10 2026 +0100 kselftest/arm64: Include for user_gcs definition [ Upstream commit bb7235e226888607e6aac1288062fcb1ac105589 ] kselftest includes kernel uAPI headers with option: -isystem $(top_srcdir)/usr/include Include in libc-gcs.c for the definition of struct user_gcs from the uAPI headers, and remove the redundant definition in gcs-util.h. This fixes a compilation error on systems where the toolchain defines NT_ARM_GCS. Fixes: a505a52b4e29 ("kselftest/arm64: Add a GCS test program built with the system libc") Signed-off-by: Leo Yan Reviewed-by: Mark Brown Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit e4d4f485259f2f1c347eea4769f7e609be4355b0 Author: Paolo Abeni Date: Wed Apr 29 09:39:11 2026 +0200 net/sched: cls_flower: revert unintended changes [ Upstream commit 1e01abec856593e02cd69fd95b784c10dd46880c ] While applying the blamed commit 4ca07b9239bd ("net: mctp i2c: check length before marking flow active"), I unintentionally included unrelated and unacceptable changes. Revert them. Fixes: 4ca07b9239bd ("net: mctp i2c: check length before marking flow active") Reported-by: Jeremy Kerr Closes: https://lore.kernel.org/netdev/bd8704fe0bd53e278add5cde4873256656623e2e.camel@codeconstruct.com.au/ Signed-off-by: Paolo Abeni Link: https://patch.msgid.link/043026a53ff84da88b17648c4b0d17f0331749cb.1777447863.git.pabeni@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 126a4a284331f4a07ae01523faf0c4aa924a28d8 Author: Dan Carpenter Date: Wed Apr 29 09:48:17 2026 +0300 sfc: fix error code in efx_devlink_info_running_versions() [ Upstream commit 051ffb001b8a232cfa6e72f38bb5f51c4270a60b ] Return -EIO if efx_mcdi_rpc() doesn't return enough space. Fixes: 14743ddd2495 ("sfc: add devlink info support for ef100") Signed-off-by: Dan Carpenter Reviewed-by: Edward Cree Link: https://patch.msgid.link/afGpsbLRHL4_H0KS@stanley.mountain Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bd07fe6c38b9e44ff3fc02692a53f095c5cc9afc Author: Jakub Kicinski Date: Tue Apr 28 16:15:59 2026 -0700 net: tls: fix strparser anchor skb leak on offload RX setup failure [ Upstream commit 58689498ca3384851145a754dbb1d8ed1cf9fb54 ] When tls_set_device_offload_rx() fails at tls_dev_add(), the error path calls tls_sw_free_resources_rx() to clean up the SW context that was initialized by tls_set_sw_offload(). This function calls tls_sw_release_resources_rx() (which stops the strparser via tls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context), but never frees the anchor skb that was allocated by alloc_skb(0) in tls_strp_init(). Note that tls_sw_free_resources_rx() is exclusively used for this "failed to start offload" code path, there's no other caller. The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use the standard strparser"), because the standard strparser doesn't try to pre-allocate an skb. The normal close path in tls_sk_proto_close() handles cleanup by calling tls_sw_strparser_done() (which calls tls_strp_done()) after dropping the socket lock, because tls_strp_done() does cancel_work_sync() and the strparser work handler takes the socket lock. Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser") Signed-off-by: Jakub Kicinski Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260428231559.1358502-1-kuba@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ede3b6569cc88810cbfdcb30ee8fe89614e29a3c Author: Petr Oros Date: Mon Apr 27 22:22:23 2026 -0700 ice: add dpll peer notification for paired SMA and U.FL pins [ Upstream commit 9e5dead140af10e8b5f975b8f04e46197d48d274 ] SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1 and SMA2/U.FL2). When one pin's state changes via a PCA9575 GPIO write, the paired pin's state also changes, but no notification is sent for the peer pin. Userspace consumers monitoring the peer via dpll netlink subscribe never learn about the update. Add ice_dpll_sw_pin_notify_peer() which sends a change notification for the paired SW pin. Call it from ice_dpll_pin_sma_direction_set(), ice_dpll_sma_pin_state_set(), and ice_dpll_ufl_pin_state_set() after pf->dplls.lock is released. Use __dpll_pin_change_ntf() because dpll_lock is still held by the dpll netlink layer (dpll_pin_pre_doit). Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Signed-off-by: Petr Oros Tested-by: Alexander Nowlin Reviewed-by: Arkadiusz Kubalewski Reviewed-by: Aleksandr Loktionov Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-11-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4bb46e56d0ad75c8cefd5df33161e63ef0dc247a Author: Ivan Vecera Date: Mon Apr 27 22:22:21 2026 -0700 dpll: export __dpll_pin_change_ntf() for use under dpll_lock [ Upstream commit 620055cb1036a6125fd912e7a14b47a6572b809b ] Export __dpll_pin_change_ntf() so that drivers can send pin change notifications from within pin callbacks, which are already called under dpll_lock. Using dpll_pin_change_ntf() in that context would deadlock. Add lockdep_assert_held() to catch misuse without the lock held. Acked-by: Vadim Fedorenko Signed-off-by: Ivan Vecera Signed-off-by: Petr Oros Tested-by: Alexander Nowlin Reviewed-by: Arkadiusz Kubalewski Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-9-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Stable-dep-of: 9e5dead140af ("ice: add dpll peer notification for paired SMA and U.FL pins") Signed-off-by: Sasha Levin commit e365416628f1d6226aabfa0cc932d236323e0446 Author: Petr Oros Date: Mon Apr 27 22:22:22 2026 -0700 ice: fix missing dpll notifications for SW pins [ Upstream commit 1a41b58fd4dc80dca16c717e6e77c88b9d4e83a7 ] The SMA/U.FL pin redesign (commit 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")) introduced software-controlled pins that wrap backing CGU input/output pins, but never updated the notification and data paths to propagate pin events to these SW wrappers. The periodic work sends dpll_pin_change_ntf() only for direct CGU input pins. SW pins that wrap these inputs never receive change or phase offset notifications, so userspace consumers such as synce4l monitoring SMA pins via dpll netlink never learn about state transitions or phase offset updates. Similarly, ice_dpll_phase_offset_get() reads the SW pin's own phase_offset field which is never updated; the PPS monitor writes to the backing CGU input's field instead. Fix by introducing ice_dpll_pin_ntf(), a wrapper around dpll_pin_change_ntf() that also notifies any registered SMA/U.FL pin whose backing CGU input matches. Replace all direct dpll_pin_change_ntf() calls in the periodic notification paths with this wrapper. Fix ice_dpll_phase_offset_get() to return the backing CGU input's phase_offset for input-direction SW pins. Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Signed-off-by: Petr Oros Tested-by: Alexander Nowlin Reviewed-by: Arkadiusz Kubalewski Reviewed-by: Aleksandr Loktionov Reviewed-by: Ivan Vecera Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-10-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2473136a025f1404342650a2ef7a779e35783de0 Author: Petr Oros Date: Mon Apr 27 22:22:20 2026 -0700 ice: fix SMA and U.FL pin state changes affecting paired pin [ Upstream commit 6f9d8393c9f50fbc68b9c9e99f78ca5a7b43ff44 ] SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1 and SMA2/U.FL2) controlled by the PCA9575 GPIO expander. Each pair can only have one active pin at a time: SMA1 output and U.FL1 output share the same CGU output, SMA2 input and U.FL2 input share the same CGU input. The PCA9575 register bits determine which connector in each pair owns the signal path. The driver does not account for this pairing in two places: ice_dpll_ufl_pin_state_set() modifies PCA9575 bits and disables the backing CGU pin without checking whether the U.FL pin is currently active. Disconnecting an already inactive U.FL pin flips bits that the paired SMA pin relies on, breaking its connection. ice_dpll_sma_direction_set() does not propagate direction changes to the paired U.FL pin. For SMA2/U.FL2 the ICE_SMA2_UFL2_RX_DIS bit is never managed, so U.FL2 stays disconnected after SMA2 switches to output. For both pairs the backing CGU pin of the U.FL side is never enabled when a direction change activates it, so userspace sees the pin as disconnected even though the routing is correct. Fix by guarding the U.FL disconnect path against inactive pins and by updating the paired U.FL pin fully on SMA direction changes: manage ICE_SMA2_UFL2_RX_DIS for the SMA2/U.FL2 pair and enable the backing CGU pin whenever the peer becomes active. Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Signed-off-by: Petr Oros Tested-by: Alexander Nowlin Reviewed-by: Arkadiusz Kubalewski Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-8-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2fd350d516ac87994a822a66cb801d6e6e954118 Author: Petr Oros Date: Mon Apr 27 22:22:19 2026 -0700 ice: fix missing SMA pin initialization in DPLL subsystem [ Upstream commit 56a643aed0f0af5c29ebb4593d4917b78344dd48 ] The DPLL SMA/U.FL pin redesign introduced ice_dpll_sw_pin_frequency_get() which gates frequency reporting on the pin's active flag. This flag is determined by ice_dpll_sw_pins_update() from the PCA9575 GPIO expander state. Before the redesign, SMA pins were exposed as direct HW input/output pins and ice_dpll_frequency_get() returned the CGU frequency unconditionally — the PCA9575 state was never consulted. The PCA9575 powers on with all outputs high, setting ICE_SMA1_DIR_EN, ICE_SMA1_TX_EN, ICE_SMA2_DIR_EN and ICE_SMA2_TX_EN. Nothing in the driver writes the register during initialization, so ice_dpll_sw_pins_update() sees all pins as inactive and ice_dpll_sw_pin_frequency_get() permanently returns 0 Hz for every SW pin. Fix this by writing a default SMA configuration in ice_dpll_init_info_sw_pins(): clear all SMA bits, then set SMA1 and SMA2 as active inputs (DIR_EN=0) with U.FL1 output and U.FL2 input disabled. Each SMA/U.FL pair shares a physical signal path so only one pin per pair can be active at a time. U.FL pins still report frequency 0 after this fix: U.FL1 (output-only) is disabled by ICE_SMA1_TX_EN which keeps the TX output buffer off, and U.FL2 (input-only) is disabled by ICE_SMA2_UFL2_RX_DIS. They can be activated by changing the corresponding SMA pin direction via dpll netlink. Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Signed-off-by: Petr Oros Reviewed-by: Ivan Vecera Reviewed-by: Arkadiusz Kubalewski Tested-by: Alexander Nowlin Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-7-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ba1720946f79a11bfa7385c6ea7e728d526d3dfb Author: Petr Oros Date: Mon Apr 27 22:22:18 2026 -0700 ice: fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw [ Upstream commit 70ad216411e030f67b1743774e245601194aee6a ] On certain E810 configurations where firmware supports Tx scheduler topology switching (tx_sched_topo_comp_mode_en), ice_cfg_tx_topo() may need to apply a new 5-layer or 9-layer topology from the DDP package. If the AQ command to set the topology fails (e.g. due to invalid DDP data or firmware limitations), the global configuration lock must still be cleared via a CORER reset. Commit 86aae43f21cf ("ice: don't leave device non-functional if Tx scheduler config fails") correctly fixed this by refactoring ice_cfg_tx_topo() to always trigger CORER after acquiring the global lock and re-initialize hardware via ice_init_hw() afterwards. However, commit 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end of deinit paths") later moved ice_init_dev_hw() into ice_init_hw(), breaking the reinit path introduced by 86aae43f21cf. This creates an infinite recursive call chain: ice_init_hw() ice_init_dev_hw() ice_cfg_tx_topo() # topology change needed ice_deinit_hw() ice_init_hw() # reinit after CORER ice_init_dev_hw() # recurse ice_cfg_tx_topo() ... # stack overflow Fix by moving ice_init_dev_hw() back out of ice_init_hw() and calling it explicitly from ice_probe() and ice_devlink_reinit_up(). The third caller, ice_cfg_tx_topo(), intentionally does not need ice_init_dev_hw() during its reinit, it only needs the core HW reinitialization. This breaks the recursion cleanly without adding flags or guards. The deinit ordering changes from commit 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end of deinit paths") which fixed slow rmmod are preserved, only the init-side placement of ice_init_dev_hw() is reverted. Fixes: 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end of deinit paths") Signed-off-by: Petr Oros Reviewed-by: Paul Menzel Reviewed-by: Jacob Keller Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Tested-by: Alexander Nowlin Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-6-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 429024f3a407e4137aee825c2a6be0aba857937d Author: Petr Oros Date: Mon Apr 27 22:22:17 2026 -0700 ice: fix NULL pointer dereference in ice_reset_all_vfs() [ Upstream commit 54ef02487914c24170c7e1c061e45212dc55365e ] ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi(). When the VSI rebuild fails (e.g. during NVM firmware update via nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path, leaving txq_map and rxq_map as NULL. The subsequent unconditional call to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in ice_ena_vf_q_mappings() when it accesses vsi->txq_map[0]. The single-VF reset path in ice_reset_vf() already handles this correctly by checking the return value of ice_vf_reconfig_vsi() and skipping ice_vf_post_vsi_rebuild() on failure. Apply the same pattern to ice_reset_all_vfs(): check the return value of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and ice_eswitch_attach_vf() on failure. The VF is left safely disabled (ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can be recovered via a VFLR triggered by a PCI reset of the VF (sysfs reset or driver rebind). Note that this patch does not prevent the VF VSI rebuild from failing during NVM update — the underlying cause is firmware being in a transitional state while the EMP reset is processed, which can cause Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This patch only prevents the subsequent NULL pointer dereference that crashes the kernel when the rebuild does fail. crash> bt PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5" #0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee #1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba #2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540 #3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda #4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997 #5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595 #6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2 [exception RIP: ice_ena_vf_q_mappings+0x79] RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206 RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000 RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040 R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000 R13: 0000000000000010 R14: R15: ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice] #8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice] #9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice] #10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4 #11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de #12 [ff72159bcfe5bf18] kthread at ffffffffaa946663 #13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9 The panic occurs attempting to dereference the NULL pointer in RDX at ice_sriov.c:294, which loads vsi->txq_map (offset 0x4b8 in ice_vsi). The faulting VSI is an allocated slab object but not fully initialized after a failed ice_vsi_rebuild(): crash> struct ice_vsi 0xff34c9efc27d4828 netdev = 0x0, rx_rings = 0x0, tx_rings = 0x0, q_vectors = 0x0, txq_map = 0x0, rxq_map = 0x0, alloc_txq = 0x10, num_txq = 0x10, alloc_rxq = 0x10, num_rxq = 0x10, The nvmupdate64e process was performing NVM firmware update: crash> bt 0xff34c9edd1a30000 PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e" #0 [ff72159bcd617618] __schedule at ffffffffab5333f8 #4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice] #5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice] #6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice] #7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice] #8 [ff72159bcd6178b8] ice_read_flat_nvm at ffffffffc0a4034c [ice] #9 [ff72159bcd617918] ice_devlink_nvm_snapshot at ffffffffc0a6ffa5 [ice] dmesg: ice 0000:13:00.0: firmware recommends not updating fw.mgmt, as it may result in a downgrade. continuing anyways ice 0000:13:00.1: ice_init_nvm failed -5 ice 0000:13:00.1: Rebuild failed, unload and reload driver Fixes: 12bb018c538c ("ice: Refactor VF reset") Signed-off-by: Petr Oros Tested-by: Rafal Romanowski Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-5-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ffceb773a1ec9c0e288454e3f29a03d4f9f1ba02 Author: Petr Oros Date: Mon Apr 27 22:22:16 2026 -0700 iavf: add VIRTCHNL_OP_ADD_VLAN to success completion handler [ Upstream commit 34d33313b52eeac3a97ad2e3176d523ec70d9283 ] The V1 ADD_VLAN opcode had no success handler; filters sent via V1 stayed in ADDING state permanently. Add a fallthrough case so V1 filters also transition ADDING -> ACTIVE on PF confirmation. Critically, add an `if (v_retval) break` guard: the error switch in iavf_virtchnl_completion() does NOT return after handling errors, it falls through to the success switch. Without this guard, a PF-rejected ADD would incorrectly mark ADDING filters as ACTIVE, creating a driver/HW mismatch where the driver believes the filter is installed but the PF never accepted it. For V2, this is harmless: iavf_vlan_add_reject() in the error block already kfree'd all ADDING filters, so the success handler finds nothing to transition. Fixes: 968996c070ef ("iavf: Fix VLAN_V2 addition/rejection") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-4-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 03155c1a7ad432a9e18281c4e80a1833998fbd00 Author: Petr Oros Date: Mon Apr 27 22:22:15 2026 -0700 iavf: wait for PF confirmation before removing VLAN filters [ Upstream commit bbcbe4ed70dea948849549af7edf44bd42bbd695 ] The VLAN filter DELETE path was asymmetric with the ADD path: ADD waits for PF confirmation (ADD -> ADDING -> ACTIVE), but DELETE immediately frees the filter struct after sending the DEL message without waiting for the PF response. This is problematic because: - If the PF rejects the DEL, the filter remains in HW but the driver has already freed the tracking structure, losing sync. - Race conditions between DEL pending and other operations (add, reset) cannot be properly resolved if the filter struct is already gone. Add IAVF_VLAN_REMOVING state to make the DELETE path symmetric: REMOVE -> REMOVING (send DEL) -> PF confirms -> kfree -> PF rejects -> ACTIVE In iavf_del_vlans(), transition filters from REMOVE to REMOVING instead of immediately freeing them. The new DEL completion handler in iavf_virtchnl_completion() frees filters on success or reverts them to ACTIVE on error. Update iavf_add_vlan() to handle the REMOVING state: if a DEL is pending and the user re-adds the same VLAN, queue it for ADD so it gets re-programmed after the PF processes the DEL. The !VLAN_FILTERING_ALLOWED early-exit path still frees filters directly since no PF message is sent in that case. Also update iavf_del_vlan() to skip filters already in REMOVING state: DEL has been sent to PF and the completion handler will free the filter when PF confirms. Without this guard, the sequence DEL(pending) -> user-del -> second DEL could cause the PF to return an error for the second DEL (filter already gone), causing the completion handler to incorrectly revert a deleted filter back to ACTIVE. Fixes: 968996c070ef ("iavf: Fix VLAN_V2 addition/rejection") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-3-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 81bebc2411811d5102a2c8fb2f3e7f3c4a38513e Author: Petr Oros Date: Mon Apr 27 22:22:14 2026 -0700 iavf: stop removing VLAN filters from PF on interface down [ Upstream commit f2ce65b9b917474a1a6ce68d357e15fac2aca0f2 ] When a VF goes down, the driver currently sends DEL_VLAN to the PF for every VLAN filter (ACTIVE -> DISABLE -> send DEL -> INACTIVE), then re-adds them all on UP (INACTIVE -> ADD -> send ADD -> ADDING -> ACTIVE). This round-trip is unnecessary because: 1. The PF disables the VF's queues via VIRTCHNL_OP_DISABLE_QUEUES, which already prevents all RX/TX traffic regardless of VLAN filter state. 2. The VLAN filters remaining in PF HW while the VF is down is harmless - packets matching those filters have nowhere to go with queues disabled. 3. The DEL+ADD cycle during down/up creates race windows where the VLAN filter list is incomplete. With spoofcheck enabled, the PF enables TX VLAN filtering on the first non-zero VLAN add, blocking traffic for any VLANs not yet re-added. Remove the entire DISABLE/INACTIVE state machinery: - Remove IAVF_VLAN_DISABLE and IAVF_VLAN_INACTIVE enum values - Remove iavf_restore_filters() and its call from iavf_open() - Remove VLAN filter handling from iavf_clear_mac_vlan_filters(), rename it to iavf_clear_mac_filters() - Remove DEL_VLAN_FILTER scheduling from iavf_down() - Remove all DISABLE/INACTIVE handling from iavf_del_vlans() VLAN filters now stay ACTIVE across down/up cycles. Only explicit user removal (ndo_vlan_rx_kill_vid) or PF/VF reset triggers VLAN filter deletion/re-addition. Fixes: ed1f5b58ea01 ("i40evf: remove VLAN filters on close") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Simon Horman Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-2-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2208d73830bae8da949bdfe2e6c1e38217b3d51d Author: Petr Oros Date: Mon Apr 27 22:22:13 2026 -0700 iavf: rename IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING [ Upstream commit 70d62b669f1f9080a25278fc90b64309f4ae8959 ] Rename the IAVF_VLAN_IS_NEW state to IAVF_VLAN_ADDING to better describe what the state represents: an ADD request has been sent to the PF and is waiting for a response. This is a pure rename with no behavioral change, preparing for a cleanup of the VLAN filter state machine. Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Reviewed-by: Simon Horman Reviewed-by: Przemek Kitszel Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-1-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni Stable-dep-of: f2ce65b9b917 ("iavf: stop removing VLAN filters from PF on interface down") Signed-off-by: Sasha Levin commit e6f847ab07a02674c7b17228fcb87a06e2308a11 Author: Hasan Basbunar Date: Tue Apr 28 19:07:39 2026 +0200 page_pool: fix memory-provider leak in page_pool_create_percpu() error path [ Upstream commit 5ef343614db766acdc01c56d66e780a1b43c6ac6 ] When page_pool_create_percpu() fails on page_pool_list(), it falls through to its err_uninit: label, which calls page_pool_uninit(). At that point page_pool_init() has already taken two references when the user requested PP_FLAG_ALLOW_UNREADABLE_NETMEM: pool->mp_ops->init(pool) static_branch_inc(&page_pool_mem_providers); Neither is undone by page_pool_uninit(); both are only undone by __page_pool_destroy() (success-side teardown). The error path therefore leaks the per-provider reference taken by mp_ops->init (io_zcrx_ifq->refs in the io_uring zcrx provider, the dmabuf binding refcount in the devmem provider) plus one increment of the page_pool_mem_providers static branch on every failure of xa_alloc_cyclic() inside page_pool_list(). The leaked io_zcrx_ifq->refs in turn pins everything io_zcrx_ifq_free() would release on cleanup: ifq->user (uid), ifq->mm_account (mmdrop), ifq->dev (device refcount), ifq->netdev_tracker (netdev refcount), and the rbuf region. The leaked static branch increment forces all subsequent page_pool_alloc_netmems() and page_pool_return_page() callers to take the slow mp_ops branch for the lifetime of the kernel. Reachable via the io_uring zcrx path: io_uring_register(IORING_REGISTER_ZCRX_IFQ) /* CAP_NET_ADMIN */ -> __io_uring_register -> io_register_zcrx -> zcrx_register_netdev -> netif_mp_open_rxq -> driver ndo_queue_mem_alloc -> page_pool_create_percpu -> page_pool_init succeeds (mp_ops->init runs, branch++) -> page_pool_list fails (xa_alloc_cyclic -ENOMEM) -> goto err_uninit <-- leak The same shape applies to the devmem dmabuf provider via mp_dmabuf_devmem_init()/mp_dmabuf_devmem_destroy(). Restore the cleanup symmetry by moving the mp_ops->destroy() and static_branch_dec() calls out of __page_pool_destroy() and into page_pool_uninit(), so page_pool_uninit() is again the strict inverse of page_pool_init(). page_pool_uninit() has only two callers (the err_uninit: path and __page_pool_destroy()), so this preserves the single-call invariant on the success path while fixing the err path. The error path of page_pool_init() itself still skips the mp_ops cleanup correctly: mp_ops->init is the last action that takes a reference before page_pool_init() returns 0, so when it returns an error neither the refcount nor the static branch has been touched. Triggering the bug requires xa_alloc_cyclic() to fail with -ENOMEM, which under normal GFP_KERNEL retry behaviour is rare. It is deterministic under CONFIG_FAULT_INJECTION with fail_page_alloc / xa fault injection, or under sustained memory pressure. The leak is silent: there is no warning, and the released kernel build continues running with a permanently-incremented static branch. Fixes: 0f9214046893 ("memory-provider: dmabuf devmem memory provider") Signed-off-by: Hasan Basbunar Link: https://patch.msgid.link/20260428170739.34881-1-basbunarhasan@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 78f409fd34fe9de2b24ad8e9dca1b4608a48ed3d Author: Eric Dumazet Date: Tue Apr 28 12:32:07 2026 +0000 bonding: 3ad: implement proper RCU rules for port->aggregator [ Upstream commit c4f050ce06c56cfb5993268af4a5cb66ed1cd04e ] syzbot found a data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler [1] which hints at lack of proper RCU implementation. Add __rcu qualifier to port->aggregator, and add proper RCU API. [1] BUG: KCSAN: data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler write to 0xffff88813cf5c4b0 of 8 bytes by task 36 on cpu 0: ad_port_selection_logic drivers/net/bonding/bond_3ad.c:1659 [inline] bond_3ad_state_machine_handler+0x9d5/0x2d60 drivers/net/bonding/bond_3ad.c:2569 process_one_work kernel/workqueue.c:3302 [inline] process_scheduled_works+0x4f0/0x9c0 kernel/workqueue.c:3385 worker_thread+0x58a/0x780 kernel/workqueue.c:3466 kthread+0x22a/0x280 kernel/kthread.c:436 ret_from_fork+0x146/0x330 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 read to 0xffff88813cf5c4b0 of 8 bytes by task 22063 on cpu 1: __bond_3ad_get_active_agg_info drivers/net/bonding/bond_3ad.c:2858 [inline] bond_3ad_get_active_agg_info+0x8c/0x230 drivers/net/bonding/bond_3ad.c:2881 bond_fill_info+0xe0f/0x10f0 drivers/net/bonding/bond_netlink.c:853 rtnl_link_info_fill net/core/rtnetlink.c:906 [inline] rtnl_link_fill+0x1d7/0x4e0 net/core/rtnetlink.c:927 rtnl_fill_ifinfo+0xf8e/0x1380 net/core/rtnetlink.c:2168 rtmsg_ifinfo_build_skb+0x11c/0x1b0 net/core/rtnetlink.c:4453 rtmsg_ifinfo_event net/core/rtnetlink.c:4486 [inline] rtmsg_ifinfo+0x6d/0x110 net/core/rtnetlink.c:4495 __dev_notify_flags+0x76/0x390 net/core/dev.c:9790 netif_change_flags+0xac/0xd0 net/core/dev.c:9823 do_setlink+0x905/0x2950 net/core/rtnetlink.c:3180 rtnl_group_changelink net/core/rtnetlink.c:3813 [inline] __rtnl_newlink net/core/rtnetlink.c:3981 [inline] rtnl_newlink+0xf55/0x1400 net/core/rtnetlink.c:4109 rtnetlink_rcv_msg+0x64b/0x720 net/core/rtnetlink.c:6995 netlink_rcv_skb+0x123/0x220 net/netlink/af_netlink.c:2550 rtnetlink_rcv+0x1c/0x30 net/core/rtnetlink.c:7022 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5a8/0x680 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x5c8/0x6f0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x563/0x5b0 net/socket.c:2698 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0xd4/0x160 net/socket.c:2787 x64_sys_call+0x194c/0x3020 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x12c/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x0000000000000000 -> 0xffff88813cf5c400 Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 22063 Comm: syz.0.31122 Tainted: G W syzkaller #0 PREEMPT(full) Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 Fixes: 47e91f56008b ("bonding: use RCU protection for 3ad xmit path") Reported-by: syzbot+9bb2ff2a4ab9e17307e1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69f0a82f.050a0220.3aadc4.0000.GAE@google.com/ Signed-off-by: Eric Dumazet Cc: Jay Vosburgh Cc: Andrew Lunn Link: https://patch.msgid.link/20260428123207.3809211-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 56b1d2bf88adf35f3391f690201b810f923d97bd Author: Hangbin Liu Date: Tue Feb 24 02:02:14 2026 +0000 bonding: print churn state via netlink [ Upstream commit 4916f2e2f3fc9aef289fcd07949301e5c29094c2 ] Currently, the churn state is printed only in sysfs. Add netlink support so users could get the state via netlink. Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20260224020215.6012-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni Stable-dep-of: c4f050ce06c5 ("bonding: 3ad: implement proper RCU rules for port->aggregator") Signed-off-by: Sasha Levin commit 4b0e24e9ae65bcc69df123770b6e3b2733665de8 Author: Lorenzo Bianconi Date: Tue Apr 28 08:53:16 2026 +0200 net: airoha: Do not return err in ndo_stop() callback [ Upstream commit 4ca01292ea2f2363660610a65ba0285d7c3309ed ] Always complete the airoha_dev_stop() routine regardless of the airoha_set_vip_for_gdm_port() return value, since errors from ndo_stop() are ignored by the networking stack and the interface is always considered down after the call. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260428-airoha-ndo-stop-not-err-v1-1-674506d29a91@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5a678a40a97312a037d5ec23a4cafee61edb4715 Author: Tvrtko Ursulin Date: Mon Apr 20 14:16:03 2026 +0100 drm/xe/xelp: Fix Wa_18022495364 [ Upstream commit 7fe6cae2f7fad2b5166b0fc096618629f9e2ebcb ] It looks I mistyped CS_DEBUG_MODE2 as CS_DEBUG_MODE1 when adding the workaround. Fix it. Signed-off-by: Tvrtko Ursulin Fixes: ca33cd271ef9 ("drm/xe/xelp: Add Wa_18022495364") Cc: Matt Roper Cc: "Thomas Hellström" Cc: Rodrigo Vivi Cc: # v6.18+ Reviewed-by: Matt Roper Signed-off-by: Thomas Hellström Link: https://patch.msgid.link/20260116095040.49335-1-tvrtko.ursulin@igalia.com Stable-dep-of: 0df99689eb79 ("drm/xe/xelp: Fix Wa_18022495364") Signed-off-by: Sasha Levin commit 1a2e9332b935e2bd22ef73de84fb089ccabdbfc9 Author: Shuicheng Lin Date: Fri Apr 17 16:33:08 2026 +0000 drm/xe/gsc: Fix BO leak on error in query_compatibility_version() [ Upstream commit 3762d6c36549accea7068c4a175483fafdd03657 ] When xe_gsc_read_out_header() fails, query_compatibility_version() returns directly instead of jumping to the out_bo label. This skips the xe_bo_unpin_map_no_vm() call, leaving the BO pinned and mapped with no remaining reference to free it. Fix by using goto out_bo so the error path properly cleans up the BO, consistent with the other error handling in the same function. Fixes: 0881cbe04077 ("drm/xe/gsc: Query GSC compatibility version") Cc: Daniele Ceraolo Spurio Reviewed-by: Daniele Ceraolo Spurio Link: https://patch.msgid.link/20260417163308.3416147-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 8de86d0a843c32ca9d36864bdb92f0376a830bce) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 84f2bfbe6e38f8b9815ca00826e53b7f51420402 Author: Shuicheng Lin Date: Wed Apr 15 22:54:28 2026 +0000 drm/xe/eustall: Fix drm_dev_put called before stream disable in close [ Upstream commit dc2d9842c67d883d3200ae33b9c3859dd9492408 ] In xe_eu_stall_stream_close(), drm_dev_put() is called before the stream is disabled and its resources are freed. If this drops the last reference, the device structures could be freed while the subsequent cleanup code still accesses them, leading to a use-after-free. Fix this by moving drm_dev_put() after all device accesses are complete. This matches the ordering in xe_oa_release(). Fixes: 9a0b11d4cf3b ("drm/xe/eustall: Add support to init, enable and disable EU stall sampling") Cc: Harish Chegondi Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Shuicheng Lin Reviewed-by: Harish Chegondi Link: https://patch.msgid.link/20260415225428.3399934-1-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit 35aff528f7297e949e5e19c9cd7fd748cf1cf21c) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 1be55646d8a2035343b012dcb12210db7bb8b056 Author: Shuicheng Lin Date: Wed Apr 8 02:06:47 2026 +0000 drm/xe: Fix error cleanup in xe_exec_queue_create_ioctl() [ Upstream commit f3cc22d4df3ed58439ea7e21daa54c3608e03b78 ] Two error handling issues exist in xe_exec_queue_create_ioctl(): 1. When xe_hw_engine_group_add_exec_queue() fails, the error path jumps to put_exec_queue which skips xe_exec_queue_kill(). If the VM is in preempt fence mode, xe_vm_add_compute_exec_queue() has already added the queue to the VM's compute exec queue list. Skipping the kill leaves the queue on that list, leading to a dangling pointer after the queue is freed. 2. When xa_alloc() fails after xe_hw_engine_group_add_exec_queue() has succeeded, the error path does not call xe_hw_engine_group_del_exec_queue() to remove the queue from the hw engine group list. The queue is then freed while still linked into the hw engine group, causing a use-after-free. Fix both by: - Changing the xe_hw_engine_group_add_exec_queue() failure path to jump to kill_exec_queue so that xe_exec_queue_kill() properly removes the queue from the VM's compute list. - Adding a del_hw_engine_group label before kill_exec_queue for the xa_alloc() failure path, which removes the queue from the hw engine group before proceeding with the rest of the cleanup. Fixes: 7970cb36966c ("'drm/xe/hw_engine_group: Register hw engine group's exec queues") Cc: Francois Dugast Cc: Matthew Brost Cc: Niranjana Vishwanathapura Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260408020647.3397933-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 37c831f401746a45d510b312b0ed7a77b1e06ec8) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit ee306b1102a972c86dc38819890f7bd3b52f78e5 Author: Shuicheng Lin Date: Thu Apr 9 00:34:49 2026 +0000 drm/xe: Fix potential NULL deref in xe_exec_queue_tlb_inval_last_fence_put_unlocked [ Upstream commit f8c4151d50b12923b67819ebf03c1c6782c984c1 ] xe_exec_queue_tlb_inval_last_fence_put_unlocked() uses q->vm->xe as the first argument to xe_assert(). This function is called unconditionally from xe_exec_queue_destroy() for all queues, including kernel queues that have q->vm == NULL (e.g., queues created during GT init in xe_gt_record_default_lrcs() with vm=NULL). While current compilers optimize away the q->vm->xe dereference (even in CONFIG_DRM_XE_DEBUG=y builds, the compiler pushes the dereference into the WARN branch that is only taken when the assert condition is false), the code is semantically incorrect and constitutes undefined behavior in the C abstract machine for the NULL pointer case. Use gt_to_xe(q->gt) instead, which is always valid for any exec queue. This is consistent with how xe_exec_queue_destroy() itself obtains the xe_device pointer in its own xe_assert at the top of the function. Fixes: b2d7ec41f2a3 ("drm/xe: Attach last fence to TLB invalidation job queues") Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260409003449.3405767-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 96078a1c68bf97f17fd1d08c3f58f5c5cc9ccd65) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit e32915eb6b48afd3fe820a3d809181a0857282b1 Author: Matt Roper Date: Wed Apr 8 15:27:44 2026 -0700 drm/xe/debugfs: Correct printing of register whitelist ranges [ Upstream commit 03f2499c51dffce611b065b2894406beb9f2ebe0 ] The register-save-restore debugfs prints whitelist entries as offset ranges. E.g., REG[0x39319c-0x39319f]: allow read access for a single dword-sized register. However the GENMASK value used to set the lower bits to '1' for the upper bound of the whitelist range incorrectly included one more bit than it should have, causing the whitelist ranges to sometimes appear twice as large as they really were. For example, REG[0x6210-0x6217]: allow rw access was also intended to be a single dword-sized register whitelist (with a range 0x6210-0x6213) but was printed incorrectly as a qword-sized range because one too many bits was flipped on. Similar 'off by one' logic was applied when printing 4-dword register ranges and 64-dword register ranges as well. Correct the GENMASK logic to print these ranges in debugfs correctly. No impact outside of correcting the misleading debugfs output. Fixes: d855d2246ea6 ("drm/xe: Print whitelist while applying") Reviewed-by: Stuart Summers Link: https://patch.msgid.link/20260408-regsr_wl_range-v1-1-e9a28c8b4264@intel.com Signed-off-by: Matt Roper (cherry picked from commit 1a2a722ff96749734a5585dfe7f0bea7719caa8b) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 34e33fa74b61bf4d03aa6d9f62a26f7aa126e2e7 Author: Matthew Brost Date: Thu Mar 26 14:01:16 2026 -0700 drm/xe: Drop registration of guc_submit_wedged_fini from xe_guc_submit_wedge() [ Upstream commit a0fc362f095330f7b3f68ac0c55ef8da18290c87 ] xe_guc_submit_wedge() runs in the DMA-fence signaling path, where GFP_KERNEL memory allocations are not permitted. However, registering guc_submit_wedged_fini via drmm_add_action_or_reset() triggers such an allocation. Avoid this by moving the logic from guc_submit_wedged_fini() into guc_submit_fini(), where wedged exec queue references are dropped during normal teardown. Fixes: 8ed9aaae39f3 ("drm/xe: Force wedged state and block GT reset upon any GPU hang") Signed-off-by: Matthew Brost Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260326210116.202585-3-matthew.brost@intel.com (cherry picked from commit 4a706bd93c4fb156a13477e26ffdf2e633edeb10) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit b97f8a9e0e629dd22eddc1c62699c2f0b2783fbc Author: Zhanjun Dong Date: Tue Mar 10 18:50:36 2026 -0400 drm/xe: Use XE_WEDGED_MODE_UPON_ANY_HANG_NO_RESET enum instead of magic number [ Upstream commit a7f607610da721f77db358b09be8091e60bd8e89 ] Replace the magic number 2 with the proper enum value XE_WEDGED_MODE_UPON_ANY_HANG_NO_RESET for better code readability and maintainability. Signed-off-by: Zhanjun Dong Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260310225039.1320161-5-zhanjun.dong@intel.com Stable-dep-of: a0fc362f0953 ("drm/xe: Drop registration of guc_submit_wedged_fini from xe_guc_submit_wedge()") Signed-off-by: Sasha Levin commit 71ad1b0d39e8f379325eca5ea22b30aa4ef8e78b Author: Timur Kristóf Date: Tue Apr 28 13:40:45 2026 +0200 drm/amd/display: Use EDID from VBIOS embedded panel info [ Upstream commit 019155e2bd3e2cec425553195e9f9bc76bb0f848 ] When an embedded panel has no DDC, read the EDID from the VBIOS embedded panel info and use that. Fixes: 7c7f5b15be65 ("drm/amd/display: Refactor edid read.") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 399b9abc353c62f6e37d38325edbdb6c2c00411c) Signed-off-by: Sasha Levin commit d76e3548c49df629e5f401b7e7f2cb335a884da3 Author: Timur Kristóf Date: Tue Apr 28 13:40:44 2026 +0200 drm/amd/display: Read EDID from VBIOS embedded panel info [ Upstream commit 9ea16f64189bf7b6ba50fc7f0325b3c1f836d105 ] Some board manufacturers hardcode the EDID for the embedded panel in the VBIOS. This EDID should be used when the panel doesn't have a DDC. For reference, see the legacy non-DC display code: amdgpu_atombios_encoder_get_lcd_info() This is necessary to support embedded connectors without DDC. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit eb105e63b474c11ef6a84a1c6b18100d851ff364) Signed-off-by: Sasha Levin commit cbd0796a507aeae9a3fc0a2b642dfbc1376772ba Author: Timur Kristóf Date: Tue Apr 28 13:40:43 2026 +0200 drm/amd/display: Allow constructing DCE8 link encoder without DDC [ Upstream commit 60af4605ef35ecb7ad649a8534b83a2f7c69576d ] When the DDC channel ID is set to CHANNEL_ID_UNKNOWN, pass NULL to the AUX regs array. This is necessary to support embedded connectors without DDC. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 155baf3038c1af50b602723022ed869b38e86a99) Signed-off-by: Sasha Levin commit a878ff083539620c3ba2b0acb9b73389d2a013ef Author: Timur Kristóf Date: Tue Apr 28 13:40:42 2026 +0200 drm/amd/display: Allow constructing DCE6 link encoder without DDC [ Upstream commit 880498a1943f865529819f778df3b9945ca57262 ] When the DDC channel ID is set to CHANNEL_ID_UNKNOWN, pass NULL to the AUX regs array. This is necessary to support embedded connectors without DDC. Fixes: 7c15fd86aaec ("drm/amd/display: dc/dce: add initial DCE6 support (v10)") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 38a70e50b22a188ff601740d64dd75f46213121f) Signed-off-by: Sasha Levin commit d2d2352bff04978b0f8d4d2781bb42ba0f53fb97 Author: Timur Kristóf Date: Tue Apr 28 13:40:41 2026 +0200 drm/amd/display: Allow DCE link encoder without AUX registers [ Upstream commit ac27e3f99035f132f23bc0409d0e57f11f054c70 ] Allow constructing the DCE link encoder without DDC, which means the AUX registers array will be NULL. This is necessary to support embedded connectors without DDC. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 87f30b101af62590faf6020d106da07efdda199b) Signed-off-by: Sasha Levin commit 31554fda73e5d36745b72a7cb688d431cc4fdfcf Author: Timur Kristóf Date: Tue Apr 28 13:40:40 2026 +0200 drm/amd/display: Allow embedded connectors without DDC [ Upstream commit 494941aa772dab79251543764db6cd14bd337e43 ] On some laptops, the embedded panel may not have a DDC (display data channel) available. On these, the EDID may be hardcoded in ACPI or the VBIOS. In this case, use GPIO_DDC_LINE_UNKNOWN and don't fail. Fixes: def3488eb0fd ("drm/amd/display: refactor HPD to increase flexibility") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5192 Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 75b8a6ca0e8bc3ce24572f854e95f8721b321179) Signed-off-by: Sasha Levin commit 0304d60abb9dcc02bc7fe6d1850f4ca206e8f1a0 Author: Sebastian Andrzej Siewior Date: Tue Apr 28 12:34:25 2026 +0200 futex: Prevent lockup in requeue-PI during signal/ timeout wakeup [ Upstream commit bc7304f3ae20972d11db6e0b1b541c63feda5f05 ] During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup(). Fixes: 07d91ef510fb1 ("futex: Prevent requeue_pi() lock nesting issue on RT") Reported-by: Moritz Klammler Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260428103425.dywXyPd3@linutronix.de Closes: https://lore.kernel.org/all/VE1PR06MB6894BE61C173D802365BE19DFF4CA@VE1PR06MB6894.eurprd06.prod.outlook.com Signed-off-by: Sasha Levin commit af8adb09c1719e4c3f310c2981565121699051bc Author: Shenghao Ding Date: Wed Apr 29 13:42:06 2026 +0800 ALSA: hda/tas2781: Fix incorrect bit update for non-book-zero or book 0 pages >1 [ Upstream commit e052a1f7199260eda4d6ca08a59c3b98738f8491 ] In TAS2781 SPI mode, when accessing non-book-zero or page numbers greater than 1 in book 0, an additional byte must be read. The first byte in such cases is a dummy byte and should be ignored. Fixes: 9fa6a693ad8d ("ALSA: hda/tas2781: Remove tas2781_spi_fwlib.c and leverage SND_SOC_TAS2781_FMWLIB") Signed-off-by: Shenghao Ding Link: https://patch.msgid.link/20260429054206.429-1-shenghao-ding@ti.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f494a7953bf544761cd32f0541a927e7d41d6409 Author: Richard Fitzgerald Date: Tue Apr 28 14:05:31 2026 +0100 ALSA: hda: cs35l56: Fix uninitialized value in cs35l56_hda_read_acpi() [ Upstream commit 90df4957a3271adf391b3432cd76a40887cf3273 ] Eliminate the uninitialized 'nval' in cs35l56_hda_read_acpi() if a system-specific quirk overrides processing of the dev-index property. The value is now stored in a new 'num_amps' member of struct cs35l56_hda so that the quirk handler can set the value. The quirk for the Lenovo Yoga Book 9i GenX replaces the values from the dev-index property with hardcoded indexes. So cs35l56_hda_read_acpi() would then skip reading the property. But this left the 'nval' local variable uninitialized when it is later passed to cirrus_scodec_get_speaker_id(). Fixes: 40b1c2f9b299 ("ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-sound/aenFesLAStjrVNy8@stanley.mountain/T/#u Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260428130531.169600-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1da5c73f3793b224696617a2a21def7500ba18d6 Author: wangdicheng Date: Tue Apr 28 16:04:50 2026 +0800 ALSA: hda/conexant: Fix missing error check for jack detection [ Upstream commit b0e2333a231107adedd38c6fcfe1adc6162716fc ] In cx_probe(), the return value of snd_hda_jack_detect_enable_callback() is ignored. This function returns a pointer, and if it fails (e.g., due to memory allocation failure), it returns an error pointer which must be checked using IS_ERR(). If the registration fails, the driver continues to probe, but the jack detection callback will not be registered. This can lead to a kernel crash later when the driver attempts to handle jack events or accesses the uninitialized structure. Check the return value using IS_ERR() and propagate the error via PTR_ERR() to the probe caller. Fixes: 7aeb25908648 ("ALSA: hda/conexant: Fix headset auto detect fail in cx8070 and SN6140") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260428080450.108801-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit af8aaafe46596be8c86882940eda0aafa43a1d0e Author: Breno Leitao Date: Mon Apr 27 07:30:38 2026 -0700 netconsole: restore userdatum value on update_userdata() failure [ Upstream commit 869cd6490fafe09c89a15d01610e8a03932d79f0 ] userdatum_value_store() updates udm->value first and only then calls update_userdata() to rebuild the on-the-wire payload. If update_userdata() fails (e.g. -ENOMEM from kmalloc), the function returns the error to userspace, but udm->value already holds the new string while the live nt->userdata buffer still reflects the old one. The next successful write to any sibling userdatum on the same target will call update_userdata() again, which walks every entry and packs the now-stale udm->value into the payload. The failed write is thus silently activated later, with no indication to userspace that the value it tried to set was rejected. Snapshot the previous value before overwriting udm->value and restore it if update_userdata() fails so the visible state and the active payload stay consistent. Fixes: eb83801af2dc ("netconsole: Dynamic allocation of userdata buffer") Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260427-netconsole_ai_fixes-v2-4-59965f29d9cc@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 75e16d1170621c7bfd4c5ae3e9e36f64bf34994e Author: Breno Leitao Date: Mon Apr 27 07:30:37 2026 -0700 netconsole: propagate device name truncation in dev_name_store() [ Upstream commit 92ceb7bff62c2606f664c204750eca0b85d44112 ] dev_name_store() calls strscpy(nt->np.dev_name, buf, IFNAMSIZ) without checking the return value. If userspace writes an interface name longer than IFNAMSIZ - 1, strscpy() silently truncates and returns -E2BIG, but the function ignores it and reports a fully successful write back to userspace. If a real interface happens to match the truncated name, netconsole will bind to the wrong device on the next enable, sending kernel logs and panic output to an unintended network segment with no indication to userspace that anything was rewritten. Reject writes whose length cannot fit in nt->np.dev_name up front: if (count >= IFNAMSIZ) return -ENAMETOOLONG; This is not a big deal of a problem, but, it is still the correct approach. Fixes: 0bcc1816188e57 ("[NET] netconsole: Support dynamic reconfiguration using configfs") Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260427-netconsole_ai_fixes-v2-3-59965f29d9cc@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7c682d135e717f3e6b97e742608536f1098d9a7b Author: Breno Leitao Date: Mon Apr 27 07:30:36 2026 -0700 netconsole: avoid clobbering userdatum value on truncated write [ Upstream commit e6dd94252b0fa7b4fcc00577c6898432c5d97a08 ] userdatum_value_store() bounds count by MAX_EXTRADATA_VALUE_LEN (200) and then copies straight into udm->value, which is itself 200 bytes: if (count > MAX_EXTRADATA_VALUE_LEN) return -EMSGSIZE; ... ret = strscpy(udm->value, buf, sizeof(udm->value)); if (ret < 0) goto out_unlock; If userspace writes exactly MAX_EXTRADATA_VALUE_LEN bytes with no NUL within them, strscpy() copies 199 bytes plus a NUL into udm->value and returns -E2BIG. The function jumps to out_unlock and reports the error to userspace, but udm->value has already been overwritten with the truncated string and update_userdata() is skipped, so the corruption is not yet visible on the wire. The next successful write to any userdatum entry under the same target calls update_userdata(), which packs udm->value into the active netconsole payload. From that point on, every netconsole message carries the silently truncated value, and userspace has no indication that a previous, error-returning write left state behind. Tighten the entry check from "count > MAX_EXTRADATA_VALUE_LEN" to "count >= MAX_EXTRADATA_VALUE_LEN". With count strictly less than sizeof(udm->value), strscpy() can no longer return -E2BIG here, so the corrupting truncation path is removed entirely. Fixes: 8a6d5fec6c7f ("net: netconsole: add a userdata config_group member to netconsole_target") Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260427-netconsole_ai_fixes-v2-2-59965f29d9cc@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b7eaeee1d60c1e33cfc60119a3ef42e56a1c8995 Author: Breno Leitao Date: Mon Apr 27 07:30:35 2026 -0700 netconsole: return count instead of strnlen(buf, count) from store callbacks [ Upstream commit d62c6f2df5c0e1390b9a1f45b1b52689e3f234f0 ] Several configfs store callbacks in netconsole end with: ret = strnlen(buf, count); This under-reports the number of bytes consumed when the input contains an embedded NUL within count, telling the VFS that fewer bytes were written than userspace actually handed in. A conformant partial-write loop would then retry the trailing bytes against a callback that has already accepted them. Every other configfs driver in the tree returns count directly from its store callbacks once parsing has succeeded, including drivers/nvme/target/configfs.c, drivers/gpio/gpio-sim.c, drivers/most/configfs.c, drivers/block/null_blk/main.c, drivers/pci/endpoint/pci-ep-cfs.c, and the rest of the configfs users. netconsole was the outlier (along with drivers/infiniband/core/cma_configfs.c, which has the same latent issue). Align netconsole with the rest of the configfs ecosystem: return count once the parser/validator has accepted the input. The numeric and boolean parsers (kstrtobool, kstrtou16, mac_pton, netpoll_parse_ip_addr) have already validated the meaningful prefix; any trailing bytes are padding and should simply be reported as consumed. Fixes: 0bcc1816188e ("[NET] netconsole: Support dynamic reconfiguration using configfs") Reviewed-by: Simon Horman Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260427-netconsole_ai_fixes-v2-1-59965f29d9cc@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ac8461260d3d88550ee1e88dcb0ff0ec473d8aa3 Author: Eric Dumazet Date: Mon Apr 27 08:36:06 2026 +0000 net/sched: sch_cake: annotate data-races in cake_dump_stats() (V) [ Upstream commit a6c95b833dc17e84d16a8ac0f40fd0931616a52d ] cake_dump_stats() runs without qdisc spinlock being held. In this final patch, I add READ_ONCE()/WRITE_ONCE() annotations for cparams.target and cparams.interval. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Eric Dumazet Acked-by: "Toke Høiland-Jørgensen" Link: https://patch.msgid.link/20260427083606.459355-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit abd1cd22cc415f8f6ee774b7d6feae5d3b91e9bc Author: Eric Dumazet Date: Mon Apr 27 08:36:05 2026 +0000 net/sched: sch_cake: annotate data-races in cake_dump_stats() (IV) [ Upstream commit 8fab48d87745a6ab1cec594b8d5865d9ae2db879 ] cake_dump_stats() runs without qdisc spinlock being held. In this fourth patch, I add READ_ONCE()/WRITE_ONCE() annotations for the following fields: - avg_peak_bandwidth - buffer_limit - buffer_max_used - avg_netoff - max_netlen - max_adjlen - min_netlen - min_adjlen - active_queues - tin_rate_bps - bytes - tin_backlog Other annotations are added in following patch, to ease code review. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Eric Dumazet Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260427083606.459355-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e5cabd2427d5cba5ebcc21940e22985fa3b5b3c9 Author: Eric Dumazet Date: Mon Apr 27 08:36:04 2026 +0000 net/sched: sch_cake: annotate data-races in cake_dump_stats() (III) [ Upstream commit 276a98a434964088fccd4745db5b34d6e831e358 ] cake_dump_stats() runs without qdisc spinlock being held. In this third patch, I add READ_ONCE()/WRITE_ONCE() annotations for the following fields: - packets - tin_dropped - tin_ecn_mark - ack_drops - peak_delay - avge_delay - base_delay Other annotations are added in following patches, to ease code review. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Eric Dumazet Acked-by: "Toke Høiland-Jørgensen" Link: https://patch.msgid.link/20260427083606.459355-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 586ac57ded9bb745449204afc35b06ec723d96a8 Author: Eric Dumazet Date: Mon Apr 27 08:36:03 2026 +0000 net/sched: sch_cake: annotate data-races in cake_dump_stats() (II) [ Upstream commit 91a96427b93b9ba27413077b7e825d2fefbfa134 ] cake_dump_stats() runs without qdisc spinlock being held. In this second patch, I add READ_ONCE()/WRITE_ONCE() annotations for the following fields: - bulk_flow_count - unresponsive_flow_count - max_skblen - flow_quantum Other annotations are added in following patches, to ease code review. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Eric Dumazet Acked-by: "Toke Høiland-Jørgensen" Link: https://patch.msgid.link/20260427083606.459355-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a8e9477bcba7274845ba3983ef791a23faf84ac0 Author: Eric Dumazet Date: Mon Apr 27 08:36:02 2026 +0000 net/sched: sch_cake: annotate data-races in cake_dump_stats() (I) [ Upstream commit 44967ac3785ebef6442377708925181d4a0eb1c8 ] cake_dump_stats() runs without qdisc spinlock being held. In this first patch, I add READ_ONCE()/WRITE_ONCE() annotations for the following fields: - way_hits - way_misses - way_collisions - sparse_flow_count - decaying_flow_count Other annotations are added in following patches, to ease code review. Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Eric Dumazet Acked-by: "Toke Høiland-Jørgensen" Link: https://patch.msgid.link/20260427083606.459355-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 638905520fc4fae6a80991563f264131545ba3df Author: Weiming Shi Date: Sun Apr 26 09:53:51 2026 -0700 bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() [ Upstream commit aa6c6d9ee064aabfede4402fd1283424e649ca19 ] bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver. Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260426165350.1663137-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 325fb6d023dd6bd623828c9a83ea0816f0a2df13 Author: Xin Long Date: Sun Apr 26 10:46:41 2026 -0400 sctp: discard stale INIT after handshake completion [ Upstream commit 8a92cb475ca90d84db769e4d4383e631ace0d6e5 ] After an association reaches ESTABLISHED, the peer’s init_tag is already known from the handshake. Any subsequent INIT with the same init_tag is not a valid restart, but a delayed or duplicate INIT. Drop such INIT chunks in sctp_sf_do_unexpected_init() instead of processing them as new association attempts. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Link: https://patch.msgid.link/5788c76c1ee122a3ed00189e88dcf9df1fba226c.1777214801.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 023ff5ed3d2a5b00c2a111d736462463d52ea84e Author: Xin Long Date: Sun Apr 26 10:46:40 2026 -0400 netfilter: skip recording stale or retransmitted INIT [ Upstream commit 576a5d2bad4814c881a829576b1261b9b8159d2b ] An INIT whose init_tag matches the peer's vtag does not provide new state information. It indicates either: - a stale INIT (after INIT-ACK has already been seen on the same side), or - a retransmitted INIT (after INIT has already been recorded on the same side). In both cases, the INIT must not update ct->proto.sctp.init[] state, since it does not advance the handshake tracking and may otherwise corrupt INIT/INIT-ACK validation logic. Allow INIT processing only when the conntrack entry is newly created (SCTP_CONNTRACK_NONE), or when the init_tag differs from the stored peer vtag. Note it skips the check for the ct with old_state SCTP_CONNTRACK_NONE in nf_conntrack_sctp_packet(), as it is just created in sctp_new() where it set ct->proto.sctp.vtag[IP_CT_DIR_REPLY] = ih->init_tag. Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.") Signed-off-by: Xin Long Reviewed-by: Marcelo Ricardo Leitner Acked-by: Florian Westphal Link: https://patch.msgid.link/ee56c3e416452b2a40589a2a85245ac2ad5e9f4b.1777214801.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4dbb4a4ffcd1dad606c3823cbb2262534133d226 Author: Christian A. Ehrhardt Date: Tue Apr 28 21:22:49 2026 +0200 ASoC: codecs: ab8500: Fix casting of private data [ Upstream commit a201aef1a88b675e9eb8487e27d14e2eef3cef80 ] ab8500_filter_controls[i].private_value is initialized using .private_value = (unsigned long)&(struct filter_control) {.count = xcount, .min = xmin, .max = xmax} thus it's a pointer to a struct filter_control casted to unsigned long. So to get back that pointer .private_data must be cast back, not its address. Fixes: 679d7abdc754 ("ASoC: codecs: Add AB8500 codec-driver") Signed-off-by: Christian A. Ehrhardt Signed-off-by: Uwe Kleine-König (The Capable Hub) Link: https://patch.msgid.link/20260428192255.2294705-2-u.kleine-koenig@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fb88a8c86109edb15971481e3de816a8bfdfe571 Author: Jakub Kicinski Date: Mon Apr 27 12:58:56 2026 -0700 net: psp: require admin permission for dev-set and key-rotate [ Upstream commit b718342a7fbaa2dff5fefc31988c07af8c6cbc21 ] The dev-set and key-rotate netlink operations modify shared device state (PSP version configuration and cryptographic key material, respectively) but do not require CAP_NET_ADMIN. The only access control is psp_dev_check_access() which merely verifies netns membership. Fixes: 00c94ca2b99e ("psp: base PSP device support") Reviewed-by: Daniel Zahka Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260427195856.401223-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e201c57073e624dd2ba5beaf9eda31e19b77b332 Author: Jakub Kicinski Date: Mon Apr 27 12:06:06 2026 -0700 net: psp: check for device unregister when creating assoc [ Upstream commit b89769f936a8fa9e66de72ddc1b71a9745a488e6 ] psp_assoc_device_get_locked() obtains a psp_dev reference via psp_dev_get_for_sock() (which uses psp_dev_tryget() under RCU); it then acquires psd->lock and drops the reference. Before the lock is taken, psp_dev_unregister() can run to completion: take psd->lock, clear out state, unlock, drop the registration reference. The expectation is that the lock prevents device unregistration, but much like with netdevs special care has to be taken when "upgrading" a reference to a locked device. Add the missing check if device is still alive. psp_dev_is_registered() exists already but had no callers, which makes me wonder if I either forgot to add this or lost the check during refactoring... Reported-by: Yiming Qian Fixes: 6b46ca260e22 ("net: psp: add socket security association code") Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260427190606.366101-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fd012e165ae2db85494eccc8192af34398a5c1d5 Author: Richard Fitzgerald Date: Tue Apr 28 12:52:28 2026 +0100 ASoC: cs35l56: Fix illegal writes to OTP_MEM registers [ Upstream commit be102efb832ef7e30e4cd4c2edf22bbf64ddf35a ] Mark the OTP_MEM registers as volatile so that regcache_sync() will not attempt to write to them. These registers hold a constant, and originally they were marked as readable non-volatile so that this value would be read into the regmap cache. The problem with this is regcache_sync() issues a write for any cached register that does not have a reg_default. Though these registers are constants and writing them in normal use cannot change OTP, it is illegal for the host to write to them. Fixes: e1830f66f6c6 ("ASoC: cs35l56: Add helper functions for amp calibration") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260428115228.158252-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cb3af525f8dfb8930f0c123e5755fa967a12d5c1 Author: Jens Axboe Date: Mon Apr 27 14:42:18 2026 -0600 io_uring/napi: cap busy_poll_to 10 msec [ Upstream commit df8599ee18c0e5fe343ffe0b4c379636b8bb839a ] Currently there's no cap on the maximum amount of time that napi is allowed to poll if no events are found, which can lead to kernel complaints on a task being stuck as there's no conditional rescheduling done within that loop. Just cap it to 10 msec in total, that's already way above any kind of sane value that will reap any benefits, yet low enough that it's nowhere near being able to trigger preemption complaints. Fixes: 8d0c12a80cde ("io-uring: add napi busy poll support") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5830a6dde31891787bffbc35909a06babaa0ff90 Author: Lijo Lazar Date: Mon Apr 27 12:53:30 2026 +0530 drm/amd/pm: Add fine grained flag to SMU v13.0.6 [ Upstream commit 47a5dfc8add4e60ff1ddc312f79998e70cbb0c09 ] Gfx clock is fine grained on SMU v13.0.6/12 SOCs. Add the flag to report clock frequencies correctly. Fixes: 7380228401c4 ("drm/amd/pm: Use generic dpm table for SMUv13 SOCs") Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher (cherry picked from commit d4871d837bbf70173f63426a84fa80b39e408b9e) Signed-off-by: Sasha Levin commit 46ad73aec27d020f103b4262e4da2d2c22f54799 Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v5.3.0 ring [ Upstream commit 3b0ea2021351b6b813b34fac940957f1f4fad85b ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 4aeaf3cbfa9f ("drm/amdgpu/jpeg: Add jpeg 5.3.0 support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 86ac011ae234c03fb872f4945913391ea1d8862e) Signed-off-by: Sasha Levin commit 869ce148c0d953570f8307c3e206b47bd5d3be99 Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v5.0.1 ring [ Upstream commit 2f8e3da71a1b469b6e157aa3972f1448b3157840 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: b8f57b69942b ("drm/amdgpu: Add JPEG5_0_1 support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 742a98e2e81702df8fe1b1eccee5223220a03dc2) Signed-off-by: Sasha Levin commit 69ab75c7c5f378eb46f4c918aa848bb5c5603924 Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v5.0.0 ring [ Upstream commit ea7c61c5f895e8f9ea0ffffa180498ef9c740152 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: dfad65c65728 ("drm/amdgpu: Add JPEG5 support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 0f43893d3cd478fa57836697525b338817c9c23d) Signed-off-by: Sasha Levin commit f9bc5633b761cff200c428f61ed0df6212b1c721 Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.5 ring [ Upstream commit b65b7f3f3c18f797f81a2af7c97e2079900ad6db ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 8f98a715da8e ("drm/amdgpu/jpeg: add jpeg support for VCN4_0_5") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit f05d0a4f21fc720116d6e238f23308b199891058) Signed-off-by: Sasha Levin commit 249fa7549736de1c8e327d7ca6b32fa148a40bd6 Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.3 ring [ Upstream commit 83e37c0987ca92f9e87789b46dd311dcf5a4a6c8 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: e684e654eba9 ("drm/amdgpu/jpeg: add jpeg support for VCN4_0_3") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 2f6afc97d259d530f4f86c7743efbc573a8da927) Signed-off-by: Sasha Levin commit af4b458daa597dae707bf3f1f74745f5fc133ca2 Author: Yinjie Yao Date: Mon Apr 27 11:46:11 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0 ring [ Upstream commit e7e90b5839aeb8805ec83bb4da610b8dab8e184d ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: b13111de32a9 ("drm/amdgpu/jpeg: add jpeg support for VCN4_0_0") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 8d0cac9478a3f046279c657d6a2545de49ae675a) Signed-off-by: Sasha Levin commit 48ce00787e3fddd2b45692fc991b8ab128343da5 Author: Yinjie Yao Date: Mon Apr 27 11:46:10 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v3.0 ring [ Upstream commit a2baf12eec41f246689e6a3f8619af1200031576 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: dfd57dbf44dd ("drm/amdgpu: add JPEG3.0 support for Sienna_Cichlid") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 4d7d774f100efb5089c86a1fb8c5bf47c63fc9ef) Signed-off-by: Sasha Levin commit 694fe016969c5e5a24b9e0ef7c1307eedec8ddf8 Author: Yinjie Yao Date: Mon Apr 27 11:46:10 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v2.5 ring [ Upstream commit 79405e774ede411c6b47ed41c651e40b92de64a2 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 14f43e8f88c5 ("drm/amdgpu: move JPEG2.5 out from VCN2.5") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 3216a7f4e2642bda5fd14f57586e835ae9202587) Signed-off-by: Sasha Levin commit 41c4f3f68a343d62bd352a95ace93a11c4ad92ed Author: Yinjie Yao Date: Mon Apr 27 11:46:10 2026 -0400 drm/amdgpu/jpeg: set no_user_fence for JPEG v2.0 ring [ Upstream commit e5f612dc91650561fe2b5b76dd6d2898ec9ad480 ] JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 6ac27241106b ("drm/amdgpu: add JPEG v2.0 function supports") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 96179da0c6b059eb31706a0abe8dd6381c533143) Signed-off-by: Sasha Levin commit 5a4bffd67e94944ed3db26a959346cfb7fabaecd Author: Yinjie Yao Date: Mon Apr 27 11:45:36 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v5.0.1 enc ring [ Upstream commit 8f4954722eab88e10c4ea0c0d3b1269c31421d3a ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 346492f30ce3 ("drm/amdgpu: Add VCN_5_0_1 support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit e16be95a2c3ee712b142cb27d2dca0b461181359) Signed-off-by: Sasha Levin commit 2c350f3cd94be847ac216e1358ec7001eaaf0934 Author: Yinjie Yao Date: Mon Apr 27 11:45:36 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v5.0.0 enc ring [ Upstream commit 8cae0ce77de492d7c31c1532a2e80c0c6e7e58cb ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: b6d1a0632051 ("drm/amdgpu: add VCN_5_0_0 IP block support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 49b1fbbb5a071197ee71e2d70959b1cb29bdc317) Signed-off-by: Sasha Levin commit 7f23b5c420b9f68a210c29c5123bace670aa8cc9 Author: Yinjie Yao Date: Mon Apr 27 11:45:36 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v4.0.5 enc ring [ Upstream commit 589a254bf3e88204c8402b9cbccd5e23a0af990f ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 547aad32edac ("drm/amdgpu: add VCN4 ip block support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 084d94ac93707bdda07efb5cee786f632de4219b) Signed-off-by: Sasha Levin commit 0177ac6141c8857130cf365369c74dee7b6b1f7f Author: Yinjie Yao Date: Mon Apr 27 11:45:36 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v4.0.3 enc ring [ Upstream commit 4532b52b34e4e4310386e6fdf6a643368599f522 ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: b889ef4ac988 ("drm/amdgpu/vcn: add vcn support for VCN4_0_3") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit ff1a5a125c5a70c328806b9bc01d7d942cf3f9aa) Signed-off-by: Sasha Levin commit 6bdd2ed6458d35c368fbe9550a4d7f342abd3a92 Author: Yinjie Yao Date: Mon Apr 27 11:45:36 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v4.0 enc ring [ Upstream commit 51f694221047c84fa185be98210eb2c354ffb8c6 ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 8da1170a16e4 ("drm/amdgpu: add VCN4 ip block support") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit fd852c048b46f9825e904a4f3f4538fe9d8827d9) Signed-off-by: Sasha Levin commit b076e45e6f757a2829e80d0144c1b5f201bee5af Author: Yinjie Yao Date: Mon Apr 27 11:45:35 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v3.0 enc/dec rings [ Upstream commit f1e5a6660d7cbf006079126d9babbf0ccf538c6b ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: cf14826cdfb5 ("drm/amdgpu: add VCN3.0 support for Sienna_Cichlid") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit 663bed3c7b8b9a7624b0d95d300ddae034ad0614) Signed-off-by: Sasha Levin commit 5a3c6f76cab164a5d803084908d7050f649ab7f9 Author: Yinjie Yao Date: Mon Apr 27 11:45:35 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v2.5 enc/dec rings [ Upstream commit 4f317863a3ab212a027d8c8c3cc3af4e3fb95704 ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 28c17d72072b ("drm/amdgpu: add VCN2.5 basic supports") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit efc9dd5590894109bce9a0bfe1fa5592dd6b20b1) Signed-off-by: Sasha Levin commit c71aecae98e42dcf2baf462df50b3a2cf1a93fe4 Author: Yinjie Yao Date: Mon Apr 27 11:45:35 2026 -0400 drm/amdgpu/vcn: set no_user_fence for VCN v2.0 enc/dec rings [ Upstream commit 8d80b293b41fcb5e9396db93e788b0f4ebcbafb7 ] VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. Fixes: 1b61de45dfaf ("drm/amdgpu: add initial VCN2.0 support (v2)") Reviewed-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Yinjie Yao Signed-off-by: Alex Deucher (cherry picked from commit e2b5499fca55f1a32960a311bbb62e35891eaf73) Signed-off-by: Sasha Levin commit 8968fb99fde4512cee9a3c1460708a9f61ef8d2d Author: Alex Deucher Date: Thu Apr 23 12:29:03 2026 -0400 drm/amd/display: properly handle family setting for early GC 11.5.4 [ Upstream commit 31bc64e87f5f3d9ccbb7e625d570cfd8f52c77fc ] Early variants need an override. Fixes: 57d00816c6a9 ("drm/amdgpu: set family for GC 11.5.4") Cc: Pratik Vishwakarma Cc: Roman Li Cc: Mario Limonciello Reviewed-by: Mario Limonciello (AMD) Tested-by: Mario Limonciello (AMD) Signed-off-by: Alex Deucher (cherry picked from commit 922fccc2d3f8186008c19ba08a49ae8a9463cb50) Signed-off-by: Sasha Levin commit a9b4fdee5f0d28cfa88b5fb2e40cb03a4dc37160 Author: Heiko Schocher Date: Sat Apr 25 05:13:39 2026 +0200 net: phy: dp83869: fix setting CLK_O_SEL field. [ Upstream commit 46f74a3f7d57d9cc0110b09cbc8163fa0a01afa2 ] Table 7-121 in datasheet says we have to set register 0xc6 to value 0x10 before CLK_O_SEL can be modified. No more infos about this field found in datasheet. With this fix, setting of CLK_O_SEL field in IO_MUX_CFG register worked through dts property "ti,clk-output-sel" on a DP83869HMRGZR. Signed-off-by: Heiko Schocher Reviewed-by: Simon Horman Fixes: 01db923e8377 ("net: phy: dp83869: Add TI dp83869 phy") Link: https://patch.msgid.link/20260425031339.3318-1-hs@nabladev.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 85fa9634e2bca818b2fcd8a97852a742539325fd Author: Heiko Carstens Date: Tue Apr 21 07:52:44 2026 +0200 s390/mm: Fix phys_to_folio() usage in do_secure_storage_access() [ Upstream commit b95e0e792822bad8fc9eb33ea3a90005e29e75e9 ] In case of a Secure-Storage-Access exception the effective aka virtual address which caused the exception is contained within the TEID. do_secure_storage_access() incorrectly uses phys_to_folio() instead of virt_to_folio() to translate the virtual address to the corresponding folio. Fix this by using virt_to_folio() instead of phys_to_folio(). Fixes: 084ea4d611a3 ("s390/mm: add (non)secure page access exceptions handlers") Reviewed-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit b49c67cf7fb312ca909081d12e4b0faf4c1dd2cc Author: Yu Kuai Date: Sat Apr 25 10:46:15 2026 +0800 md/md-bitmap: add a none backend for bitmap grow [ Upstream commit f2926a533d03fe70d753b512b713e06a2aa174af ] Add a real none bitmap backend that exposes the common bitmap sysfs group and use it to keep bitmap/location available when an array has no bitmap. Then switch the bitmap location sysfs path to move only between none and the classic bitmap backend, using the no-sysfs bitmap helpers while merging or unmerging the internal bitmap sysfs group. This restores mdadm --grow bitmap addition through bitmap/location. Fixes: fb8cc3b0d9db ("md/md-bitmap: delay registration of bitmap_ops until creating bitmap") Reviewed-by: Su Yue Link: https://lore.kernel.org/r/20260425024615.1696892-4-yukuai@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit bb4df37d9089a651748ab8f8eeb0c5ec48e2024b Author: Yu Kuai Date: Sat Apr 25 10:46:14 2026 +0800 md/md-bitmap: split bitmap sysfs groups [ Upstream commit aba3d6d6cb55c6e1116d1215140559dd7ecdf9a9 ] Split the classic bitmap sysfs files into a common bitmap group with the location attribute and a separate internal bitmap group for the remaining files. At the same time, convert bitmap operations from a single sysfs group to a sysfs group array so backends can share part of their sysfs layout while adding backend-specific attributes separately. Switch the bitmap sysfs helpers to use sysfs_update_groups() for the add and update path, and remove groups in reverse order so shared named groups are unmerged before the last group removes the directory. Also make bitmap operation lookup depend only on the currently selected bitmap id matching the installed backend. This prepares the lookup path for a later registered none backend. Reviewed-by: Su Yue Link: https://lore.kernel.org/r/20260425024615.1696892-3-yukuai@fnnas.com Signed-off-by: Yu Kuai Stable-dep-of: f2926a533d03 ("md/md-bitmap: add a none backend for bitmap grow") Signed-off-by: Sasha Levin commit 2c192bd27a27bdded10c0d30cf25f5466ce076c7 Author: Yu Kuai Date: Sat Apr 25 10:46:13 2026 +0800 md: factor bitmap creation away from sysfs handling [ Upstream commit 8776d342cf8fa0b98ca5e6fb2d956966fb5ca364 ] Factor bitmap creation and destruction into helpers that do not touch bitmap sysfs registration. This prepares the bitmap sysfs rework so callers such as the sysfs bitmap location path can create or destroy a bitmap backend without coupling that to sysfs group lifetime management. Reviewed-by: Su Yue Link: https://lore.kernel.org/r/20260425024615.1696892-2-yukuai@fnnas.com Signed-off-by: Yu Kuai Stable-dep-of: f2926a533d03 ("md/md-bitmap: add a none backend for bitmap grow") Signed-off-by: Sasha Levin commit ff5881d0cf0618b125bc56289055b3a22831db98 Author: Yu Kuai Date: Mon Mar 23 13:46:42 2026 +0800 md: add fallback to correct bitmap_ops on version mismatch [ Upstream commit 09af773650024279a60348e7319d599e6571b15c ] If default bitmap version and on-disk version doesn't match, and mdadm is not the latest version to set bitmap_type, set bitmap_ops based on the disk version. Link: https://lore.kernel.org/linux-raid/20260323054644.3351791-2-yukuai@fnnas.com/ Signed-off-by: Yu Kuai Stable-dep-of: f2926a533d03 ("md/md-bitmap: add a none backend for bitmap grow") Signed-off-by: Sasha Levin commit b5dbe4d1a20cd4a7042fc567e5d4ef4bf65cee18 Author: Keith Busch Date: Thu Apr 16 07:03:45 2026 -0700 md/raid1,raid10: don't fail devices for invalid IO errors [ Upstream commit f7b24c7b41f23b5f9caa8b913afe79cd4c397d39 ] BLK_STS_INVAL indicates the IO request itself was invalid, not that the device has failed. When raid1 treats this as a device error, it retries on alternate mirrors which fail the same way, eventually exceeding the read error threshold and removing the device from the array. This happens when stacking configurations bypass bio_split_to_limits() in the IO path: dm-raid calls md_handle_request() directly without going through md_submit_bio(), skipping the alignment validation that would otherwise reject invalid bios early. The invalid bio reaches the lower block layers, which fail the bio with BLK_STS_INVAL, and raid1 wrongly interprets this as a device failure. Add BLK_STS_INVAL to raid1_should_handle_error() so that invalid IO errors are propagated back to the caller rather than triggering device removal. This is consistent with the previous kernel behavior when alignment checks were done earlier in the direct-io path. Fixes: 5ff3f74e145adc7 ("block: simplify direct io validity check") Reported-by: Tomáš Trnka Closes: https://lore.kernel.org/linux-block/2982107.4sosBPzcNG@electra/ Signed-off-by: Keith Busch Tested-by: Tomáš Trnka Link: https://lore.kernel.org/r/20260416140345.3872265-1-kbusch@meta.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit bb71c5101a824e63682a2402f57c7a56b210dd54 Author: William A. Kennington III Date: Thu Apr 23 00:46:52 2026 -0700 net: mctp i2c: check length before marking flow active [ Upstream commit 4ca07b9239bd0478ae586632a2ed72be37ed8407 ] Currently, mctp_i2c_get_tx_flow_state() is called before the packet length sanity check. This function marks a new flow as active in the MCTP core. If the sanity check fails, mctp_i2c_xmit() returns early without calling mctp_i2c_lock_nest(). This results in a mismatched locking state: the flow is active, but the I2C bus lock was never acquired for it. When the flow is later released, mctp_i2c_release_flow() will see the active state and queue an unlock marker. The TX thread will then decrement midev->i2c_lock_count from 0, causing it to underflow to -1. This underflow permanently breaks the driver's locking logic, allowing future transmissions to occur without holding the I2C bus lock, leading to bus collisions and potential hardware hangs. Move the mctp_i2c_get_tx_flow_state() call to after the length sanity check to ensure we only transition the flow state if we are actually going to proceed with the transmission and locking. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: William A. Kennington III Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20260423074741.201460-1-william@wkennington.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8f4a16200785f49cf02c5b71bdfe7a9dab63f23a Author: Zicheng Qu Date: Fri Apr 24 07:11:13 2026 +0000 sched/fair: Clear rel_deadline when initializing forked entities [ Upstream commit 3da56dc063cd77b9c0b40add930767fab4e389f3 ] A yield-triggered crash can happen when a newly forked sched_entity enters the fair class with se->rel_deadline unexpectedly set. The failing sequence is: 1. A task is forked while se->rel_deadline is still set. 2. __sched_fork() initializes vruntime, vlag and other sched_entity state, but does not clear rel_deadline. 3. On the first enqueue, enqueue_entity() calls place_entity(). 4. Because se->rel_deadline is set, place_entity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime. 5. However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline. 6. If the task later calls sched_yield(), yield_task_fair() advances se->vruntime to se->deadline. 7. The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight. 8. This corrupts cfs_rq->sum_w_vruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. pick_next_entity() may then return NULL unexpectedly, leading to a later NULL dereference. A captured trace shows the effect clearly. Before yield, the entity's vruntime was around: 9834017729983308 After yield_task_fair() executed: se->vruntime = se->deadline the vruntime jumped to: 19668035460670230 and the deadline was later advanced further to: 19668035463470230 This shows that the deadline had already become abnormally large before yield_task_fair() copied it into vruntime. rel_deadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked sched_entity should not inherit or retain this state. Clear se->rel_deadline in __sched_fork(), together with the other sched_entity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline. Fixes: 82e9d0456e06 ("sched/fair: Avoid re-setting virtual deadline on 'migrations'") Analyzed-by: Hui Tang Analyzed-by: Zhang Qiao Signed-off-by: Zicheng Qu Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260424071113.1199600-1-quzicheng@huawei.com Signed-off-by: Sasha Levin commit 59f5aa871718a950c5fca88e177db3b21da49899 Author: Vincent Guittot Date: Wed Apr 22 11:34:00 2026 +0200 sched/fair: Fix wakeup_preempt_fair() vs delayed dequeue [ Upstream commit ac8e69e693631689d74d8f1ebee6f84f737f797f ] Similar to how pick_next_entity() must dequeue delayed entities, so too must wakeup_preempt_fair(). Any delayed task being found means it is eligible and hence past the 0-lag point, ready for removal. Worse, by not removing delayed entities from consideration, it can skew the preemption decision, with the end result that a short slice wakeup will not result in a preemption. tip/sched/core tip/sched/core +this patch cyclictest slice (ms) (default)2.8 8 8 hackbench slice (ms) (default)2.8 20 20 Total Samples | 22559 22595 22683 Average (us) | 157 64( 59%) 59( 8%) Median (P50) (us) | 57 57( 0%) 58(- 2%) 90th Percentile (us) | 64 60( 6%) 60( 0%) 99th Percentile (us) | 2407 67( 97%) 67( 0%) 99.9th Percentile (us) | 3400 2288( 33%) 727( 68%) Maximum (us) | 5037 9252(-84%) 7461( 19%) Fixes: f12e148892ed ("sched/fair: Prepare pick_next_task() for delayed dequeue") Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260422093400.319251-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit 9da6aa3639a8ffdf99096f8ea457d098155486a6 Author: Takashi Iwai Date: Mon Apr 27 17:15:04 2026 +0200 ALSA: usb-audio: Fix potential leak of pd at parsing UAC3 streams [ Upstream commit c39f0bc03f84ba64c9144c95714df1dc36150f6d ] At parsing UAC3 streams, we allocate a PD object at each time, and either assign or free it. But there is a case where the PD object may be leaked; namely, in __snd_usb_parse_audio_interface() loop, when an audioformat shares the same endpoint with others, it's put to a link and returns from snd_usb_add_audio_stream(), but the PD is forgotten afterwards. Overall, the treatment of PD object in the parser code is a bit flaky, and we should be more careful about the object ownership. This patch tries to fix the above case and improve the code a bit. The pd object is now managed with the auto-cleanup in the loop, and the ownership is updated when the pd object gets assigned to the stream, which guarantees the release of the leftover object. Fixes: 7edf3b5e6a45 ("ALSA: usb-audio: AudioStreaming Power Domain parsing") Link: https://patch.msgid.link/20260427151508.12544-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 99b114bf0f086d7c9c333502c2bf4de19d6c527b Author: Breno Leitao Date: Fri Apr 24 08:31:16 2026 -0700 netpoll: fix IPv6 local-address corruption [ Upstream commit 3bc179bc7146c26c9dff75d2943d10528274e301 ] netpoll_setup() decides whether to auto-populate the local source address by testing np->local_ip.ip, which only inspects the first 4 bytes of the union inet_addr storage. For an IPv6 netpoll whose caller-supplied local address has a zero high-32 bits (::1, ::, IPv4-mapped ::ffff:a.b.c.d, etc.), this misdetects the address as unset (which they are not, but the first 4 bytes are empty), calls netpoll_take_ipv6() and overwrites it with whatever matching link-local/global address the device happens to expose first. Introduce a helper netpoll_local_ip_unset() that picks the correct family-aware test (ipv6_addr_any() for IPv6, !.ip for IPv4) and use it from netpoll_setup(). Reproducer is something like: echo "::2" > local_ip echo 1 > enabled cat local_ip # before this fix: 2001:db8::1 (caller-supplied ::2 was clobbered) # after this fix: ::2 Fixes: b7394d2429c1 ("netpoll: prepare for ipv6") Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260424-netpoll_fix-v1-1-3a55348c625f@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ddf7647fd8e27b13f6251af830adfebaa5dcc640 Author: Altan Hacigumus Date: Thu Apr 23 18:46:38 2026 -0700 tcp: make probe0 timer handle expired user timeout [ Upstream commit 2b9f6f7065d4cfb65ba19126e0b35ac4544c3f3a ] tcp_clamp_probe0_to_user_timeout() computes remaining time in jiffies using subtraction with an unsigned lvalue. If elapsed probing time exceeds the configured TCP_USER_TIMEOUT, the underflow yields a large value. This ends up re-arming the probe timer for a full backoff interval instead of expiring immediately, delaying connection teardown beyond the configured timeout. Fix this by preventing underflow so user-set timeout expiration is handled correctly without extending the probe timer. Fixes: 344db93ae3ee ("tcp: make TCP_USER_TIMEOUT accurate for zero window probes") Link: https://lore.kernel.org/r/20260414013634.43997-1-ahacigu.linux@gmail.com Signed-off-by: Altan Hacigumus Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260424014639.54110-1-ahacigu.linux@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 445e45a2c3a078316a62d2d331a570cf34ef5079 Author: Florian Westphal Date: Fri Apr 24 16:58:38 2026 +0200 neigh: let neigh_xmit take skb ownership [ Upstream commit 4438113be604ee67a7bf4f81da6e1cca41332ce4 ] neigh_xmit always releases the skb, except when no neighbour table is found. But even the first added user of neigh_xmit (mpls) relied on neigh_xmit to release the skb (or queue it for tx). sashiko reported: If neigh_xmit() is called with an uninitialized neighbor table (for example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT and bypasses its internal out_kfree_skb error path. Because the return value of neigh_xmit() is ignored here, does this leak the SKB? Assume full ownership and remove the last code path that doesn't xmit or free skb. Fixes: 4fd3d7d9e868 ("neigh: Add helper function neigh_xmit") Signed-off-by: Florian Westphal Reviewed-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260424145843.74055-1-fw@strlen.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6db58ee730bf434d1afca91b91826e26688856ed Author: Morduan Zang Date: Thu Apr 23 09:05:57 2026 +0800 net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind [ Upstream commit 5b0c911bcdbd982f7748d11c0b39ec5808eae2de ] syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via pn_socket_autobind(): kernel BUG at net/phonet/socket.c:213! RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline] RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421 Call Trace: sock_sendmsg_nosec+0x112/0x150 net/socket.c:797 __sock_sendmsg net/socket.c:812 [inline] __sys_sendto+0x402/0x590 net/socket.c:2280 ... pn_socket_autobind() calls pn_socket_bind() with port 0 and, on -EINVAL, assumes the socket was already bound and asserts that the port is non-zero: err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn)); if (err != -EINVAL) return err; BUG_ON(!pn_port(pn_sk(sock->sk)->sobject)); return 0; /* socket was already bound */ However pn_socket_bind() also returns -EINVAL when sk->sk_state is not TCP_CLOSE, even when the socket has never been bound and pn_port() is still 0. In that case the BUG_ON() fires and panics the kernel from a user-triggerable path. Treat the "bind returned -EINVAL but pn_port() is still 0" case as a regular error and propagate -EINVAL to the caller instead of crashing. Existing callers already translate a non-zero return from pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here only changes behaviour from panic to a normal errno. Fixes: ba113a94b750 ("Phonet: common socket glue") Reported-by: syzbot+706f5eb79044e686c794@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=706f5eb79044e686c794 Suggested-by: Remi Denis-Courmont Signed-off-by: Morduan Zang Signed-off-by: zhanjun Acked-by: Rémi Denis-Courmont Link: https://patch.msgid.link/87A8960A2045AF3C+20260423010557.138124-1-zhangdandan@uniontech.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8f1ff8866cb9f655e5faea6994eb902960be8e04 Author: Weiming Shi Date: Thu Apr 23 00:19:58 2026 +0800 net/sched: taprio: fix NULL pointer dereference in class dump [ Upstream commit 3d07ca5c0fae311226f737963984bd94bb159a87 ] When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft() is called with new == NULL and stores NULL into q->qdiscs[cl - 1]. Subsequent RTM_GETTCLASS dump operations walk all classes via taprio_walk() and call taprio_dump_class(), which calls taprio_leaf() returning the NULL pointer, then dereferences it to read child->handle, causing a kernel NULL pointer dereference. The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user namespaces enabled, an unprivileged local user can trigger a kernel panic by creating a taprio qdisc inside a new network namespace, grafting an explicit child qdisc, deleting it, and requesting a class dump. The RTM_GETTCLASS dump itself requires no capability. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2478) Call Trace: tc_fill_tclass (net/sched/sch_api.c:1966) qdisc_class_dump (net/sched/sch_api.c:2326) taprio_walk (net/sched/sch_taprio.c:2514) tc_dump_tclass_qdisc (net/sched/sch_api.c:2352) tc_dump_tclass_root (net/sched/sch_api.c:2370) tc_dump_tclass (net/sched/sch_api.c:2431) rtnl_dumpit (net/core/rtnetlink.c:6864) netlink_dump (net/netlink/af_netlink.c:2325) rtnetlink_rcv_msg (net/core/rtnetlink.c:6959) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Fix this by substituting &noop_qdisc when new is NULL in taprio_graft(), a common pattern used by other qdiscs (e.g., multiq_graft()) to ensure the q->qdiscs[] slots are never NULL. This makes control-plane dump paths safe without requiring individual NULL checks. Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq) previously had explicit NULL guards that would drop/skip the packet cleanly, update those checks to test for &noop_qdisc instead. Without this, packets would reach taprio_enqueue_one() which increments the root qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc drops the packet but those counters are never rolled back, permanently inflating the root qdisc's statistics. After this change *old can be a valid qdisc, NULL, or &noop_qdisc. Only call qdisc_put(*old) in the first case to avoid decreasing noop_qdisc's refcount, which was never increased. Fixes: 665338b2a7a0 ("net/sched: taprio: dump class stats for the actual q->qdiscs[]") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Acked-by: Jamal Hadi Salim Tested-by: Weiming Shi Link: https://patch.msgid.link/20260422161958.2517539-3-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5b251436b3a39cdfc5d9751bbb7d5957905b6b31 Author: Paul Geurts Date: Wed Apr 22 12:09:30 2026 +0200 NFC: trf7970a: Ignore antenna noise when checking for RF field [ Upstream commit a9bc28aa4e64320668131349436a650bf42591a5 ] The main channel Received Signal Strength Indicator (RSSI) measurement is used to determine whether an RF field is present or not. RSSI != 0 is interpreted as an RF Field is present. This does not take RF noise and measurement inaccuracy into account, and results in false positives in the field. Define a noise level and make sure the RF field is only interpreted as present when the RSSI is above the noise level. Fixes: 851ee3cbf850 ("NFC: trf7970a: Don't turn on RF if there is already an RF field") Signed-off-by: Paul Geurts Reviewed-by: Krzysztof Kozlowski Reviewed-by: Mark Greer Link: https://patch.msgid.link/20260422100930.581237-1-paul.geurts@prodrive-technologies.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8ea8f47bd7d7b392d0098a87dcfe892d0a8909ec Author: Felix Gu Date: Tue Apr 28 01:42:00 2026 +0800 spi: amlogic-spisg: initialize completion before requesting IRQ [ Upstream commit 8d0189c1ea98b56481eb809e3d1bdbf85557e819 ] Move init_completion(&spisg->completion) to before devm_request_irq() to avoid a potential race condition where an interrupt could fire before the completion structure is initialized. Fixes: cef9991e04ae ("spi: Add Amlogic SPISG driver") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260428-amlogic-spisg-v1-1-8eecc3b446d6@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 30a2a2bf245cafa6b5430af5e97c50429f1edb25 Author: Morduan Zang Date: Fri Apr 24 09:55:17 2026 +0800 net: usb: rtl8150: free skb on usb_submit_urb() failure in xmit [ Upstream commit adbe2cdf75461891e50dbe11896ac78e9af1f874 ] When rtl8150_start_xmit() fails to submit the tx URB, the URB is never handed to the USB core and write_bulk_callback() will not run. The driver returns NETDEV_TX_OK, which tells the networking stack that the skb has been consumed, but nothing actually frees the skb on this error path: dev->tx_skb = skb; ... if ((res = usb_submit_urb(dev->tx_urb, GFP_ATOMIC))) { ... /* no kfree_skb here */ } return NETDEV_TX_OK; This leaks the skb on every submit failure and also leaves dev->tx_skb pointing at memory that the driver itself may later free, which is fragile. Free the skb with dev_kfree_skb_any() in the error path and clear dev->tx_skb so no stale pointer is left behind. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Andrew Lunn Signed-off-by: Morduan Zang Link: https://patch.msgid.link/E7D3E1C013C5A859+20260424015517.9574-1-zhangdandan@uniontech.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4dd7eb94f79486b77ca6b4c8676aedbc465dc802 Author: Zhan Jun Date: Thu Apr 23 08:49:12 2026 +0800 net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit() [ Upstream commit 23f0e34c64acba15cad4d23e50f41f533da195fa ] syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit() when accessing skb->len for tx statistics after usb_submit_urb() has been called: BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c:712 Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226 The URB completion handler write_bulk_callback() frees the skb via dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU in softirq context before usb_submit_urb() returns in the submitter, so by the time the submitter reads skb->len the skb has already been queued to the per-CPU completion_queue and freed by net_tx_action(): CPU A (xmit) CPU B (USB completion softirq) ------------ ------------------------------ dev->tx_skb = skb; usb_submit_urb() --+ |-------> write_bulk_callback() | dev_kfree_skb_irq(dev->tx_skb) | net_tx_action() | napi_skb_cache_put() <-- free netdev->stats.tx_bytes | += skb->len; <-- UAF read Fix it by caching skb->len before submitting the URB and using the cached value when updating the tx_bytes counter. The pre-existing tx_bytes semantics are preserved: the counter tracks the original frame length (skb->len), not the ETH_ZLEN/USB-alignment padded "count" value that is handed to the device. Changing that would be a user-visible accounting change and is out of scope for this UAF fix. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+3f46c095ac0ca048cb71@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e69ee7.050a0220.24bfd3.002b.GAE@google.com/ Closes: https://syzkaller.appspot.com/bug?extid=3f46c095ac0ca048cb71 Reviewed-by: Andrew Lunn Signed-off-by: Zhan Jun Link: https://patch.msgid.link/809895186B866C10+20260423004913.136655-1-zhangdandan@uniontech.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d47204c127992da0c976ac9747070a575912e0fe Author: Ido Schimmel Date: Thu Apr 23 09:36:07 2026 +0300 vrf: Fix a potential NPD when removing a port from a VRF [ Upstream commit 2674d603a9e6970463b2b9ebcf8e31e90beae169 ] RCU readers that identified a net device as a VRF port using netif_is_l3_slave() assume that a subsequent call to netdev_master_upper_dev_get_rcu() will return a VRF device. They then continue to dereference its l3mdev operations. This assumption is not always correct and can result in a NPD [1]. There is no RCU synchronization when removing a port from a VRF, so it is possible for an RCU reader to see a new master device (e.g., a bridge) that does not have l3mdev operations. Fix by adding RCU synchronization after clearing the IFF_L3MDEV_SLAVE flag. Skip this synchronization when a net device is removed from a VRF as part of its deletion and when the VRF device itself is deleted. In the latter case an RCU grace period will pass by the time RTNL is released. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:l3mdev_fib_table_rcu (net/l3mdev/l3mdev.c:181) [...] Call Trace: l3mdev_fib_table_by_index (net/l3mdev/l3mdev.c:201 net/l3mdev/l3mdev.c:189) __inet_bind (net/ipv4/af_inet.c:499 (discriminator 3)) inet_bind_sk (net/ipv4/af_inet.c:469) __sys_bind (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:1951 (discriminator 1)) __x64_sys_bind (net/socket.c:1969 (discriminator 1) net/socket.c:1967 (discriminator 1) net/socket.c:1967 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking") Reported-by: Haoze Xie Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Yuan Tan Closes: https://lore.kernel.org/netdev/20260419145332.3988923-1-n05ec@lzu.edu.cn/ Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260423063607.1208202-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f6e59487a2edbce74765ee13fe94306cd4646d8b Author: Eric Dumazet Date: Thu Apr 23 06:35:27 2026 +0000 net/sched: sch_fq_pie: annotate data-races in fq_pie_dump_stats() [ Upstream commit 59b145771c7982cfe9020d4e9e22da92d6b5ae31 ] fq_codel_dump_stats() acquires the qdisc spinlock a bit too late. Move this acquisition before we fill tc_fq_pie_xstats with live data. Alternative would be to add READ_ONCE() and WRITE_ONCE() annotations, but the spinlock is needed anyway to scan q->new_flows and q->old_flows. Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260423063527.2568262-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ba77fa0be98e0bdf1881274f264f07e445f93768 Author: Eric Dumazet Date: Thu Apr 23 06:28:39 2026 +0000 net/sched: sch_choke: annotate data-races in choke_dump_stats() [ Upstream commit d3aeb889dcbd78e95f500d383799a23d949796e0 ] choke_dump_stats() only runs with RTNL held. It reads fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260423062839.2524324-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d78c8ab7bd84952e053d0c622b7fc1b4ad8a19a3 Author: Lorenzo Bianconi Date: Fri Apr 24 11:00:28 2026 +0200 net: airoha: Do not read uninitialized fragment address in airoha_dev_xmit() [ Upstream commit bde34e84edc8b5571fbde7e941e175a4293ee1eb ] The transmit loop in airoha_dev_xmit() reads fragment address and length during its final iteration, when the loop index equals skb_shinfo(skb)->nr_frags, at which point the fragment data is uninitialized. While these values are never consumed, the read itself is unsafe and may trigger a page fault. Fix this by avoiding the fragment read on the last iteration. Additionally, move the skb pointer from the first to the last used packet descriptor, so that airoha_qdma_tx_napi_poll() defers freeing the skb until the final descriptor is processed. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260424-airoha-xmit-fix-read-frag-v1-1-fdc0a83c79e8@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7b3b5cdaa8f3fc34e6b99cc9937459dd500d6a3e Author: Lorenzo Bianconi Date: Tue Apr 21 10:53:33 2026 +0200 net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs() [ Upstream commit e070aac63b42bf81f4dc565f9f841ff47e6c992f ] Do not wake every netdev TX queue across all ports sharing the QDMA running netif_tx_wake_all_queues routine in airoha_qdma_wake_netdev_txqs() but only the ones that are mapped the specific QDMA stopped hw TX queue. This patch can potentially avoid waking already stopped netdev TX queues that are mapped to a different QDMA hw TX queue. Introduce airoha_qdma_get_txq utility routine. Fixes: b94769eb2f30 ("net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f56a05577d0fef715ba1951bc2b09700742277c6 Author: Zhengping Zhang Date: Thu Feb 26 10:37:08 2026 +0800 net: airoha: fix typo in function name [ Upstream commit aebf15e8eb09b01e99f043e9f5d423798aac9d32 ] Corrected the typo in the function name from `airhoa_is_lan_gdm_port` to `airoha_is_lan_gdm_port`. This change ensures consistency in the API naming convention. Signed-off-by: Zhengping Zhang Reviewed-by: Simon Horman Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/tencent_E4FD5D6BC0131E617D848896F5F9FCED6E0A@qq.com Signed-off-by: Jakub Kicinski Stable-dep-of: e070aac63b42 ("net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()") Signed-off-by: Sasha Levin commit e2e2c6a824651fb172e87cecdc12b71b764cae6e Author: Lorenzo Bianconi Date: Tue Apr 21 08:43:07 2026 +0200 net: airoha: stop net_device TX queue before updating CPU index [ Upstream commit 3854de7b38be742cf7558476956d12414cb274f2 ] Currently, airoha_eth driver updates the CPU index register prior of verifying whether the number of free descriptors has fallen below the threshold. Move net_device TX queue length check before updating the TX CPU index in order to update TX CPU index even if there are more packets to be transmitted but the net_device TX queue is going to be stopped accounting the inflight packets. Fixes: 1d304174106c ("net: airoha: Implement BQL support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ded2694247a55a16d0ebbe2d6f9139305c21457a Author: Lorenzo Bianconi Date: Tue Apr 21 08:35:11 2026 +0200 net: airoha: fix BQL imbalance in TX path [ Upstream commit 2d9f5a118205da2683ffcec78b9347f1f01a820e ] Fix a possible BQL imbalance in airoha_dev_xmit(), where inflight packets are accounted only for the AIROHA_NUM_TX_RING netdev TX queues. The queue index is computed as: qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx) txq = netdev_get_tx_queue(dev, qid); However, airoha_qdma_tx_napi_poll() accounts completions across all netdev TX queues (num_tx_queues), leading to inconsistent BQL accounting. Also reset all netdev TX queues in the ndo_stop callback. Fixes: 1d304174106c ("net: airoha: Implement BQL support") Fixes: c9f947769b77 ("net: airoha: Reset BQL stopping the netdevice") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260421-airoha-fix-bql-v1-1-f135afe4275b@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2c258836848db362327a298eb91f53c823f769ad Author: Stephen Hemminger Date: Fri Apr 17 20:19:44 2026 -0700 net/sched: netem: check for negative latency and jitter [ Upstream commit 90be9fedb218ee95a1cf59050d1306fbfb0e8b87 ] Reject requests with negative latency or jitter. A negative value added to current timestamp (u64) wraps to an enormous time_to_send, disabling dequeue. The original UAPI used u32 for these values; the conversion to 64-bit time values via TCA_NETEM_LATENCY64 and TCA_NETEM_JITTER64 allowed signed values to reach the kernel without validation. Jitter is already silently clamped by an abs() in netem_change(); that abs() can be removed in a follow-up once this rejection is in place. Fixes: 99803171ef04 ("netem: add uapi to express delay and jitter in nanoseconds") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-7-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b6689c6da9b37a41f059fe4d611095bd15c51568 Author: Stephen Hemminger Date: Fri Apr 17 20:19:43 2026 -0700 net/sched: netem: fix slot delay calculation overflow [ Upstream commit 51e94e1e2fef351c74d69eb53666df808d26af95 ] get_slot_next() computes a random delay between min_delay and max_delay using: get_random_u32() * (max_delay - min_delay) >> 32 This overflows signed 64-bit arithmetic when the delay range exceeds approximately 2.1 seconds (2^31 nanoseconds), producing a negative result that effectively disables slot-based pacing. This is a realistic configuration for WAN emulation (e.g., slot 1s 5s). Use mul_u64_u32_shr() which handles the widening multiply without overflow. Fixes: 0a9fe5c375b5 ("netem: slotting with non-uniform distribution") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-6-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit afc308303b3c7d35e9154651bf934eb493e7b3c2 Author: Stephen Hemminger Date: Fri Apr 17 20:19:42 2026 -0700 net/sched: netem: validate slot configuration [ Upstream commit 01801c359a74737b9b1aa28568b60374d857241a ] Reject slot configurations that have no defensible meaning: - negative min_delay or max_delay - min_delay greater than max_delay - negative dist_delay or dist_jitter - negative max_packets or max_bytes Negative or out-of-order delays underflow in get_slot_next(), producing garbage intervals. Negative limits trip the per-slot accounting (packets_left/bytes_left <= 0) on the first packet of every slot, defeating the rate-limiting half of the slot feature. Note that dist_jitter has been silently coerced to its absolute value by get_slot() since the feature was introduced; rejecting negatives here converts that silent coercion into -EINVAL. The abs() can be removed in a follow-up. Fixes: 836af83b54e3 ("netem: support delivering packets in delayed time slots") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-5-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3ebeb830a2beeaf5a8d8473303750441b286e305 Author: Stephen Hemminger Date: Fri Apr 17 20:19:41 2026 -0700 net/sched: netem: only reseed PRNG when seed is explicitly provided [ Upstream commit 986afaf809940577224a99c3a08d97a15eb37e93 ] netem_change() unconditionally reseeds the PRNG on every tc change command. If TCA_NETEM_PRNG_SEED is not specified, a new random seed is generated, destroying reproducibility for users who set a deterministic seed on a previous change. Move the initial random seed generation to netem_init() and only reseed in netem_change() when TCA_NETEM_PRNG_SEED is explicitly provided by the user. Fixes: 4072d97ddc44 ("netem: add prng attribute to netem_sched_data") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-4-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 936a7dd87251f6f3e88983350833edf60fe6a80b Author: Stephen Hemminger Date: Fri Apr 17 20:19:40 2026 -0700 net/sched: netem: fix queue limit check to include reordered packets [ Upstream commit 4185701fcce6b426b6c3630b25330dddd9c47b0d ] The queue limit check in netem_enqueue() uses q->t_len which only counts packets in the internal tfifo. Packets placed in sch->q by the reorder path (__qdisc_enqueue_head) are not counted, allowing the total queue occupancy to exceed sch->limit under reordering. Include sch->q.qlen in the limit check. Fixes: f8d4bc455047 ("net/sched: netem: account for backlog updates from child qdisc") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-3-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3289c5a1f53151645e2b047cd20d366b738484ea Author: Stephen Hemminger Date: Fri Apr 17 20:19:39 2026 -0700 net/sched: netem: fix probability gaps in 4-state loss model [ Upstream commit 732b463449fd0ef90acd13cda68eab1c91adb00c ] The 4-state Markov chain in loss_4state() has gaps at the boundaries between transition probability ranges. The comparisons use: if (rnd < a4) else if (a4 < rnd && rnd < a1 + a4) When rnd equals a boundary value exactly, neither branch matches and no state transition occurs. The redundant lower-bound check (a4 < rnd) is already implied by being in the else branch. Remove the unnecessary lower-bound comparisons so the ranges are contiguous and every random value produces a transition, matching the GI (General and Intuitive) loss model specification. This bug goes back to original implementation of this model. Fixes: 661b79725fea ("netem: revised correlated loss generator") Signed-off-by: Stephen Hemminger Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260418032027.900913-2-stephen@networkplumber.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bc6002865e8c4fcf9e94975f7cf023448d8764e2 Author: Nikola Z. Ivanov Date: Sun Apr 26 23:14:34 2026 +0300 netdevsim: zero initialize struct iphdr in dummy sk_buff [ Upstream commit 35eaa6d8d6c2ee65e96f507add856e0eacf24591 ] Syzbot reports a KMSAN uninit-value originating from nsim_dev_trap_skb_build, with the allocation also being performed in the same function. Fix this by calling skb_put_zero instead of skb_put to guarantee zero initialization of the whole IP header. Closes: https://syzkaller.appspot.com/bug?extid=23d7fcd204e3837866ff Fixes: da58f90f11f5 ("netdevsim: Add devlink-trap support") Signed-off-by: Nikola Z. Ivanov Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260426201434.742030-1-zlatistiv@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 72938921f6a9c5c1ad83810cc4792c631a358b59 Author: Felix Gu Date: Tue Apr 28 00:33:04 2026 +0800 spi: axiado: replace usleep_range() with udelay() in IRQ path [ Upstream commit f5c6a272b699b9a0698535e1a56e683207e50030 ] ax_spi_fill_tx_fifo() can be called from ax_spi_irq() which is a hard irq handler. Replace usleep_range(10, 10) with udelay(10) in atomic context. Fixes: e75a6b00ad79 ("spi: axiado: Add driver for Axiado SPI DB controller") Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260428-axiado-v1-1-cd767500af72@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c8690f541a28136e4a70c7f0e12789c510ecd77c Author: Daan De Meyer Date: Mon Apr 27 22:01:39 2026 +0100 cdrom, scsi: sr: propagate read-only status to block layer via set_disk_ro() [ Upstream commit 0898a817621a2f0cddca8122d9b974003fe5036d ] The cdrom core never calls set_disk_ro() for a registered device, so BLKROGET on a CD-ROM device always returns 0 (writable), even when the drive has no write capabilities and writes will inevitably fail. This causes problems for userspace that relies on BLKROGET to determine whether a block device is read-only. For example, systemd's loop device setup uses BLKROGET to decide whether to create a loop device with LO_FLAGS_READ_ONLY. Without the read-only flag, writes pass through the loop device to the CD-ROM and fail with I/O errors. systemd-fsck similarly checks BLKROGET to decide whether to run fsck in no-repair mode (-n). The write-capability bits in cdi->mask come from two different sources: CDC_DVD_RAM and CDC_CD_RW are populated by the driver from the MODE SENSE capabilities page (page 0x2A) before register_cdrom() is called, while CDC_MRW_W and CDC_RAM require the MMC GET CONFIGURATION command and were only probed by cdrom_open_write() at device open time. This meant that any attempt to compute the writable state from the full mask at probe time was incorrect, because the GET CONFIGURATION bits were still unset (and cdi->mask is initialized such that capabilities are assumed present). Fix this by factoring the GET CONFIGURATION probing out of cdrom_open_write() into a new exported helper, cdrom_probe_write_features(), and having sr call it from sr_probe() right after get_capabilities() has populated the MODE SENSE bits. register_cdrom() then calls set_disk_ro() based on the full write-capability mask (CDC_DVD_RAM | CDC_MRW_W | CDC_RAM | CDC_CD_RW) so the block layer reflects the drive's actual write support. The feature queries used (CDF_MRW and CDF_RWRT via GET CONFIGURATION with RT=00) report drive-level capabilities that are persistent across media, so a single probe before register_cdrom() is sufficient and the redundant probe at open time is dropped. With set_disk_ro() now accurate, the long-vestigial cd->writeable flag in sr can go: get_capabilities() used to set cd->writeable based on the same four mask bits, but because CDC_MRW_W and CDC_RAM default to "capability present" in cdi->mask and aren't touched by MODE SENSE, the condition that gated cd->writeable was always true, making it unconditionally 1. Replace the corresponding gate in sr_init_command() with get_disk_ro(cd->disk), which turns a previously no-op check into a real one and also catches kernel-internal bio writers that bypass blkdev_write_iter()'s bdev_read_only() check. The sd driver (SCSI disks) does not have this problem because it checks the MODE SENSE Write Protect bit and calls set_disk_ro() accordingly. The sr driver cannot use the same approach because the MMC specification does not define the WP bit in the MODE SENSE device-specific parameter byte for CD-ROM devices. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Daan De Meyer Reviewed-by: Phillip Potter Reviewed-by: Martin K. Petersen Signed-off-by: Phillip Potter Link: https://patch.msgid.link/20260427210139.1400-2-phil@philpotter.co.uk Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c5aaca6c5fa1ff2ef23948f9f497dee7610faec1 Author: Tony Luck Date: Tue Apr 21 08:02:16 2026 -0700 ACPI: APEI: EINJ: Fix EINJV2 memory error injection [ Upstream commit 0c00cfbcfcffa7085e4f0c7fd7a4caada4e7a90f ] Error types in EINJV2 use different bit positions for each flavor of injection from legacy EINJ. Two issues: 1) The address sanity checks in einj_error_inject() were skipped for EINJV2 injections. Noted by sashiko[1] 2) __einj_error_trigger() failed to drop the entry of the target physical address from the list of resources that need to be requested. Add a helper function that checks if an injection is to memory and use it to solve each of these issues. Note that the old test in __einj_error_trigger() checked that param2 was not zero. This isn't needed because the sanity checks in einj_error_inject() reject memory injections with param2 == 0. Fixes: b47610296d17 ("ACPI: APEI: EINJ: Enable EINJv2 error injections") Reported-by: sashiko Reported-by: Herman Li Signed-off-by: Tony Luck Tested-by: "Lai, Yi1" Link: https://sashiko.dev/#/patchset/20260415163620.12957-1-tony.luck%40intel.com # [1] Reviewed-by: Jiaqi Yan Reviewed-by: Zaid Alali Link: https://patch.msgid.link/20260421150216.11666-3-tony.luck@intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d60bed8139ed0803ba528500ce22a14c653ed339 Author: Tony Luck Date: Tue Apr 21 08:02:15 2026 -0700 ACPICA: Provide #defines for EINJV2 error types [ Upstream commit 1f6008538384453eb4c13a3d7ff9e37ee8aee6b9 ] EINJV2 defined new error types by moving the severity (correctable, uncorrectable non-fatal, uncorrectable fatal) out of the "type". ACPI 6.5 introduced EINJV2 and defined a vendor defined error type using bit 31. This was dropped in ACPI 6.6. Link: https://github.com/acpica/acpica/commit/e82d2d2fd145 Signed-off-by: Tony Luck Link: https://patch.msgid.link/20260421150216.11666-2-tony.luck@intel.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: 0c00cfbcfcff ("ACPI: APEI: EINJ: Fix EINJV2 memory error injection") Signed-off-by: Sasha Levin commit 59b8f8c3a2a582377ad900334edaf7ff03259c4d Author: Miquel Raynal Date: Fri Apr 10 19:41:05 2026 +0200 mtd: spinand: winbond: Fix ODTR write VCR on W35NxxJW [ Upstream commit 135ac3b84bcedae1860e7a9512d63166f42b736e ] In most scenarios this variant is actually unused (VCR is written in SSDR mode), but we need to provide an octal variant. The address is 24 bits but is sent over 4 bytes MSB first. This means we need to shift the register address by one extra byte for the address to be correct. I didn't catch this initially because the volatile register region is 256 bytes wide, so the write-then-read procedure did work with the small register addresses I was using at that time: 0 and 1. Fixes: 44a2f49b9bdc ("mtd: spinand: winbond: W35N octal DTR support") Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 0b70a9deb63cf40199f9f29d919ac5515e031372 Author: Miquel Raynal Date: Fri Apr 10 19:41:04 2026 +0200 mtd: spinand: winbond: Set the packed page read flag to W35N02/04JW [ Upstream commit 8d655748aba1b603c54053a20322401dc1e5d782 ] Both W35N02JW and W35N04JW diverge from W35N01JW when it comes to the "data read" operation in ODTR mode. In order to stuff more address bits (up to 18), the second command byte is replaced by the most significant address bits, keeping the number of address bytes to 2. Fixes: 44a2f49b9bdc ("mtd: spinand: winbond: W35N octal DTR support") Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit c888833ef826fe9bbf41f566d28c7435793b308d Author: Miquel Raynal Date: Fri Apr 10 19:41:03 2026 +0200 mtd: spinand: Add support for packed read data ODTR commands [ Upstream commit 5e25407b68f460142539536e31fa20338db6146f ] Some devices stuff address bits in the double byte opcode (in place of the repeated byte) in order to be able to increase the size of the devices, without adding extra address bytes. Create a flag to identify those devices. When the flag is set, use the "packed" variant for the read data operation. Signed-off-by: Miquel Raynal Stable-dep-of: 8d655748aba1 ("mtd: spinand: winbond: Set the packed page read flag to W35N02/04JW") Signed-off-by: Sasha Levin commit e62eac1fbcb35bf410dededba6aa1d670d900aa3 Author: Miquel Raynal Date: Fri Apr 10 19:41:02 2026 +0200 spi: spi-mem: Add a packed command operation [ Upstream commit f79ee9e4b23244e77b28d176ce99a2d84d813ac5 ] Instead of repeating the command opcode twice, some flash devices try to pack command and address bits. In this case, the second opcode byte being sent (LSB) is free to be used. The input data must be ANDed to only provide the relevant bits. Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20260410-winbond-6-19-rc1-oddr-v1-2-2ac4827a3868@bootlin.com Signed-off-by: Mark Brown Stable-dep-of: 8d655748aba1 ("mtd: spinand: winbond: Set the packed page read flag to W35N02/04JW") Signed-off-by: Sasha Levin commit f7e0ca52dcc69be40b057d6cfbf17b30f67859f1 Author: Wentao Guan Date: Mon Apr 13 17:54:59 2026 +0800 arm64/scs: Fix potential sign extension issue of advance_loc4 [ Upstream commit 4023b7424ecd5d38cc75b650d6c1bf630ef8cb40 ] The expression (*opcode++ << 24) and exp * code_alignment_factor may overflow signed int and becomes negative. Fix this by casting each byte to u64 before shifting. Also fix the misaligned break statement while we are here. Example of the result can be seen here: Link: https://godbolt.org/z/zhY8d3595 It maybe not a real problem, but could be a issue in future. Fixes: d499e9627d70 ("arm64/scs: Fix handling of advance_loc4") Signed-off-by: Wentao Guan Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 29ddb724e812c1abbcd860685f72e95e0b508054 Author: Geert Uytterhoeven Date: Tue Apr 21 09:48:32 2026 +0200 drm/color-mgmt: Typo s/R332/RGB332/ [ Upstream commit 9d5a2b8f6281f6090002517fb9272ea07038afe8 ] Fix a typo of "RGB332" in kerneldoc for the drm_crtc_fill_palette_332() helper. Fixes: 7ff61177b7116825 ("drm/color-mgmt: Prepare for RGB332 palettes") Signed-off-by: Geert Uytterhoeven Reviewed-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/c413e45c8f752a532a4ff377f7a8b9eaab4a082a.1776757681.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit e8971c78e70c3257a02f396413f707fd8222c75a Author: Yuho Choi Date: Sun Apr 19 20:25:13 2026 -0400 drm/sysfb: ofdrm: fix PCI device reference leaks [ Upstream commit 4aa8110000b0d215deef8eed283565dd0c1def88 ] display_get_pci_dev_of() gets a referenced PCI device via pci_get_device(). Drop that reference when pci_enable_device() fails and release it during the managed teardown path after pci_disable_device(). Without that, ofdrm leaks the pci_dev reference on both the error path and the normal cleanup path. Fixes: c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers") Co-developed-by: Myeonghun Pak Signed-off-by: Myeonghun Pak Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Co-developed-by: Taegyu Kim Signed-off-by: Taegyu Kim Signed-off-by: Yuho Choi Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patch.msgid.link/20260420002513.216-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin commit d5ca2ba62f2c65f0c3e2f496198c1e922a6aa97f Author: James Calligeros Date: Sat Apr 25 10:44:05 2026 +1000 ASoC: tas2770: Fix order of operations for temperature calculation [ Upstream commit c7ecb6a61908c2604dda6e42da66724d256de7b9 ] The order of operations to derive the temperature from the temp register values was wrong, since 1000 / 16 is not an integer. This resulted in the calculated temperature value deviating from the value represented by the registers slightly, which was most obvious when the registers were zeroed (-92.265 *C vs the expected -93.000 *C). Scale the reading before dividing the whole thing by 16 to correct this. Fixes: ff73e2780169 ("ASoC: tas2770: expose die temp to hwmon") Signed-off-by: James Calligeros Link: https://patch.msgid.link/20260425-tas27xx-hwmon-fixes-v1-3-83c13b8e8f54@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 824b59f352e4e37a50c2edcd130b61860798f49b Author: James Calligeros Date: Sat Apr 25 10:44:03 2026 +1000 ASoC: tas2764: Mark die temp register as volatile [ Upstream commit 4cfb5971c2fbfac061c23fb4224a3a008199de81 ] Reading the temperature register always returns the first value read from the chip due to regcache. Mark TAS2764_TEMP as volatile to prevent returning stale, cached values when reading the die temp. Fixes: 186dfc85f9a8 ("ASoC: tas2764: expose die temp to hwmon") Signed-off-by: James Calligeros Link: https://patch.msgid.link/20260425-tas27xx-hwmon-fixes-v1-1-83c13b8e8f54@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c773b5c7595f288bc421b00786726f23b8681f4d Author: John Madieu Date: Sat Apr 25 09:29:34 2026 +0000 spi: rockchip: Read ISR, not IMR, to detect cs-inactive IRQ [ Upstream commit b4683a239a409d65f88052f5630c748a8ba070cd ] rockchip_spi_isr() decides whether the current interrupt was the cs-inactive event by reading IMR: if (rs->cs_inactive && readl_relaxed(rs->regs + ROCKCHIP_SPI_IMR) & INT_CS_INACTIVE) ctlr->target_abort(ctlr); IMR is the interrupt mask register: it tells which sources are enabled, not which one fired. In the PIO path, rockchip_spi_prepare_irq() enables both INT_RF_FULL and INT_CS_INACTIVE in IMR when rs->cs_inactive is true: if (rs->cs_inactive) writel_relaxed(INT_RF_FULL | INT_CS_INACTIVE, rs->regs + ROCKCHIP_SPI_IMR); so the IMR check is always true once cs_inactive is enabled, and every PIO interrupt - including normal RF_FULL completions - is dispatched to ctlr->target_abort(), aborting the transfer. The bug is reachable on ROCKCHIP_SPI_VER2_TYPE2 in target mode with a DMA-capable controller when the transfer is short enough to fall back to PIO (rockchip_spi_can_dma() returns false below fifo_len). Read ISR (which is RISR masked by IMR) so the check actually reflects which interrupt fired, and parenthesise the expression for clarity while at it. Fixes: 869f2c94db92 ("spi: rockchip: Stop spi slave dma receiver when cs inactive") Signed-off-by: John Madieu Link: https://patch.msgid.link/20260425092936.2590132-2-john.madieu@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0b7696d0cd1b669007957a945449c0db7dcdb296 Author: Bard Liao Date: Fri Apr 24 18:50:31 2026 +0800 ASoC: SOF: Intel: add an empty adr_link [ Upstream commit 3c6f06a200796ae7b2b1065e8a6499b138e27a50 ] An empty adr_link is expected to terminate the for (adr_link = mach_params->links; adr_link->num_adr; adr_link++) loop. Allocate link_num + 1 links to add an empty adr_link. Fixes: 5226d19d4cae5 ("ASoC: SOF: Intel: use sof_sdw as default SDW machine driver") Signed-off-by: Bard Liao Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260424105031.114053-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 27310d8032023c1140335ff2b0069f311eae6f50 Author: Guilherme G. Piccoli Date: Thu Apr 23 15:30:58 2026 -0300 ASoC: amd: acp: Add DMI quirk for Valve Steam Deck OLED [ Upstream commit b0f6f4ac7d5d04fe2adcdd63ed1cd1ad505b8958 ] Commit 671dd2ffbd8b ("ASoC: amd: acp: Add new cpu dai and dailink creation for I2S BT instance") introduced a change that "broke" Steam Deck's audio probe, in the OLED model, as observed in the following dmesg snippet: [...] snd_sof_amd_vangogh 0000:04:00.5: Topology: ABI 3:26:0 Kernel ABI 3:23:1 sof_mach nau8821-max: ASoC: physical link acp-bt-codec (id 2) not exist sof_mach nau8821-max: ASoC: topology: could not load header: -22 snd_sof_amd_vangogh 0000:04:00.5: tplg amd/sof-tplg/sof-vangogh-nau8821-max.tplg component load failed -22 snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP topology -22 snd_sof_amd_vangogh 0000:04:00.5: ASoC error (-22): at snd_soc_component_probe() on 0000:04:00.5 sof_mach nau8821-max: ASoC: failed to instantiate card -22 sof_mach nau8821-max: error -EINVAL: Failed to register card(sof-nau8821-max) sof_mach nau8821-max: probe with driver sof_mach failed with error -22 [...] Notice the quotes in "broke": it's not really a bug in such commit, but instead a problem with a topology file from Steam Deck OLED. This was discussed to great extent in [1], and Cristian proposed a pretty simple and functional change that resolved the issue for the Deck's issue. That change, though, would break other devices, so it wasn't accepted upstream. And the proper suggested solution (fix the topology) was never implemented, so Valve's kernel (and anyone that wants to boot the mainline on Steam Deck OLED) is carrying that fix downstream. So, we propose hereby a different approach: a DMI quirk, as many already present in the sound drivers, to address this issue solely on Steam Deck OLED, not breaking other devices and as a bonus, allowing simple patch up in case eventually the topology file gets fixed (we'd just need to check against any DMI info reflecting that or the topology/FW versions). The motivation of such upstream quirk is related to users that want to test latest kernel trees on their devices and get no only non-working sound device, but seems some games (like Ori and the Blind Forest) can't properly work without a proper functional audio device. Example of such report can be seen at [2]. Cc: Mark Brown Cc: Robert Beckett Cc: Umang Jain Fixes: 671dd2ffbd8b ("ASoC: amd: acp: Add new cpu dai and dailink creation for I2S BT instance") Link: https://lore.kernel.org/r/20231209205351.880797-11-cristian.ciocaltea@collabora.com/ [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=218677 [2] Reviewed-by: Cristian Ciocaltea Reviewed-by: Mario Limonciello Tested-by: Melissa Wen Signed-off-by: Guilherme G. Piccoli Link: https://patch.msgid.link/20260423183505.116445-1-gpiccoli@igalia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3d534ab053b58c1cd0359964d4cf10e869f20fde Author: John Madieu Date: Sat Apr 25 02:47:25 2026 +0000 spi: rzv2h-rspi: Fix silent failure in clock setup error path [ Upstream commit 54900126ae0a2671f8790a7f95706b9ea95fac4e ] rzv2h_rspi_setup_clock() is declared to return u32 but returns -EINVAL when no valid clock parameters are found. Cast to u32, -EINVAL becomes 0xffffffea, which is a non-zero value. The caller in rzv2h_rspi_prepare_message() guards against failure with: rspi->freq = rzv2h_rspi_setup_clock(rspi, speed_hz); if (!rspi->freq) return -EINVAL; Because 0xffffffea is non-zero, the check is bypassed and the controller proceeds to program SPBR/SPCMD with stale values, leading to an unknown bit rate. Return 0 on the failed-search path, consistent with the existing clk_set_rate() failure path which already returns 0. Fixes: 77d931584dd3 ("spi: rzv2h-rspi: make transfer clock rate finding chip-specific") Signed-off-by: John Madieu Reviewed-by: Biju Das Reviewed-by: Cosmin Tanislav Link: https://patch.msgid.link/20260425024725.2393632-1-john.madieu.xa@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 523762e3b6933fff81f01dfa3c60c0774044cdab Author: Florian Westphal Date: Thu Apr 23 02:19:11 2026 +0200 netfilter: nf_conntrack_sip: don't use simple_strtoul [ Upstream commit 8cf6809cddcbe301aedfc6b51bcd4944d45795f6 ] Replace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(), and ct_sip_parse_request() with a new sip_parse_port() helper that validates each digit against the buffer limit, eliminating the use of simple_strtoul() which assumes NUL-terminated strings. The previous code dereferenced pointers without bounds checks after sip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated skb data. A port that reaches the buffer limit without a trailing character is also rejected as malformed. Also get rid of all simple_strtoul() usage in conntrack, prefer a stricter version instead. There are intentional changes: - Bail out if number is > UINT_MAX and indicate a failure, same for too long sequences. While we do accept 05535 as port 5535, we will not accept e.g. 'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261, we should restrict this to not waste cycles when presented with malformed packets with 64k '0' characters. - Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch 'expire=' and 'rports='; both are expected to use base-10. - In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k range. - epaddr_len now returns 0 if the port is invalid, as it already does for invalid ip addresses. This is intentional. nf_conntrack_sip performs lots of guesswork to find the right parts of the message to parse. Being stricter could break existing setups. Connection tracking helpers are designed to allow traffic to pass, not to block it. Based on an earlier patch from Jenny Guanni Qu . Fixes: 05e3ced297fe ("[NETFILTER]: nf_conntrack_sip: introduce SIP-URI parsing helper") Reported-by: Klaudia Kloc Reported-by: Dawid Moczadło Reported-by: Jenny Guanni Qu . Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 392cc1d8408b5665215c1e9290bbf0f92339b043 Author: Jiexun Wang Date: Fri Apr 17 20:25:06 2026 +0800 netfilter: xt_policy: fix strict mode inbound policy matching [ Upstream commit 4b2b4d7d4e203c92db8966b163edfacb1f0e1e29 ] match_policy_in() walks sec_path entries from the last transform to the first one, but strict policy matching needs to consume info->pol[] in the same forward order as the rule layout. Derive the strict-match policy position from the number of transforms already consumed so that multi-element inbound rules are matched consistently. Fixes: c4b885139203 ("[NETFILTER]: x_tables: replace IPv4/IPv6 policy match by address family independant version") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Jiexun Wang Signed-off-by: Ren Wei Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c78ececfea7e43c199607e7fd14349b1eaf17942 Author: Kent Russell Date: Wed Apr 22 09:34:04 2026 -0400 drm/amdgpu: Only send RMA CPER when threshold is exceeded [ Upstream commit b56922fc37454633b831a2a04a1537616742977d ] According to our documentation, the RMA should only occur when the threshold has been exceeded, not met. Fixes: 5028a24aa89a ("drm/amdgpu: Send applicable RMA CPERs at end of RAS init") Signed-off-by: Kent Russell Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher (cherry picked from commit 8bc09a7d0e90ec45a0b4865661cf45cbbce1c3d7) Signed-off-by: Sasha Levin commit 89002d2fea2477f14694d061a7874577dedcef6a Author: Timur Kristóf Date: Sat Apr 18 23:49:33 2026 +0200 drm/amdgpu/gfx6: Support harvested SI chips with disabled TCCs (v2) [ Upstream commit fe2b84f9228e2a0903221a4d0d8c350b018e9c0c ] This commit fixes amdgpu to work on the Radeon HD 7870 XT which has never worked with the Linux open source drivers before. Some boards have "harvested" chips, meaning that some parts of the chip are disabled and fused, and it's sold for cheaper and under a different marketing name. On a harvested chip, any of the following can be disabled: - CUs (Compute Units) - RBs (Render Backend, aka. ROP) - Memory channels (ie. the chip has a lower bandwidth) - TCCs (ie. less L2 cache) Handle chips with harvested TCCs by patching the registers that configure how TCCs are mapped. If some TCCs are disabled, we need to make sure that the disabled TCCs are not used, and the remaining TCCs are used optimally. TCP_CHAN_STEER_LO/HI control which TCC is used by TCP channels. TCP_ADDR_CONFIG.NUM_TCC_BANKS controls how many channels are used. Note that the TCC configuration is highly relevant to performance. Suboptimal configuration (eg. CHAN_STEER=0) can significantly reduce gaming performance. For optimal performance: - Rely on the CHAN_STEER from the golden registers table, only skip disabled TCCs but keep the mapping order. - Limit NUM_TCC_BANKS to number of active TCCs to avoid thrashing, which performs better than using the same TCC twice. v2: - Also consider CGTS_USER_TCC_DISABLE for disabled TCCs. Link: https://bugs.freedesktop.org/show_bug.cgi?id=60879 Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/2664 Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8") Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 00218d15528fab9f6b31241fe5904eea4fcaa30d) Signed-off-by: Sasha Levin commit 422c3d8ef6f37ad4aa73124b931fb8c6fb15ddc5 Author: Timur Kristóf Date: Sat Apr 18 23:49:31 2026 +0200 drm/amdgpu/uvd3.1: Don't validate the firmware when already validated [ Upstream commit 13e4cf116dbf7a1fb8123a59bea2c098f30d3736 ] UVD 3.1 firmware validation seems to always fail after attempting it when it had already been validated. (This works similarly with the VCE 1.0 as well.) Don't attempt repeating the validation when it's already done. This caused issues in situations when the system isn't able to suspend the GPU properly and so the GPU isn't actually powered down. Then amdgpu would fail when calling the IP block resume function. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/2887 Fixes: bb7978111dd3 ("drm/amdgpu: fix SI UVD firmware validate resume fail") Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 889a2cfd889c4a4dd9d0c89ce9a8e60b78be71dd) Signed-off-by: Sasha Levin commit 5c29d20470d4566d1b68df57097d642d01f8b427 Author: Christian König Date: Fri Apr 17 15:52:45 2026 +0200 drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG [ Upstream commit 0ef196a208385b7d7da79f411c161b04e97283e2 ] There were multiple issues in that code. First of all the order between the reset semaphore and the mm_lock was wrong (e.g. copy_to_user) was called while holding the lock. Then we allocated memory while holding the reset semaphore which is also a pretty big bug and can deadlock. Then we used down_read_trylock() instead of waiting for the reset to finish. Signed-off-by: Christian König Fixes: 9e823f307074 ("drm/amdgpu: Block MMR_READ IOCTL in reset") Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e) Signed-off-by: Sasha Levin commit 210a33da8fe77c9826e9805585df1f5c16bb6ccf Author: Yang Wang Date: Wed Apr 22 18:41:42 2026 +0800 drm/amd/pm: fix missing fine-grained dpm table flag on aldebaran [ Upstream commit ccf8932ed8cf4fbfdcd4df2c6b524913691ee700 ] Add the missing SMU_DPM_TABLE_FINE_GRAINED flag to aldebaran DPM table. This fixes the pp_dpm_sclk node issue caused by missing flag configuration. Fixes: 7ea1c722fe1d ("drm/amd/pm: Use common helper for aldebaran dpm table") Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher (cherry picked from commit 3427dea3a48ebddb491a26093f3627384b3cb2c2) Signed-off-by: Sasha Levin commit 0b95f432cb2f2c60e5401aeb8aed31e61a85b9bc Author: Timur Kristóf Date: Sat Apr 18 23:49:30 2026 +0200 drm/amdgpu/gmc: Fix AMDGPU_GART_PLACEMENT_LOW to not overlap with VRAM [ Upstream commit 36d65da7570bf72ce28504fa9a81abfc728e6d96 ] When the GART placement is set to AMDGPU_GART_PLACEMENT_LOW: Make sure that GART does not overlap with VRAM when VRAM is configured to be in the low address space. Solve this according to the following logic: - When GART fits before VRAM, use zero address for GART - Otherwise, put GART after the end of VRAM, aligned to 4 GiB Previously, I had assumed this was not possible so it was OK to not handle it, but now we got a report from a user who has a board that is configured this way. Fixes: 917f91d8d8e8 ("drm/amdgpu/gmc: add a way to force a particular placement for GART") Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 3d9de5d86a1658cadb311461b001eb1df67263ad) Signed-off-by: Sasha Levin commit c7c3ae7c01e5a0742b93cb9b40800bdd7f811e38 Author: Hongyan Xu Date: Wed Apr 22 20:38:17 2026 +0800 drm/amdgpu: avoid double drm_exec_fini() in userq validate [ Upstream commit 508babf310365f1107a2e8831c267c292a286818 ] When new_addition is true, amdgpu_userq_vm_validate() calls drm_exec_fini(&exec) before iterating over the collected HMM ranges and calling amdgpu_ttm_tt_get_user_pages(). If amdgpu_ttm_tt_get_user_pages() fails in that path, the code jumps to unlock_all and calls drm_exec_fini(&exec) a second time on the same exec object. drm_exec_fini() is not idempotent: it frees exec->objects and may also drop exec->contended and finalize the ww acquire context. Route that error path directly to the range cleanup once exec has already been finalized. Fixes: 42f148788469 ("drm/amdgpu/userqueue: validate userptrs for userqueues") Issue found using a prototype static analysis tool and confirmed by code review. Reviewed-by: Christian König Signed-off-by: Hongyan Xu Signed-off-by: Slavin Liu <220245772@seu.edu.cn> Signed-off-by: Alex Deucher (cherry picked from commit 2802952e4a07306da6ebe813ff1acacc5691851a) Signed-off-by: Sasha Levin commit aad5648ba88e9f4ffabed0860d90ee7e52625664 Author: Keith Busch Date: Tue Apr 21 09:14:02 2026 -0700 nvme-pci: fix missed admin queue sq doorbell write [ Upstream commit 1cc4cdae2a3b7730d462d69e30f213fd2efe7807 ] We can batch admin commands submitted through io_uring_cmd passthrough, which means bd->last may be false and skips the doorbell write to aggregate multiple commands per write. If a subsequent command can't be dispatched for whatever reason, we have to provide the blk-mq ops' commit_rqs callback in order to ensure we properly update the doorbell. Fixes: 58e5bdeb9c2b ("nvme: enable uring-passthrough for admin commands") Reviewed-by: Christoph Hellwig Reviewed-by: Kanchan Joshi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 4e69bfb32b2db323d9205fdb30e284481b37817c Author: Pablo Neira Ayuso Date: Wed Apr 15 22:58:23 2026 +0200 netfilter: nf_tables: add hook transactions for device deletions [ Upstream commit 10f79dbd7719d1da9f5884d13060322d8729f091 ] Restore the flag that indicates that the hook is going away, ie. NFT_HOOK_REMOVE, but add a new transaction object to track deletion of hooks without altering the basechain/flowtable hook_list during the preparation phase. The existing approach that moves the hook from the basechain/flowtable hook_list to transaction hook_list breaks netlink dump path readers of this RCU-protected list. It should be possible use an array for nft_trans_hook to store the deleted hooks to compact the representation but I am not expecting many hook object, specially now that wildcard support for devices is in place. Note that the nft_trans_chain_hooks() list contains a list of struct nft_trans_hook objects for DELCHAIN and DELFLOWTABLE commands, while this list stores struct nft_hook objects for NEWCHAIN and NEWFLOWTABLE. Note that new commands can be updated to use nft_trans_hook for consistency. This patch also adapts the event notification path to deal with the list of hook transactions. Fixes: 7d937b107108 ("netfilter: nf_tables: support for deleting devices in an existing netdev chain") Fixes: b6d9014a3335 ("netfilter: nf_tables: delete flowtable hooks via transaction list") Reported-by: Xiang Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1346be9379639c30877083b12747d4eacb83c24f Author: Pablo Neira Ayuso Date: Wed Apr 15 17:56:14 2026 +0200 netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase [ Upstream commit a6134e62dba2ea4f760b29d5226907f447c92400 ] Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on. Fixes: 78d9f48f7f44 ("netfilter: nf_tables: add devices to existing flowtable") Fixes: b9703ed44ffb ("netfilter: nf_tables: support for adding new devices to an existing netdev chain") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 66f81fb3c28f22d62f144c1e91b1c5f371f553b3 Author: Pablo Neira Ayuso Date: Wed Apr 15 17:56:02 2026 +0200 rculist: add list_splice_rcu() for private lists [ Upstream commit f902877b635551513729bdf9a8d1422c4aab7741 ] This patch adds a helper function, list_splice_rcu(), to safely splice a private (non-RCU-protected) list into an RCU-protected list. The function ensures that only the pointer visible to RCU readers (prev->next) is updated using rcu_assign_pointer(), while the rest of the list manipulations are performed with regular assignments, as the source list is private and not visible to concurrent RCU readers. This is useful for moving elements from a private list into a global RCU-protected list, ensuring safe publication for RCU readers. Subsystems with some sort of batching mechanism from userspace can benefit from this new function. The function __list_splice_rcu() has been added for clarity and to follow the same pattern as in the existing list_splice*() interfaces, where there is a check to ensure that the list to splice is not empty. Note that __list_splice_rcu() has no documentation for this reason. Reviewed-by: Paul E. McKenney Signed-off-by: Pablo Neira Ayuso Stable-dep-of: a6134e62dba2 ("netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase") Signed-off-by: Sasha Levin commit 0f33e8ad6ac563ae2233dd7f75884e0ee010521d Author: Florian Westphal Date: Thu Apr 16 15:14:51 2026 +0200 netfilter: nf_tables: use list_del_rcu for netlink hooks [ Upstream commit f3224ee463f8f6f6ced7dcdf6081add4f8128527 ] nft_netdev_unregister_hooks and __nft_unregister_flowtable_net_hooks need to use list_del_rcu(), this list can be walked by concurrent dumpers. Add a new helper and use it consistently. Fixes: f9a43007d3f7 ("netfilter: nf_tables: double hook unregistration in netns path") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ac698d81fd6619c7504cee913f1cab5285fba1b7 Author: Pablo Neira Ayuso Date: Mon Apr 20 23:15:32 2026 +0200 netfilter: arp_tables: fix IEEE1394 ARP payload parsing [ Upstream commit 1e8e3f449b1e73b73a843257635b9c50f0cc0f0a ] Weiming Shi says: "arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match()." Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi . Fixes: 6752c8db8e0c ("firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.") Reported-by: Xiang Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 046fa5c72d15cd8e2d592e275697ea399d8f76b0 Author: Maurizio Lombardi Date: Mon Mar 16 15:39:35 2026 +0100 nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers [ Upstream commit ea8e356acb165cb1fd75537a52e1f66e5e76c538 ] Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers. Fixes: 52a0a9854934 ("nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec") Reviewed-by: Hannes Reinecke Reviewed-by: Yunje Shin Reviewed-by: Chaitanya Kulkarni Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 77b9562bac74b1d034570aa829e4159d1943b363 Author: Breno Leitao Date: Mon Apr 20 06:25:09 2026 -0700 tracing: branch: Fix inverted check on stat tracer registration [ Upstream commit 3b75dd76e64a04771861bb5647951c264919e563 ] init_annotated_branch_stats() and all_annotated_branch_stats() check the return value of register_stat_tracer() with "if (!ret)", but register_stat_tracer() returns 0 on success and a negative errno on failure. The inverted check causes the warning to be printed on every successful registration, e.g.: Warning: could not register annotated branches stats while leaving real failures silent. The initcall also returned a hard-coded 1 instead of the actual error. Invert the check and propagate ret so that the warning fires on real errors and the initcall reports the correct status. Cc: Mathieu Desnoyers Cc: Ingo Molnar Cc: Frederic Weisbecker Link: https://patch.msgid.link/20260420-tracing-v1-1-d8f4cd0d6af1@debian.org Fixes: 002bb86d8d42 ("tracing/ftrace: separate events tracing and stats tracing engine") Signed-off-by: Breno Leitao Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 0210d68c60bc4777d00faf98ba51628b90771b56 Author: Mark Harmstone Date: Thu Apr 16 18:15:23 2026 +0100 btrfs: fix double-decrement of bytes_may_use in submit_one_async_extent() [ Upstream commit 82323b1a7088b7a5c3e528a5d634bff447fa286f ] submit_one_async_extent() calls btrfs_reserve_extent(), which decrements bytes_may_use. If the call btrfs_create_io_em() fails, we jump to out_free_reserve, which calls extent_clear_unlock_delalloc(). Because we're specifying EXTENT_DO_ACCOUNTING, i.e. EXTENT_CLEAR_META_RESV | EXTENT_CLEAR_DATA_RESV, this decreases bytes_may_use again. This can lead to problems later on, as an initial write can fail only for the writeback to silently ENOSPC. Fix this by replacing EXTENT_DO_ACCOUNTING with EXTENT_CLEAR_META_RESV. This parallels a4fe134fc1d8eb ("btrfs: fix a double release on reserved extents in cow_one_range()"), which is the same fix in cow_one_range(). Fixes: 151a41bc46df ("Btrfs: fix what bits we clear when erroring out from delalloc") Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 01cc967c6378d008da316dcf1126b09b53cefba4 Author: Mark Harmstone Date: Mon Mar 23 17:17:01 2026 +0000 btrfs: don't clobber errors in add_remap_tree_entries() [ Upstream commit 44366af74061793ee5ceef455a4f0e465892d0de ] In add_remap_tree_entries(), we only process a certain number of entries at a time, meaning we may need to loop. But because we weren't checking the return value of btrfs_insert_empty_items() within the loop, this meant that if the last iteration of the loop succeeded but a previous iteration failed, we were erroneously returning 0. Fix this by breaking the loop early if btrfs_insert_empty_items() fails. Fixes: b56f35560b82 ("btrfs: handle setting up relocation of block group with remap-tree") Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 806aeb061baf0c2d48e68515e0440264cd7a86c2 Author: Mark Harmstone Date: Mon Mar 23 12:59:57 2026 +0000 btrfs: fix bytes_may_use leak in do_remap_reloc_trans() [ Upstream commit 9b8824533d75fb199a3fb0f6147ffcca64b5caf8 ] If the call to btrfs_reserve_extent() in do_remap_reloc_trans() returns a smaller extent than we asked for, currently we're not undoing the bytes_may_use change that we made. Fix this by calling btrfs_space_info_update_bytes_may_use() again for the difference. Fixes: fd6594b1446c ("btrfs: replace identity remaps with actual remaps when doing relocations") Reviewed-by: Boris Burkov Signed-off-by: Mark Harmstone Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 662f4a8bd1db4dd552c0c4df900f9f7de848bec1 Author: Mark Harmstone Date: Mon Mar 23 12:59:47 2026 +0000 btrfs: fix bytes_may_use leak in move_existing_remap() [ Upstream commit 68a135013bf73dfd6a277f76fc4e088b0f3dfa79 ] If the call to btrfs_reserve_extent() in move_existing_remap() returns a smaller extent than we asked for, currently we're not undoing the bytes_may_use change that we made. Fix this by calling btrfs_space_info_update_bytes_may_use() again for the difference. Fixes: bbea42dfb91f ("btrfs: move existing remaps before relocating block group") Reviewed-by: Boris Burkov Signed-off-by: Mark Harmstone Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5c80289503da3658e3df80280598c68d181eadbd Author: Amir Goldstein Date: Mon Apr 20 14:58:00 2026 +0200 fsnotify: fix inode reference leak in fsnotify_recalc_mask() [ Upstream commit 4aca914ac152f5d055ddcb36704d1e539ac08977 ] fsnotify_recalc_mask() fails to handle the return value of __fsnotify_recalc_mask(), which may return an inode pointer that needs to be released via fsnotify_drop_object() when the connector's HAS_IREF flag transitions from set to cleared. This manifests as a hung task with the following call trace: INFO: task umount:1234 blocked for more than 120 seconds. Call Trace: __schedule schedule fsnotify_sb_delete generic_shutdown_super kill_anon_super cleanup_mnt task_work_run do_exit do_group_exit The race window that triggers the iref leak: Thread A (adding mark) Thread B (removing mark) ────────────────────── ──────────────────────── fsnotify_add_mark_locked(): fsnotify_add_mark_list(): spin_lock(conn->lock) add mark_B(evictable) to list spin_unlock(conn->lock) return /* ---- gap: no lock held ---- */ fsnotify_detach_mark(mark_A): spin_lock(mark_A->lock) clear ATTACHED flag on mark_A spin_unlock(mark_A->lock) fsnotify_put_mark(mark_A) fsnotify_recalc_mask(): spin_lock(conn->lock) __fsnotify_recalc_mask(): /* mark_A skipped: ATTACHED cleared */ /* only mark_B(evictable) remains */ want_iref = false has_iref = true /* not yet cleared */ -> HAS_IREF transitions true -> false -> returns inode pointer spin_unlock(conn->lock) /* BUG: return value discarded! * iput() and fsnotify_put_sb_watched_objects() * are never called */ Fix this by deferring the transition true -> false of HAS_IREF flag from fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B). Fixes: c3638b5b1374 ("fsnotify: allow adding an inode mark without pinning inode") Signed-off-by: Xin Yin Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/CAOQ4uxiPsbHb0o5voUKyPFMvBsDkG914FYDcs4C5UpBMNm0Vcg@mail.gmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit eff2ce3e6945a9dae69e8ac1f979381a614c7200 Author: Wolfram Sang Date: Fri Apr 17 09:42:36 2026 +0200 mailbox: mailbox-test: make data_ready a per-instance variable [ Upstream commit 6e937f4e769e60947909e3525965f0137b9039e8 ] While not the default case, multiple tests can be run simultaneously. Then, data_ready being a global variable will be overwritten and the per-instance lock will not help. Turn the global variable into a per-instance one to avoid this problem. Fixes: e339c80af95e ("mailbox: mailbox-test: don't rely on rx_buffer content to signal data ready") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 1213ba48964a09149805d0f62c576f2fe2a6cb92 Author: Wolfram Sang Date: Fri Apr 17 09:42:35 2026 +0200 mailbox: mailbox-test: initialize struct earlier [ Upstream commit bbcf9af68bfedb3d9cc3c7eae62f5c844d8b78b9 ] The waitqueue must be initialized before the debugfs files are created because from that time, requests from userspace can already be made. Similarily, drvdata and spinlock needs to be initialized before we request the channel, otherwise dangling irqs might run into problems like a NULL pointer exception. Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 240c71a2aea36a1a4210f911a1c32ea88777e8e4 Author: Wolfram Sang Date: Fri Apr 17 09:42:34 2026 +0200 mailbox: mailbox-test: don't free the reused channel [ Upstream commit 88ebadbf0deefdaccdab868b44ff70a0a257f473 ] The RX channel can be aliased to the TX channel if it has a different MMIO. This special case needs to be handled when freeing the channels otherwise a double-free occurs. Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 9f5dc5247cef1cd63c295eb398163189603c4dc0 Author: Wolfram Sang Date: Fri Apr 17 09:42:33 2026 +0200 mailbox: mailbox-test: handle channel errors consistently [ Upstream commit dd9aa1f269000d679f4ec12b32abacfc8d921413 ] mbox_test_request_channel() returns either an ERR_PTR or NULL. The callers, however, mostly checked for non-NULL which allows for bogus code paths when an ERR_PTR is treated like a valid channel. A later commit tried to fix it in one place but missed the other ones. Because the ERR_PTR is only used for -ENOMEM once and is converted to -EPROBE_DEFER anyhow, convert the callee to only return NULL which simplifies handling a lot and makes it less error prone. Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Fixes: 9b63a810c6f9 ("mailbox: mailbox-test: Fix an error check in mbox_test_probe()") Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 37792091ab28ba030fd8d61184c47d4d51294170 Author: Wolfram Sang Date: Mon Apr 13 12:42:38 2026 +0200 mailbox: add sanity check for channel array [ Upstream commit c1aad75595fb67edc7fda8af249d3b886efa1be9 ] Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here. Fixes: 2b6d83e2b8b7 ("mailbox: Introduce framework for mailbox") Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 87ef628531b72359c6a71b9dd5e152f59f16df91 Author: Guopeng Zhang Date: Fri Apr 17 11:37:41 2026 +0800 cgroup/cpuset: record DL BW alloc CPU for attach rollback [ Upstream commit 41d701ddc36d5301b44ea79529f3cf03c541c1e1 ] cpuset_can_attach() allocates DL bandwidth only when migrating deadline tasks to a disjoint CPU mask, but cpuset_cancel_attach() rolls back based only on nr_migrate_dl_tasks. This makes the DL bandwidth alloc/free paths asymmetric: rollback can call dl_bw_free() even when no dl_bw_alloc() was done. Rollback also needs to undo the reservation against the same CPU/root domain that was charged. Record the CPU used by dl_bw_alloc() and use that state in cpuset_cancel_attach(). If no allocation happened, dl_bw_cpu stays at -1 and rollback skips dl_bw_free(). If allocation did happen, bandwidth is returned to the same CPU/root domain. Successful attach paths are unchanged. This only fixes failed attach rollback accounting. Fixes: 2ef269ef1ac0 ("cgroup/cpuset: Free DL BW in case can_attach() fails") Signed-off-by: Guopeng Zhang Reviewed-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b13eaa382686983e40fba43bc10e91401ad86f82 Author: cuitao Date: Tue Apr 14 09:53:27 2026 +0800 cgroup/rdma: fix integer overflow in rdmacg_try_charge() [ Upstream commit c802f460dd485c1332b5a35e7adcfb2bc22536a2 ] The expression `rpool->resources[index].usage + 1` is computed in int arithmetic before being assigned to s64 variable `new`. When usage equals INT_MAX (the default "max" value), the addition overflows to INT_MIN. This negative value then passes the `new > max` check incorrectly, allowing a charge that should be rejected and corrupting usage to negative. Fix by casting usage to s64 before the addition so the arithmetic is done in 64-bit. Fixes: 39d3e7584a68 ("rdmacg: Added rdma cgroup controller") Signed-off-by: cuitao Reviewed-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit d4352c0709bfd38c752fccbde7fd72a82ac78f23 Author: Edward Adam Davis Date: Tue Apr 14 14:15:43 2026 +0800 sched/psi: fix race between file release and pressure write [ Upstream commit a5b98009f16d8a5fb4a8ff9a193f5735515c38fa ] A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfs_open_file, which triggers the uaf reported in [1]. Consider the following scenario involving execution on two separate CPUs: CPU0 CPU1 ==== ==== vfs_rmdir() kernfs_iop_rmdir() cgroup_rmdir() cgroup_kn_lock_live() cgroup_destroy_locked() cgroup_addrm_files() cgroup_rm_file() kernfs_remove_by_name() kernfs_remove_by_name_ns() vfs_write() __kernfs_remove() new_sync_write() kernfs_drain() kernfs_fop_write_iter() kernfs_drain_open_files() cgroup_file_write() kernfs_release_file() pressure_write() cgroup_file_release() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards the memory deallocation of of->priv performed within cgroup_file_release(). However, the operations involving of->priv executed within pressure_write() are not entirely covered by the protection of cgroup_mutex. Consequently, if the code in pressure_write(), specifically the section handling the ctx variable executes after cgroup_file_release() has completed, a uaf vulnerability involving of->priv is triggered. Therefore, the issue can be resolved by extending the scope of the cgroup_mutex lock within pressure_write() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroup_file_release() and pressure_write(). And, if an live kn lock can be successfully acquired while executing the pressure write operation, it indicates that the cgroup deletion process has not yet reached its final stage; consequently, the priv pointer within open_file cannot be NULL. Therefore, the operation to retrieve the ctx value must be moved to a point *after* the live kn lock has been successfully acquired. In another situation, specifically after entering cgroup_kn_lock_live() but before acquiring cgroup_mutex, there exists a different class of race condition: CPU0: write memory.pressure CPU1: write cgroup.pressure=0 =========================== ============================= kernfs_fop_write_iter() kernfs_get_active_of(of) pressure_write() cgroup_kn_lock_live(memory.pressure) cgroup_tryget(cgrp) kernfs_break_active_protection(kn) ... blocks on cgroup_mutex cgroup_pressure_write() cgroup_kn_lock_live(cgroup.pressure) cgroup_file_show(memory.pressure, false) kernfs_show(false) kernfs_drain_open_files() cgroup_file_release(of) kfree(ctx) of->priv = NULL cgroup_kn_unlock() ... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereference Consequently, there is a possibility that of->priv is NULL, the pressure write needs to check for this. Now that the scope of the cgroup_mutex has been expanded, the original explicit cgroup_get/put operations are no longer necessary, this is because acquiring/releasing the live kn lock inherently executes a cgroup get/put operation. [1] BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace: pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:4311 kernfs_fop_write_iter+0x3b0/0x540 fs/kernfs/file.c:352 Allocated by task 9352: cgroup_file_open+0x90/0x3a0 kernel/cgroup/cgroup.c:4256 kernfs_fop_open+0x9eb/0xcb0 fs/kernfs/file.c:724 do_dentry_open+0x83d/0x13e0 fs/open.c:949 Freed by task 9353: cgroup_file_release+0xd6/0x100 kernel/cgroup/cgroup.c:4283 kernfs_release_file fs/kernfs/file.c:764 [inline] kernfs_drain_open_files+0x392/0x720 fs/kernfs/file.c:834 kernfs_drain+0x470/0x600 fs/kernfs/dir.c:525 Fixes: 0e94682b73bf ("psi: introduce psi monitor") Reported-by: syzbot+33e571025d88efd1312c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=33e571025d88efd1312c Tested-by: syzbot+33e571025d88efd1312c@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Reviewed-by: Chen Ridong Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 02beb178e2e159daeb8f992d7abb16a37da31664 Author: Wolfram Sang Date: Fri Apr 10 14:53:00 2026 +0200 mailbox: mailbox-test: free channels on probe error [ Upstream commit c02053a9055d5fdfd32432287cca8958db1d5bc5 ] On probe error, free the previously obtained channels. This not only prevents a leak, but also UAF scenarios because the client structure will be removed nonetheless because it was allocated with devm. Link: https://sashiko.dev/#/patchset/20260327151217.5327-2-wsa%2Brenesas%40sang-engineering.com Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Wolfram Sang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 2c93efe747a8f40f71f8198f271ca8c093c00e27 Author: Jason-JH Lin Date: Mon Mar 23 17:07:11 2026 +0800 mailbox: mtk-cmdq: Fix CURR and END addr for task insert case [ Upstream commit d2591db9c8ef19fbb4d24ed15e0c6edfa6bc7917 ] Fix CURR and END address calculation for inserting a cmdq task into the task list by using cmdq_reg_shift_addr() for proper address converting. This ensures both CURR and END addresses are set correctly when enabling the thread. Fixes: a195c7ccfb7a ("mailbox: mtk-cmdq: Refine DMA address handling for the command buffer") Signed-off-by: Jason-JH Lin Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 80fd7b8052c4e6a5a0e3caed01ecf0db5c39aa50 Author: Felix Gu Date: Thu Feb 26 00:33:24 2026 +0800 mailbox: mtk-vcp-mailbox: Fix the return value in mtk_vcp_mbox_xlate() [ Upstream commit 1e0ec9719f58d53da61adf830e81f4af892e4582 ] The return value of mtk_vcp_mbox_xlate() is checked by IS_ERR(), so return NULL is incorrect and could lead to a NULL pointer dereference. Fixes: b562abd95672 ("mailbox: mediatek: Add mtk-vcp-mailbox driver") Signed-off-by: Felix Gu Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit bed3efea0dc9ccda699a8c12564b828dbc5f3e4f Author: Thomas Weißschuh Date: Wed Apr 22 17:10:27 2026 +0200 kbuild: Never respect CONFIG_WERROR / W=e to fixdep [ Upstream commit 75f7c47ccd78c947cf1b6ddb18ea453ff0555716 ] The fixdep hostprog may be built multiple times during a single build. Once during the configuration phase and later during the regular phase. As only the regular build phase respects CONFIG_WERROR / W=e, the compiler flags might change between the phases, leading to rebuilds. Example, the rebuilds will happen twice on each invocation of the build: $ make allyesconfig prepare make[1]: Entering directory '/tmp/deleteme' HOSTCC scripts/basic/fixdep # # No change to .config # HOSTCC scripts/basic/fixdep DESCEND objtool INSTALL libsubcmd_headers make[1]: Leaving directory '/tmp/deleteme' Fix the compilation flags used for scripts/basic/ before scripts/Makefile.warn is evaluated to stop CONFIG_WERROR / W=e influencing the fixdep build to avoid the spurious rebuilds. Fixes: 7ded7d37e5f5 ("scripts/Makefile.extrawarn: Respect CONFIG_WERROR / W=e for hostprogs") Signed-off-by: Thomas Weißschuh Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260422-kbuild-scripts-basic-werror-v1-1-8c6912ff22e0@weissschuh.net Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit e5ff5338a2bffad73eb9d393a94f8af0df496468 Author: Len Brown Date: Tue Apr 21 18:35:15 2026 -0400 tools/power turbostat: Fix --cpu-set 1 regression on HT systems [ Upstream commit 08e11edd0e63b72651ed5eb9142430d1ca764923 ] When the "--cpu-set" option limits turbostat to run on a higher numbered HT sibling, it exits upon dividing by zero. This is because the HT support handles higher numbered siblings at the same time as lower numbered siblings. But when that lower number sibling is dis-allowed, the higher numbered sibling is never processed. The result is a time delta of 0, which results in a divide by 0 for any of the "per-second" metrics. Enhance the HT enumeration code to record all siblings (up to SMT4). Consult this complete HT sibling list to determine when to process an HT sibling, and when to skip it. Fixes: a2b4d0f8bf07 ("tools/power turbostat: Favor cpu# over core#") Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 16317d01ecffbba39dd1c3d53fc61189e4d7919e Author: Len Brown Date: Thu Apr 16 16:17:31 2026 -0400 tools/power turbostat: Fix --cpu-set 0 regression on HT systems [ Upstream commit 2c52f942fcf21c8e09c7dac669fca591cec2692b ] "turbostat --cpu-set 0" appears to hang if cpu0 has an HT sibling. This is because the initialization code recognizes that it does not have to open perf files for the HT sibling, but the HT support in the collection code sees the HT sibling and tries to read from an uninitialized file descriptor, 0 (standard input). Access HT siblings only when they are in the allowed set. Fixes: a2b4d0f8bf07 ("tools/power turbostat: Favor cpu# over core#") Signed-off-by: Len Brown Reported-by: Artem Bityutskiy Signed-off-by: Sasha Levin commit f68be0fb0eaa27a6cb544e62f522466b5bb1e0d8 Author: David Arcari Date: Tue Apr 21 10:32:17 2026 -0400 tools/power turbostat: Fix unrecognized option '-P' [ Upstream commit ce012c966b518c53475ba9a4e979242d7322d819 ] The '-P' short option (shorthand for --no-perf) is not present in the optstring of the second call to getopt_long_only(). This results in the "unrecognized option" error when the tool reaches the main parsing loop. Add 'P' to the second getopt_long_only() call to ensure it is consistently recognized. Fixes: a0e86c90b83c ("tools/power turbostat: Add --no-perf option") Signed-off-by: David Arcari Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit f56533df50451d2badf859410413f2f4ae9d6a65 Author: Yuho Choi Date: Sun Apr 19 21:01:18 2026 -0400 fbdev: offb: fix PCI device reference leak on probe failure [ Upstream commit 869b93ba04088713596e68453c1146f52f713290 ] offb_init_nodriver() gets a referenced PCI device with pci_get_device(). If pci_enable_device() fails, the function returns without dropping that reference. Release the PCI device reference before returning from the pci_enable_device() failure path. Fixes: 5bda8f7b5468 ("video: fbdev: offb: Call pci_enable_device() before using the PCI VGA device") Co-developed-by: Myeonghun Pak Signed-off-by: Myeonghun Pak Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Co-developed-by: Taegyu Kim Signed-off-by: Taegyu Kim Signed-off-by: Yuho Choi Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 49047916b1823fdb3bbfd31c882266d1ae4c9f3f Author: Len Brown Date: Tue Apr 21 17:26:33 2026 -0400 tools/power turbostat: Fix AMD RAPL regression on big systems [ Upstream commit 3ae6bafa104d93ddc525b8de547bf66b43fcaf10 ] turbostat.c:8688: rapl_perf_init: Assertion `next_domain < num_domains' failed. The initial fix for this regression was incomplete, as it did not handle multi-package systems with sparse core ids. Fixes: ef0e60083f76 ("tools/power turbostat: Fix AMD RAPL regression") Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 2067846d72490fa0d95f9ea1153403638818b4be Author: Mathias Krause Date: Thu Apr 2 16:51:16 2026 +0200 kbuild: builddeb - avoid recompiles for non-cross-compiles [ Upstream commit 2452dcf4d740effff5aa71b7f6529ee8c04fd8f6 ] Commit e2c318225ac1 ("kbuild: deb-pkg: add pkg.linux-upstream.nokernelheaders build profile") changed how install-extmod-build gets called, making it always rebuild the host programs below scripts/ if HOSTCC wasn't specified with its full triplet on the make command line. That is, apparently, needed to fix up commit f1d87664b82a ("kbuild: cross-compile linux-headers package when possible") for cross-compiles. However, in the much more common case of non-cross-compile builds this will lead to unnecessary rebuilding of host tools including gcc plugins. This, in turn, will lead to a full kernel rebuild on the next 'make bindeb-pkg' which is unfortunate. Avoid that by only triggering the rebuild of host tools for actual cross-compile builds. Signed-off-by: Mathias Krause Fixes: e2c318225ac1 ("kbuild: deb-pkg: add pkg.linux-upstream.nokernelheaders build profile") Cc: Masahiro Yamada Reviewed-by: Nathan Chancellor Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260402145116.1010901-1-minipli@grsecurity.net Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 4f41887159840a9d5a5187410546b930655c6dfd Author: Anthony Pighin (Nokia) Date: Tue Nov 25 18:00:10 2025 +0000 rtc: abx80x: Disable alarm feature if no interrupt attached [ Upstream commit 0fedce7244e4b85c049ce579c87e298a1b0b811d ] Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm") exposed an issue where the rtc-abx80x driver does not clear the alarm feature bit, but instead relies on the set_alarm operation to return invalid. For example, when a RTC_UIE_ON ioctl is handled, it should abort at the feature validation. Instead, it proceeds to the rtc_timer_enqueue(), which used to return an error from the set_alarm call. However, following the race condition handling, which likely should not be discarding predecing errors, a success condition is returned to the ioctl() caller. This results in (for example): hwclock: select() to /dev/rtc0 to wait for clock tick timed out Notwithstanding the validity of the race condition handling, if an interrupt wasn't specified, or could not be attached, the driver should clear the alarm feature bit. Fixes: 718a820a303c ("rtc: abx80x: add alarm support") Signed-off-by: Anthony Pighin Link: https://patch.msgid.link/BN0PR08MB69510928028C933749F4139383D1A@BN0PR08MB6951.namprd08.prod.outlook.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 60d82592ac8b5637fbed871381eb0a16df0a492e Author: Bae Yeonju Date: Sat Mar 21 13:45:02 2026 +0900 fs/adfs: validate nzones in adfs_validate_bblk() [ Upstream commit dd9d3e16c2d5fa166e13dce07413be51f42c8f5d ] Reject ADFS disc records with a zero zone count during boot block validation, before the disc record is used. When nzones is 0, adfs_read_map() passes it to kmalloc_array(0, ...) which returns ZERO_SIZE_PTR, and adfs_map_layout() then writes to dm[-1], causing an out-of-bounds write before the allocated buffer. adfs_validate_dr0() already rejects nzones != 1 for old-format images. Add the equivalent check to adfs_validate_bblk() for new-format images so that a crafted image with nzones == 0 is rejected at probe time. Found by syzkaller. Fixes: f6f14a0d71b0 ("fs/adfs: map: move map-specific sb initialisation to map.c") Signed-off-by: Bae Yeonju Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit ced39b6a8062bac5c18a1c3df85634107eb8664a Author: Christian Brauner Date: Thu Apr 23 11:56:09 2026 +0200 eventpoll: fix ep_remove struct eventpoll / struct file UAF [ Upstream commit a6dc643c69311677c574a0f17a3f4d66a5f3744b ] ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays. Fixes: 58c9b016e128 ("epoll: use refcount to reduce ep_mutex contention") Reported-by: Jaeyoung Chung Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-6-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 42f0bd64c928852c01e8dfa6385003992fd89fb1 Author: Christian Brauner Date: Thu Apr 23 11:56:08 2026 +0200 eventpoll: move epi_fget() up [ Upstream commit 86e87059e6d1fd5115a31949726450ed03c1073b ] We'll need it when removing files so move it up. No functional change. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-5-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: a6dc643c6931 ("eventpoll: fix ep_remove struct eventpoll / struct file UAF") Signed-off-by: Sasha Levin commit 530d62d78b0760956daee420d6731bf49c658a53 Author: Christian Brauner Date: Fri Apr 24 00:23:18 2026 +0200 eventpoll: drop vestigial __ prefix from ep_remove_{file,epi}() [ Upstream commit 0feaf644f7180c4a91b6b405a881afbfd958f1cf ] With __ep_remove() gone, the double-underscore on __ep_remove_file() and __ep_remove_epi() no longer contrasts with a __-less parent and just reads as noise. Rename both to ep_remove_file() and ep_remove_epi(). No functional change. Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: a6dc643c6931 ("eventpoll: fix ep_remove struct eventpoll / struct file UAF") Signed-off-by: Sasha Levin commit 45855b9cbd1b7fb505d1f123c11aea78b68f7112 Author: Christian Brauner Date: Thu Apr 23 11:56:06 2026 +0200 eventpoll: kill __ep_remove() [ Upstream commit e9e5cd40d7c403e19f21d0f7b8b8ba3a76b58330 ] Remove the boolean conditional in __ep_remove() and restructure the code so the check for racing with eventpoll_release_file() are only done in the ep_remove_safe() path where they belong. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-3-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: a6dc643c6931 ("eventpoll: fix ep_remove struct eventpoll / struct file UAF") Signed-off-by: Sasha Levin commit 6045e4173a616602b9b25a78e999e6ffdfee8ba8 Author: Christian Brauner Date: Thu Apr 23 11:56:05 2026 +0200 eventpoll: split __ep_remove() [ Upstream commit 0f7bdfd413000985de09fc39eb9efa1e091a3ce0 ] Split __ep_remove() to delineate file removal from epoll item removal. Suggested-by: Linus Torvalds Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-2-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: a6dc643c6931 ("eventpoll: fix ep_remove struct eventpoll / struct file UAF") Signed-off-by: Sasha Levin commit 0229c2f262891512e74323322007716ddeb353f1 Author: Christian Brauner Date: Thu Apr 23 11:56:04 2026 +0200 eventpoll: use hlist_is_singular_node() in __ep_remove() [ Upstream commit 3d9fd0abc94d8cd430cc7cd7d37ce5e5aae2cd2b ] Replace the open-coded "epi is the only entry in file->f_ep" check with hlist_is_singular_node(). Same semantics, and the helper avoids the head-cacheline access in the common false case. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-1-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: a6dc643c6931 ("eventpoll: fix ep_remove struct eventpoll / struct file UAF") Signed-off-by: Sasha Levin commit a644204f3c8327044cb9fb7ece53e76eda66c44b Author: Randy Dunlap Date: Thu Apr 16 14:54:29 2026 -0700 nstree: fix func. parameter kernel-doc warnings [ Upstream commit 43eb354ecb471426e97b0ce6a0c922ec20f82027 ] Use the correct parameter name ("__ns") for function parameter kernel-doc to avoid 3 warnings: Warning: include/linux/nstree.h:68 function parameter '__ns' not described in 'ns_tree_add_raw' Warning: include/linux/nstree.h:77 function parameter '__ns' not described in 'ns_tree_add' Warning: include/linux/nstree.h:88 function parameter '__ns' not described in 'ns_tree_remove' Fixes: 885fc8ac0a4d ("nstree: make iterator generic") Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260416215429.948898-1-rdunlap@infradead.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit e6c3df7fbed2f52216092663a8f5c2cf7512ce3f Author: Kohei Enju Date: Wed Apr 22 02:30:24 2026 +0000 vhost_net: fix sleeping with preempt-disabled in vhost_net_busy_poll() [ Upstream commit e08a9fac5cf8c3fecf4755e7e3ac059f78b8f83d ] syzbot reported "sleeping function called from invalid context" in vhost_net_busy_poll(). Commit 030881372460 ("vhost_net: basic polling support") introduced a busy-poll loop and preempt_{disable,enable}() around it, where each iteration calls a sleepable function inside the loop. The purpose of disabling preemption was to keep local_clock()-based timeout accounting on a single CPU, rather than as a requirement of busy-poll itself: https://lore.kernel.org/1448435489-5949-4-git-send-email-jasowang@redhat.com From this perspective, migrate_disable() is sufficient here, so replace preempt_disable() with migrate_disable(), avoiding sleepable accesses from a preempt-disabled context. Fixes: 030881372460 ("vhost_net: basic polling support") Tested-by: syzbot+6985cb8e543ea90ba8ee@syzkaller.appspotmail.com Reported-by: syzbot+6985cb8e543ea90ba8ee@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e6a414.050a0220.24bfd3.002d.GAE@google.com/T/ Signed-off-by: Kohei Enju Acked-by: Michael S. Tsirkin Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 29940fff14110ca48c5ccc168d121665b51bb778 Author: Lee Jones Date: Tue Apr 21 13:45:26 2026 +0100 tipc: fix double-free in tipc_buf_append() [ Upstream commit d293ca716e7d5dffdaecaf6b9b2f857a33dc3d3a ] tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations. Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb truesize and contents") Suggested-by: Tung Nguyen Signed-off-by: Lee Jones Reviewed-by: Tung Nguyen Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 09d5b5d704d5e25b1dfac1677f49d6f2835bfac2 Author: Jiayuan Chen Date: Wed Apr 22 20:35:38 2026 +0800 tcp: send a challenge ACK on SEG.ACK > SND.NXT [ Upstream commit 42726ec644cbdde0035c3e0417fee8ed9547e120 ] RFC 5961 Section 5.2 validates an incoming segment's ACK value against the range [SND.UNA - MAX.SND.WND, SND.NXT] and states: "All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back." Commit 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation") opted Linux into this mitigation and implements the challenge ACK on the lower side (SEG.ACK < SND.UNA - MAX.SND.WND), but the symmetric upper side (SEG.ACK > SND.NXT) still takes the pre-RFC-5961 path and silently returns SKB_DROP_REASON_TCP_ACK_UNSENT_DATA, even though RFC 793 Section 3.9 (now RFC 9293 Section 3.10.7.4) has always required: "If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return." Complete the mitigation by sending a challenge ACK on that branch, reusing the existing tcp_send_challenge_ack() path which already enforces the per-socket RFC 5961 Section 7 rate limit via __tcp_oow_rate_limited(). FLAG_NO_CHALLENGE_ACK is honoured for symmetry with the lower-edge case. Update the existing tcp_ts_recent_invalid_ack.pkt selftest, which drives this exact path, to consume the new challenge ACK. Fixes: 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation") Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260422123605.320000-2-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 28afecb0b1182cc5c55c2e29abb2d4408362ef9c Author: Alexey Kodanev Date: Wed Apr 22 16:05:36 2026 +0000 nfp: fix swapped arguments in nfp_encode_basic_qdr() calls [ Upstream commit 4078c5611d7585548b249377ebd60c272e410490 ] There is a mismatch between the passed arguments and the actual nfp_encode_basic_qdr() function parameter names: static int nfp_encode_basic_qdr(u64 addr, int dest_island, int cpp_tgt, int mode, bool addr40, int isld1, int isld0) { ... But "dest_island" and "cpp_tgt" are swapped at every call-site. For example: return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island, mode, addr40, isld1, isld0); As a result, nfp_encode_basic_qdr() receives "dest_island" as CPP target type, which is always NFP_CPP_TARGET_QDR(2) for these calls, and "cpp_tgt" as the destination island ID, which can accidentally match or be outside the valid NFP_CPP_TARGET_* types (e.g. '-1' for any destination). Since code already worked for years, also add extra pr_warn() to error paths in nfp_encode_basic_qdr() to help identify any potential address verification failures. Detected using the static analysis tool - Svace. Fixes: 4cb584e0ee7d ("nfp: add CPP access core") Signed-off-by: Alexey Kodanev Link: https://patch.msgid.link/20260422160536.61855-1-aleksei.kodanev@bell-sw.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 93bef3240d92856d8967437f642fb16b4be88735 Author: Brett Creeley Date: Thu Apr 16 14:21:21 2026 -0700 virtio_net: sync rss_trailer.max_tx_vq on queue_pairs change via VQ_PAIRS_SET [ Upstream commit 3bc06da858ef17cfe94b49efc0d9713727012835 ] When netif_is_rxfh_configured() is true (i.e., the user has explicitly configured the RSS indirection table), virtnet_set_queues() skips the RSS update path and falls through to the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command to change the number of queue pairs. However, it does not update vi->rss_trailer.max_tx_vq to reflect the new queue_pairs value. This causes a mismatch between vi->curr_queue_pairs and vi->rss_trailer.max_tx_vq. Any subsequent RSS reconfiguration (e.g., via ethtool -X) calls virtnet_commit_rss_command(), which sends the stale max_tx_vq to the device, silently reverting the queue count. Reproduction: 1. User configured RSS ethtool -X eth0 equal 8 2. VQ_PAIRS_SET path; max_tx_vq stays 16 ethtool -L eth0 combined 12 3. RSS commit uses max_tx_vq=16 instead of 12 ethtool -X eth0 equal 4 Fix this by updating vi->rss_trailer.max_tx_vq after a successful VQ_PAIRS_SET command when RSS is enabled, keeping it in sync with curr_queue_pairs. Fixes: 50bfcaedd78e ("virtio_net: Update rss when set queue") Signed-off-by: Brett Creeley Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260416212121.29073-1-brett.creeley@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d0117950075f0a9d5944980784c719d8ebcd4bff Author: Stefano Garzarella Date: Mon Apr 20 15:20:51 2026 +0200 vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting [ Upstream commit 1cb36e252211506f51095fe7ced8286cc77b4c80 ] virtio_transport_init_zcopy_skb() uses iter->count as the size argument for msg_zerocopy_realloc(), which in turn passes it to mm_account_pinned_pages() for RLIMIT_MEMLOCK accounting. However, this function is called after virtio_transport_fill_skb() has already consumed the iterator via __zerocopy_sg_from_iter(), so on the last skb, iter->count will be 0, skipping the RLIMIT_MEMLOCK enforcement. Pass pkt_len (the total bytes being sent) as an explicit parameter to virtio_transport_init_zcopy_skb() instead of reading the already-consumed iter->count. This matches TCP and UDP, which both call msg_zerocopy_realloc() with the original message size. Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support") Reported-by: Yiming Qian Signed-off-by: Stefano Garzarella Reviewed-by: Bobby Eshleman Link: https://patch.msgid.link/20260420132051.217589-1-sgarzare@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2355598a046fdd6adde02b55b6e8fc8f0a97621e Author: Erni Sri Satya Vennela Date: Mon Apr 20 05:47:39 2026 -0700 net: mana: Fix EQ leak in mana_remove on NULL port [ Upstream commit 65267c9c4f28199985505977bc2c628c82fc50ef ] In mana_remove(), when a NULL port is encountered in the port iteration loop, 'goto out' skips the mana_destroy_eq(ac) call, leaking the event queues allocated earlier by mana_create_eq(). This can happen when mana_probe_port() fails for port 0, leaving ac->ports[0] as NULL. On driver unload or error cleanup, mana_remove() hits the NULL entry and jumps past mana_destroy_eq(). Change 'goto out' to 'break' so the for-loop exits normally and mana_destroy_eq() is always reached. Remove the now-unreferenced out: label. Fixes: 1e2d0824a9c3 ("net: mana: Add support for EQ sharing") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-6-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6546c9e7b00bd584ac9d9b3f2afc741b5dc1f0ac Author: Erni Sri Satya Vennela Date: Mon Apr 20 05:47:38 2026 -0700 net: mana: Don't overwrite port probe error with add_adev result [ Upstream commit a7fdaf069bd031fcc234581fa6a580be11bf2175 ] In mana_probe(), if mana_probe_port() fails for any port, the error is stored in 'err' and the loop breaks. However, the subsequent unconditional 'err = add_adev(gd, "eth")' overwrites this error. If add_adev() succeeds, mana_probe() returns success despite ports being left in a partially initialized state (ac->ports[i] == NULL). Only call add_adev() when there is no prior error, so the probe correctly fails and triggers mana_remove() cleanup. Fixes: a69839d4327d ("net: mana: Add support for auxiliary device") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-5-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bbe5c3c570645a4ceb120979d3ee203a1583d775 Author: Erni Sri Satya Vennela Date: Mon Apr 20 05:47:37 2026 -0700 net: mana: Guard mana_remove against double invocation [ Upstream commit 50271d7ec95144d26808025b508f463780517d3c ] If PM resume fails (e.g., mana_attach() returns an error), mana_probe() calls mana_remove(), which tears down the device and sets gd->gdma_context = NULL and gd->driver_data = NULL. However, a failed resume callback does not automatically unbind the driver. When the device is eventually unbound, mana_remove() is invoked a second time. Without a NULL check, it dereferences gc->dev with gc == NULL, causing a kernel panic. Add an early return if gdma_context or driver_data is NULL so the second invocation is harmless. Move the dev = gc->dev assignment after the guard so it cannot dereference NULL. Fixes: 635096a86edb ("net: mana: Support hibernation and kexec") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-4-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c1318d76e104fae84dd3a7b927950829db9a645b Author: Erni Sri Satya Vennela Date: Mon Apr 20 05:47:36 2026 -0700 net: mana: Init gf_stats_work before potential error paths in probe [ Upstream commit 6e8bc03349fe4f09567fa76235abf52bdaf83082 ] Move INIT_DELAYED_WORK(gf_stats_work) to before mana_create_eq(), while keeping schedule_delayed_work() at its original location. Previously, if any function between mana_create_eq() and the INIT_DELAYED_WORK call failed, mana_probe() would call mana_remove() which unconditionally calls cancel_delayed_work_sync(gf_stats_work) in __flush_work() or debug object warnings with CONFIG_DEBUG_OBJECTS_WORK enabled. Fixes: be4f1d67ec56 ("net: mana: Add standard counter rx_missed_errors") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-3-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6012df2019d02599f0f2c2269b5c21b2720d5198 Author: Erni Sri Satya Vennela Date: Mon Apr 20 05:47:35 2026 -0700 net: mana: Init link_change_work before potential error paths in probe [ Upstream commit cb4a90744bcd1adf12f0d0c7c4f0dd2647444ec5 ] Move INIT_WORK(link_change_work) to right after the mana_context allocation, before any error path that could reach mana_remove(). Previously, if mana_create_eq() or mana_query_device_cfg() failed, mana_probe() would jump to the error path which calls mana_remove(). mana_remove() unconditionally calls disable_work_sync(link_change_work), but the work struct had not been initialized yet. This can trigger CONFIG_DEBUG_OBJECTS_WORK enabled. Fixes: 54133f9b4b53 ("net: mana: Support HW link state events") Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260420124741.1056179-2-ernis@linux.microsoft.com Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fc38600b45abbfa08143564540bca38e63099a8f Author: Lorenzo Bianconi Date: Mon Apr 20 10:07:48 2026 +0200 net: airoha: Add size check for TX NAPIs in airoha_qdma_cleanup() [ Upstream commit 4b91cb65789b794bfc8d50554b8994f8e0f16309 ] If airoha_qdma_init routine fails before airoha_qdma_tx_irq_init() runs successfully for all TX NAPIs, airoha_qdma_cleanup() will unconditionally runs netif_napi_del() on TX NAPIs, triggering a NULL pointer dereference. Fix the issue relying on q_tx_irq size value to check if the TX NAPIs is properly initialized in airoha_qdma_cleanup(). Moreover, run netif_napi_add_tx() just if irq_q queue is properly allocated. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260420-airoha_qdma_init_rx_queue-fix-v2-2-d99347e5c18d@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit dcec9be39cfcc5230c842428ea41d1430f964d6c Author: Lorenzo Bianconi Date: Sat Mar 21 15:41:44 2026 +0100 net: airoha: Rework the code flow in airoha_remove() and in airoha_probe() error path [ Upstream commit b1c803d5c8167026791abfaed96fd3e6a1fcd750 ] As suggested by Simon in [0], rework the code flow in airoha_remove() and in the airoha_probe() error path in order to rely on a more common approach un-registering configured net-devices first and destroying the hw resources at the end of the code. Introduce airoha_qdma_cleanup routine to release QDMA resources. [0] https://lore.kernel.org/netdev/20251214-airoha-fix-dev-registration-v1-1-860e027ad4c6@kernel.org/ Suggested-by: Simon Horman Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260321-airoha-remove-rework-v2-1-16c7bade5fe5@kernel.org Signed-off-by: Paolo Abeni Stable-dep-of: 4b91cb65789b ("net: airoha: Add size check for TX NAPIs in airoha_qdma_cleanup()") Signed-off-by: Sasha Levin commit 14dc48e5ba73d5c69559bf1a1a6884f7843aade7 Author: Lorenzo Bianconi Date: Mon Apr 20 10:07:47 2026 +0200 net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue() [ Upstream commit 379050947a1828826ad7ea50c95245a56929b35a ] If queue entry or DMA descriptor list allocation fails in airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a NULL pointer dereference running netif_napi_del() for RX queue NAPIs since netif_napi_add() has never been executed to this particular RX NAPI. The issue is due to the early ndesc initialization in airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc value to check if the queue is properly initialized. Fix the issue moving ndesc initialization at end of airoha_qdma_init_tx routine. Move page_pool allocation after descriptor list allocation in order to avoid memory leaks if desc allocation fails. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260420-airoha_qdma_init_rx_queue-fix-v2-1-d99347e5c18d@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c7575306c03dc5de7b00151f26744ef39b6a5a47 Author: Mieczyslaw Nalewaj Date: Sun Apr 19 21:37:07 2026 +0200 net: dsa: realtek: rtl8365mb: fix mode mask calculation [ Upstream commit 0c078021d3861966614d5e594ee03587f0c9e74d ] The RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK macro was shifting the 4-bit mask (0xF) by only (_extint % 2) bits instead of (_extint % 2) * 4. This caused the mask to overlap with the adjacent nibble when configuring odd-numbered external interfaces, selecting the wrong bits entirely. Align the shift calculation with the existing ...MODE_OFFSET macro. Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC") Signed-off-by: Abdulkader Alrezej Signed-off-by: Mieczyslaw Nalewaj Reviewed-by: Luiz Angelo Daros de Luca Link: https://patch.msgid.link/400a6387-a444-4576-af6d-26be5410bce3@yahoo.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9b5d56fe389d68ede080c716e6f10895facaf7db Author: Lorenzo Bianconi Date: Fri Apr 17 08:36:32 2026 +0200 net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue() [ Upstream commit 3309965fe44c00fd65af7cef5016e9e782c021a7 ] Similar to airoha_qdma_cleanup_rx_queue(), reset DMA TX descriptors in airoha_qdma_cleanup_tx_queue routine. Moreover, reset TX_DMA_IDX to TX_CPU_IDX to notify the NIC the QDMA TX ring is empty. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-2-e04bcc2c9642@kernel.org Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ece31f9dae0c3cd3277e66667e7b8ab2577cf34a Author: Lorenzo Bianconi Date: Fri Apr 17 08:36:31 2026 +0200 net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx() [ Upstream commit f329924bb49458c65297f1361f545816a5b90998 ] If queue entry list allocation fails in airoha_qdma_init_tx_queue routine, airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference accessing the queue entry array. The issue is due to the early ndesc initialization in airoha_qdma_init_tx_queue(). Fix the issue moving ndesc initialization at end of airoha_qdma_init_tx routine. Fixes: 3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order DMA tx descriptors") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-1-e04bcc2c9642@kernel.org Reviewed-by: Simon Horman Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 579d1e17a34b4b36528452f81b2cb8d205fb792c Author: Eric Dumazet Date: Tue Apr 21 14:16:55 2026 +0000 net/sched: sch_sfb: annotate data-races in sfb_dump_stats() [ Upstream commit 1ada03fdef82d3d7d2edb9dcd3acc91917675e48 ] sfb_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Alternative would be to acquire the qdisc spinlock, but our long-term goal is to make qdisc dump operations lockless as much as we can. tc_sfb_xstats fields don't need to be latched atomically, otherwise this bug would have been caught earlier. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260421141655.3953721-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 137723fba7b19eb30db766b643be17724d1a325b Author: Eric Dumazet Date: Tue Apr 21 14:23:09 2026 +0000 net/sched: sch_red: annotate data-races in red_dump_stats() [ Upstream commit a8f5192809caf636d05ba47c144f282cfd0e3839 ] red_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Alternative would be to acquire the qdisc spinlock, but our long-term goal is to make qdisc dump operations lockless as much as we can. tc_red_xstats fields don't need to be latched atomically, otherwise this bug would have been caught earlier. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421142309.3964322-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3bad26188b6d997bd0e2a76edccbda77343c34e6 Author: Eric Dumazet Date: Tue Apr 21 14:25:09 2026 +0000 net/sched: sch_fq_codel: remove data-races from fq_codel_dump_stats() [ Upstream commit bbfaa73ea6871db03dc05d7f05f00557a8981f25 ] fq_codel_dump_stats() acquires the qdisc spinlock a bit too late. Move this acquisition before we fill st.qdisc_stats with live data. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421142509.3967231-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit baa896c01867cb96ea35b2d8ea78a11b60176919 Author: Eric Dumazet Date: Tue Apr 21 14:29:44 2026 +0000 net/sched: sch_pie: annotate data-races in pie_dump_stats() [ Upstream commit 5154561d9b119f781249f8e845fecf059b38b483 ] pie_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Alternative would be to acquire the qdisc spinlock, but our long-term goal is to make qdisc dump operations lockless as much as we can. tc_pie_xstats fields don't need to be latched atomically, otherwise this bug would have been caught earlier. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421142944.4009941-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fc0f98c66fd75af0f9ff62703b2211cf6107e125 Author: Eric Dumazet Date: Tue Apr 21 14:33:49 2026 +0000 net_sched: sch_hhf: annotate data-races in hhf_dump_stats() [ Upstream commit a6edf2cd4156b71e07258876b7626692e158f7e8 ] hhf_dump_stats() only runs with RTNL held, reading fields that can be changed in qdisc fast path. Add READ_ONCE()/WRITE_ONCE() annotations. Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump") Signed-off-by: Eric Dumazet Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260421143349.4052215-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 027b10c087d42d40d06a19afea73a6f8bb2faf1f Author: Jacob Keller Date: Mon Apr 20 17:51:28 2026 -0700 ice: fix ice_ptp_read_tx_hwtstamp_status_eth56g [ Upstream commit 1f75dbc53f68f0fb2acd99f92315e426a3d0b446 ] The ice_ptp_read_tx_hwtstamp_status_eth56g function calls ice_read_phy_eth56g with a PHY index. However the function actually expects a port index. This causes the function to read the wrong PHY_PTP_INT_STATUS registers, and effectively makes the status wrong for the second set of ports from 4 to 7. The ice_read_phy_eth56g function uses the provided port index to determine which PHY device to read. We could refactor the entire chain to take a PHY index, but this would impact many code sites. Instead, multiply the PHY index by the number of ports, so that we read from the first port of each PHY. Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Reviewed-by: Aleksandr Loktionov Reviewed-by: Petr Oros Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260420-jk-iwl-net-2026-04-20-ptp-e825c-phy-interrupt-fixes-v1-4-bc2240f42251@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b78b2b353368563678bc0f5f66c68203e2268d67 Author: Jacob Keller Date: Mon Apr 20 17:51:27 2026 -0700 ice: fix ready bitmap check for non-E822 devices [ Upstream commit 359dc1d41358c88955eeff1b75aee55da7a415d3 ] The E800 hardware (apart from E810) has a ready bitmap for the PHY indicating which timestamp slots currently have an outstanding timestamp waiting to be read by software. This bitmap is checked in multiple places using the ice_get_phy_tx_tstamp_ready(): * ice_ptp_process_tx_tstamp() calls it to determine which timestamps to attempt reading from the PHY * ice_ptp_tx_tstamps_pending() calls it in a loop at the end of the miscellaneous IRQ to check if new timestamps came in while the interrupt handler was executing. * ice_ptp_maybe_trigger_tx_interrupt() calls it in the auxiliary work task to trigger a software interrupt in the event that the hardware logic gets stuck. For E82X devices, multiple PHYs share the same block, and the parameter passed to the ready bitmap is a block number associated with the given port. For E825-C devices, the PHYs have their own independent blocks and do not share, so the parameter passed needs to be the port number. For E810 devices, the ice_get_phy_tx_tstamp_ready() always returns all 1s regardless of what port, since this hardware does not have a ready bitmap. Finally, for E830 devices, each PF has its own ready bitmap accessible via register, and the block parameter is unused. The first call correctly uses the Tx timestamp tracker block parameter to check the appropriate timestamp block. This works because the tracker is setup correctly for each timestamp device type. The second two callers behave incorrectly for all device types other than the older E822 devices. They both iterate in a loop using ICE_GET_QUAD_NUM() which is a macro only used by E822 devices. This logic is incorrect for devices other than the E822 devices. For E810 the calls would always return true, causing E810 devices to always attempt to trigger a software interrupt even when they have no reason to. For E830, this results in duplicate work as the ready bitmap is checked once per number of quads. Finally, for E825-C, this results in the pending checks failing to detect timestamps on ports other than the first two. Fix this by introducing a new hardware API function to ice_ptp_hw.c, ice_check_phy_tx_tstamp_ready(). This function will check if any timestamps are available and returns a positive value if any timestamps are pending. For E810, the function always returns false, so that the re-trigger checks never happen. For E830, check the ready bitmap just once. For E82x hardware, check each quad. Finally, for E825-C, check every port. The interface function returns an integer to enable reporting of error code if the driver is unable read the ready bitmap. This enables callers to handle this case properly. The previous implementation assumed that timestamps are available if they failed to read the bitmap. This is problematic as it could lead to continuous software IRQ triggering if the PHY timestamp registers somehow become inaccessible. This change is especially important for E825-C devices, as the missing checks could leave a window open where a new timestamp could arrive while the existing timestamps aren't completed. As a result, the hardware threshold logic would not trigger a new interrupt. Without the check, the timestamp is left unhandled, and new timestamps will not cause an interrupt again until the timestamp is handled. Since both the interrupt check and the backup check in the auxiliary task do not function properly, the device may have Tx timestamps permanently stuck failing on a given port. The faulty checks originate from commit d938a8cca88a ("ice: Auxbus devices & driver for E822 TS") and commit 712e876371f8 ("ice: periodically kick Tx timestamp interrupt"), however at the time of the original coding, both functions only operated on E822 hardware. This is no longer the case, and hasn't been since the introduction of the ETH56G PHY model in commit 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Reviewed-by: Aleksandr Loktionov Reviewed-by: Petr Oros Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260420-jk-iwl-net-2026-04-20-ptp-e825c-phy-interrupt-fixes-v1-3-bc2240f42251@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2991b39f4ec55280d27dad450d178331a1e45c58 Author: Grzegorz Nitka Date: Mon Apr 20 17:51:26 2026 -0700 ice: perform PHY soft reset for E825C ports at initialization [ Upstream commit 3ec46e157c7fa420c77dfc23f7030e61f2f3fd55 ] In some cases the PHY timestamp block of the E825C can become stuck. This is known to occur if the software writes 0 to the Tx timestamp threshold, and with older versions of the ice driver the threshold configuration is buggy and can race in such that hardware briefly operates with a zero threshold enabled. There are no other known ways to trigger this behavior, but once it occurs, the hardware is not recovered by normal reset, a driver reload, or even a warm power cycle of the system. A cold power cycle is sufficient to recover hardware, but this is extremely invasive and can result in significant downtime on customer deployments. The PHY for each port has a timestamping block which has its own reset functionality accessible by programming the PHY_REG_GLOBAL register. Writing to the PHY_REG_GLOBAL_SOFT_RESET_BIT triggers the hardware to perform a complete reset of the timestamping block of the PHY. This includes clearing the timestamp status for the port, clearing all outstanding timestamps in the memory bank, and resetting the PHY timer. The new ice_ptp_phy_soft_reset_eth56g() function toggles the PHY_REG_GLOBAL soft reset bit with the required delays, ensuring the PHY is properly reinitialized without requiring a full device reset. The sequence clears the reset bit, asserts it, then clears it again, with short waits between transitions to allow hardware stabilization. Call this function in the new ice_ptp_init_phc_e825c(), implementing the E825C device specific variant of the ice_ptp_init_phc(). Note that if ice_ptp_init_phc() fails, PTP functionality may be disabled, but the driver will still load to allow basic functionality to continue. This causes the clock owning PF driver to perform a PHY soft reset for every port during initialization. This ensures the driver begins life in a known functional state regardless of how it was previously programmed. This ensures that we properly reconfigure the hardware after a device reset or when loading the driver, even if it was previously misconfigured with an out-of-date or modified driver. Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Signed-off-by: Timothy Miskell Signed-off-by: Grzegorz Nitka Reviewed-by: Aleksandr Loktionov Reviewed-by: Petr Oros Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260420-jk-iwl-net-2026-04-20-ptp-e825c-phy-interrupt-fixes-v1-2-bc2240f42251@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ac47d41a64dd635c5b3efe5a59d9896b13479a2e Author: Grzegorz Nitka Date: Mon Apr 20 17:51:25 2026 -0700 ice: fix timestamp interrupt configuration for E825C [ Upstream commit c0a575a801a2040eb1e0db54b488f8c548c8458a ] The E825C ice_phy_cfg_intr_eth56g() function is responsible for programming the PHY interrupt for a given port. This function writes to the PHY_REG_TS_INT_CONFIG register of the port. The register is responsible for configuring whether the port interrupt logic is enabled, as well as programming the threshold of waiting timestamps that will trigger an interrupt from this port. This threshold value must not be programmed to zero while the interrupt is enabled. Doing so puts the port in a misconfigured state where the PHY timestamp interrupt for the quad of connected ports will become stuck. This occurs, because a threshold of zero results in the timestamp interrupt status for the port becoming stuck high. The four ports in the connected quad have their timestamp status indicators muxed together. A new interrupt cannot be generated until the timestamp status indicators return low for all four ports. Normally, the timestamp status for a port will clear once there are fewer timestamps in that ports timestamp memory bank than the threshold. A threshold of zero makes this impossible, so the timestamp status for the port does not clear. The ice driver never intentionally programs the threshold to zero, indeed the driver always programs it to a value of 1, intending to get an interrupt immediately as soon as even a single packet is waiting for a timestamp. However, there is a subtle flaw in the programming logic in the ice_phy_cfg_intr_eth56g() function. Due to the way that the hardware handles enabling the PHY interrupt. If the threshold value is modified at the same time as the interrupt is enabled, the HW PHY state machine might enable the interrupt before the new threshold value is actually updated. This leaves a potential race condition caused by the hardware logic where a PHY timestamp interrupt might be triggered before the non-zero threshold is written, resulting in the PHY timestamp logic becoming stuck. Once the PHY timestamp status is stuck high, it will remain stuck even after attempting to reprogram the PHY block by changing its threshold or disabling the interrupt. Even a typical PF or CORE reset will not reset the particular block of the PHY that becomes stuck. Even a warm power cycle is not guaranteed to cause the PHY block to reset, and a cold power cycle is required. Prevent this by always writing the PHY_REG_TS_INT_CONFIG in two stages. First write the threshold value with the interrupt disabled, and only write the enable bit after the threshold has been programmed. When disabling the interrupt, leave the threshold unchanged. Additionally, re-read the register after writing it to guarantee that the write to the PHY has been flushed upon exit of the function. While we're modifying this function implementation, explicitly reject programming a threshold of 0 when enabling the interrupt. No caller does this today, but the consequences of doing so are significant. An explicit rejection in the code makes this clear. Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Signed-off-by: Grzegorz Nitka Reviewed-by: Aleksandr Loktionov Reviewed-by: Petr Oros Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260420-jk-iwl-net-2026-04-20-ptp-e825c-phy-interrupt-fixes-v1-1-bc2240f42251@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 912ba2e5704fdb8bc5decda96dfc1a57838f0099 Author: Michael Bommarito Date: Sat Apr 18 10:10:47 2026 -0400 net/rds: zero per-item info buffer before handing it to visitors [ Upstream commit c88eb7e8d8397a8c1db59c425332c5a30b2a1682 ] rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back to user space via rds_info_copy() regardless of how much of the buffer the visitor actually wrote. rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only write a subset of their output struct when the underlying rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl and the two GIDs via explicit memsets). Several u32 fields (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size, cache_allocs) and the 2-byte alignment hole between sl and cache_allocs remain as whatever stack contents preceded the visitor call and are then memcpy_to_user()'d out to user space. struct rds_info_rdma_connection and struct rds6_info_rdma_connection are the only rds_info_* structs in include/uapi/linux/rds.h that are not marked __attribute__((packed)), so they have a real alignment hole. The other info visitors (rds_conn_info_visitor, rds6_conn_info_visitor, rds_tcp_tc_info, ...) write all fields of their packed output struct today and are not known to be vulnerable, but a future visitor that adds a conditional write-path would have the same bug. Reproduction on a kernel built without CONFIG_INIT_STACK_ALL_ZERO=y: a local unprivileged user opens AF_RDS, sets SO_RDS_TRANSPORT=IB, binds to a local address on an RDMA-capable netdev (rxe soft-RoCE on any netdev is sufficient), sendto()'s any peer on the same subnet (fails cleanly but installs an rds_connection in the global hash in RDS_CONN_CONNECTING), then calls getsockopt(SOL_RDS, RDS_INFO_IB_CONNECTIONS). The returned 68-byte item contains 26 bytes of stack garbage including kernel text/data pointers: 0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2 8..39 00 ... gids (memset-zeroed) 40..47 e0 92 a3 81 ff ff ff ff kernel pointer (max_send_wr) 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdma_mr_max) 56..59 01 00 08 00 rdma_mr_size (garbage) 60..61 00 00 tos, sl 62..63 00 00 alignment padding 64..67 18 00 00 00 cache_allocs (garbage) Fix by zeroing the per-item buffer in both rds_for_each_conn_info() and rds_walk_conn_path_info() before invoking the visitor. This covers the IPv4/IPv6 IB visitors and hardens all current and future visitors against the same class of bug. No functional change for visitors that fully populate their output. Changes in v2: - retarget at the net tree (subject prefix "[PATCH net v2]", net/rds: prefix in the title) - pick up Reviewed-by tags from Sharath Srinivasan and Allison Henderson Fixes: ec16227e1414 ("RDS/IB: Infiniband transport") Signed-off-by: Michael Bommarito Reviewed-by: Sharath Srinivasan Reviewed-by: Allison Henderson Assisted-by: Claude:claude-opus-4-7 Link: https://patch.msgid.link/20260418141047.3398203-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 11e08495c949af594f76514aa03572e8ad1b1945 Author: Xin Long Date: Fri Apr 17 17:09:40 2026 -0400 sctp: fix sockets_allocated imbalance after sk_clone() [ Upstream commit 7c9b012d6367a335f1e91da28401a7c612305a46 ] sk_clone() increments sockets_allocated and sets the socket refcount to 2. SCTP performs additional accounting in sctp_clone_sock(), so the clone-time increment must be undone to avoid double counting. Note we cannot simply remove the SCTP-side increment, because the SCTP destroy path in sctp_destroy_sock() only decrements sockets_allocated when sp->ep is set, which may not be true for all failure paths in sctp_clone_sock(). Fixes: 16942cf4d3e3 ("sctp: Use sk_clone() in sctp_accept().") Signed-off-by: Xin Long Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/af8d66f928dec3e9fcbee8d4a85b7d5a6b86f515.1776460180.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8f47fc01f701c13d3c27e1fccdacb1ed5fcf462c Author: Vikas Gupta Date: Sat Apr 18 08:04:38 2026 +0530 bnge: remove unsupported backing store type [ Upstream commit c6b34add67a5402f53359580956b5c318965a893 ] The backing store type, BNGE_CTX_MRAV, is not applicable in Thor Ultra devices. Remove it from the backing store configuration, as the firmware will not populate entities in this backing store type, due to which the driver load fails. Fixes: 29c5b358f385 ("bng_en: Add backing store support") Signed-off-by: Vikas Gupta Reviewed-by: Dharmender Garg Link: https://patch.msgid.link/20260418023438.1597876-3-vikas.gupta@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6156854bf6a748ebe96bd453b9d3209a9a858360 Author: Vikas Gupta Date: Sat Apr 18 08:04:37 2026 +0530 bnge: fix initial HWRM sequence [ Upstream commit 70d7c905a07ae8415b955569620bf2bf77423553 ] Firmware may not advertize correct resources if backing store is not enabled before resource information is queried. Fix the initial sequence of HWRMs so that driver gets capabilities and resource information correctly. Fixes: 3fa9e977a0cd ("bng_en: Initialize default configuration") Signed-off-by: Vikas Gupta Reviewed-by: Rahul Gupta Link: https://patch.msgid.link/20260418023438.1597876-2-vikas.gupta@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0d2fb678b29a2ddd83e9d269c9d0d50daa59ea8b Author: Kohei Enju Date: Mon Apr 20 10:54:23 2026 +0000 net: validate skb->napi_id in RX tracepoints [ Upstream commit 3bfcf396081ace536733b454ff128d53116581e5 ] Since commit 2bd82484bb4c ("xps: fix xps for stacked devices"), skb->napi_id shares storage with sender_cpu. RX tracepoints using net_dev_rx_verbose_template read skb->napi_id directly and can therefore report sender_cpu values as if they were NAPI IDs. For example, on the loopback path this can report 1 as napi_id, where 1 comes from raw_smp_processor_id() + 1 in the XPS path: # bpftrace -e 'tracepoint:net:netif_rx_entry{ print(args->napi_id); }' # taskset -c 0 ping -c 1 ::1 Report only valid NAPI IDs in these tracepoints and use 0 otherwise. Fixes: 2bd82484bb4c ("xps: fix xps for stacked devices") Signed-off-by: Kohei Enju Reviewed-by: Simon Horman Reviewed-by: Jiayuan Chen Link: https://patch.msgid.link/20260420105427.162816-1-kohei@enjuk.jp Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1e2bec062c5c9ec282636715166056d0998d746d Author: Hyunwoo Kim Date: Tue Apr 21 00:31:47 2026 +0900 ksmbd: scope conn->binding slowpath to bound sessions only [ Upstream commit b0da97c034b6107d14e537e212d4ce8b22109a58 ] When the binding SESSION_SETUP sets conn->binding = true, the flag stays set after the call so that the global session lookup in ksmbd_session_lookup_all() can find the session, which was not added to conn->sessions. Because the flag is connection-wide, the global lookup path will also resolve any other session by id if asked. Tighten the global lookup so that the returned session must have this connection registered in its channel xarray (sess->ksmbd_chann_list). The channel entry is installed by the existing binding_session path in ntlm_authenticate()/krb5_authenticate() when a SESSION_SETUP completes successfully, so this condition is a strict equivalent of "this connection has been accepted as a channel of this session". Connections that have not bound to a given session cannot reach it via the global table. The existing conn->binding gate for entering the slowpath is preserved so that non-binding connections keep the fast-path-only behavior, and the session->state check is unchanged. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Signed-off-by: Hyunwoo Kim Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 8c4a0ef19c8264c150833131af34541495832cd0 Author: DaeMyung Kang Date: Tue Apr 21 03:45:11 2026 +0900 ksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open [ Upstream commit 804054d19886ac6628883d82410f6ee42a818664 ] ksmbd_lookup_fd_cguid() returns a ksmbd_file with its refcount incremented via ksmbd_fp_get(). parse_durable_handle_context() in the DURABLE_REQ_V2 case properly releases this reference on every path inside the ClientGUID-match branch, either by calling ksmbd_put_durable_fd() or by transferring ownership to dh_info->fp for a successful reconnect. However, when an entry exists in the global file table with the same CreateGuid but a different ClientGUID, the code simply falls through to the new-open path without dropping the reference obtained from ksmbd_lookup_fd_cguid(). Per MS-SMB2 section 3.3.5.9.10 ("Handling the SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context"), the server MUST locate an Open whose Open.CreateGuid matches the request's CreateGuid AND whose Open.ClientGuid matches the ClientGuid of the connection that received the request. If no such Open is found, the server MUST continue with the normal open execution phase. A CreateGuid hit with a ClientGUID mismatch is therefore the "Open not found" case: proceeding with a new open is correct, but the reference obtained purely as a side effect of the lookup must not be leaked. Repeated requests that hit this mismatch pin global_ft entries, prevent __ksmbd_close_fd() from ever running for the corresponding files, and defeat the durable scavenger, leading to long-lived resource leaks. Release the reference in the mismatch path and clear dh_info->fp so subsequent logic does not mistake a non-matching lookup result for a reconnect target. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 5ff116fb34842ab24b535ade3a8ec1ff6acdde2d Author: DaeMyung Kang Date: Sun Apr 19 20:02:55 2026 +0900 ksmbd: destroy async_ida in ksmbd_conn_free() [ Upstream commit b32c8db48212a34998c36d0bbc05b29d5c407ef5 ] When per-connection async_ida was converted from a dynamically allocated ksmbd_ida to an embedded struct ida, ksmbd_ida_free() was removed from the connection teardown path but no matching ida_destroy() was added. The connection is therefore freed with the IDA's backing xarray still intact. The kernel IDA API expects ida_init() and ida_destroy() to be paired over an object's lifetime, so add the missing cleanup before the connection is freed. No leak has been observed in testing; this is a pairing fix to match the IDA lifetime rules, not a response to a reproduced regression. Fixes: d40012a83f87 ("cifsd: declare ida statically") Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 44d76f9b532110e1d831c4fec9b7dfeb140f01b7 Author: DaeMyung Kang Date: Sun Apr 19 20:02:54 2026 +0900 ksmbd: destroy tree_conn_ida in ksmbd_session_destroy() [ Upstream commit c049ee14eb4343b69b6f7755563f961f5e153423 ] When per-session tree_conn_ida was converted from a dynamically allocated ksmbd_ida to an embedded struct ida, ksmbd_ida_free() was removed from ksmbd_session_destroy() but no matching ida_destroy() was added. The session is therefore freed with the IDA's backing xarray still intact. The kernel IDA API expects ida_init() and ida_destroy() to be paired over an object's lifetime, so add the missing cleanup before the enclosing session is freed. Also move ida_init() to right after the session is allocated so that it is always paired with the destroy call even on the early error paths of __session_create() (ksmbd_init_file_table() or __init_smb2_session() failures), both of which jump to the error label and invoke ksmbd_session_destroy() on a partially initialised session. No leak has been observed in testing; this is a pairing fix to match the IDA lifetime rules, not a response to a reproduced regression. Fixes: d40012a83f87 ("cifsd: declare ida statically") Signed-off-by: DaeMyung Kang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ad114980e5052997de30dbad01f5083100b27370 Author: Sangyun Kim Date: Sun Apr 19 17:08:38 2026 +0900 pwm: atmel-tcb: Cache clock rates and mark chip as atomic [ Upstream commit 68637b68afcc3cb4d56aca14a3a1d1b47b879369 ] atmel_tcb_pwm_apply() holds tcbpwmc->lock as a spinlock via guard(spinlock)() and then calls atmel_tcb_pwm_config(), which calls clk_get_rate() twice. clk_get_rate() acquires clk_prepare_lock (a mutex), so this is a sleep-in-atomic-context violation. On CONFIG_DEBUG_ATOMIC_SLEEP kernels every pwm_apply_state() that enables or reconfigures the PWM triggers a "BUG: sleeping function called from invalid context" warning. Acquire exclusive control over the clock rates with clk_rate_exclusive_get() at probe time and cache the rates in struct atmel_tcb_pwm_chip, then read the cached rates from atmel_tcb_pwm_config(). This keeps the spinlock-based mutual exclusion introduced in commit 37f7707077f5 ("pwm: atmel-tcb: Fix race condition and convert to guards") and removes the sleeping calls from the atomic section. With no sleeping calls left in .apply() and the regmap-mmio bus already running with fast_io=true, also mark the chip as atomic so consumers can use pwm_apply_atomic() from atomic context. Fixes: 37f7707077f5 ("pwm: atmel-tcb: Fix race condition and convert to guards") Signed-off-by: Sangyun Kim Link: https://patch.msgid.link/20260419080838.3192357-1-sangyun.kim@snu.ac.kr [ukleinek: Ensure .clk is enabled before calling clk_get_rate on it.] Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 4f1000a30f67cf7d328059242776a858611d5ef9 Author: Matt Evans Date: Wed Apr 15 11:17:52 2026 -0700 vfio/pci: Clean up DMABUFs before disabling function [ Upstream commit d97708701434ce72968e771976aaf9d3438fcafd ] On device shutdown, make vfio_pci_core_close_device() call vfio_pci_dma_buf_cleanup() before the function is disabled via vfio_pci_core_disable(). This ensures that all access via DMABUFs is revoked before the function's BARs become inaccessible. This fixes an issue where, if the function is disabled first, a tiny window exists in which the function's MSE is cleared and yet BARs could still be accessed via the DMABUF. The resources would also be freed and up for grabs by a different driver. Fixes: 5d74781ebc86c ("vfio/pci: Add dma-buf export support for MMIO regions") Signed-off-by: Matt Evans Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Reviewed-by: Leon Romanovsky Link: https://lore.kernel.org/r/20260415181752.1027604-1-mattev@meta.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit ebaeebf51fc5c0190ee0f04509d4cdb77671248b Author: Jun Yan Date: Mon Mar 30 22:51:11 2026 +0800 arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number [ Upstream commit 174a0ef3b33434f475c87e66f37980e39b73805a ] Correct the interrupt number assigned to the Realtek PHY in the p230 following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm: fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY interrupt improvements [1]. [1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/ Fixes: b94d22d94ad2 ("ARM64: dts: meson-gx: add external PHY interrupt on some platforms") Signed-off-by: Jun Yan Reviewed-by: Martin Blumenstingl Link: https://patch.msgid.link/20260330145111.115318-1-jerrysteve1101@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit e2f7d31a595634de88cfb113fbf6f20e825d8916 Author: Anand Moon Date: Thu Feb 19 16:05:46 2026 +0530 arm64: dts: amlogic: meson-axg: Add missing cache information to cpu0 [ Upstream commit 918273be0885362a9a00615b46e03f15f8b55667 ] Add missing L1 data and instruction cache parameters to the CPU node 0 for the Cortex-A53 caches on the Meson AXG SoC. Fixes: 3b6ad2a43367 ("arm64: dts: amlogic: Add cache information to the Amlogic AXG SoCS") Signed-off-by: Anand Moon Link: https://patch.msgid.link/20260219103548.18392-1-linux.amoon@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 3042add80c2c50bd127d570b83319af612efde65 Author: Chia-Yu Chang Date: Fri Apr 17 17:25:51 2026 +0200 net/sched: sch_dualpi2: drain both C-queue and L-queue in dualpi2_change() [ Upstream commit 478ed6b7d2577439c610f91fa8759a4c878a4264 ] Fix dualpi2_change() to correctly enforce updated limit and memlimit values after a configuration change of the dualpi2 qdisc. Before this patch, dualpi2_change() always attempted to dequeue packets via the root qdisc (C-queue) when reducing backlog or memory usage, and unconditionally assumed that a valid skb will be returned. When traffic classification results in packets being queued in the L-queue while the C-queue is empty, this leads to a NULL skb dereference during limit or memlimit enforcement. This is fixed by first dequeuing from the C-queue path if it is non-empty. Once the C-queue is empty, packets are dequeued directly from the L-queue. Return values from qdisc_dequeue_internal() are checked for both queues. When dequeuing from the L-queue, the parent qdisc qlen and backlog counters are updated explicitly to keep overall qdisc statistics consistent. Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc") Reported-by: "Kito Xu (veritas501)" Closes: https://lore.kernel.org/netdev/20260413075740.2234828-1-hxzene@gmail.com/ Signed-off-by: Chia-Yu Chang Link: https://patch.msgid.link/20260417152551.71648-1-chia-yu.chang@nokia-bell-labs.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d42bec6e4f6d6d658be365539400b3314b76b2a7 Author: Weiming Shi Date: Thu Apr 16 18:01:51 2026 +0800 slip: bound decode() reads against the compressed packet length [ Upstream commit 4c1367a2d7aad643a6f87c6931b13cc1a25e8ca7 ] slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Simon Horman Closes: https://lore.kernel.org/netdev/20260414134126.758795-2-horms@kernel.org/ Signed-off-by: Weiming Shi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260416100147.531855-5-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7b0d9e878ec2b21d99ae8051b3dda59cdb66c152 Author: Weiming Shi Date: Thu Apr 16 04:41:31 2026 +0800 slip: reject VJ receive packets on instances with no rstate array [ Upstream commit e76607442d5b73e1ba6768f501ef815bb58c2c0e ] slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work. Fixes: 4ab42d78e37a ("ppp, slip: Validate VJ compression slot parameters completely") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260415204130.258866-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 83fc5dd63455a779ea2dd0f7ffee3c920919d80b Author: Fernando Fernandez Mancera Date: Fri Apr 17 18:20:57 2026 +0200 netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check [ Upstream commit 711987ba281fd806322a7cd244e98e2a81903114 ] The nf_osf_ttl() function accessed skb->dev to perform a local interface address lookup without verifying that the device pointer was valid. Additionally, the implementation utilized an in_dev_for_each_ifa_rcu loop to match the packet source address against local interface addresses. It assumed that packets from the same subnet should not see a decrement on the initial TTL. A packet might appear it is from the same subnet but it actually isn't especially in modern environments with containers and virtual switching. Remove the device dereference and interface loop. Replace the logic with a switch statement that evaluates the TTL according to the ttl_check. Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Reported-by: Kito Xu (veritas501) Closes: https://lore.kernel.org/netfilter-devel/20260414074556.2512750-1-hxzene@gmail.com/ Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Pablo Neira Ayuso Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit edb78a142d2e5948e63647c0646aa7e7886935f0 Author: Fernando Fernandez Mancera Date: Fri Apr 17 18:20:56 2026 +0200 netfilter: nfnetlink_osf: fix out-of-bounds read on option matching [ Upstream commit f5ca450087c3baf3651055e7a6de92600f827af3 ] In nf_osf_match(), the nf_osf_hdr_ctx structure is initialized once and passed by reference to nf_osf_match_one() for each fingerprint checked. During TCP option parsing, nf_osf_match_one() advances the shared ctx->optp pointer. If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nf_osf_match_one() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches. Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nf_osf_match_one() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset. Fixes: 1a6a0951fc00 ("netfilter: nfnetlink_osf: add missing fmatch check") Suggested-by: Florian Westphal Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Pablo Neira Ayuso Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ce567b03ce7ae9c93dfe936055fa35545fdd034c Author: Yingnan Zhang <342144303@qq.com> Date: Wed Apr 15 22:40:29 2026 +0800 ipvs: fix MTU check for GSO packets in tunnel mode [ Upstream commit 67bf42cae41d847fd6e5749eb68278ca5d748b25 ] Currently, IPVS skips MTU checks for GSO packets by excluding them with the !skb_is_gso(skb) condition. This creates problems when IPVS tunnel mode encapsulates GSO packets with IPIP headers. The issue manifests in two ways: 1. MTU violation after encapsulation: When a GSO packet passes through IPVS tunnel mode, the original MTU check is bypassed. After adding the IPIP tunnel header, the packet size may exceed the outgoing interface MTU, leading to unexpected fragmentation at the IP layer. 2. Fragmentation with problematic IP IDs: When net.ipv4.vs.pmtu_disc=1 and a GSO packet with multiple segments is fragmented after encapsulation, each segment gets a sequentially incremented IP ID (0, 1, 2, ...). This happens because: a) The GSO packet bypasses MTU check and gets encapsulated b) At __ip_finish_output, the oversized GSO packet is split into separate SKBs (one per segment), with IP IDs incrementing c) Each SKB is then fragmented again based on the actual MTU This sequential IP ID allocation differs from the expected behavior and can cause issues with fragment reassembly and packet tracking. Fix this by properly validating GSO packets using skb_gso_validate_network_len(). This function correctly validates whether the GSO segments will fit within the MTU after segmentation. If validation fails, send an ICMP Fragmentation Needed message to enable proper PMTU discovery. Fixes: 4cdd34084d53 ("netfilter: nf_conntrack_ipv6: improve fragmentation handling") Signed-off-by: Yingnan Zhang <342144303@qq.com> Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3c7511f38ab511b791196b13ae48bf4973bf7dfd Author: Pablo Neira Ayuso Date: Wed Apr 15 17:29:45 2026 +0200 netfilter: nat: use kfree_rcu to release ops [ Upstream commit 6eda0d771f94267f73f57c94630aa47e90957915 ] Florian Westphal says: "Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nf_hook_ops that are used to register the callbacks. However, in v5.14 I added the ability to dump the active netfilter hooks from userspace. This code will peek back into the nf_hook_ops that are available at the tail of the pointer-array blob used by the datapath. The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though. But once that changes the nat ops structures have to be deferred too." Update nf_nat_register_fn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlink_hook. Fixes: e2cf17d3774c ("netfilter: add new hook nfnl subsystem") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit fa88161ef56e29bdaa05cc89dbc4ee221e94bfe9 Author: Pablo Neira Ayuso Date: Wed Apr 15 12:21:00 2026 +0200 netfilter: xtables: restrict several matches to inet family [ Upstream commit b6fe26f86a1649f84e057f3f15605b08eda15497 ] This is a partial revert of: commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions") to allow ipv4 and ipv6 only. - xt_mac - xt_owner - xt_physdev These extensions are not used by ebtables in userspace. Moreover, xt_realm is only for ipv4, since dst->tclassid is ipv4 specific. Fixes: ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions") Reported-by: "Kito Xu (veritas501)" Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c08ff52e44945e6ef4ce0790f49ea761b060c45b Author: Florian Westphal Date: Tue Apr 14 19:13:46 2026 +0200 netfilter: conntrack: remove sprintf usage [ Upstream commit 6e7066bdb481a87fe88c4fa563e348c03b2d373d ] Replace it with scnprintf, the buffer sizes are expected to be large enough to hold the result, no need for snprintf+overflow check. Increase buffer size in mangle_content_len() while at it. BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270 Write of size 1 at addr [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 mangle_content_len+0x1ac/0x280 nf_nat_sdp_session+0x1cc/0x240 process_sdp+0x8f8/0xb80 process_invite_request+0x108/0x2b0 process_sip_msg+0x5da/0xf50 sip_help_tcp+0x45e/0x780 nf_confirm+0x34d/0x990 [..] Fixes: 9fafcd7b2032 ("[NETFILTER]: nf_conntrack/nf_nat: add SIP helper port") Reported-by: Yiming Qian Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9a05e195618a6d474f2bcd5b6376d0ffc2f00366 Author: Xiang Mei Date: Tue Apr 14 15:14:01 2026 -0700 netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO [ Upstream commit 2195574dc6d9017d32ac346987e12659f931d932 ] nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as "should not happen". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622) Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Reported-by: Weiming Shi Suggested-by: Florian Westphal Suggested-by: Pablo Neira Ayuso Signed-off-by: Xiang Mei Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1c1af83b878c3908bf7daa577ff267028a487d84 Author: Pablo Neira Ayuso Date: Tue Apr 14 13:06:38 2026 +0200 netfilter: nft_osf: restrict it to ipv4 [ Upstream commit b336fdbb7103fb1484e1dcb6741151d4b5a41e35 ] This expression only supports for ipv4, restrict it. Fixes: b96af92d6eaf ("netfilter: nf_tables: implement Passive OS fingerprint module in nft_osf") Acked-by: Florian Westphal Reviewed-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 40fa60567c47804066a6f99bd18f24bcac0a0c06 Author: Lorenzo Bianconi Date: Thu Apr 16 12:30:12 2026 +0200 net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll() [ Upstream commit b94769eb2f30e61e86cd8551c084c34134290d89 ] Since multiple net_device TX queues can share the same hw QDMA TX queue, there is no guarantee we have inflight packets queued in hw belonging to a net_device TX queue stopped in the xmit path because hw QDMA TX queue can be full. In this corner case the net_device TX queue will never be re-activated. In order to avoid any potential net_device TX queue stall, we need to wake all the net_device TX queues feeding the same hw QDMA TX queue in airoha_qdma_tx_napi_poll routine. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260416-airoha-txq-potential-stall-v2-1-42c732074540@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1d6c02b86329883aa467a3a61f8d34369db73a2f Author: Weiming Shi Date: Wed Apr 15 19:46:54 2026 -0700 openvswitch: cap upcall PID array size and pre-size vport replies [ Upstream commit 2091c6aa0df6aba47deb5c8ab232b1cb60af3519 ] The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent. Fixes: 5cd667b0a456 ("openvswitch: Allow each vport to have an array of 'port_id's.") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Weiming Shi Reviewed-by: Ilya Maximets Link: https://patch.msgid.link/20260416024653.153456-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6ea36220e28f26215eb028ce14f7cf38e116981b Author: Prathamesh Deshpande Date: Wed Apr 15 01:49:37 2026 +0100 net/mlx5: Fix HCA caps leak on notifier init failure [ Upstream commit d03fc81a57956248383efec99967d0ae627390a8 ] mlx5_mdev_init() allocates HCA caps via mlx5_hca_caps_alloc() before calling mlx5_notifiers_init(). If notifier initialization fails, the error path jumps to err_hca_caps and skips mlx5_hca_caps_free(), leaking allocated caps. Add a dedicated unwind label for notifier-init failure that frees HCA caps before continuing the existing cleanup sequence. Fixes: b6b03097f982 ("net/mlx5: Initialize events outside devlink lock") Signed-off-by: Prathamesh Deshpande Reviewed-by: Cosmin Ratiu Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260415005022.34764-1-prathameshdeshpande7@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2b5c3c040d020e3ab3b9a8887031202d96843b1e Author: Qingfang Deng Date: Wed Apr 15 10:24:51 2026 +0800 pppoe: drop PFC frames [ Upstream commit cc1ff87bce1ccd38410ab10960f576dcd17db679 ] RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function ppp_input() is not aware of the negotiation result, and still accepts PFC frames. If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures. To reduce the attack surface, drop PPPoE PFC frames. Introduce ppp_skb_is_compressed_proto() helper function to be used in both ppp_generic.c and pppoe.c to avoid open-coding. Fixes: 7fb1b8ca8fa1 ("ppp: Move PFC decompression to PPP generic layer") Signed-off-by: Qingfang Deng Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260415022456.141758-2-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6bcf8fe4ef7967b22b814cbae9a57bbd3c853410 Author: Michael Bommarito Date: Wed Apr 15 23:19:03 2026 -0400 sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks [ Upstream commit 0cf004ffb61cd32d140531c3a84afe975f9fc7ea ] sctp_getsockopt_peer_auth_chunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with if (len < num_chunks) return -EINVAL; but then writes num_chunks bytes to p->gauth_chunks, which lives at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8 inside optval. The check is missing the sizeof(struct sctp_authchunks) = 8-byte header. When the caller supplies len == num_chunks (for any num_chunks > 0) the test passes but copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes past the declared buffer. The sibling function sctp_getsockopt_local_auth_chunks() at the next line already has the correct check: if (len < sizeof(struct sctp_authchunks) + num_chunks) return -EINVAL; Align the peer variant with its sibling. Reproducer confirms on v7.0-13-generic: an unprivileged userspace caller that opens a loopback SCTP association with AUTH enabled, queries num_chunks with a short optval, then issues the real getsockopt with len == num_chunks and sentinel bytes painted past the buffer observes those sentinel bytes overwritten with the peer's AUTH chunk type. The bytes written are under the peer's control but land in the caller's own userspace; this is not a kernel memory corruption, but it is a kernel-side contract violation that can silently corrupt adjacent userspace data. Fixes: 65b07e5d0d09 ("[SCTP]: API updates to suport SCTP-AUTH extensions.") Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Michael Bommarito Acked-by: Xin Long Link: https://patch.msgid.link/20260416031903.1447072-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b34a1d83c74a124c968b5adb25c809db3e2eb86a Author: Kuniyuki Iwashima Date: Wed Apr 15 18:48:29 2026 +0000 af_unix: Drop all SCM attributes for SOCKMAP. [ Upstream commit 965dc93481d1b80d341bdd16c27b16fe197175ee ] SOCKMAP can hide inflight fd from AF_UNIX GC. When a socket in SOCKMAP receives skb with inflight fd, sk_psock_verdict_data_ready() looks up the mapped socket and enqueue skb to its psock->ingress_skb. Since neither the old nor the new GC can inspect the psock queue, the hidden skb leaks the inflight sockets. Note that this cannot be detected via kmemleak because inflight sockets are linked to a global list. In addition, SOCKMAP redirect breaks the Tarjan-based GC's assumption that unix_edge.successor is always alive, which is no longer true once skb is redirected, resulting in use-after-free below. [0] Moreover, SOCKMAP does not call scm_stat_del() properly, so unix_show_fdinfo() could report an incorrect fd count. sk_msg_recvmsg() does not support any SCM attributes in the first place. Let's drop all SCM attributes before passing skb to the SOCKMAP layer. [0]: BUG: KASAN: slab-use-after-free in unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) Read of size 8 at addr ffff888125362670 by task kworker/56:1/496 CPU: 56 UID: 0 PID: 496 Comm: kworker/56:1 Not tainted 7.0.0-rc7-00263-gb9d8b856689d #3 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: events sk_psock_backlog Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:379) kasan_report (mm/kasan/report.c:597) unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) unix_destroy_fpl (net/unix/garbage.c:317) unix_destruct_scm (./include/net/scm.h:80 ./include/net/scm.h:86 net/unix/af_unix.c:1976) sk_psock_backlog (./include/linux/skbuff.h:?) process_scheduled_works (kernel/workqueue.c:?) worker_thread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:258) Allocated by task 955: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) __kasan_slab_alloc (mm/kasan/common.c:369) kmem_cache_alloc_noprof (mm/slub.c:4539) sk_prot_alloc (net/core/sock.c:2240) sk_alloc (net/core/sock.c:2301) unix_create1 (net/unix/af_unix.c:1099) unix_create (net/unix/af_unix.c:1169) __sock_create (net/socket.c:1606) __sys_socketpair (net/socket.c:1811) __x64_sys_socketpair (net/socket.c:1863 net/socket.c:1860 net/socket.c:1860) do_syscall_64 (arch/x86/entry/syscall_64.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 496: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kmem_cache_free (mm/slub.c:6165) __sk_destruct (net/core/sock.c:2282 net/core/sock.c:2384) sk_psock_destroy (./include/net/sock.h:?) process_scheduled_works (kernel/workqueue.c:?) worker_thread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:258) Fixes: c63829182c37 ("af_unix: Implement ->psock_update_sk_prot()") Fixes: 77462de14a43 ("af_unix: Add read_sock for stream socket types") Reported-by: Xingyu Jin Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260415184830.3988432-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 085e31a811ef234ef8c3e219c4636dfebfe7e10f Author: Eric Dumazet Date: Thu Apr 16 10:35:05 2026 +0000 ipv6: fix possible UAF in icmpv6_rcv() [ Upstream commit f996edd7615e686ada141b7f3395025729ff8ccb ] Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. Remove these temporary variables: - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path. - Avoid potential future misuse after pskb_pull() call. Fixes: 4b3418fba0fe ("ipv6: icmp: include addresses in debug messages") Signed-off-by: Eric Dumazet Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Joe Damato Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260416103505.2380753-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a1c7070df8482383c99499723f96cb04d30d6184 Author: Matt Vollrath Date: Thu Apr 16 17:53:36 2026 -0700 e1000e: Unroll PTP in probe error handling [ Upstream commit aa3f7fe409350857c25d050482a2eef2cfd69b58 ] If probe fails after registering the PTP clock and its delayed work, these resources must be released. This was not an issue until a 2016 fix moved the e1000e_ptp_init() call before the jump to err_register. Fixes: aa524b66c5ef ("e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl") Signed-off-by: Matt Vollrath Tested-by: Avigail Dahan Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-12-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3d026fa02ef859b836e4529268ed08c4c78ae59c Author: Petr Oros Date: Thu Apr 16 17:53:34 2026 -0700 iavf: fix wrong VLAN mask for legacy Rx descriptors L2TAG2 [ Upstream commit 496d9f91062fa07956702e0f234c5203f03a974d ] The IAVF_RXD_LEGACY_L2TAG2_M mask was incorrectly defined as GENMASK_ULL(63, 32), extracting 32 bits from qw2 instead of the 16-bit VLAN tag. In the legacy Rx descriptor layout, the 2nd L2TAG2 (VLAN tag) occupies bits 63:48 of qw2, not 63:32. The oversized mask causes FIELD_GET to return a 32-bit value where the actual VLAN tag sits in bits 31:16. When this value is passed to iavf_receive_skb() as a u16 parameter, it gets truncated to the lower 16 bits (which contain the 1st L2TAG2, typically zero). As a result, __vlan_hwaccel_put_tag() is never called and software VLAN interfaces on VFs receive no traffic. This affects VFs behind ice PF (VIRTCHNL VLAN v2) when the PF advertises VLAN stripping into L2TAG2_2 and legacy descriptors are used. The flex descriptor path already uses the correct mask (IAVF_RXD_FLEX_L2TAG2_2_M = GENMASK_ULL(63, 48)). Reproducer: 1. Create 2 VFs on ice PF (echo 2 > sriov_numvfs) 2. Disable spoofchk on both VFs 3. Move each VF into a separate network namespace 4. On each VF: create VLAN interface (e.g. vlan 198), assign IP, bring up 5. Set rx-vlan-offload OFF on both VFs 6. Ping between VLAN interfaces -> expect PASS (VLAN tag stays in packet data, kernel matches in-band) 7. Set rx-vlan-offload ON on both VFs 8. Ping between VLAN interfaces -> expect FAIL if bug present (HW strips VLAN tag into descriptor L2TAG2 field, wrong mask extracts bits 47:32 instead of 63:48, truncated to u16 -> zero, __vlan_hwaccel_put_tag() never called, packet delivered to parent interface, not VLAN interface) The reproducer requires legacy Rx descriptors. On modern ice + iavf with full PTP support, flex descriptors are always negotiated and the buggy legacy path is never reached. Flex descriptors require all of: - CONFIG_PTP_1588_CLOCK enabled - VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC granted by PF - PTP capabilities negotiated (VIRTCHNL_VF_CAP_PTP) - VIRTCHNL_1588_PTP_CAP_RX_TSTAMP supported - VIRTCHNL_RXDID_2_FLEX_SQ_NIC present in DDP profile If any condition is not met, iavf_select_rx_desc_format() falls back to legacy descriptors (RXDID=1) and the wrong L2TAG2 mask is hit. Fixes: 2dc8e7c36d80 ("iavf: refactor iavf_clean_rx_irq to support legacy and flex descriptors") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Reviewed-by: Jacob Keller Tested-by: Rafal Romanowski Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-10-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 19de9e2617096f6269bab198e1f12ee26998a53c Author: Kohei Enju Date: Thu Apr 16 17:53:33 2026 -0700 i40e: don't advertise IFF_SUPP_NOFCS [ Upstream commit a24162f18825684ad04e3a5d0531f8a50d679347 ] i40e advertises IFF_SUPP_NOFCS, allowing users to use the SO_NOFCS socket option. However, this option is silently ignored, as the driver does not check skb->no_fcs, and always enables FCS insertion offload. Fix this by removing the advertisement of IFF_SUPP_NOFCS. This behavior can be reproduced with a simple AF_PACKET socket: import socket s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW) s.setsockopt(socket.SOL_SOCKET, 43, 1) # SO_NOFCS s.bind(("eth0", 0)) s.send(b'\xff' * 64) Previously, send() succeeds but the driver ignores SO_NOFCS. With this change, send() fails with -EPROTONOSUPPORT, as expected. Fixes: 41c445ff0f48 ("i40e: main driver core") Signed-off-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-9-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c54e3c270384829336b2526033d44ce1aa6dc67c Author: Kohei Enju Date: Thu Apr 16 17:53:32 2026 -0700 ice: fix potential NULL pointer deref in error path of ice_set_ringparam() [ Upstream commit fa28351f970fa5138c7c5dedfe5dea480a0ee065 ] ice_set_ringparam nullifies tstamp_ring of temporary tx_rings, without clearing ICE_TX_RING_FLAGS_TXTIME bit. When ICE_TX_RING_FLAGS_TXTIME is set and the subsequent ice_setup_tx_ring() call fails, a NULL pointer dereference could happen in the unwinding sequence: ice_clean_tx_ring() -> ice_is_txtime_cfg() == true (ICE_TX_RING_FLAGS_TXTIME is set) -> ice_free_tx_tstamp_ring() -> ice_free_tstamp_ring() -> tstamp_ring->desc (NULL deref) Clear ICE_TX_RING_FLAGS_TXTIME bit to avoid the potential issue. Note that this potential issue is found by manual code review. Compile test only since unfortunately I don't have E830 devices. Fixes: ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support") Signed-off-by: Kohei Enju Reviewed-by: Paul Greenwalt Tested-by: Rinitha S Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-8-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 097409d20465723283632515df73038a4a853eda Author: Keita Morisaki Date: Thu Apr 16 17:53:31 2026 -0700 ice: fix race condition in TX timestamp ring cleanup [ Upstream commit 7c72ec18c2a4111204c2e915f8e4f6d849ce9398 ] Fix a race condition between ice_free_tx_tstamp_ring() and ice_tx_map() that can cause a NULL pointer dereference. ice_free_tx_tstamp_ring currently clears the ICE_TX_FLAGS_TXTIME flag after NULLing the tstamp_ring. This could allow a concurrent ice_tx_map call on another CPU to dereference the tstamp_ring, which could lead to a NULL pointer dereference. CPU A:ice_free_tx_tstamp_ring() | CPU B:ice_tx_map() --------------------------------|--------------------------------- tx_ring->tstamp_ring = NULL | | ice_is_txtime_cfg() -> true | tstamp_ring = tx_ring->tstamp_ring | tstamp_ring->count // NULL deref! flags &= ~ICE_TX_FLAGS_TXTIME | Fix by: 1. Reordering ice_free_tx_tstamp_ring() to clear the flag before NULLing the pointer, with smp_wmb() to ensure proper ordering. 2. Adding smp_rmb() in ice_tx_map() after the flag check to order the flag read before the pointer read, using READ_ONCE() for the pointer, and adding a NULL check as a safety net. 3. Converting tx_ring->flags from u8 to DECLARE_BITMAP() and using atomic bitops (set_bit(), clear_bit(), test_bit()) for all flag operations throughout the driver: - ICE_TX_RING_FLAGS_XDP - ICE_TX_RING_FLAGS_VLAN_L2TAG1 - ICE_TX_RING_FLAGS_VLAN_L2TAG2 - ICE_TX_RING_FLAGS_TXTIME Fixes: ccde82e909467 ("ice: add E830 Earliest TxTime First Offload support") Signed-off-by: Keita Morisaki Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-7-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9d1cd3f3241355a2a93ab6ab1c596b91d439ca1c Author: Paul Greenwalt Date: Thu Apr 16 17:53:30 2026 -0700 ice: fix ICE_AQ_LINK_SPEED_M for 200G [ Upstream commit 4a3a940059e98539de293a6e36e464094c2e875b ] When setting PHY configuration during driver initialization, 200G link speed is not being advertised even when the PHY is capable. This is because the get PHY capabilities link speed response is being masked by ICE_AQ_LINK_SPEED_M, which does not include the 200G link speed bit. ICE_AQ_LINK_SPEED_200GB is defined as BIT(11), but the mask 0x7FF only covers bits 0-10. Fix ICE_AQ_LINK_SPEED_M to use GENMASK(11, 0) so that it covers all defined link speed bits including 200G. Fixes: 24407a01e57c ("ice: Add 200G speed/phy type use") Signed-off-by: Paul Greenwalt Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-6-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 75f11fd0e1b1b197c944ae8b1461da252bb934d5 Author: Paul Greenwalt Date: Thu Apr 16 17:53:29 2026 -0700 ice: fix PHY config on media change with link-down-on-close [ Upstream commit 55e74f9ea7fea3d3da1cb6d5cacdaf8cf0fe3516 ] Commit 1a3571b5938c ("ice: restore PHY settings on media insertion") introduced separate flows for setting PHY configuration on media present: ice_configure_phy() when link-down-on-close is disabled, and ice_force_phys_link_state() when enabled. The latter incorrectly uses the previous configuration even after module change, causing link issues such as wrong speed or no link. Unify PHY configuration into a single ice_phy_cfg() function with a link_en parameter, ensuring PHY capabilities are always fetched fresh from hardware. Fixes: 1a3571b5938c ("ice: restore PHY settings on media insertion") Reviewed-by: Przemek Kitszel Signed-off-by: Paul Greenwalt Reviewed-by: Aleksandr Loktionov Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-5-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4c08fc2119ef0281cfa2cee007acf0a251be55f2 Author: Michal Schmidt Date: Thu Apr 16 17:53:28 2026 -0700 ice: fix double-free of tx_buf skb [ Upstream commit 1a303baa715e6b78d6a406aaf335f87ff35acfcd ] If ice_tso() or ice_tx_csum() fail, the error path in ice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points to it and is marked as valid (ICE_TX_BUF_SKB). 'next_to_use' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the tx_buf gets overwritten. But if there is no next packet and the interface is brought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf() will find the tx_buf and free the skb for the second time. The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error path, so that ice_unmap_and_free_tx_buf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path. The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch. I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN. I looked for similar bugs in related Intel drivers and did not find any. Fixes: d76a60ba7afb ("ice: Add support for VLANs and offloads") Assisted-by: Claude:claude-4.6-opus-high Cursor Signed-off-by: Michal Schmidt Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-4-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2d4eab8746436c7a468344bb38bb5dac53e3fc8e Author: Grzegorz Nitka Date: Thu Apr 16 17:53:26 2026 -0700 ice: update PCS latency settings for E825 10G/25Gb modes [ Upstream commit 05567e4052732d70c7ff9655217b3d14d25f639a ] Update MAC Rx/Tx offset registers settings (PHY_MAC_[RX|TX]_OFFSET registers) with the data obtained with the latest research. It applies to PCS latency settings for the following speeds/modes: * 10Gb NO-FEC - TX latency changed from 71.25 ns to 73 ns - RX latency changed from -25.6 ns to -28 ns * 25Gb NO-FEC - TX latency changed from 28.17 ns to 33 ns - RX latency changed from -12.45 ns to -12 ns * 25Gb RS-FEC - TX latency changed from 64.5 ns to 69 ns - RX latency changed from -3.6 ns to -3 ns The original data came from simulation and pre-production hardware. The new data measures the actual delays and as such is more accurate. Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Co-developed-by: Zoltan Fodor Signed-off-by: Zoltan Fodor Reviewed-by: Aleksandr Loktionov Reviewed-by: Jacob Keller Signed-off-by: Grzegorz Nitka Tested-by: Sunitha Mekala Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-2-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fd32e101d3ca4299fcc65a3490694264698cc65b Author: Grzegorz Nitka Date: Thu Apr 16 17:53:25 2026 -0700 ice: fix 'adjust' timer programming for E830 devices [ Upstream commit 885c5e57924dc040b23d0ad0d8388f0e35772159 ] Fix incorrect 'adjust the timer' programming sequence for E830 devices series. Only shadow registers GLTSYN_SHADJ were programmed in the current implementation. According to the specification [1], write to command GLTSYN_CMD register is also required with CMD field set to "Adjust the Time" value, for the timer adjustment to take the effect. The flow was broken for the adjustment less than S32_MAX/MIN range (around +/- 2 seconds). For bigger adjustment, non-atomic programming flow is used, involving set timer programming. Non-atomic flow is implemented correctly. Testing hints: Run command: phc_ctl /dev/ptpX get adj 2 get Expected result: Returned timestamps differ at least by 2 seconds [1] Intel® Ethernet Controller E830 Datasheet rev 1.3, chapter 9.7.5.4 https://cdrdv2.intel.com/v1/dl/getContent/787353?explicitVersion=true Fixes: f00307522786 ("ice: Implement PTP support for E830 devices") Reviewed-by: Aleksandr Loktionov Signed-off-by: Grzegorz Nitka Reviewed-by: Simon Horman Tested-by: Rinitha S Reviewed-by: Jacob Keller Signed-off-by: Jacob Keller Link: https://patch.msgid.link/20260416-iwl-net-submission-2026-04-14-v2-1-686c33c9828d@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 09bdca3fe58c1833446d338a79a2987749ccd66d Author: Eric Dumazet Date: Thu Apr 16 20:03:19 2026 +0000 tcp: annotate data-races around tp->plb_rehash [ Upstream commit 9e89b9d03a2d2e30dcca166d5af52f9a8eceab25 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 29c1c44646ae ("tcp: add u32 counter in tcp_sock and an SNMP counter for PLB") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-15-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d32dcfe2436cc0711e7d36fcdea64adc4350e561 Author: Eric Dumazet Date: Thu Apr 16 20:03:18 2026 +0000 tcp: annotate data-races around (tp->write_seq - tp->snd_nxt) [ Upstream commit 3a63b3d160560ef51e43fb4c880a5cde8078053c ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() annotations to keep KCSAN happy. WRITE_ONCE() annotations are already present. Fixes: e08ab0b377a1 ("tcp: add bytes not sent to SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-14-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2bd5e95bff916e0d94750d1874ac45b369d69d7e Author: Eric Dumazet Date: Thu Apr 16 20:03:17 2026 +0000 tcp: annotate data-races around tp->timeout_rehash [ Upstream commit 71c675358b711bbfd8528949249419dc2dfa4ce1 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 32efcc06d2a1 ("tcp: export count for rehash attempts") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-13-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6fc6f0612034c198a64e2e06e09de5984f84ecdf Author: Eric Dumazet Date: Thu Apr 16 20:03:16 2026 +0000 tcp: annotate data-races around tp->srtt_us [ Upstream commit 290b693ce7c9d48588d88b15a782a3efc6fa036b ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: e8bd8fca6773 ("tcp: add SRTT to SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-12-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 12687a286f67c86b3fa5dd053509267fa822282f Author: Eric Dumazet Date: Thu Apr 16 20:03:15 2026 +0000 tcp: annotate data-races around tp->reord_seen [ Upstream commit 62585690e6b2a112c408fe25f142b246ac833c42 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 7ec65372ca53 ("tcp: add stat of data packet reordering events") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-11-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d1ad7e1ea8a5fe5bd82ea391be2efd44a23335b8 Author: Eric Dumazet Date: Thu Apr 16 20:03:14 2026 +0000 tcp: annotate data-races around tp->dsack_dups [ Upstream commit a984705ca88b976bf1087978fd98b7f3993da88c ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 7e10b6554ff2 ("tcp: add dsack blocks received stats") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-10-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ad58c4144bd942476272f74945ffb4fc229f370 Author: Eric Dumazet Date: Thu Apr 16 20:03:13 2026 +0000 tcp: annotate data-races around tp->bytes_retrans [ Upstream commit 5efc7b9f7cbd43401f1af81d3d7f2be00f93390d ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: fb31c9b9f6c8 ("tcp: add data bytes retransmitted stats") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-9-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3841a0924c05cf47b4e5d260a0a94042d6892094 Author: Eric Dumazet Date: Thu Apr 16 20:03:12 2026 +0000 tcp: annotate data-races around tp->bytes_sent [ Upstream commit ee43e957ce2ec77b2ec47fef28f3c0df6ab01a31 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: ba113c3aa79a ("tcp: add data bytes sent stats") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-8-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 03bab42919c4406148ccebe69f7acbad0f34f68e Author: Eric Dumazet Date: Thu Apr 16 20:03:11 2026 +0000 tcp: add data-race annotations for TCP_NLA_SNDQ_SIZE [ Upstream commit 124199444de467767175a9004e1574dc42523e62 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 87ecc95d81d9 ("tcp: add send queue size stat in SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-7-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0dbbd3865a52772c42f7da37a4a0c53201263aca Author: Eric Dumazet Date: Thu Apr 16 20:03:10 2026 +0000 tcp: annotate data-races around tp->delivered and tp->delivered_ce [ Upstream commit faa886ad3ce5fc8f5156493491fe189b2b726bc9 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: feb5f2ec6464 ("tcp: export packets delivery info") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b9109cd21b5cf084672b722642e40b3cd7ab30b4 Author: Eric Dumazet Date: Thu Apr 16 20:03:09 2026 +0000 tcp: annotate data-races around tp->snd_ssthresh [ Upstream commit fd571afb05ebaeac5d8f09460a0640d4cf6755f8 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 7156d194a077 ("tcp: add snd_ssthresh stat in SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 32815ed45a5711865d4b2a08197d74bdbe0e8253 Author: Eric Dumazet Date: Thu Apr 16 20:03:08 2026 +0000 tcp: add data-races annotations around tp->reordering, tp->snd_cwnd [ Upstream commit 829ba1f329cb7cbd56d599a6d225997fba66dc32 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE(), WRITE_ONCE() data_race() annotations to keep KCSAN happy. Fixes: bb7c19f96012 ("tcp: add related fields into SCM_TIMESTAMPING_OPT_STATS") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 31752350f0b3db163346b1b34a1186b3fc3ffe22 Author: Eric Dumazet Date: Thu Apr 16 20:03:07 2026 +0000 tcp: add data-race annotations around tp->data_segs_out and tp->total_retrans [ Upstream commit 21e92a38cfd891538598ba8f805e0165a820d532 ] tcp_get_timestamping_opt_stats() intentionally runs lockless, we must add READ_ONCE() and WRITE_ONCE() annotations to keep KCSAN happy. Fixes: 7e98102f4897 ("tcp: record pkts sent and retransmistted") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ccad2c7a7fda6ed0ec95fa2aa18e90a43a213c24 Author: Eric Dumazet Date: Thu Apr 16 20:03:06 2026 +0000 tcp: annotate data-races in tcp_get_info_chrono_stats() [ Upstream commit 267bf3cf9a6f0ffb98b8afd983c1950e835f07c9 ] tcp_get_timestamping_opt_stats() does not own the socket lock, this is intentional. It calls tcp_get_info_chrono_stats() while other threads could change chrono fields in tcp_chrono_set(). I do not think we need coherent TCP socket state snapshot in tcp_get_timestamping_opt_stats(), I chose to only add annotations to keep KCSAN happy. Fixes: 1c885808e456 ("tcp: SOF_TIMESTAMPING_OPT_STATS option for SO_TIMESTAMPING") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260416200319.3608680-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c6592f3c5bfe4be8625ca4472ce244c63b91b180 Author: Eric Dumazet Date: Sun Mar 8 12:35:49 2026 +0000 tcp: inline tcp_chrono_start() [ Upstream commit d6d4ff335db2d9242937ca474d292010acd35c38 ] tcp_chrono_start() is small enough, and used in TCP sendmsg() fast path (from tcp_skb_entail()). Note clang is already inlining it from functions in tcp_output.c. Inlining it improves performance and reduces bloat : $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/2 grow/shrink: 1/0 up/down: 1/-84 (-83) Function old new delta tcp_skb_entail 280 281 +1 __pfx_tcp_chrono_start 16 - -16 tcp_chrono_start 68 - -68 Total: Before=25192434, After=25192351, chg -0.00% Note that tcp_chrono_stop() is too big. Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Link: https://patch.msgid.link/20260308123549.2924460-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 267bf3cf9a6f ("tcp: annotate data-races in tcp_get_info_chrono_stats()") Signed-off-by: Sasha Levin commit 79e2d00c17e9c92e121e316d2f4eee95cd892d93 Author: Eric Dumazet Date: Sun Mar 8 12:23:02 2026 +0000 tcp: move tp->chrono_type next tp->chrono_stat[] [ Upstream commit 4b78c9cbd8f1fbb9517aee48b372646f4cf05442 ] chrono_type is currently in tcp_sock_read_txrx group, which is supposed to hold read-mostly fields. But chrono_type is mostly written in tx path, it should be moved to tcp_sock_write_tx group, close to other chrono fields (chrono_stat[], chrono_start). Note this adds holes, but data locality is far more important. Use a full u8 for the time being, compiler can generate more efficient code. Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Link: https://patch.msgid.link/20260308122302.2895067-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 267bf3cf9a6f ("tcp: annotate data-races in tcp_get_info_chrono_stats()") Signed-off-by: Sasha Levin commit 97a0cd55283b4e63fd92804da91c8d9896adcad9 Author: Akif Date: Fri Apr 17 23:57:09 2026 +0530 ksmbd: fix use-after-free in smb2_open during durable reconnect [ Upstream commit 1baff47b81f94f9231c91236aa511420d0e266b9 ] In smb2_open, the call to ksmbd_put_durable_fd(fp) drops the reference to the durable file descriptor early during the durable reconnect process. If an error occurs subsequently (eg, ksmbd_iov_pin_rsp fails) or a scavenger accesses the file, it leads to a use-after-free when accessing fp properties (eg fp->create_time). Move the single put to the end of the function below err_out2 so fp stays valid until smb2_open returns. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Signed-off-by: Akif Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 655d9ce9b1d3db0aa5271acb5e5101c66bd0d58b Author: Wei Fang Date: Wed Apr 15 14:08:33 2026 +0800 net: enetc: fix NTMP DMA use-after-free issue [ Upstream commit 3cade698881eb238f88cbbfec82acc2110440a3f ] The AI-generated review reported a potential DMA use-after-free issue [1]. If netc_xmit_ntmp_cmd() times out and returns an error, the pending command is not explicitly aborted, while ntmp_free_data_mem() unconditionally frees the DMA buffer. If the buffer has already been reallocated elsewhere, this may lead to silent memory corruption. Because the hardware eventually processes the pending command and perform a DMA write of the response to the physical address of the freed buffer. To resolve this issue, this patch does the following modifications: 1. Convert cbdr->ring_lock from a spinlock to a mutex The lock was originally a spinlock in case NTMP operations might be invoked from atomic context. After downstream support for all NTMP tables, no such usage has materialized. A mutex lock is now required because the driver now needs to reclaim used BDs and release associated DMA memory within the lock's context, while dma_free_coherent() might sleep. 2. Introduce software command BD (struct netc_swcbd) The hardware write-back overwrites the addr and len fields of the BD, so the driver cannot rely on the hardware BD to free the associated DMA memory. The driver now maintains a software shadow BD storing the DMA buffer pointer, DMA address, and size. And netc_xmit_ntmp_cmd() only reclaims older BDs when the number of used BDs reaches NETC_CBDR_CLEAN_WORK (16). The software BD enables correct DMA memory release. With this, struct ntmp_dma_buf and ntmp_free_data_mem() are no longer needed and are removed. 3. Require callers to hold ring_lock across netc_xmit_ntmp_cmd() netc_xmit_ntmp_cmd() releases the ring_lock before the caller finishes consuming the response. At this point, if a concurrent thread submits a new command, it may trigger ntmp_clean_cbdr() and free the DMA buffer while it is still in use. Move ring_lock ownership to the caller to ensure the response buffer cannot be reclaimed prematurely. So the helpers ntmp_select_and_lock_cbdr() and ntmp_unlock_cbdr() are added. These changes eliminate the DMA use-after-free condition and ensure safe and consistent BD reclamation and DMA buffer lifecycle management. Fixes: 4701073c3deb ("net: enetc: add initial netc-lib driver to support NTMP") Link: https://lore.kernel.org/netdev/20260403011729.1795413-1-kuba@kernel.org/ # [1] Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260415060833.2303846-3-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 03f8886923d130d66a55f665478e608fa7c6595b Author: Wei Fang Date: Wed Apr 15 14:08:32 2026 +0800 net: enetc: correct the command BD ring consumer index [ Upstream commit 759a32900b6f3db3d0f34a3b61123742723b50b4 ] The command BD ring cousumer index register has the consumer index as the lower 10 bits, and the bit 31 is SBE, which indicates whether a system bus error occurred during execution of the CBD command. So if a system bus error occurs, reading the register will get the SBE bit set. However, the current implementation directly uses the register value as the consumer index without masking it. Therefore, if a system bus error occurs, an incorrect consumer index will be obtained, causing errors in the processing of the command BD ring. Thus, we need to mask out the other bits to obtain the correct consumer index. In addition, this patch adds a check for the SBE bit after the polling loop and returns an error if the bit is set. Fixes: 4701073c3deb ("net: enetc: add initial netc-lib driver to support NTMP") Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260415060833.2303846-2-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit abe91fd045874d21834482adcd7a9693e7377056 Author: Stanislav Fomichev Date: Tue Apr 14 16:10:35 2026 -0700 net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops [ Upstream commit 0f99e0c3e19badaf3fdced0d3feba623e59eed41 ] DSA replaces the conduit (master) device's ethtool_ops with its own wrappers that aggregate stats from both the conduit and DSA switch ports. Taking the lock again inside the DSA wrappers causes a deadlock. Stumbled upon this when booting qemu with fbnic and CONFIG_NET_DSA_LOOP=y (which looks like some kind of testing device that auto-populates the ports of eth0). `ethtool -i` is enough to deadlock. This means we have basically zero coverage for DSA stuff with real ops locked devs. Remove the redundant netdev_lock_ops()/netdev_unlock_ops() calls from the DSA conduit ethtool wrappers. Fixes: 2bcf4772e45a ("net: ethtool: try to protect all callback with netdev instance lock") Signed-off-by: Stanislav Fomichev Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260414231035.1917035-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0e62171df8ed4804d00db088f17eed06468233fa Author: Vinicius Costa Gomes Date: Fri Apr 10 18:57:57 2026 -0700 net/sched: taprio: fix use-after-free in advance_sched() on schedule switch [ Upstream commit 105425b1969c5affe532713cfac1c0b320d7ac2b ] In advance_sched(), when should_change_schedules() returns true, switch_schedules() is called to promote the admin schedule to oper. switch_schedules() queues the old oper schedule for RCU freeing via call_rcu(), but 'next' still points into an entry of the old oper schedule. The subsequent 'next->end_time = end_time' and rcu_assign_pointer(q->current_entry, next) are use-after-free. Fix this by selecting 'next' from the new oper schedule immediately after switch_schedules(), and using its pre-calculated end_time. setup_first_end_time() sets the first entry's end_time to base_time + interval when the schedule is installed, so the value is already correct. The deleted 'end_time = sched_base_time(admin)' assignment was also harmful independently: it would overwrite the new first entry's pre-calculated end_time with just base_time. Fixes: a3d43c0d56f1 ("taprio: Add support adding an admin schedule") Reported-by: Junxi Qian Signed-off-by: Vinicius Costa Gomes Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6908b647aeefea98c443c3df46e8b5e5bc4af909 Author: Lorenzo Bianconi Date: Tue Apr 14 16:08:52 2026 +0200 net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup() [ Upstream commit f3206328bb52c2787197d80d7cbd687946047d5f ] In order to properly enable flowtable hw offloading, poll REG_PPE_FLOW_CFG register in airoha_ppe_offload_setup routine and wait for NPU PPE configuration triggered by ppe_init callback to complete before running airoha_ppe_hw_init(). Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260414-airoha-wait-for-npu-config-offload-setup-v2-1-5a9bf6d43aee@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3b7e850e1541f0520c4a12ec884255c30427ff6 Author: Jiayuan Chen Date: Mon Apr 13 19:45:19 2026 +0800 nexthop: fix IPv6 route referencing IPv4 nexthop [ Upstream commit 29c95185ba32b621fbc3800fb86e7dc3edf5c2be ] syzbot reported a panic [1] [2]. When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag of all groups containing this nexthop is not updated. This is because nh_group_v4_update is only called when replacing AF_INET to AF_INET6, but the reverse direction (AF_INET6 to AF_INET) is missed. This allows a stale has_v4=false to bypass fib6_check_nexthop, causing IPv6 routes to be attached to groups that effectively contain only AF_INET members. Subsequent route lookups then call nexthop_fib6_nh() which returns NULL for the AF_INET member, leading to a NULL pointer dereference. Fix by calling nh_group_v4_update whenever the family changes, not just AF_INET to AF_INET6. Reproducer: # AF_INET6 blackhole ip -6 nexthop add id 1 blackhole # group with has_v4=false ip nexthop add id 100 group 1 # replace with AF_INET (no -6), has_v4 stays false ip nexthop replace id 1 blackhole # pass stale has_v4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1 [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3 Fixes: 7bf4796dd099 ("nexthops: add support for replace") Signed-off-by: Jiayuan Chen Reviewed-by: David Ahern Link: https://patch.msgid.link/20260413114522.147784-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4d8bb13769d513b5bec7abacc09804759c71f27d Author: Dudu Lu Date: Mon Apr 13 19:00:41 2026 +0800 net/sched: sch_cake: fix NAT destination port not being updated in cake_update_flowkeys [ Upstream commit f9e40664706927d7ae22a448a3383e23c38a4c0b ] cake_update_flowkeys() is supposed to update the flow dissector keys with the NAT-translated addresses and ports from conntrack, so that CAKE's per-flow fairness correctly identifies post-NAT flows as belonging to the same connection. For the source port, this works correctly: keys->ports.src = port; But for the destination port, the assignment is reversed: port = keys->ports.dst; This means the NAT destination port is never updated in the flow keys. As a result, when multiple connections are NATed to the same destination, CAKE treats them as separate flows because the original (pre-NAT) destination ports differ. This breaks CAKE's NAT-aware flow isolation when using the "nat" mode. The bug was introduced in commit b0c19ed6088a ("sch_cake: Take advantage of skb->hash where appropriate") which refactored the original direct assignment into a compare-and-conditionally-update pattern, but wrote the destination port update backwards. Fix by reversing the assignment direction to match the source port pattern. Fixes: b0c19ed6088a ("sch_cake: Take advantage of skb->hash where appropriate") Signed-off-by: Dudu Lu Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260413110041.44704-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1c004f14ccdc11585625c168bb9a7c5e1b8afb0c Author: Dudu Lu Date: Mon Apr 13 16:53:49 2026 +0800 macvlan: fix macvlan_get_size() not reserving space for IFLA_MACVLAN_BC_CUTOFF [ Upstream commit fa92a77b0ed4d5f11a71665a232ac5a54a4b055d ] macvlan_get_size() does not account for IFLA_MACVLAN_BC_CUTOFF, but macvlan_fill_info() conditionally includes it when port->bc_cutoff != 1. This causes nla_put_s32() to fail with -EMSGSIZE when the netlink skb runs out of space, triggering a WARN_ON in rtnetlink and preventing the interface from being dumped. The bug can be reproduced with: ip link add macvlan0 link eth0 type macvlan mode bridge ip link set macvlan0 type macvlan bc_cutoff 0 ip -d link show macvlan0 # fails with -EMSGSIZE The bc_cutoff feature was added in commit 954d1fa1ac93 ("macvlan: Add netlink attribute for broadcast cutoff"), which added the nla_put_s32() call in macvlan_fill_info() but missed adding the corresponding nla_total_size(4) in macvlan_get_size(). A follow-up commit 55cef78c244d ("macvlan: add forgotten nla_policy for IFLA_MACVLAN_BC_CUTOFF") fixed the missing nla_policy entry but still did not fix the size calculation. Fixes: 954d1fa1ac93 ("macvlan: Add netlink attribute for broadcast cutoff") Signed-off-by: Dudu Lu Reviewed-by: Vadim Fedorenko Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260413085349.73977-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4764953c4b47585eb72797b216b63a831dc0c7e6 Author: Dudu Lu Date: Mon Apr 13 16:49:27 2026 +0800 net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir [ Upstream commit 4510d140524ca7d6e772db962e013f26f09a63b1 ] In tcf_blockcast_redir(), when iterating block ports to redirect packets to multiple devices, the mac_header_xmit flag is queried from the wrong device. The loop sends to dev_prev but queries dev_is_mac_header_xmit(dev) — which is the NEXT device in the iteration, not the one being sent to. This causes tcf_mirred_to_dev() to make incorrect decisions about whether to push or pull the MAC header. When the block contains mixed device types (e.g., an ethernet veth and a tunnel device), intermediate devices get the wrong mac_header_xmit flag, leading to skb header corruption. In the worst case, skb_push_rcsum with an incorrect mac_len can exhaust headroom and panic. The last device in the loop is handled correctly (line 365-366 uses dev_is_mac_header_xmit(dev_prev)), confirming this is a copy-paste oversight for the intermediate devices. Fix by using dev_prev instead of dev for the mac_header_xmit query, consistent with the device actually being sent to. Fixes: 42f39036cda8 ("net/sched: act_mirred: Allow mirred to block") Signed-off-by: Dudu Lu Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260413084927.71353-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 335244f0c18659d0700b3c078f23939dedbd3acb Author: Uwe Kleine-König Date: Wed Apr 15 16:50:12 2026 +0200 pwm: stm32: Fix rounding issue for requests with inverted polarity [ Upstream commit 5d087c485b6ecf200a9ebb2a032bf8571d330250 ] The calculation of the number of pwm clk ticks from a time length in nanoseconds involves a division and thus some rounding. That might result in duty_ticks + offset_ticks < period_ticks despite duty_length_ns + duty_offset_ns >= period_length_ns . The stm32 PWM cannot configure offset_ticks freely, it can only select 0 or period_length_ns - duty_length_ns---that is the classic normal and inverted polarity. The decision to select the hardware polarity must be done using the ticks values and not the nanoseconds times to adhere to the rounding rules by the pwm core. With the pwm clk running at 208900 kHz on my test machine (stm32mp135f-dk), a test case that was handled wrong is: # pwmround -P 9999962 -O 24970 -D 9974992 period_length = 9999962 duty_length = 9974840 duty_offset = 25123 With this change applied the rounding is done correctly: # pwmround -P 9999962 -O 24970 -D 9974992 period_length = 9999962 duty_length = 9974840 duty_offset = 0 Fixes: deaba9cff809 ("pwm: stm32: Implementation of the waveform callbacks") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/c5e7767cee821b5f6e00f95bd14a5e13015646fb.1776264104.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit f852f55dfed6528fd197528dd5b482e958ac4a2c Author: Gabor Juhos Date: Mon Mar 30 17:25:16 2026 +0200 arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names [ Upstream commit 0fef19844624f8bc07651b4d26088d8940affba3 ] Instead of the generic 'usb2-phy' name, the Armada 37xx device trees are using a custom 'usb2-utmi-otg-phy' name for the USB2 PHY in the USB3 controller node. Since commit 53a2d95df836 ("usb: core: add phy notify connect and disconnect"), this triggers a bug [1] in the USB core which causes double use of the USB3 PHY. Change the PHY name to 'usb2-phy' in the SoC and in the uDPU specific dtsi files in order to avoid triggering the bug and also to keep the names in line with the ones used by other platforms. Link: https://lore.kernel.org/r/20260330-usb-avoid-usb3-phy-double-use-v1-1-d2113aecb535@gmail.com # [1] Fixes: 53a2d95df836 ("usb: core: add phy notify connect and disconnect") Signed-off-by: Gabor Juhos Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit c6852940512c251bc5c9a49ad8d51d1c7c0be098 Author: Peng Fan Date: Sun Mar 29 21:00:13 2026 +0800 arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT [ Upstream commit 42a9f5a16328ed78a88e0498556965b6c6ec515c ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: dfcd1b6f7620e ("arm64: dts: freescale: add initial device tree for TQMa8MQML with i.MX8MM") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit e4a6c7b4bda4e4bb74f174c5d9899676fb05af16 Author: Peng Fan Date: Sun Mar 29 21:00:12 2026 +0800 arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT [ Upstream commit 0fb37990774113afd943eaa91323679388584b6d ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: 3e56e354db6d3 ("arm64: dts: freescale: add initial device tree for TQMa8MQNL with i.MX8MN") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit d12e3db067a47fa60028058761c8b0b65296e33a Author: Peng Fan Date: Sun Mar 29 21:00:11 2026 +0800 arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT [ Upstream commit 721dec3ee9ff5231d13a412ff87df63b966d137b ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. While at here, also correct interrupt type as IRQ_TYPE_LEVEL_LOW. Fixes: cbd3ef64eb9d1 ("arm64: dts: Add support for Emtop SoM & Baseboard") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 463a0885de665d3f36e219c5502584b99fa61c85 Author: Ronald Claveau Date: Tue Mar 31 16:24:04 2026 +0200 reset: amlogic: t7: Fix null reset ops [ Upstream commit 9797524ef2b69c6b187b55bd844eb72a8c1cbd99 ] Fix missing reset ops causing kernel null pointer dereference. This SOC's reset is currently not used yet. Signed-off-by: Ronald Claveau Fixes: fb4c31587adf ("reset: amlogic: add auxiliary reset driver support") Reviewed-by: Philipp Zabel Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 8d4c475852778c293d5d57349a5c61e61a2561a6 Author: René Rebe Date: Wed Nov 26 17:42:56 2025 +0100 PCMCIA: Fix garbled log messages for KERN_CONT [ Upstream commit bfeaa6814bd3f9a1f6d525b3b35a03b9a0368961 ] For years the PCMCIA info messages are messed up by superfluous newlines. While f2e6cf76751d ("pcmcia: Convert dev_printk to dev_") converted the code to pr_cont(), dev_info enforces a \n via vprintk_store setting LOG_NEWLINE, breaking subsequent pr_cont. Fix by logging the device name manually to allow pr_cont to work for more readable and not \n distorted logs. Fixes: f2e6cf76751d ("pcmcia: Convert dev_printk to dev_") Signed-off-by: René Rebe Signed-off-by: Dominik Brodowski Signed-off-by: Sasha Levin commit 95f05e7cd62afd6103b0757eec4cae2189f973e2 Author: Peng Fan Date: Thu Mar 26 15:28:16 2026 +0800 arm64: dts: imx8mp-data-modul-edm-sbc: Correct PAD settings for PMIC_nINT [ Upstream commit 8ff145577e93f312ff398cb950ee3bd44835f5be ] PMIC_nINT is low level triggered, but the current PAD settings is PE=0,PUE=0,FSEL_1_FAST_SLEW_RATE=1,SION=1. So PAD needs to be configured as PULL UP with PULL Enable, no need SION. Correct it. Fixes: 562d222f23f0f ("arm64: dts: imx8mp: Add support for Data Modul i.MX8M Plus eDM SBC") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 91b5057f57973fcf322b71de00ddcdad4b9d5218 Author: Peng Fan Date: Thu Mar 26 15:28:15 2026 +0800 arm64: dts: imx8mp-dhcom-som: Correct PAD settings for PMIC_nINT [ Upstream commit f9ed5afc988da3e22543725e35be6addbb0497bc ] PMIC_nINT is low level triggered, but the current PAD settings is PE=0,PUE=0,FSEL_1_FAST_SLEW_RATE=1,SION=1. So PAD needs to be configured as PULL UP with PULL Enable, no need SION. Correct it. Fixes: 8d6712695bc8e ("arm64: dts: imx8mp: Add support for DH electronics i.MX8M Plus DHCOM and PDK2") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 09574699f6f01f160a0a348a7b7e02aa88e96941 Author: Peng Fan Date: Thu Mar 26 15:28:14 2026 +0800 arm64: dts: imx8mp-ultra-mach-sbc: Correct PAD settings for PMIC_nINT [ Upstream commit daaf41ee72fb5fad936e7051a015cccae9b33937 ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: d1c1400bd3b8b ("arm64: dts: imx8mp: Add initial support for Ultratronik imx8mp-ultra-mach-sbc board") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit b8c355e0c264b81eff3981704cad2939b7ad56b9 Author: Peng Fan Date: Thu Mar 26 15:28:13 2026 +0800 arm64: dts: imx8mp-sr-som: Correct PAD settings for PMIC_nINT [ Upstream commit 695a476275cfb9c798a696aeaa43967701d5c78a ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: a009c0c66ecb4 ("arm64: dts: add description for solidrun imx8mp som and cubox-m") Signed-off-by: Peng Fan Reviewed-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 8df01203a15841fa32ef6e6548ba491d105dae2d Author: Peng Fan Date: Thu Mar 26 15:28:12 2026 +0800 arm64: dts: imx8mp-nitrogen-som: Correct PAD settings for PMIC_nINT [ Upstream commit 16611eda2c7584a1a7d6f80511d825e5108f026c ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: ab4d874c9f44e ("arm64: dts: imx8mp: Add device tree for Nitrogen8M Plus ENC Carrier Board") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit ac63df2f1b0d99ff8b15ecdf6c430a3508b4cf0f Author: Peng Fan Date: Thu Mar 26 15:28:11 2026 +0800 arm64: dts: imx8mp-aristainetos3a-som-v1: Correct PAD settings for PMIC_nINT [ Upstream commit e6d2d8e49ca34bb39126a69128794d08ffd7c83e ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: eead8f3536d5c ("arm64: dts: imx8mp: add aristainetos3 board support") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit a9cf2045b162fe653ed8a251edcdfed4acd5fd5f Author: Peng Fan Date: Thu Mar 26 15:28:10 2026 +0800 arm64: dts: imx8mp-edm-g: Correct PAD settings for PMIC_nINT [ Upstream commit c46c5a54443440ce0f71de9f4df9dd860f5c2afd ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: 95e882c021c8b ("arm64: dts: imx8mp: Add TechNexion EDM-G-IMX8M-PLUS SOM on WB-EDM-G carrier board") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 21c0fe15c279ddb92812e97433bcb7b9ea0e8ab6 Author: Peng Fan Date: Thu Mar 26 15:28:09 2026 +0800 arm64: dts: imx8mp-icore-mx8mp: Correct PAD settings for PMIC_nINT [ Upstream commit ea8c90f5c7ceeb6657a8fe564aa7b190dce298a6 ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there might be interrupt storm for this board. Need to set PAD PUE and PU together to make pull up work properly. Fixes: eefe06b295087 ("arm64: dts: imx8mp: Add Engicam i.Core MX8M Plus SoM") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 1128a3106d5820d8a42af9790ba527354242eb4b Author: Peng Fan Date: Thu Mar 26 15:28:07 2026 +0800 arm64: dts: imx8mp-navqp: Correct PAD settings for PMIC_nINT [ Upstream commit 741d6ac1a2a2e0f3e2cae5eef3516cdd75119e83 ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there will be interrupt storm for i.MX8MP NAVQP. Per schematic, there is no on board PULL-UP resistors for GPIO1_IO03, so need to set PAD PUE and PU together to make pull up work properly. Fixes: 682729a9d506d ("arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit") Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 8ad852195e9c1806f17c8e3a6ef8749d26c4e857 Author: Peng Fan Date: Thu Mar 26 15:28:06 2026 +0800 arm64: dts: imx8mp-debix-som-a: Correct PAD settings for PMIC_nINT [ Upstream commit 2ea7872048a179b0ea8dadc67771961df3f0fc4a ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there is interrupt storm for i.MX8MP DEBIX SOM A. Need to set PAD PUE and PU together to make pull up work properly. Fixes: 21baf0b47f81b ("arm64: dts: freescale: Add DEBIX SOM A and SOM A I/O Board support") Reported-by: Laurent Pinchart Closes: https://lore.kernel.org/all/20260323105858.GA2185714@killaraus.ideasonboard.com/ Reported-by: Kieran Bingham Closes: https://lore.kernel.org/imx/20260324194353.GB2352505@killaraus.ideasonboard.com/T/#m9a07fdc75496369a7d76d52c5e34ed140dcabfe3 Signed-off-by: Peng Fan Reviewed-by: Kieran Bingham Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 8f370cf1fd6091688377a04bb958473a8d562c4d Author: Peng Fan Date: Thu Mar 26 15:28:05 2026 +0800 arm64: dts: imx8mp-debix-model-a: Correct PAD settings for PMIC_nINT [ Upstream commit 3b778178997aee24537b521a8cb60970bc1ce01c ] With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"), there is interrupt storm for i.MX8MP DEBIX Model A. Per schematic, there is no on board PULL-UP resistors for GPIO1_IO03, so need to set PAD PUE and PU together to make pull up work properly. Fixes: c86d350aae68e ("arm64: dts: Add device tree for the Debix Model A Board") Reported-by: Laurent Pinchart Closes: https://lore.kernel.org/all/20260323105858.GA2185714@killaraus.ideasonboard.com/ Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart Signed-off-by: Peng Fan Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit f0f0165039ceb3272fe8b96491a2dd0950c77a59 Author: Jork Loeser Date: Tue Apr 7 18:36:38 2026 -0700 Drivers: hv: vmbus: fix hyperv_cpuhp_online variable shadowing [ Upstream commit 3c42b33433796b73ddecd8f60bda419b1648d997 ] vmbus_alloc_synic_and_connect() declares a local 'int hyperv_cpuhp_online' that shadows the file-scope global of the same name. The cpuhp state returned by cpuhp_setup_state() is stored in the local, leaving the global at 0 (CPUHP_OFFLINE). When hv_kexec_handler() or hv_machine_shutdown() later call cpuhp_remove_state(hyperv_cpuhp_online) they pass 0, which hits the BUG_ON in __cpuhp_remove_state_cpuslocked(). Remove the local declaration so the cpuhp state is stored in the file-scope global where hv_kexec_handler() and hv_machine_shutdown() expect it. Fixes: 2647c96649ba ("Drivers: hv: Support establishing the confidential VMBus connection") Signed-off-by: Jork Loeser Reviewed-by: Stanislav Kinsburskii Reviewed-by: Anirudh Rayabharam (Microsoft) Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 11ba8e8c03962f53ca9049c6a0fe590c9ebbd765 Author: Aditya Garg Date: Thu Apr 9 03:32:18 2026 -0700 tools: hv: Fix cross-compilation [ Upstream commit ca5ee0e918115fb5cf626d75461d9fca06e06caf ] Use the native ARCH only in case it is not set, this will allow the cross-compilation where ARCH is explicitly set. Additionally, simplify the ARCH check to build the fcopy daemon only for x86 and x86_64. Fixes: 82b0945ce2c2 ("tools: hv: Add new fcopy application based on uio driver") Reported-by: Adrian Vladu Closes: https://lore.kernel.org/linux-hyperv/PR3PR09MB54119DB2FD76977C62D8DD6AB04D2@PR3PR09MB5411.eurprd09.prod.outlook.com/ Co-developed-by: Saurabh Sengar Signed-off-by: Saurabh Sengar Signed-off-by: Aditya Garg Reviewed-by: Roman Kisel Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 582b0bf201157632cb5474c885989a6ebda46521 Author: Gao Xiang Date: Mon Apr 20 18:11:42 2026 +0800 erofs: unify lcn as u64 for 32-bit platforms [ Upstream commit 2d8c7edcb661812249469f4a5b62e9339118846f ] As sashiko reported [1], `lcn` was typed as `unsigned long` (or `unsigned int` sometimes), which is only 32 bits wide on 32-bit platforms, which causes `(lcn << lclusterbits)` to be truncated at 4 GiB. In order to consolidate the logic, just use `u64` consistently around the codebase. [1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com Fixes: 152a333a5895 ("staging: erofs: add compacted compression indexes support") Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 64125cfca93792e1df33135536c42a8f8e2f6fb3 Author: Thomas Zimmermann Date: Tue Oct 28 18:07:55 2025 +0100 sh: Include in dac.h [ Upstream commit 57b3ec396dd898aadc073bb16f3d05ee64b2c8af ] Include to avoid depending on for including it. Declares __raw_readb() and __raw_writeb(). Signed-off-by: Thomas Zimmermann Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202510282206.wI0HrqcK-lkp@intel.com/ Fixes: 243ce64b2b37 ("backlight: Do not include in header file") Cc: Thomas Zimmermann Cc: Daniel Thompson (RISCstar) Cc: Simona Vetter Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: dri-devel@lists.freedesktop.org Reviewed-by: John Paul Adrian Glaubitz Reviewed-by: Daniel Thompson (RISCstar) Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: Sasha Levin commit 227c1e1d9e2aa4cfc65ba446d5690da1f546cda4 Author: Paul Moses Date: Wed Apr 1 03:07:49 2026 -0500 crypto: ccp - copy IV using skcipher ivsize [ Upstream commit a7a1f3cdd64d8a165d9b8c9e9ad7fb46ac19dfc4 ] AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver. ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer. Use crypto_skcipher_ivsize() to copy only the algorithm's IV length. Fixes: 2b789435d7f3 ("crypto: ccp - CCP AES crypto API support") Signed-off-by: Paul Moses Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3966cac84a2863c699b29e89ef717c84441f1fe1 Author: T Pratham Date: Wed Apr 15 20:06:58 2026 +0530 crypto: sa2ul - Fix AEAD fallback algorithm names [ Upstream commit 8451ab6ad686ffdcdf9ddadaa446a79ab48e5590 ] For authenc AEAD algorithms, sa2ul is trying to register very specific -ce version as a fallback. This causes registration failure on SoCs which do not have ARMv8-CE enabled/available. Change the fallback algorithm from the specific driver name to generic algorithm name so that the kernel can allocate any available fallback. Fixes: d2c8ac187fc92 ("crypto: sa2ul - Add AEAD algorithm support") Signed-off-by: T Pratham Reviewed-by: Manorit Chawdhry Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ec226d3e58bb9f0e26a77346085b6b4d594d53d8 Author: Aleksander Jan Bajkowski Date: Sat Apr 11 23:08:17 2026 +0200 crypto: eip93 - fix hmac setkey algo selection [ Upstream commit 3ba3b02f897b14e34977e1886d95ffe64d907204 ] eip93_hmac_setkey() allocates a temporary ahash transform for computing HMAC ipad/opad key material. The allocation uses the driver-specific cra_driver_name (e.g. "sha256-eip93") but passes CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms. Since the EIP93 hash algorithms are the only ones registered under those driver names and they are inherently async, the lookup is self-contradictory and always fails with -ENOENT. When called from the AEAD setkey path, this failure leaves the SA record partially initialized with zeroed digest fields. A subsequent crypto operation then dereferences a NULL pointer in the request context, resulting in a kernel panic: ``` pc : eip93_aead_handle_result+0xc8c/0x1240 [crypto_hw_eip93] lr : eip93_aead_handle_result+0xbec/0x1240 [crypto_hw_eip93] sp : ffffffc082feb820 x29: ffffffc082feb820 x28: ffffff8011043980 x27: 0000000000000000 x26: 0000000000000000 x25: ffffffc078da0bc8 x24: 0000000091043980 x23: ffffff8004d59e50 x22: ffffff8004d59410 x21: ffffff8004d593c0 x20: ffffff8004d593c0 x19: ffffff8004d4f300 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000007fda7aa498 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: fffffffff8127a80 x9 : 0000000000000000 x8 : ffffff8004d4f380 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000000009 x2 : 0000000000000008 x1 : 0000000028000003 x0 : ffffff8004d388c0 Code: 910142b6 f94012e0 f9002aa0 f90006d3 (f9400740) ``` The reported symbol eip93_aead_handle_result+0xc8c is a resolution artifact from static functions being merged under the nearest exported symbol. Decoding the faulting sequence: ``` 910142b6 ADD X22, X21, #0x50 f94012e0 LDR X0, [X23, #0x20] f9002aa0 STR X0, [X21, #0x50] f90006d3 STR X19, [X22, #0x8] f9400740 LDR X0, [X26, #0x8] ``` The faulting LDR at [X26, #0x8] is loading ctx->flags (offset 8 in eip93_hash_ctx), where ctx has been resolved to NULL from a partially initialized or unreachable transform context following the failed setkey. Fix this by dropping the CRYPTO_ALG_ASYNC mask from the crypto_alloc_ahash() call. The code already handles async completion correctly via crypto_wait_req(), so there is no requirement to restrict the lookup to synchronous algorithms. Note that hashing a single 64-byte block through the hardware is likely slower than doing it in software due to the DMA round-trip overhead, but offloading it may still spare CPU cycles on the slower embedded cores where this IP is found. Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski [Detailed investigation report of this bug] Signed-off-by: Kenneth Kasilag Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3d84df3364fcd9ab6e6259aa312af6eba5652100 Author: Sami Mujawar Date: Fri Apr 10 17:36:36 2026 +0100 virt: arm-cca-guest: fix error check for RSI_INCOMPLETE [ Upstream commit e534e9d13d0b7bdbb2cccdace7b96b769a10540e ] The RSI interface can return RSI_INCOMPLETE when a report spans multiple granules. This is an expected condition and should not be treated as a fatal error. Currently, arm_cca_report_new() checks for `info.result != RSI_SUCCESS` and bails out, which incorrectly flags RSI_INCOMPLETE as a failure. Fix the check to only break out on results other than RSI_SUCCESS or RSI_INCOMPLETE. This ensures partial reports are handled correctly and avoids spurious -ENXIO errors when generating attestation reports. Fixes: 7999edc484ca ("virt: arm-cca-guest: TSM_REPORT support for realms") Signed-off-by: Sami Mujawar Reported-by: Jagdish Gediya Reviewed-by: Steven Price Reviewed-by: Gavin Shan Reviewed-by: Suzuki K Poulose Reviewed-by: Yeoreum Yun Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 12d4e825369e9ee4d0d72009be97d9eed03b2385 Author: Ville Syrjälä Date: Tue Mar 24 15:48:38 2026 +0200 drm/i915/wm: Verify the correct plane DDB entry [ Upstream commit a97c88a176b6b8d116f4d3f508f3bd02bc77b462 ] Actually verify the DDB entry for the plane we're looking at instead of always verifying the cursor DDB. Fixes: 7d4561722c3b ("drm/i915: Tweak plane ddb allocation tracking") Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260324134843.2364-5-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai (cherry picked from commit f002f7c7439de18117a31ca84dc87a59719c3dd6) Signed-off-by: Tvrtko Ursulin Signed-off-by: Sasha Levin commit ea3ab43a1f3cf2c7cecd75c8be1ee99a5e94a92e Author: Yongpeng Yang Date: Fri Apr 10 23:05:39 2026 +0800 f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show() [ Upstream commit 5909bedbed38c558bee7cb6758ceedf9bc3a9194 ] In f2fs_sbi_show(), the extension_list, extension_count and hot_ext_count are read without holding sbi->sb_lock. If a concurrent sysfs store modifies the extension list via f2fs_update_extension_list(), the show path may read inconsistent count and array contents, potentially leading to out-of-bounds access or displaying stale data. Fix this by holding sb_lock around the entire extension list read and format operation. Fixes: b6a06cbbb5f7 ("f2fs: support hot file extension") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit b7fa4094126c5b2d57cf90702bf083fdbde48bfe Author: Jaegeuk Kim Date: Mon Mar 30 23:40:59 2026 +0000 f2fs: allow empty mount string for Opt_usr|grp|projjquota [ Upstream commit 2a3db1e02ce08c14af04da70bb99e8a0a31eb9e8 ] The fsparam_string_empty() gives an error when mounting without string, since its type is set to fsparam_flag in VFS. So, let's allow the flag as well. This addresses xfstests/f2fs/015 and f2fs/021. Fixes: d18535132523 ("f2fs: separate the options parsing and options checking") Reviewed-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit fa2700ae0efe0c912f05b17fd5f6a5878e67115d Author: Brian Masney Date: Mon Mar 30 10:32:37 2026 -0400 clk: visconti: pll: initialize clk_init_data to zero [ Upstream commit 1603cbb64173a0e9fa7500f2a686f4aa011c58b9 ] Sashiko reported the following: > The struct clk_init_data init is declared on the stack without being > fully zero-initialized. While fields like name, flags, parent_names, > num_parents, and ops are explicitly assigned, the parent_data and > parent_hws fields are left containing stack garbage. clk_core_populate_parent_map() currently prefers the parent names over the parent data and hws, so this isn't a problem at the moment. If that ordering ever changed in the future, then this could lead to some unexpected crashes. Let's just go ahead and make sure that the struct clk_init_data is initialized to zero as a good practice. Fixes: b4cbe606dc367 ("clk: visconti: Add support common clock driver and reset driver") Link: https://sashiko.dev/#/patchset/20260326042317.122536-1-rosenp%40gmail.com Signed-off-by: Brian Masney Reviewed-by: Benoît Monin Reviewed-by: Nobuhiro Iwamatsu Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit bc4cddbe42a194670647482f9702ba85e39f7634 Author: Jagadeesh Kona Date: Fri Mar 27 20:36:46 2026 +0530 clk: qcom: gcc-x1e80100: Keep GCC USB QTB clock always ON [ Upstream commit 05566ebcc0cd170bd4f50c907ee3ed8e106251e3 ] In Hamoa, SMMU invalidation requires the GCC_AGGRE_USB_NOC_AXI_CLK to be on for the USB QTB to be functional. This is currently explicitly enabled by the DWC3 glue driver, so an invalidation happening while the USB controller is suspended will fault. Solve this by voting for the GCC MMU USB QTB clock. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Jagadeesh Kona Reviewed-by: Taniya Das Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260327-hamoa-usb-qtb-clk-always-on-v2-1-7d8a406e650f@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ef08a71c78f28992d9e1f64de6426fce2844845a Author: Srinivasan Shanmugam Date: Mon Mar 30 08:42:29 2026 +0530 drm/amd/display: Fix parameter mismatch in panel self-refresh helper [ Upstream commit f2483b3f39c8e20d2de0cc16e512a1b2aa14baf9 ] Align parameter names with function arguments. The function controls panel self-refresh enable/disable based on vblank and VRR state. Fixes the below with gcc W=1: ../display/amdgpu_dm/amdgpu_dm_crtc.c:131 function parameter 'dm' not described in 'amdgpu_dm_crtc_set_panel_sr_feature' ../display/amdgpu_dm/amdgpu_dm_crtc.c:131 function parameter 'acrtc' not described in 'amdgpu_dm_crtc_set_panel_sr_feature' ../display/amdgpu_dm/amdgpu_dm_crtc.c:131 function parameter 'stream' not described in 'amdgpu_dm_crtc_set_panel_sr_feature' ../display/amdgpu_dm/amdgpu_dm_crtc.c:131 function parameter 'dm' not described in 'amdgpu_dm_crtc_set_panel_sr_feature' ../display/amdgpu_dm/amdgpu_dm_crtc.c:131 function parameter 'acrtc' not described in 'amdgpu_dm_crtc_set_panel_sr_feature' ../display/amdgpu_dm/amdgpu_dm_crtc.c:131 function parameter 'stream' not described in 'amdgpu_dm_crtc_set_panel_sr_feature' Fixes: 754003486c3c ("drm/amd/display: Add Idle state manager(ISM)") Cc: Ray Wu Cc: Leo Li Cc: Roman Li Cc: Alex Hung Cc: Tom Chung Cc: Aurabindo Pillai Cc: Mario Limonciello (AMD) Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 30651a83bdbcf5b7973c8fc071d49efa715b0a30 Author: Pengpeng Hou Date: Wed Apr 1 20:05:52 2026 +0800 scsi: hpsa: Enlarge controller and IRQ name buffers [ Upstream commit 8e8cb6f39930e836144f51cdb6d409c9e4cb71fe ] hpsa formats the controller name into h->devname[8] and derives interrupt names from it in h->intrname[][16]. Once host_no reaches four digits, "hpsa%d" no longer fits in devname, and the derived IRQ names can then overrun the interrupt-name buffers as well. The previous fix switched these builders to bounded formatting, but that would truncate user-visible controller and IRQ names. Keep the existing names intact instead by enlarging the fixed buffers to cover the current formatted strings. Fixes: 2946e82bdd76 ("hpsa: use scsi host_no as hpsa controller number") Fixes: 8b47004a5512 ("hpsa: add interrupt number to /proc/interrupts interrupt name") Acked-by: Don Brace Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260401120552.78541-1-pengpeng@iscas.ac.cn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit af79eb17e03cbaf694d111222b937e4b62d872dc Author: Zhiguo Niu Date: Thu Mar 5 11:22:46 2026 +0800 f2fs: fix to preserve previous reserve_{blocks,node} value when remount [ Upstream commit 01968164d94762db2f703647c5acfa28613844f1 ] The following steps will change previous value of reserve_{blocks,node}, this dones not match the original intention. 1.mount -t f2fs -o reserve_root=8192 imgfile test_mount/ F2FS-fs (loop56): Mounted with checkpoint version = 1b69f8c7 mount info: /dev/block/loop56 on /data/test_mount type f2fs (xxx,reserve_root=8192,reserve_node=0,resuid=0,resgid=0,xxx) 2.mount -t f2fs -o remount,reserve_root=4096 /data/test_mount F2FS-fs (loop56): Preserve previous reserve_root=8192 check mount info: reserve_root change to 4096 /dev/block/loop56 on /data/test_mount type f2fs (xxx,reserve_root=4096,reserve_node=0,resuid=0,resgid=0,xxx) Prior to commit d18535132523 ("f2fs: separate the options parsing and options checking"), the value of reserve_{blocks,node} was only set during the first mount, along with the corresponding mount option F2FS_MOUNT_RESERVE_{ROOT,NODE} . If the mount option F2FS_MOUNT_RESERVE_{ROOT,NODE} was found to have been set during the mount/remount, the previously value of reserve_{blocks,node} would also be preserved, as shown in the code below. if (test_opt(sbi, RESERVE_ROOT)) { f2fs_info(sbi, "Preserve previous reserve_root=%u", F2FS_OPTION(sbi).root_reserved_blocks); } else { F2FS_OPTION(sbi).root_reserved_blocks = arg; set_opt(sbi, RESERVE_ROOT); } But commit d18535132523 ("f2fs: separate the options parsing and options checking") only preserved the previous mount option; it did not preserve the previous value of reserve_{blocks,node}. Since value of reserve_{blocks,node} value is assigned or not depends on ctx->spec_mask, ctx->spec_mask should be alos handled in f2fs_check_opt_consistency. This patch will clear the corresponding ctx->spec_mask bits in f2fs_check_opt_consistency to preserve the previously values of reserve_{blocks,node} if it already have a value. Fixes: d18535132523 ("f2fs: separate the options parsing and options checking") Signed-off-by: Zhiguo Niu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 20cedb4d9f6b230d0ee469690b8f868f06a07c29 Author: Yongpeng Yang Date: Tue Mar 10 17:36:14 2026 +0800 f2fs: fix data loss caused by incorrect use of nat_entry flag [ Upstream commit 238e14eb7226f883b72caccd2d37bf5707df066b ] Data loss can occur when fsync is performed on a newly created file (before any checkpoint has been written) concurrently with a checkpoint operation. The scenario is as follows: create & write & fsync 'file A' write checkpoint - f2fs_do_sync_file // inline inode - f2fs_write_inode // inode folio is dirty - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_flush_nat_entries - f2fs_fsync_node_pages // no dirty node - f2fs_need_inode_block_update // return false SPO and lost 'file A' f2fs_flush_nat_entries() sets the IS_CHECKPOINTED and HAS_LAST_FSYNC flags for the nat_entry, but this does not mean that the checkpoint has actually completed successfully. However, f2fs_need_inode_block_update() checks these flags and incorrectly assumes that the checkpoint has finished. The root cause is that the semantics of IS_CHECKPOINTED and HAS_LAST_FSYNC are only guaranteed after the checkpoint write fully completes. This patch modifies f2fs_need_inode_block_update() to acquire the sbi->node_write lock before reading the nat_entry flags, ensuring that once IS_CHECKPOINTED and HAS_LAST_FSYNC are observed to be set, the checkpoint operation has already completed. Fixes: e05df3b115e7 ("f2fs: add node operations") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 4298f03c3f37c6bf8550df63b5a9e7a1465a6a2e Author: Geert Uytterhoeven Date: Tue Mar 31 17:21:43 2026 +0200 lib/hexdump: print_hex_dump_bytes() calls print_hex_dump_debug() [ Upstream commit 36776b7f8a8955b4e75b5d490a75fee0c7a2a7ef ] print_hex_dump_bytes() claims to be a simple wrapper around print_hex_dump(), but it actally calls print_hex_dump_debug(), which means no output is printed if (dynamic) DEBUG is disabled. Update the documentation to match the implementation. Fixes: 091cb0994edd20d6 ("lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds") Signed-off-by: Geert Uytterhoeven Reviewed-by: Petr Mladek Link: https://patch.msgid.link/3d5c3069fd9102ecaf81d044b750cd613eb72a08.1774970392.git.geert+renesas@glider.be Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit df5ed4b6a2d79ceb523d6b8f4fddc772ad926249 Author: Vladimir Zapolskiy Date: Sat Mar 28 03:26:19 2026 +0200 clk: qcom: gdsc: Fix error path on registration of multiple pm subdomains [ Upstream commit 16ba98dace9e7cfe25ad8a314e34befacd91f86f ] Some pm subdomains may be left in added to a parent domain state, if gdsc_add_subdomain_list() function fails in the middle and bails from a GDSC power domain controller registration out. Fixes: b489235b4dc0 ("clk: qcom: Support attaching GDSCs to multiple parents") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Dmitry Baryshkov Reviewed-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20260328012619.832770-1-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9f32cd529c7b3f3cc71739fb9b5f2e5f2501eab1 Author: John Ogness Date: Thu Mar 26 14:44:01 2026 +0106 printk_ringbuffer: Fix get_data() size sanity check [ Upstream commit 8e81ecbf1cb46b8d2d13e772d5924b09bd60169a ] Commit cc3bad11de6e ("printk_ringbuffer: Fix check of valid data size when blk_lpos overflows") added sanity checking to get_data() to avoid returning data of illegal sizes (too large or too small). It uses the helper function data_check_size() for the check. However, data_check_size() expects the size of the data, not the size of the data block. get_data() is providing the size of the data block. This means that if the data size (text_buf_size) is at or near the maximum legal size: sizeof(prb_data_block) + text_buf_size == DATA_SIZE(data_ring) / 2 data_check_size() will report failure because it adds sizeof(prb_data_block) to the provided size. The sanity check in get_data() is counting the data block header twice. The result is that the reader fails to read the legal record. Since get_data() subtracts the data block header size before returning, move the sanity check to after the subtraction. Luckily printk() is not vulnerable to this problem because truncate_msg() limits printk-messages to 1/4 of the ringbuffer. Indeed, by adjusting the printk_ringbuffer KUnit test, which does not use printk() and its truncate_msg() check, it is easy to see that the reader fails and the WARN_ON is triggered. Fixes: cc3bad11de6e ("printk_ringbuffer: Fix check of valid data size when blk_lpos overflows") Signed-off-by: John Ogness Reviewed-by: Petr Mladek Tested-by: Petr Mladek Link: https://patch.msgid.link/20260326133809.8045-1-john.ogness@linutronix.de Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit b663ebb8a340eae5442e605b6acd2cff5677f016 Author: Jianan Huang Date: Thu Mar 5 09:18:10 2026 +0800 f2fs: avoid reading already updated pages during GC [ Upstream commit 570e2ccc7cb35fe720106964e65060602d3d2ac4 ] We found the following issue during fuzz testing: page: refcount:3 mapcount:0 mapping:00000000b6e89c65 index:0x18b2dc pfn:0x161ba9 memcg:f8ffff800e269c00 aops:f2fs_meta_aops ino:2 flags: 0x52880000000080a9(locked|waiters|uptodate|lru|private|zone=1|kasantag=0x4a) raw: 52880000000080a9 fffffffec6e17588 fffffffec0ccc088 a7ffff8067063618 raw: 000000000018b2dc 0000000000000009 00000003ffffffff f8ffff800e269c00 page dumped because: VM_BUG_ON_FOLIO(folio_test_uptodate(folio)) page_owner tracks the page as allocated post_alloc_hook+0x58c/0x5ec prep_new_page+0x34/0x284 get_page_from_freelist+0x2dcc/0x2e8c __alloc_pages_noprof+0x280/0x76c __folio_alloc_noprof+0x18/0xac __filemap_get_folio+0x6bc/0xdc4 pagecache_get_page+0x3c/0x104 do_garbage_collect+0x5c78/0x77a4 f2fs_gc+0xd74/0x25f0 gc_thread_func+0xb28/0x2930 kthread+0x464/0x5d8 ret_from_fork+0x10/0x20 ------------[ cut here ]------------ kernel BUG at mm/filemap.c:1563! folio_end_read+0x140/0x168 f2fs_finish_read_bio+0x5c4/0xb80 f2fs_read_end_io+0x64c/0x708 bio_endio+0x85c/0x8c0 blk_update_request+0x690/0x127c scsi_end_request+0x9c/0xb8c scsi_io_completion+0xf0/0x250 scsi_finish_command+0x430/0x45c scsi_complete+0x178/0x6d4 blk_mq_complete_request+0xcc/0x104 scsi_done_internal+0x214/0x454 scsi_done+0x24/0x34 which is similar to the problem reported by syzbot: https://syzkaller.appspot.com/bug?extid=3686758660f980b402dc This case is consistent with the description in commit 9bf1a3f ("f2fs: avoid GC causing encrypted file corrupted"): Page 1 is moved from blkaddr A to blkaddr B by move_data_block, and after being written it is marked as uptodate. Then, Page 1 is moved from blkaddr B to blkaddr C, VM_BUG_ON_FOLIO was triggered in the endio initiated by ra_data_block. There is no need to read Page 1 again from blkaddr B, since it has already been updated. Therefore, avoid initiating I/O in this case. Fixes: 6aa58d8ad20a ("f2fs: readahead encrypted block during GC") Signed-off-by: Jianan Huang Signed-off-by: Sheng Yong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 16dfbc4e95c46dd9c79cb8d550c7f267d4a79b91 Author: Shuwei Wu Date: Thu Mar 5 20:46:08 2026 +0800 clk: spacemit: ccu_mix: fix inverted condition in ccu_mix_trigger_fc() [ Upstream commit 54e97360b44bed6b4399dd3be3d65f392df940fa ] Fix inverted condition that skips frequency change trigger, causing kernel panics during cpufreq scaling. Fixes: 1b72c59db0ad ("clk: spacemit: Add clock support for SpacemiT K1 SoC") Signed-off-by: Shuwei Wu Reviewed-by: Yixun Lan Link: https://lore.kernel.org/r/20260305-k1-clk-fix-v1-1-abca85d6e266@mailbox.org Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit ac7892f7fc1875d20ea684a992127054419a46e1 Author: Geert Uytterhoeven Date: Thu Mar 5 11:11:16 2026 +0100 clk: xgene: Fix mapping leak in xgene_pllclk_init() [ Upstream commit f520a492e07bc6718e26cfb7543ab4cadd8bb0e2 ] If xgene_register_clk_pll() fails, the mapped register block is never unmapped. Fixes: 308964caeebc45eb ("clk: Add APM X-Gene SoC clock driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit aa03143de7d03be4cf392cbe2c85eabed964dee2 Author: Arnd Bergmann Date: Fri Mar 20 16:18:49 2026 +0100 clk: qoriq: avoid format string warning [ Upstream commit 096abbb6682ee031a0f5ce9f4c71ead9fa63d31e ] clang-22 warns about the use of non-variadic format arguments passed into snprintf(): drivers/clk/clk-qoriq.c:925:39: error: diagnostic behavior may be improved by adding the 'format(printf, 7, 8)' attribute to the declaration of 'create_mux_common' [-Werror,-Wmissing-format-attribute] 910 | static struct clk * __init create_mux_common(struct clockgen *cg, | __attribute__((format(printf, 7, 8))) 911 | struct mux_hwclock *hwc, 912 | const struct clk_ops *ops, 913 | unsigned long min_rate, 914 | unsigned long max_rate, 915 | unsigned long pct80_rate, 916 | const char *fmt, int idx) 917 | { 918 | struct clk_init_data init = {}; 919 | struct clk *clk; 920 | const struct clockgen_pll_div *div; 921 | const char *parent_names[NUM_MUX_PARENTS]; 922 | char name[32]; 923 | int i, j; 924 | 925 | snprintf(name, sizeof(name), fmt, idx); | ^ drivers/clk/clk-qoriq.c:910:28: note: 'create_mux_common' declared here 910 | static struct clk * __init create_mux_common(struct clockgen *cg, Rework this to pass the 'int idx' as a varargs argument, allowing the format string to be verified at the caller location. Fixes: 0dfc86b3173f ("clk: qoriq: Move chip-specific knowledge into driver") Signed-off-by: Arnd Bergmann Reviewed-by: Kees Cook Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 618fff07c9efbd3e0299dfd6210f2f785837f8f9 Author: Thomas Weißschuh Date: Wed Mar 18 22:03:26 2026 +0100 x86/um: fix vDSO installation [ Upstream commit d1895c15fc7d90a615bc8c455feb02acaf08ef1e ] The generic vDSO installation logic used by 'make vdso_install' requires that $(vdso-install-y) is defined by the top-level architecture Makefile and that it contains a path relative to the root of the tree. For UML neither of these is satisfied. Move the definition of $(vdso-install-y) to a place which is included by the arch/um/Makefile and use the full relative path. Fixes: f1c2bb8b9964 ("um: implement a x86_64 vDSO") Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20260318-um-vdso-install-v1-1-26a4ca5c4210@weissschuh.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f21c343ec7419377bff89ab11146c03ae117036f Author: Tiwei Bie Date: Tue Mar 3 07:52:23 2026 +0800 um: Fix potential race condition in TLB sync [ Upstream commit 102331b66bcaf1f41f50b9c4cd5c36e46bafa9f3 ] During the TLB sync, we need to traverse and modify the page table, so we should hold the page table lock. Since full SMP support for threads within the same process is still missing, let's disable the split page table lock for simplicity. Fixes: 1e4ee5135d81 ("um: Add initial SMP support") Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20260302235224.1915380-2-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2efc59de4016a76c87ff90b2457864e0d809e80d Author: Sebastian Krzyszkowiak Date: Wed Jan 28 00:47:21 2026 +0100 clk: imx8mq: Correct the CSI PHY sels [ Upstream commit d16f57caa78776e6e8a88b96cb2597797b376138 ] According to i.MX 8M Quad Reference Manual (Section 5.1.2 Table 5-1) MIPI_CSI1_PHY_REF_CLK_ROOT and MIPI_CSI2_PHY_REF_CLK_ROOT have SYSTEM_PLL2_DIV3 available as their second source, which corresponds to sys2_pll_333m rather than sys2_pll_125m. Fixes: b80522040cd3 ("clk: imx: Add clock driver for i.MX8MQ CCM") Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260128-imx8mq-csi-clk-v1-1-ac028ed26e8c@puri.sm Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit d0b026d2c68cc8c9c0e4b316bcb7788a544cdef8 Author: Felix Gu Date: Tue Feb 3 22:07:58 2026 +0800 clk: imx: imx6q: Fix device node reference leak in of_assigned_ldb_sels() [ Upstream commit 9faf207208951460f3f7eefbc112246c8d28ff1b ] The function of_assigned_ldb_sels() calls of_parse_phandle_with_args() but never calls of_node_put() to release the reference, causing a memory leak. Fix this by adding proper cleanup calls on all exit paths. Fixes: 5d283b083800 ("clk: imx6: Fix procedure to switch the parent of LDB_DI_CLK") Signed-off-by: Felix Gu Reviewed-by: Frank Li Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260203-clk-imx6q-v3-2-6cd2696bb371@gmail.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 431188220169eca60172fa80fa4476557b1bbbe0 Author: Felix Gu Date: Tue Feb 3 22:07:57 2026 +0800 clk: imx: imx6q: Fix device node reference leak in pll6_bypassed() [ Upstream commit 4b84d496c804b470124cd3a08e928df6801d8eae ] The function pll6_bypassed() calls of_parse_phandle_with_args() but never calls of_node_put() to release the reference, causing a memory leak. Fix this by adding proper cleanup calls on all exit paths. Fixes: 3cc48976e9763 ("clk: imx6q: handle ENET PLL bypass") Signed-off-by: Felix Gu Reviewed-by: Frank Li Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260203-clk-imx6q-v3-1-6cd2696bb371@gmail.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit d4a4c8ad06ce89b38ceb4127d8bc7934fa0c42fb Author: Val Packett Date: Thu Mar 12 08:12:13 2026 -0300 clk: qcom: dispcc-sm8250: Enable parents for pixel clocks [ Upstream commit acf7a91d0b0e9e3ef374944021de62062125b7e4 ] Add CLK_OPS_PARENT_ENABLE to MDSS pixel clock sources to ensure parent clocks are enabled during clock operations, preventing potential stability issues during display configuration. Fixes: 80a18f4a8567 ("clk: qcom: Add display clock controller driver for SM8150 and SM8250") Signed-off-by: Val Packett Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260312112321.370983-9-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2f290e765b4cb373e086dd46a6e66b7d651a395d Author: Val Packett Date: Thu Mar 12 08:12:12 2026 -0300 clk: qcom: dispcc-sm8250: Use shared ops on the mdss vsync clk [ Upstream commit 8c522da70f0c2e5148c4c13ccb1c64cca57a6fdb ] mdss_gdsc can get stuck on boot due to RCGs being left on from last boot. As a fix, commit 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") introduced a callback to ensure the RCG is off upon init. However, the fix depends on all shared RCGs being marked as such in code. For SM8150/SC8180X/SM8250 the MDSS vsync clock was using regular ops, unlike the same clock in the SC7180 code. This was causing display to frequently fail to initialize after rebooting on the Surface Pro X. Fix by using shared ops for this clock. Fixes: 80a18f4a8567 ("clk: qcom: Add display clock controller driver for SM8150 and SM8250") Signed-off-by: Val Packett Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260312112321.370983-8-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 00770de15ab837fb40b2a1e6e0f4def9eb572768 Author: Val Packett Date: Thu Mar 12 08:12:09 2026 -0300 clk: qcom: gcc-sc8180x: Use retention for PCIe power domains [ Upstream commit ccb92c78b42edd26225b4d5920847dfee3e1b093 ] As the PCIe host controller driver does not yet support dealing with the loss of state during suspend, use retention for relevant GDSCs. This fixes the link not surviving upon resume: nvme 0002:01:00.0: Unable to change power state from D3cold to D0, device inaccessible nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS read failed (134) nvme 0002:01:00.0: Unable to change power state from D3cold to D0, device inaccessible nvme nvme0: Disabling device after reset failure: -19 Fixes: 4433594bbe5d ("clk: qcom: gcc: Add global clock controller driver for SC8180x") Reviewed-by: Dmitry Baryshkov Signed-off-by: Val Packett Reviewed-by: Konrad Dybcio Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20260312112321.370983-5-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8c3282dbd3adba31bdb0ca5344504e82943bcfd3 Author: Val Packett Date: Thu Mar 12 08:12:08 2026 -0300 clk: qcom: gcc-sc8180x: Use retention for USB power domains [ Upstream commit 25bc96f26cd6c19dde13a0b9859183e531d6fbfc ] The USB subsystem does not expect to lose its state on suspend: xhci-hcd xhci-hcd.0.auto: xHC error in resume, USBSTS 0x401, Reinit usb usb1: root hub lost power or was reset (The reinitialization usually succeeds, but it does slow down resume.) To maintain state during suspend, the relevant GDSCs need to stay in retention mode, like they do on other similar SoCs. Change the mode to PWRSTS_RET_ON to fix. Fixes: 4433594bbe5d ("clk: qcom: gcc: Add global clock controller driver for SC8180x") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Val Packett Link: https://lore.kernel.org/r/20260312112321.370983-4-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 978887830d151aae6a5775799ceab961efb5171d Author: Val Packett Date: Thu Mar 12 08:12:07 2026 -0300 clk: qcom: gcc-sc8180x: Add missing GDSCs [ Upstream commit 3565741eb985a8a7cc6656eb33496195468cb99e ] There are 5 more GDSCs that we were ignoring and not putting to sleep, which are listed in downstream DTS. Add them. Fixes: 4433594bbe5d ("clk: qcom: gcc: Add global clock controller driver for SC8180x") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Val Packett Link: https://lore.kernel.org/r/20260312112321.370983-3-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7b8b06dc71691d3c434d9c5b4cf9074d316e8f3f Author: Val Packett Date: Thu Mar 12 08:12:06 2026 -0300 dt-bindings: clock: qcom,gcc-sc8180x: Add missing GDSCs [ Upstream commit 76404ffbf07f28a5ec04748e18fce3dac2e78ef6 ] There are 5 more GDSCs that we were ignoring and not putting to sleep, which are listed in downstream DTS. Add them. Signed-off-by: Val Packett Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260312112321.370983-2-val@packett.cool Signed-off-by: Bjorn Andersson Stable-dep-of: 3565741eb985 ("clk: qcom: gcc-sc8180x: Add missing GDSCs") Signed-off-by: Sasha Levin commit 84e491954e4eac11117aec94f2df63b72931508b Author: Shawn Lin Date: Fri Mar 13 10:21:07 2026 +0800 scsi: ufs: rockchip,rk3576-ufshc: dt-bindings: Add new mphy reset item [ Upstream commit bdce3a69c578090dd5e3c77bcdaaca10c3a41e34 ] Add the mphy reset property to the devicetree bindings for the Rockchip RK3576 UFS host controller. The mphy reset signal is used to reset the physical adapter. Resetting other components while leaving the mphy unreset may occasionally prevent the UFS controller from successfully linking up with the device. This addresses an intermittent hardware bug where the UFS link fails to establish under specific timing conditions with certain chips. While difficult to reproduce initially, this issue was consistently observed in downstream testing and requires explicit mphy reset control for full stability. Although this change increases the maxItems for resets and adds a new entry (which technically alters the binding ABI), it does not break compatibility for existing Linux systems. The driver uses devm_reset_control_array_get_exclusive() to manage resets, allowing it to function correctly with both older Device Trees (without the mphy entry) and newer ones. Fixes: d90e92023771 ("scsi: ufs: dt-bindings: Document Rockchip UFS host controller") Signed-off-by: Shawn Lin Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/1773368467-109650-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 02115986d027ade793e7f6be87e91d6a796d0aa3 Author: Junrui Luo Date: Wed Mar 4 23:42:58 2026 +0800 scsi: target: core: Fix integer overflow in UNMAP bounds check [ Upstream commit 2bf2d65f76697820dbc4227d13866293576dd90a ] sbc_execute_unmap() checks LBA + range does not exceed the device capacity, but does not guard against LBA + range wrapping around on 64-bit overflow. Add an overflow check matching the pattern already used for WRITE_SAME in the same file. Fixes: 86d7182985d2 ("target: Add sbc_execute_unmap() helper") Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB7881593C61AD52C69FBDB0BDAF7CA@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ca8db750b5ba008842d3b7a4185f316c49e51a71 Author: Nilesh Javali Date: Thu Mar 5 15:03:37 2026 +0530 scsi: qla2xxx: Add support to report MPI FW state [ Upstream commit 0e124af675ebabddacfeb0958abd443265dddf13 ] MPI firmware state was returned as 0. Get MPI FW state to proceed with flash image validation. A new sysfs node 'mpi_fw_state' is added to report MPI firmware state: /sys/class/scsi_host/hostXX/mpi_fw_state Fixes: d74181ca110e ("scsi: qla2xxx: Add bsg interface to support firmware img validation") Signed-off-by: Nilesh Javali Link: https://patch.msgid.link/20260305093337.2007205-1-njavali@marvell.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 45e9bfc718f9a6a91ba2349d5e744282402e0376 Author: Fabrizio Castro Date: Tue Feb 3 12:42:47 2026 +0000 clk: renesas: r9a09g057: Remove entries for WDT{0,2,3} [ Upstream commit 1b4f047dc4010d51821694cc4ed73b52b3040a5c ] The HW user manual for the Renesas RZ/V2H(P) SoC specifies that only the WDT1 IP is supposed to be used by Linux, while the WDT{0,2,3} IPs are supposed to be used by the CM33 and CR8 cores. Remove the clock and reset entries for WDT{0,2,3} to prevent interfering with the CM33 and CR8 cores. This change is harmless as only WDT1 is used by Linux, there are no users for the WDT{0,2,3} cores. Fixes: 3aeccbe08171 ("clk: renesas: r9a09g057: Add clock and reset entries for GTM/RIIC/SDHI/WDT") Signed-off-by: Fabrizio Castro Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260203124247.7320-4-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit f051c4e21148832a1a6931fa5f4a54be4b1f805d Author: Konrad Dybcio Date: Wed Mar 4 14:48:31 2026 +0100 clk: qcom: dispcc[01]-sa8775p: Fix DSI byte clock rate setting [ Upstream commit 2851b6c6a42e22c243aa4cd606a49e2b9acfb6d6 ] The clock tree for byte_clk_src is as follows: ┌──────byte0_clk_src─────┐ │ │ byte0_clk byte0_div_clk_src │ byte0_intf_clk If both of its direct children have CLK_SET_RATE_PARENT with different requests, byte0_clk_src (and its parent) will be reconfigured. In this case, byte0_intf should strictly follow the rate of byte0_clk (with some adjustments based on PHY mode). Remove CLK_SET_RATE_PARENT from byte0_div_clk_src to avoid this issue. Fixes: e700bfd2f976 ("clk: qcom: Add support for Display clock Controllers on SA8775P") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-topic-dsi_byte_fixup-v1-5-b79b29f83176@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cad73e383a60600a96919fd79f7d04b749596209 Author: Konrad Dybcio Date: Wed Mar 4 14:48:30 2026 +0100 clk: qcom: dispcc-sm4450: Fix DSI byte clock rate setting [ Upstream commit 7bc48fcdf9e77bf68ef04af015d50df2a9acac00 ] The clock tree for byte_clk_src is as follows: ┌──────byte0_clk_src─────┐ │ │ byte0_clk byte0_div_clk_src │ byte0_intf_clk If both of its direct children have CLK_SET_RATE_PARENT with different requests, byte0_clk_src (and its parent) will be reconfigured. In this case, byte0_intf should strictly follow the rate of byte0_clk (with some adjustments based on PHY mode). Remove CLK_SET_RATE_PARENT from byte0_div_clk_src to avoid this issue. Fixes: 76f05f1ec766 ("clk: qcom: Add DISPCC driver support for SM4450") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-topic-dsi_byte_fixup-v1-4-b79b29f83176@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c58577bde5fefae8f69e455fa1c0de9440ad2f30 Author: Konrad Dybcio Date: Wed Mar 4 14:48:29 2026 +0100 clk: qcom: dispcc-milos: Fix DSI byte clock rate setting [ Upstream commit dd5b76257b4048151006620c9895e2f5f0d997eb ] The clock tree for byte_clk_src is as follows: ┌──────byte0_clk_src─────┐ │ │ byte0_clk byte0_div_clk_src │ byte0_intf_clk If both of its direct children have CLK_SET_RATE_PARENT with different requests, byte0_clk_src (and its parent) will be reconfigured. In this case, byte0_intf should strictly follow the rate of byte0_clk (with some adjustments based on PHY mode). Remove CLK_SET_RATE_PARENT from byte0_div_clk_src to avoid this issue. Fixes: f40b5217dce1 ("clk: qcom: Add Display Clock controller (DISPCC) driver for Milos") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-topic-dsi_byte_fixup-v1-3-b79b29f83176@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit df2271beedf480b810f052d6febb47d484b338ca Author: Konrad Dybcio Date: Wed Mar 4 14:48:28 2026 +0100 clk: qcom: dispcc-kaanapali: Fix DSI byte clock rate setting [ Upstream commit e892f4e3f3d558ce5d7595dca7cce2bd170a19fa ] The clock tree for byte_clk_src is as follows: ┌──────byte0_clk_src─────┐ │ │ byte0_clk byte0_div_clk_src │ byte0_intf_clk If both of its direct children have CLK_SET_RATE_PARENT with different requests, byte0_clk_src (and its parent) will be reconfigured. In this case, byte0_intf should strictly follow the rate of byte0_clk (with some adjustments based on PHY mode). Remove CLK_SET_RATE_PARENT from byte0_div_clk_src to avoid this issue. Fixes: 6c6750b7061c ("clk: qcom: dispcc: Add support for display clock controller Kaanapali") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-topic-dsi_byte_fixup-v1-2-b79b29f83176@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9d549e12427ff57ec30b664cb6d485f1e2ad8e4a Author: Konrad Dybcio Date: Wed Mar 4 14:48:27 2026 +0100 clk: qcom: dispcc-glymur: Fix DSI byte clock rate setting [ Upstream commit 98ea9eda030587601db56425efcd32263d853591 ] The clock tree for byte_clk_src is as follows: ┌──────byte0_clk_src─────┐ │ │ byte0_clk byte0_div_clk_src │ byte0_intf_clk If both of its direct children have CLK_SET_RATE_PARENT with different requests, byte0_clk_src (and its parent) will be reconfigured. In this case, byte0_intf should strictly follow the rate of byte0_clk (with some adjustments based on PHY mode). Remove CLK_SET_RATE_PARENT from byte0_div_clk_src to avoid this issue. Fixes: b4d15211c408 ("clk: qcom: dispcc-glymur: Add support for Display Clock Controller") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-topic-dsi_byte_fixup-v1-1-b79b29f83176@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 23f0cacfa3d12fdb633d9284a957c6548556a326 Author: White Lewis Date: Tue Mar 3 19:55:50 2026 +0800 clk: qcom: dispcc-sc8280xp: remove CLK_SET_RATE_PARENT from byte_div_clk_src dividers [ Upstream commit 0b151a6307205eb867250985a910a88787cbf12e ] The four byte_div_clk_src dividers (disp{0,1}_cc_mdss_byte{0,1}_div_clk_src) had CLK_SET_RATE_PARENT set. When the DSI driver calls clk_set_rate() on byte_intf_clk, the rate-change propagates through the divider up to the parent PLL (byte_clk_src), halving the byte clock rate. A simiar issue had been also encountered on SM8750. b8501febdc51 ("clk: qcom: dispcc-sm8750: Drop incorrect CLK_SET_RATE_PARENT on byte intf parent"). Likewise, remove CLK_SET_RATE_PARENT from all four byte divider clocks so that clk_set_rate() on the divider adjusts only the divider ratio, leaving the parent PLL untouched. Fixes: 4a66e76fdb6d ("clk: qcom: Add SC8280XP display clock controller") Signed-off-by: White Lewis [pengyu: reword] Signed-off-by: Pengyu Luo Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260303115550.9279-1-mitltlatltl@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit feade299e932967de27519338d41de348fb5b061 Author: Yang Erkun Date: Tue Jan 27 14:20:43 2026 +0800 scsi: sg: Resolve soft lockup issue when opening /dev/sgX [ Upstream commit d06a310b45e153872033dd0cf19d5a2279121099 ] The parameter def_reserved_size defines the default buffer size reserved for each Sg_fd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sg_proc_write_dressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup: echo -1 > /sys/module/sg/parameters/def_reserved_size exec 4<> /dev/sg0 watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace: sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7e The fix is to use module_param_cb to validate and reject invalid values assigned to def_reserved_size. Fixes: 6460e75a104d ("[SCSI] sg: fixes for large page_size") Signed-off-by: Yang Erkun Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260127062044.3034148-3-yangerkun@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b8b7c63b04f718a4befb28df951c8f382071be5e Author: Yang Erkun Date: Tue Jan 27 14:20:42 2026 +0800 scsi: sg: Fix sysctl sg-big-buff register during sg_init() [ Upstream commit 3033c471aaf675254efaa0da431e95d91a104b41 ] Commit 26d1c80fd61e ("scsi/sg: move sg-big-buff sysctl to scsi/sg.c") made a mistake. sysctl sg-big-buff was not created because the call to register_sg_sysctls() was placed on the wrong code path. Fixes: 26d1c80fd61e ("scsi/sg: move sg-big-buff sysctl to scsi/sg.c") Signed-off-by: Yang Erkun Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260127062044.3034148-2-yangerkun@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7e0ef25b3785535ee31c2284b27c1b8f612ad2b8 Author: Chen-Yu Tsai Date: Tue Feb 17 17:30:03 2026 +0800 clk: sunxi-ng: sun55i-a523-r: Add missing r-spi module clock [ Upstream commit fb20ccf70cf695f178d7c32e2d33b376560df0ff ] When the PRCM clk driver was added, somehow the r-spi module clock was skipped over. Add it so that r-spi can actually work. Fixes: 8cea339cfb81 ("clk: sunxi-ng: add support for the A523/T527 PRCM CCU") Reviewed-by: Andre Przywara Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260217093004.3239051-1-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit acc4e8974e4b50849728631586d88002d634b065 Author: Ovidiu Panait Date: Sun Jan 25 19:27:01 2026 +0000 clk: renesas: r9a09g056: Fix ordering of module clocks array [ Upstream commit dc71d92f0d36dcb68fcf0ef126131a2dedef9393 ] The r9a09g056_mod_clks array is sorted by CPG_CLKON register number and bit position. Move the RSPI 0/1/2 module clock entries to their correct position to restore the array sort order. Fixes: 1f76689d1715 ("clk: renesas: r9a09g056: Add entries for RSCIs") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260125192706.27099-2-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 358a3072d87e87e8e2610ac2c540181abfb4d56f Author: Ovidiu Panait Date: Sun Jan 25 19:03:14 2026 +0000 clk: renesas: r9a09g057: Fix ordering of module clocks array [ Upstream commit 79cac2b8dc1d9f63fbf6c6793e423052118cc51a ] The r9a09g057_mod_clks array is sorted by CPG_CLKON register number and bit position. Move the RTC and RSPI module clock entries to their correct position to restore the array sort order. Fixes: 2efea3b35cc9 ("clk: renesas: r9a09g057: Add entries for RSCIs") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260125190314.26729-1-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit a219c2bb86a50ffbf6e571dcc81bb0bc3b9917a4 Author: Dmitry Baryshkov Date: Mon Jan 12 04:12:23 2026 +0200 clk: qcom: dispcc-sm8450: use RCG2 ops for DPTX1 AUX clock source [ Upstream commit 141af1be817c42c7f1e1605348d4b1983d319bea ] The clk_dp_ops are supposed to be used for DP-related clocks with a proper MND divier. Use standard RCG2 ops for dptx1_aux_clk_src, the same as all other DPTX AUX clocks in this driver. Fixes: 16fb89f92ec4 ("clk: qcom: Add support for Display Clock Controller on SM8450") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20260112-dp-aux-clks-v1-2-456b0c11b069@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b3ebf69f9b9fabfff2e108d09285040a22370c51 Author: Dmitry Baryshkov Date: Mon Jan 12 04:12:22 2026 +0200 clk: qcom: dispcc-glymur: use RCG2 ops for DPTX1 AUX clock source [ Upstream commit e7c8eb1646db5d967d77ee67793dd95a2c5ff451 ] The clk_dp_ops are supposed to be used for DP-related clocks with a proper MND divier. Use shared RCG2 ops for dptx1_aux_clk_src, the same as all other DPTX AUX clocks in this driver. Fixes: b4d15211c408 ("clk: qcom: dispcc-glymur: Add support for Display Clock Controller") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20260112-dp-aux-clks-v1-1-456b0c11b069@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5733376ef751a3327068034f0cf6e8369d929e25 Author: Taniya Das Date: Mon Feb 2 16:26:52 2026 +0530 clk: qcom: gcc-glymur: Add video axi clock resets for glymur [ Upstream commit 1c8ce43e1e07ecc531fb517f95620ed85e998608 ] The global clock controller video axi reset clocks are required by the video SW driver to assert and deassert the clock resets during their power down sequence. Hence add these clock resets. Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller") Signed-off-by: Taniya Das Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260202-glymur_videocc-v2-3-8f7d8b4d8edd@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f4d361fb2ca9a3a5403405e8847dc2d938f69352 Author: Taniya Das Date: Mon Feb 2 16:26:50 2026 +0530 dt-bindings: clock: qcom: Add GCC video axi reset clock for Glymur [ Upstream commit 7c3260327fc874b7c89d7bb230cd569d2e78aff7 ] The global clock controller video axi reset clocks are required by the video SW driver to assert and deassert the clock resets. Signed-off-by: Taniya Das Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260202-glymur_videocc-v2-1-8f7d8b4d8edd@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 1c8ce43e1e07 ("clk: qcom: gcc-glymur: Add video axi clock resets for glymur") Signed-off-by: Sasha Levin commit ec3113afa28a604e8e914046c4db939885252601 Author: Krishna Chomal Date: Sat Apr 11 00:40:36 2026 +0530 platform/x86: hp-wmi: fix fan table parsing [ Upstream commit 9d317a54e46d3b6420567dc5b63e9d7ff5c064a3 ] For Victus S devices, the BIOS fan table header was being incorrectly parsed as: struct { u8 unknown; u8 num_entries; } The first field should be num_fans and the second should be unknown. It is pure coincidence that interpreting an "unknown" field as "num_entries" worked on multiple device, however for board 8D87 (in an upcoming patch), this assumption fails, and the hp-wmi driver fails to load. We fix this by correcting the header definition and compensating for num_entries by parsing each entry of the fan table until an all-NULL row is obtained, mirroring the behavior of OMEN Gaming Hub on Windows. Fixes: 46be1453e6e6 ("platform/x86: hp-wmi: add manual fan control for Victus S models") Signed-off-by: Krishna Chomal Link: https://patch.msgid.link/20260410191039.125659-2-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit c26a0052cceed4c4d380ee5808b699f937fb58d8 Author: Florian Westphal Date: Mon Mar 30 14:27:39 2026 +0200 RDMA/core: Prefer NLA_NUL_STRING [ Upstream commit 6ed3d14fc45d3da6025e7fe4a6a09066856698e2 ] These attributes are evaluated as c-string (passed to strcmp), but NLA_STRING doesn't check for the presence of a \0 terminator. Either this needs to switch to nla_strcmp() and needs to adjust printf fmt specifier to not use plain %s, or this needs to use NLA_NUL_STRING. As the code has been this way for long time, it seems to me that userspace does include the terminating nul, even tough its not enforced so far, and thus NLA_NUL_STRING use is the simpler solution. Fixes: 30dc5e63d6a5 ("RDMA/core: Add support for iWARP Port Mapper user space service") Link: https://patch.msgid.link/r/20260330122742.13315-1-fw@strlen.de Signed-off-by: Florian Westphal Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 90b118d264845f7aaf539ac49f7c75f1f29590e2 Author: Pengpeng Hou Date: Wed Apr 8 08:38:21 2026 +0800 platform/x86: dell-wmi-sysman: bound enumeration string aggregation [ Upstream commit 3c34471c26abc52a37f5ad90949e2e4b8027eb14 ] populate_enum_data() aggregates firmware-provided value-modifier and possible-value strings into fixed 512-byte struct members. The current code bounds each individual source string but then appends every string and separator with raw strcat() and no remaining-space check. Switch the aggregation loops to a bounded append helper and reject enumeration packages whose combined strings do not fit in the destination buffers. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260408084501.1-dell-wmi-sysman-v2-pengpeng@iscas.ac.cn [ij: add include] Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit da58e08d400bc0e1bc5d68369576deec6b3be546 Author: Fedor Pchelkin Date: Fri Apr 3 16:42:39 2026 +0300 platform/x86: dell_rbu: avoid uninit value usage in packet_size_write() [ Upstream commit f8fd138c2363c0e2d3235c32bfb4fb5c6474e4ae ] Ensure the temp value has been properly parsed from the user-provided buffer and initialized to be used in later operations. While at it, prefer a convenient kstrtoul() helper. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: ad6ce87e5bd4 ("[PATCH] dell_rbu: changes in packet update mechanism") Signed-off-by: Fedor Pchelkin Link: https://patch.msgid.link/20260403134240.604837-1-pchelkin@ispras.ru [ij: add include] Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 9e2eae9fe8aa148e1192a2c786e335fdb360d4da Author: Emre Cecanpunar Date: Tue Apr 7 17:25:14 2026 +0300 platform/x86: hp-wmi: add locking for concurrent hwmon access [ Upstream commit 5969c55e2145368254194edbe0e64880314be69f ] hp_wmi_hwmon_priv.mode and .pwm are written by hp_wmi_hwmon_write() in sysfs context and read by hp_wmi_hwmon_keep_alive_handler() in a workqueue. A concurrent write and keep-alive expiry can observe an inconsistent mode/pwm pair (e.g. mode=MANUAL with a stale pwm). Add a mutex to hp_wmi_hwmon_priv protecting mode and pwm. Hold it in hp_wmi_hwmon_write() across the field update and apply call, and in hp_wmi_hwmon_keep_alive_handler() before calling apply. In hp_wmi_hwmon_read(), only the pwm_enable path reads priv->mode; use scoped_guard() there to avoid holding the lock across unrelated WMI calls. Fixes: c203c59fb5de ("platform/x86: hp-wmi: implement fan keep-alive") Suggested-by: Ilpo Järvinen Signed-off-by: Emre Cecanpunar Link: https://patch.msgid.link/20260407142515.20683-6-emreleno@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit e9fca2b196e5f63d185c618896b71bf3c139b1f9 Author: Emre Cecanpunar Date: Tue Apr 7 17:25:13 2026 +0300 platform/x86: hp-wmi: fix u8 underflow in gpu_delta calculation [ Upstream commit cb4daa450f05447c1f914eaef75b2577c25a0fcd ] gpu_delta was declared as u8. If the firmware specifies a GPU RPM lower than the CPU RPM, subtracting them causes an underflow (e.g. 10 - 20 = 246), which forces the GPU fan to remain clamped at U8_MAX (100% speed) during operation. Change gpu_delta to int and use signed arithmetic. Existing signed logic in hp_wmi_fan_speed_set() correctly handles negative deltas. Fixes: 46be1453e6e6 ("platform/x86: hp-wmi: add manual fan control for Victus S models") Suggested-by: Ilpo Järvinen Signed-off-by: Emre Cecanpunar Link: https://patch.msgid.link/20260407142515.20683-5-emreleno@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 03b75fb11ae312dcd54647f75cbe83f093b7fbde Author: Emre Cecanpunar Date: Tue Apr 7 17:25:12 2026 +0300 platform/x86: hp-wmi: use mod_delayed_work to reset keep-alive timer [ Upstream commit 6297443beb0c5606399ec7d4f4b335e2e7379147 ] Currently, schedule_delayed_work() is used to queue the 90s keep-alive timer. If a user manually changes the fan speed at T=85s, schedule_delayed_work() leaves the existing timer in place as it is a no-op if the work is already pending. This results in the keep-alive timer firing unnecessarily at T=90s, just 5 seconds after the user action. Replace schedule_delayed_work() with mod_delayed_work() to reset the 90s timer whenever fan settings are applied. This guarantees a full 90s delay after every user interaction, preventing redundant keep-alive executions and improving efficiency. Fixes: c203c59fb5de ("platform/x86: hp-wmi: implement fan keep-alive") Signed-off-by: Emre Cecanpunar Link: https://patch.msgid.link/20260407142515.20683-4-emreleno@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit c5b100269b14a4d60f0b3398861bc72610b53e9d Author: Emre Cecanpunar Date: Tue Apr 7 17:25:11 2026 +0300 platform/x86: hp-wmi: avoid cancel_delayed_work_sync from work handler [ Upstream commit 249ddba9c0ba4453c0a6bc0e3626e7864751d940 ] hp_wmi_apply_fan_settings() uses cancel_delayed_work_sync() to stop the keep-alive timer in AUTO mode. However, since hp_wmi_apply_fan_settings() is also called from the keep-alive handler, a race condition with a sysfs write can cause the handler to wait on itself, leading to a deadlock. Replace cancel_delayed_work_sync() with cancel_delayed_work() in hp_wmi_apply_fan_settings() to avoid the self-flush deadlock. Fixes: c203c59fb5de ("platform/x86: hp-wmi: implement fan keep-alive") Signed-off-by: Emre Cecanpunar Link: https://patch.msgid.link/20260407142515.20683-3-emreleno@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 9e635acb4b7d55587d21ff2efa34f4c41b3f373a Author: Emre Cecanpunar Date: Tue Apr 7 17:25:10 2026 +0300 platform/x86: hp-wmi: fix ignored return values in fan settings [ Upstream commit 7265b57fbc32782d02bdb8d865ba0d8efa209c8c ] hp_wmi_get_fan_count_userdefine_trigger() can fail, but its return value was silently ignored in hp_wmi_apply_fan_settings() for PWM_MODE_MAX/AUTO. Propagate these errors consistently. Additionally, handle the return value of hp_wmi_apply_fan_settings() in its callers by adding appropriate warnings on failure, and remove an unreachable "return 0" at the end of the function. Fixes: 46be1453e6e6 ("platform/x86: hp-wmi: add manual fan control for Victus S models") Signed-off-by: Emre Cecanpunar Link: https://patch.msgid.link/20260407142515.20683-2-emreleno@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 5cd0707b81cb4589f00aec5c4c1288bd0980d2a4 Author: Pengpeng Hou Date: Fri Mar 27 14:19:55 2026 +0800 fs/ntfs3: terminate the cached volume label after UTF-8 conversion [ Upstream commit a6cd43fe9b083fa23fe1595666d5738856cb261a ] ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only returns the number of bytes written and does not add a trailing NUL. If the converted label fills the entire fixed buffer, ntfs3_label_show() can read past the end of sbi->volume.label while looking for a terminator. Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer. Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Pengpeng Hou Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 8684216c7d1d3fe27eb1c339e36706646be485b1 Author: Thomas Bogendoerfer Date: Thu Apr 2 12:21:53 2026 +0200 tty: serial: ip22zilog: Fix section mispatch warning [ Upstream commit a1a81aef99e853dec84241d701fbf587d713eb5b ] ip22zilog_prepare() is now called by driver probe routine, so it shouldn't be in the __init section any longer. Fixes: 3fc36ae6abd2 ("tty: serial: ip22zilog: Use platform device for probing") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604020945.c9jAvCPs-lkp@intel.com/ Signed-off-by: Thomas Bogendoerfer Link: https://patch.msgid.link/20260402102154.136620-1-tbogendoerfer@suse.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8d4335d4a6a937fbb72dced464fbbec9f5409140 Author: Denis Benato Date: Mon Mar 2 18:44:31 2026 +0100 platform/x86: asus-wmi: fix screenpad brightness range [ Upstream commit 8d95d1f4aa5c76202b0833a70998769384612488 ] Fix screenpad brightness range being too limited without reason: testing this patch on a Zenbook Duo showed the hardware minimum not being too low, therefore allow the user to configure the entire range, and expose to userspace the hardware brightness range and value. Fixes: 2c97d3e55b70 ("platform/x86: asus-wmi: add support for ASUS screenpad") Signed-off-by: Denis Benato Signed-off-by: Luke Jones Link: https://patch.msgid.link/20260302174431.349816-3-denis.benato@linux.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 6a773c5ed16f49e5d56ba4e84c061c181f37b007 Author: Denis Benato Date: Mon Mar 2 18:44:30 2026 +0100 platform/x86: asus-wmi: adjust screenpad power/brightness handling [ Upstream commit 130d29c5627cd50e786e926ad7ef66322c5a0c09 ] Fix illogical screen off control by hardcoding 0 and 1 depending on the requested brightness and also do not rely on the last screenpad power state to issue screen brightness commands. Fixes: 2c97d3e55b70 ("platform/x86: asus-wmi: add support for ASUS screenpad") Signed-off-by: Denis Benato Signed-off-by: Luke Jones Link: https://patch.msgid.link/20260302174431.349816-2-denis.benato@linux.dev Link: https://patch.msgid.link/20260326231154.856729-2-ethantidmore06@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 48d6c32bc049abd114e8f0836c0e7d7cbfba7827 Author: Damien Riégel Date: Tue Mar 24 10:00:39 2026 -0400 greybus: raw: fix use-after-free if write is called after disconnect [ Upstream commit 84265cbd96b97058ef67e3f8be3933667a000835 ] If a user writes to the chardev after disconnect has been called, the kernel panics with the following trace (with CONFIG_INIT_ON_FREE_DEFAULT_ON=y): BUG: kernel NULL pointer dereference, address: 0000000000000218 ... Call Trace: gb_operation_create_common+0x61/0x180 gb_operation_create_flags+0x28/0xa0 gb_operation_sync_timeout+0x6f/0x100 raw_write+0x7b/0xc7 [gb_raw] vfs_write+0xcf/0x420 ? task_mm_cid_work+0x136/0x220 ksys_write+0x63/0xe0 do_syscall_64+0xa4/0x290 entry_SYSCALL_64_after_hwframe+0x77/0x7f Disconnect calls gb_connection_destroy, which ends up freeing the connection object. When gb_operation_sync is called in the write file operations, its gets a freed connection as parameter and the kernel panics. The gb_connection_destroy cannot be moved out of the disconnect function, as the Greybus subsystem expect all connections belonging to a bundle to be destroyed when disconnect returns. To prevent this bug, use a rw lock to synchronize access between write and disconnect. This guarantees that the write function doesn't try to use a disconnected connection. Fixes: e806c7fb8e9b ("greybus: raw: add raw greybus kernel driver") Reviewed-by: Johan Hovold Signed-off-by: Damien Riégel Link: https://patch.msgid.link/20260324140039.40001-2-damien.riegel@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ef2d97c15b19b3489de01695bce478601e236c3e Author: Damien Riégel Date: Tue Mar 24 10:00:38 2026 -0400 greybus: raw: fix use-after-free on cdev close [ Upstream commit 983cc2c7efbce04ecbf6328448d895044dd6ab31 ] This addresses a use-after-free bug when a raw bundle is disconnected but its chardev is still opened by an application. When the application releases the cdev, it causes the following panic when init on free is enabled (CONFIG_INIT_ON_FREE_DEFAULT_ON=y): refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 139 at lib/refcount.c:28 refcount_warn_saturate+0xd0/0x130 ... Call Trace: cdev_put+0x18/0x30 __fput+0x255/0x2a0 __x64_sys_close+0x3d/0x80 do_syscall_64+0xa4/0x290 entry_SYSCALL_64_after_hwframe+0x77/0x7f The cdev is contained in the "gb_raw" structure, which is freed in the disconnect operation. When the cdev is released at a later time, cdev_put gets an address that points to freed memory. To fix this use-after-free, convert the struct device from a pointer to being embedded, that makes the lifetime of the cdev and of this device the same. Then, use cdev_device_add, which guarantees that the device won't be released until all references to the cdev have been released. Finally, delegate the freeing of the structure to the device release function, instead of freeing immediately in the disconnect callback. Fixes: e806c7fb8e9b ("greybus: raw: add raw greybus kernel driver") Reviewed-by: Johan Hovold Signed-off-by: Damien Riégel Link: https://patch.msgid.link/20260324140039.40001-1-damien.riegel@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 04ea87df71e4cb0716cbfa40bcdcb21252701aa0 Author: Leon Romanovsky Date: Mon Mar 23 22:10:18 2026 +0200 RDMA/umem: Use consistent DMA attributes when unmapping entries [ Upstream commit 179b32095854d44749dd535502f05d95bbf43775 ] The DMA API expects that mapping and unmapping use the same DMA attributes. The RDMA umem code did not meet this requirement, so fix the mismatch. Fixes: f03d9fadfe13 ("RDMA/core: Add weak ordering dma attr to dma mapping") Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d2b29f3fc007dccd12e4536b703bf369a2164c2a Author: Chuck Lever Date: Tue Feb 24 12:10:34 2026 -0500 nfsd: use dynamic allocation for oversized NFSv4.0 replay cache [ Upstream commit 116b6b7acdd82605ed530232cd7509d1b5282f5c ] Commit 1e8e9913672a ("nfsd: fix heap overflow in NFSv4.0 LOCK replay cache") capped the replay cache copy at NFSD4_REPLAY_ISIZE to prevent a heap overflow, but set rp_buflen to zero when the encoded response exceeded the inline buffer. A retransmitted LOCK reaching the replay path then produced only a status code with no operation body, resulting in a malformed XDR response. When the encoded response exceeds the 112-byte inline rp_ibuf, a buffer is kmalloc'd to hold it. If the allocation fails, rp_buflen remains zero, preserving the behavior from the capped-copy fix. The buffer is freed when the stateowner is released or when a subsequent operation's response fits in the inline buffer. Fixes: 1e8e9913672a ("nfsd: fix heap overflow in NFSv4.0 LOCK replay cache") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit b81572b073441dfd32213e41857676d0dbff4665 Author: Dai Ngo Date: Wed Feb 4 13:07:43 2026 -0800 NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg [ Upstream commit b48f44f36e6607b2f818560f19deb86b4a9c717b ] In nfsd4_add_rdaccess_to_wrdeleg, if fp->fi_fds[O_RDONLY] is already set by another thread, __nfs4_file_get_access should not be called to increment the nfs4_file access count since that was already done by the thread that added READ access to the file. The extra fi_access count in nfs4_file can prevent the corresponding nfsd_file from being freed. When stopping nfs-server service, these extra access counts trigger a BUG in kmem_cache_destroy() that shows nfsd_file object remaining on __kmem_cache_shutdown. This problem can be reproduced by running the Git project's test suite over NFS. Fixes: 8072e34e1387 ("nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()") Signed-off-by: Dai Ngo Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit ead0bd92d88d2483cd7ac8418cf8979861616fbb Author: Andy Shevchenko Date: Wed Feb 4 21:21:51 2026 +0100 sunrpc: Fix compilation error (`make W=1`) when dprintk() is no-op [ Upstream commit 6f57293abb8d087de830dd3f02e66d94b3e59973 ] Clang compiler is not happy about set but unused variables: .../flexfilelayout/flexfilelayoutdev.c:56:9: error: variable 'ret' set but not used [-Werror,-Wunused-but-set-variable] .../flexfilelayout/flexfilelayout.c:1505:6: error: variable 'err' set but not used [-Werror,-Wunused-but-set-variable] .../nfs4proc.c:9244:12: error: variable 'ptr' set but not used [-Werror,-Wunused-but-set-variable] Fix these by forwarding parameters of dprintk() to no_printk(). The positive side-effect is a format-string checker enabled even for the cases when dprintk() is no-op. Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Fixes: fc931582c260 ("nfs41: create_session operation") Acked-by: Geert Uytterhoeven Reviewed-by: Jeff Layton Signed-off-by: Andy Shevchenko Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit b9f53c25cd1c729968bedd930c6f894c4bf193e2 Author: Andy Shevchenko Date: Wed Feb 4 21:21:50 2026 +0100 sunrpc: Kill RPC_IFDEBUG() [ Upstream commit adcc59114ccd402259c089b0fea24da5e4974563 ] RPC_IFDEBUG() is used in only two places. In one the user of the definition is guarded by ifdeffery, in the second one it's implied due to dprintk() usage. Kill the macro and move the ifdeffery to the regular condition with the variable defined inside, while in the second case add the same conditional and move the respective code there. Reviewed-by: Jeff Layton Signed-off-by: Andy Shevchenko Signed-off-by: Chuck Lever Stable-dep-of: 6f57293abb8d ("sunrpc: Fix compilation error (`make W=1`) when dprintk() is no-op") Signed-off-by: Sasha Levin commit 27afd939adc01d8ed6e684dd8d0e888d97493954 Author: Andy Shevchenko Date: Wed Feb 4 21:21:49 2026 +0100 nfs/blocklayout: Fix compilation error (`make W=1`) in bl_write_pagelist() [ Upstream commit f83c8dda456ce4863f346aa26d88efa276eda35d ] Clang compiler is not happy about set but unused variable (when dprintk() is no-op): .../blocklayout/blocklayout.c:384:9: error: variable 'count' set but not used [-Werror,-Wunused-but-set-variable] Remove a leftover from the previous cleanup. Fixes: 3a6fd1f004fc ("pnfs/blocklayout: remove read-modify-write handling in bl_write_pagelist") Acked-by: Anna Schumaker Reviewed-by: Jeff Layton Signed-off-by: Andy Shevchenko Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit a92648b23427c42f60bc0271ff64beecc8997ee7 Author: Abdun Nihaal Date: Tue Jan 20 15:56:20 2026 +0530 mfd: mc13xxx-core: Fix memory leak in mc13xxx_add_subdevice_pdata() [ Upstream commit a5a65a7fb2f7796bbe492cd6be59c92cb64377d1 ] The memory allocated for cell.name using kmemdup() is not freed when mfd_add_devices() fails. Fix that by using devm_kmemdup(). Fixes: 8e00593557c3 ("mfd: Add mc13892 support to mc13xxx") Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260120102622.66921-1-nihaal@cse.iitm.ac.in Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2b4ae1ce613ade8a7e118fba4a5a77cd23e97e54 Author: Deepanshu Kartikey Date: Thu Mar 19 13:15:46 2026 +0530 fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked() [ Upstream commit d7ea8495fd307b58f8867acd81a1b40075b1d3ba ] When a compressed or sparse attribute has its clusters frame-aligned, vcn is rounded down to the frame start using cmask, which can result in vcn != vcn0. In this case, vcn and vcn0 may reside in different attribute segments. The code already handles the case where vcn is in a different segment by loading its runs before allocation. However, it fails to load runs for vcn0 when vcn0 resides in a different segment than vcn. This causes run_lookup_entry() to return SPARSE_LCN for vcn0 since its segment was never loaded into the in-memory run list, triggering the WARN_ON(1). Fix this by adding a missing check for vcn0 after the existing vcn segment check. If vcn0 falls outside the current segment range [svcn, evcn1), find and load the attribute segment containing vcn0 before performing the run lookup. The following scenario triggers the bug: attr_data_get_block_locked() vcn = vcn0 & cmask <- vcn != vcn0 after frame alignment load runs for vcn segment <- vcn0 segment not loaded! attr_allocate_clusters() <- allocation succeeds run_lookup_entry(vcn0) <- vcn0 not in run -> SPARSE_LCN WARN_ON(1) <- bug fires here! Reported-by: syzbot+c1e9aedbd913fadad617@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c1e9aedbd913fadad617 Fixes: c380b52f6c57 ("fs/ntfs3: Change new sparse cluster processing") Signed-off-by: Deepanshu Kartikey Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 17c3b8d10e7fb0ce9850eddcb0d193f8f44e37bf Author: Dmitry Torokhov Date: Wed Mar 18 19:56:17 2026 -0700 platform/x86: barco-p50-gpio: normalize return value of gpio_get [ Upstream commit 1c9d30d37aaffe3454d70b89a77f8aaecda257bf ] The GPIO get callback is expected to return 0 or 1 (or a negative error code). Ensure that the value returned by p50_gpio_get() is normalized to the [0, 1] range. Fixes: 86ef402d805d606a ("gpiolib: sanitize the return value of gpio_chip::get()") Reviewed-by: Linus Walleij Signed-off-by: Dmitry Torokhov Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260318-barco-p50-gpio-set-v2-1-c0a4a6416163@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit d7cea1f6e575e7082ed0947308076e8866dcdfde Author: Rafael J. Wysocki Date: Fri Mar 20 11:31:54 2026 +0100 platform/x86: panasonic-laptop: Fix OPTD notifier registration and cleanup [ Upstream commit 8baeff2c1d33dad8572216c6ad3a7425852507d4 ] An ACPI notify handler is leaked if device_create_file() returns an error in acpi_pcc_hotkey_add(). Also, it is pointless to call pcc_unregister_optd_notifier() in acpi_pcc_hotkey_remove() if pcc->platform is NULL and it is better to arrange the cleanup code in that function in the same order as the rollback code in acpi_pcc_hotkey_add(). Address the above by placing the pcc_register_optd_notifier() call in acpi_pcc_hotkey_add() after the device_create_file() return value check and placing the pcc_unregister_optd_notifier() call in acpi_pcc_hotkey_remove() right before the device_remove_file() call. Fixes: d5a81d8e864b ("platform/x86: panasonic-laptop: Add support for optical driver power in Y and W series") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2411055.ElGaqSPkdT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit c404d0ac0cb085cb7077ba32c334cc4042feb81a Author: Mostafa Saleh Date: Fri Mar 13 15:55:34 2026 +0000 usb: typec: ps883x: Fix Oops at unbind [ Upstream commit 381133848a033c2086cf9cafb226f425bd0414ff ] When trying to unbind a device in order to bind to it vfio-platform as: echo bc0000.geniqup > /sys/bus/platform/devices/bc0000.geniqup/driver/unbind I get the following Oops: [ 436.478639] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 [ 436.487762] Mem abort info: [ 436.490716] ESR = 0x0000000096000004 [ 436.494595] EC = 0x25: DABT (current EL), IL = 32 bits [ 436.500071] SET = 0, FnV = 0 [ 436.503250] EA = 0, S1PTW = 0 [ 436.506505] FSC = 0x04: level 0 translation fault [ 436.511533] Data abort info: [ 436.514558] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 436.520215] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 436.525436] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 436.530918] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008861a9000 [ 436.537554] [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 [ 436.544548] Internal error: Oops: 0000000096000004 [#1] SMP [ 436.550374] Modules linked in: [ 436.553542] CPU: 2 UID: 0 PID: 671 Comm: bash Tainted: G W 7.0.0-rc3-g56fcdd0911a5-dirty #2 PREEMPT [ 436.564440] Tainted: [W]=WARN [ 436.567515] Hardware name: LENOVO 91B6CTO1WW/3796, BIOS O6NKT3BA 05/02/2025 [ 436.574675] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 436.581841] pc : ps883x_retimer_remove+0x14/0x94 [ 436.586605] lr : i2c_device_remove+0x28/0x84 [ 436.591017] sp : ffff8000847137c0 That's because the ps883x_retimer_remove() retrieves the driver data from i2c_get_clientdata() which was never set at probe. So, add i2c_set_clientdata() at the end of the probe. Signed-off-by: Mostafa Saleh Reviewed-by: Konrad Dybcio Fixes: 257a087c8b52 ("usb: typec: Add support for Parade PS8830 Type-C Retimer") Link: https://patch.msgid.link/20260313155534.1916773-1-smostafa@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f1dc8e72de9aabe5d96767a4e97219ac26b79fe5 Author: Randy Dunlap Date: Thu Jan 29 23:29:37 2026 -0800 tty: hvc_iucv: fix off-by-one in number of supported devices [ Upstream commit f2a880e802ad12d1e38039d1334fb1475d0f5241 ] MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8. This is the number of entries in: static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES]; Sometimes hvc_iucv_table[] is limited by: (a) if (num > hvc_iucv_devices) // for error detection or (b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places (so these 2 don't agree; second one appears to be correct to me.) hvc_iucv_devices can be 0..8. This is a counter. (c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES) If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8]. Oops. Fixes: 44a01d5ba8a4 ("[S390] s390/hvc_console: z/VM IUCV hypervisor console support") Signed-off-by: Randy Dunlap Link: https://patch.msgid.link/20260130072939.1535869-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9e31082f92c913d74fefb4e60cd0284e605ba3a3 Author: Ethan Tidmore Date: Wed Feb 18 15:46:21 2026 -0600 usb: typec: Fix error pointer dereference [ Upstream commit f2529d08fcb429ea01bb87c326342f41483f8b2f ] The variable tps->partner is checked for an error pointer and then if it is, it sends an error message but does not return and then immediately dereferenced a few lines below: tps->partner = typec_register_partner(tps->port, &desc); if (IS_ERR(tps->partner)) dev_warn(tps->dev, "%s: failed to register partnet\n", __func__); if (desc.identity) { typec_partner_set_identity(tps->partner); cd321x->cur_partner_identity = st.partner_identity; } Add early return and fix spelling mistake in error message. Detected by Smatch: drivers/usb/typec/tipd/core.c:827 cd321x_update_work() error: 'tps->partner' dereferencing possible ERR_PTR() Fixes: 82432bbfb9e83 ("usb: typec: tipd: Handle mode transitions for CD321x") Signed-off-by: Ethan Tidmore Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260218214621.38154-1-ethantidmore06@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0d01f0bb995bba8bdd127955b1398d2237d943b5 Author: Chen Ni Date: Thu Feb 26 11:30:48 2026 +0800 leds: lgm-sso: Remove duplicate assignments for priv->mmap [ Upstream commit 7186d0330c3f3e86de577687a82f4ebd96dcb5ac ] Remove duplicate assignment of priv->mmap in intel_sso_led_probe(). Fixes: fba8a6f2263b ("leds: lgm-sso: Fix clock handling") Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260226033048.3715915-1-nichen@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit b2b7c48f66100d139857922090b8c33978cb9f76 Author: Rafael J. Wysocki Date: Wed Mar 4 19:54:08 2026 +0100 platform/surface: surfacepro3_button: Drop wakeup source on remove [ Upstream commit 1410a228ab2d36fe2b383415a632ae12048d4f3a ] The wakeup source added by device_init_wakeup() in surface_button_add() needs to be dropped during driver removal, so update the driver to do that. Fixes: 19351f340765 ("platform/x86: surfacepro3: Support for wakeup from suspend-to-idle") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/4368848.1IzOArtZ34@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit e57aa71ee38ba7d56a17e54f7dfb8f2397a52620 Author: Chen Ni Date: Tue Feb 3 10:16:25 2026 +0800 backlight: sky81452-backlight: Check return value of devm_gpiod_get_optional() in sky81452_bl_parse_dt() [ Upstream commit 797cc011ae02bda26f93d25a4442d7a1a77d84df ] The devm_gpiod_get_optional() function may return an ERR_PTR in case of genuine GPIO acquisition errors, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the call in sky81452_bl_parse_dt(). On error, return the error code to ensure proper failure handling rather than proceeding with invalid pointers. Fixes: e1915eec54a6 ("backlight: sky81452: Convert to GPIO descriptors") Signed-off-by: Chen Ni Reviewed-by: Linus Walleij Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260203021625.578678-1-nichen@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 485f750cac3d8bdf5552a0e3d79ce5e3a03ece49 Author: Edward Adam Davis Date: Mon Feb 23 16:01:13 2026 +0800 fs/ntfs3: prevent uninitialized lcn caused by zero len [ Upstream commit e98266e823a1fa06fe6499df61aeaac2fd6f7a49 ] syzbot reported a uninit-value in ntfs_iomap_begin [1]. Since runs was not touched yet, run_lookup_entry() immediately fails and returns false, which makes the value of "*len" 0. Simultaneously, the new value and err value are also 0, causing the logic in attr_data_get_block_locked() to jump directly to ok, ultimately resulting in *lcn being triggered before it is set [1]. In ntfs_iomap_begin(), the check for a 0 value in clen is moved forward to before updating lcn to avoid this [1]. [1] BUG: KMSAN: uninit-value in ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110 Local variable lcn created at: ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c:786 Fixes: 10d7c95af043 ("fs/ntfs3: add delayed-allocation (delalloc) support") Reported-by: syzbot+7be88937363ac7ab7bb0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7be88937363ac7ab7bb0 Tested-by: syzbot+7be88937363ac7ab7bb0@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 6410624c4256cd1c46aa15f476a1e500178ea9af Author: Billy Tsai Date: Tue Apr 7 16:53:23 2026 +0800 i3c: mipi-i3c-hci: fix IBI payload length calculation for final status [ Upstream commit d35a6db887eeae7c57b719521e39d64f929c6dc3 ] In DMA mode, the IBI status descriptor encodes the payload using CHUNKS (number of chunks) and DATA_LENGTH (valid bytes in the last chunk). All preceding chunks are implicitly full-sized. The current code accumulates full chunk sizes for non-final status descriptors, but for the final status descriptor it only adds DATA_LENGTH. This ignores the contribution of the preceding full chunks described by the same final status entry. As a result, the computed IBI payload length is truncated whenever the final status spans multiple chunks. For example, with a chunk size of 4 bytes, CHUNKS=2 and DATA_LENGTH=1 should result in a total payload size of 5 bytes, but the current code reports only 1 byte. Fix the calculation by adding the size of (CHUNKS - 1) full chunks plus DATA_LENGTH for the last chunk. Fixes: 9ad9a52cce28 ("i3c/master: introduce the mipi-i3c-hci driver") Signed-off-by: Billy Tsai Reviewed-by: Frank Li Link: https://patch.msgid.link/20260407-i3c-hci-dma-v2-1-a583187b9d22@aspeedtech.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 98da14e092894ac436d059298b42ca858ecbf131 Author: Jorge Marques Date: Mon Mar 23 17:11:33 2026 +0100 i3c: master: adi: Fix error propagation for CCCs [ Upstream commit 0b73da96b6eb6b9354654f96a9d423ab22cb222d ] adi_i3c_master_send_ccc_cmd() always returned 0, ignoring the transfer result populated in the completion path. As a consequence, CCC command errors were silently dropped, including the default -ETIMEDOUT and later overwritten by adi_i3c_master_end_xfer_locked(). Fix this by returning xfer->ret so that callers correctly receive any transfer error codes. Fixes: a79ac2cdc91d ("i3c: master: Add driver for Analog Devices I3C Controller IP") Reviewed-by: Adrian Hunter Reviewed-by: Frank Li Signed-off-by: Jorge Marques Link: https://patch.msgid.link/20260323-ad4062-positive-error-fix-v3-5-30bdc68004be@analog.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit ba5b3bdb8fb2e574d8cddb243ddd77615c89bb89 Author: Felix Gu Date: Sat Apr 4 18:32:30 2026 +0800 i3c: dw: Fix memory leak in dw_i3c_master_i3c_xfers() [ Upstream commit 256cc1f1305a8e5dcadf8ca208d04a3acadd26f1 ] The dw_i3c_master_i3c_xfers() function allocates memory for the xfer structure using dw_i3c_master_alloc_xfer(). If pm_runtime_resume_and_get() fails, the function returns without freeing the allocated xfer, resulting in a memory leak. Since dw_i3c_master_free_xfer() is a thin wrapper around kfree(), use the __free(kfree) cleanup attribute to handle the free automatically on all exit paths. Fixes: 62fe9d06f570 ("i3c: dw: Add power management support") Signed-off-by: Felix Gu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260404-dw-i3c-2-v3-1-8f7d146549c1@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit ab8f00ffcca0f618fb8198d358f24728950d9860 Author: Felix Gu Date: Mon Apr 6 20:43:16 2026 +0800 i3c: master: renesas: Fix memory leak in renesas_i3c_i3c_xfers() [ Upstream commit d7665c3b4f575251e449e2656879392346ca612b ] The xfer structure allocated by renesas_i3c_alloc_xfer() was never freed in the renesas_i3c_i3c_xfers() function. Use the __free(kfree) cleanup attribute to automatically free the memory when the variable goes out of scope. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Tested-by: Tommaso Merciai Reviewed-by: Tommaso Merciai Reviewed-by: Frank Li Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260406-renesas-v3-1-4b724d7708f4@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 346a93e5bacae9de934a6597fc69d1b071989175 Author: Felix Gu Date: Sat Mar 21 17:04:43 2026 +0800 i3c: master: dw-i3c: Balance PM runtime usage count on probe failure [ Upstream commit 19d6dd322c3f05550606dbfcbafb5f6989975c02 ] When DW_I3C_DISABLE_RUNTIME_PM_QUIRK is set, the probe function calls pm_runtime_get_noresume() to prevent runtime suspend. However, if i3c_master_register() fails, the error path does not balance this call, leaving the usage count incremented. Add pm_runtime_put_noidle() in the error cleanup path to properly balance the usage count. Fixes: fba0e56ee752 ("i3c: dw: Disable runtime PM on Agilex5 to avoid bus hang on IBI") Signed-off-by: Felix Gu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260321-dw-i3c-1-v1-1-821623aac7bb@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 66e886fd8351ef2a35c3cc1678052e3ec6f795d6 Author: Felix Gu Date: Fri Mar 20 22:18:02 2026 +0800 i3c: master: dw-i3c: Fix missing reset assertion in remove() callback [ Upstream commit bef1eef667186cedb0bc6d152464acb3c97d5f72 ] The reset line acquired during probe is currently left deasserted when the driver is unbound. Switch to devm_reset_control_get_optional_exclusive_deasserted() to ensure the reset is automatically re-asserted by the devres core when the driver is removed. Fixes: 62fe9d06f570 ("i3c: dw: Add power management support") Reviewed-by: Philipp Zabel Signed-off-by: Felix Gu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260320-dw-i3c-v3-1-477040c2e3f5@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 61677075ab07c6ca03d406479e7eaf8312cf78aa Author: Arnaldo Carvalho de Melo Date: Wed Apr 8 14:31:57 2026 -0300 perf util: Kill die() prototype, dead for a long time [ Upstream commit e5cce1b9c82fbd48e2f1f7a25a9fad8ee228176f ] In fef2a735167a827a ("perf tools: Kill die()") the die() function was removed, but not the prototype in util.h, now when building with LIBPERL=1, during a 'make -C tools/perf build-test' routine test, it is failing as perl likes die() calls and then this clashes with this remnant, remove it. Fixes: fef2a735167a827a ("perf tools: Kill die()") Reviewed-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 62f0515c86d2025787612927891b3390be5701a8 Author: Ian Rogers Date: Tue Apr 7 19:08:38 2026 -0700 perf maps: Fix copy_from that can break sorted by name order [ Upstream commit f552b132e4d5248715828e7e5c2bf7889bf05b2e ] When an parent is copied into a child the name array is populated in address not name order. Make sure the name array isn't flagged as sorted. Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 1e551e8fc789de0938877c0d09bba45c2232f707 Author: Ian Rogers Date: Tue Apr 7 19:08:37 2026 -0700 perf maps: Fix fixup_overlap_and_insert that can break sorted by name order [ Upstream commit c4f3ff3289380437d26177e8f2fe4b7507816ee3 ] When an entry in the address array is replaced, the corresponding name entry is replaced. The entries names may sort differently and so it is important that the sorted by name property be cleared on the maps. Fixes: 0d11fab32714 ("perf maps: Fixup maps_by_name when modifying maps_by_address") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit ef151ae6476438d5079c5292856c0d1c3aff22ca Author: Inochi Amaoto Date: Wed Apr 1 08:35:50 2026 +0800 pinctrl: sophgo: pinctrl-sg2044: Fix wrong module description [ Upstream commit 7648112358a4207916d3e38bfee49f85552fe95f ] Fix the SoC model in module description string, it should be sg2044 instead of sg2002. Fixes: 614a54cb5ac3 ("pinctrl: sophgo: add support for SG2044 SoC") Signed-off-by: Inochi Amaoto Reviewed-by: Chen Wang Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6081bb686387c381e45963811e080ebb72b62acf Author: Inochi Amaoto Date: Wed Apr 1 08:35:49 2026 +0800 pinctrl: sophgo: pinctrl-sg2042: Fix wrong module description [ Upstream commit ca1c2ddff00480c213903a1479b56203536e92de ] Fix the SoC model in module description string, it should be sg2042 instead of sg2002. Fixes: 1e67465d3b74 ("pinctrl: sophgo: add support for SG2042 SoC") Signed-off-by: Inochi Amaoto Reviewed-by: Chen Wang Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 58727055ac16bc99d1f919f7d89b0a61371b7bc1 Author: Ian Rogers Date: Fri Apr 3 23:05:52 2026 -0700 perf cgroup: Update metric leader in evlist__expand_cgroup [ Upstream commit c9ef786c0970991578397043f1c819229e2b7197 ] When the evlist is expanded the metric leader wasn't being updated. As the original evsel is deleted this creates a use-after-free in stat-shadow's prepare_metric. This was detected running the "perf stat --bpf-counters --for-each-cgroup test" with sanitizers. The change itself puts the copied evsel into the priv field (known unused because of evsel__clone use) and then in a second pass over the list updates the copied values using the priv pointer. Fixes: d1c5a0e86a4e ("perf stat: Add --for-each-cgroup option") Signed-off-by: Ian Rogers Acked-by: Sun Jian Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 48fc9a33fa29ec7f4e306e7fd25ccf2fc5a61d40 Author: Jian Zhang Date: Fri Apr 3 17:06:01 2026 +0800 ipmi: ssif_bmc: change log level to dbg in irq callback [ Upstream commit c9c99b7b7051eb7121b3224bfce181fb023b0269 ] Long-running tests indicate that this logging can occasionally disrupt timing and lead to request/response corruption. Irq handler need to be executed as fast as possible, most I2C slave IRQ implementations are byte-level, logging here can significantly affect transfer behavior and timing. It is recommended to use dev_dbg() for these messages. Fixes: dd2bc5cc9e25 ("ipmi: ssif_bmc: Add SSIF BMC driver") Signed-off-by: Jian Zhang Message-ID: <20260403090603.3988423-4-zhangjian.3032@bytedance.com> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 1791a465778e1aa53c5d6fc28c8fb66042d82fc6 Author: Jian Zhang Date: Fri Apr 3 17:06:00 2026 +0800 ipmi: ssif_bmc: fix message desynchronization after truncated response [ Upstream commit 1d38e849adb6851ee280aa1a1d687b2181549a66 ] A truncated response, caused by host power-off, or other conditions, can lead to message desynchronization. Raw trace data (STOP loss scenario, add state transition comment): 1. T-1: Read response phase (SSIF_RES_SENDING) 8271.955342 WR_RCV [03] <- Read polling cmd 8271.955348 RD_REQ [04] <== SSIF_RES_SENDING <- start sending response 8271.955436 RD_PRO [b4] 8271.955527 RD_PRO [00] 8271.955618 RD_PRO [c1] 8271.955707 RD_PRO [00] 8271.955814 RD_PRO [ad] <== SSIF_RES_SENDING <- last byte <- !! STOP lost (truncated response) 2. T: New Write request arrives, BMC still in SSIF_RES_SENDING 8271.967973 WR_REQ [] <== SSIF_RES_SENDING >> SSIF_ABORTING <- log: unexpected WR_REQ in RES_SENDING 8271.968447 WR_RCV [02] <== SSIF_ABORTING <- do nothing 8271.968452 WR_RCV [02] <== SSIF_ABORTING <- do nothing 8271.968454 WR_RCV [18] <== SSIF_ABORTING <- do nothing 8271.968456 WR_RCV [01] <== SSIF_ABORTING <- do nothing 8271.968458 WR_RCV [66] <== SSIF_ABORTING <- do nothing 8271.978714 STOP [] <== SSIF_ABORTING >> SSIF_READY <- log: unexpected SLAVE STOP in state=SSIF_ABORTING 3. T+1: Next Read polling, treated as a fresh transaction 8271.979125 WR_REQ [] <== SSIF_READY >> SSIF_START 8271.979326 WR_RCV [03] <== SSIF_START >> SSIF_SMBUS_CMD <- smbus_cmd=0x03 8271.979331 RD_REQ [04] <== SSIF_RES_SENDING <- sending response 8271.979427 RD_PRO [b4] <- !! this is T's stale response -> desynchronization When in SSIF_ABORTING state, a newly arrived command should still be handled to avoid dropping the request or causing message desynchronization. Fixes: dd2bc5cc9e25 ("ipmi: ssif_bmc: Add SSIF BMC driver") Signed-off-by: Jian Zhang Message-ID: <20260403090603.3988423-3-zhangjian.3032@bytedance.com> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 20f63ce378a0aa1cfd264484860a317eb33f54e9 Author: Jian Zhang Date: Fri Apr 3 17:05:59 2026 +0800 ipmi: ssif_bmc: fix missing check for copy_to_user() partial failure [ Upstream commit ea641be7a4faee4351f9c5ed6b188e1bbf5586a6 ] copy_to_user() returns the number of bytes that could not be copied, with a non-zero value indicating a partial or complete failure. The current code only checks for negative return values and treats all non-negative results as success. Treating any positive return value from copy_to_user() as an error and returning -EFAULT. Fixes: dd2bc5cc9e25 ("ipmi: ssif_bmc: Add SSIF BMC driver") Signed-off-by: Jian Zhang Message-ID: <20260403090603.3988423-2-zhangjian.3032@bytedance.com> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 2f81d201f83f9aa41184a963fb1d62fd990627be Author: Ian Rogers Date: Wed Mar 18 18:01:03 2026 -0700 perf metrics: Make common stalled metrics conditional on having the event [ Upstream commit 210259987d9a7bb8506f3e93c2ddbece15c13b15 ] The metric code uses the event parsing code but it generally assumes all events are supported. Arnaldo reported AMD supporting stalled-cycles-frontend but not stalled-cycles-backend [1]. An issue with this is that before parsing happens the metric code tries to share events within groups to reduce the number of events and multiplexing. If the group has some supported and not supported events, the whole group will become broken. To avoid this situation add has_event tests to the metrics for stalled-cycles-frontend and stalled-cycles-backend. has_events is evaluated when parsing the metric and its result constant propagated (with if-elses) to reduce the number of events. This means when the metric code considers sharing the events, only supported events will be shared. Note for backporting. This change updates tools/perf/pmu-events/empty-pmu-events.c a convenience file for builds on systems without python present. While the metrics.json code should backport easily there can be conflicts on empty-pmu-events.c. In this case the build will have left a file test-empty-pmu-events.c that can be copied over empty-pmu-events.c to resolve issues and make an appropriate empty-pmu-events.c for the json in the source tree at the time of the build. [1] https://lore.kernel.org/lkml/abm1nR-2xjOUBroD@x1/ Reported-by: Arnaldo Carvalho de Melo Closes: https://lore.kernel.org/lkml/abm1nR-2xjOUBroD@x1/ Fixes: c7adeb0974f1 ("perf jevents: Add set of common metrics based on default ones") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit dd7d8f5da73ae306cdba782cfc7195c1b7fa5ff1 Author: Leo Yan Date: Thu Apr 2 17:04:47 2026 +0100 perf expr: Return -EINVAL for syntax error in expr__find_ids() [ Upstream commit 3a61fd866ef9aaa1d3158b460f852b74a2df07f4 ] expr__find_ids() propagates the parser return value directly. For syntax errors, the parser can return a positive value, but callers treat it as success, e.g., for below case on Arm64 platform: metric expr 100 * (STALL_SLOT_BACKEND / (CPU_CYCLES * #slots) - BR_MIS_PRED * 3 / CPU_CYCLES) for backend_bound parsing metric: 100 * (STALL_SLOT_BACKEND / (CPU_CYCLES * #slots) - BR_MIS_PRED * 3 / CPU_CYCLES) Failure to read '#slots' literal: #slots = nan syntax error Convert positive parser returns in expr__find_ids() to -EINVAL, as a result, the error value will be respected by callers. Before: perf stat -C 5 Failure to read '#slots'Failure to read '#slots'Failure to read '#slots'Failure to read '#slots'Segmentation fault After: perf stat -C 5 Failure to read '#slots'Cannot find metric or group `Default' Fixes: ded80bda8bc9 ("perf expr: Migrate expr ids table to a hashmap") Signed-off-by: Leo Yan Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7725e6cb107dccc97bd22fcb1401644454575ca7 Author: Thomas Richter Date: Wed Apr 1 14:21:01 2026 +0200 perf test: Skip perf data type profiling tests for s390 [ Upstream commit eb27e1c885ea75c1661188a548d100c8bce5970a ] Test case 'perf data type profiling tests' fails on s390 with this error: # ./perf mem record -- ./perf test -w code_with_type failed: no PMU supports the memory events # echo $? 255 # because s390 does not support memory events at all. According to the man page, perf annotate --code-with-type only works with memory instructions only. As command 'perf mem record ...' is not supported on s390, skip this test for s390. Output before: # ./perf test 'perf data type profiling tests' 77: perf data type profiling tests : FAILED! Output after: # ./perf test 'perf data type profiling tests' 77: perf data type profiling tests : Skip Fixes: f60a5c22967b8 ("perf tests: Test annotate with data type profiling and rust") Signed-off-by: Thomas Richter Reviewed-by: Ian Rogers Cc: Dmitrii Dolgov <9erthalion6@gmail.com> Suggested-by: Namhyung Kim Suggested-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit ba50aca11dd05b8680cf555c6b040bea31e29d11 Author: Thomas Falcon Date: Thu Mar 26 20:59:27 2026 -0500 perf test: Fix ratio_to_prev event parsing test [ Upstream commit 77cb9b443b7fff2a93d78cd2e309db030046772f ] test__ratio_to_prev() assumed the first event in a group is the leader, which is not the case when the event is expanded into two event groups on hybrid PMU's with auto counter reload support. Instead, iterate over the event group generated for each core PMU. Also update "wrong leader" test to check that the subordinate event has the correct leader instead of checking that it is not the group leader. Finally, do not exit immediately if a PMU without auto counter reload support is found. Signed-off-by: Thomas Falcon Reviewed-by: Dapeng Mi Reviewed-by: Ian Rogers Fixes: 56be0fe5f62c ("perf record: Add auto counter reload parse and regression tests") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b8d0d73f1fb66fc6e5e6d3878bc4a7548c2df392 Author: Chuck Lever Date: Mon Mar 23 11:58:04 2026 -0400 perf tools: Fix module symbol resolution for non-zero .text sh_addr [ Upstream commit 9a82bfde4775b7a87cd1a7e791f46f83ae442848 ] When perf resolves symbols from kernel module ELF files (ET_REL), it converts symbol addresses to file offsets so that sample IPs can be matched to the correct symbol. The conversion adjusts each symbol's st_value: sym->st_value -= shdr->sh_addr - shdr->sh_offset; For vmlinux (ET_EXEC), st_value is a virtual address and sh_addr is the section's virtual base, so subtracting sh_addr and adding sh_offset correctly yields a file offset. For kernel modules (ET_REL), st_value is a section-relative offset. The module loader ignores sh_addr entirely and places symbols at module_base + st_value. Converting to file offset requires only adding sh_offset; subtracting sh_addr introduces an error equal to sh_addr bytes. When .text has sh_addr == 0 -- the historical norm for simple modules -- both formulas produce the same result and the bug is latent. As modules gain more metadata sections before .text (.note, .static_call.text, etc.), the linker assigns .text a non-zero sh_addr, exposing the defect. For example, nfsd.ko on this kernel has sh_addr=0xa80, kvm-intel.ko has sh_addr=0x1e90. The effect is that all .text symbols in affected modules shift by sh_addr bytes relative to sample IPs, causing perf report to attribute samples to incorrect, nearby symbols. This was observed as 13% of LLC-load-miss samples misattributed to nfsd_file_get_dio_attrs when the actual hot function was nfsd_cache_lookup, approximately 0xa80 bytes away in the symbol table. Use the existing dso__rel() flag (already set for ET_REL modules) to select the correct adjustment: add sh_offset for ET_REL, subtract (sh_addr - sh_offset) for ET_EXEC/ET_DYN. Fixes: 0131c4ec794a ("perf tools: Make it possible to read object code from kernel modules") Signed-off-by: Chuck Lever Reviewed-by: Ian Rogers Tested-by: Thomas Richter Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 2789f15451a30acf8224c6f53381645e9228afa3 Author: Breno Leitao Date: Wed Mar 25 03:24:30 2026 -0700 perf stat: Fix crash on arm64 [ Upstream commit b5708a308a5602d4a3caf0720dce452082d443ec ] Perf stat is crashing on arm64 hosts with the following issue: # make -C tools/perf DEBUG=1 # perf stat sleep 1 perf: util/evsel.c:2034: get_group_fd: Assertion `!(!leader->core.fd)' failed. [1] 1220794 IOT instruction (core dumped) ./perf stat The sorting function introduced by commit a745c0831c15c ("perf stat: Sort default events/metrics") compares events based on their individual properties. This can cause events from different groups to be interleaved, resulting in group members appearing before their leaders in the sorted evlist. When the iterator opens events in list order, a group member may be processed before its leader has been opened. For example, CPU_CYCLES (idx=32) with leader STALL_SLOT_BACKEND (idx=37) could be sorted before its leader, causing the crash when CPU_CYCLES tries to get its group fd from the not-yet-opened leader. Fix this by comparing events based on their leader's attributes instead of their own attributes when the events are in different groups. This ensures all members of a group share the same sort key as their leader, keeping groups together and guaranteeing leaders are opened before their members. Fixes: a745c0831c15c ("perf stat: Sort default events/metrics") Reported-by: Denis Yaroshevskiy Tested-by: Dmitry Ilvokhin Tested-by: Ian Rogers Signed-off-by: Breno Leitao Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b1f267b2ea79fb31ccd14cf1c723720586004bc1 Author: Mike Rapoport (Microsoft) Date: Mon Mar 23 09:48:28 2026 +0200 memblock: reserve_mem: fix end caclulation in reserve_mem_release_by_name() [ Upstream commit c12c3e1507809ad1fc0448f51c933f52e17d13cd ] free_reserved_area() expects end parameter to point to the first address after the area, but reserve_mem_release_by_name() passes it the last address inside the area. Remove subtraction of one in calculation of the area end. Fixes: 74e2498ccf7b ("mm/memblock: Add reserved memory release function") Link: https://patch.msgid.link/20260323074836.3653702-2-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 7e0649b20aaf9a233d338f43ab971b58a8acd010 Author: Ian Rogers Date: Thu Mar 19 16:33:49 2026 -0700 perf stat: Fix opt->value type for parse_cache_level [ Upstream commit 44311ae84ad9177fb311aee856027861c22f17b2 ] Commit f5803651b4a4 ("perf stat: Choose the most disaggregate command line option") changed aggregation option handling for `perf stat` but not `perf stat report` leading to parse_cache_level being passed a struct in the `perf stat` case but erroneously an aggr_mode enum value for `perf stat report`. Change the `perf stat report` aggregation handling to use the same opt_aggr_mode as `perf stat`. Also, just pass the boolean for consistency with other boolean argument handling. Fixes: f5803651b4a4 ("perf stat: Choose the most disaggregate command line option") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit df4d5c8bd93a3af90f50fbca37b4d16f1857e654 Author: Ian Rogers Date: Thu Mar 19 16:33:48 2026 -0700 perf lock: Fix option value type in parse_max_stack [ Upstream commit cfaade34b52aa1ec553044255702c4b31b57c005 ] The value is a void* and the address of an int, max_stack_depth, is set up in the perf lock options. The parse_max_stack function treats the int* as a long*, make this more correct by declaring the value to be an int*. Fixes: 0a277b622670 ("perf lock contention: Check --max-stack option") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 3e0cf5599df6e6e1b99700c3210967bc0c29120d Author: Leo Yan Date: Tue Mar 17 18:58:00 2026 +0000 tools build: Correct link flags for libopenssl [ Upstream commit 5c980ab238c8a9e2b24221603f11eadc98a7f45e ] The perf static build reports that the BPF skeleton is disabled due to the missing libopenssl feature. Use PKG_CONFIG to determine the link flags for libopenssl. Add "--static" to the PKG_CONFIG command for static linking. Fixes: 7678523109d1 ("tools/build: Add a feature test for libopenssl") Signed-off-by: Leo Yan Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 4e75acb6c1b1accb8c676db07177bdf22872393a Author: Biju Das Date: Thu Mar 26 16:24:51 2026 +0000 pinctrl: renesas: rzg2l: Fix save/restore of {IOLH,IEN,PUPD,SMT} registers [ Upstream commit d9a60e367919752a1d398ebeba667f1e200fae1e ] The rzg2l_pinctrl_pm_setup_regs() handles save/restore of {IOLH,IEN,PUPD,SMT} registers during s2ram, but only for ports where all pins share the same pincfg. Extend the code to also support ports with variable pincfg per pin, so that {IOLH,IEN,PUPD,SMT} registers are correctly saved and restored for all pins. Fixes: 254203f9a94c ("pinctrl: renesas: rzg2l: Add suspend/resume support") Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260326162459.101414-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit ac68566e08ed29ea6b8a1586c55f35cf87d0b7af Author: Yu-Chun Lin Date: Fri Mar 20 23:15:06 2026 +0800 pinctrl: abx500: Fix type of 'argument' variable [ Upstream commit 34006f77890d050e6d80cbee365b5d703c1140b4 ] The argument variable is assigned the return value of pinconf_to_config_argument(), which returns a u32. Change its type from enum pin_config_param to unsigned int to correctly store the configuration argument. Fixes: 03b054e9696c ("pinctrl: Pass all configs to driver on pin_config_set()") Signed-off-by: Yu-Chun Lin Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1d4a058b37247b9382e9e37877bf9a61901ad281 Author: Yu-Chun Lin Date: Tue Mar 17 19:54:03 2026 +0800 pinctrl: realtek: Fix function signature for config argument [ Upstream commit 1f5451844786ed203605528dca9e5d84ed378160 ] The argument originates from pinconf_to_config_argument(), which returns a u32. Therefore, the arg parameter should be an unsigned int instead of enum pin_config_param. Fixes: e99ce78030db ("pinctrl: realtek: Add common pinctrl driver for Realtek DHC RTD SoCs") Signed-off-by: Yu-Chun Lin Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b7842b722169359e7ffe4b838d2496e9e72ac996 Author: Andy Shevchenko Date: Tue Mar 17 11:36:11 2026 +0100 pinctrl: pinconf-generic: Fully validate 'pinmux' property [ Upstream commit c98324ea7849b6e5baa1774f71709b375a2c2f9e ] The pinconf_generic_parse_dt_pinmux() assumes that the 'pinmux' property is not empty when present. This might be not true. With that, the allocator will give a special value in return and not NULL which lead to the crash when trying to access that (invalid) memory. Fix that by fully validating 'pinmux' value, including its length. Fixes: 7112c05fff83 ("pinctrl: pinconf-generic: Add API for pinmux propertity in DTS file") Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f882318ec9c17c479f711a2fb25ee7d4bfc6fd48 Author: Mike Leach Date: Wed Mar 18 10:36:39 2026 +0000 perf: tools: cs-etm: Fix print issue for Coresight debug in ETE/TRBE trace [ Upstream commit 6c478e7b3eba3f387a2d6c749e3e3ee0f8ad1c53 ] Building perf with CORESIGHT=1 and the optional CSTRACE_RAW=1 enables additional debug printing of raw trace data when using command:- perf report --dump. This raw trace prints the CoreSight formatted trace frames, which may be used to investigate suspected issues with trace quality / corruption / decode. These frames are not present in ETE + TRBE trace. This fix removes the unnecessary call to print these frames. This fix also rationalises implementation - original code had helper function that unnecessarily repeated initialisation calls that had already been made. Due to an addtional fault with the OpenCSD library, this call when ETE/TRBE are being decoded will cause a segfault in perf. This fix also prevents that problem for perf using older (<= 1.8.0 version) OpenCSD libraries. Fixes: 68ffe3902898 ("perf tools: Add decoder mechanic to support dumping trace data") Reported-by: Leo Yan Signed-off-by: Mike Leach Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 48dc1b265c2d86c0b971335447c7d233ec18a877 Author: Ian Rogers Date: Thu Mar 12 15:31:31 2026 -0700 perf branch: Avoid incrementing NULL [ Upstream commit c969a9d7bbf46f983c4a48566b3b2f7340b02296 ] If the entry is NULL the value is meaningless so early return NULL to avoid an increment of NULL. This was happening in calls from has_stitched_lbr when running the "perf record LBR tests". The return value isn't used in that case, so returning NULL as no effect. Fixes: 42bbabed09ce ("perf tools: Add hw_idx in struct branch_stack") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit db3fc6ee3b3a07f365934f4c5d211481c19e6011 Author: Andy Shevchenko Date: Fri Feb 27 17:43:35 2026 +0100 pinctrl: cy8c95x0: Avoid returning positive values to user space [ Upstream commit 5ad32c3607cf241a1a2680cabd64cbcd757227aa ] When probe fails due to unclear interrupt status register, it returns a positive number instead of the proper error code. Fix this accordingly. Fixes: e6cbbe42944d ("pinctrl: Add Cypress cy8c95x0 support") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202602271847.vVWkqLBD-lkp@intel.com/ Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit a6a17c9a90d2116fde928eb8c880e49511680bf2 Author: Andy Shevchenko Date: Mon Feb 23 19:06:54 2026 +0100 pinctrl: cy8c95x0: Unify messages with help of dev_err_probe() [ Upstream commit 014884732095b982412d13d3220c3fe8483b9b3e ] Unify error messages that might appear during probe phase by switching to use dev_err_probe(). Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Stable-dep-of: 5ad32c3607cf ("pinctrl: cy8c95x0: Avoid returning positive values to user space") Signed-off-by: Sasha Levin commit 59d98da8710cf8f987b1e597a6b7f36e6cf70aab Author: Andy Shevchenko Date: Mon Feb 23 19:06:53 2026 +0100 pinctrl: cy8c95x0: remove duplicate error message [ Upstream commit 970dacb3b9f0fedbbbcfd7dbf1f4f22340b3f359 ] The pin control core is covered to report any error via message. The devm_request_threaded_irq() already prints an error message. Remove the duplicates. While at it, drop the info message as the same information about an IRQ in use can be retrieved differently. Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Stable-dep-of: 5ad32c3607cf ("pinctrl: cy8c95x0: Avoid returning positive values to user space") Signed-off-by: Sasha Levin commit 3a1a155b7be59918d22a646a138b2ccd313c609c Author: Ian Rogers Date: Mon Mar 2 15:58:21 2026 -0800 perf test type profiling: Remote typedef on struct [ Upstream commit 6910944bf0b92fea63d5a7aeed69e4b9c14fd01b ] The typedef creates an issue where the struct or the typedef may appear in the output and cause the "perf data type profiling tests" to fail. Let's remove the typedef to keep the test passing. Fixes: 335047109d7d ("perf tests: Test annotate with data type profiling and C") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 382839175658ffdbe24ac9099f9a5a232228fce2 Author: Felix Gu Date: Tue Mar 3 02:13:17 2026 +0800 pinctrl: microchip-mssio: Fix missing return in probe [ Upstream commit 8f72335002db29fb593f8c2c25761feb3b947eb3 ] In mpfs_pinctrl_probe(), when pctrl->regmap fails, it just print out an error message without return, which could lead serious errors. Fixes: 488d704ed7b7 ("pinctrl: add polarfire soc mssio pinctrl driver") Signed-off-by: Felix Gu Reviewed-by: Conor Dooley Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 7a1d6ed72485e7c2fd26fea01acbb43be2863c37 Author: Ian Rogers Date: Mon Mar 2 15:45:15 2026 -0800 perf trace: Avoid an ERR_PTR in syscall_stats [ Upstream commit d05073adda0f047e9b2115a2932bcb2797eab238 ] hashmap__new may return an ERR_PTR and previously this would be assigned to syscall_stats meaning all use of syscall_stats needs to test for NULL (uninitialized) or an ERR_PTR. Given the only reason hashmap__new can fail is ENOMEM, just use NULL to indicate the allocation failure and avoid the code having to test for NULL and IS_ERR. Fixes: 96f202eab813 (perf trace: Fix IS_ERR() vs NULL check bug) Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 949134e38667514f1ba31792206f0d1e294ffdc0 Author: Ethan Tidmore Date: Fri Feb 27 15:56:23 2026 -0600 pinctrl: pinctrl-pic32: Fix resource leak [ Upstream commit fe5560688f3ba98364c7de7b4f8dc240ffd1ff75 ] Fix three possible resource leaks by using the devres version of clk_prepare_enable(). Also, update error message accordingly. Detected by Smatch: drivers/pinctrl/pinctrl-pic32.c:2211 pic32_pinctrl_probe() warn: 'pctl->clk' from clk_prepare_enable() not released on lines: 2208. drivers/pinctrl/pinctrl-pic32.c:2274 pic32_gpio_probe() warn: 'bank->clk' from clk_prepare_enable() not released on lines: 2264,2272. Fixes: 2ba384e6c3810 ("pinctrl: pinctrl-pic32: Add PIC32 pin control driver") Signed-off-by: Ethan Tidmore Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e567fe205a24cd79f53c96eeb4ab62af5c36f3b6 Author: Gabor Juhos Date: Fri Feb 27 15:15:54 2026 +0100 dt-bindings: pinctrl: marvell,armada3710-xb-pinctrl: add missing items keyword [ Upstream commit a92b75100826b1ea27e6b8a678e53970ad4736d7 ] Even though the type of the 'groups' property of a pinmux node is specified as string-array in pinmux-node.yaml, but trying to use multiple strings causes dtbs_check warnings. For example, checking the following dts ... $ cat arch/arm64/boot/dts/marvell/armada-3720-test.dts /dts-v1/; #include "armada-372x.dtsi" &pinctrl_nb { pwm-gpio-pins { groups = "pwm0", "pwm1", "pwm2", "pwm3"; function = "gpio"; }; }; ... results in this warning: arch/arm64/boot/dts/marvell/armada-3720-test.dtb: pinctrl@13800 (marvell,armada3710-nb-pinctrl): pwm-gpio-pins:groups: ['pwm0', 'pwm1', 'pwm2', 'pwm3'] is too long from schema $id: http://devicetree.org/schemas/pinctrl/marvell,armada3710-xb-pinctrl.yaml Add the missing 'items' keyword to the schema to allow using multiple strings without such warnings. Also adjust the indentation of the next statements accordingly. Signed-off-by: Gabor Juhos Acked-by: Conor Dooley Fixes: c1c9641a04e83 ("dt-bindings: pinctrl: Convert marvell,armada-3710-(sb|nb)-pinctrl to DT schema") Reviewed-by: Miquel Raynal Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 654c9c06416d228672552113a9c9be0e0435daad Author: wangguangju Date: Thu Feb 26 20:22:08 2026 +0800 perf trace: Fix IS_ERR() vs NULL check bug [ Upstream commit 96f202eab8133f94479b14a32902c636e9bdf6af ] The alloc_syscall_stats() function always returns an error pointer (ERR_PTR) on failure. So replace NULL check with IS_ERR() check after calling delete_syscall_stats() function. Fixes: ef2da619b132c6f74 ("perf trace: Convert syscall_stats to hashmap") Signed-off-by: wangguangju Reviewed-by: Howard Chu Acked-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit a2ac8872d86488d2539c608f71ac484648e94755 Author: Puranjay Mohan Date: Fri Apr 17 07:33:52 2026 -0700 bpf, arm32: Reject BPF-to-BPF calls and callbacks in the JIT [ Upstream commit e1d486445af3c392628532229f7ce5f5cf7891b6 ] The ARM32 BPF JIT does not support BPF-to-BPF function calls (BPF_PSEUDO_CALL) or callbacks (BPF_PSEUDO_FUNC), but it does not reject them either. When a program with subprograms is loaded (e.g. libxdp's XDP dispatcher uses __noinline__ subprograms, or any program using callbacks like bpf_loop or bpf_for_each_map_elem), the verifier invokes bpf_jit_subprogs() which calls bpf_int_jit_compile() for each subprogram. For BPF_PSEUDO_CALL, since ARM32 does not reject it, the JIT silently emits code using the wrong address computation: func = __bpf_call_base + imm where imm is a pc-relative subprogram offset, producing a bogus function pointer. For BPF_PSEUDO_FUNC, the ldimm64 handler ignores src_reg and loads the immediate as a normal 64-bit value without error. In both cases, build_body() reports success and a JIT image is allocated. ARM32 lacks the jit_data/extra_pass mechanism needed for the second JIT pass in bpf_jit_subprogs(). On the second pass, bpf_int_jit_compile() performs a full fresh compilation, allocating a new JIT binary and overwriting prog->bpf_func. The first allocation is never freed. bpf_jit_subprogs() then detects the function pointer changed and aborts with -ENOTSUPP, but the original JIT binary has already been leaked. Each program load/unload cycle leaks one JIT binary allocation, as reported by kmemleak: unreferenced object 0xbf0a1000 (size 4096): backtrace: bpf_jit_binary_alloc+0x64/0xfc bpf_int_jit_compile+0x14c/0x348 bpf_jit_subprogs+0x4fc/0xa60 Fix this by rejecting both BPF_PSEUDO_CALL in the BPF_CALL handler and BPF_PSEUDO_FUNC in the BPF_LD_IMM64 handler, falling through to the existing 'notyet' path. This causes build_body() to fail before any JIT binary is allocated, so bpf_int_jit_compile() returns the original program unjitted. bpf_jit_subprogs() then sees !prog->jited and cleanly falls back to the interpreter with no leak. Acked-by: Daniel Borkmann Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs") Reported-by: Jonas Rebmann Closes: https://lore.kernel.org/bpf/b63e9174-7a3d-4e22-8294-16df07a4af89@pengutronix.de Tested-by: Jonas Rebmann Signed-off-by: Puranjay Mohan Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260417143353.838911-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fb66e20130f95a93ffea1677252526a9e39170b2 Author: Puranjay Mohan Date: Fri Apr 17 08:21:33 2026 -0700 bpf: Validate node_id in arena_alloc_pages() [ Upstream commit 2845989f2ebaf7848e4eccf9a779daf3156ea0a5 ] arena_alloc_pages() accepts a plain int node_id and forwards it through the entire allocation chain without any bounds checking. Validate node_id before passing it down the allocation chain in arena_alloc_pages(). Fixes: 317460317a02 ("bpf: Introduce bpf_arena.") Signed-off-by: Puranjay Mohan Reviewed-by: Emil Tsalapatis Link: https://lore.kernel.org/r/20260417152135.1383754-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 338c073351b882eb57fe84e5d1e88999aa735115 Author: Jiri Olsa Date: Thu Apr 16 12:00:34 2026 +0200 libbpf: Prevent double close and leak of btf objects [ Upstream commit 380044c40b1636a72fd8f188b5806be6ae564279 ] Sashiko found possible double close of btf object fd [1], which happens when strdup in load_module_btfs fails at which point the obj->btf_module_cnt is already incremented. The error path close btf fd and so does later cleanup code in bpf_object_post_load_cleanup function. Also libbpf_ensure_mem failure leaves btf object not assigned and it's leaked. Replacing the err_out label with break to make the error path less confusing as suggested by Alan. Incrementing obj->btf_module_cnt only if there's no failure and releasing btf object in error path. Fixes: 91abb4a6d79d ("libbpf: Support attachment of BPF tracing programs to kernel modules") [1] https://sashiko.dev/#/patchset/20260324081846.2334094-1-jolsa%40kernel.org Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20260416100034.1610852-1-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a9a532d35ebbdd5e6f604019c48fa007f098df04 Author: Yihan Ding Date: Thu Apr 16 20:01:41 2026 +0800 bpf: allow UTF-8 literals in bpf_bprintf_prepare() [ Upstream commit b960430ea8862ef37ce53c8bf74a8dc79d3f2404 ] bpf_bprintf_prepare() only needs ASCII parsing for conversion specifiers. Plain text can safely carry bytes >= 0x80, so allow UTF-8 literals outside '%' sequences while keeping ASCII control bytes rejected and format specifiers ASCII-only. This keeps existing parsing rules for format directives unchanged, while allowing helpers such as bpf_trace_printk() to emit UTF-8 literal text. Update test_snprintf_negative() in the same commit so selftests keep matching the new plain-text vs format-specifier split during bisection. Fixes: 48cac3f4a96d ("bpf: Implement formatted output helpers with bstr_printf") Signed-off-by: Yihan Ding Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260416120142.1420646-2-dingyihan@uniontech.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit da1d615ce49a47986a8864e2371a26e97861085c Author: Mykyta Yatsenko Date: Thu Apr 16 11:08:07 2026 -0700 bpf: Fix NULL deref in map_kptr_match_type for scalar regs [ Upstream commit 4d0a375887ab4d49e4da1ff10f9606cab8f7c3ad ] Commit ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with local kptr") refactored map_kptr_match_type() to branch on btf_is_kernel() before checking base_type(). A scalar register stored into a kptr slot has no btf, so the btf_is_kernel(reg->btf) call dereferences NULL. Move the base_type() != PTR_TO_BTF_ID guard before any reg->btf access. Fixes: ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with local kptr") Reported-by: Hiker Cl Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221372 Signed-off-by: Mykyta Yatsenko Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260416-kptr_crash-v1-1-5589356584b4@meta.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2631bf9a0b2d7332f20185ea688cee01c146ab46 Author: Daniel Borkmann Date: Thu Apr 16 14:27:19 2026 +0200 bpf: Fix precedence bug in convert_bpf_ld_abs alignment check [ Upstream commit e5f635edd393aeaa7cad9e42831d397e6e2e1eed ] Fix an operator precedence issue in convert_bpf_ld_abs() where the expression offset + ip_align % size evaluates as offset + (ip_align % size) due to % having higher precedence than +. That latter evaluation does not make any sense. The intended check is (offset + ip_align) % size == 0 to verify that the packet load offset is properly aligned for direct access. With NET_IP_ALIGN == 2, the bug causes the inline fast-path for direct packet loads to almost never be taken on !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS platforms. This forces nearly all cBPF BPF_LD_ABS packet loads through the bpf_skb_load_helper slow path on the affected archs. Fixes: e0cea7ce988c ("bpf: implement ld_abs/ld_ind in native bpf") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260416122719.661033-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 98f744d204e5d6fca589cd2c44c3190a0c71697f Author: Michal Luczaj Date: Tue Apr 14 16:13:19 2026 +0200 bpf, sockmap: Take state lock for af_unix iter [ Upstream commit 64c2f93fc3254d3bf5de4445fb732ee5c451edb6 ] When a BPF iterator program updates a sockmap, there is a race condition in unix_stream_bpf_update_proto() where the `peer` pointer can become stale[1] during a state transition TCP_ESTABLISHED -> TCP_CLOSE. CPU0 bpf CPU1 close -------- ---------- // unix_stream_bpf_update_proto() sk_pair = unix_peer(sk) if (unlikely(!sk_pair)) return -EINVAL; // unix_release_sock() skpair = unix_peer(sk); unix_peer(sk) = NULL; sock_put(skpair) sock_hold(sk_pair) // UaF More practically, this fix guarantees that the iterator program is consistently provided with a unix socket that remains stable during iterator execution. [1]: BUG: KASAN: slab-use-after-free in unix_stream_bpf_update_proto+0x155/0x490 Write of size 4 at addr ffff8881178c9a00 by task test_progs/2231 Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x170/0x4f3 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x155/0x490 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x63/0x80 kmem_cache_alloc_noprof+0x1d5/0x680 sk_prot_alloc+0x59/0x210 sk_alloc+0x34/0x470 unix_create1+0x86/0x8a0 unix_stream_connect+0x318/0x15b0 __sys_connect+0xfd/0x130 __x64_sys_connect+0x72/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x47/0x70 kmem_cache_free+0x11c/0x590 __sk_destruct+0x432/0x6e0 unix_release_sock+0x9b3/0xf60 unix_release+0x8a/0xf0 __sock_release+0xb0/0x270 sock_close+0x18/0x20 __fput+0x36e/0xac0 fput_close_sync+0xe5/0x1a0 __x64_sys_close+0x7d/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 2c860a43dd77 ("bpf: af_unix: Implement BPF iterator for UNIX domain socket.") Suggested-by: Kuniyuki Iwashima Signed-off-by: Michal Luczaj Signed-off-by: Martin KaFai Lau Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260414-unix-proto-update-null-ptr-deref-v4-5-2af6fe97918e@rbox.co Signed-off-by: Sasha Levin commit 37bfcd164161b47d00b1c3bd20adc816a6977ce0 Author: Michal Luczaj Date: Tue Apr 14 16:13:18 2026 +0200 bpf, sockmap: Fix af_unix null-ptr-deref in proto update [ Upstream commit dca38b7734d2ea00af4818ff3ae836fab33d5d5a ] unix_stream_connect() sets sk_state (`WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`). sk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that socket is properly set up, which would include having a defined peer. IOW, there's a window when unix_stream_bpf_update_proto() can be called on socket which still has unix_peer(sk) == NULL. CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) ... sk_pair = unix_peer(sk) sock_hold(sk_pair) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) = newsk BUG: kernel NULL pointer dereference, address: 0000000000000080 RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0 Call Trace: sock_map_link+0x564/0x8b0 sock_map_update_common+0x6e/0x340 sock_map_update_elem_sys+0x17d/0x240 __sys_bpf+0x26db/0x3250 __x64_sys_bpf+0x21/0x30 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Initial idea was to move peer assignment _before_ the sk_state update[1], but that involved an additional memory barrier, and changing the hot path was rejected. Then a NULL check during proto update in unix_stream_bpf_update_proto() was considered[2], but the follow-up discussion[3] focused on the root cause, i.e. sockmap update taking a wrong lock. Or, more specifically, missing unix_state_lock()[4]. In the end it was concluded that teaching sockmap about the af_unix locking would be unnecessarily complex[5]. Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT are allowed to update sockmaps, sock_map_update_elem() taking the unix lock, as it is currently implemented in unix_state_lock(): spin_lock(&unix_sk(s)->lock), would be problematic. unix_state_lock() taken in a process context, followed by a softirq-context TC BPF program attempting to take the same spinlock -- deadlock[6]. This way we circled back to the peer check idea[2]. [1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/ [2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/ [3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/ [4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/ [5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/ [6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/ Summary of scenarios where af_unix/stream connect() may race a sockmap update: 1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys() Implemented NULL check is sufficient. Once assigned, socket peer won't be released until socket fd is released. And that's not an issue because sock_map_update_elem_sys() bumps fd refcnf. 2. connect() vs BPF program doing update Update restricted per verifier.c:may_update_sockmap() to BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only) BPF_PROG_TYPE_SOCKET_FILTER BPF_PROG_TYPE_SCHED_CLS BPF_PROG_TYPE_SCHED_ACT BPF_PROG_TYPE_XDP BPF_PROG_TYPE_SK_REUSEPORT BPF_PROG_TYPE_FLOW_DISSECTOR BPF_PROG_TYPE_SK_LOOKUP Plus one more race to consider: CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) = newsk sk_pair = unix_peer(sk) if (unlikely(!sk_pair)) return -EINVAL; CPU1 close ---------- skpair = unix_peer(sk); unix_peer(sk) = NULL; sock_put(skpair) // use after free? sock_hold(sk_pair) 2.1 BPF program invoking helper function bpf_sock_map_update() -> BPF_CALL_4(bpf_sock_map_update(), ...) Helper limited to BPF_PROG_TYPE_SOCK_OPS. Nevertheless, a unix sock might be accessible via bpf_map_lookup_elem(). Which implies sk already having psock, which in turn implies sk already having sk_pair. Since sk_psock_destroy() is queued as RCU work, sk_pair won't go away while BPF executes the update. 2.2 BPF program invoking helper function bpf_map_update_elem() -> sock_map_update_elem() 2.2.1 Unix sock accessible to BPF prog only via sockmap lookup in BPF_PROG_TYPE_SOCKET_FILTER, BPF_PROG_TYPE_SCHED_CLS, BPF_PROG_TYPE_SCHED_ACT, BPF_PROG_TYPE_XDP, BPF_PROG_TYPE_SK_REUSEPORT, BPF_PROG_TYPE_FLOW_DISSECTOR, BPF_PROG_TYPE_SK_LOOKUP. Pretty much the same as case 2.1. 2.2.2 Unix sock accessible to BPF program directly: BPF_PROG_TYPE_TRACING, narrowed down to BPF_TRACE_ITER. Sockmap iterator (sock_map_seq_ops) is safe: unix sock residing in a sockmap means that the sock already went through the proto update step. Unix sock iterator (bpf_iter_unix_seq_ops), on the other hand, gives access to socks that may still be unconnected. Which means iterator prog can race sockmap/proto update against connect(). BUG: KASAN: null-ptr-deref in unix_stream_bpf_update_proto+0x253/0x4d0 Write of size 4 at addr 0000000000000080 by task test_progs/3140 Call Trace: dump_stack_lvl+0x5d/0x80 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x253/0x4d0 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e While the introduced NULL check prevents null-ptr-deref in the BPF program path as well, it is insufficient to guard against a poorly timed close() leading to a use-after-free. This will be addressed in a subsequent patch. Fixes: c63829182c37 ("af_unix: Implement ->psock_update_sk_prot()") Closes: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/ Reported-by: Michal Luczaj Reported-by: 钱一铭 Suggested-by: Kuniyuki Iwashima Suggested-by: Martin KaFai Lau Signed-off-by: Michal Luczaj Signed-off-by: Martin KaFai Lau Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260414-unix-proto-update-null-ptr-deref-v4-4-2af6fe97918e@rbox.co Signed-off-by: Sasha Levin commit 66d9fab4565eafe1afe7ba0581f79b76073b60fa Author: Michal Luczaj Date: Tue Apr 14 16:13:16 2026 +0200 bpf, sockmap: Fix af_unix iter deadlock [ Upstream commit 4d328dd695383224aa750ddee6b4ad40c0f8d205 ] bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast path and the iter prog attempts to update a sockmap. Which ends up spinning at sock_map_update_elem()'s bh_lock_sock(): WARNING: possible recursive locking detected test_progs/1393 is trying to acquire lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0 but task is already holding lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(slock-AF_UNIX); lock(slock-AF_UNIX); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by test_progs/1393: #0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0 #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0 #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00 Call Trace: dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0 _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 bpf_iter_run_prog+0x5b9/0xb00 bpf_iter_unix_seq_show+0x1f7/0x2e0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 2c860a43dd77 ("bpf: af_unix: Implement BPF iterator for UNIX domain socket.") Suggested-by: Kuniyuki Iwashima Suggested-by: Martin KaFai Lau Signed-off-by: Michal Luczaj Signed-off-by: Martin KaFai Lau Reviewed-by: Jiayuan Chen Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260414-unix-proto-update-null-ptr-deref-v4-2-2af6fe97918e@rbox.co Signed-off-by: Sasha Levin commit af0b4175cde4df56f300a360f5489de5422b7f1e Author: Puranjay Mohan Date: Mon Apr 13 12:11:09 2026 -0700 bpf, riscv: Remove redundant bpf_flush_icache() after pack allocator finalize [ Upstream commit 46ee1342b887c9387a933397d846ff6c9584322c ] bpf_flush_icache() calls flush_icache_range() to clean the data cache and invalidate the instruction cache for the JITed code region. However, since commit 48a8f78c50bd ("bpf, riscv: use prog pack allocator in the BPF JIT"), this flush is redundant. bpf_jit_binary_pack_finalize() copies the JITed instructions to the ROX region via bpf_arch_text_copy() -> patch_text_nosync(), and patch_text_nosync() already calls flush_icache_range() on the written range. The subsequent bpf_flush_icache() repeats the same cache maintenance on an overlapping range. Remove the redundant bpf_flush_icache() call and its now-unused definition. Fixes: 48a8f78c50bd ("bpf, riscv: use prog pack allocator in the BPF JIT") Acked-by: Song Liu Signed-off-by: Puranjay Mohan Reviewed-by: Pu Lehui Tested-by: Paul Chaignon Link: https://lore.kernel.org/r/20260413191111.3426023-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 31725056c28073882ae341d85fb4877e91bb7a04 Author: Puranjay Mohan Date: Mon Apr 13 12:11:08 2026 -0700 bpf, arm64: Remove redundant bpf_flush_icache() after pack allocator finalize [ Upstream commit 42f18ae53011826cfd3c84d041817e7f07bc645b ] bpf_flush_icache() calls flush_icache_range() to clean the data cache and invalidate the instruction cache for the JITed code region. However, since commit 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management"), this flush is redundant. bpf_jit_binary_pack_finalize() copies the JITed instructions to the ROX region via bpf_arch_text_copy() -> aarch64_insn_copy() -> __text_poke(), and __text_poke() already calls flush_icache_range() on the written range. The subsequent bpf_flush_icache() repeats the same cache maintenance on an overlapping range, including an unnecessary second synchronous IPI to all CPUs via kick_all_cpus_sync(). Remove the redundant bpf_flush_icache() call and its now-unused definition. Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management") Acked-by: Song Liu Signed-off-by: Puranjay Mohan Acked-by: Breno Leitao Link: https://lore.kernel.org/r/20260413191111.3426023-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fb74defa1cca1a73177c0c761e641332e4f979a3 Author: Daniel Borkmann Date: Wed Apr 15 14:14:03 2026 +0200 bpf, arm64: Fix off-by-one in check_imm signed range check [ Upstream commit 1dd8be4ec722ce54e4cace59f3a4ba658111b3ec ] check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side. In particular, for check_imm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64_insn_encode_immediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced. Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260415121403.639619-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ef8b238f1a908a5fc8702297c5f32d5c24ba1612 Author: Daniel Borkmann Date: Wed Apr 15 14:14:02 2026 +0200 bpf, arm64: Reject out-of-range B.cond targets [ Upstream commit 48d83d94930eb4db4c93d2de44838b9455cff626 ] aarch64_insn_gen_cond_branch_imm() calls label_imm_common() to compute a 19-bit signed byte offset for a conditional branch, but unlike its siblings aarch64_insn_gen_branch_imm() and aarch64_insn_gen_comp_branch_imm(), it does not check whether label_imm_common() returned its out-of-range sentinel (range) before feeding the value to aarch64_insn_encode_immediate(). aarch64_insn_encode_immediate() unconditionally masks the value with the 19-bit field mask, so an offset that was rejected by label_imm_common() gets silently truncated. With the sentinel value SZ_1M, the resulting field ends up with bit 18 (the sign bit of the 19-bit signed displacement) set, and the CPU decodes it as a ~1 MiB *backward* branch, producing an incorrectly targeted B.cond instruction. For code-gen locations like the emit_bpf_tail_call() this function is the only barrier between an overflowing displacement and a silently miscompiled branch. Fix it by returning AARCH64_BREAK_FAULT when the offset is out of range, so callers see a loud failure instead of a silently misencoded branch. validate_code() scans the generated image for any AARCH64_BREAK_FAULT and then lets the JIT fail. Fixes: 345e0d35ecdd ("arm64: introduce aarch64_insn_gen_cond_branch_imm()") Fixes: c94ae4f7c5ec ("arm64: insn: remove BUG_ON from codegen") Signed-off-by: Daniel Borkmann Reviewed-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260415121403.639619-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 0695647c81adc2ab344518c9fff30d8cb0017643 Author: Ye Bin Date: Mon Mar 30 21:30:35 2026 +0800 ext4: fix possible null-ptr-deref in mbt_kunit_exit() [ Upstream commit 22f53f08d9eb837ce69b1a07641d414aac8d045f ] There's issue as follows: # test_new_blocks_simple: failed to initialize: -12 KASAN: null-ptr-deref in range [0x0000000000000638-0x000000000000063f] Tainted: [E]=UNSIGNED_MODULE, [N]=TEST RIP: 0010:mbt_kunit_exit+0x5e/0x3e0 [ext4_test] Call Trace: kunit_try_run_case_cleanup+0xbc/0x100 [kunit] kunit_generic_run_threadfn_adapter+0x89/0x100 [kunit] kthread+0x408/0x540 ret_from_fork+0xa76/0xdf0 ret_from_fork_asm+0x1a/0x30 If mbt_kunit_init() init testcase failed will lead to null-ptr-deref. So add test if 'sb' is inited success in mbt_kunit_exit(). Fixes: 7c9fa399a369 ("ext4: add first unit test for ext4_mb_new_blocks_simple in mballoc") Signed-off-by: Ye Bin Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Ojaswin Mujoo Link: https://patch.msgid.link/20260330133035.287842-6-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit ce7cc3aadbb065eedfdc9a9a06eb39b9652934e8 Author: Ye Bin Date: Mon Mar 30 21:30:34 2026 +0800 ext4: fix possible null-ptr-deref in extents_kunit_exit() [ Upstream commit ca78c31af467ffe94b15f6a2e4e1cc1c164db19b ] There's issue as follows: KASAN: null-ptr-deref in range [0x00000000000002c0-0x00000000000002c7] Tainted: [E]=UNSIGNED_MODULE, [N]=TEST RIP: 0010:extents_kunit_exit+0x2e/0xc0 [ext4_test] Call Trace: kunit_try_run_case_cleanup+0xbc/0x100 [kunit] kunit_generic_run_threadfn_adapter+0x89/0x100 [kunit] kthread+0x408/0x540 ret_from_fork+0xa76/0xdf0 ret_from_fork_asm+0x1a/0x30 Above issue happens as extents_kunit_init() init testcase failed. So test if testcase is inited success. Fixes: cb1e0c1d1fad ("ext4: kunit tests for extent splitting and conversion") Signed-off-by: Ye Bin Reviewed-by: Ojaswin Mujoo Reviewed-by: Ritesh Harjani (IBM) Link: https://patch.msgid.link/20260330133035.287842-5-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 04d5200ea735cc86d6b2f43944d87af0f2329202 Author: Ye Bin Date: Mon Mar 30 21:30:33 2026 +0800 ext4: fix the error handling process in extents_kunit_init). [ Upstream commit 17f73c95d47325000ee68492be3ad76ae09f6f19 ] The error processing in extents_kunit_init() is improper, causing resource leakage. Reconstruct the error handling process to prevent potential resource leaks Fixes: cb1e0c1d1fad ("ext4: kunit tests for extent splitting and conversion") Signed-off-by: Ye Bin Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Ojaswin Mujoo Link: https://patch.msgid.link/20260330133035.287842-4-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit b98c5628b8b9d09bc3944e3518957920214473c9 Author: Ye Bin Date: Mon Mar 30 21:30:32 2026 +0800 ext4: call deactivate_super() in extents_kunit_exit() [ Upstream commit f9c1f7647ac8fb70bebb1615ac112d1568abe339 ] Call deactivate_super() is called in extents_kunit_exit() to cleanup the file system resource. Fixes: cb1e0c1d1fad ("ext4: kunit tests for extent splitting and conversion") Signed-off-by: Ye Bin Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Ojaswin Mujoo Link: https://patch.msgid.link/20260330133035.287842-3-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 869d8395c8b41b12d4109a04a728cc6d2db9295c Author: Ye Bin Date: Mon Mar 30 21:30:31 2026 +0800 ext4: fix miss unlock 'sb->s_umount' in extents_kunit_init() [ Upstream commit 5941a072d48841255005e3a5b5a620692d81d1a7 ] There's warning as follows when do ext4 kunit test: WARNING: kunit_try_catch/15923 still has locks held! 7.0.0-rc3-next-20260309-00028-g73f965a1bbb1-dirty #281 Tainted: G E N 1 lock held by kunit_try_catch/15923: #0: ffff888139f860e0 (&type->s_umount_key#70/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x172/0xa90 Call Trace: dump_stack_lvl+0x180/0x1b0 debug_check_no_locks_held+0xc8/0xd0 do_exit+0x1502/0x2b20 kthread+0x3a9/0x540 ret_from_fork+0xa76/0xdf0 ret_from_fork_asm+0x1a/0x30 As sget() will return 'sb' which holds 's->s_umount' lock. However, "extents-test" miss unlock this lock. So unlock 's->s_umount' in the end of extents_kunit_init(). Fixes: cb1e0c1d1fad ("ext4: kunit tests for extent splitting and conversion") Signed-off-by: Ye Bin Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Ojaswin Mujoo Link: https://patch.msgid.link/20260330133035.287842-2-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit b3d16611d7cd78e9d5c6baa19b61b7caf9f1ab5e Author: Oliver Neukum Date: Tue Mar 24 15:24:54 2026 +0100 HID: usbhid: fix deadlock in hid_post_reset() [ Upstream commit 8df2c1b47ee3cd50fd454f75c7a7e2ae8a6adf72 ] You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them. Fixes: dc3c78e434690 ("HID: usbhid: Check HID report descriptor contents after device reset") Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit e7820f84d59c7f381f6218554c933ad65330d067 Author: Miquel Raynal Date: Wed Mar 18 11:47:50 2026 +0100 mtd: spinand: winbond: Clarify when to enable the HS bit [ Upstream commit 25a915fad503c2678902075565d47ddc2aa45db9 ] Above 104MHz when in fast dual or quad I/O reads, the delay between address and data cycles is too short. It is possible to reach higher frequencies, up to 166MHz, by adding a few more dummy cycles through the setting of the HS bit. Improve the condition for enabling this bit, and also make sure we set it at soon as we go over 104MHz. Fixes: f1a91175faaa ("mtd: spinand: winbond: Enable high-speed modes on w25n0xjw") Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 555b9e6fce3042a4062b363760333519b0392871 Author: Richard Genoud Date: Tue Mar 17 15:24:30 2026 +0100 mtd: rawnand: sunxi: fix sunxi_nfc_hw_ecc_read_extra_oob [ Upstream commit 848c13996c55fe4ea6bf5acc3ce6c8c5c944b5f6 ] When dumping the OOB, the bytes at the end where actually copied from the beginning of the OOB instead of current_offset. That leads to something like: OOB: ff ff ff ff ff ff ff ff ea 19 00 3a 83 db aa 8d OOB: 99 09 c8 9a 90 36 35 7d aa 15 13 07 3d 97 b2 a4 OOB: a8 bb 19 b3 07 e9 f6 25 52 d7 1a 23 e2 7e 0a e4 OOB: 52 8a 09 d2 1a 86 3d cf b4 99 43 13 d3 90 33 0b OOB: ff ff ff ff ff ff ff ff ea 19 00 3a 83 db aa 8d OOB: 99 09 c8 9a 90 36 35 7d aa 15 13 07 3d 97 b2 a4 OOB: a8 bb 19 b3 07 e9 f6 25 52 d7 1a 23 e2 7e 0a e4 OOB: 52 8a 09 d2 1a 86 3d cf b4 99 43 13 d3 90 33 0b instead of: OOB: ff ff ff ff ff ff ff ff ea 19 00 3a 83 db aa 8d OOB: 99 09 c8 9a 90 36 35 7d aa 15 13 07 3d 97 b2 a4 OOB: a8 bb 19 b3 07 e9 f6 25 52 d7 1a 23 e2 7e 0a e4 OOB: 52 8a 09 d2 1a 86 3d cf b4 99 43 13 d3 90 33 0b OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff (example with BCH16, user data [8,0], no scrambling) *cur_off (offset from the beginning of the page) was compared to offset (offset from the beginning of the OOB), and then, the nand_change_read_column_op() sets the current position to the beginning of the OOB instead of OOB+offset Fixes: 15d6f118285f ("mtd: rawnand: sunxi: Stop supporting ECC_HW_SYNDROME mode") Reviewed-by: Jernej Skrabec Signed-off-by: Richard Genoud Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit e65a26829a6352c039f3e5b0efcc0061f987a426 Author: Li Ming Date: Sat Mar 14 15:06:33 2026 +0800 cxl/pci: Check memdev driver binding status in cxl_reset_done() [ Upstream commit e8069c66d09309579e53567be8ddfa6ccb2f452a ] cxl_reset_done() accesses the endpoint of the corresponding CXL memdev without endpoint validity checking. By default, cxlmd->endpoint is initialized to -ENXIO, if cxl_reset_done() is triggered after the corresponding CXL memdev probing failed, this results in access to an invalid endpoint. CXL subsystem can always check CXL memdev driver binding status to confirm its endpoint validity. So adding the CXL memdev driver checking inside cxl_reset_done() to avoid accessing an invalid endpoint. Fixes: 934edcd436dc ("cxl: Add post-reset warning if reset results in loss of previously committed HDM decoders") Reviewed-by: Dan Williams Reviewed-by: Dave Jiang Signed-off-by: Li Ming Link: https://patch.msgid.link/20260314-fix_access_endpoint_without_drv_check-v2-4-4c09edf2e1db@zohomail.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit 6ea62254934d1c518da9b44d5371e6ad9d616859 Author: Cosmin Tanislav Date: Wed Mar 11 17:39:57 2026 +0200 mtd: parsers: ofpart: call of_node_get() for dedicated subpartitions [ Upstream commit e882626c1747653f1f01ea9d12e278e613b11d0f ] In order to parse sub-partitions, add_mtd_partitions() calls parse_mtd_partitions() for all previously found partitions. Each partition will end up being passed to parse_fixed_partitions(), and its of_node will be treated as the ofpart_node. Commit 7cce81df7d26 ("mtd: parsers: ofpart: fix OF node refcount leak in parse_fixed_partitions()") added of_node_put() calls for ofpart_node on all exit paths. In the case where the partition passed to parse_fixed_partitions() has a parent, it is treated as a dedicated partitions node, and of_node_put() is wrongly called for it, even if of_node_get() was not called explicitly. On repeated bind / unbinds of the MTD, the extra of_node_put() ends up decrementing the refcount down to 0, which should never happen, resulting in the following error: OF: ERROR: of_node_release() detected bad of_node_put() on /soc/spi@80007000/flash@0/partitions/partition@0 Call of_node_get() to balance the call to of_node_put() done for dedicated partitions nodes. Fixes: 7cce81df7d26 ("mtd: parsers: ofpart: fix OF node refcount leak in parse_fixed_partitions()") Signed-off-by: Cosmin Tanislav Tested-by: Tommaso Merciai Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 564eead065319a78ff3e71ac18c9e01dc62def58 Author: Cosmin Tanislav Date: Wed Mar 11 17:39:56 2026 +0200 mtd: parsers: ofpart: call of_node_put() only in ofpart_fail path [ Upstream commit 0c87dea1aab86116211cb37387c404c9e9231c39 ] ofpart_none can only be reached after the for_each_child_of_node() loop finishes. for_each_child_of_node() correctly calls of_node_put() for all device nodes it iterates over as long as we don't break or jump out of the loop. Calling of_node_put() inside the ofpart_none path will wrongly decrement the ref count of the last node in the for_each_child_of_node() loop. Move the call to of_node_put() under the ofpart_fail label to fix this. Fixes: ebd5a74db74e ("mtd: ofpart: Check availability of reg property instead of name property") Signed-off-by: Cosmin Tanislav Tested-by: Tommaso Merciai Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit f110ecdcfde7be57e96a43bf67f05c52c6135f5d Author: Shiji Yang Date: Wed Jan 28 20:42:56 2026 +0800 mtd: spi-nor: swp: check SR_TB flag when getting tb_mask [ Upstream commit 94645aa41bf9ecb87c2ce78b1c3405bfb6074a37 ] When the chip does not support top/bottom block protect, the tb_mask must be set to 0, otherwise SR1 bit5 will be unexpectedly modified. Signed-off-by: Shiji Yang Fixes: 3dd8012a8eeb ("mtd: spi-nor: add TB (Top/Bottom) protect support") Reviewed-by: Michael Walle Reviewed-by: Miquel Raynal Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Sasha Levin commit 855ddfdd662399a24e8ed52b7d9faba744bfade5 Author: Haibo Chen Date: Tue Dec 23 11:01:02 2025 +0800 mtd: spi-nor: micron-st: add SNOR_CMD_PP_8_8_8_DTR sfdp fixup for mt35xu512aba [ Upstream commit 6d660fba6a32a34ad7d746d7f65317831daaf033 ] Find two batches mt35xu512aba has different SFDP but with same jedec ID. The batch which use the new version of SFDP contain all the necessary information to support OCT DTR mode. The batch with old version do not contain the OCT DTR command information, but in fact it did support OCT DTR mode. Current mt35xu512aba_post_sfdp_fixup() add some setting including SNOR_CMD_READ_8_8_8_DTR, but still lack SNOR_CMD_PP_8_8_8_DTR. Meet issue on the batch mt35xu512aba with old SFDP version. Because no SNOR_CMD_PP_8_8_8_DTR, micron_st_nor_octal_dtr_en() will not be called, then use SNOR_CMD_READ_8_8_8_DTR will meet issue. Fixes: 44dd635cd632 ("mtd: spi-nor: micron-st: use SFDP of mt35xu512aba") Reviewed-by: Pratyush Yadav Signed-off-by: Haibo Chen Reviewed-by: Michael Walle [pratyush@kernel.org: touch up the comment a bit] Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Sasha Levin commit 2cc81d97cd7bfa23e08ad457de35348120c7dcbd Author: Jonas Gorski Date: Thu Dec 18 10:54:30 2025 +0100 mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation [ Upstream commit 3620d67b48493c6252bbc873dc88dde81641d56b ] After commit 5273cc6df984 ("mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only when SFDP is defined") spi_nor_post_sfdp_fixups() isn't called anymore if no SFDP is detected. Update the documentation accordingly. Fixes: 5273cc6df984 ("mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only when SFDP is defined") Signed-off-by: Jonas Gorski Reviewed-by: Pratyush Yadav Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Sasha Levin commit b9feb10f37a60a5e6a34ab5c2913a09f2181fe66 Author: Haibo Chen Date: Mon Dec 8 17:14:14 2025 +0800 mtd: spi-nor: core: correct the op.dummy.nbytes when check read operations [ Upstream commit 756564a536ecd8c9d33edd89f0647a91a0b03587 ] When check read operation, need to setting the op.dummy.nbytes based on current read operation rather than the nor->read_proto. Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Signed-off-by: Haibo Chen Reviewed-by: Pratyush Yadav Signed-off-by: Pratyush Yadav (Google) Signed-off-by: Sasha Levin commit 12e5a04b31a18b65310bc2a55c029cc7ad45df6d Author: Geert Uytterhoeven Date: Fri Mar 6 11:26:20 2026 +0100 dt-bindings: interrupt-controller: arm,gic-v3: Fix EPPI range [ Upstream commit 15cfc8984defc17e5e4de1f58db7b993240fcbda ] According to the "Arm Generic Interrupt Controller (GIC) Architecture Specification, v3 and v4", revision H.b[1], there can be only 64 Extended PPI interrupts. [1] https://developer.arm.com/documentation/ihi0069/hb/ Fixes: 4b049063e0bcbfd3 ("dt-bindings: interrupt-controller: arm,gic-v3: Describe EPPI range support") Signed-off-by: Geert Uytterhoeven Brain-farted-by: Marc Zyngier Acked-by: Marc Zyngier Link: https://patch.msgid.link/3e49a63c6b2b6ee48e3737adee87781f9c136c5f.1772792753.git.geert+renesas@glider.be Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 88d4e89a39f0de07798ca3fd93bd1a9ea212a82e Author: Dmitry Safonov <0x7f454c46@gmail.com> Date: Tue Mar 10 17:40:39 2026 +0000 ima_fs: Correctly create securityfs files for unsupported hash algos [ Upstream commit d7bd8cf0b348d3edae7bee33e74a32b21668b181 ] ima_tpm_chip->allocated_banks[i].crypto_id is initialized to HASH_ALGO__LAST if the TPM algorithm is not supported. However there are places relying on the algorithm to be valid because it is accessed by hash_algo_name[]. On 6.12.40 I observe the following read out-of-bounds in hash_algo_name: ================================================================== BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440 Read of size 8 at addr ffffffff83e18138 by task swapper/0/1 CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3 Call Trace: dump_stack_lvl+0x61/0x90 print_report+0xc4/0x580 ? kasan_addr_to_slab+0x26/0x80 ? create_securityfs_measurement_lists+0x396/0x440 kasan_report+0xc2/0x100 ? create_securityfs_measurement_lists+0x396/0x440 create_securityfs_measurement_lists+0x396/0x440 ima_fs_init+0xa3/0x300 ima_init+0x7d/0xd0 init_ima+0x28/0x100 do_one_initcall+0xa6/0x3e0 kernel_init_freeable+0x455/0x740 kernel_init+0x24/0x1d0 ret_from_fork+0x38/0x80 ret_from_fork_asm+0x11/0x20 The buggy address belongs to the variable: hash_algo_name+0xb8/0x420 Memory state around the buggy address: ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9 ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9 ^ ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9 ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 ================================================================== Seems like the TPM chip supports sha3_256, which isn't yet in tpm_algorithms: tpm tpm0: TPM with unsupported bank algorithm 0x0027 That's TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0 Library Part 2: Structures", page 51 [1]. See also the related U-Boot algorithms update [2]. Thus solve the problem by creating a file name with "_tpm_alg_" postfix if the crypto algorithm isn't initialized. This is how it looks on the test machine (patch ported to v6.12 release): # ls -1 /sys/kernel/security/ima/ ascii_runtime_measurements ascii_runtime_measurements_tpm_alg_27 ascii_runtime_measurements_sha1 ascii_runtime_measurements_sha256 binary_runtime_measurements binary_runtime_measurements_tpm_alg_27 binary_runtime_measurements_sha1 binary_runtime_measurements_sha256 policy runtime_measurements_count violations [1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf [2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm") Signed-off-by: Dmitry Safonov Cc: Enrico Bravi Cc: Silvia Sisinni Cc: Roberto Sassu Cc: Mimi Zohar Reviewed-by: Roberto Sassu Tested-by: Roberto Sassu Link: https://github.com/linux-integrity/linux/issues/14 Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 599ceeb01b1f3bc6e6bf6a0b7a3d35264d52b440 Author: Chen Ni Date: Fri Feb 27 09:43:36 2026 +0800 mtd: physmap_of_gemini: Fix disabled pinctrl state check [ Upstream commit b7c0982184b0661f5b1b805f3a56f1bd3757b63e ] The condition for checking the disabled pinctrl state incorrectly checks gf->enabled_state instead of gf->disabled_state. This causes misleading error messages and could lead to incorrect behavior when only one of the pinctrl states is defined. Fix the condition to properly check gf->disabled_state. Fixes: 9d3b5086f6d4 ("mtd: physmap_of_gemini: Handle pin control") Signed-off-by: Chen Ni Reviewed-by: Linus Walleij Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit b98e4e57e34d099a8f846fa54749654082975ea0 Author: Krzysztof Kozlowski Date: Thu Mar 5 22:45:43 2026 +0100 power: supply: max77705: Free allocated workqueue and fix removal order [ Upstream commit 1e668baadefb16e81269dbfebf3ffc2672e3a3bb ] Use devm interface for allocating workqueue to fix two bugs at the same time: 1. Driver leaks the memory on remove(), because the workqueue is not destroyed. 2. Driver allocates workqueue and then registers interrupt handlers with devm interface. This means that probe error paths will not use a reversed order, but first destroy the workqueue and then, via devm release handlers, free the interrupt. The interrupt handler schedules work on this exact workqueue, thus if interrupt is hit in this short time window - after destroying workqueue, but before devm() frees the interrupt - the schedulled work will lead to use of freed memory. Change is not equivalent in the workqueue itself: use non-legacy API which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is used to update power supply (power_supply_changed()) status, thus there is no point to run it for memory reclaim. Note that dev_name() is not directly used in second argument to prevent possible unlikely parsing any "%" character in device name as format. Fixes: 11741b8e382d ("power: supply: max77705: Fix workqueue error handling in probe") Fixes: a6a494c8e3ce ("power: supply: max77705: Add charger driver for Maxim 77705") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260305-workqueue-devm-v2-4-66a38741c652@oss.qualcomm.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 8031b683f0681fc6c9582d8ae6900b05771091c7 Author: Krzysztof Kozlowski Date: Thu Mar 5 22:45:42 2026 +0100 power: supply: max77705: Drop duplicated IRQ error message [ Upstream commit 2064c64ceb1996ee02a6bbb1de05fd6e8028e3e4 ] Core already prints error message on devm_request_threaded_irq() failure, so no need to do that second time. Suggested-by: Andy Shevchenko Signed-off-by: Krzysztof Kozlowski Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260305-workqueue-devm-v2-3-66a38741c652@oss.qualcomm.com Signed-off-by: Sebastian Reichel Stable-dep-of: 1e668baadefb ("power: supply: max77705: Free allocated workqueue and fix removal order") Signed-off-by: Sasha Levin commit adfb9fb9072ceec110b6243fd3a97ff0dee5bf86 Author: Krzysztof Kozlowski Date: Thu Mar 5 22:45:40 2026 +0100 workqueue: devres: Add device-managed allocate workqueue [ Upstream commit 1dfc9d60a69ec148e1cb709256617d86e5f0e8f8 ] Add a Resource-managed version of alloc_workqueue() to fix common problem of drivers mixing devm() calls with destroy_workqueue. Such naive and discouraged driver approach leads to difficult to debug bugs when the driver: 1. Allocates workqueue in standard way and destroys it in driver remove() callback, 2. Sets work struct with devm_work_autocancel(), 3. Registers interrupt handler with devm_request_threaded_irq(). Which leads to following unbind/removal path: 1. destroy_workqueue() via driver remove(), Any interrupt coming now would still execute the interrupt handler, which queues work on destroyed workqueue. 2. devm_irq_release(), 3. devm_work_drop() -> cancel_work_sync() on destroyed workqueue. devm_alloc_workqueue() has two benefits: 1. Solves above problem of mix-and-match devres and non-devres code in driver, 2. Simplify any sane drivers which were correctly using alloc_workqueue() + devm_add_action_or_reset(). Signed-off-by: Krzysztof Kozlowski Acked-by: Tejun Heo Reviewed-by: Andy Shevchenko Signed-off-by: Tejun Heo Stable-dep-of: 1e668baadefb ("power: supply: max77705: Free allocated workqueue and fix removal order") Signed-off-by: Sasha Levin commit 72ac18e2d1b98f963d1ddf6af00e0c73dc820b7f Author: Denis Benato Date: Sat Feb 28 20:10:09 2026 +0100 HID: asus: do not abort probe when not necessary [ Upstream commit 7253091766ded0fd81fe8d8be9b8b835495b06e8 ] In order to avoid dereferencing a NULL pointer asus_probe is aborted early and control of some asus devices is transferred over hid-generic after erroring out even when such NULL dereference cannot happen: only early abort when the NULL dereference can happen. Also make the code shorter and more adherent to coding standards removing square brackets enclosing single-line if-else statements. Fixes: d3af6ca9a8c3 ("HID: asus: fix UAF via HID_CLAIMED_INPUT validation") Signed-off-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 604da0fddbfa05f1d8be9f91541445bb8b1801c3 Author: Denis Benato Date: Sat Feb 28 20:10:07 2026 +0100 HID: asus: make asus_resume adhere to linux kernel coding standards [ Upstream commit 51d33b42b8ae23da92819d28439fdd5636c45186 ] Linux kernel coding standars requires functions opening brackets to be in a newline: move the opening bracket of asus_resume in its own line. Fixes: 546edbd26cff ("HID: hid-asus: reset the backlight brightness level on resume") Signed-off-by: Denis Benato Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a10ce8c819b5324d6109f9c4330c24fa0945bce6 Author: Daniel Hodges Date: Sat Jan 31 18:40:15 2026 -0800 ima: check return value of crypto_shash_final() in boot aggregate [ Upstream commit 870819434c8dfcc3158033b66e7851b81bb17e21 ] The return value of crypto_shash_final() is not checked in ima_calc_boot_aggregate_tfm(). If the hash finalization fails, the function returns success and a corrupted boot aggregate digest could be used for IMA measurements. Capture the return value and propagate any error to the caller. Fixes: 76bb28f6126f ("ima: use new crypto_shash API instead of old crypto_hash") Signed-off-by: Daniel Hodges Reviewed-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit cc06fcd1f238283369ef060561eea0f4aac737a8 Author: Chen Ni Date: Mon Feb 9 13:14:07 2026 +0800 remoteproc: imx_rproc: Check return value of regmap_attach_dev() in imx_rproc_mmio_detect_mode() [ Upstream commit a48c6676912fb808d2af1b8344d8656815a3e108 ] Add error checking for regmap_attach_dev() call in imx_rproc_mmio_detect_mode() function to ensure proper error propagation. Return the value of regmap_attach_dev() if it fails to prevent proceeding with an incomplete regmap setup. Suggested-by: Peng Fan Signed-off-by: Chen Ni Fixes: e14168bf3493 ("remoteproc: imx_rproc: Simplify IMX_RPROC_MMIO switch case") Link: https://lore.kernel.org/r/20260209051407.1467660-1-nichen@iscas.ac.cn Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit fa7497e9a7940e7b6ae3312c6af50aad8fb2fb1d Author: Thomas Weißschuh Date: Tue Feb 17 14:11:11 2026 +0100 stop_machine: Fix the documentation for a NULL cpus argument [ Upstream commit 48f7a50c027dd2abb9e7b8a6ecc8e531d87f2c21 ] A recent refactoring of the kernel-docs for stop machine changed the description of the cpus parameter from "NULL = any online cpu" to "NULL = run on each online CPU". However the callback is only executed on a single CPU, not all of them. The old wording was a bit ambiguous and could have been read both ways. Reword the documentation to be correct again and hopefully also clearer. Fixes: fc6f89dc7078 ("stop_machine: Improve kernel-doc function-header comments") Signed-off-by: Thomas Weißschuh Signed-off-by: Paul E. McKenney Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Sasha Levin commit 91f3237e49035db75dce69cf2ead2eb1d48addde Author: Tim Michals Date: Wed Feb 4 12:27:30 2026 -0800 remoteproc: xlnx: Fix sram property parsing [ Upstream commit d116bccf6f1c199b27c9ebdf07cc3cfe868f919c ] As per sram bindings, "sram" property can be list of phandles. When more than one sram phandles are listed, driver can't parse second phandle's address correctly. Because, phandle index is passed to the API instead of offset of address from reg property which is always 0 as per sram.yaml bindings. Fix it by passing 0 to the API instead of sram phandle index. Fixes: 77fcdf51b8ca ("remoteproc: xlnx: Add sram support") Signed-off-by: Tim Michals Signed-off-by: Tanmay Shah Link: https://lore.kernel.org/r/20260204202730.3729984-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 583fd691dfce9f247f91af87dd8774dce197f8e2 Author: Francesco Lavra Date: Wed Nov 26 11:46:18 2025 +0100 hte: tegra194: remove Kconfig dependency on Tegra194 SoC [ Upstream commit 92dfd92f747698352b256cd9ddd7497bb7ebe9c8 ] This driver runs also on other Tegra SoCs (e.g. Tegra234). Replace Kconfig dependency on Tegra194 with more generic dependency on Tegra, and amend the Kconfig help text to reflect the fact that this driver works on SoCs other than Tegra194. Fixes: b003fb5c9df8 ("hte: Add Tegra234 provider") Signed-off-by: Francesco Lavra Acked-by: Dipen Patel Signed-off-by: Dipen Patel Signed-off-by: Sasha Levin commit 6929e650db8451a9975ac0a631ba2d6e5d1e80ba Author: Pengpeng Hou Date: Wed Apr 1 19:22:23 2026 +0800 tracing: Rebuild full_name on each hist_field_name() call [ Upstream commit 5ec1d1e97de134beed3a5b08235a60fc1c51af96 ] hist_field_name() uses a static MAX_FILTER_STR_VAL buffer for fully qualified variable-reference names, but it currently appends into that buffer with strcat() without rebuilding it first. As a result, repeated calls append a new "system.event.field" name onto the previous one, which can eventually run past the end of full_name. Build the name with snprintf() on each call and return NULL if the fully qualified name does not fit in MAX_FILTER_STR_VAL. Link: https://patch.msgid.link/20260401112224.85582-1-pengpeng@iscas.ac.cn Fixes: 067fe038e70f ("tracing: Add variable reference handling to hist triggers") Reviewed-by: Tom Zanussi Tested-by: Tom Zanussi Signed-off-by: Pengpeng Hou Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit b086fb945ab4009b23511654544c3157f95007a5 Author: Arnd Bergmann Date: Tue Feb 3 17:45:29 2026 +0100 tracing: move __printf() attribute on __ftrace_vbprintk() [ Upstream commit 473e470f16f98569d59adc11c4a318780fb68fe9 ] The sunrpc change to use trace_printk() for debugging caused a new warning for every instance of dprintk() in some configurations, when -Wformat-security is enabled: fs/nfs/getroot.c: In function 'nfs_get_root': fs/nfs/getroot.c:90:17: error: format not a string literal and no format arguments [-Werror=format-security] 90 | nfs_errorf(fc, "NFS: Couldn't getattr on root"); I've been slowly chipping away at those warnings over time with the intention of enabling them by default in the future. While I could not figure out why this only happens for this one instance, I see that the __trace_bprintk() function is always called with a local variable as the format string, rather than a literal. Move the __printf(2,3) annotation on this function from the declaration to the caller. As this is can only be validated for literals, the attribute on the declaration causes the warnings every time, but removing it entirely introduces a new warning on the __ftrace_vbprintk() definition. The format strings still get checked because the underlying literal keeps getting passed into __trace_printk() in the "else" branch, which is not taken but still evaluated for compile-time warnings. Cc: Masami Hiramatsu Cc: Anna Schumaker Cc: Chuck Lever Cc: Simon Horman Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Yury Norov Cc: Randy Dunlap Link: https://patch.msgid.link/20260203164545.3174910-1-arnd@kernel.org Fixes: ec7d8e68ef0e ("sunrpc: add a Kconfig option to redirect dfprintk() output to trace buffer") Acked-by: Jeff Layton Acked-by: Steven Rostedt (Google) Signed-off-by: Arnd Bergmann Acked-by: Andy Shevchenko Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 2ce0b02ca080b50771ae93a0f959cd59c483bc2c Author: Richard Fitzgerald Date: Tue Mar 10 11:31:33 2026 +0000 soundwire: cadence: Clear message complete before signaling waiting thread [ Upstream commit cbfea84f820962c3c5394ff06e7e9344c96bf761 ] Clear the CDNS_MCP_INT_RX_WL interrupt before signaling completion. This is to prevent the potential race where: - The main thread is scheduled immediately the completion is signaled, and starts a new message - The RX_WL IRQ for this new message happens before sdw_cdns_irq() has been re-scheduled. - When sdw_cdns_irq() is re-scheduled it clears the new RX_WL interrupt. MAIN THREAD | IRQ THREAD | _cdns_xfer_msg() | { | write data to FIFO | wait_for_completion_timeout() | | <---- RX_WL IRQ | sdw_cdns_irq() | { | signal completion <== RESCHEDULE <== Handle message completion | } | | Start new message | _cdns_xfer_msg() | { | write data to FIFO | wait_for_completion_timeout() | | <---- RX_WL IRQ ==> RESCHEDULE ==> | // New RX_WL IRQ is cleared before | // it has been handled. | clear CDNS_MCP_INTSTAT | return IRQ_HANDLED; | } Before this change, this error message was sometimes seen on kernels that have large amounts of debugging enabled: SCP Msg trf timed out This error indicates that the completion has not been signalled after 500ms. Signed-off-by: Richard Fitzgerald Fixes: 956baa1992f9 ("soundwire: cdns: Add sdw_master_ops and IO transfer support") Reported-by: Norman Bintang Closes: https://issuetracker.google.com/issues/477099834 Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260310113133.1707288-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f8946bc58541c77c91710fcbc4c0dc8c312bdcdd Author: Frank Li Date: Wed Feb 25 16:41:38 2026 -0500 dmaengine: mxs-dma: Fix missing return value from of_dma_controller_register() [ Upstream commit ab2bf6d4c0a0152907b18d25c1b118ea5ea779df ] Propagate the return value of of_dma_controller_register() in probe() instead of ignoring it. Fixes: a580b8c5429a6 ("dmaengine: mxs-dma: add dma support for i.MX23/28") Signed-off-by: Frank Li Link: https://patch.msgid.link/20260225-mxsdma-module-v3-2-8f798b13baa6@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7c1537ee295b82ee2458c5ffa4790cc04a55eb4d Author: Bard Liao Date: Mon Jan 26 13:40:45 2026 +0800 soundwire: Intel: test bus.bpt_stream before assigning it [ Upstream commit b2c9f1d5a7eb50bcdda607afef1378e552bbb490 ] We only allow up to 1 bpt stream running on a SoundWire bus. bus.bpt_stream will be assigned when it is opened and will be set to NULL when it is closed. We do check bus->bpt_stream_refcount if the stream type is SDW_STREAM_BPT in sdw_master_rt_alloc(), but at that moment the bpt stream is allocated and set to bus.bpt_stream. It will lead to the original bus.bpt_stream be changed to the new and not used bpt stream. And it will be released and set to NULL when sdw_slave_bpt_stream_add() return error as it supposed to. Then the original stream will try to use the NULL bus.bpt_stream. Fixes: 4c1ce9f37d8a ("soundwire: intel_ace2x: add BPT send_async/wait callbacks") Reported-by: Simon Trimmer Signed-off-by: Bard Liao Reviewed-by: Simon Trimmer Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20260126054045.2504103-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 32224b89ba33320008bc6029dcb831384d05ecd3 Author: Cole Leavitt Date: Wed Feb 18 11:02:10 2026 -0700 soundwire: bus: demote UNATTACHED state warnings to dev_dbg() [ Upstream commit 2c96956fe764f8224f9ec93b2a9160a578949a7a ] The dev_warn() messages in sdw_handle_slave_status() for UNATTACHED transitions were added in commit d1b328557058 ("soundwire: bus: add dev_warn() messages to track UNATTACHED devices") to debug attachment failures with dynamic debug enabled. These warnings fire during normal operation -- for example when a codec driver triggers a hardware reset after firmware download, causing the device to momentarily go UNATTACHED before re-attaching -- producing misleading noise on every boot. Demote the messages to dev_dbg() so they remain available via dynamic debug for diagnosing real attachment failures without alarming users during expected initialization sequences. Fixes: d1b328557058 ("soundwire: bus: add dev_warn() messages to track UNATTACHED devices") Signed-off-by: Cole Leavitt Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260218180210.9263-1-cole@unwrap.rs Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 364893ebe288468de4b90c6c2ffb738f2720bc45 Author: Janne Grunau Date: Sun Feb 15 09:02:51 2026 +0100 phy: apple: apple: Use local variable for ioremap return value [ Upstream commit 290a35756aaef85bbe0527eaf451f533a61b5f6c ] The indirection through the resources array is unnecessarily complicated and resuling in using IS_ERR() and PTR_ERR() on a valid address. A local variable for the devm_ioremap_resource() return value is both easier to read and matches expectations when reading code. Reported-by: Dan Carpenter Closes: https://lore.kernel.org/asahi/aYXvX1bYOXtYCgfC@stanley.mountain/ Suggested-by: Vladimir Oltean Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY") Signed-off-by: Janne Grunau Reviewed-by: Sven Peter Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260215-phy-apple-resource-err-ptr-v2-1-e43c22453682@jannau.net Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit dda85d28d42125e4ed15682179751f872de4a01c Author: Khairul Anuar Romli Date: Mon Feb 2 14:02:19 2026 +0800 dmaengine: dw-axi-dmac: Remove unnecessary return statement from void function [ Upstream commit 48278a72fce8a8d30efaedeb206c9c3f05c1eb3f ] checkpatch.pl --strict reports a WARNING in dw-axi-dmac-platform.c: WARNING: void function return statements are not generally useful FILE: drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c According to Linux kernel coding style [Documentation/process/ coding-style.rst], explicit "return;" statements at the end of void functions are redundant and should be omitted. The function will automatically return upon reaching the closing brace, so the extra statement adds unnecessary clutter without functional benefit. This patch removes the superfluous "return;" statement in dw_axi_dma_set_hw_channel() to comply with kernel coding standards and eliminate the checkpatch warning. Fixes: 32286e279385 ("dmaengine: dw-axi-dmac: Remove free slot check algorithm in dw_axi_dma_set_hw_channel") Signed-off-by: Khairul Anuar Romli Link: https://patch.msgid.link/20260202060224.12616-4-karom.9560@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f893b872000478e6a599e19043e5194f944fab21 Author: Khairul Anuar Romli Date: Mon Feb 2 14:02:17 2026 +0800 dmaengine: dw-axi-dmac: fix Alignment should match open parenthesis [ Upstream commit 6c5883a9ba296d2797437066592d15b2d202de7a ] checkpatch.pl --strict reports a CHECK warning in dw-axi-dmac-platform.c: CHECK: Alignment should match open parenthesis This warning occurs when multi-line function calls or expressions have continuation lines that don't properly align with the opening parenthesis position. This patch fixes all instances in dw-axi-dmac-platform.c where continuation lines were indented with an inconsistent number of spaces/tabs that neither matched the parenthesis column nor followed a standard indent pattern. Proper alignment improves code readability and maintainability by making parameter lists visually consistent across the kernel codebase. Fixes: 1fe20f1b8454 ("dmaengine: Introduce DW AXI DMAC driver") Fixes: e32634f466a9 ("dma: dw-axi-dmac: support per channel interrupt") Signed-off-by: Khairul Anuar Romli Link: https://patch.msgid.link/20260202060224.12616-2-karom.9560@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6c5e70409c1961fe1278968f038eaaed6cc1145a Author: ZhengYuan Huang Date: Fri Apr 10 10:02:08 2026 +0800 ocfs2: validate group add input before caching [ Upstream commit 70b672833f4025341c11b22c7f83778a5cd611bc ] [BUG] OCFS2_IOC_GROUP_ADD can trigger a BUG_ON in ocfs2_set_new_buffer_uptodate(): kernel BUG at fs/ocfs2/uptodate.c:509! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_set_new_buffer_uptodate+0x194/0x1e0 fs/ocfs2/uptodate.c:509 Code: ffffe88f 42b9fe4c 89e64889 dfe8b4df Call Trace: ocfs2_group_add+0x3f1/0x1510 fs/ocfs2/resize.c:507 ocfs2_ioctl+0x309/0x6e0 fs/ocfs2/ioctl.c:887 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7bbfb55a966d [CAUSE] ocfs2_group_add() calls ocfs2_set_new_buffer_uptodate() on a user-controlled group block before ocfs2_verify_group_and_input() validates that block number. That helper is only valid for newly allocated metadata and asserts that the block is not already present in the chosen metadata cache. The code also uses INODE_CACHE(inode) even though the group descriptor belongs to main_bm_inode and later journal accesses use that cache context instead. [FIX] Validate the on-disk group descriptor before caching it, then add it to the metadata cache tracked by INODE_CACHE(main_bm_inode). Keep the validation failure path separate from the later cleanup path so we only remove the buffer from that cache after it has actually been inserted. This keeps the group buffer lifetime consistent across validation, journaling, and cleanup. Link: https://lkml.kernel.org/r/20260410020209.3786348-1-gality369@gmail.com Fixes: 7909f2bf8353 ("[PATCH 2/2] ocfs2: Implement group add for online resize") Signed-off-by: ZhengYuan Huang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit e0dcf12665d6dde37facf790803cdad44d5c328c Author: ZhengYuan Huang Date: Fri Apr 10 11:42:20 2026 +0800 ocfs2: validate bg_bits during freefrag scan [ Upstream commit 8f687eeed3da3012152b0f9473f578869de0cd7b ] [BUG] A crafted filesystem can trigger an out-of-bounds bitmap walk when OCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT. BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 [inline] kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200 __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] test_bit_le include/asm-generic/bitops/le.h:21 [inline] ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828 ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 ... [CAUSE] ocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as the bitmap scan limit. The coherent path reads group descriptors through ocfs2_read_group_descriptor(), which validates the descriptor before use. The non-coherent path uses ocfs2_read_blocks_sync() instead and skips that validation, so an impossible bg_bits value can drive the bitmap walk past the end of the block. [FIX] Compute the bitmap capacity from the filesystem format with ocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds that limit, and clamp the scan to the computed capacity. This keeps the freefrag report going while avoiding reads beyond the buffer. Link: https://lkml.kernel.org/r/20260410034220.3825769-1-gality369@gmail.com Fixes: d24a10b9f8ed ("Ocfs2: Add a new code 'OCFS2_INFO_FREEFRAG' for o2info ioctl.") Signed-off-by: ZhengYuan Huang Reviewed-by: Heming Zhao Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 50033ec1350fe68abdc63b950ced7ae57364b77a Author: ZhengYuan Huang Date: Fri Apr 10 12:03:39 2026 +0800 ocfs2: fix listxattr handling when the buffer is full [ Upstream commit d12f558e6200b3f47dbef9331ed6d115d2410e59 ] [BUG] If an OCFS2 inode has both inline and block-based xattrs, listxattr() can return a size larger than the caller's buffer when the inline names consume that buffer exactly. kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102 Call Trace: __check_heap_object+0xe3/0x120 mm/slub.c:8243 check_heap_object mm/usercopy.c:196 [inline] __check_object_size mm/usercopy.c:250 [inline] __check_object_size+0x5c5/0x780 mm/usercopy.c:215 check_object_size include/linux/ucopysize.h:22 [inline] check_copy_size include/linux/ucopysize.h:59 [inline] copy_to_user include/linux/uaccess.h:219 [inline] listxattr+0xb0/0x170 fs/xattr.c:926 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x137/0x320 fs/xattr.c:988 __do_sys_listxattr fs/xattr.c:1001 [inline] __se_sys_listxattr fs/xattr.c:998 [inline] __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998 ... [CAUSE] Commit 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") replaced the old per-handler list accounting with ocfs2_xattr_list_entry(), but it kept using size == 0 to detect probe mode. That assumption stops being true once ocfs2_listxattr() finishes the inline-xattr pass. If the inline names fill the caller buffer exactly, the block-xattr pass runs with a non-NULL buffer and a remaining size of zero. ocfs2_xattr_list_entry() then skips the bounds check, keeps counting block names, and returns a positive size larger than the supplied buffer. [FIX] Detect probe mode by testing whether the destination buffer pointer is NULL instead of whether the remaining size is zero. That restores the pre-refactor behavior and matches the OCFS2 getxattr helpers. Once the remaining buffer reaches zero while more names are left, the block-xattr pass now returns -ERANGE instead of reporting a size larger than the allocated list buffer. Link: https://lkml.kernel.org/r/20260410040339.3837162-1-gality369@gmail.com Fixes: 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") Signed-off-by: ZhengYuan Huang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 1075f2f590fdac147f8b8010c35b606564b5c7d7 Author: Richard Cheng Date: Thu Apr 9 13:19:02 2026 +0800 fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal [ Upstream commit a55f80233f384dc89ef3425b2e1dd0e6d44bcf29 ] CXL is linked before fwctl in drivers/Makefile. Both use `module_init, so `cxl_pci_driver_init()` runs first. When `cxl_pci_probe()` calls `fwctl_register()` and then `device_add()`, fwctl_class is not yet registered because fwctl_init() hasn't run, causing `class_to_subsys()` to return NULL and skip knode_class initialization. On device removal, `class_to_subsys()` returns non-NULL, and `device_del()` calls `klist_del()` on the uninitialized knode, triggering a NULL pointer dereference. Fixes: 858ce2f56b52 ("cxl: Add FWCTL support to CXL") Link: https://patch.msgid.link/r/20260409051902.40218-1-icheng@nvidia.com Signed-off-by: Richard Cheng Reviewed-by: Kai-Heng Feng Reviewed-by: Dave Jiang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 377861552d67b8a76ec197439a58cf08986966d5 Author: Sebastian Ene Date: Thu Apr 2 11:39:39 2026 +0000 firmware: arm_ffa: Use the correct buffer size during RXTX_MAP [ Upstream commit 83210251fd70d5f96bcdc8911e15f7411a6b2463 ] Don't use the discovered buffer size from an FFA_FEATURES call directly since we can run on a system that has the PAGE_SIZE larger than the returned size which makes the alloc_pages_exact for the buffer to be rounded up. Fixes: 61824feae5c0 ("firmware: arm_ffa: Fetch the Rx/Tx buffer size using ffa_features()") Signed-off-by: Sebastian Ene Link: https://patch.msgid.link/20260402113939.930221-1-sebastianene@google.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit cd3a5e5ce42c16ff323c23f5d83a67dec4e83ac7 Author: Frank Li Date: Wed Feb 11 18:12:55 2026 -0500 ARM: dts: imx27-eukrea: replace interrupts with interrupts-extended [ Upstream commit 0477a6b31e2874e554e3bcfac9883684b8f8ca2d ] The property interrupts use default interrupt controllers. But pass down gpio as phandle. Correct it by use interrupts-extended. Fixes: d8cae888aa2bc ("ARM: dts: Add support for the cpuimx27 board from Eukrea and its baseboard") Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit a8486acfa1a54cb144f76b1e98fcef14cc3d3d87 Author: Christian A. Ehrhardt Date: Thu Mar 26 22:49:03 2026 +0100 lib: kunit_iov_iter: fix memory leaks [ Upstream commit 0b49c7d0ae697fcecd7377cb7dda220f7cd096ff ] Use vfree() instead of vunmap() to free the buffer allocated by iov_kunit_create_buffer() because vunmap() does not honour VM_MAP_PUT_PAGES. In order for this to work the page array itself must not be managed by kunit. Remove the folio_put() when destroying a folioq. This is handled by vfree(), now. Pointed out by sashiko.dev on a previous iteration of this series. Tested by running the kunit test 10000 times in a loop. Link: https://lkml.kernel.org/r/20260326214905.818170-4-lk@c--e.de Fixes: 2d71340ff1d4 ("iov_iter: Kunit tests for copying to/from an iterator") Signed-off-by: Christian A. Ehrhardt Cc: David Howells Cc: David Gow Cc: Kees Cook Cc: Petr Mladek Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 6d29b0afb681a55cfd1c81814f48a0e9251dbe7d Author: Christoph Hellwig Date: Fri Mar 27 07:16:35 2026 +0100 arm64/xor: fix conflicting attributes for xor_block_template [ Upstream commit 675a0dd596e712404557286d0a883b54ee28e4f4 ] Commit 2c54b423cf85 ("arm64/xor: use EOR3 instructions when available") changes the definition to __ro_after_init instead of const, but failed to update the external declaration in xor.h. This was not found because xor-neon.c doesn't include , and can't easily do that due to current architecture of the XOR code. Link: https://lkml.kernel.org/r/20260327061704.3707577-4-hch@lst.de Fixes: 2c54b423cf85 ("arm64/xor: use EOR3 instructions when available") Signed-off-by: Christoph Hellwig Reviewed-by: Eric Biggers Tested-by: Eric Biggers Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Andreas Larsson Cc: Anton Ivanov Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: "Borislav Petkov (AMD)" Cc: Catalin Marinas Cc: Chris Mason Cc: Christian Borntraeger Cc: Dan Williams Cc: David S. Miller Cc: David Sterba Cc: Heiko Carstens Cc: Herbert Xu Cc: "H. Peter Anvin" Cc: Huacai Chen Cc: Ingo Molnar Cc: Jason A. Donenfeld Cc: Johannes Berg Cc: Li Nan Cc: Madhavan Srinivasan Cc: Magnus Lindholm Cc: Matt Turner Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Palmer Dabbelt Cc: Richard Henderson Cc: Richard Weinberger Cc: Russell King Cc: Song Liu Cc: Sven Schnelle Cc: Ted Ts'o Cc: Vasily Gorbik Cc: WANG Xuerui Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5925fb3dd6cdf33502c2158c5c2b2fe84e99ab78 Author: Aaro Koskinen Date: Fri Mar 27 19:15:10 2026 +0200 ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX [ Upstream commit 7e74b606dd39c46d4378d6f6563f560a00ab8694 ] On OMAP16XX, the UART enable bit shifts are written instead of the actual bits. This breaks the boot when DEBUG_LL and earlyprintk is enabled; the UART gets disabled and some random bits get enabled. Fix that. Fixes: 34c86239b184 ("ARM: OMAP1: clock: Fix early UART rate issues") Signed-off-by: Aaro Koskinen Link: https://patch.msgid.link/aca7HnXZ-aCSJPW7@darkstar.musicnaut.iki.fi Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit a62bf383ed4adc981963188b2868b4eaed2e9601 Author: Alexander Koskovich Date: Sun Mar 8 04:26:37 2026 +0000 arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP [ Upstream commit b683730e27ba4f91986c4c92f5cb7297f1e01a6d ] This resolves the following error seen on the ASUS ROG Phone 3: cpu cpu7: Voltage update failed freq=3091200 cpu cpu7: failed to update OPP for freq=3091200 Fixes: 8e0e8016cb79 ("arm64: dts: qcom: sm8250: Add CPU opp tables") Signed-off-by: Alexander Koskovich Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260307-sm8250-cpu7-opp-v1-1-435f5f6628a1@pm.me Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 38db1ce9519749fe0e50d5b7d2a373172cf743a7 Author: Abel Vesa Date: Fri Mar 27 14:13:41 2026 +0200 arm64: dts: qcom: milos: Add missing CX power domain to GCC [ Upstream commit e46b48b853122626806d989d5db4ce97eaaac2ca ] Unless CX is declared as the power-domain of GCC, votes (power and performance) on the GDSCs it provides will not propagate to the CX, which might result in under-voltage conditions. Add the missing power-domains property to associate GCC with RPMHPD_CX. Fixes: d9d59d105f98 ("arm64: dts: qcom: Add initial Milos dtsi") Signed-off-by: Abel Vesa Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260327-dt-fix-milos-eliza-gcc-power-domains-v1-2-f14a22c73fe9@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e523eba2643c8ec807a8222508105867ebfa0f1b Author: Alok Tiwari Date: Sun Mar 29 12:53:23 2026 -0700 soc: qcom: aoss: compare against normalized cooling state [ Upstream commit cd3c4670db3ffe997be9548c7a9db3952563cf14 ] qmp_cdev_set_cur_state() normalizes the requested state to a boolean (cdev_state = !!state). The existing early-return check compares qmp_cdev->state == state, which can be wrong if state is non-boolean (any non-zero value). Compare qmp_cdev->state against cdev_state instead, so the check matches the effective state and avoids redundant updates. Signed-off-by: Alok Tiwari Fixes: 05589b30b21a ("soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.") Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260329195333.1478090-1-alok.a.tiwari@oracle.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 591e7009f5c6c99ac5265abbaa4a13bcfdc07a01 Author: Alok Tiwari Date: Mon Mar 30 02:51:11 2026 -0700 soc: qcom: llcc: fix v1 SB syndrome register offset [ Upstream commit 24e7625df5ce065393249b78930781be593bc381 ] The llcc_v1_edac_reg_offset table uses 0x2304c for trp_ecc_sb_err_syn0, which is inconsistent with the surrounding TRP ECC registers (0x2034x) and with llcc_v2_1_edac_reg_offset, where trp_ecc_sb_err_syn0 is 0x2034c adjacent to trp_ecc_error_status0/1 at 0x20344/0x20348. Use 0x2034c for llcc v1 so the SB syndrome register follows the expected +0x4 progression from trp_ecc_error_status1. This fixes EDAC reading the wrong register for SB syndrome reporting. Fixes: c13d7d261e36 ("soc: qcom: llcc: Pass LLCC version based register offsets to EDAC driver") Signed-off-by: Alok Tiwari Reviewed-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260330095118.2657362-1-alok.a.tiwari@oracle.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 426cd8eedac89b86148d4478990eeef16e8a2520 Author: Junrui Luo Date: Sat Mar 7 15:21:09 2026 +0800 ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison [ Upstream commit 01b61e8dda9b0fdb0d4cda43de25f4e390554d7b ] The local-vs-remote region comparison loop uses '<=' instead of '<', causing it to read one entry past the valid range of qr_regions. The other loops in the same function correctly use '<'. Fix the loop condition to use '<' for consistency and correctness. Link: https://lkml.kernel.org/r/SYBPR01MB78813DA26B50EC5E01F00566AF7BA@SYBPR01MB7881.ausprd01.prod.outlook.com Fixes: ea2034416b54 ("ocfs2/dlm: Add message DLM_QUERY_REGION") Signed-off-by: Junrui Luo Reported-by: Yuhao Jiang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 3c2d0de23ae4be22b6c18e8f0915be74d3b5fb21 Author: Junrui Luo Date: Sat Mar 7 15:21:08 2026 +0800 ocfs2/dlm: validate qr_numregions in dlm_match_regions() [ Upstream commit 7ab3fbb01bc6d79091bc375e5235d360cd9b78be ] Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()". In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION network message is used to drive loops over the qr_regions buffer without sufficient validation. This series fixes two issues: - Patch 1 adds a bounds check to reject messages where qr_numregions exceeds O2NM_MAX_REGIONS. The o2net layer only validates message byte length; it does not constrain field values, so a crafted message can set qr_numregions up to 255 and trigger out-of-bounds reads past the 1024-byte qr_regions buffer. - Patch 2 fixes an off-by-one in the local-vs-remote comparison loop, which uses '<=' instead of '<', reading one entry past the valid range even when qr_numregions is within bounds. This patch (of 2): The qr_numregions field from a DLM_QUERY_REGION network message is used directly as loop bounds in dlm_match_regions() without checking against O2NM_MAX_REGIONS. Since qr_regions is sized for at most O2NM_MAX_REGIONS (32) entries, a crafted message with qr_numregions > 32 causes out-of-bounds reads past the qr_regions buffer. Add a bounds check for qr_numregions before entering the loops. Link: https://lkml.kernel.org/r/SYBPR01MB7881A334D02ACEE5E0645801AF7BA@SYBPR01MB7881.ausprd01.prod.outlook.com Link: https://lkml.kernel.org/r/SYBPR01MB788166F524AD04E262E174BEAF7BA@SYBPR01MB7881.ausprd01.prod.outlook.com Fixes: ea2034416b54 ("ocfs2/dlm: Add message DLM_QUERY_REGION") Signed-off-by: Junrui Luo Reported-by: Yuhao Jiang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 665dc1ed16357988d439fc5bbc860ee36f540d81 Author: Michal Grzedzicki Date: Fri Feb 13 11:39:59 2026 -0800 unshare: fix nsproxy leak in ksys_unshare() on set_cred_ucounts() failure [ Upstream commit a98621a0f187a934c115dcfe79a49520ae892111 ] When set_cred_ucounts() fails in ksys_unshare() new_nsproxy is leaked. Let's call put_nsproxy() if that happens. Link: https://lkml.kernel.org/r/20260213193959.2556730-1-mge@meta.com Fixes: 905ae01c4ae2 ("Add a reference to ucounts for each cred") Signed-off-by: Michal Grzedzicki Reviewed-by: Andrew Morton Cc: Alexey Gladkov (Intel) Cc: Ben Segall Cc: David Hildenbrand Cc: Dietmar Eggemann Cc: Ingo Molnar Cc: Juri Lelli Cc: Kees Cook Cc: "Liam R. Howlett" Cc: Lorenzo Stoakes (Oracle) Cc: Mel Gorman Cc: Michal Hocko Cc: Mike Rapoport Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Valentin Schneider Cc: Vincent Guittot Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit bba68ec0f1808042d8024342ce4184d077f7b15d Author: Jon Hunter Date: Wed Mar 25 19:25:53 2026 +0000 soc/tegra: pmc: Add kerneldoc for wake-up variables [ Upstream commit e6ad1988e56834d641ba4aa0d58970723c1c9c9b ] Commit e6d96073af68 ("soc/tegra: pmc: Fix unsafe generic_handle_irq() call") added the variables 'wake_work' and 'wake_status' to the 'tegra_pmc' structure but did not add the associated kerneldoc for these new variables. Add the kerneldoc for these variables. Fixes: e6d96073af68 ("soc/tegra: pmc: Fix unsafe generic_handle_irq() call") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit a838e347a2902c49abc4ba541193e4eb645f48d1 Author: Jon Hunter Date: Wed Mar 25 19:25:52 2026 +0000 soc/tegra: pmc: Correct function names in kerneldoc [ Upstream commit ec0e4da5d679f9da1cc198927951f70fdf28f001 ] Commit 70f752ebb08c ("soc/tegra: pmc: Add PMC contextual functions") added the functions devm_tegra_pmc_get() and tegra_pmc_io_pad_power_enable(), but the names of the functions in the associated kerneldoc is incorrect. Update the kerneldoc for these functions to correct their names. Fixes: 70f752ebb08c ("soc/tegra: pmc: Add PMC contextual functions") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 6ef6ae007e8bdc4ad571bf236a720035fc241d0a Author: Jon Hunter Date: Wed Mar 25 19:25:51 2026 +0000 soc/tegra: pmc: Add kerneldoc for reboot notifier [ Upstream commit 21669619e4c17a5f097e0415bc64b1d400c54fcb ] Commit 48b7f802fb78 ("soc/tegra: pmc: Embed reboot notifier in PMC context") added the reboot_notifier structure to the PMC SoC structure but did not update the kerneldoc accordingly. Add this missing kerneldoc description to fix this. Fixes: 48b7f802fb78 ("soc/tegra: pmc: Embed reboot notifier in PMC context") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 8f267071017bd30c61263cc4cb298f1d179e7d97 Author: Jon Hunter Date: Thu Mar 5 15:16:59 2026 +0000 arm64: tegra: Fix RTC aliases [ Upstream commit 69ec77b3f1074f3000d28f67f7629303e7999b84 ] The following warning is observed on the Tegra234 Jetson platforms ... rtc-nvidia-vrs10 4-003c: /aliases ID 0 not available This happens because the 'rtc@c2a0000' device is registered before the vrs10 RTC and so is assigned the 'rtc0' alias. We want the vrs10 RTC to be the default RTC because this RTC maintains time across power cycles. Fix this by adding a 'rtc1' alias for the 'rtc@c2a0000' device. Fixes: b1806f2b4e78 ("arm64: tegra: Add device-tree node for NVVRS RTC") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 8445d69a5cabd8d6cb2bf0f8b798be205f53afa2 Author: Sumit Gupta Date: Wed Jan 21 15:42:05 2026 +0530 soc/tegra: cbb: Fix cross-fabric target timeout lookup [ Upstream commit a5f51b04cbb3ae0f9cb2c4488952b775ebb0ccbf ] When a fabric receives an error interrupt, the error may have occurred on a different fabric. The target timeout lookup was using the wrong base address (cbb->regs) with offsets from a different fabric's target map, causing a kernel page fault. Unable to handle kernel paging request at virtual address ffff80000954cc00 pc : tegra234_cbb_get_tmo_slv+0xc/0x28 Call trace: tegra234_cbb_get_tmo_slv+0xc/0x28 print_err_notifier+0x6c0/0x7d0 tegra234_cbb_isr+0xe4/0x1b4 Add tegra234_cbb_get_fabric() to look up the correct fabric device using fab_id, and use its base address for accessing target timeout registers. Fixes: 25de5c8fe0801 ("soc/tegra: cbb: Improve handling for per SoC fabric data") Signed-off-by: Sumit Gupta Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 5c009a5f8bb3c81f2cfb511701ce571e3c8733cd Author: Sumit Gupta Date: Wed Jan 21 15:42:04 2026 +0530 soc/tegra: cbb: Fix incorrect ARRAY_SIZE in fabric lookup tables [ Upstream commit 499f7e5ebbdd9ff0c4d532b1c432f8a61ff585b3 ] Fix incorrect ARRAY_SIZE usage in fabric lookup tables which could cause out-of-bounds access during target timeout lookup. Fixes: 25de5c8fe0801 ("soc/tegra: cbb: Improve handling for per SoC fabric data") Signed-off-by: Sumit Gupta Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 71df3d5bf2d1d70332ab6b114de1dbd1a8971cb1 Author: Sumit Gupta Date: Wed Jan 21 15:42:03 2026 +0530 soc/tegra: cbb: Set ERD on resume for err interrupt [ Upstream commit b6ff71c5d1d4ad858ddf6f39394d169c96689596 ] Set the Error Response Disable (ERD) bit to mask SError responses and use interrupt-based error reporting. When the ERD bit is set, inband error responses to the initiator via SError are suppressed, and fabric errors are reported via an interrupt instead. The register is set during boot but the info is lost during system suspend and needs to be set again on resume. Fixes: fc2f151d2314 ("soc/tegra: cbb: Add driver for Tegra234 CBB 2.0") Signed-off-by: Sumit Gupta Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 30e20fb9c7105ce7f4968b7a51942d6b9ba7fc47 Author: Xu Yang Date: Tue Mar 24 19:04:59 2026 +0800 arm64: dts: imx8qxp-mek: switch Type-C connector power-role to dual [ Upstream commit 825b8c7e1d2918d89eb378b761530d1e51dba82e ] When attach to PC Type-A port, the USB device controller does not function at all. Because it is configured as source-only and a Type-A port doesn't support PD capability, a data role swap is impossible. Actually, PTN5110THQ is configured for Source role only at POR, but after POR it can operate as a DRP (Dual-Role Power). By switching the power-role to dual, the port can operate as a sink and enter device mode when attach to Type-A port. Since the board design uses EN_SRC to control the 5V VBUS path and EN_SNK to control the 12V VBUS output, to avoid outputting a higher VBUS when in sink role, we set the operation current limit to 0mA so that SW will not control EN_SNK at all. Fixes: 2faf4ebcee2e5 ("arm64: dts: freescale: imx8qxp-mek: enable cadence usb3") Signed-off-by: Xu Yang Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit aa05797fc9238dfc900ddc627268c950b4c85130 Author: Xu Yang Date: Tue Mar 24 19:04:58 2026 +0800 arm64: dts: imx8qm-mek: switch Type-C connector power-role to dual [ Upstream commit e3d3d19d1c0050789a4813ce836a641a3387d916 ] When attach to PC Type-A port, the USB device controller does not function at all. Because it is configured as source-only and a Type-A port doesn't support PD capability, a data role swap is impossible. Actually, PTN5110THQ is configured for Source role only at POR, but after POR it can operate as a DRP (Dual-Role Power). By switching the power-role to dual, the port can operate as a sink and enter device mode when attach to Type-A port. Since the board design uses EN_SRC to control the 5V VBUS path and EN_SNK to control the 12V VBUS output, to avoid outputting a higher VBUS when in sink role, we set the operation current limit to 0mA so that SW will not control EN_SNK at all. Fixes: b237975b2cd58 ("arm64: dts: imx8qm-mek: add usb 3.0 and related type C nodes") Signed-off-by: Xu Yang Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit ebdddfb60d167453393e908c01aa6d16c289997e Author: Josua Mayer Date: Tue Mar 24 13:41:01 2026 +0100 arm64: dts: lx2160a: complete pinmux for rcwsr12 configuration word [ Upstream commit 284ad7064aaa1badde022785cd925af29c696b21 ] Commit 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") introduced pinmux nodes for lx2160 i2c interfaces, allowing runtime change between i2c and gpio functions implementing bus recovery. However, the dynamic configuration area (overwrite MUX) used by the pinctrl-single driver initially reads as zero and does not reflect the actual hardware state set by the Reset Configuration Word (RCW) at power-on. Because multiple groups of pins are configured from a single 32-bit register, the first write from the pinctrl driver unintentionally clears all other bits to zero. Add description for all bits of RCWSR12 register, allowing boards to explicitly define and restore their intended hardware state. This includes i2c, gpio, flextimer, spi, can and sdhc functions. Other configuration words, i.e. RCWSR13 & RCWSR14 may be added in the future for boards setting non-zero values there. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 6186ba38dff858a1c362d0744a39d1355c116d00 Author: Josua Mayer Date: Tue Mar 24 13:41:00 2026 +0100 arm64: dts: lx2160a: change zeros to hexadecimal in pinmux nodes [ Upstream commit 03241620d2b9915c9e3463dbc56e9eb95ad43c08 ] Replace some stray zeros from decimal to hexadecimal format within pinmux nodes. No functional change intended. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 17eed9edb8042d92d2062d4e2338016cdecea58b Author: Josua Mayer Date: Tue Mar 24 13:40:59 2026 +0100 arm64: dts: lx2160a: add sda gpio references for i2c bus recovery [ Upstream commit 89ea0dbd701f89805499d26bd90657468c789545 ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. In particular i2c sda/scl pins are always configured together. Therefore bus recovery may control both sda and scl. When pinmux nodes and bus recovery was enabled originally for LX2160, only the scl-gpios were added to the i2c controller nodes. Add references to sda-gpios for each i2c controller. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 5780bd32087b752c72973a41a5789487acac15ee Author: Josua Mayer Date: Tue Mar 24 13:40:58 2026 +0100 arm64: dts: lx2160a: rename pinmux nodes for readability [ Upstream commit 456eb494746afd56d3a9dc30271300136e55b96e ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. Each group of pins is named in the reference manual after a primary function using soc-specific naming, e.g. IIC1 (for i2c0). Hardware block numbering starts from zero in device-tree but one in the reference manual. Rename the already defined pinmux nodes originally added for changing i2c pins between i2c and gpio functions reflecting the reference manual name (IIC) in the node name, and the device-tree name (i2c, gpio) in the label. Specifically, drop the "_scl" suffix from the I2C labels because the nodes actually configure both SDA and SCL pins together. Instead add "_pins" suffix to avoid conflicts with I2C controller labels. For GPIO functions, include the specific controller and pin numbers in the label to clarify they are generic GPIOs and help spot mistakes. No functional change intended. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit eee296cf42379e38fa04edfaa4b554deaa6b20df Author: Josua Mayer Date: Tue Mar 24 13:40:57 2026 +0100 arm64: dts: lx2160a: remove duplicate pinmux nodes [ Upstream commit 325ca511ca3dda936207ce737e0afe837d45a674 ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. The pinmux nodes i2c7-scl-pins and i2c7-scl-gpio-pins are duplicates of i2c6-scl-gpio and i2c6-scl-gpio-pins, writing to the same register and bits. These two i2c buses i2c6/i2c7 (IIC7/IIC8) are configured together in register RCWSR13 bits 3-0. Drop the duplicate node name and change references to the i2c6 node. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit ad3b11fd13814053b18588903ef132c2a08b06b7 Author: Josua Mayer Date: Tue Mar 24 13:40:56 2026 +0100 arm64: dts: lx2160a: change i2c0 (iic1) pinmux mask to one bit [ Upstream commit 7a3cc49ad1fc8d063abb7f5de8f1b981b99d2978 ] LX2160A pinmux is done in groups by various length bitfields within configuration registers. The first i2c bus (called IIC1 in reference manual) is configured through field IIC1_PMUX in register RCWSR14 bit 10 which is described in the reference manual as a single bit, unlike the other i2c buses. Change the bitmask for the pinmux nodes from 0x7 to 0x1 to ensure only single bit is modified. Further change the zero in the same line to hexadecimal format for consistency. Align with documentation by avoiding writes to reserved bits. No functional change, as writing the extra two reserved bits is not known to cause issues. Fixes: 8a1365c7bbc1 ("arm64: dts: lx2160a: add pinmux and i2c gpio to support bus recovery") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 33c0fee2558a176cf6c75e44c500f241ce1ff0b9 Author: Liu Ying Date: Tue Mar 24 13:52:03 2026 +0800 arm64: dts: imx8mp-evk: Specify ADV7535 register addresses [ Upstream commit bfb91be0eba426913f2950ed8b3d963f0de53fcc ] MIPI DSI to HDMI bridge ADV7535 CEC default register address is 0x3c on an I2C bus. And, OV5640 camera uses the same address on the same I2C bus. To resolve this conflict, use 0x3b as ADV7535 CEC register address by specifying all ADV7535 register addresses. Fixes: 6f6c18cba16f ("arm64: dts: imx8mp-evk: add camera ov5640 and related nodes") Signed-off-by: Liu Ying Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit ceb3d4f5cea45f6db52dcefa9a6c916e25ab69e8 Author: Shengjiu Wang Date: Tue Mar 17 13:37:38 2026 +0800 arm64: dts: imx8dxl-evk: Use audio-graph-card2 for wm8960-2 and wm8960-3 [ Upstream commit e8341b0245736619f8d6a2cc311c9e8ad8e82390 ] The sound card wm8960-2 and wm8960-3 only support capture mode for the reason of connection on the EVK board. But fsl-asoc-card don't support capture_only setting, the sound card creation will fail. fsl-sai 59060000.sai: Missing dma channel for stream: 0 fsl-sai 59060000.sai: ASoC error (-22): at snd_soc_pcm_component_new() on 59060000.sai fsl-sai 59070000.sai: Missing dma channel for stream: 0 fsl-sai 59070000.sai: ASoC error (-22): at snd_soc_pcm_component_new() on 59070000.sai so switch to use audio-graph-card2 which supports 'capture_only' property for wm8960-2 and wm8960-3 cards. Fixes: b41c45eb990a ("arm64: dts: imx8dxl-evk: add audio nodes") Signed-off-by: Shengjiu Wang Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit aafb0e6c41d1ba3074bfe65f14deb47c7726b8c9 Author: Annette Kobou Date: Mon Mar 9 09:57:43 2026 +0100 arm64: dts: imx8mp-kontron: Fix boot order for PMIC and RTC [ Upstream commit 130d90114c5255a7a729158da8fd8298a02017f1 ] The PMIC provides a level-shifter for the I2C lines to the RTC. As the level shifter needs to be enabled before the RTC can be accessed, make sure that the PMIC driver is probed first. As the PMIC also provides the supply voltage for the RTC through the 3.3V regulator, simply express this in the DT to create the required dependency. Avoid sporadic boot hangs that occurred when the RTC was accessed before the level-shifter was enabled. Fixes: 946ab10e3f40f ("arm64: dts: Add support for Kontron OSM-S i.MX8MP SoM and BL carrier board") Signed-off-by: Annette Kobou Signed-off-by: Frieder Schrempf Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 5b064a041e0d74029d31b41bab5137d79982241c Author: Alexander Stein Date: Thu Mar 5 17:42:22 2026 +0100 arm64: dts: imx91: Remove TMU's superfluous sensor ID [ Upstream commit 53a0485304f11f5371fddf9fb06b95268154bf82 ] Currently a sensor ID is added to the reference, but thermal-sensor@44482000 has #thermal-sensor-cells = <0>, so parsing fails. This also has the effect that other hwmon sensors (jc42) fail to probe. Fix this by removing the superfluous sensor ID. Fixes: f0ed0e844452 ("arm64: dts: imx91: Add thermal-sensor and thermal-zone support") Signed-off-by: Alexander Stein Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit d19d9dbbb04aa926559425f8763a599236d4ee82 Author: Nora Schiffer Date: Mon Mar 2 09:45:48 2026 +0100 arm64: dts: freescale: imx8mp-tqma8mpql-mba8mp-ras314: fix UART1 RTS/CTS muxing [ Upstream commit b8d785a9f360abcd6a6f8f10a2adf222f8494d66 ] UART1 operates in DCE mode, but the RTS/CTS pins were incorrectly configured using the DTE pinmux setting. Correct the pinmux to match DCE mode. Switching the RTS and CTS signals is fine for this board, as UART1 is routed to a pin header. Existing functionality is unaffected, as RTS/CTS could never have worked with the incorrect pinmux. Fixes: ddabb3ce3f90 ("arm64: dts: freescale: add TQMa8MPQL on MBa8MP-RAS314") Signed-off-by: Nora Schiffer Reviewed-by: Alexander Stein Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 8bcc7b6839e6f17103f2b24aa1b3889373204b21 Author: Francesco Dolcini Date: Tue Mar 24 10:36:57 2026 +0100 arm64: dts: ti: k3-am62-verdin: Fix SPI_1 GPIO CS pinctrl label [ Upstream commit 944dffaec1ef0f21c203728de77b5618ed70df6e ] Fix SPI_1_CS GPIO pinmux label, this is spi1_cs, not qspi1_io4. There are no user of this label yet, therefore this change does not create any compatibility issue. Fixes: fcb335934c51 ("arm64: dts: ti: verdin-am62: Improve spi1 chip-select pinctrl") Signed-off-by: Francesco Dolcini Link: https://patch.msgid.link/20260324093705.26730-3-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 6eaac807fe37a6cc8bfcf705eadef1d1f4a84b47 Author: Judith Mendez Date: Mon Feb 23 17:37:31 2026 -0600 arm64: dts: ti: k3-am62-lp-sk: Enable internal pulls for MMC0 data pins [ Upstream commit ee2a9d9c9e6c9643fb7e45febcaedfbc038e483a ] AM62 LP SK board does not have external pullups on MMC0 DAT1-DAT7 pins [0]. Enable internal pullups on DAT1-DAT7 considering: - without a host-side pullup, these lines rely solely on the eMMC device's internal pullup (R_int, 10-150K per JEDEC), which may exceed the recommended 50K max for 1.8V VCCQ - JEDEC JESD84-B51 Table 200 requires host-side pullups (R_DAT, 10K-100K) on all data lines to prevent bus floating [0] https://www.ti.com/lit/zip/SPRR471 Fixes: a0b8da04153e ("arm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board file") Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260223233731.2690472-4-jm@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit bc898ebd895f0aeb70dbbbf029a280fae8051ea5 Author: Judith Mendez Date: Mon Feb 23 17:37:30 2026 -0600 arm64: dts: ti: k3-am62l3-evm: Disable MMC1 internal pulls on data pins [ Upstream commit 02532ba56362907b6aca3e8289c4a9247ef83325 ] AM62L EVM has external 47K pullups on MMC1 DAT1-DAT3 pins [0]. Disable internal pullups on DAT1-DAT3 so that each line has a single pullup source: - with both pullups enabled, the effective parallel resistance on DAT1-3 (~24.2K) creates a ~2x mismatch vs DAT0 (47K external only). Removing internal pullups results in DAT1-3 matching DAT0 at 47K - 47K external alone is within the recommended range for 1.8V signaling (10K min, 50K recommended max) - both internal and external pullups enabled equals unnecessary power consumption [0] https://www.ti.com/lit/zip/SPRCAL6 Fixes: 00fb4c73b67d ("arm64: dts: ti: k3-am62l: add initial reference board file") Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260223233731.2690472-3-jm@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit cc0699e9063a97ef42c069268a4dc269dd81e136 Author: Judith Mendez Date: Mon Feb 23 17:37:29 2026 -0600 arm64: dts: ti: k3-am62p5-sk: Disable MMC1 internal pulls on data pins [ Upstream commit 6d4441be969bea89bb9702781f5dfb3a8f2a02a4 ] AM62P SK has external 10K pullups on MMC1 DAT1-DAT3 pins [0]. Disable internal pullups on DAT1-DAT3 so that each line has a single pullup source: - with both pullups enabled, the effective parallel resistance on DAT1-3 (~8.33K) drops below the 10K minimum pullup requirement for data lines (per SD Physical Layer Specification) - removing internal pullups makes DAT1-3 match DAT0 10K external pullup so its consistent and within spec - both internal and external pullups enabled equals unnecessary power consumption [0] https://www.ti.com/lit/zip/SPRR487 Fixes: c00504ea42c0 ("arm64: dts: ti: k3-am62p5-sk: Updates for SK EVM") Signed-off-by: Judith Mendez Reviewed-by: Moteen Shah Link: https://patch.msgid.link/20260223233731.2690472-2-jm@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 5820e6a0ed68a64ae0427804de0684ad1793b5f4 Author: Barnabás Czémán Date: Sun Mar 15 17:26:19 2026 +0100 arm64: dts: qcom: msm8917-xiaomi-riva: Fix board-id for all bootloader [ Upstream commit a49cd243503c528ea99e31a7853cf438ccc9032d ] Redmi 5A comes with multiple bootloader versions where the expected board-id is different. Change the board-id to unified form what works on both bootloader version. Fixes: 26633b582056 ("arm64: dts: qcom: Add Xiaomi Redmi 5A") Reviewed-by: Konrad Dybcio Signed-off-by: Barnabás Czémán Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260315-riva-common-v3-1-897f130786ed@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 98386b37466295ad3aeb519710592cc3929c8213 Author: David Heidelberg Date: Fri Mar 20 18:33:11 2026 +0100 arm64: dts: qcom: sdm845-xiaomi-beryllium: Mark l1a regulator as powered during boot [ Upstream commit 3b0dd81eea6b7a239fce456ce4545af76f1a9715 ] The regulator must be on, since it provides the display subsystem and therefore the bootloader had turned it on before Linux booted. Fixes: 77809cf74a8c ("arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)") Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260320-beryllium-booton-v2-1-931d1be21eae@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8b51c913589ac1d619c41e89bf6bc384f63d5d23 Author: Luca Weiss Date: Thu Mar 19 09:55:00 2026 +0100 arm64: dts: qcom: sm7225-fairphone-fp4: Fix conflicting bias pinctrl [ Upstream commit be7c1badb0b934cfe88427b1d4ec3eb9f52ba587 ] The pinctrl nodes from sm6350.dtsi already contain a bias-* property, so that needs to be deleted, otherwise the dtb will contain two conflicting bias-* properties. Reported-by: Conor Dooley Closes: https://lore.kernel.org/r/20260310-maritime-silly-05e7b7e03aa6@spud/ Fixes: c4ef464b24c5 ("arm64: dts: qcom: sm7225-fairphone-fp4: Add Bluetooth") Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20260319-fp4-uart1-fix-v1-1-f6b3fedef583@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 72020d303cf144429e345359e9af3564108bf6fb Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:15 2026 +0200 arm64: dts: qcom: sm8650: Enable UHS-I SDR50 and SDR104 SD card modes [ Upstream commit 93f823e7d48232e62fb8fb74481696609c90244a ] The restriction on UHS-I speed modes was added to all SM8650 platforms by copying it from SM8450 and SM8550 dtsi files, and it was an actually reproducible problem due to the overclocking of SD cards. Since the latter issue has been fixed in the SM8650 GCC driver, UHS-I speed modes are working fine on SM8650 boards, below is the test performed on SM8650-HDK: SDR50 speed mode: mmc0: new UHS-I speed SDR50 SDHC card at address 0001 mmcblk0: mmc0:0001 00000 14.6 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.8086 s, 43.3 MB/s SDR104 speed mode: mmc0: new UHS-I speed SDR104 SDHC card at address 59b4 mmcblk0: mmc0:59b4 USDU1 28.3 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9448 s, 82.9 MB/s Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi file, there is no indication that the SDHC controller is broken. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Signed-off-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20260314023715.357512-7-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6a95653434cac889db90255f2a196baf16f364a0 Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:14 2026 +0200 arm64: dts: qcom: sm8550: Enable UHS-I SDR50 and SDR104 SD card modes [ Upstream commit 66b0f024fba0728ddce6916dce173bb1bdd4eab0 ] The restriction on UHS-I speed modes was added to all SM8550 platforms by copying it from SM8450 dtsi file, and due to the overclocking of SD cards it was an actually reproducible problem. Since the latter issue has been fixed, UHS-I speed modes are working fine on SM8550 boards, below is the test performed on SM8550-HDK: SDR50 speed mode: mmc0: new UHS-I speed SDR50 SDHC card at address 0001 mmcblk0: mmc0:0001 00000 14.6 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5468 s, 45.6 MB/s SDR104 speed mode: mmc0: new UHS-I speed SDR104 SDHC card at address 59b4 mmcblk0: mmc0:59b4 USDU1 28.3 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.9819 s, 89.6 MB/s Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi file, there is no indication that the SDHC controller is broken. Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Reviewed-by: Neil Armstrong Signed-off-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20260314023715.357512-6-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 582b57fd8ddb6305ab077a36df2603a613bb9e64 Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:13 2026 +0200 arm64: dts: qcom: sm8450: Enable UHS-I SDR50 and SDR104 SD card modes [ Upstream commit db0c5ef1abda6effdc5c85d6688fb6af2b351ae5 ] The reported problem of some non-working UHS-I speed modes on SM8450 originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards"). The tests show that the rootcause of the problem was related to an overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs"). Since then both SDR50 and SDR104 speed modes are working fine on SM8450, tested on SM8450-HDK: SDR50 speed mode: mmc0: new UHS-I speed SDR50 SDHC card at address 0001 mmcblk0: mmc0:0001 00000 14.6 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6254 s, 43.6 MB/s SDR104 speed mode: mmc0: new UHS-I speed SDR104 SDHC card at address 59b4 mmcblk0: mmc0:59b4 USDU1 28.3 GiB mmcblk0: p1 % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.3266 s, 87.1 MB/s Remove the restrictions on SD card speed modes from the SM8450 platform dtsi file and enable UHS-I speed modes. Fixes: 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards") Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Signed-off-by: Vladimir Zapolskiy Link: https://lore.kernel.org/r/20260314023715.357512-5-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 12d5a15789b66ba9e40e1f87993beefa2147dfdf Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:12 2026 +0200 arm64: dts: qcom: hamoa: Fix xo clock supply of platform SD host controller [ Upstream commit d094f79960e1da20c1380083c95945371baa3668 ] The expected frequency of SD host controller core supply clock is 19.2MHz, while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz. Apparently the overclocked supply clock could be good enough on some boards and even with the most of SD cards, however some low-end UHS-I SD cards in SDR104 mode of the host controller produce I/O errors in runtime, fortunately this problem is gone, if the "xo" clock frequency matches the expected 19.2MHz clock rate. Fixes: ffb21c1e19b1 ("arm64: dts: qcom: x1e80100: Describe the SDHC controllers") Reported-by: Neil Armstrong Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20260314023715.357512-4-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 34c0b2cc07e2697a4076b393f2ce854a1c8cc6f8 Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:11 2026 +0200 arm64: dts: qcom: sm8650: Fix xo clock supply of SD host controller [ Upstream commit 390903efaa057c44fd80e7d9839419c50092018e ] The expected frequency of SD host controller core supply clock is 19.2MHz, while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz. Apparently the overclocked supply clock could be good enough on some boards and even with the most of SD cards, however some low-end UHS-I SD cards in SDR104 mode of the host controller produce I/O errors in runtime, fortunately this problem is gone, if the "xo" clock frequency matches the expected 19.2MHz clock rate. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20260314023715.357512-3-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7f6cb15b8d7e8a7c946b75c88fa60b474565c745 Author: Vladimir Zapolskiy Date: Sat Mar 14 04:37:10 2026 +0200 arm64: dts: qcom: sm8550: Fix xo clock supply of platform SD host controller [ Upstream commit 30ac651c69bddbc83cab6d52fc5d2e03bed83282 ] The expected frequency of SD host controller core supply clock is 19.2MHz, while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz. Apparently the overclocked supply clock could be good enough on some boards and even with the most of SD cards, however some low-end UHS-I SD cards in SDR104 mode of the host controller produce I/O errors in runtime, fortunately this problem is gone, if the "xo" clock frequency matches the expected 19.2MHz clock rate. Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20260314023715.357512-2-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9bffd040bbaa5fb8819b050ac5928687951a05c9 Author: Konrad Dybcio Date: Tue Mar 17 15:41:19 2026 +0100 arm64: dts: qcom: sm8750: Fix GIC_ITS range length [ Upstream commit c2f1f8874fda674af1efaa9a90efbdea8b6834ff ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: 068c3d3c83be ("arm64: dts: qcom: Add base SM8750 dtsi") Signed-off-by: Konrad Dybcio Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-6-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ea75eeb2977f9607532c128c9bb44eeb86c94600 Author: Konrad Dybcio Date: Tue Mar 17 15:41:18 2026 +0100 arm64: dts: qcom: sm8650: Fix GIC_ITS range length [ Upstream commit 6c8e2ca1263d0da5976418ed285eaec430e8d87f ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: d2350377997f ("arm64: dts: qcom: add initial SM8650 dtsi") Signed-off-by: Konrad Dybcio Reviewed-by: Neil Armstrong Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-5-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ae3529dcf7778162531d637ec2c5b5d15d754882 Author: Konrad Dybcio Date: Tue Mar 17 15:41:17 2026 +0100 arm64: dts: qcom: sm8550: Fix GIC_ITS range length [ Upstream commit 357c559e386705609b6b9dc0544c420e3f91f3a0 ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Signed-off-by: Konrad Dybcio Reviewed-by: Neil Armstrong Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-4-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d02dcddb12f786bd1e88ec64218c9ffbd193caef Author: Konrad Dybcio Date: Tue Mar 17 15:41:16 2026 +0100 arm64: dts: qcom: sm8450: Fix GIC_ITS range length [ Upstream commit 14044fa192c50265bc1f636108371044bbdcf7b7 ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: fc8b0b9b630d ("arm64: dts: qcom: sm8450 add ITS device tree node") Signed-off-by: Konrad Dybcio Reviewed-by: Neil Armstrong Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-3-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0032020184b64fbbc0c9b6289d3287eb30ecdbe5 Author: Konrad Dybcio Date: Tue Mar 17 15:41:15 2026 +0100 arm64: dts: qcom: milos: Fix GIC_ITS range length [ Upstream commit 1831b64854bd8adfccfef4f949534f9e8163293a ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: d9d59d105f98 ("arm64: dts: qcom: Add initial Milos dtsi") Signed-off-by: Konrad Dybcio Reviewed-by: Luca Weiss Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-2-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 89bf16615e523ca721ea96427c3633c3f1e568d9 Author: Konrad Dybcio Date: Tue Mar 17 15:41:14 2026 +0100 arm64: dts: qcom: kaanapali: Fix GIC_ITS range length [ Upstream commit 51cf2818376f5ebbc5f8753d5be547b1e7206021 ] Currently, the GITS_SGIR register is cut off. Fix it up. Fixes: 2eeb5767d53f ("arm64: dts: qcom: Introduce Kaanapali SoC") Signed-off-by: Konrad Dybcio Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-1-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6e803f8ce32660cf951c6b65907ccba4f728cec5 Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:13 2026 +0200 arm64: dts: qcom: sm8750: correct Iris corners for the MXC rail [ Upstream commit 2755bdd02a43c204fb0ca02b93787a863c1cf9d2 ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: c0d11ff90475 ("arm64: dts: qcom: sm8750: Add Iris VPU v3.5") Signed-off-by: Dmitry Baryshkov Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-6-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cde6338d4ec1824262ae7a6af4e156ce3956f72a Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:12 2026 +0200 arm64: dts: qcom: sm8650: correct Iris corners for the MXC rail [ Upstream commit 7c302a2a6c1a4644e798ecfc4e72ddc4acec653f ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: 56cf5ad39a55 ("arm64: dts: qcom: sm8650: add iris DT node") Signed-off-by: Dmitry Baryshkov Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-5-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit edda5516c3d74f2c476959a35d73fc1046808481 Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:11 2026 +0200 arm64: dts: qcom: sm8550: correct Iris corners for the MXC rail [ Upstream commit ff8edb5bc8bdf8bdf4573d8dc062b09cc1e6bc76 ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: 41661853ae8e ("arm64: dts: qcom: sm8550: add iris DT node") Signed-off-by: Dmitry Baryshkov Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-4-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e03b976831bb3beefdcf0040ef2f2a84d1fa0dc7 Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:10 2026 +0200 arm64: dts: qcom: monaco: correct Iris corners for the MXC rail [ Upstream commit bba8d9ba7df8f6592552377049fc84958fd0575a ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: bf6ec39c3f36 ("arm64: dts: qcom: qcs8300: add video node") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-3-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d7b1494fa28ed5e4451cfd0b75651c5b53cf1149 Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:09 2026 +0200 arm64: dts: qcom: lemans: correct Iris corners for the MXC rail [ Upstream commit 85a6cf5ef8cf6e6de948fbba56101fa05049417f ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: 7bc95052c64f ("arm64: dts: qcom: sa8775p: add support for video node") Signed-off-by: Dmitry Baryshkov Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-2-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ea30a026ca6aa6aea3f938f557a678ad1d0fed38 Author: Dmitry Baryshkov Date: Fri Mar 13 17:27:08 2026 +0200 arm64: dts: qcom: hamoa: correct Iris corners for the MXC rail [ Upstream commit baac8b5e43f42b632b912a6a837d94fd5bca48f2 ] The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always match the PLL corners on the MXC rail. Correct the performance corners for the MXC rail following the PLL documentation. Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec") Signed-off-by: Dmitry Baryshkov Reviewed-by: Dikshita Agarwal Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-1-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 202431754c19cabcd331fc1c18d8232bcf7829ac Author: Tobias Heider Date: Thu Feb 26 15:04:30 2026 +0100 arm64: dts: qcom: add missing denali-oled.dtb to Makefile [ Upstream commit 9ffb2dfcc955faa5072cf8de547ae5909544fdad ] The DeviceTree for the OLED variant of the Microsoft Surface Pro 11th Edition was originally added in commit '0d72ccaa1e84 ("arm64: dts: qcom: Add support for X1-based Surface Pro 11")'. The original patch on the mailing list also added the new device tree to the Makefile but that part seems to have been dropped (by accident) when it got merged. Signed-off-by: Tobias Heider Fixes: 0d72ccaa1e84 ("arm64: dts: qcom: Add support for X1-based Surface Pro 11") Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260226140429.232544-3-tobias.heider@canonical.com [bjorn: Rewrote commit message reference to offending commit] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit da8b650672a5a6d7a1ce922b3e79253b7c03ff19 Author: Riccardo Mereu Date: Fri Feb 13 11:10:02 2026 +0100 arm64: dts: qcom: arduino-imola: fix faulty spidev node [ Upstream commit 1a040df09fab28b31399fce14a76455b536a2b08 ] CS pin added on pinctrl0 property is causing spidev to return -ENODEV since that GPIO is already part of spi5 pinmuxing. Fixes: 3f745bc0f11f ("arm64: dts: qcom: qrb2210: add dts for Arduino unoq") Signed-off-by: Riccardo Mereu Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260213101002.105238-1-r.mereu.kernel@arduino.cc Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 28f32024a8fddc2cae3813dbaf054ca8ae0b19ee Author: Gatien Chevallier Date: Thu Jan 29 13:56:17 2026 +0100 bus: rifsc: fix RIF configuration check for peripherals [ Upstream commit d5ce3b4e951bc41a6ce877c8500bb4fe42146669 ] Peripheral holding CID0 cannot be accessed, remove this completely incorrect check. While there, fix and simplify the semaphore checking that should be performed when the CID filtering is enabled. Fixes: a18208457253 ("bus: rifsc: introduce RIFSC firewall controller driver") Signed-off-by: Gatien Chevallier Link: https://lore.kernel.org/r/20260129-fix_cid_check_rifsc-v1-1-ef280ccf764d@foss.st.com Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit ed7881948d740d7f63c1baf81cdcabd846aa7cda Author: Shawn Lin Date: Thu Mar 12 09:11:53 2026 +0800 arm64: dts: rockchip: Add mphy reset to ufshc node [ Upstream commit 792c42da47fa199f90492784e3c57280acd57f22 ] The mphy reset signal is used to reset the physical adapter. Resetting other components while leaving the mphy unreset may occasionally prevent the UFS controller from successfully linking up with the device. This addresses an intermittent hardware bug where the UFS link fails to establish under specific timing conditions with certain chips. While difficult to reproduce initially, this issue was consistently observed in downstream testing and requires explicit mphy reset control for full stability. Fixes: c75e5e010fef ("scsi: arm64: dts: rockchip: Add UFS support for RK3576 SoC") Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1773277913-29580-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 0e34e56ed34a22024a627a42bfe186b2ba455eaf Author: 谢致邦 (XIE Zhibang) Date: Thu Mar 19 13:55:00 2026 +0000 arm64: dts: rockchip: Fix RK3562 EVB2 model name [ Upstream commit ede6a05606892bab4f6d785ffcfc124150c2eb32 ] The model name should be "Rockchip RK3562 EVB2 V10 Board". Fixes: ceb6ef1ea900 ("arm64: dts: rockchip: Add RK3562 evb2 devicetree") Signed-off-by: 谢致邦 (XIE Zhibang) Link: https://patch.msgid.link/tencent_78E7E3F6991FB4403D5ADC9E6A6BC3BF8307@qq.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 4bfea5f06f5901be7c8fa47cd54f45badd50aebb Author: Aurelien Jarno Date: Sun Mar 22 21:25:01 2026 +0100 riscv: dts: spacemit: drop incorrect pinctrl for combo PHY [ Upstream commit c68360c0d636dae71f766b7b296ddfcf2827ccc7 ] The combo PHY on the Banana Pi F3 is used for the USB 3.0 port. The high speed differential lanes are always configured as such, and do not require a pinctrl entry. The existing pinctrl entry only configures PCIe secondary pins, which are unused for USB and instead routed to the MIPI CSI1 connector. Remove this incorrect pinctrl entry. Fixes: 0be016a4b5d1b9 ("riscv: dts: spacemit: PCIe and PHY-related updates") Signed-off-by: Aurelien Jarno Reviewed-by: Yixun Lan Link: https://lore.kernel.org/r/20260322202502.2205755-1-aurelien@aurel32.net Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit a8edb3e9e3f09452f4657a4b2739eb5bf1a42b3d Author: Dmitry Baryshkov Date: Mon Mar 23 03:20:59 2026 +0200 soc: qcom: ocmem: return -EPROBE_DEFER is ocmem is not available [ Upstream commit 91b59009c7d48b58dbc50fecb27f2ad20749a05a ] If OCMEM is declared in DT, it is expected that it is present and handled by the driver. The GPU driver will ignore -ENODEV error, which typically means that OCMEM isn't defined in DT. Let ocmem return -EPROBE_DEFER if it supposed to be used, but it is not probed (yet). Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260323-ocmem-v1-3-ad9bcae44763@oss.qualcomm.com [bjorn: s/ERR_PTR(dev_err_probe)/dev_err_ptr_probe/ Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c96ed851ae76dcd789a0524958180962dc47e28b Author: Dmitry Baryshkov Date: Mon Mar 23 03:20:58 2026 +0200 soc: qcom: ocmem: register reasons for probe deferrals [ Upstream commit 9dfd69cd89cd6afa4723be9098979abeef3bb8c6 ] Instead of printing messages to the dmesg, let the message be recorded as a reason for the OCMEM client deferral. Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver") Signed-off-by: Dmitry Baryshkov Reviewed-by: Brian Masney Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260323-ocmem-v1-2-ad9bcae44763@oss.qualcomm.com [bjorn: s/ERR_PTR(dev_err_probe)/dev_err_ptr_probe/ Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 249826471902cdd7b5fa23bda70eb5c8c2289b9e Author: Dmitry Baryshkov Date: Mon Mar 23 03:20:57 2026 +0200 soc: qcom: ocmem: make the core clock optional [ Upstream commit e8a61c51417c679d1a599fb36695e9d3b8d95514 ] OCMEM's core clock (aka RPM bus 2 clock) is being handled internally by the interconnect driver. Corresponding clock has been dropped from the SMD RPM clock driver. The users of the ocmem will vote on the ocmemnoc interconnect paths, making sure that ocmem is on. Make the clock optional, keeping it for compatibility with older DT. Fixes: d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out interconnect bus clocks") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260323-ocmem-v1-1-ad9bcae44763@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 290d221bb6b2ed381b789929fb18e15417b0e6c9 Author: Chris Morgan Date: Tue Mar 10 08:49:19 2026 -0500 arm64: dts: rockchip: Correct Joystick Axes on Gameforce Ace [ Upstream commit c337c1b561c1c3016d30776d7dc2032ea4979334 ] The Gameforce Ace's joystick axes were set incorrectly initially, getting the X/Y and RX/RY axes backwards. Additionally, correct the RY axis so that it is inverted. All axes tested with evtest and outputting correct values. Fixes: 4e946c447a04 ("arm64: dts: rockchip: Add GameForce Ace") Reported-by: sydarn Signed-off-by: Chris Morgan Link: https://patch.msgid.link/20260310134919.550023-1-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit dc4d4da277fd8be68a8d926b422c439d766d7279 Author: Chris Morgan Date: Tue Mar 10 08:46:48 2026 -0500 arm64: dts: rockchip: Correct Fan Supply for Gameforce Ace [ Upstream commit c7079215b7dbf88b84a95ff13982bf3dab3cfbe1 ] Correct the regulator providing power to the PWM controlled fan. Without this fix the fan only runs when the audio path is playing audio (because the speaker amplifier and PWM fan share the same regulator). Fixes: 4e946c447a04 ("arm64: dts: rockchip: Add GameForce Ace") Signed-off-by: Chris Morgan Link: https://patch.msgid.link/20260310134648.550006-1-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit f4090e279461f11544802eedc1aa251c1dccc9ef Author: Robin Murphy Date: Mon Jan 26 12:32:04 2026 +0000 Revert "arm64: dts: rockchip: add SPDIF audio to Beelink A1" [ Upstream commit 03978cb18059ecd27e3d955508b18cf2a1196142 ] This reverts commit bdc4d388c6452498ab62ef2564589f40e0c8c262. While Beelink A1 mostly follows the high-end RK3328 reference design, it does not in fact have the S/PDIF connector, only HDMI and a 3.5mm jack for the analog audio/TV codecs - the tiny form factor literally doesn't have room to fit more! Cc: Christian Hewitt Cc: Alex Bee Fixes: bdc4d388c645 ("arm64: dts: rockchip: add SPDIF audio to Beelink A1") Signed-off-by: Robin Murphy Link: https://patch.msgid.link/0af77a02c2b0806d4ca72066392a5453fcc89a8f.1767111968.git.robin.murphy@arm.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 3e33a6752ea79c67daeaf89a3936a85883659605 Author: Ming Wang Date: Fri Feb 6 17:04:53 2026 +0800 arm64: dts: rockchip: Fix Bluetooth stability on LCKFB TaiShan Pi [ Upstream commit 861a9593e10bb6ab2a492b315c8a2a3aad70ac00 ] The AP6212 WiFi/BT module on the LCKFB TaiShan Pi (RK3566) is prone to communication timeouts and reset failures (error -110) when operating at 3 Mbps. This patch stabilizes the Bluetooth interface by: 1. Updating the compatible string to 'brcm,bcm43430a1-bt' to better reflect the actual chip revision used in the AP6212 module. 2. Lowering the maximum UART baud rate from 3,000,000 to 1,500,000 bps. Tests show that 1.5 Mbps is the reliable upper limit for this board's UART configuration, eliminating the initialization timeouts. Fixes: 251e5ade9ba4 ("arm64: dts: rockchip: add dts for LCKFB Taishan Pi RK3566") Signed-off-by: Ming Wang Link: https://patch.msgid.link/20260206090453.1041919-1-wming126@126.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 7fc79714479a17ba4e84dd3c35cc70d4b737e47a Author: Dmitry Baryshkov Date: Sat Feb 28 20:34:27 2026 +0200 soc: qcom: ubwc: disable bank swizzling for Glymur platform [ Upstream commit e031e7ceac4ee04973bd77362c363734e79dd08c ] Due to the way the DDR controller is organized on Glymur, hardware engineers strongly recommended disabling UBWC bank swizzling on Glymur. Follow that recommendation. Fixes: 9b21c3bd2480 ("soc: qcom: ubwc: Add configuration Glymur platform") Signed-off-by: Dmitry Baryshkov Acked-by: Rob Clark Reviewed-by: Konrad Dybcio Reviewed-by: Abel Vesa Reviewed-by: Akhil P Oommen Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20260228-fix-glymur-ubwc-v2-1-70819bd6a6b4@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c1abcf55476f9ccbf2a32f98bdd5083326c6aad0 Author: Mukesh Ojha Date: Tue Mar 10 19:32:55 2026 +0530 firmware: qcom_scm: don't opencode kmemdup [ Upstream commit e32701726c0e6312aabd83aa1c00f59b0d7df276 ] Lets not opencode kmemdup which is reported by coccinelle tool. Fix it using kmemdup. cocci warnings: (new ones prefixed by >>) >> drivers/firmware/qcom/qcom_scm.c:916:11-18: WARNING opportunity for kmemdup Fixes: 8b9d2050cfa0 ("firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202601142144.HvSlBSI9-lkp@intel.com/ Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260310140255.2520230-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d273ed149fc17ea059a5291db1df3da023eaa3f4 Author: Barnabás Czémán Date: Fri Jan 16 08:07:39 2026 +0100 arm64: dts: qcom: msm8953-xiaomi-daisy: fix backlight [ Upstream commit 7131f6d909a6546329b71f2bacfdc60cb3e6020e ] The backlight on this device is connected via 3 strings. Currently, the DT claims only two are present, which results in visible stripes on the display (since every third backlight string remains unconfigured). Fix the number of strings to avoid that. Fixes: 38d779c26395 ("arm64: dts: qcom: msm8953: Add device tree for Xiaomi Mi A2 Lite") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260116-pmi8950-wled-v3-7-e6c93de84079@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c68ef927706f843a77f68bebdc6956a11c3ca6cd Author: Barnabás Czémán Date: Fri Jan 16 08:07:38 2026 +0100 arm64: dts: qcom: msm8937-xiaomi-land: correct wled ovp value [ Upstream commit 9bc4b18a425e8cf1bca190a136a11c3be516f513 ] PMI8950 doesn't actually support setting an OVP threshold value of 29.6 V. The closest allowed value is 29.5 V. Set that instead. Fixes: 2144f6d57d8e ("arm64: dts: qcom: Add Xiaomi Redmi 3S") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260116-pmi8950-wled-v3-6-e6c93de84079@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1cf87dd167b2965522d40c28ad58c993dfdf17da Author: Barnabás Czémán Date: Fri Jan 16 08:07:37 2026 +0100 arm64: dts: qcom: msm8953-xiaomi-vince: correct wled ovp value [ Upstream commit 9e87f0eaadccc3fecdf3c3c0334e05694804b5f5 ] PMI8950 doesn't actually support setting an OVP threshold value of 29.6 V. The closest allowed value is 29.5 V. Set that instead. Fixes: aa17e707e04a ("arm64: dts: qcom: msm8953: Add device tree for Xiaomi Redmi 5 Plus") Reviewed-by: Konrad Dybcio Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20260116-pmi8950-wled-v3-5-e6c93de84079@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7cbbbd11bba58bb43110caed3387f3b183c6c79e Author: Miquel Raynal Date: Wed Feb 4 10:15:30 2026 +0100 ARM: dts: BCM5301X: Drop extra NAND controller compatible [ Upstream commit f699e0aa7a1382f52fb6f3e8e26754e7aaad6db6 ] Fix the dtbs_check warning introduced when the brcm,brcmnand fallback compatible got removed for iProc machines. Fixes: 4db35366d6dc ("dt-bindings: mtd: brcm,brcmnand: Drop "brcm,brcmnand" compatible for iProc") Signed-off-by: Miquel Raynal Acked-by: Rob Herring (Arm) Acked-by: William Zhang Link: https://lore.kernel.org/r/20260204091530.624230-1-miquel.raynal@bootlin.com Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 8e55b87c7c20a69853f40cc3e4cda79d2df9e451 Author: Josua Mayer Date: Thu Feb 26 18:36:32 2026 +0200 arm64: dts: imx8mp-hummingboard-pulse: fix mini-hdmi dsi port reference [ Upstream commit 1d1d14d4253e6f373c247e67f3716768910be81e ] imx8mp.dtsi includes a default port@1 node with an empty placeholder endpoint intended for linking to a dsi bridge or panel. HummingBoard Pulse mini-hdmi dtsi described a new endpoint node with a different label attached. This duplicate label causes confusion and is suspected to also cause errors during dsi_attach. Remove the duplicate node and link to the one defined in soc dtsi. Further remove the unnecessary attach-bridge property. Fixes: 2a222aa2bee9 ("arm64: dts: add description for solidrun imx8mp hummingboard variants") Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit f8dc8586597879f97818206a87aeee90555d07d5 Author: Josua Mayer Date: Thu Feb 26 18:36:31 2026 +0200 arm64: dts: imx8mp-hummingboard-pulse/cubox-m: fix vmmc gpio polarity [ Upstream commit 70ecea46d36b3b0ddcbe71f9cde8d0df00c11f87 ] Fix the polarity in vmmc regulator node for the gpio from active-high to active-low. This is a cosmetic change as regulator default to active-low unless property enable-active-high was also specified - ignoring the flag on gpio handle. Fixes: a009c0c66ecb ("arm64: dts: add description for solidrun imx8mp som and cubox-m") Fixes: 2a222aa2bee9 ("arm64: dts: add description for solidrun imx8mp hummingboard variants") Reviewed-by: Frank Li Signed-off-by: Josua Mayer Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit c96259a2ad6cb96fe49d9e376aa3dd7ba8938d23 Author: Frieder Schrempf Date: Fri Feb 20 11:36:17 2026 +0100 arm64: dts: imx8mp-kontron: Drop vmmc-supply to fix SD card on SMARC eval carrier [ Upstream commit d2ce84eecf081056b1d18d7524de52f849281ba7 ] The SMARC evaluation carrier provides an SD card power switch that complies with the OSM standard definition. The OSM base devicetree already describes this correctly. Stop overriding the vmmc-supply in the board devicetree and rely on the definition from the OSM base DTS instead to fix the power supply configuration for the SD card. Fixes: 6fe1ced5ccab7 ("arm64: dts: Add support for Kontron i.MX8MP SMARC module and eval carrier") Signed-off-by: Frieder Schrempf Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 03c6f8ef97c2674aca054fe1f49dc30255e29a44 Author: Frieder Schrempf Date: Fri Feb 20 11:36:16 2026 +0100 arm64: dts: imx8mp-kontron: Fix touch reset configuration on DL devices [ Upstream commit 058c53476dde9937877e93d964a283bbb5e1e4c7 ] The reset signal needs a pullup, but there is no hardware pullup. As a workaround, enable the internal pullup to fix the touchscreen. As this deviates from the default generic GPIO settings in the OSM devicetree, add a new node for the touch pinctrl and redefine the generic gpio1 pinctrl. Fixes: 946ab10e3f40f ("arm64: dts: Add support for Kontron OSM-S i.MX8MP SoM and BL carrier board") Signed-off-by: Frieder Schrempf Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit dbbeceb4c9909aae6e6e83702efec249c77c66e1 Author: Thorsten Blum Date: Thu Mar 12 17:40:42 2026 +0100 iommufd/selftest: Fix page leaks in mock_viommu_{init,destroy} [ Upstream commit 09c091fddb0b93297ea659ab48ee64f54ebeeaa2 ] mock_viommu_init() allocates two pages using __get_free_pages(..., 1), but its error path and mock_viommu_destroy() only release the first page using free_page(), leaking the second page. Use free_pages() with the matching order instead to avoid any page leaks. Fixes: 80478a2b450e ("iommufd/selftest: Add coverage for the new mmap interface") Link: https://patch.msgid.link/r/20260312164040.457293-3-thorsten.blum@linux.dev Signed-off-by: Thorsten Blum Reviewed-by: Nicolin Chen Reviewed-by: Pranjal Shrivastava Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 442b3e675e67f07b44b567d493b763d87be6e822 Author: Akari Tsuyukusa Date: Thu Mar 12 13:15:30 2026 +0900 arm64: dts: mediatek: mt7986a: Fix gpio-ranges pin count [ Upstream commit 820ed0c1a13c5fafb36232538d793f99a0986ef3 ] The gpio-ranges in the MT7986A pinctrl node were incorrectly defined, therefore, pin 100 cannot be used. Correct the range count to match the driver. Fixes: c3a064a32ed9 ("arm64: dts: mediatek: add pinctrl support for mt7986a") Signed-off-by: Akari Tsuyukusa Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 6de66a05df3014adcc251a25be6da50c1c8c16fb Author: Akari Tsuyukusa Date: Thu Mar 12 13:15:29 2026 +0900 arm64: dts: mediatek: mt7981b: Fix gpio-ranges pin count [ Upstream commit b62a927f4a46a7f58d88ba3d5fb6e88e1a4b4603 ] The gpio-ranges in the MT7981B pinctrl node were incorrectly defined, therefore, pin 56 cannot be used. Correct the range count to match the driver. Fixes: 62b24c7fdf0a ("arm64: dts: mediatek: mt7981: add pinctrl") Signed-off-by: Akari Tsuyukusa Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit ba5506e2bfb7a63a1007d74b114643c96b6c083d Author: Akari Tsuyukusa Date: Thu Mar 12 13:15:28 2026 +0900 arm64: dts: mediatek: mt6795: Fix gpio-ranges pin count [ Upstream commit c4c4823c8a5baa10b8100b01f49d7c3f4a871689 ] The gpio-ranges in the MT6795 pinctrl node were incorrectly defined, therefore, GPIO196 cannot be used. Correct the range count to match the driver. Fixes: b888886a4536 ("arm64: dts: mediatek: mt6795: Add pinctrl controller node") Signed-off-by: Akari Tsuyukusa Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 5c5225ce4f57202b0aac5431a576d536d220e181 Author: Kendall Willis Date: Thu Feb 19 13:43:16 2026 -0600 arm64: dts: ti: k3-am62l: include WKUP_UART0 in wakeup peripheral window [ Upstream commit e5452968a4b04f93bf9b778ccfd00f79e4d4f529 ] WKUP_UART0 is apart of the wakeup peripherals and has a range from 0x002B300000 to 0x002B3001FF. Expand the wakeup peripheral window to include WKUP_UART0. Fixes: 5f016758b0ab ("arm64: dts: ti: k3-am62l: add initial infrastructure") Reviewed-by: Dhruva Gole Signed-off-by: Kendall Willis Link: https://patch.msgid.link/20260219-v6-19-wkup-uart-wakeup-v4-1-eda09dce5623@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 7e177c62d6e3943d291ab8358c5b240bb1f90d29 Author: Konrad Dybcio Date: Mon Jan 26 10:45:03 2026 +0100 arm64: dts: qcom: talos: Add missing clock-names to GCC [ Upstream commit c653607929bb4e0d8b80573bdb523adab5b975c2 ] The binding for this clock controller requires that clock-names are present. They're not really used by the kernel driver, but they're marked as required, so someone might have assumed it's done on purpose (where in reality we try to stay away from that since index-based references are faster, take up less space and are already widely used) and referenced it in drivers for another OS. Hence, do the least painful thing and add the missing entries. Fixes: 8e266654a2fe ("arm64: dts: qcom: add QCS615 platform") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20260126-topic-talos_dt_warn-v1-1-c452afc647ad@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5080fdea369596141502d05ca4fd44944e165bb5 Author: Hongyang Zhao Date: Sat Feb 7 15:32:56 2026 +0800 arm64: dts: qcom: qcs6490-rubikpi3: Use lt9611 DSI Port B [ Upstream commit ebcf2240a2494faf202ce5ec80ef159a38b1e542 ] The LT9611 HDMI bridge on RubikPi3 has DSI physically connected to Port B. Update the devicetree to use port@1 which corresponds to Port B input on the LT9611. Fixes: f055a39f6874 ("arm64: dts: qcom: Add qcs6490-rubikpi3 board dts") Reviewed-by: Konrad Dybcio Signed-off-by: Hongyang Zhao Reviewed-by: Roger Shimizu Tested-by: Roger Shimizu Link: https://lore.kernel.org/r/20260207-rubikpi-next-20260116-v3-3-23b9aa189a3a@thundersoft.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ff82b323c998fbebd1e85611f597f2271c1b37f8 Author: Barnabás Czémán Date: Mon Jan 26 17:34:55 2026 +0100 arm64: dts: qcom: sm6125-xiaomi-ginkgo: Fix reserved gpio ranges [ Upstream commit e8669e010991154bedadd1cd67700544e0362e99 ] The device was crashing on boot because the reserved gpio ranges was wrongly defined. Correct the ranges for avoid pinctrl crashing. Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for xiaomi-ginkgo") Tested-by: Biswapriyo Nath Reviewed-by: Konrad Dybcio Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20260126-xiaomi-willow-v3-5-aad7b106c311@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 79d2abe4353bd9a6e9ced6e4de7f22e057914d7f Author: Barnabás Czémán Date: Mon Jan 26 17:34:54 2026 +0100 arm64: dts: qcom: sm6125-xiaomi-ginkgo: Remove extcon [ Upstream commit 79664600fd3ed3972ad9321e13d1f80267730447 ] GPIO pin 102 is related to DisplayPort what is not supported by this device and it is also disabled at downstream, remove the unnecessary extcon-usb node. Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for xiaomi-ginkgo") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20260126-xiaomi-willow-v3-4-aad7b106c311@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit fc39bf2a70b5b5bca6b04eb26e7fd10ebbf1e7c6 Author: Barnabás Czémán Date: Mon Jan 26 17:34:52 2026 +0100 arm64: dts: qcom: sm6125-xiaomi-ginkgo: Correct reserved memory ranges [ Upstream commit 242801cc24e865cb525ef7d826ce6ebeffcad606 ] The device was crashing on high memory load because the reserved memory ranges was wrongly defined. Correct the ranges for avoid the crashes. Change the ramoops memory range to match with the values from the recovery to be able to get the results from the device. Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for xiaomi-ginkgo") Reviewed-by: Konrad Dybcio Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20260126-xiaomi-willow-v3-2-aad7b106c311@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e3d8680b707bc49ba16d7cc21431d2d6d698ae1b Author: Barnabás Czémán Date: Mon Jan 26 17:34:51 2026 +0100 arm64: dts: qcom: sm6125-xiaomi-ginkgo: Remove board-id [ Upstream commit 535e5741bc9acef5ea2561aa300f28370599e7e2 ] Remove board-id it is not necessary for the bootloader. Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for xiaomi-ginkgo") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20260126-xiaomi-willow-v3-1-aad7b106c311@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2e7a52223b880bb2c81297e4ca71d76d67657284 Author: Jacob Pan Date: Fri Feb 13 10:36:36 2026 -0800 iommufd: vfio compatibility extension check for noiommu mode [ Upstream commit 7147ec874ea08c322d779d8eba28946e294ed1f3 ] VFIO_CHECK_EXTENSION should return false for TYPE1_IOMMU variants when in NO-IOMMU mode and IOMMUFD compat container is set. This change makes the behavior match VFIO_CONTAINER in noiommu mode. It also prevents userspace from incorrectly attempting to use TYPE1 IOMMU operations in a no-iommu context. Fixes: d624d6652a65 ("iommufd: vfio container FD ioctl compatibility") Link: https://patch.msgid.link/r/20260213183636.3340-1-jacob.pan@linux.microsoft.com Signed-off-by: Jacob Pan Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d8877de422d36463a51c3265ec9dee7da4d5f6dd Author: Sherry Sun Date: Thu Feb 5 15:34:53 2026 +0800 arm64: dts: imx8mp-evk: Enable pull select bit for PCIe regulator GPIO (M.2 W_DISABLE1) [ Upstream commit d1e7eab6033f9885a02c4b4e8f09e34d8e9d21ab ] The current pin configuration for MX8MP_IOMUXC_SD1_DATA4__GPIO2_IO06 sets the weak pull-up but does not enable the pull select field. Bit 8 in the IOMUX register must be set in order for the weak pull-up to actually take effect. Update the pinctrl setting from 0x40 to 0x140 to enable both the pull select and the weak pull-up, ensuring the line behaves as expected. Fixes: d50650500064 ("arm64: dts: imx8mp-evk: Add PCIe support") Signed-off-by: Sherry Sun Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 9d40fb3c7c8f5cb3489b7dd37f7379caf9736702 Author: Heiko Stuebner Date: Tue Feb 10 09:03:02 2026 +0100 arm64: dts: rockchip: Make Jaguar PCIe-refclk pin use pull-up config [ Upstream commit f45d4356feeba1c8dac3414b688f59292ddfc9f9 ] The hardware PU/PD config of the pin after reset is to pull-up and on Jaguar this will also keep the device in reset until the driver actually enables the pin. So restore this boot pull-up config of the pin on Jaguar instead of setting it to pull-none. Suggested-by: Quentin Schulz Fixes: 0ec7e1096332 ("arm64: dts: rockchip: add PCIe3 support on rk3588-jaguar") Signed-off-by: Heiko Stuebner Reviewed-by: Shawn Lin Reviewed-by: Quentin Schulz Link: https://patch.msgid.link/20260210080303.680403-5-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 9666dc129b972ffcf4cabdcd3e080e34b0e24fd8 Author: Frank Wunderlich Date: Mon Dec 15 08:46:08 2025 +0100 arm64: dts: mediatek: mt7988a-bpi-r4pro: fix model string [ Upstream commit e4e6f0c5a4dc238684acef079e792c81d37e3226 ] Fix incorrect model string in Devicetree for BPI-R4-Pro. Fixes: f397471a6a8c ("arm64: dts: mediatek: mt7988: Add devicetree for BananaPi R4 Pro") Signed-off-by: Frank Wunderlich Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 333d2f08d8c66a5979bf36ece436797bf83fe83f Author: Yixun Lan Date: Thu Feb 26 08:17:55 2026 +0000 riscv: dts: spacemit: pcie: fix missing power regulator [ Upstream commit 8a9071299dec817a544c0fb48f7302396fafdc4b ] The PCIe port require 3.3v power regulator for device to work properly, So explicitly add it to fix the DT warning: arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dtb: pcie@ca400000 (spacemit,k1-pcie): pcie@0: 'vpcie3v3-supply' is a required property from schema $id: http://devicetree.org/schemas/pci/spacemit,k1-pcie-host.yaml Fixes: 0be016a4b5d1 ("riscv: dts: spacemit: PCIe and PHY-related updates") Reported-by: Conor Dooley Link: https://lore.kernel.org/r/20260226-k1-pcie-fix-pwr-v1-1-94b493cd27e5@kernel.org Signed-off-by: Yixun Lan Signed-off-by: Sasha Levin commit 976503f921839f2ae5fa33c3bcf22200b7bc3711 Author: Luke Wang Date: Tue Feb 3 19:23:10 2026 +0800 arm64: dts: imx91-11x11-evk: change usdhc tuning step for eMMC and SD [ Upstream commit 5ab0c76df2403137a6d0fb27a55e03cedf47f44c ] During system resume, the following errors occurred: [ 430.638625] mmc1: error -84 writing Cache Enable bit [ 430.643618] mmc1: error -84 doing runtime resume For eMMC and SD, there are two tuning pass windows and the gap between those two windows may only have one cell. If tuning step > 1, the gap may just be skipped and host assumes those two windows as a continuous windows. This will cause a wrong delay cell near the gap to be selected. Set the tuning step to 1 to avoid selecting the wrong delay cell. For SDIO, the gap is sufficiently large, so the default tuning step does not cause this issue. Fixes: 6772c4cffd87 ("arm64: dts: freescale: add i.MX91 11x11 EVK basic support") Signed-off-by: Luke Wang Reviewed-by: Frank Li Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 170756d2036bc32a2329dc3e480db4f234885af3 Author: Francesco Dolcini Date: Mon Jan 19 11:34:09 2026 +0100 arm64: dts: imx8-apalis: Fix LEDs name collision [ Upstream commit 92ab53b9bb2a72581c32073755077af916eb9aee ] Ixora boards have multiple instances of status leds, to avoid a name collision add the function-enumerator property. This fixes the following Linux kernel warnings: leds-gpio leds: Led green:status renamed to green:status_1 due to name collision leds-gpio leds: Led red:status renamed to red:status_1 due to name collision Fixes: c083131c9021 ("arm64: dts: freescale: add apalis imx8 aka quadmax carrier board support") Signed-off-by: Francesco Dolcini Reviewed-by: Frank Li Reviewed-by: Daniel Baluta Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit 87a8622ba39ef4dfbfa98051431a1beb6c2aeaae Author: Mikko Perttunen Date: Mon Jan 26 15:50:43 2026 +0900 memory: tegra30-emc: Fix dll_change check [ Upstream commit 0a93f2355cf4922ad2399dbef5ea1049fef116d4 ] The code checking whether the specified memory timing enables DLL in the EMRS register was reversed. DLL is enabled if bit A0 is low. Fix the check. Fixes: e34212c75a68 ("memory: tegra: Introduce Tegra30 EMC driver") Signed-off-by: Mikko Perttunen Link: https://patch.msgid.link/20260126-fix-emc-dllchange-v1-2-47ad3bb63262@nvidia.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 1ebbbef47d11cc90219c081492ccf995aaa3e9b3 Author: Mikko Perttunen Date: Mon Jan 26 15:50:42 2026 +0900 memory: tegra124-emc: Fix dll_change check [ Upstream commit 9597ab9a8296ab337e6820f8a717ff621078b632 ] The code checking whether the specified memory timing enables DLL in the EMRS register was reversed. DLL is enabled if bit A0 is low. Fix the check. Fixes: 73a7f0a90641 ("memory: tegra: Add EMC (external memory controller) driver") Signed-off-by: Mikko Perttunen Link: https://patch.msgid.link/20260126-fix-emc-dllchange-v1-1-47ad3bb63262@nvidia.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit eb6d8ca244aa5b9312d7166a14327d4951bbf1a0 Author: Rafał Miłecki Date: Tue Feb 24 09:25:41 2026 +0100 ARM: dts: mediatek: mt7623: fix efuse fallback compatible [ Upstream commit 5978ff33cc6f0988388a2830dc5cd2ea4e81f36a ] Fix following validation error: arch/arm/boot/dts/mediatek/mt7623a-rfb-emmc.dtb: efuse@10206000: compatible: 'oneOf' conditional failed, one must be fixed: ['mediatek,mt7623-efuse', 'mediatek,mt8173-efuse'] is too long 'mediatek,mt8173-efuse' was expected 'mediatek,efuse' was expected from schema $id: http://devicetree.org/schemas/nvmem/mediatek,efuse.yaml# arch/arm/boot/dts/mediatek/mt7623a-rfb-emmc.dtb: efuse@10206000: Unevaluated properties are not allowed ('compatible' was unexpected) from schema $id: http://devicetree.org/schemas/nvmem/mediatek,efuse.yaml# Fixes: 43c7a91b4b3a ("arm: dts: mt7623: add efuse nodes to the mt7623.dtsi file") Signed-off-by: Rafał Miłecki Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit aad63e76cafc9b51c56238e30504e2ec07cb7a47 Author: Nícolas F. R. A. Prado Date: Fri May 2 12:43:22 2025 -0400 arm64: dts: mediatek: mt8365: Describe infracfg-nao as a pure syscon [ Upstream commit 0651c24658360706c30588cec0a12c05edb03e9a ] The infracfg-nao register space at 0x1020e000 has different registers than the infracfg space at 0x10001000, and most importantly, doesn't contain any clock controls. Therefore it shouldn't use the same compatible used for the mt8365 infracfg clocks driver: mediatek,mt8365-infracfg. Since it currently does, probe errors are reported in the kernel logs: [ 0.245959] Failed to register clk ifr_pmic_tmr: -EEXIST [ 0.245998] clk-mt8365 1020e000.infracfg: probe with driver clk-mt8365 failed with error -17 This register space is used only as a syscon for bus control by the power domain controller, so in order to properly describe it and fix the errors, set its compatible to a distinct compatible used exclusively as a syscon, drop the clock-cells, and while at it rename the node to 'syscon' following the naming convention. Fixes: 6ff945376556 ("arm64: dts: mediatek: Initial mt8365-evk support") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: David Lechner Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit b46aa129fa2807bfe1545fe74d9295d53c51520b Author: Joshua Klinesmith Date: Mon Apr 6 22:31:12 2026 -0400 ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine [ Upstream commit 3e298897f41c61450c2e7a4f457e8b2485eb35b3 ] ksmbd_crypt_message() sets a NULL completion callback on AEAD requests and does not handle the -EINPROGRESS return code from async hardware crypto engines like the Qualcomm Crypto Engine (QCE). When QCE returns -EINPROGRESS, ksmbd treats it as an error and immediately frees the request while the hardware DMA operation is still in flight. The DMA completion callback then dereferences freed memory, causing a NULL pointer crash: pc : qce_skcipher_done+0x24/0x174 lr : vchan_complete+0x230/0x27c ... el1h_64_irq+0x68/0x6c ksmbd_free_work_struct+0x20/0x118 [ksmbd] ksmbd_exit_file_cache+0x694/0xa4c [ksmbd] Use the standard crypto_wait_req() pattern with crypto_req_done() as the completion callback, matching the approach used by the SMB client in fs/smb/client/smb2ops.c. This properly handles both synchronous engines (immediate return) and async engines (-EINPROGRESS followed by callback notification). Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Link: https://github.com/openwrt/openwrt/issues/21822 Signed-off-by: Joshua Klinesmith Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit ab3f7098a3a27175b91cfc947950f5c26855801b Author: Thomas Huth Date: Fri Apr 10 17:46:37 2026 +0200 efi/capsule-loader: fix incorrect sizeof in phys array reallocation [ Upstream commit 48a428215782321b56956974f23593e40ce84b7a ] The krealloc() call for cap_info->phys in __efi_capsule_setup_info() uses sizeof(phys_addr_t *) instead of sizeof(phys_addr_t), which might be causing an undersized allocation. The allocation is also inconsistent with the initial array allocation in efi_capsule_open() that allocates one entry with sizeof(phys_addr_t), and the efi_capsule_write() function that stores phys_addr_t values (not pointers) via page_to_phys(). On 64-bit systems where sizeof(phys_addr_t) == sizeof(phys_addr_t *), this goes unnoticed. On 32-bit systems with PAE where phys_addr_t is 64-bit but pointers are 32-bit, this allocates half the required space, which might lead to a heap buffer overflow when storing physical addresses. This is similar to the bug fixed in commit fccfa646ef36 ("efi/capsule-loader: fix incorrect allocation size") which fixed the same issue at the initial allocation site. Fixes: f24c4d478013 ("efi/capsule-loader: Reinstate virtual capsule mapping") Assisted-by: Claude:claude-sonnet-4-5 Signed-off-by: Thomas Huth Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit abd73229f0e886a91a16ea781ab656bd9b4d1ee8 Author: Andreas Gruenbacher Date: Tue Apr 7 12:14:30 2026 +0200 gfs2: prevent NULL pointer dereference during unmount [ Upstream commit 74b4dbb946060a3233604d91859a9abd3708141d ] When flushing out outstanding glock work during an unmount, gfs2_log_flush() can be called when sdp->sd_jdesc has already been deallocated and sdp->sd_jdesc is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it missed the sdp->sd_jdesc dereference in gfs2_log_release(). Fix that. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202604071139.HNJiCaAi-lkp@intel.com/ Fixes: 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 98e8bf249c790d56de1abc4a5f8bd68035a00921 Author: Andreas Gruenbacher Date: Tue Mar 31 06:13:42 2026 +0200 gfs2: add some missing log locking [ Upstream commit fe2c8d051150b90b3ccb85f89e3b1d636cb88ec8 ] Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(), gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock, but these functions require exclusion against concurrent transactions. To fix that, add a non-locking __gfs2_log_flush() function. Then, in gfs2_logd(), take sdp->sd_log_flush_lock before calling the above mentioned log flushing functions and __gfs2_log_flush(). Fixes: 5e4c7632aae1c ("gfs2: Issue revokes more intelligently") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit f29e2a8dddacda0d331530169534e02534f22484 Author: Arnd Bergmann Date: Fri Mar 27 17:55:08 2026 +0100 vfio: unhide vdev->debug_root [ Upstream commit 555aa178f8d22261d71da74df6267e6e6e97f95a ] When debugfs is disabled, the hisilicon driver now fails to build: drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c: In function 'hisi_acc_vfio_debug_init': drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c:1671:62: error: 'struct vfio_device' has no member named 'debug_root' 1671 | vfio_dev_migration = debugfs_lookup("migration", vdev->debug_root); | ^~ The driver otherwise relies on dead-code elimination, but this reference fails. The single struct member is not going to make much of a difference for memory consumption, so just keep this visible unconditionally. Signed-off-by: Arnd Bergmann Fixes: b398f91779b8 ("hisi_acc_vfio_pci: register debugfs for hisilicon migration driver") Link: https://lore.kernel.org/r/20260327165521.3779707-1-arnd@kernel.org Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 82cbdb4c1ebb5ea7d7bd45c18d3483b5bd32ebc1 Author: Jan Kara Date: Fri Feb 27 14:22:16 2026 +0100 quota: Fix race of dquot_scan_active() with quota deactivation [ Upstream commit e93ab401da4b2e2c1b8ef2424de2f238d51c8b2d ] dquot_scan_active() can race with quota deactivation in quota_release_workfn() like: CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set */ spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { /* finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count)); The problem is not only a cosmetic one as under memory pressure the caller of dquot_scan_active() can end up working on freed dquot. Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it. Fixes: 869b6ea1609f ("quota: Fix slow quotaoff") Reported-by: Sam Sun Link: https://lore.kernel.org/all/CAEkJfYPTt3uP1vAYnQ5V2ZWn5O9PLhhGi5HbOcAzyP9vbXyjeg@mail.gmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 1c7b6ce6b2908d7ebda265b4c19c5f2e165b7e9f Author: Andreas Gruenbacher Date: Fri Mar 6 18:05:48 2026 +0100 gfs2: less aggressive low-memory log flushing [ Upstream commit 7288185ce87ec70133b7bc3b694b0f74bf46a0ee ] It turns out that for some workloads, the fix in commit b74cd55aa9a9d ("gfs2: low-memory forced flush fixes") causes the number of forced log flushes to increase to a degree that the overall filesystem performance drops significantly. Address that by forcing a log flush only when gfs2_writepages cannot make any progress rather than when it cannot make "enough" progress. Fixes: b74cd55aa9a9d ("gfs2: low-memory forced flush fixes") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 6ab32e6899af071904df08cff2b697f9ed72fd8a Author: Ted Logan Date: Thu Mar 19 15:58:47 2026 -0700 vfio: selftests: Build tests on aarch64 [ Upstream commit 1347a742a1e1b080e2e8d200312ae45b8d6ac859 ] Fix vfio selftests on aarch64, allowing native builds on aarch64 hosts. Reported-by: Matt Evans Closes: https://lore.kernel.org/all/e51b4ff2-13c4-47d4-b781-3dcbd740d274@meta.com/ Fixes: a55d4bbbe644 ("vfio: selftests: only build tests on arm64 and x86_64") Signed-off-by: Ted Logan Reviewed-by: David Matlack Link: https://lore.kernel.org/r/20260319-vfio-selftests-aarch64-v2-1-bb2621c24dc4@fb.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit e350f8f06a2d17f274ff38ceb46176936cde2f97 Author: Tomas Glozar Date: Tue Mar 10 17:07:25 2026 +0100 rtla: Fix segfault on multiple SIGINTs [ Upstream commit be8058f31b4e237604e4ce7599593ab68dc69ae7 ] Detach stop_trace() from SIGINT/SIGALRM on tool clean-up to prevent it from crashing RTLA by accessing freed memory. This prevents a crash when multiple SIGINTs are received. Fixes: d6899e560366 ("rtla/timerlat_hist: Abort event processing on second signal") Fixes: 80967b354a76 ("rtla/timerlat_top: Abort event processing on second signal") Reviewed-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20260310160725.144443-1-tglozar@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit 9a771b57ddefcb1c202410c24cc6e4cc859d94fb Author: Costa Shulyupin Date: Thu Jan 8 11:49:55 2026 +0200 tools/rtla: Generate optstring from long options [ Upstream commit 4a1cec7450b7159a0ee57403f44460ac4d618b4f ] getopt_long() processes short and long options independently. RTLA, like the majority of applications, uses both short and long variants for each logical option. Since the val member of struct option holds the letter of the short variant, the string of short options can be reconstructed from the array of long options. Add getopt_auto() to generate optstring from an array of long options, eliminating the need to maintain separate short option strings. Signed-off-by: Costa Shulyupin Reviewed-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20260108095011.2115719-1-costa.shul@redhat.com Signed-off-by: Tomas Glozar Stable-dep-of: be8058f31b4e ("rtla: Fix segfault on multiple SIGINTs") Signed-off-by: Sasha Levin commit 4407a17aeb844d482f98f1f0279b9dbde47165ba Author: Wander Lairson Costa Date: Mon Mar 9 16:46:30 2026 -0300 rtla/utils: Fix resource leak in set_comm_sched_attr() [ Upstream commit 5b6dc659ad792c72b3ff1be8039ae2945e030928 ] The set_comm_sched_attr() function opens the /proc directory via opendir() but fails to call closedir() on its successful exit path. If the function iterates through all processes without error, it returns 0 directly, leaking the DIR stream pointer. Fix this by refactoring the function to use a single exit path. A retval variable is introduced to track the success or failure status. All exit points now jump to a unified out label that calls closedir() before the function returns, ensuring the resource is always freed. Fixes: dada03db9bb19 ("rtla: Remove procps-ng dependency") Signed-off-by: Wander Lairson Costa Link: https://lore.kernel.org/r/20260309195040.1019085-18-wander@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Sasha Levin commit ac15f02fafde0a2e70ddfbb5ab0250640ab31de1 Author: Alex Mastro Date: Tue Mar 3 11:46:24 2026 -0800 vfio: selftests: fix crash in vfio_dma_mapping_mmio_test [ Upstream commit f183963891b4b0126f19aa0993ed931f3f3f9520 ] Remove the __iommu_unmap() call on a region that was never mapped. When __iommu_map() fails (expected for MMIO vaddrs in non-VFIO modes), the region is not added to the dma_regions list, leaving its list_head zero-initialized. If the unmap ioctl returns success, __iommu_unmap() calls list_del_init() on this zeroed node and crashes. This fixes the iommufd_compat_type1 and iommufd_compat_type1v2 test variants. Fixes: 080723f4d4c3 ("vfio: selftests: Add vfio_dma_mapping_mmio_test") Signed-off-by: Alex Mastro Reviewed-by: David Matlack Reviewed-by: Yuan Yao Link: https://lore.kernel.org/r/20260303-fix-mmio-test-v1-1-78b4a9e46a4e@fb.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 08a4db425834447979632728f443b88dc36b8b3c Author: Ricardo B. Marlière Date: Sat Mar 7 19:08:03 2026 -0300 ktest: Run POST_KTEST hooks on failure and cancellation [ Upstream commit bc6e165a452da909cef0efbc286e6695624db372 ] PRE_KTEST can be useful for setting up the environment and POST_KTEST to tear it down, however POST_KTEST only runs on the normal end-of-run path. It is skipped when ktest exits through dodie() or cancel_test(). Final cleanup hooks are skipped. Factor the final hook execution into run_post_ktest(), call it from the normal exit path and from the early exit paths, and guard it so the hook runs at most once. Cc: John Hawley Cc: Andrea Righi Cc: Marcos Paulo de Souza Cc: Matthieu Baerts Cc: Fernando Fernandez Mancera Cc: Pedro Falcato Link: https://patch.msgid.link/20260307-ktest-fixes-v1-8-565d412f4925@suse.com Fixes: 921ed4c7208e ("ktest: Add PRE/POST_KTEST and TEST options") Signed-off-by: Ricardo B. Marlière Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 631f5c39f5db3e57551ac02d0d003e3d258962b1 Author: Ricardo B. Marlière Date: Sat Mar 7 19:07:59 2026 -0300 ktest: Honor empty per-test option overrides [ Upstream commit a2de57a3c8192dcd67cccaff6c341b93748d799b ] A per-test override can clear an inherited default option by assigning an empty value, but __set_test_option() still used option_defined() to decide whether a per-test key existed. That turned an empty per-test assignment back into "fall back to the default", so tests still could not clear inherited settings. For example: DEFAULTS (...) LOG_FILE = /tmp/ktest-empty-override.log CLEAR_LOG = 1 ADD_CONFIG = /tmp/.config TEST_START TEST_TYPE = build BUILD_TYPE = nobuild ADD_CONFIG = This would run the test with ADD_CONFIG[1] = /tmp/.config Fix by checking whether the per-test key exists before falling back. If it does exist but is empty, treat it as unset for that test and stop the fallback chain there. Cc: John Hawley Cc: Andrea Righi Cc: Marcos Paulo de Souza Cc: Matthieu Baerts Cc: Fernando Fernandez Mancera Cc: Pedro Falcato Link: https://patch.msgid.link/20260307-ktest-fixes-v1-4-565d412f4925@suse.com Fixes: 22c37a9ac49d ("ktest: Allow tests to undefine default options") Signed-off-by: Ricardo B. Marlière Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit f031c982f236e5df5f9ea7575b2d83bd0700a41d Author: Ricardo B. Marlière Date: Sat Mar 7 19:07:56 2026 -0300 ktest: Avoid undef warning when WARNINGS_FILE is unset [ Upstream commit 057854f8a595160656fe77ed7bf0d2403724b915 ] check_buildlog() probes $warnings_file with -f even when WARNINGS_FILE is not configured. Perl warns about the uninitialized value and adds noise to the test log, which can hide the output we actually care about. Check that WARNINGS_FILE is defined before testing whether the file exists. Cc: John Hawley Cc: Andrea Righi Cc: Marcos Paulo de Souza Cc: Matthieu Baerts Cc: Fernando Fernandez Mancera Cc: Pedro Falcato Link: https://patch.msgid.link/20260307-ktest-fixes-v1-1-565d412f4925@suse.com Fixes: 4283b169abfb ("ktest: Add make_warnings_file and process full warnings") Signed-off-by: Ricardo B. Marlière Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 3ac9117ba3deab8a5dd22847355f861686f4bee7 Author: Luis Henriques Date: Mon Feb 16 14:48:30 2026 +0000 fuse: fix uninit-value in fuse_dentry_revalidate() [ Upstream commit 5a6baf204610589f8a5b5a1cd69d1fe661d9d3cd ] fuse_dentry_revalidate() may be called with a dentry that didn't had ->d_time initialised. The issue was found with KMSAN, where lookup_open() calls __d_alloc(), followed by d_revalidate(), as shown below: ===================================================== BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394 fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394 d_revalidate fs/namei.c:1030 [inline] lookup_open fs/namei.c:4405 [inline] open_last_lookups fs/namei.c:4583 [inline] path_openat+0x1614/0x64c0 fs/namei.c:4827 do_file_open+0x2aa/0x680 fs/namei.c:4859 [...] Uninit was created at: slab_post_alloc_hook mm/slub.c:4466 [inline] slab_alloc_node mm/slub.c:4788 [inline] kmem_cache_alloc_lru_noprof+0x382/0x1280 mm/slub.c:4807 __d_alloc+0x55/0xa00 fs/dcache.c:1740 d_alloc_parallel+0x99/0x2740 fs/dcache.c:2604 lookup_open fs/namei.c:4398 [inline] open_last_lookups fs/namei.c:4583 [inline] path_openat+0x135f/0x64c0 fs/namei.c:4827 do_file_open+0x2aa/0x680 fs/namei.c:4859 [...] ===================================================== Reported-by: syzbot+fdebb2dc960aa56c600a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69917e0d.050a0220.340abe.02e2.GAE@google.com Fixes: 2396356a945b ("fuse: add more control over cache invalidation behaviour") Signed-off-by: Luis Henriques Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 01d5c7023df09e22856f26e09b3421a66ec6eb2e Author: Ondrej Mosnacek Date: Mon Feb 16 16:06:25 2026 +0100 fanotify: call fanotify_events_supported() before path_permission() and security_path_notify() [ Upstream commit 66052a768d4726a31e939b5ac902f2b0b452c8d5 ] The latter trigger LSM (e.g. SELinux) checks, which will log a denial when permission is denied, so it's better to do them after validity checks to avoid logging a denial when the operation would fail anyway. Fixes: 0b3b094ac9a7 ("fanotify: Disallow permission events for proc filesystem") Signed-off-by: Ondrej Mosnacek Reviewed-by: Amir Goldstein Reviewed-by: Paul Moore Link: https://patch.msgid.link/20260216150625.793013-3-omosnace@redhat.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit a37efb5893213c77547220b9ae295e39c9496d44 Author: Ondrej Mosnacek Date: Mon Feb 16 16:06:24 2026 +0100 fanotify: avoid/silence premature LSM capability checks [ Upstream commit 0d5ee3373426395478c355f3e93ba4b1118a04e9 ] Make sure calling capable()/ns_capable() actually leads to access denied when false is returned, because these functions emit an audit record when a Linux Security Module denies the capability, which makes it difficult to avoid allowing/silencing unnecessary permissions in security policies (namely with SELinux). Where the return value just used to set a flag, use the non-auditing ns_capable_noaudit() instead. Fixes: 7cea2a3c505e ("fanotify: support limited functionality for unprivileged users") Signed-off-by: Ondrej Mosnacek Reviewed-by: Paul Moore Reviewed-by: Amir Goldstein Link: https://patch.msgid.link/20260216150625.793013-2-omosnace@redhat.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 677583b628751eee7e478be0f148ab2ce23388fe Author: Andreas Gruenbacher Date: Mon Feb 23 12:04:05 2026 +0100 gfs2: Call unlock_new_inode before d_instantiate [ Upstream commit 2ff7cf7e0640ff071ebc5c7e3dc2df024a7c91e6 ] As Neil Brown describes in detail in the link referenced below, new inodes must be unlocked before they can be instantiated. An even better fix is to use d_instantiate_new(), which combines d_instantiate() and unlock_new_inode(). Fixes: 3d36e57ff768 ("gfs2: gfs2_create_inode rework") Reported-by: syzbot+0ea5108a1f5fb4fcc2d8@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-fsdevel/177153754005.8396.8777398743501764194@noble.neil.brown.name/ Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit b61bf440a9adee9e2d6c8453f070a8b69c2d1e04 Author: Kailang Yang Date: Tue Apr 14 15:44:04 2026 +0800 ALSA: hda/realtek - fixed speaker no sound update [ Upstream commit 46c862f5419e0a86b60b9f9558d247f6084c99f9 ] Fixed speaker has pop noise on Lenovo Thinkpad X11 Carbon Gen 12. Fixes: 630fbc6e870e ("ALSA: hda/realtek - fixed speaker no sound") Reported-and-tested-by: Jeremy Bethmont Closes: https://lore.kernel.org/CAC88DfsHrhyhy0Pn1O-z9egBvMYu=6NYgcvcC6KCgwh_-Ldkxg@mail.gmail.com Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 62fda50cee83c57280b948481b27ab2d7de2a761 Author: Geoffrey D. Bennett Date: Tue Apr 14 03:03:00 2026 +0930 ALSA: usb-audio: Exclude Scarlett 18i20 1st Gen from SKIP_IFACE_SETUP [ Upstream commit a47306a74c31557b1e5cab54642950bbb20294cb ] Same issue as the other 1st Gen Scarletts: QUIRK_FLAG_SKIP_IFACE_SETUP causes distorted audio on the Scarlett 18i20 1st Gen (1235:800c). Fixes: 38c322068a26 ("ALSA: usb-audio: Add QUIRK_FLAG_SKIP_IFACE_SETUP") Reported-by: tucktuckg00se [https://github.com/geoffreybennett/linux-fcp/issues/54] Signed-off-by: Geoffrey D. Bennett Link: https://patch.msgid.link/ad0ozNnkcFrcjVQz@m.b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ec427dc5286da1ed08f2d510e2147a7581b0cb02 Author: Haixin Xu Date: Mon Mar 30 15:23:46 2026 +0800 crypto: jitterentropy - replace long-held spinlock with mutex [ Upstream commit 01d798e9feb30212952d4e992801ba6bd6a82351 ] jent_kcapi_random() serializes the shared jitterentropy state, but it currently holds a spinlock across the jent_read_entropy() call. That path performs expensive jitter collection and SHA3 conditioning, so parallel readers can trigger stalls as contending waiters spin for the same lock. To prevent non-preemptible lock hold, replace rng->jent_lock with a mutex so contended readers sleep instead of spinning on a shared lock held across expensive entropy generation. Fixes: bb5530e40824 ("crypto: jitterentropy - add jitterentropy RNG") Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Yuan Tan Suggested-by: Xin Liu Signed-off-by: Haixin Xu Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9b2a43131678a2378c14e24e4d973adc499b3f5f Author: Miquel Raynal Date: Fri Apr 10 19:41:01 2026 +0200 spi: cadence-qspi: Revert the filtering of certain opcodes in ODTR [ Upstream commit 5e75c1d4d386fb7d64e2b19355e4d38dd4fd8845 ] I got mislead while analyzing the driver by the fact that the second opcode byte was in all cases smashed: if (op->cmd.dtr) opcode = op->cmd.opcode >> 8; else opcode = op->cmd.opcode; While at a first glance this doesn't let a chance to the second byte to be shifted out on the bus, this is actually the second step of an initialization, where the byte being apparently "ignored" in DTR mode has already been written in a dedicated "extended opcode" register. As such, the comment and the extra check that I proposed were entirely wrong, remove them. Fixes: bee085476d27 ("spi: cadence-qspi: Make sure we filter out unsupported ops") Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20260410-winbond-6-19-rc1-oddr-v1-1-2ac4827a3868@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2eb290ce5a65feaa710f80443d5076fd68c0330c Author: Tejun Heo Date: Fri Apr 10 07:54:06 2026 -1000 sched_ext: Fix ops.cgroup_move() invocation kf_mask and rq tracking [ Upstream commit b470e37c1fad72731be6f437e233cb6b16618f41 ] sched_move_task() invokes ops.cgroup_move() inside task_rq_lock(tsk), so @p's rq lock is held. The SCX_CALL_OP_TASK invocation mislabels this: - kf_mask = SCX_KF_UNLOCKED (== 0), claiming no lock is held. - rq = NULL, so update_locked_rq() doesn't run and scx_locked_rq() returns NULL. Switch to SCX_KF_REST and pass task_rq(p), matching ops.set_cpumask() from set_cpus_allowed_scx(). Three effects: - scx_bpf_task_cgroup() becomes callable (was rejected by scx_kf_allowed(__SCX_KF_RQ_LOCKED)). Safe; rq lock is held. - scx_bpf_dsq_move() is now rejected (was allowed via the unlocked branch). Calling it while holding an unrelated task's rq lock is risky; rejection is correct. - scx_bpf_select_cpu_*() previously took the unlocked branch in select_cpu_from_kfunc() and called task_rq_lock(p, &rf), which would deadlock against the already-held pi_lock. Now it takes the locked-rq branch and is rejected with -EPERM via the existing kf_allowed(SCX_KF_SELECT_CPU | SCX_KF_ENQUEUE) check. Latent deadlock fix. No in-tree scheduler is known to call any of these from ops.cgroup_move(). v2: Add Fixes: tag (Andrea Righi). Fixes: 18853ba782be ("sched_ext: Track currently locked rq") Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Signed-off-by: Sasha Levin commit ff7523ffbff0d9dff94b97b5dc180a1c4f273fff Author: Tejun Heo Date: Fri Apr 10 07:54:06 2026 -1000 sched_ext: Track @p's rq lock across set_cpus_allowed_scx -> ops.set_cpumask [ Upstream commit 9fb457074f6d118b30458624223abef985725a88 ] The SCX_CALL_OP_TASK call site passes rq=NULL incorrectly, leaving scx_locked_rq() unset. Pass task_rq(p) instead so update_locked_rq() reflects reality. v2: Add Fixes: tag (Andrea Righi). Fixes: 18853ba782be ("sched_ext: Track currently locked rq") Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Signed-off-by: Sasha Levin commit d4545b619eb47097499d2e654c4fe6c87ccf45bc Author: Ming-Hung Tsai Date: Fri Apr 10 21:08:01 2026 +0800 dm cache: fix missing return in invalidate_committed's error path [ Upstream commit 8c0ee19db81f0fa1ff25fd75b22b17c0cc2acde3 ] In passthrough mode, dm-cache defers write submission until after metadata commit completes via the invalidate_committed() continuation. On commit error, invalidate_committed() calls invalidate_complete() to end the bio and free the migration struct, after which it should return immediately. The patch 4ca8b8bd952d ("dm cache: fix write hang in passthrough mode") omitted this early return, causing execution to fall through into the success path on error. This results in use-after-free on the migration struct in the subsequent calls. Fix by adding the missing return after the invalidate_complete() call. Fixes: 4ca8b8bd952d ("dm cache: fix write hang in passthrough mode") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/dm-devel/adjMq6T5RRjv_uxM@stanley.mountain/ Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 7f5880b1f026c5512f2c9e9c08234b347de87352 Author: Cássio Gabriel Date: Fri Apr 10 00:54:32 2026 -0300 ALSA: sc6000: Keep the programmed board state in card-private data [ Upstream commit fb79bf127ac2577b4876132da6dba768018aad4c ] The driver may auto-select IRQ and DMA resources at probe time, but sc6000_init_board() still derives the SC-6000 soft configuration from the module parameter arrays. When irq=auto or dma=auto is used, the codec is created with the selected resources while the board is programmed with the unresolved values. Store the mapped ports and generated SC-6000 board configuration in card-private data, build that configuration from the live probe results instead of the raw module parameters, and keep the probe-time board programming in a shared helper. This fixes the resource-programming mismatch and leaves the driver with a stable board-state block that can be reused by suspend/resume. Fixes: c282866101bf ("ALSA: sc6000: add support for SC-6600 and SC-7000") Signed-off-by: Cássio Gabriel Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260410-alsa-sc6000-pm-v1-1-4d9e95493d26@gmail.com Signed-off-by: Sasha Levin commit 98cf4b58299e0c6a537c68cd32155d9e7569e7cb Author: Pei Xiao Date: Tue Apr 7 15:26:59 2026 +0800 spi: mtk-snfi: unregister ECC engine on probe failure and remove() callback [ Upstream commit ab00febad191d7a4400aa1c3468279fb508258d4 ] mtk_snand_probe() registers the on-host NAND ECC engine, but teardown was missing from both probe unwind and remove-time cleanup. Add a devm cleanup action after successful registration so nand_ecc_unregister_on_host_hw_engine() runs automatically on probe failures and during device removal. Fixes: 764f1b748164 ("spi: add driver for MTK SPI NAND Flash Interface") Signed-off-by: Pei Xiao Link: https://patch.msgid.link/20263f885f1a9c9d559f95275298cd6de4b11ed5.1775546401.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit deda245f7a19a93a9f95c6155616010cc42b8bd0 Author: Lad Prabhakar Date: Fri Apr 10 09:05:16 2026 +0100 spi: rzv2h-rspi: Fix invalid SPR=0/BRDV=0 clock configuration [ Upstream commit 0335767dd8e7ade8a8e3028d08c4621515d47388 ] The combination of SPR=0 and BRDV=0 results in the minimum division ratio of 2, producing the maximum possible bit rate for a given clock source. This combination is not supported in two cases: - On RZ/G3E, RZ/G3L, RZ/V2H(P) and RZ/V2N, RSPI_n_TCLK is fixed at 200MHz, which would yield 100Mbps. The next hardware manual update will explicitly state that since the maximum frequency of the RSPICKn clock signal is 50MHz, settings with N=0 and n=0 resulting in 100Mbps are prohibited. - On RZ/T2H and RZ/N2H, when PCLK (125MHz) is used as the clock source, SPR=0 and BRDV=0 is explicitly listed as unsupported in the hardware manual (Table 36.7). Skip the SPR=0/BRDV=0 combination in rzv2h_rspi_find_rate_fixed() to prevent the driver from selecting an invalid clock configuration on the affected SoCs. Additionally, remove the now redundant RSPI_SPBR_SPR_PCLK_MIN define which was previously set to 1 to work around the PCLK restriction, but was overly broad as it incorrectly blocked valid combinations such as SPR=0/BRDV=1 (31.25Mbps on PCLK=125MHz). Fixes: 8b61c8919dff ("spi: Add driver for the RZ/V2H(P) RSPI IP") Fixes: 1ce3e8adc7d0 ("spi: rzv2h-rspi: add support for using PCLK for transfer clock") Signed-off-by: Lad Prabhakar Link: https://patch.msgid.link/20260410080517.2405700-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d6471ad4977f6e2ac55dc08cc4d96a04b5c894e2 Author: Richard Fitzgerald Date: Thu Apr 9 17:43:26 2026 +0100 ASoC: SDCA: Fix cleanup inversion in class driver [ Upstream commit 7936490e04733ade80d0d445529c0a6de0f95515 ] Fix inverted cleanup of the SoundWire IRQ and the function drivers that use it. The devm cleanup function to call sdca_dev_unregister_functions() was being registered at the end of class_sdw_probe(). The bus core creates the parent SoundWire IRQ handler after class_sdw_probe() has returned, and it registers a devm cleanup handler at the same time. This led to a cleanup inversion where the devm cleanup for the parent Soundwire IRQ runs before the handler that removes the function drivers. So the parent IRQ is destroyed before the function drivers had a chance to do any cleanup and remove their IRQ handlers. Move the registrations of the function driver cleanup into class_boot_work() after the function drivers are registered, so that it runs before the cleanup of the parent SoundWire IRQ handler. Fixes: 2d877d0659cb ("ASoC: SDCA: Add basic SDCA class driver") Signed-off-by: Richard Fitzgerald Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260409164328.3999434-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6688b92475ef4b36b6953b6c70cea30ded1ce93b Author: Yao Zi Date: Sun Apr 5 15:41:54 2026 +0000 PCI: sg2042: Avoid L0s and L1 on Sophgo 2042 PCIe Root Ports [ Upstream commit 988ef706cdd8a72e61dd90c0d0554eec4df7594a ] Since commit f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") force enables ASPM on all device tree platforms, the SG2042 Root Ports are breaking as they advertise L0s and L1 capabilities without supporting them. Set ASPM quirks to disable the L0s and L1 capabilities for the Root Ports so that these broken link states won't be enabled. Fixes: 4e27aca4881a ("riscv: sophgo: dts: add PCIe controllers for SG2042") Co-developed-by: Inochi Amaoto Signed-off-by: Inochi Amaoto Signed-off-by: Yao Zi [mani: commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Han Gao Tested-by: Chen Wang # Pioneerbox Reviewed-by: Chen Wang Link: https://patch.msgid.link/20260405154154.46829-3-me@ziyao.cc Signed-off-by: Sasha Levin commit 6dea278bfea7546c64cb5834a0bee10d2138e346 Author: Yao Zi Date: Sun Apr 5 15:41:53 2026 +0000 PCI: cadence: Add flags for disabling ASPM capability for broken Root Ports [ Upstream commit 5ccc76a87f1ec2422811e61be44165bfc9e7cf54 ] Add flags for disabling the ASPM L0s/L1 capability for broken Root Ports by clearing the corresponding bits in Link Capabilities Register through the local management bus. This allows ASPM to be disabled on platforms which don't support it. Signed-off-by: Yao Zi Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Han Gao Tested-by: Chen Wang # Pioneerbox Reviewed-by: Chen Wang Link: https://patch.msgid.link/20260405154154.46829-2-me@ziyao.cc Stable-dep-of: 988ef706cdd8 ("PCI: sg2042: Avoid L0s and L1 on Sophgo 2042 PCIe Root Ports") Signed-off-by: Sasha Levin commit fd204cf1034fc88fe58727b987c11034990f9a8a Author: Bart Van Assche Date: Fri Apr 3 13:53:54 2026 -0700 drm/fb-helper: Fix a locking bug in an error path [ Upstream commit bd64240dc88caaf7b96dd869f36f165f51b52039 ] The name of the function __drm_fb_helper_initial_config_and_unlock() and also the comment above that function make it clear that all code paths in this function should unlock fb_helper->lock before returning. Add a mutex_unlock() call in the only code path where it is missing. This has been detected by the Clang thread-safety analyzer. Cc: Thomas Zimmermann Cc: Christian König # radeon Cc: Dmitry Baryshkov # msm Cc: Javier Martinez Canillas Fixes: 63c971af4036 ("drm/fb-helper: Allocate and release fb_info in single place") Signed-off-by: Bart Van Assche Signed-off-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260403205355.1181984-1-bvanassche@acm.org Signed-off-by: Sasha Levin commit ce899f9c019591b73ef84b9afa332ed53beece25 Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:55 2026 +0530 PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on [ Upstream commit 34b3eef48d980cd37b876e128bbf314f69fb5d70 ] When PERST# is deasserted twice (assert -> deassert -> assert -> deassert), a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc (PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify() and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers on the controller core. The call chain that causes the timeout: pex_ep_event_pex_rst_deassert() pci_epc_deinit_notify() pci_epf_test_epc_deinit() pci_epf_test_clear_bar() pci_epc_clear_bar() dw_pcie_ep_clear_bar() __dw_pcie_ep_reset_bar() dw_pcie_dbi_ro_wr_en() <- Accesses 0x8bc DBI register reset_control_deassert(pcie->core_rst) <- Core powered on HERE The DBI registers, including PCIE_MISC_CONTROL_1_OFF (0x8bc), are only accessible after the controller core is powered on via reset_control_deassert(pcie->core_rst). Accessing them before this point results in a CBB timeout because the hardware is not yet operational. Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to after reset_control_deassert(pcie->core_rst), ensuring the controller is fully powered on before any DBI register accesses occur. Fixes: 40e2125381dc ("PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()") Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-15-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit db42fdf2036b02649dfa206825b2dde8e4296478 Author: Vidya Sagar Date: Wed Mar 25 00:37:54 2026 +0530 PCI: tegra194: Disable L1.2 capability of Tegra234 EP [ Upstream commit f59df1d9e6bdb6bd7ef65fb5d200900ac40c20ba ] When Tegra234 is operating in the Endpoint mode with L1.2 enabled, PCIe link goes down during L1.2 exit. This is because Tegra234 powers up UPHY PLL immediately without making sure that the REFCLK is stable. This causes UPHY PLL to fail to lock to the correct frequency and leads to link going down. There is no hardware fix for this, hence do not advertise the L1.2 capability in the Endpoint mode. Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-14-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit bdc78c84c99928b0862b2dc78e7c12131ffd1f53 Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:53 2026 +0530 PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well [ Upstream commit 40805f32dceadebb7381d911003100bec7b8cd51 ] The ECRC (TLP digest) workaround was originally added for DesignWare version 4.90a. Tegra234 SoC has 5.00a DWC HW version, which has the same ATU TD override behaviour, so apply the workaround for 5.00a too. Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-13-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit bccc0882355536260eb0c7bb2b027471e758f283 Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:52 2026 +0530 PCI: tegra194: Use DWC IP core version [ Upstream commit ea60ca067f0f098043610c96a915d162113c1aac ] Tegra194 PCIe driver used custom version numbers to detect Tegra194 and Tegra234 IPs. With version detect logic added, version check results in mismatch warnings: tegra194-pcie 14100000.pcie: Versions don't match (0000562a != 3536322a) Use HW version numbers which match to PORT_LOGIC.PCIE_VERSION_OFF in Tegra194 driver to avoid these kernel warnings. Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-12-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 430ce434f131485acdc7605ebfa39fdce03b6aa8 Author: Vidya Sagar Date: Wed Mar 25 00:37:51 2026 +0530 PCI: tegra194: Free up Endpoint resources during remove() [ Upstream commit 8870f02f7868209eb9bdc5dc53540a6262cf9227 ] Free up the resources during remove() that were acquired by the DesignWare driver for the Endpoint mode during probe(). Fixes: bb617cbd8151 ("PCI: tegra194: Clean up the exit path for Endpoint mode") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-11-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 61693e43adcea3c83fe8588294fb29a68a9e00c4 Author: Vidya Sagar Date: Wed Mar 25 00:37:50 2026 +0530 PCI: tegra194: Allow system suspend when the Endpoint link is not up [ Upstream commit c76f8eae7d4695b1176c4ea5eb93c17e16a20272 ] Host software initiates the L2 sequence. PCIe link is kept in L2 state during suspend. If Endpoint mode is enabled and the link is up, the software cannot proceed with suspend. However, when the PCIe Endpoint driver is probed, but the PCIe link is not up, Tegra can go into suspend state. So, allow system to suspend in this case. Fixes: de2bbf2b71bb ("PCI: tegra194: Don't allow suspend when Tegra PCIe is in EP mode") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-10-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit b55ba84aa39de0c8c026d3066cba8eaba2df44e2 Author: Vidya Sagar Date: Wed Mar 25 00:37:49 2026 +0530 PCI: tegra194: Set LTR message request before PCIe link up in Endpoint mode [ Upstream commit b256493bf8cacf0e524bf4c10b5c4901d0c6cefe ] LTR message should be sent as soon as the Root Port enables LTR in the Endpoint mode. So set snoop and no-snoop LTR timing and LTR message request before the PCIe link comes up, so that the LTR message is sent upstream as soon as LTR is enabled. Without programming these values, the Endpoint would send latencies of 0 to the host, which will be inaccurate. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy [mani: commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-9-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 8c82dec2af7b6c8cbc632517c6de977d125e9974 Author: Vidya Sagar Date: Wed Mar 25 00:37:48 2026 +0530 PCI: tegra194: Disable direct speed change for Endpoint mode [ Upstream commit 976f6763f57970388bcd7118931f33f447916927 ] Pre-silicon simulation showed the controller operating in Endpoint mode initiating link speed change after completing Secondary Bus Reset. Ideally, the Root Port or the Switch Downstream Port should initiate the link speed change post SBR, not the Endpoint. So, as per the hardware team recommendation, disable direct speed change for the Endpoint mode to prevent it from initiating speed change after the physical layer link is up at Gen1, leaving speed change ownership with the host. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy [mani: commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-8-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 2e87c690acf9d84cdabdce469d585c40643680f3 Author: Vidya Sagar Date: Wed Mar 25 00:37:47 2026 +0530 PCI: tegra194: Use devm_gpiod_get_optional() to parse "nvidia,refclk-select" [ Upstream commit f62bc7917de1374dce86a852ffba8baf9cb7a56a ] The GPIO DT property "nvidia,refclk-select", to select the PCIe reference clock is optional. Use devm_gpiod_get_optional() to get it. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-7-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 0aaaee05cfd911e7e006b02c469425984025a87f Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:46 2026 +0530 PCI: tegra194: Disable PERST# IRQ only in Endpoint mode [ Upstream commit 40658a31b6e134169c648041efc84944c4c71dcd ] The PERST# GPIO interrupt is only registered when the controller is operating in Endpoint mode. In Root Port mode, the PERST# GPIO is configured as an output to control downstream devices, and no interrupt is registered for it. Currently, tegra_pcie_dw_stop_link() unconditionally calls disable_irq() on pex_rst_irq, which causes issues in Root Port mode where this IRQ is not registered. Fix this by only disabling the PERST# IRQ when operating in Endpoint mode, where the interrupt is actually registered and used to detect PERST# assertion/deassertion from the host. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Reviewed-by: Vidya Sagar Link: https://patch.msgid.link/20260324190755.1094879-6-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit a9f64e1de5efc4f06b863a0d3fbfcc46bb78cdcd Author: Vidya Sagar Date: Wed Mar 25 00:37:45 2026 +0530 PCI: tegra194: Don't force the device into the D0 state before L2 [ Upstream commit 71d9f67701e1affc82d18ca88ae798c5361beddf ] As per PCIe CEM r6.0, sec 2.3, the PCIe Endpoint device should be in D3cold to assert WAKE# pin. The previous workaround that forced downstream devices to D0 before taking the link to L2 cited PCIe r4.0, sec 5.2, "Link State Power Management"; however, that spec does not explicitly require putting the device into D0 and only indicates that power removal may be initiated without transitioning to D3hot. Remove the D0 workaround so that Endpoint devices can use wake functionality (WAKE# from D3). With some Endpoints the link may not enter L2 when they remain in D3, but the Root Port continues with the usual flow after PME timeout, so there is no functional issue. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Vidya Sagar Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-5-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit 144ce5df955f9c6630cb0b992c961cebea383964 Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:44 2026 +0530 PCI: tegra194: Disable LTSSM after transition to Detect on surprise link down [ Upstream commit 9fa0c242f8d7acf1b124d4462d18f4023573ac1c ] After the link reaches a Detect-related LTSSM state, disable LTSSM so it does not keep toggling between Polling and Detect. Do this by polling for the Detect state first, then clearing APPL_CTRL_LTSSM_EN in both tegra_pcie_dw_pme_turnoff() and pex_ep_event_pex_rst_assert(). Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-4-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit ab8ba1f9f133ff08379d15f5f82a74779f313d5e Author: Manikanta Maddireddy Date: Wed Mar 25 00:37:43 2026 +0530 PCI: tegra194: Increase LTSSM poll time on surprise link down [ Upstream commit 74dd8efe4d6cead433162147333af989a568aac7 ] On surprise link down, LTSSM state transits from L0 -> Recovery.RcvrLock -> Recovery.RcvrSpeed -> Gen1 Recovery.RcvrLock -> Detect. Recovery.RcvrLock and Recovery.RcvrSpeed transit times are 24 ms and 48 ms respectively, so the total time from L0 to Detect is ~96 ms. Increase the poll timeout to 120 ms to account for this. While at it, add LTSSM state defines for Detect-related states and use them in the poll condition. Use readl_poll_timeout() instead of readl_poll_timeout_atomic() in tegra_pcie_dw_pme_turnoff() since that path runs in non-atomic context. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-3-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit fab7dc08b2365993dc5bd734899d5c57ea6edbc3 Author: Vidya Sagar Date: Wed Mar 25 00:37:42 2026 +0530 PCI: tegra194: Fix polling delay for L2 state [ Upstream commit adaffed907f14f954096555665ad6af2ae724d83 ] As per PCIe r7.0, sec 5.3.3.2.1, after sending PME_Turn_Off message, Root Port should wait for 1-10 msec for PME_TO_Ack message. Currently, driver is polling for 10 msec with 1 usec delay which is aggressive. Use existing macro PCIE_PME_TO_L2_TIMEOUT_US to poll for 10 msec with 1 msec delay. Since this function is used in non-atomic context only, use non-atomic poll function. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar Signed-off-by: Manikanta Maddireddy Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Jon Hunter Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260324190755.1094879-2-mmaddireddy@nvidia.com Signed-off-by: Sasha Levin commit a2237628c9ce0983f73d99d6cd0e58c5015f5ac8 Author: songxiebing Date: Wed Apr 8 16:33:11 2026 +0800 ALSA: usb-audio: qcom: Fix incorrect type in enable_audio_stream [ Upstream commit 292286b2d229fb732421429b027d38ac3f969383 ] Fix sparse warning: sound/usb/qcom/qc_audio_offload.c:943:27: sparse: incorrect type in argument 2 expected unsigned int val but got snd_pcm_format_t. Explicitly cast pcm_format to unsigned int for snd_mask_leave(). Fixes: 326bbc348298 ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604062109.Oxi8JjWW-lkp@intel.com/ Signed-off-by: songxiebing Link: https://patch.msgid.link/20260408083311.774173-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f61bc2a2ece909adb8b36a47c32691527ced77e5 Author: Syed Saba Kareem Date: Fri Apr 3 15:36:17 2026 +0530 ASoC: amd: ps: fix the pcm device numbering for acp pdm dmic [ Upstream commit 3666dc0c47c399695d01fde7c36e08b14f834fa0 ] Fixed PCM device numbering is required for acp pdm dmic pcm device to have a common UCM changes. Set the 'use_dai_pcm_id' flag true in acp pdm dma driver for acp 6.3 platform. This will fix the pcm device numbering based on dai_link->id. Fixes: 33cea6bbe488 ("ASoC: amd: add acp6.2 pdm platform driver") Signed-off-by: Syed Saba Kareem Fixes: tag. Link: https://patch.msgid.link/20260403100624.676953-1-syed.sabakareem@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b77c891476774fb13d9cf9df790130ca88a9ab57 Author: Kuninori Morimoto Date: Mon Mar 16 02:24:51 2026 +0000 ASoC: amd: name back to pcm_new()/pcm_free() [ Upstream commit fe33a69681e343999e18893f97bb6cd99b883992 ] We have been used pcm_new()/pcm_free(), but switched to pcm_construct()/pcm_destruct() to use extra parameters [1]. pcm_new()/free() had been removed [2], but each drivers are still using such function naming. Let's name back to pcm_new()/pcm_free() again. [1] commit c64bfc906600 ("ASoC: soc-core: add new pcm_construct/pcm_destruct") [2] commit e9067bb50278 ("ASoC: soc-component: remove snd_pcm_ops fromcomponent driver") Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/878qbslddx.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Stable-dep-of: 3666dc0c47c3 ("ASoC: amd: ps: fix the pcm device numbering for acp pdm dmic") Signed-off-by: Sasha Levin commit 8ea012a61a80da3adcc7669127ea7dfade03a5e7 Author: Kuninori Morimoto Date: Mon Mar 16 02:24:43 2026 +0000 ASoC: soc-component: re-add pcm_new()/pcm_free() [ Upstream commit 68130eef1e0d3c1770952e738f7f8d9f340bd42d ] Because old pcm_new()/pcm_free() didn't care about parameter component, to avoid name collisions, we have added pcm_construct()/pcm_destruct() by commit c64bfc9066007 ("ASoC: soc-core: add new pcm_construct/pcm_destruct") Because all driver switch to new pcm_construct()/pcm_destruct(), old pcm_new()/pcm_free() were remoted by commit e9067bb502787 ("ASoC: soc-component: remove snd_pcm_ops from component driver") But naming of pcm_construct()/pcm_destruct() are not goot. re-add pcm_new()/pcm_free(), and switch to use it, again. Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/87a4w8lde4.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Stable-dep-of: 3666dc0c47c3 ("ASoC: amd: ps: fix the pcm device numbering for acp pdm dmic") Signed-off-by: Sasha Levin commit 5c40a84a0a6a25bb3829fe0715f786c38025d48c Author: Cheng-Yang Chou Date: Tue Mar 31 17:18:33 2026 +0800 tools/sched_ext: Fix off-by-one in scx_sdt payload zeroing [ Upstream commit a3c3fb2f86f8a1f266747622037f90eab58186ad ] scx_alloc_free_idx() zeroes the payload of a freed arena allocation one word at a time. The loop bound was alloc->pool.elem_size / 8, but elem_size includes sizeof(struct sdt_data) (the 8-byte union sdt_id header). This caused the loop to write one extra u64 past the allocation, corrupting the tid field of the adjacent pool element. Fix the loop bound to (elem_size - sizeof(struct sdt_data)) / 8 so only the payload portion is zeroed. Test plan: - Add a temporary sanity check in scx_task_free() before the free call: if (mval->data->tid.idx != mval->tid.idx) scx_bpf_error("tid corruption: arena=%d storage=%d", mval->data->tid.idx, (int)mval->tid.idx); - stress-ng --fork 100 -t 10 & sudo ./build/bin/scx_sdt Without this fix, running scx_sdt under fork-heavy load triggers the corruption error. With the fix applied, the same workload completes without error. Fixes: 36929ebd17ae ("tools/sched_ext: add arena based scheduler") Signed-off-by: Cheng-Yang Chou Reviewed-by: Emil Tsalapatis Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b35a244a8d9b96aeece332b45dc728344843f4bf Author: Richard Cheng Date: Thu Apr 2 17:38:50 2026 +0800 PCI/NPEM: Set LED_HW_PLUGGABLE for hotplug-capable ports [ Upstream commit 16d021c878dca22532c984668c9e8cf4722d6a49 ] NPEM registers LED classdevs on PCI endpoint that may be behind hotplug-capable ports. During hot-removal, led_classdev_unregister() calls led_set_brightness(LED_OFF) which leads to a PCI config read to a disconnected device, which fails and returns -ENODEV (topology details in msgid.link below): leds 0003:01:00.0:enclosure:ok: Setting an LED's brightness failed (-19) The LED core already suppresses this for devices with LED_HW_PLUGGABLE set, but NPEM never sets it. Add the flag since NPEM LEDs are on hot-pluggable hardware by nature. Fixes: 4e893545ef87 ("PCI/NPEM: Add Native PCIe Enclosure Management support") Signed-off-by: Richard Cheng Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Acked-by: Kai-Heng Feng Link: https://patch.msgid.link/20260402093850.23075-1-icheng@nvidia.com Signed-off-by: Sasha Levin commit 1f20261d9f374eea5396d94f572ccc5c44c7aea1 Author: Cássio Gabriel Date: Wed Mar 25 17:05:11 2026 -0300 ASoC: SOF: compress: return the configured codec from get_params [ Upstream commit 2c4fdd055f92a2fc8602dcd88bcea08c374b7e8b ] The SOF compressed offload path accepts codec parameters in sof_compr_set_params() and forwards them to firmware as extended data in the SOF IPC stream params message. However, sof_compr_get_params() still returns success without filling the snd_codec structure. Since the compress core allocates that structure zeroed and copies it back to userspace on success, SNDRV_COMPRESS_GET_PARAMS returns an all-zero codec description even after the stream has been configured successfully. The stale TODO in this callback conflates get_params() with capability discovery. Supported codec enumeration belongs in get_caps() and get_codec_caps(). get_params() should report the current codec settings. Cache the codec accepted by sof_compr_set_params() in the per-stream SOF compress state and return it from sof_compr_get_params(). Fixes: 6324cf901e14 ("ASoC: SOF: compr: Add compress ops implementation") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260325-sof-compr-get-params-v1-1-0758815f13c7@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7670678d5c77aeb57848ce4fc4ab07840b8cdc6c Author: Ravi Hothi Date: Thu Mar 26 17:05:31 2026 +0530 ASoC: qcom: audioreach: explicitly enable speaker protection modules [ Upstream commit b481eabe5a193ba8499f446c2ab7e0ac042f8776 ] Speaker protection and VI feedback modules are disabled by default. Explicitly enable them when configuring speaker protection. Fixes: 3e43a8c033c3 ("ASoC: qcom: audioreach: Add support for VI Sense module") Fixes: 0db76f5b2235 ("ASoC: qcom: audioreach: Add support for Speaker Protection module") Signed-off-by: Ravi Hothi Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260326113531.3144998-1-ravi.hothi@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 88152c6791553b6b71223c0d0234988df12e327e Author: Panagiotis Petrakopoulos Date: Mon Apr 6 01:25:48 2026 +0300 ALSA: scarlett2: Add missing sentinel initializer field [ Upstream commit 2428cd6e8b6fa80c36db4652702ca0acd2ce3f08 ] A "-Wmissing-field-initializers" warning was emitted when compiling the module using the W=2 option. There is a sentinel initializer field missing in the end of scarlett2_devices[]. Tested using a Scarlett Solo 4th gen. Fixes: d98cc489029d ("ALSA: scarlett2: Move USB IDs out from device_info struct") Signed-off-by: Panagiotis Petrakopoulos Link: https://patch.msgid.link/20260405222548.8903-1-npetrakopoulos2003@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 61cbbcc62b6e81696b9edfa6e9bd80633064f163 Author: David Carlier Date: Tue Mar 31 11:37:44 2026 +0100 gpu: nova-core: fix missing colon in SEC2 boot debug message [ Upstream commit a7a080bb4236ebe577b6776d940d1717912ff6dd ] The SEC2 mailbox debug output formats MBOX1 without a colon separator, producing "MBOX10xdead" instead of "MBOX1: 0xdead". The GSP debug message a few lines above uses the correct format. Fixes: 5949d419c193 ("gpu: nova-core: gsp: Boot GSP") Signed-off-by: David Carlier Link: https://patch.msgid.link/20260331103744.605683-1-devnexen@gmail.com Signed-off-by: Alexandre Courbot Signed-off-by: Sasha Levin commit 9f81f3d29bd364e225709cc9c0924b154083f7ea Author: Gary Guo Date: Fri Jan 23 17:58:44 2026 +0000 gpu: nova-core: remove redundant `.as_ref()` for `dev_*` print [ Upstream commit 8d1a65c2defdc4213a49008d0531bd35d26fdf35 ] This is now handled by the macro itself. Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260123175854.176735-7-gary@kernel.org Signed-off-by: Danilo Krummrich Stable-dep-of: a7a080bb4236 ("gpu: nova-core: fix missing colon in SEC2 boot debug message") Signed-off-by: Sasha Levin commit 2a5927071c1b26a3e2e90c0ef41ba270c076fcdb Author: Waiman Long Date: Wed Mar 11 16:05:26 2026 -0400 selftest: memcg: skip memcg_sock test if address family not supported [ Upstream commit 2d028f3e4bbbfd448928a8d3d2814b0b04c214f4 ] The test_memcg_sock test in memcontrol.c sets up an IPv6 socket and send data over it to consume memory and verify that memory.stat.sock and memory.current values are close. On systems where IPv6 isn't enabled or not configured to support SOCK_STREAM, the test_memcg_sock test always fails. When the socket() call fails, there is no way we can test the memory consumption and verify the above claim. I believe it is better to just skip the test in this case instead of reporting a test failure hinting that there may be something wrong with the memcg code. Link: https://lkml.kernel.org/r/20260311200526.885899-1-longman@redhat.com Fixes: 5f8f019380b8 ("selftests: cgroup/memcontrol: add basic test for socket accounting") Signed-off-by: Waiman Long Acked-by: Michal Koutný Acked-by: Shakeel Butt Cc: Johannes Weiner Cc: Michal Hocko Cc: Michal Koutný Cc: Mike Rapoport Cc: Muchun Song Cc: Roman Gushchin Cc: Shuah Khan Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8bf2269469a1c50f1ca515b3a2bfa5e6f92552f6 Author: Sergey Senozhatsky Date: Wed Mar 11 17:42:44 2026 +0900 zram: do not permit params change after init [ Upstream commit 241f9005b1c81c2637eef2c836a03c83b4f3eeb9 ] Patch series "zram: recompression cleanups and tweaks", v2. This series is a somewhat random mix of fixups, recompression cleanups and improvements partly based on internal conversations. A few patches in the series remove unexpected or confusing behaviour, e.g. auto correction of bad priority= param for recompression, which should have always been just an error. Then it also removes "chain recompression" which has a tricky, unexpected and confusing behaviour at times. We also unify and harden the handling of algo/priority params. There is also an addition of missing device lock in algorithm_params_store() which previously permitted modification of algo params while the device is active. This patch (of 6): First, algorithm_params_store(), like any sysfs handler, should grab device lock. Second, like any write() sysfs handler, it should grab device lock in exclusive mode. Third, it should not permit change of algos' parameters after device init, as this doesn't make sense - we cannot compress with one C/D dict and then just change C/D dict to a different one, for example. Another thing to notice is that algorithm_params_store() accesses device's ->comp_algs for algo priority lookup, which should be protected by device lock in exclusive mode in general. Link: https://lkml.kernel.org/r/20260311084312.1766036-1-senozhatsky@chromium.org Link: https://lkml.kernel.org/r/20260311084312.1766036-2-senozhatsky@chromium.org Fixes: 4eac932103a5 ("zram: introduce algorithm_params device attribute") Signed-off-by: Sergey Senozhatsky Acked-by: Brian Geffon Cc: gao xu Cc: Jens Axboe Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 077cd05c3c5f940b02fc7b191a9b3efef3f27ef9 Author: SeongJae Park Date: Sat Mar 7 11:53:55 2026 -0800 Docs/mm/damon/index: fix typo: autoamted -> automated [ Upstream commit a4e82de81fe59d5bfcc9450145e8e108561f2e07 ] There is an obvious typo. Fix it (s/autoamted/automated/). Link: https://lkml.kernel.org/r/20260307195356.203753-8-sj@kernel.org Fixes: 32d11b320897 ("Docs/mm/damon/index: simplify the intro") Signed-off-by: SeongJae Park Acked-by: wang lian Cc: Brendan Higgins Cc: David Gow Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Liam Howlett Cc: Lorenzo Stoakes (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit de8206f5f951534a597b85f4eb2ea5536aea1b6b Author: SeongJae Park Date: Sat Mar 7 11:53:53 2026 -0800 Docs/admin-guide/mm/damn/lru_sort: fix intervals autotune parameter name [ Upstream commit d7f00084f6863a243b396200c81e83ae302c5a76 ] The section name should be the same as the parameter name. Fix it. Link: https://lkml.kernel.org/r/20260307195356.203753-6-sj@kernel.org Fixes: ed581147a417 ("Docs/admin-guide/mm/damon/lru_sort: document intervals autotuning") Signed-off-by: SeongJae Park Acked-by: wang lian Cc: Brendan Higgins Cc: David Gow Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Liam Howlett Cc: Lorenzo Stoakes (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0bf26f04abe961e73a4d1f392eb2488238e72dac Author: Jane Chu Date: Mon Mar 2 13:10:15 2026 -0700 Documentation: fix a hugetlbfs reservation statement [ Upstream commit 7a197d346a44384a1a858a98ef03766840e561d4 ] Documentation/mm/hugetlbfs_reserv.rst has if (resv_needed <= (resv_huge_pages - free_huge_pages)) resv_huge_pages += resv_needed; which describes this code in gather_surplus_pages() needed = (h->resv_huge_pages + delta) - h->free_huge_pages; if (needed <= 0) { h->resv_huge_pages += delta; return 0; } which means if there are enough free hugepages to account for the new reservation, simply update the global reservation count without further action. But the description is backwards, it should be if (resv_needed <= (free_huge_pages - resv_huge_pages)) instead. Link: https://lkml.kernel.org/r/20260302201015.1824798-1-jane.chu@oracle.com Fixes: 70bc0dc578b3 ("Documentation: vm, add hugetlbfs reservation overview") Signed-off-by: Jane Chu Cc: David Hildenbrand Cc: Hillf Danton Cc: Jonathan Corbet Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Muchun Song Cc: Oscar Salvador Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5da696682adbe06cd21a7261b9bef460dc92b5b7 Author: AnishMulay Date: Wed Feb 18 11:39:41 2026 -0500 selftests/mm: skip migration tests if NUMA is unavailable [ Upstream commit 54218f10dfbe88c8e41c744fd45a756cde60b8c4 ] Currently, the migration test asserts that numa_available() returns 0. On systems where NUMA is not available (returning -1), such as certain ARM64 configurations or single-node systems, this assertion fails and crashes the test. Update the test to check the return value of numa_available(). If it is less than 0, skip the test gracefully instead of failing. This aligns the behavior with other MM selftests (like rmap) that skip when NUMA support is missing. Link: https://lkml.kernel.org/r/20260218163941.13499-1-anishm7030@gmail.com Fixes: 0c2d08728470 ("mm: add selftests for migration entries") Signed-off-by: AnishMulay Reviewed-by: SeongJae Park Reviewed-by: Dev Jain Reviewed-by: Anshuman Khandual Tested-by: Sayali Patil Acked-by: David Hildenbrand (Arm) Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c55c8ea5c2a3d80d99f2a1361dba571e17b0a74b Author: Eliot Courtney Date: Wed Apr 1 10:42:28 2026 +0900 gpu: nova-core: bitfield: fix broken Default implementation [ Upstream commit de0aca13509bf47a2d49bc7a26d56079c758c95f ] The current implementation does not actually set the default values for the fields in the bitfield. Fixes: 3fa145bef533 ("gpu: nova-core: register: generate correct `Default` implementation") Signed-off-by: Eliot Courtney Link: https://patch.msgid.link/20260401-fix-bitfield-v2-1-2fa68c98114a@nvidia.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 215d4273347b9010a9deae378b0df79c163f707d Author: Chen-Yu Tsai Date: Tue Mar 24 17:35:41 2026 +0800 PCI: mediatek-gen3: Prevent leaking IRQ domains when IRQ not found [ Upstream commit 5573c44cb3fd01a9f62d569ae9ac870ef5f0e0ba ] In mtk_pcie_setup_irq(), the IRQ domains are allocated before the controller's IRQ is fetched. If the latter fails, the function directly returns an error, without cleaning up the allocated domains. Hence, reverse the order so that the IRQ domains are allocated after the controller's IRQ is found. This was flagged by Sashiko during a review of "[PATCH v6 0/7] PCI: mediatek-gen3: add power control support". Fixes: 814cceebba9b ("PCI: mediatek-gen3: Add INTx support") Signed-off-by: Chen-Yu Tsai Signed-off-by: Manivannan Sadhasivam Link: https://sashiko.dev/#/patchset/20260324052002.4072430-1-wenst%40chromium.org Link: https://patch.msgid.link/20260324093542.18523-1-wenst@chromium.org Signed-off-by: Sasha Levin commit 9fbb3d4e0531a6abe656157d0b60ad56c7dfe043 Author: Richard Zhu Date: Tue Mar 24 10:30:32 2026 +0800 dt-bindings: PCI: imx6q-pcie: Fix maxItems of clocks and clock-names [ Upstream commit 401359ef44af43b6b775dc01bb7b31396db67aab ] Commit 1352f58d7c8d ("dt-bindings: PCI: pci-imx6: Add external reference clock input") that added reference clock to the binding was incomplete. The constraints for "clocks" and "clock-names" still enforce an incorrect number of items. Update maxItems for both properties to 6 to match the actual hardware configuration. Fixes: 1352f58d7c8d ("dt-bindings: PCI: pci-imx6: Add external reference clock input") Signed-off-by: Richard Zhu [mani: commit log] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260324023036.784466-2-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin commit cd59b57e0068e0f5a8541b4715646569ed1d4310 Author: Felix Gu Date: Tue Mar 24 01:57:59 2026 +0800 PCI: aspeed: Fix IRQ domain leak on platform_get_irq() failure [ Upstream commit c54d5f5b33990f2649c20f35407f340bcadb8a53 ] The aspeed_pcie_probe() function calls aspeed_pcie_init_irq_domain() which allocates pcie->intx_domain and initializes MSI. However, if platform_get_irq() fails afterwards, the cleanup action was not yet registered via devm_add_action_or_reset(), causing the IRQ domain resources to leak. Fix this by registering the devm cleanup action immediately after aspeed_pcie_init_irq_domain() succeeds, before calling platform_get_irq(). This ensures proper cleanup on any subsequent failure. Fixes: 9aa0cb68fcc1 ("PCI: aspeed: Add ASPEED PCIe RC driver") Signed-off-by: Felix Gu Signed-off-by: Manivannan Sadhasivam Tested-by: Jacky Chou Link: https://patch.msgid.link/20260324-aspeed-v1-1-354181624c00@gmail.com Signed-off-by: Sasha Levin commit 70996053025bf1b75b3c827ce8e3680933fa6e81 Author: Richard Zhu Date: Tue Mar 31 16:52:52 2026 +0800 PCI: imx6: Keep Root Port MSI capability with iMSI-RX to work around hardware bug [ Upstream commit 3a4e8302e72f83fd5cc8a916fc6f5c8fe5c8690e ] On NXP i.MX7D, i.MX8MM, and i.MX8MQ chipsets, MSIs from the endpoints won't be received by the iMSI-RX MSI controller if the Root Port MSI capability is disabled. Even though the Root Port MSIs won't be received by the iMSI-RX controller due to design, these chipsets have some weird hardware bug that prevents the endpoint MSIs from reaching when the Root Port MSI capability is disabled. Hence, introduce a new flag, 'dw_pcie_rp::keep_rp_msi_en', set it for the above mentioned SoCs, and always keep the Root Port MSI capability when this flag is set. Note that by keeping Root Port MSI capability, Root Port MSIs such as AER, PME and others won't be received by default. So users need to use workarounds such as passing 'pcie_pme=nomsi' cmdline param. Fixes: f5cd8a929c825 ("PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI controller") Suggested-by: Manivannan Sadhasivam Signed-off-by: Richard Zhu [mani: commit log] Signed-off-by: Manivannan Sadhasivam [bhelgaas: fix typos] Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260331085252.1243108-1-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin commit 474982149b3aec9c7e6aaec7e0683ec2273ccd92 Author: Gerd Bayer Date: Mon Mar 30 15:09:45 2026 +0200 PCI: Enable AtomicOps only if Root Port supports them [ Upstream commit 1ae8c4ce157037e266184064a182af9ef9af278b ] When inspecting the config space of a Connect-X physical function in an s390 system after it was initialized by the mlx5_core device driver, we found the function to be enabled to request AtomicOps despite the Root Port lacking support for completing them: 00:00.1 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx] Subsystem: Mellanox Technologies Device 0002 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- AtomicOpsCtl: ReqEn+ On s390 and many virtualized guests, the Endpoint is visible but the Root Port is not. In this case, pci_enable_atomic_ops_to_root() previously enabled AtomicOps in the Endpoint even though it can't tell whether the Root Port supports them as a completer. Change pci_enable_atomic_ops_to_root() to fail if there's no Root Port or the Root Port doesn't support AtomicOps. Fixes: 430a23689dea ("PCI: Add pci_enable_atomic_ops_to_root()") Reported-by: Alexander Schmidt Signed-off-by: Gerd Bayer [bhelgaas: commit log, check RP first to simplify flow] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260330-fix_pciatops-v7-2-f601818417e8@linux.ibm.com Signed-off-by: Sasha Levin commit a62b3e6e42359a79158c134e3cf5c74fe160c3f5 Author: Denis Rastyogin Date: Fri Mar 27 13:33:11 2026 +0300 ASoC: rsnd: Fix potential out-of-bounds access of component_dais[] [ Upstream commit f9e437cddf6cf9e603bdaefe148c1f4792aaf39c ] component_dais[RSND_MAX_COMPONENT] is initially zero-initialized and later populated in rsnd_dai_of_node(). However, the existing boundary check: if (i >= RSND_MAX_COMPONENT) does not guarantee that the last valid element remains zero. As a result, the loop can rely on component_dais[RSND_MAX_COMPONENT] being zero, which may lead to an out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 547b02f74e4a ("ASoC: rsnd: enable multi Component support for Audio Graph Card/Card2") Signed-off-by: Denis Rastyogin Acked-by: Kuninori Morimoto Link: https://patch.msgid.link/20260327103311.459239-1-gerben@altlinux.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a05a94a47985d04f5bbc86fab96fc05b767219d7 Author: Cássio Gabriel Date: Fri Apr 3 00:21:34 2026 -0300 ALSA: hda: Notify IEC958 Default PCM switch state changes [ Upstream commit 6692ed9b4ced29aa819c95cc4ad9e2dc8720c081 ] The "IEC958 Default PCM Playback Switch" control is backed directly by mout->share_spdif. The share-switch callbacks currently access that state without serialization, and spdif_share_sw_put() always returns 0, so normal userspace writes never emit the standard ALSA control value notification. snd_hda_multi_out_analog_open() may also clear mout->share_spdif when the analog PCM capabilities and the SPDIF capabilities no longer intersect. That fallback is still needed to avoid creating an impossible hw constraint set, but it changes the mixer backing value without notifying subscribers. Protect the share-switch callbacks with spdif_mutex like the other SPDIF control handlers, return the actual change value from spdif_share_sw_put(), and notify the cached control when the open path forcibly disables shared SPDIF mode after dropping spdif_mutex. This keeps the existing auto-disable behavior while making switch state changes visible to userspace. Fixes: 9a08160bdbe3 ("[ALSA] hda-codec - Add "IEC958 Default PCM" switch") Fixes: 022b466fc353 ("ALSA: hda - Avoid invalid formats and rates with shared SPDIF") Suggested-by: Takashi Iwai Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260403-hda-spdif-share-notify-v3-1-4eb1356b0f17@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a3aefa5049da733b6ba4dc44353540b94763d9ff Author: Giovanni Cabiddu Date: Sat Mar 28 22:29:46 2026 +0000 crypto: qat - use swab32 macro [ Upstream commit 35ecb77ae0749a2f1b04872c9978d9d7ddbbeb79 ] Replace __builtin_bswap32() with swab32 in icp_qat_hw_20_comp.h to fix the following build errors on architectures without native byte-swap support: alpha-linux-ld: drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.o: in function `adf_gen4_build_decomp_block': drivers/crypto/intel/qat/qat_common/icp_qat_hw_20_comp.h:141:(.text+0xeec): undefined reference to `__bswapsi2' alpha-linux-ld: drivers/crypto/intel/qat/qat_common/icp_qat_hw_20_comp.h:141:(.text+0xef8): undefined reference to `__bswapsi2' alpha-linux-ld: drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.o: in function `adf_gen4_build_comp_block': drivers/crypto/intel/qat/qat_common/icp_qat_hw_20_comp.h:57:(.text+0xf64): undefined reference to `__bswapsi2' alpha-linux-ld: drivers/crypto/intel/qat/qat_common/icp_qat_hw_20_comp.h:57:(.text+0xf7c): undefined reference to `__bswapsi2' Fixes: 5b14b2b307e4 ("crypto: qat - enable deflate for QAT GEN4") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202603290259.Ig9kDOmI-lkp@intel.com/ Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 60b1ca1851eb4ff74669a348e133e0a50d544320 Author: Giovanni Cabiddu Date: Tue Mar 24 18:29:05 2026 +0000 crypto: iaa - fix per-node CPU counter reset in rebalance_wq_table() [ Upstream commit 590fa5d69c27cfaecd2e8287aec78f902417c877 ] The cpu counter used to compute the IAA device index is reset to zero at the start of each NUMA node iteration. This causes CPUs on every node to map starting from IAA index 0 instead of continuing from the previous node's last index. On multi-node systems, this results in all nodes mapping their CPUs to the same initial set of IAA devices, leaving higher-indexed devices unused. Move the cpu counter initialization before the for_each_node_with_cpus() loop so that the IAA index computation accumulates correctly across all nodes. Fixes: 714ca27e9bf4 ("crypto: iaa - Optimize rebalance_wq_table()") Signed-off-by: Giovanni Cabiddu Acked-by: Vinicius Costa Gomes Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f47c9fd1e271708e3fea3392c79cc26c1c3709bc Author: Giovanni Cabiddu Date: Tue Mar 24 18:17:23 2026 +0000 crypto: qat - fix type mismatch in RAS sysfs show functions [ Upstream commit ec23d75c4b77ae42af0777ea59599b1d4f611371 ] ADF_RAS_ERR_CTR_READ() expands to atomic_read(), which returns int. The local variable 'counter' was declared as 'unsigned long', causing a type mismatch on the assignment. The format specifier '%ld' was consequently wrong in two ways: wrong length modifier and wrong signedness. Use int to match the return type of atomic_read() and update the format specifier to '%d' accordingly. Fixes: 532d7f6bc458 ("crypto: qat - add error counters") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Reviewed-by: Andy Shevchenko Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 00143b177cca744722aa1021cbeaf9786dfd9dca Author: Giovanni Cabiddu Date: Tue Mar 24 17:59:40 2026 +0000 crypto: qat - fix compression instance leak [ Upstream commit 795c24c677c7a1c12f5768daf22a874a2890662f ] qat_comp_alg_init_tfm() acquires a compression instance via qat_compression_get_instance_node() before calling qat_comp_build_ctx() to initialize the compression context. If qat_comp_build_ctx() fails, the function returns an error without releasing the compression instance, causing a resource leak. When qat_comp_build_ctx() fails, release the compression instance with qat_compression_put_instance() and clear the context to avoid leaving a stale reference to the released instance. The issue was introduced when build_deflate_ctx() (which always returned void) was replaced by qat_comp_build_ctx() (which can return an error) without adding error handling for the failure path. Fixes: cd0e7160f80f ("crypto: qat - refactor compression template logic") Signed-off-by: Giovanni Cabiddu Reviewed-by: Laurent M Coquerel Reviewed-by: Ahsan Atta Reviewed-by: Wojciech Drewek Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bc8b67c3eca7be344b5662868b906a6b391bc8ba Author: Ahsan Atta Date: Tue Mar 24 11:12:34 2026 +0000 crypto: qat - disable 420xx AE cluster when lead engine is fused off [ Upstream commit f216e0f2d1787e662bb6662c9c522185aa3b855a ] The get_ae_mask() function only disables individual engines based on the fuse register, but engines are organized in clusters of 4. If the lead engine of a cluster is fused off, the entire cluster must be disabled. Replace the single bitmask inversion with explicit test_bit() checks on the lead engine of each group, disabling the full ADF_AE_GROUP when the lead bit is set. Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Fixes: fcf60f4bcf54 ("crypto: qat - add support for 420xx devices") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a3d826dd0ac29080f64219e92b17470656121328 Author: Ahsan Atta Date: Tue Mar 24 11:11:12 2026 +0000 crypto: qat - disable 4xxx AE cluster when lead engine is fused off [ Upstream commit b260d53561dd69b29505222ec44cf386ac2c2ca6 ] The get_ae_mask() function only disables individual engines based on the fuse register, but engines are organized in clusters of 4. If the lead engine of a cluster is fused off, the entire cluster must be disabled. Replace the single bitmask inversion with explicit test_bit() checks on the lead engine of each group, disabling the full ADF_AE_GROUP when the lead bit is set. Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Fixes: 8c8268166e834 ("crypto: qat - add qat_4xxx driver") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 859e3fe75d78c131a8b7450ff7fba2595c6ef116 Author: Hans Zhang <18255117159@163.com> Date: Wed Apr 1 10:30:48 2026 +0800 PCI: dwc: Fix type mismatch for kstrtou32_from_user() return value [ Upstream commit 445588a3b18bb0702d746cb61f7a443639027651 ] kstrtou32_from_user() returns int, but the return value was stored in a u32 variable 'val', risking sign loss. Use a dedicated int variable to correctly handle the return code. Fixes: 4fbfa17f9a07 ("PCI: dwc: Add debugfs based Silicon Debug support for DWC") Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260401023048.4182452-1-18255117159@163.com Signed-off-by: Sasha Levin commit 6d2491a585202a967ed91f30ec5960024f2536d0 Author: Srinivas Kandagatla Date: Thu Apr 2 08:11:08 2026 +0000 ASoC: qcom: qdsp6: topology: check widget type before accessing data [ Upstream commit d5bfdd28e0cdd45043ae6e0ac168a451d59283dc ] Check widget type before accessing the private data, as this could a virtual widget which is no associated with a dsp graph, container and module. Accessing witout check could lead to incorrect memory access. Fixes: 36ad9bf1d93d ("ASoC: qdsp6: audioreach: add topology support") Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260402081118.348071-4-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e4b7687784153481de45fd39fb97ba3919605c0c Author: Jason Gunthorpe Date: Fri Mar 27 12:22:10 2026 -0300 iommu/riscv: Remove overflows on the invalidation path [ Upstream commit 40a13b49957937427bc23e78eb50679df4396a47 ] Since RISC-V supports a sign extended page table it should support a gather->end of ULONG_MAX, but if this happens it will infinite loop because of the overflow. Also avoid overflow computing the length by moving the +1 to the other side of the < Fixes: 488ffbf18171 ("iommu/riscv: Paging domain support") Signed-off-by: Jason Gunthorpe Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit dae251ff11d2d2208a029f98923756831cefec46 Author: Vasant Hegde Date: Wed Apr 1 08:00:17 2026 +0000 iommu/amd: Fix clone_alias() to use the original device's devid [ Upstream commit faad224fe0f0857a04ff2eb3c90f0de57f47d0f3 ] Currently clone_alias() assumes first argument (pdev) is always the original device pointer. This function is called by pci_for_each_dma_alias() which based on topology decides to send original or alias device details in first argument. This meant that the source devid used to look up and copy the DTE may be incorrect, leading to wrong or stale DTE entries being propagated to alias device. Fix this by passing the original pdev as the opaque data argument to both the direct clone_alias() call and pci_for_each_dma_alias(). Inside clone_alias(), retrieve the original device from data and compute devid from it. Fixes: 3332364e4ebc ("iommu/amd: Support multiple PCI DMA aliases in device table") Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 407a6958ee16bb73a74ccb6e87224143b1620ce6 Author: Shengjiu Wang Date: Wed Apr 1 17:42:26 2026 +0800 ASoC: fsl_easrc: Change the type for iec958 channel status controls [ Upstream commit 47f28a5bd154a95d5aa563dde02a801bd32ddb81 ] Use the type SNDRV_CTL_ELEM_TYPE_IEC958 for iec958 channel status controls, the original type will cause mixer-test to iterate all 32bit values, which costs a lot of time. And using IEC958 type can reduce the control numbers. Also enable pm runtime before updating registers to make the regmap cache data align with the value in hardware. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-12-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c20fbd0d178f35d8d2e510dbcf1205613026f91a Author: Shengjiu Wang Date: Wed Apr 1 17:42:25 2026 +0800 ASoC: fsl_easrc: Fix value type in fsl_easrc_iec958_get_bits() [ Upstream commit aa21fe4a81458cf469c2615b08cbde5997dde25a ] The value type of controls "Context 0 IEC958 Bits Per Sample" should be integer, not enumerated, the issue is found by the mixer-test. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-11-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 32abd012a5b0121ed4c6372e1c749e697fa148c8 Author: Shengjiu Wang Date: Wed Apr 1 17:42:24 2026 +0800 ASoC: fsl_easrc: Check the variable range in fsl_easrc_iec958_put_bits() [ Upstream commit 00541b86fb578d4949cfdd6aff1f82d43fcf07af ] Add check of input value's range in fsl_easrc_iec958_put_bits(), otherwise the wrong value may be written from user space. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-10-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8dd0ea941a6a183f85d3b8fbb5d4c5f239bbb65c Author: Shengjiu Wang Date: Wed Apr 1 17:42:23 2026 +0800 ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_mode_put() [ Upstream commit 64a496ba976324615b845d60739dfcdae3d57434 ] ALSA controls should return 1 if the value in the control changed but the control put operation fsl_xcvr_mode_put() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the mode variable. Fixes: 28564486866f ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-9-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5026dc44d4658462cbe96cabe1c8dada3e1b20a9 Author: Shengjiu Wang Date: Wed Apr 1 17:42:22 2026 +0800 ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_arc_mode_put() [ Upstream commit 1b61c8103c9317a9c37fe544c2d83cee1c281149 ] ALSA controls should return 1 if the value in the control changed but the control put operation fsl_xcvr_arc_mode_put() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the arc_mode variable. Fixes: 28564486866f ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-8-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ba04af0120fc6b5381e7c35d8f44836684d050ea Author: Shengjiu Wang Date: Wed Apr 1 17:42:21 2026 +0800 ASoC: fsl_micfil: Fix event generation in micfil_quality_set() [ Upstream commit e5785093b1b45af7ee57d18619b2854a8aed073a ] ALSA controls should return 1 if the value in the control changed but the control put operation micfil_quality_set() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the quality variable. Also enable pm runtime before calling the function micfil_set_quality() to make the regmap cache data align with the value in hardware. Fixes: bea1d61d5892 ("ASoC: fsl_micfil: rework quality setting") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-7-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 19453f9ba08075fde4b83f047e627d9edadbdc13 Author: Shengjiu Wang Date: Wed Apr 1 17:42:20 2026 +0800 ASoC: fsl_micfil: Fix event generation in micfil_put_dc_remover_state() [ Upstream commit 7d2bd35100de370dc326b250e8f6b66bee06a2f3 ] ALSA controls should return 1 if the value in the control changed but the control put operation micfil_put_dc_remover_state() only returns 0 or a negative error code, causing ALSA to not generate any change events. return the value of snd_soc_component_update_bits() directly, as it has the capability of return check status of changed or not. Also enable pm runtime before calling the function snd_soc_component_update_bits() to make the regmap cache data align with the value in hardware. Fixes: 29dbfeecab85 ("ASoC: fsl_micfil: Add Hardware Voice Activity Detector support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-6-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 37b574e841b5eb4b0f8036d60d3cd9ee86028e7a Author: Shengjiu Wang Date: Wed Apr 1 17:42:19 2026 +0800 ASoC: fsl_micfil: Fix event generation in micfil_range_set() [ Upstream commit fc4daaddb276d370b7da3819872044df446a1911 ] ALSA controls should return 1 if the value in the control changed but the control put operation micfil_range_set() only returns 0 or a negative error code, causing ALSA to not generate any change events. Use snd_soc_component_update_bits() function to replace the regmap_update_bits(), for snd_soc_component_update_bits() has the capability of return check status. Also enable pm runtime before calling the function snd_soc_component_update_bits() to make the regmap cache data align with the value in hardware. Fixes: ef1a7e02fdb7 ("ASoC: fsl_micfil: Set channel range control") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-5-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bc2edb82eb30bf597c6ee9223d59720d62c21cc1 Author: Shengjiu Wang Date: Wed Apr 1 17:42:18 2026 +0800 ASoC: fsl_micfil: Fix event generation in hwvad_put_init_mode() [ Upstream commit 7e226209906906421f0d952d7304e48fdb0adabc ] ALSA controls should return 1 if the value in the control changed but the control put operation hwvad_put_init_mode() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the vad_init_mode variable. Fixes: 29dbfeecab85 ("ASoC: fsl_micfil: Add Hardware Voice Activity Detector support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-4-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 50ad35b650251f096a0faf2e6a9f31b462c4bc10 Author: Shengjiu Wang Date: Wed Apr 1 17:42:17 2026 +0800 ASoC: fsl_micfil: Fix event generation in hwvad_put_enable() [ Upstream commit 59b9061824f2179fe133e2636203548eaba3e528 ] ALSA controls should return 1 if the value in the control changed but the control put operation hwvad_put_enable() only returns 0 or a negative error code, causing ALSA to not generate any change events. Add a suitable check in the function before updating the vad_enabled variable. Fixes: 29dbfeecab85 ("ASoC: fsl_micfil: Add Hardware Voice Activity Detector support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ae61c088ae9c0cf52aa2d879adf95d6c41922056 Author: Shengjiu Wang Date: Wed Apr 1 17:42:16 2026 +0800 ASoC: fsl_micfil: Add access property for "VAD Detected" [ Upstream commit c7661bfc7422443df394c01e069ae4e5c3a7f04c ] Add access property SNDRV_CTL_ELEM_ACCESS_READ for control "VAD Detected", which doesn't support put operation, otherwise there will be issue with mixer-test. Fixes: 29dbfeecab85 ("ASoC: fsl_micfil: Add Hardware Voice Activity Detector support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260401094226.2900532-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 04fa684978271d2881b36092c5dedefc87aa6d14 Author: Dmitry Baryshkov Date: Wed Mar 25 07:35:44 2026 +0200 drm/msm/dpu: drop INTF_0 on MSM8953 [ Upstream commit 7090420420d5a7d7c88b21d16962f2a230be3ef3 ] There is no INTF_0 on MSM8953. Currently catalog lists dummy INTF_NONE entry for it. Drop it from the catalog. Fixes: 7a6109ce1c2c ("drm/msm/dpu: Add support for MSM8953") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/713990/ Link: https://lore.kernel.org/r/20260325-drop-8953-intf-v1-1-d80e214a1a75@oss.qualcomm.com Signed-off-by: Sasha Levin commit 20fa04887e670fa1382a2523ef96cdaf06210235 Author: Dmitry Baryshkov Date: Sun Feb 1 12:48:59 2026 +0200 PM: domains: De-constify fields in struct dev_pm_domain_attach_data [ Upstream commit 1877d3f258cbb57d64e275754fb9b18b089ce72d ] It doesn't really make sense to keep u32 fields to be marked as const. Having the const fields prevents their modification in the driver. Instead the whole struct can be defined as const, if it is constant. Fixes: 161e16a5e50a ("PM: domains: Add helper functions to attach/detach multiple PM domains") Signed-off-by: Dmitry Baryshkov Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 612f9b89740c16122bf16eec0eb1aff67b199d73 Author: Felix Gu Date: Wed Jan 21 22:17:17 2026 +0800 pmdomain: imx: scu-pd: Fix device_node reference leak during ->probe() [ Upstream commit c8e9b6a55702be6c6d034e973d519c52c3848415 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In imx_sc_pd_get_console_rsrc(), it does not release the reference. Fixes: 893cfb99734f ("firmware: imx: scu-pd: do not power off console domain") Signed-off-by: Felix Gu Reviewed-by: Peng Fan Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit bf436c592c2ca1a74ad4b66bce4c06a7979f0c74 Author: Felix Gu Date: Fri Jan 16 20:27:47 2026 +0800 pmdomain: ti: omap_prm: Fix a reference leak on device node [ Upstream commit 44c28e1c52764fef6dd1c1ada3a248728812e67f ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In omap_prm_domain_attach_dev, it does not release the reference. Fixes: 58cbff023bfa ("soc: ti: omap-prm: Add basic power domain support") Signed-off-by: Felix Gu Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 95a85d7959cbe709fbfcd1aa190ccbe97804e4a3 Author: wangdicheng Date: Wed Apr 1 16:26:25 2026 +0800 ALSA: hda/cmedia: Remove duplicate pin configuration parsing [ Upstream commit 579e7b820de5dd5124585413bb5e9c278d255436 ] The cmedia_probe() function calls snd_hda_parse_pin_defcfg() and snd_hda_gen_parse_auto_config() twice unnecessarily. Remove The duplicate code. Fixes: 0f1e8306dcbe ("ALSA: hda/cmedia: Rewrite to new probe method") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260401082625.157868-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 766dd20f2f3b219da3201fe1a56d295a6bd76f94 Author: Akhil P Oommen Date: Fri Mar 27 05:43:55 2026 +0530 drm/msm/a6xx: Fix gpu init from secure world [ Upstream commit bb9b1d6e945ea90459bda1aac7e2aa7179119887 ] A7XX_GEN2 and newer GPUs requires initialization of few configurations related to features/power from secure world. The SCM call to do this should be triggered after GDSC and clocks are enabled. So, keep this sequence to a6xx_gmu_resume instead of the probe. Also, simplify the error handling in a6xx_gmu_resume() using 'goto' labels. Fixes: 14b27d5df3ea ("drm/msm/a7xx: Initialize a750 "software fuse"") Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/714664/ Message-ID: <20260327-a8xx-gpu-batch2-v2-6-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit c6d29701356d2cd6fb13de29c00826f7b9abec0b Author: Akhil P Oommen Date: Fri Mar 27 05:43:54 2026 +0530 drm/msm/adreno: Implement gx_is_on() for A8x [ Upstream commit ae25e6e9cdcac4cfef102b9d6de8bff13ca4d13b ] A8x has a diverged enough for a separate implementation of gx_is_on() check. Add that and move them to the adreno func table. Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Reviewed-by: Konrad Dybcio Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/714661/ Message-ID: <20260327-a8xx-gpu-batch2-v2-5-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit c1bb9f194e87fcf7f4160c55ef768650e0a93ce6 Author: Akhil P Oommen Date: Fri Mar 27 05:43:53 2026 +0530 drm/msm/a6xx: Correct OOB usage [ Upstream commit d34b6919798c1a8c93e1d7cca297d0e068146bd5 ] During the GMU resume sequence, using another OOB other than OOB_GPU may confuse the internal state of GMU firmware. To align more strictly with the downstream sequence, move the sysprof related OOB setup after the OOB_GPU is cleared. Fixes: 62cd0fa6990b ("drm/msm/adreno: Disable IFPC when sysprof is active") Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/714659/ Message-ID: <20260327-a8xx-gpu-batch2-v2-4-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 98b99f84a4fc829acae9b892c87929c417cae2e3 Author: Akhil P Oommen Date: Fri Mar 27 05:43:52 2026 +0530 drm/msm/a6xx: Switch to preemption safe AO counter [ Upstream commit 0c59f258ffd4c9c2a6bd37d71a0ade1db8bc03b7 ] CP_ALWAYS_ON_COUNTER is not save-restored during preemption, so it won't provide accurate data about the 'submit' when preemption is enabled. Switch to CP_ALWAYS_ON_CONTEXT which is preemption safe. Fixes: e7ae83da4a28 ("drm/msm/a6xx: Implement preemption for a7xx targets") Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/714657/ Message-ID: <20260327-a8xx-gpu-batch2-v2-3-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit e682f3bcacb5c8f7ea10b470a4b72fdd0bc5e73e Author: Akhil P Oommen Date: Fri Mar 27 05:43:51 2026 +0530 drm/msm/a8xx: Fix the ticks used in submit traces [ Upstream commit cfc8b48649e159ff394fb4b7b08e5006c5c1c234 ] GMU_ALWAYS_ON_COUNTER_* registers got moved in A8x, but currently, A6x register offsets are used in the submit traces instead of A8x offsets. To fix this, refactor a bit and use adreno_gpu->funcs->get_timestamp() everywhere. While we are at it, update a8xx_gmu_get_timestamp() to use the GMU AO counter. Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/714655/ Message-ID: <20260327-a8xx-gpu-batch2-v2-2-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit f4cfdda36ddd2a1e07eccd8ac66abdcd4b74bc6a Author: Akhil P Oommen Date: Fri Mar 27 05:43:50 2026 +0530 drm/msm/a6xx: Use barriers while updating HFI Q headers [ Upstream commit dc78b35d5ec09d1b0b8a937e6e640d2c5a030915 ] To avoid harmful compiler optimizations and IO reordering in the HW, use barriers and READ/WRITE_ONCE helpers as necessary while accessing the HFI queue index variables. Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/714653/ Message-ID: <20260327-a8xx-gpu-batch2-v2-1-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 6ce39e2d9eeb0a4b6a6d0c6620a62e9efc2bdd15 Author: Connor Abbott Date: Wed Mar 25 16:58:37 2026 -0400 drm/msm/a6xx: Fix dumping A650+ debugbus blocks [ Upstream commit cc83f71c9be0715fe93b963ffa9767d5d84354ed ] These should be appended after the existing debugbus blocks, instead of replacing them. Fixes: 1e05bba5e2b8 ("drm/msm/a6xx: Update a6xx gpu coredump") Signed-off-by: Connor Abbott Patchwork: https://patchwork.freedesktop.org/patch/714270/ Message-ID: <20260325-drm-msm-a650-debugbus-v1-1-dfbf358890a7@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 2c41ac73f3934cf66343c9150e01b8a1cf57d7e6 Author: Rob Clark Date: Wed Mar 25 11:41:05 2026 -0700 drm/msm/shrinker: Fix can_block() logic [ Upstream commit df0f439e3926817cf577ca6272aad68468ff7624 ] The intention here was to allow blocking if DIRECT_RECLAIM or if called from kswapd and KSWAPD_RECLAIM is set. Reported by Claude code review: https://lore.gitlab.freedesktop.org/drm-ai-reviews/review-patch9-20260309151119.290217-10-boris.brezillon@collabora.com/ on a panthor patch which had copied similar logic. Reported-by: Boris Brezillon Fixes: 7860d720a84c ("drm/msm: Fix build break with recent mm tree") Signed-off-by: Rob Clark Reviewed-by: Boris Brezillon Patchwork: https://patchwork.freedesktop.org/patch/714238/ Message-ID: <20260325184106.1259528-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 109449479b9d2de6798ca92d1868a77ac7fc7395 Author: Rob Clark Date: Wed Mar 25 11:40:42 2026 -0700 drm/msm/a6xx: Fix HLSQ register dumping [ Upstream commit c289a6db9ba6cb974f0317da142e4f665d589566 ] Fix the bitfield offset of HLSQ_READ_SEL state-type bitfield. Otherwise we are always reading TP state when we wanted SP or HLSQ state. Reported-by: Connor Abbott Suggested-by: Connor Abbott Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/714236/ Message-ID: <20260325184043.1259312-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit d9ecf758270501b2e7a0bc1dd69a6f28f1ae3cae Author: Rob Clark Date: Tue Mar 24 15:05:18 2026 -0700 drm/msm: Fix VM_BIND UNMAP locking [ Upstream commit 85042c2cd970a6b0e686329387096fe19989ae62 ] Wrong argument meant that the objs involved in UNMAP ops were not always getting locked. Since _NO_SHARE objs share a common resv with the VM (which is always locked) this would only show up with non-_NO_SHARE BOs. Reported-by: Victoria Brekenfeld Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/94 Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/713898/ Message-ID: <20260324220519.1221471-2-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 1d2bb93902a5b7bf0e3472c57b1f0bd4f95e1e47 Author: Rob Clark Date: Wed Mar 25 11:59:26 2026 -0700 drm/msm: Reject fb creation from _NO_SHARE objs [ Upstream commit cf50ccdb765b3a6f1cd8e75642b0439fea0263a5 ] It would be an error to map these into kms->vm. So reject this as early as possible, when creating an fb. Fixes: b58e12a66e47 ("drm/msm: Add _NO_SHARE flag") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/714264/ Message-ID: <20260325185926.1265661-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 79a357b278d6ce64dea1d8deddf67f574be36214 Author: Rob Clark Date: Mon Mar 23 09:16:02 2026 -0700 drm/msm/a6xx: Add missing aperture_lock init [ Upstream commit d4ef6d77bb1ef92bdbfb70c7a5d08072848357d8 ] Looks like this was somehow missed when introducing gen8 support. Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Signed-off-by: Rob Clark Reviewed-by: Dmitry Baryshkov Reviewed-by: Akhil P Oommen Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/713545/ Message-ID: <20260323161603.1165108-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 5ddb2c810aec4ed9c95ac56589de2d7604c30615 Author: Rob Clark Date: Mon Mar 16 11:44:42 2026 -0700 drm/msm/vma: Avoid lock in VM_BIND fence signaling path [ Upstream commit 8a7023b035355ef5bfa096bd323256fa8abbbc6a ] Use msm_gem_unpin_active(), similar to what is used in the GEM_SUBMIT path. This avoids needing to hold the obj lock, and the end result is the same. (As with GEM_SUBMIT, we know the fence isn't signaled yet.) Reported-by: Akhil P Oommen Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/712230/ Message-ID: <20260316184442.673558-1-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit e1411fa065212d7db4c1a251ea85a0a44aff3291 Author: Ethan Tidmore Date: Tue Mar 24 12:38:30 2026 -0500 ASoC: SOF: Intel: hda: Place check before dereference [ Upstream commit 6cbc8360f51a3df2ea16a786b262b9fe44d4c68c ] The struct hext_stream is dereferenced before it is checked for NULL. Although it can never be NULL due to a check prior to hda_dsp_iccmax_stream_hw_params() being called, this change clears any confusion regarding hext_stream possibly being NULL. Check hext_stream for NULL and then assign its members. Detected by Smatch: sound/soc/sof/intel/hda-stream.c:488 hda_dsp_iccmax_stream_hw_params() warn: variable dereferenced before check 'hext_stream' (see line 486) Fixes: aca961f196e5d ("ASoC: SOF: Intel: hda: Add helper function to program ICCMAX stream") Signed-off-by: Ethan Tidmore Link: https://patch.msgid.link/20260324173830.17563-1-ethantidmore06@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c197159a71828a6cc96a2c29c5cc175db18c80f8 Author: Lei Huang Date: Tue Mar 31 15:54:05 2026 +0800 ALSA: hda/realtek: fix code style (ERROR: else should follow close brace '}') [ Upstream commit d1888bf848ade6a9e71c7ba516fd215aa1bd8d65 ] Fix checkpatch code style errors: ERROR: else should follow close brace '}' #2300: FILE: sound/hda/codecs/realtek/alc269.c:2300: + } + else Fixes: 31278997add6 ("ALSA: hda/realtek - Add headset quirk for Dell DT") Signed-off-by: Lei Huang Link: https://patch.msgid.link/20260331075405.78148-1-huanglei814@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ec84792d87d2486fc9529901387a73e41c078243 Author: Lei Huang Date: Tue Mar 31 10:40:36 2026 +0800 ALSA: hda/realtek: fix bad indentation for alc269 [ Upstream commit c1258a2924d3a2453a6e7a6581acd8d6e5c6ba70 ] Mention complains about this coding style: ERROR: code indent should use tabs where possible #6640: FILE: sound/hda/codecs/realtek/alc269.c:6640: + [ALC233_FIXUP_LENOVO_GPIO2_MIC_HOTKEY] = {$ fix it up. Fixes: 5de5db35350d ("ALSA: hda/realtek - Enable Mute LED for Lenovo platform") Signed-off-by: Lei Huang Link: https://patch.msgid.link/20260331024036.30782-1-huanglei814@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8088437546788cd3635c7492ab6ab72e8ae4c809 Author: Billy Tsai Date: Mon Mar 9 10:33:24 2026 +0800 hwmon: (aspeed-g6-pwm-tach): remove redundant driver remove callback [ Upstream commit 46fef8583daa1bf78fda7eaa523c64d4440322ac ] Drops the remove callback as it only asserts reset and the probe already registers a devres action (devm_add_action_or_reset()) to call aspeed_pwm_tach_reset_assert(). Fixes: 7e1449cd15d1 ("hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach") Signed-off-by: Billy Tsai Link: https://lore.kernel.org/r/20260309-pwm_fixes-v2-1-ca9768e70470@aspeedtech.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f3c37809ee3ba69a7f8556da0c4a107399402095 Author: Kuppuswamy Sathyanarayanan Date: Wed Mar 18 10:04:49 2026 -0700 PCI/DPC: Log AER error info for DPC/EDR uncorrectable errors [ Upstream commit 97970e7c694356e3386a10e3b936d61eafd06bce ] aer_print_error() skips printing if ratelimit_print[i] is not set. In the native AER path, ratelimit_print is initialized by add_error_device() during source device discovery, and is set to 1 for fatal errors to bypass rate limiting since fatal errors should always be logged. The DPC/EDR path uses the DPC-capable port as the error source and reads its AER uncorrectable error status registers directly in dpc_get_aer_uncorrect_severity(). Since it does not go through add_error_device(), ratelimit_print[0] is left uninitialized and zero. As a result, aer_print_error() silently drops all AER error messages for DPC/EDR triggered events. Set ratelimit_print[0] to 1 to bypass rate limiting and always print AER logs for uncorrectable errors detected by the DPC port. Fixes: a57f2bfb4a58 ("PCI/AER: Ratelimit correctable and non-fatal error logging") Co-developed-by: Goudar Manjunath Ramanagouda Signed-off-by: Goudar Manjunath Ramanagouda Signed-off-by: Kuppuswamy Sathyanarayanan [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260318170449.2733581-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Sasha Levin commit 1b522abb0537ba2ebc7ae319e54d2dfc3975fdd2 Author: Timur Kristóf Date: Sun Mar 29 18:03:06 2026 +0200 drm/amdgpu/uvd4.2: Don't initialize UVD 4.2 when DPM is disabled [ Upstream commit 8b3e8fa6d7bdab292447a43f70532db437d5d4f5 ] UVD 4.2 doesn't work at all when DPM is disabled because the SMU is responsible for ungating it. So, Linux fails to boot with CIK GPUs when using the amdgpu.dpm=0 parameter. Fix this by returning -ENOENT from uvd_v4_2_early_init() when amdgpu_dpm isn't enabled. Note: amdgpu.dpm=0 is often suggested as a workaround for issues and is useful for debugging. Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 297c4d5eebdcf399391b48de8b3937047065d3c3 Author: Timur Kristóf Date: Sun Mar 29 18:03:05 2026 +0200 drm/amd/pm/smu7: Add SCLK cap for quirky Hawaii board [ Upstream commit 4724bc5b8d78c34b993594f9406135408ccb312a ] On a specific Radeon R9 390X board, the GPU can "randomly" hang while gaming. Initially I thought this was a RADV bug and tried to work around this in Mesa: commit 8ea08747b86b ("radv: Mitigate GPU hang on Hawaii in Dota 2 and RotTR") However, I got some feedback from other users who are reporting that the above mitigation causes a significant performance regression for them, and they didn't experience the hang on their GPU in the first place. After some further investigation, it turns out that the problem is that the highest SCLK DPM level on this board isn't stable. Lowering SCLK to 1040 MHz (from 1070 MHz) works around the issue, and has a negligible impact on performance compared to the Mesa patch. (Note that increasing the voltage can also work around it, but we felt that lowering the SCLK is the safer option.) To solve the above issue, add an "sclk_cap" field to smu7_hwmgr and set this field for the affected board. The capped SCLK value correctly appears on the sysfs interface and shows up in GUI tools such as LACT. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b2f01c77fd8b5a92a133191dd572323999072f50 Author: Timur Kristóf Date: Sun Mar 29 18:03:04 2026 +0200 drm/amd/pm/ci: Fill DW8 fields from SMC [ Upstream commit baf28ec5795c077406d6f52b8ad39e614153bce6 ] In ci_populate_dw8() we currently just read a value from the SMU and then throw it away. Instead of throwing away the value, we should use it to fill other fields in DW8 (like radeon). Otherwise the value of the other fiels is just cleared when we copy this data to the SMU later. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c9163cbf4d50240b6ccf69169c16fe443147a9f5 Author: Timur Kristóf Date: Sun Mar 29 18:03:03 2026 +0200 drm/amd/pm/ci: Clear EnabledForActivity field for memory levels [ Upstream commit 5facfd4c4c67e8500116ffec0d9da35d92b9c787 ] Follow what radeon did and what amdgpu does for other GPUs with SMU7. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6676dbdf47edb4ca15ac5cab059380c151659ff8 Author: Timur Kristóf Date: Sun Mar 29 18:03:02 2026 +0200 drm/amd/pm/ci: Fix powertune defaults for Hawaii 0x67B0 [ Upstream commit d784759c07924280f3c313f205fc48eb62d7cb71 ] There is no AMD GPU with the ID 0x66B0, this looks like a typo. It should be 0x67B0 which is actually part of the PCI ID list, and should use the Hawaii XT powertune defaults according to the old radeon driver. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9637d0099ad888b49614cd76a27c43f28044167c Author: Timur Kristóf Date: Sun Mar 29 18:03:00 2026 +0200 drm/amd/pm/smu7: Fix SMU7 voltage dependency on display clock [ Upstream commit 0138610c14130425be53423b35336561829965e0 ] The DCE (display controller engine) requires a minimum voltage in order to function correctly, depending on which clock level it currently uses. Add a new table that contains display clock frequency levels and the corresponding required voltages. The clock frequency levels are taken from DC (and the old radeon driver's voltage dependency table for CI in cases where its values were lower). The voltage levels are taken from the following function: phm_initializa_dynamic_state_adjustment_rule_settings(). Furthermore, in case of CI, call smu7_patch_vddc() on the new table to account for leakage voltage (like in radeon). Use the display clock value from amd_pp_display_configuration to look up the voltage level needed by the DCE. Send the voltage to the SMU via the PPSMC_MSG_VddC_Request command. The previous implementation of this feature was non-functional because it relied on a "dal_power_level" field which was never assigned; and it was not at all implemented for CI ASICs. I verified this on a Radeon R9 M380 which previously booted to a black screen with DC enabled (default since Linux 6.19), but now works correctly. Fixes: 599a7e9fe1b6 ("drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 49cc62087becf1f47db0053cb3b420930602dd4a Author: Timur Kristóf Date: Sun Mar 29 18:02:59 2026 +0200 drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs [ Upstream commit 9851f29cb06c09f7dad3867d8b0feec3fc71b6c8 ] There are two known cases where MCLK DPM can causes issues: Radeon R9 M380 found in iMac computers from 2015. The SMU in this GPU just hangs as soon as we send it the PPSMC_MSG_MCLKDPM_Enable command, even when MCLK switching is disabled, and even when we only populate one MCLK DPM level. Apply workaround to all devices with the same subsystem ID. Radeon R7 260X due to old memory controller microcode. We only flash the MC ucode when it isn't set up by the VBIOS, therefore there is no way to make sure that it has the correct ucode version. I verified that this patch fixes the SMU hang on the R9 M380 which would previously fail to boot. This also fixes the UVD initialization error on that GPU which happened because the SMU couldn't ungate the UVD after it hung. Fixes: 86457c3b21cb ("drm/amd/powerplay: Add support for CI asics to hwmgr") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 64d4df2ddd8aa5eb43f9949b2253775d527b6f97 Author: Timur Kristóf Date: Sun Mar 29 18:02:58 2026 +0200 drm/amd/pm/ci: Use highest MCLK on CI when MCLK DPM is disabled [ Upstream commit 894f0d34d66cb47fe718fe2ae5c18729d22c5218 ] When MCLK DPM is disabled for any reason, populate the MCLK table with the highest MCLK DPM level, so that the ASIC can use the highest possible memory clock to get good performance even when MCLK DPM is disabled. Fixes: 9f4b35411cfe ("drm/amd/powerplay: add CI asics support to smumgr (v3)") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 772a30974abdb228c3f37e0b7206bd5ec1c1fc1c Author: Vijendar Mukunda Date: Mon Mar 30 12:50:27 2026 +0530 ASoC: amd: acp: update dmic_num logic for acp pdm dmic [ Upstream commit 5902e1f3c501375797dcd7ca21b58e2c9abbe317 ] Currently there is no mechanism to read dmic_num in mach_params structure. In this scenario mach_params->dmic_num check always returns 0 which fails to add component string for dmic. Update the condition check with acp pdm dmic quirk check and pass the dmic_num as 1. Fixes: 2981d9b0789c ("ASoC: amd: acp: add soundwire machine driver for legacy stack") Signed-off-by: Vijendar Mukunda Link: https://patch.msgid.link/20260330072431.3512358-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b37a978e6d8c33fbfa4abc5dcca4c7cfc6d01f22 Author: Srinivasan Shanmugam Date: Mon Mar 23 13:02:09 2026 +0530 drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths [ Upstream commit 4ae3e16f4b3bf64140f773629b765d605ee079a9 ] In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace(). Both functions check: if (!dc_dmub_srv || !dc_dmub_srv->dmub) and then call DC_LOG_ERROR() inside that block. DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if dc_dmub_srv is NULL, the logging itself can dereference a NULL pointer and cause a crash. Fix this by splitting the checks. First check if dc_dmub_srv is NULL and return immediately. Then check dc_dmub_srv->dmub and log the error only when dc_dmub_srv is valid. Fixes the below: ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961) ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166) Fixes: 2631ac1ac328 ("drm/amd/display: add DMUB registers to crash dump diagnostic data.") Fixes: 71ba6b577a35 ("drm/amd/display: Add interface to enable DPIA trace") Cc: Roman Li Cc: Alex Hung Cc: Tom Chung Cc: Dan Carpenter Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 549d98c09f5c37f98cef966d63f4010a6356d306 Author: Cássio Gabriel Date: Wed Mar 25 02:24:04 2026 -0300 ALSA: core: Validate compress device numbers without dynamic minors [ Upstream commit 796e119e9b14763be905ad0d023c71a14bc2e931 ] Without CONFIG_SND_DYNAMIC_MINORS, ALSA reserves only two fixed minors for compress devices on each card: comprD0 and comprD1. snd_find_free_minor() currently computes the compress minor as type + dev without validating dev first, so device numbers greater than 1 spill into the HWDEP minor range instead of failing registration. ASoC passes rtd->id to snd_compress_new(), so this can happen on real non-dynamic-minor builds. Add a dedicated fixed-minor check for SNDRV_DEVICE_TYPE_COMPRESS in snd_find_free_minor() and reject out-of-range device numbers with -EINVAL before constructing the minor. Also remove the stale TODO in compress_offload.c that still claims multiple compress nodes are missing. Fixes: 3eafc959b32f ("ALSA: core: add support for compressed devices") Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260325-alsa-compress-static-minors-v1-1-0628573bee1c@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9352ffb3b64a0729dbe8a95cc5af50ae98376b5c Author: Ethan Tidmore Date: Thu Mar 19 13:26:44 2026 -0500 iommu/riscv: Fix signedness bug [ Upstream commit 553a127cb66523089bc10eb54640205495f4bb5b ] The function platform_irq_count() returns negative error codes and iommu->irqs_count is an unsigned integer, so the check (iommu->irqs_count <= 0) is always impossible. Make the return value of platform_irq_count() be assigned to ret, check for error, and then assign iommu->irqs_count to ret. Detected by Smatch: drivers/iommu/riscv/iommu-platform.c:119 riscv_iommu_platform_probe() warn: 'iommu->irqs_count' unsigned <= 0 Signed-off-by: Ethan Tidmore Fixes: 5c0ebbd3c6c6 ("iommu/riscv: Add RISC-V IOMMU platform device driver") Reviewed-by: Andrew Jones Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit c9fa0c0a6bd5e9838518fd1720502028fbd87785 Author: Ilpo Järvinen Date: Tue Mar 24 18:56:33 2026 +0200 PCI: Fix alignment calculation for resource size larger than align [ Upstream commit 8cb081667377709f4924ab6b3a88a0d7a761fe91 ] The commit bc75c8e50711 ("PCI: Rewrite bridge window head alignment function") did not use if (r_size <= align) check from pbus_size_mem() for the new head alignment bookkeeping structure (aligns2[]). In some configurations, this can result in producing a gap into the bridge window which the resource larger than its alignment cannot fill. The old alignment calculation algorithm was removed by the subsequent commit 3958bf16e2fe ("PCI: Stop over-estimating bridge window size") which renamed the aligns2[] array leaving only aligns[] array. Add the if (r_size <= align) check back to avoid this problem. Fixes: bc75c8e50711 ("PCI: Rewrite bridge window head alignment function") Reported-by: Guenter Roeck Closes: https://lore.kernel.org/all/b05a6f14-979d-42c9-924c-d8408cb12ae7@roeck-us.net/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Xifer Link: https://patch.msgid.link/20260324165633.4583-11-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit ad73563f3a1edbfddf2724136c6a15826b354e18 Author: Wenkai Lin Date: Sat Mar 21 15:00:38 2026 +0800 crypto: hisilicon/sec2 - prevent req used-after-free for sec [ Upstream commit 67b53a660e6bf0da2fa8d8872e897a14d8059eaf ] During packet transmission, if the system is under heavy load, the hardware might complete processing the packet and free the request memory (req) before the transmission function finishes. If the software subsequently accesses this req, a use-after-free error will occur. The qp_ctx memory exists throughout the packet sending process, so replace the req with the qp_ctx. Fixes: f0ae287c5045 ("crypto: hisilicon/sec2 - implement full backlog mode for sec") Signed-off-by: Wenkai Lin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a4bd046a9e5a015ca4bfda7cdb35beb7cf4def52 Author: Ilpo Järvinen Date: Fri Mar 13 10:45:50 2026 +0200 PCI: Fix premature removal from realloc_head list during resource assignment [ Upstream commit 1ee4716a5a28eaef81ae1f280d983258bee49623 ] reassign_resources_sorted() checks for two things: a) Resource assignment failures for mandatory resources by checking if the resource remains unassigned, which are known to always repeat, and does not attempt to assign them again. b) That resource is not among the ones being processed/assigned at this stage, leading to skip processing such resources in reassign_resources_sorted() as well (resource assignment progresses one PCI hierarchy level at a time). The problem here is that a) is checked before b), but b) also implies the resource is not being assigned yet, making also a) true. As a) only skips resource assignment but still removes the resource from realloc_head, the later stages that would need to process the information in realloc_head cannot obtain the optional size information anymore. This leads to considering only non-optional part for bridge windows deeper in the PCI hierarchy. This problem has been observed during rescan (add_size is not considered while attempting assignment for 0000:e2:00.0 indicating the corresponding entry was removed from realloc_head while processing resource assignments for 0000:e1): pci_bus 0000:e1: scanning bus ... pci 0000:e3:01.0: bridge window [mem 0x800000000-0x1000ffffff 64bit pref] to [bus e4] add_size 60c000000 add_align 800000000 pci 0000:e3:01.0: bridge window [mem 0x00100000-0x000fffff] to [bus e4] add_size 200000 add_align 200000 pci 0000:e3:02.0: disabling bridge window [mem 0x00000000-0x000fffff 64bit pref] to [bus e5] (unused) pci 0000:e2:00.0: bridge window [mem 0x800000000-0x1000ffffff 64bit pref] to [bus e3-e5] add_size 60c000000 add_align 800000000 pci 0000:e2:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus e3-e5] add_size 200000 add_align 200000 pcieport 0000:e1:02.0: bridge window [io size 0x2000]: can't assign; no space pcieport 0000:e1:02.0: bridge window [io size 0x2000]: failed to assign pcieport 0000:e1:02.0: bridge window [io 0x1000-0x2fff]: resource restored pcieport 0000:e1:02.0: bridge window [io 0x1000-0x2fff]: resource restored pcieport 0000:e1:02.0: bridge window [io size 0x2000]: can't assign; no space pcieport 0000:e1:02.0: bridge window [io size 0x2000]: failed to assign pci 0000:e2:00.0: bridge window [mem 0x28f000000000-0x28f800ffffff 64bit pref]: assigned Fixes: 96336ec70264 ("PCI: Perform reset_resource() and build fail list in sync") Reported-by: Peter Nisbet Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Peter Nisbet Link: https://patch.msgid.link/20260313084551.1934-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit 0727089d96763859841bafa88719c8c785a9eff8 Author: Ilpo Järvinen Date: Thu Feb 19 17:39:51 2026 +0200 PCI: Prevent shrinking bridge window from its required size [ Upstream commit dc4b4d04e1caa3552f000d84d832779ebe51b093 ] Steve reported an eGPU (either Radeon Instinct MI50 32GB or NVIDIA 3080 10GB) connected via Thunderbolt was not assigned sufficient BAR space in v6.11, so the amdgpu and nvidia drivers were unable to initialize the device. pci_bridge_distribute_available_resources() -> ... -> adjust_bridge_window() is called between __pci_bus_size_bridges() and assigning the resources. Since the commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") adjust_bridge_window() can also shrink the bridge window. The shrunken size, however, conflicts with what __pci_bus_size_bridges() -> pbus_size_mem() calculated as the required bridge window size. By shrinking the size, adjust_bridge_window() prevents the rest of the resource fitting algorithm from working as intended. Resource fitting logic is expecting assignment failures when bridge windows need resizing, but there are cases where failures are no longer happening after the commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary"). The commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") justifies the change by the extra reservation made due to hpmemsize parameter, however, the kernel code contradicts that statement. (For simplicity, finer-grained hpmmiosize and hpmmiopref parameters that can be used to the same effect as hpmemsize are ignored in this description.) pbus_size_mem() calls calculate_memsize() twice. First with add_size=0 to find out the minimal required resource size. The second call occurs with add_size=hpmemsize (effectively) but the result does not directly affect the resource size only resulting in an entry on the realloc_head list (a.k.a. add_list). Yet, adjust_bridge_window() directly changes the resource size which does not include what is reserved due to hpmemsize. Also, if the required size for the bridge window exceeds hpmemsize, the parameter does not have any effect even on the second size calculation made by pbus_size_mem(); from calculate_memsize(): size = max(size, add_size) + children_add_size; The commit ae4611f1d7e9 ("PCI: Set resource size directly in adjust_bridge_window()") that precedes the commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") is also related to causing this problem. Its changelog explicitly states adjust_bridge_window() wants to "guarantee" allocation success. Guaranteed allocations, however, are incompatible with how the other parts of the resource fitting algorithm work. The given justification fails to explain why guaranteed allocations at this stage are required nor why forcing window to a smaller value than what was calculated by pbus_size_mem() is correct. While the change might have worked by chance in some test scenario, too small bridge window does not "guarantee" success from the point of view of the endpoint device resource assignments. No issue is mentioned within the changelog so it's unclear if the change was made to fix some observed issue nor and what that issue was. The unwanted shrinking of a bridge window occurs, e.g., when a device with large BARs such as eGPU is attached using Thunderbolt and the Root Port holds less than enough resource space for the eGPU. The GPU resources are in order of GBs and the default hotplug allocation is a mere 2MB (DEFAULT_HOTPLUG_MMIO_PREF_SIZE). The problem is illustrated by this log (filtered to the relevant content only): pci 0000:00:07.0: PCI bridge to [bus 03-2c] pci 0000:00:07.0: bridge window [mem 0x6000000000-0x601bffffff 64bit pref] pci 0000:03:00.0: PCI bridge to [bus 00] pci 0000:03:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref] pci 0000:03:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0000:03:00.0: PCI bridge to [bus 04-2c] pcieport 0000:00:07.0: Assigned bridge window [mem 0x6000000000-0x601bffffff 64bit pref] to [bus 03-2c] cannot fit 0xc00000000 required for 0000:03:00.0 bridging to [bus 04-2c] pci 0000:03:00.0: bridge window [mem 0x800000000-0x10003fffff 64bit pref] to [bus 04-2c] add_size 100000 add_align 100000 pcieport 0000:00:07.0: distributing available resources pci 0000:03:00.0: bridge window [mem 0x800000000-0x10003fffff 64bit pref] shrunken by 0x00000007e4400000 pci 0000:03:00.0: bridge window [mem 0x6000000000-0x601bffffff 64bit pref]: assigned The initial size of the Root Port's window is 448MB (0x601bffffff - 0x6000000000). __pci_bus_size_bridges() -> pbus_size_mem() calculates the required size to be 32772 MB (0x10003fffff - 0x800000000) which would fit the eGPU resources. adjust_bridge_window() then shrinks the bridge window down to what is guaranteed to fit into the Root Port's bridge window. The bridge window for 03:00.0 is also eliminated from the add_list (a.k.a. realloc_head) list by adjust_bridge_window(). After adjustment, the resources are assigned and as the bridge window for 03:00.0 is assigned successfully, no failure is recorded. Without a failure, no attempt to resize the window of the Root Port is required. The end result is eGPU not having large enough resources to work. The commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") also claims nested bridge windows are sized the same, which is false. pbus_size_mem() calculates the size for the parent bridge window by summing all the downstream resources so the resource fitting calculates larger bridge window for the parent to accommodate the childen. That is, hpmemsize does not result the same size for the case where there are nested bridge windows. In order to fix the most immediate problem, don't shrink the resource size in adjust_bridge_window() as hpmemsize had nothing to do with it. When considering add_size, only reduce it up to what is added due to hpmemsize (if required size is larger than hpmemsize, the parameter has no impact, see calculate_memsize()). Unfortunately, if the tail of the bridge window was aligned in calculate_memsize() from below hpmemsize to above it, the size check will falsely match but the check at least errs to the side of caution. There's not enough information available in adjust_bridge_window() to know the calculated size precisely. This is not exactly a revert of the commits e4611f1d7e9 ("PCI: Set resource size directly in adjust_bridge_window()") and 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") as shrinking still remains in place but is implemented differently, and the end result behaves very differently. It is possible that those two commits fixed some other issue that is not described with enough detail in the changelog and undoing parts of them results in another regression due to behavioral change. Nonetheless, as described above, the solution by those two commits was flawed and the issue, if one exists, should be solved in a way that is compatible with the rest of the resource fitting algorithm instead of working against it. Besides shrinking, the case where adjust_bridge_window() expands the bridge window is likely somewhat wrong as well because it removes the entry from add_list (a.k.a. realloc_head), but it is less damaging as that only impacts optional resources and may have no impact if expanding by hpmemsize is larger than what add_size was. Fixing it is left as further work. Fixes: 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") Fixes: ae4611f1d7e9 ("PCI: Set resource size directly in adjust_bridge_window()") Reported-by: Steve Oswald Closes: https://lore.kernel.org/linux-pci/CAN95MYEaO8QYYL=5cN19nv_qDGuuP5QOD17pD_ed6a7UqFVZ-g@mail.gmail.com/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260219153951.68869-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit a27806cf5351b359c7207ce51149bb1a19a74557 Author: Krishna Chaitanya Chundru Date: Sat Mar 14 07:26:34 2026 +0530 PCI: qcom: Advertise Hotplug Slot Capability with no Command Completion support [ Upstream commit 33a76fc3c3e61386524479b99f35423bd3d9a895 ] Qcom PCIe Root Ports advertise hotplug capability in hardware, but do not support hotplug command completion. As a result, the hotplug commands issued by the pciehp driver never gets completion notification, leading to repeated timeout warnings and multi-second delays during boot and suspend/resume. Commit a54db86ddc153 ("PCI: qcom: Do not advertise hotplug capability for IPs v2.7.0 and v1.9.0") mistakenly assumed that the Root Ports doesn't support Hotplug due to timeouts and disabled the Hotplug functionality altogether. But the Root Ports does support reporting Hotplug events like DL_Up/Down events. So to fix the command completion timeout issues, just set the No Command Completed Support (NCCS) bit and enable Hotplug in Slot Capability field back. Fixes: a54db86ddc153 ("PCI: qcom: Do not advertise hotplug capability for IPs v2.7.0 and v1.9.0") Signed-off-by: Krishna Chaitanya Chundru [mani: renamed function, commit log and added comment] Signed-off-by: Manivannan Sadhasivam Tested-by: Konrad Dybcio # Hamoa CRD, tunneled link Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260314-hotplug-v1-1-96ac87d93867@oss.qualcomm.com Signed-off-by: Sasha Levin commit 776a4928fa3bb2cb4d8e8dcadcb960aadd7879e7 Author: Sebastian Reichel Date: Tue Feb 17 16:25:26 2026 +0200 drm/panel: simple: Correct G190EAN01 prepare timing [ Upstream commit f1080f82570b797598c1ba7e9c800ae9e94aafc6 ] The prepare timing specified by the G190EAN01 datasheet should be between 30 and 50 ms. Considering it might take some time for the LVDS encoder to enable the signal, we should only wait the min. required time in the panel driver and not the max. allowed time. Fixes: 2f7b832fc992 ("drm/panel: simple: Add support for AUO G190EAN01 panel") Signed-off-by: Sebastian Reichel Signed-off-by: Ian Ray Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260217142528.68613-1-ian.ray@gehealthcare.com Signed-off-by: Sasha Levin commit f5a6cc408c7fe35a94a3f7af25b66573b3d6047a Author: Dmitry Baryshkov Date: Mon Mar 23 03:21:49 2026 +0200 drm/panel: sharp-ls043t1le01: make use of prepare_prev_first [ Upstream commit c222177d7c7e1b2e0433d9e47ec2da7015345d50 ] The DSI link must be powered up to let panel driver to talk to the panel during prepare() callback execution. Set the prepare_prev_first flag to guarantee this. Fixes: 9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset") Signed-off-by: Dmitry Baryshkov Reviewed-by: Douglas Anderson Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260323-panel-fix-v1-1-9f12b09161e8@oss.qualcomm.com Signed-off-by: Sasha Levin commit 0951abf3feedbd0c1b3686a2485423f5dfeb6503 Author: Zhao Mengmeng Date: Thu Mar 26 10:51:55 2026 +0800 tools/sched_ext: scx_pair: fix pair_ctx indexing for CPU pairs [ Upstream commit f546c77038ab898726e7344255217fbec382b97f ] scx_pair sizes pair_ctx to nr_cpu_ids / 2, so valid pair_ctx keys are dense pair indexes in the range [0, nr_cpu_ids / 2). However, the userspace setup code stores pair_id as the first CPU number in each pair. On an 8-CPU system with "-S 1", that produces pair IDs 0, 2, 4 and 6 for pairs [0,1], [2,3], [4,5] and [6,7]. CPUs in the latter half then look up pair_ctx with out-of-range keys and the BPF scheduler aborts with: EXIT: scx_bpf_error (scx_pair.bpf.c:328: failed to lookup pairc and in_pair_mask for cpu[5]) Assign pair_id using a dense pair counter instead so that each CPU pair maps to a valid pair_ctx entry. Besides, reject odd CPU configuration, as scx_pair requires all CPUs to be paired. Fixes: f0262b102c7c ("tools/sched_ext: add scx_pair scheduler") Signed-off-by: Zhao Mengmeng Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b76584ca563114ba3da843f93b750e1bcb6f7ed3 Author: Alexey Charkov Date: Wed Mar 18 18:50:25 2026 +0400 ASoC: rockchip: rockchip_sai: Set slot width for non-TDM mode [ Upstream commit 8a6391ec669366cbe7bde92b468c561e8b309fd6 ] Currently the slot width in non-TDM mode is always kept at the POR value of 32 bits, regardless of the sample width, which doesn't work well for some codecs such as NAU8822. Set the slot width according to the sample width in non-TDM mode, which is what other CPU DAI drivers do. Tested on the following RK3576 configurations: - SAI2 + NAU8822 (codec as the clock master), custom board - SAI1 + ES8388 (codec as the clock master), RK3576 EVB1 - SAI2 + RT5616 (SAI as the clock master), FriendlyElec NanoPi M5 NAU8822 didn't work prior to this patch but works after the patch. Other two configurations work both before and after the patch. Fixes: cc78d1eaabad ("ASoC: rockchip: add Serial Audio Interface (SAI) driver") Signed-off-by: Alexey Charkov Tested-by: Nicolas Frattaroli Link: https://patch.msgid.link/20260318-sai-slot-width-v1-1-1f68186f71e3@flipper.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d3a4bb88820bf6e56ffda690a8682033de635212 Author: Alexander Koskovich Date: Tue Mar 24 11:48:27 2026 +0000 drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0 [ Upstream commit 913a709dea0eff9c7b2e9470f8c8594b9a0114ab ] The MSM8998 DSI controller is v2.0.0 as stated in commit 7b8c9e203039 ("drm/msm/dsi: Add support for MSM8998 DSI controller"). The value was always correct just the name was wrong. Rename and reorder to maintain version sorting. Fixes: 7b8c9e203039 ("drm/msm/dsi: Add support for MSM8998 DSI controller") Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Alexander Koskovich Patchwork: https://patchwork.freedesktop.org/patch/713717/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-3-ff6afc904115@pm.me Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 5065130412edf44c771e36ff7dfb24f4df7bb78e Author: Pengyu Luo Date: Sat Mar 7 19:12:49 2026 +0800 drm/msm/dsi: fix hdisplay calculation for CMD mode panel [ Upstream commit 82159db4371f5cef56444ebd0b8f96e2a6d709ff ] Commit ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when programming dsi registers") incorrecly broke hdisplay calculation for CMD mode by specifying incorrect number of bytes per transfer, fix it. Fixes: ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when programming dsi registers") Signed-off-by: Pengyu Luo Patchwork: https://patchwork.freedesktop.org/patch/709917/ Link: https://lore.kernel.org/r/20260307111250.105772-2-mitltlatltl@gmail.com [DB: fixed commit message] Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 37aa6317f39c7588b84b4bfdff0c94f2c315178d Author: Pengyu Luo Date: Sat Mar 7 19:12:48 2026 +0800 drm/msm/dsi: fix bits_per_pclk [ Upstream commit 2d51cfb77daa30b10bc68c403f8ace35783d2922 ] mipi_dsi_pixel_format_to_bpp return dst bpp not src bpp, dst bpp may not be the uncompressed data size. use src bpc * 3 to get src bpp, this aligns with pclk rate calculation. Fixes: ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when programming dsi registers") Signed-off-by: Pengyu Luo Patchwork: https://patchwork.freedesktop.org/patch/709916/ Link: https://lore.kernel.org/r/20260307111250.105772-1-mitltlatltl@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 1ec793bcfc1172b3fc2d821aadff97f32bb7dd43 Author: Dmitry Baryshkov Date: Tue Mar 17 17:30:05 2026 +0200 drm/msm/dpu: don't try using 2 LMs if only one DSC is available [ Upstream commit b9699dd862760e642807a2bc226e4d127e35dcb7 ] Current topology code will try using 2 LMs with just one DSC, which breaks cases like SC7280 / Fairphone5. Forbid using 2 LMs split in such a case. Fixes: 1ce69c265a53 ("drm/msm/dpu: move resource allocation to CRTC") Reported-by: Luca Weiss Closes: https://lore.kernel.org/r/DH1IKLU0YZYU.2SW4WYO7H3H4R@fairphone.com/ Tested-by: Luca Weiss # qcm6490-fairphone-fp5 Patchwork: https://patchwork.freedesktop.org/patch/712386/ Link: https://lore.kernel.org/r/20260317-fix-3d-dsc-v1-1-88b54f62f659@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 79600b511c1236e12ef61d4bc745043965e3aba4 Author: Pengyu Luo Date: Mon Mar 9 18:02:53 2026 +0800 drm/msm/dsi: add the missing parameter description [ Upstream commit 958adefc4c0fddee3b12269da5dd7cb49bac953f ] Add a description for is_bonded_dsi in dsi_adjust_pclk_for_compression to match the existing kernel-doc comment. Fixes: e4eb11b34d6c ("drm/msm/dsi: fix pclk rate calculation for bonded dsi") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202603080314.XeqyRZ7A-lkp@intel.com/ Signed-off-by: Pengyu Luo Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/710112/ Link: https://lore.kernel.org/r/20260309100254.877801-1-mitltlatltl@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0ccf4f27b4652570b5de3de02a89a86435559de9 Author: Yuanjie Yang Date: Mon Mar 9 14:37:20 2026 +0800 drm/msm/dpu: fix mismatch between power and frequency [ Upstream commit bc1dccc518cc5ab5140fba06c27e7188e0ed342b ] During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops the MMCX rail to MIN_SVS while the core clock frequency remains at its original (highest) rate. When runtime resume re-enables the clock, this may result in a mismatch between the rail voltage and the clock rate. For example, in the DPU bind path, the sequence could be: cpu0: dev_sync_state -> rpmhpd_sync_state cpu1: dpu_kms_hw_init timeline 0 ------------------------------------------------> t After rpmhpd_sync_state, the voltage performance is no longer guaranteed to stay at the highest level. During dpu_kms_hw_init, calling dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to fall to MIN_SVS while the core clock is still at its maximum frequency. When the power is re-enabled, only the clock is enabled, leading to a situation where the MMCX rail is at MIN_SVS but the core clock is at its highest rate. In this state, the rail cannot sustain the clock rate, which may cause instability or system crash. Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend to ensure the correct vote is restored when DPU resumes. Fixes: b0530eb11913 ("drm/msm/dpu: Use OPP API to set clk/perf state") Signed-off-by: Yuanjie Yang Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/710077/ Link: https://lore.kernel.org/r/20260309063720.13572-1-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit a8d39b8a2114708154a0e5086ea1e381fc869006 Author: Dmitry Baryshkov Date: Sat Feb 28 19:20:37 2026 +0200 drm/msm: add missing MODULE_DEVICE_ID definitions [ Upstream commit b21e85400ce763f2c6ad913e03fea5cadc323c13 ] The drm/msm module bundles several drivers, each of them having a separate OF match table, however only MDSS (subsystem), KMS devices and GPU have corresponding MODULE_DEVICE_ID tables. Add MODULE_DEVICE_ID to the display-related driver and to all other drivers in this module, simplifying userspace job. Fixes: 060530f1ea67 ("drm/msm: use componentised device support") Reported-by: Loïc Minier Patchwork: https://patchwork.freedesktop.org/patch/707960/ Link: https://lore.kernel.org/r/20260228-msm-device-id-v2-1-24b085919444@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit fab956c7a24009944f80edf7c6b68b1699089528 Author: Nicolin Chen Date: Thu Mar 12 17:36:35 2026 -0700 iommu/tegra241-cmdqv: Update uAPI to clarify HYP_OWN requirement [ Upstream commit 9dcef98dbee35b8ae784df04c041efffdd42a69c ] >From hardware implementation perspective, a guest tegra241-cmdqv hardware is different than the host hardware: - Host HW is backed by a VINTF (HYP_OWN=1) - Guest HW is backed by a VINTF (HYP_OWN=0) The kernel driver has an implementation requirement of the HYP_OWN bit in the VM. So, VMM must follow that to allow the same copy of Linux to work. Add this requirement to the uAPI, which is currently missing. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Signed-off-by: Nicolin Chen Reviewed-by: Eric Auger Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b6726d347c61ad8c086371dafc2e3316b112c375 Author: Nicolin Chen Date: Thu Mar 12 17:36:34 2026 -0700 iommu/tegra241-cmdqv: Set supports_cmd op in tegra241_vcmdq_hw_init() [ Upstream commit 803e41f36d227022ab9bbe780c82283fd4713b2e ] vintf->hyp_own is finalized in tegra241_vintf_hw_init(). On the other hand, tegra241_vcmdq_alloc_smmu_cmdq() is called via an init_structures callback, which is earlier than tegra241_vintf_hw_init(). This results in the supports_cmd op always being set to the guest function, although this doesn't break any functionality nor have some noticeable perf impact since non-invalidation commands are not issued in the perf sensitive context. Fix this by moving supports_cmd to tegra241_vcmdq_hw_init(). After this change, - For a guest kernel, this will be a status quo - For a host kernel, non-invalidation commands will be issued to VCMDQ(s) Fixes: a9d40285bdef ("iommu/tegra241-cmdqv: Limit CMDs for VCMDQs of a guest owned VINTF") Reported-by: Eric Auger Reported-by: Shameer Kolothum Closes: https://lore.kernel.org/qemu-devel/CH3PR12MB754836BEE54E39B30C7210C0AB44A@CH3PR12MB7548.namprd12.prod.outlook.com/ Signed-off-by: Nicolin Chen Reviewed-by: Eric Auger Tested-by: Shameer Kolothum Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2a3b4f55f07f2065b1920e7ee329f6ed89859f49 Author: Alexandru Dadu Date: Mon Mar 23 20:31:29 2026 +0200 drm/imagination: Switch reset_reason fields from enum to u32 [ Upstream commit d2f83a6cd598bf413f1acf34153bd1d71023fbab ] Update the reset_reason fwif structure fields from enum to u32 to remove any ambiguity from the interface (enum is not a fixed size thus is unfit for the purpose of the data type). Fixes: a26f067feac1f ("drm/imagination: Add FWIF headers") Signed-off-by: Alexandru Dadu Reviewed-by: Matt Coster Link: https://patch.msgid.link/20260323-b4-firmware-context-reset-notification-handling-v3-2-1a66049a9a65@imgtec.com Signed-off-by: Matt Coster Signed-off-by: Sasha Levin commit 3522f27fce7c13e61e73b5c94cf630bb0686e4bf Author: Felix Gu Date: Tue Mar 24 00:41:28 2026 +0800 PCI: sky1: Fix missing cleanup of ECAM config on probe failure [ Upstream commit 72e76b63d6ff6d1f96acccbfc6c118656f63e66a ] When devm_kzalloc() for reg_off fails, the code returns -ENOMEM without freeing pcie->cfg, which was allocated earlier by pci_ecam_create(). Add the missing pci_ecam_free() call to properly release the allocated ECAM configuration window on this error path. Fixes: a0d9f2c08f45 ("PCI: sky1: Add PCIe host support for CIX Sky1") Signed-off-by: Felix Gu Signed-off-by: Manivannan Sadhasivam Reviewed-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260324-sky1-v1-1-6a00cb2776b6@gmail.com Signed-off-by: Sasha Levin commit c976e19cac400d1877cfa8fc04ae7aa67e2ac2c5 Author: Pei Xiao Date: Thu Mar 19 11:06:41 2026 +0800 spi: hisi-kunpeng: prevent infinite while() loop in hisi_spi_flush_fifo [ Upstream commit 9f61daf2c2debe9f5cf4e1a4471e56a89a6fe45a ] The hisi_spi_flush_fifo()'s inner while loop that lacks any timeout mechanism. Maybe the hardware never becomes empty, the loop will spin forever, causing the CPU to hang. Fix this by adding a inner_limit based on loops_per_jiffy. The inner loop now exits after approximately one jiffy if the FIFO remains non-empty, logs a ratelimited warning, and breaks out of the outer loop. Additionally, add a cpu_relax() inside the busy loop to improve power efficiency. Fixes: c770d8631e18 ("spi: Add HiSilicon SPI Controller Driver for Kunpeng SoCs") Signed-off-by: Pei Xiao Link: https://patch.msgid.link/d834ce28172886bfaeb9c8ca00cfd9bf1c65d5a1.1773889292.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 67f60f7a4c2a14ad3f63edf2ecc5c4eee8208157 Author: Alex Deucher Date: Thu Feb 19 18:20:27 2026 -0500 drm/amdgpu/gfx11: look at the right prop for gfx queue priority [ Upstream commit f9a4e81bcbd04e6f967d851f9fe69d8bb3cc08b3 ] Look at hqd_queue_priority rather than hqd_pipe_priority. In practice, it didn't matter as both were always set for kernel queues, but that will change in the future. Fixes: 2e216b1e6ba2 ("drm/amdgpu/gfx11: handle priority setup for gfx pipe1") Reviewed-by：Jesse Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 65c3abe2aded3a76984502567eb80c0ffca7ad62 Author: Alex Deucher Date: Thu Feb 19 18:18:28 2026 -0500 drm/amdgpu/gfx10: look at the right prop for gfx queue priority [ Upstream commit 355d96cdec5c61fd83f7eb54f1a28e38809645d6 ] Look at hqd_queue_priority rather than hqd_pipe_priority. In practice, it didn't matter as both were always set for kernel queues, but that will change in the future. Fixes: b07d1d73b09e ("drm/amd/amdgpu: Enable high priority gfx queue") Reviewed-by：Jesse Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4f1f639aea97efd688c8e363703e7c1a92047642 Author: Srinivasan Shanmugam Date: Sun Mar 15 11:53:31 2026 +0530 drm/amd/ras: Remove redundant NULL check in pending bad-bank list iteration [ Upstream commit fd490bb9e1054705e1b35e6f321cdc713e0c7348 ] ras_umc_log_pending_bad_bank() walks through a list of pending ECC bad-bank entries. These entries are saved when a bad-bank error cannot be processed immediately, for example during a GPU reset. Later, this function iterates over the pending list and retries logging each bad-bank error. If logging succeeds, the entry is removed from the list and the memory for that node is freed. The loop uses list_for_each_entry_safe(), which already guarantees that ecc_node points to a valid list entry while the loop body is executing. Checking "ecc_node &&" inside the loop is therefore unnecessary and redundant. Fixes the below: drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_umc.c:225 ras_umc_log_pending_bad_bank() warn: variable dereferenced before check 'ecc_node' (see line 223) Fixes: 7a3f9c0992c4 ("drm/amd/ras: Add umc common ras functions") Cc: Dan Carpenter Cc: YiPeng Chai Cc: Tao Zhou Cc: Hawking Zhang Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: YiPeng Chai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c932aef23cdc9d1d06aa13994ac6f00279a31686 Author: haoyu.lu Date: Mon Mar 23 11:49:32 2026 +0800 accel/amdxdna: fix missing newline in pr_err message [ Upstream commit d1c73884858cb3ce2a0f761988a6f279bff32b91 ] Add missing newline to pr_err message in amdxdna_mailbox.c. Fixes: b87f920b9344 ("accel/amdxdna: Support hardware mailbox") Signed-off-by: haoyu.lu Reviewed-by: Lizhi.hou Signed-off-by: Lizhi.hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260323034933.216-1-hechushiguitu666@gmail.com Signed-off-by: Sasha Levin commit 787bb0bb77d2fb2965398aab3c66851512c68fa3 Author: Koichiro Den Date: Fri Mar 6 00:10:50 2026 +0900 PCI: dwc: rcar-gen4: Change EPC BAR alignment to 4K as per the documentation [ Upstream commit 13f55a7ca773c731a1e645934c1ae48577f48785 ] R-Car S4 Series (R8A779F[4-7]*) EP controller uses a 4K minimum iATU region size (CX_ATU_MIN_REGION_SIZE = 4K) as per R19UH0161EJ0130 Rev.1.30. Also, the controller itself can only be configured in the range 4 KB to 64 KB, so the current 1 MB alignment requirement is incorrect. Hence, change the alignment to the min size 4K as per the documentation. This also fixes needless unusability of BAR4 on this platform when the target address is fixed, such as for doorbell targets. Fixes: e311b3834dfa ("PCI: rcar-gen4: Add endpoint mode support") Signed-off-by: Koichiro Den [mani: commit log] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260305151050.1834007-1-den@valinux.co.jp Signed-off-by: Sasha Levin commit 9afe53f14a2aae8c4beb30e5ea51641a34f1a3d3 Author: Daniel Jordan Date: Fri Mar 13 11:24:33 2026 -0400 padata: Put CPU offline callback in ONLINE section to allow failure [ Upstream commit c8c4a2972f83c8b68ff03b43cecdb898939ff851 ] syzbot reported the following warning: DEAD callback error for CPU1 WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614 at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padata_cpu_dead() given it's the only sub-CPUHP_TEARDOWN_CPU callback that returns an error. Failure isn't allowed in hotplug states before CPUHP_TEARDOWN_CPU so move the CPU offline callback to the ONLINE section where failure is possible. Fixes: 894c9ef9780c ("padata: validate cpumask without removed CPU during offline") Reported-by: syzbot+123e1b70473ce213f3af@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69af0a05.050a0220.310d8.002f.GAE@google.com/ Debugged-by: Thomas Gleixner Signed-off-by: Daniel Jordan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9eee23a24d461144e27f39aa7df394d57361dd71 Author: Chuyi Zhou Date: Thu Feb 26 16:07:03 2026 +0800 padata: Remove cpu online check from cpu add and removal [ Upstream commit 73117ea6470dca787f70f33c001f9faf437a1c0b ] During the CPU offline process, the dying CPU is cleared from the cpu_online_mask in takedown_cpu(). After this step, various CPUHP_*_DEAD callbacks are executed to perform cleanup jobs for the dead CPU, so this cpu online check in padata_cpu_dead() is unnecessary. Similarly, when executing padata_cpu_online() during the CPUHP_AP_ONLINE_DYN phase, the CPU has already been set in the cpu_online_mask, the action even occurs earlier than the CPUHP_AP_ONLINE_IDLE stage. Remove this unnecessary cpu online check in __padata_add_cpu() and __padata_remove_cpu(). Signed-off-by: Chuyi Zhou Acked-by: Daniel Jordan Signed-off-by: Herbert Xu Stable-dep-of: c8c4a2972f83 ("padata: Put CPU offline callback in ONLINE section to allow failure") Signed-off-by: Sasha Levin commit 60ebd6a12acfdb51f7d5023c7db6ed3d8e99c6a4 Author: Thorsten Blum Date: Wed Mar 11 12:39:28 2026 +0100 crypto: atmel-aes - guard unregister on error in atmel_aes_register_algs [ Upstream commit 57a13941c0bb06ae24e3b34672d7b6f2172b253f ] Ensure the device supports XTS and GCM with 'has_xts' and 'has_gcm' before unregistering algorithms when XTS or authenc registration fails, which would trigger a WARN in crypto_unregister_alg(). Currently, with the capabilities defined in atmel_aes_get_cap(), this bug cannot happen because all devices that support XTS and authenc also support GCM, but the error handling should still be correct regardless of hardware capabilities. Fixes: d52db5188a87 ("crypto: atmel-aes - add support to the XTS mode") Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 243cd9a9944cf1558d060ae7624f2a08e2e0c0af Author: Herbert Xu Date: Tue Mar 10 18:28:29 2026 +0900 crypto: tegra - Disable softirqs before finalizing request [ Upstream commit 2aeec9af775fb53aa086419b953302c6f4ad4984 ] Softirqs must be disabled when calling the finalization fucntion on a request. Reported-by: Guangwu Zhang Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b28ae7799eebc450e56b74fb9f02a8318e73fb59 Author: Wesley Atwell Date: Sun Mar 8 22:31:43 2026 -0600 crypto: simd - reject compat registrations without __ prefixes [ Upstream commit e0ce97f781c78b717b00493630a9e34caf04f79b ] simd_register_skciphers_compat() and simd_register_aeads_compat() derive the wrapper algorithm names by stripping the __ prefix from the internal algorithm names. Currently they only WARN if cra_name or cra_driver_name lacks that prefix, but they still continue and unconditionally add 2 to both strings. That registers wrapper algorithms with incorrectly truncated names after a violated precondition. Reject such inputs with -EINVAL before registering anything, while keeping the warning so invalid internal API usage is still visible. Fixes: d14f0a1fc488 ("crypto: simd - allow registering multiple algorithms at once") Fixes: 1661131a0479 ("crypto: simd - support wrapping AEAD algorithms") Assisted-by: Codex:GPT-5 Signed-off-by: Wesley Atwell Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f23acdd409fd04cef4fe900973f4fe99e0a68c21 Author: Andy Shevchenko Date: Fri Mar 20 15:36:46 2026 +0100 fbdev: matroxfb: Mark variable with __maybe_unused to avoid W=1 build break [ Upstream commit caf6144053b4e1c815aa56afb54745a176f999df ] Clang is not happy about set but unused variable: drivers/video/fbdev/matrox/g450_pll.c:412:18: error: variable 'mnp' set but not used 412 | unsigned int mnp; | ^ 1 error generated. Since the commit 7b987887f97b ("video: fbdev: matroxfb: remove dead code and set but not used variable") the 'mnp' became unused, but eliminating that code might have side-effects. The question here is what should we do with 'mnp'? The easiest way out is just mark it with __maybe_unused which will shut the compiler up and won't change any possible IO flow. So does this change. A dive into the history of the driver: The problem was revealed when the #if 0 guarded code along with unused pixel_vco variable was removed. That code was introduced in the original commit 213d22146d1f ("[PATCH] (1/3) matroxfb for 2.5.3"). And then guarded in the commit 705e41f82988 ("matroxfb DVI updates: Handle DVI output on G450/G550. Powerdown unused portions of G450/G550 DAC. Split G450/G550 DAC from older DAC1064 handling. Modify PLL setting when both CRTCs use same pixel clocks."). NOTE: The two commits mentioned above pre-date Git era and available in history.git repository for archaeological purposes. Even without that guard the modern compilers may see that the pixel_vco wasn't ever used and seems a leftover after some debug or review made 25 years ago. The g450_mnp2vco() doesn't have any IO and as Jason said doesn't seem to have any side effects either than some unneeded CPU processing during runtime. I agree that's unlikely that timeout (or heating up the CPU) has any effect on the HW (GPU/display) functionality. Fixes: 7b987887f97b ("video: fbdev: matroxfb: remove dead code and set but not used variable") Signed-off-by: Andy Shevchenko Reviewed-by: Jason Yan Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 3b84f59725c350065bac52e696a8ffb6b13051c4 Author: Guillaume Gonnet Date: Tue Mar 17 22:32:28 2026 +0100 dm init: ensure device probing has finished in dm-mod.waitfor= [ Upstream commit 99a2312f69805f4ba92d98a757625e0300a747ab ] The early_lookup_bdev() function returns successfully when the disk device is present but not necessarily its partitions. In this situation, dm_early_create() fails as the partition block device does not exist yet. In my case, this phenomenon occurs quite often because the device is an SD card with slow reading times, on which kernel takes time to enumerate available partitions. Fortunately, the underlying device is back to "probing" state while enumerating partitions. Waiting for all probing to end is enough to fix this issue. That's also the reason why this problem never occurs with rootwait= parameter: the while loop inside wait_for_root() explicitly waits for probing to be done and then the function calls async_synchronize_full(). These lines were omitted in 035641b, even though the commit says it's based on the rootwait logic... Anyway, calling wait_for_device_probe() after our while loop does the job (it both waits for probing and calls async_synchronize_full). Fixes: 035641b01e72 ("dm init: add dm-mod.waitfor to wait for asynchronously probed block devices") Signed-off-by: Guillaume Gonnet Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 3f3711e1f7c54c6f3eb86350ce6787fedbf17354 Author: Srinivasan Shanmugam Date: Thu Mar 12 18:53:59 2026 +0530 drm/amdgpu: Remove dead negative offset check in amdgpu_virt_init_critical_region() [ Upstream commit 4fce3dfab54d60ebaff1c7a9020a730a0708b705 ] amdgpu_virt_init_critical_region() stores init_hdr_offset as u64. The subsequent check for init_hdr_offset < 0 is therefore always false. Drop the unreachable validation and rely on the existing check_add_overflow() and VRAM end bounds check for offset validation. This resolves the Smatch warning about comparing an unsigned value against zero. drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:953 amdgpu_virt_init_critical_region() warn: unsigned 'init_hdr_offset' is never less than zero. Fixes: 07009df6494d ("drm/amdgpu: Introduce SRIOV critical regions v2 during VF init") Cc: Dan Carpenter Cc: Ellen Pan Cc: Lijo Lazar Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Reviewed-by: Bokun Zhang Reviewed-by: Ellen Pan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f9ecad1d7428753679003f6b2ce1a172faa2e85a Author: Srinivasan Shanmugam Date: Sun Mar 15 12:42:42 2026 +0530 drm/amdgpu: Drop redundant queue NULL check in hang detect worker [ Upstream commit 9a62a097a7f8d223d722b9e9b557a792d30600ca ] amdgpu_userq_hang_detect_work() retrieves the queue pointer using container_of() from the embedded work item. Since the work structure is part of struct amdgpu_usermode_queue, the returned queue pointer cannot be NULL in normal execution. Remove the redundant !queue check and keep the validation for queue->userq_mgr. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c:159 amdgpu_userq_hang_detect_work() warn: can 'queue' even be NULL? Fixes: 290f46cf5726 ("drm/amdgpu: Implement user queue reset functionality") Cc: Jesse Zhang Cc: Dan Carpenter Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Acked-by: Jesse Zhang Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6c84f7f0afc415691ffa7d48aa7ce1d8e6083032 Author: Srinivasan Shanmugam Date: Sun Mar 15 11:29:41 2026 +0530 drm/amd/ras: Fix NULL deref in ras_core_get_utc_second_timestamp() [ Upstream commit 2b8101cc3b34d4d80d799360d2744829d5964479 ] ras_core_get_utc_second_timestamp() retrieves the current UTC timestamp (in seconds since the Unix epoch) through a platform-specific RAS system callback and is used for timestamping RAS error events. The function checks ras_core in the conditional statement before calling the sys_fn callback. However, when the condition fails, the function prints an error message using ras_core->dev. If ras_core is NULL, this can lead to a potential NULL pointer dereference when accessing ras_core->dev. Add an early NULL check for ras_core at the beginning of the function and return 0 when the pointer is not valid. This prevents the dereference and makes the control flow clearer. Fixes: 13c91b5b4378 ("drm/amd/ras: Add rascore unified interface function") Cc: YiPeng Chai Cc: Dan Carpenter Cc: Tao Zhou Cc: Hawking Zhang Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: YiPeng Chai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 90a750a29ba15a28bd3d328a958287b564124593 Author: Robby Cai Date: Fri Mar 13 21:31:02 2026 +0800 regulator: fp9931: Fix handling of mandatory "vin" supply [ Upstream commit 58068932402c7f5bf26489e01ae8e8bb89802d1e ] The FP9931 requires a mandatory "vin" power supply to operate. Replace devm_regulator_get_optional() with devm_regulator_get() to enforce this mandatory dependency. Fixes: 12d821bd13d42 ("regulator: Add FP9931/JD9930 driver") Signed-off-by: Robby Cai Link: https://patch.msgid.link/20260313133102.2749890-3-robby.cai@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f334ef2b9920da8e1a8f9c0c5cb3e233935259ba Author: Robby Cai Date: Fri Mar 13 21:31:01 2026 +0800 regulator: dt-bindings: fp9931: Make vin-supply property as required [ Upstream commit d342f5e355aaa4ff4fb5bd4a4aab70ed3a4f3c35 ] The FP9931 requires a vin power supply to operate, so mark vin-supply as a required property in the binding. Fixes: 80bbdefdfb417 ("dt-bindings: regulator: Add Fitipower FP9931/JD9930") Signed-off-by: Robby Cai Link: https://patch.msgid.link/20260313133102.2749890-2-robby.cai@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9636c99b8abf7a6a5c4bfe1ae975489d80202b14 Author: Srinivasan Shanmugam Date: Thu Mar 12 19:29:54 2026 +0530 drm/amdgpu: Add default case in DVI mode validation [ Upstream commit e6020a55b8e364d15eac27f9c788e13114eec6b7 ] amdgpu_connector_dvi_mode_valid() assigns max_digital_pixel_clock_khz based on connector_object_id using a switch statement that lacks a default case. In practice this code path should never be hit because the existing cases already cover all digital connector types that this function is used for. This is also legacy display code which is not used for new hardware. Add a default case returning MODE_BAD to make the switch exhaustive and silence the static analyzer smatch error. The new branch is effectively defensive and should never be reached during normal operation. Fixes: 585b2f685c56 ("drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)") Cc: Dan Carpenter Cc: Timur Kristóf Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f2f2ed3d359509c311cc6626226e4578d7eb77d8 Author: Srinivasan Shanmugam Date: Wed Oct 22 18:16:51 2025 +0530 drm/amd/ras: Fix NULL deref in ras_core_ras_interrupt_detected() [ Upstream commit 6b606216e03fa2b53cc179d8383b683a140fe6e1 ] Fixes a NULL pointer dereference when ras_core is NULL and ras_core->dev is accessed in the error path. Fixes: 13c91b5b4378 ("drm/amd/ras: Add rascore unified interface function") Reported by: Dan Carpenter Cc: YiPeng Chai Cc: Tao Zhou Cc: Hawking Zhang Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit efc2005866380b05083b7dd8c8ec4f1e96325abf Author: Philip Yang Date: Tue Dec 9 16:01:10 2025 -0500 drm/amdkfd: Update queue properties for metadata ring [ Upstream commit 189208d3d503090d95a39e85433bd608a0d84511 ] Metadata ring and queue ring is allocated as one buffer and map to GPU, so update queue peoperties should add the queue metadata size and ring size as buffer size to validate queue ring buffer. Fixes: c51bb53d5c68 ("drm/amdkfd: Add metadata ring buffer for compute") Signed-off-by: Philip Yang Reviewed-by: Alex Sierra Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 41245c314e166bca2757e86f75e77839c10014f6 Author: Fangyu Yu Date: Fri Feb 27 19:26:40 2026 +0800 iommu/riscv: Stop polling when CQCSR reports an error [ Upstream commit b2e5684558edf3e9bbe18d0e0043854994eab1be ] The cmdq wait loop busy-polls the consumer index until it advances or the software timeout expires. If the IOMMU has already signaled a command queue failure in CQCSR, continuing to poll for progress is pointless. Make riscv_iommu_queue_wait() also terminate the poll when any of these CQCSR error bits are observed. This helps the caller return earlier in failure cases and avoids spinning until the full timeout interval when the hardware has already reported an error. On single-core systems in particular, the current busy-wait can delay servicing the command-timeout interrupt until the software timeout expires (90s by default). Fixes: 856c0cfe5c5f ("iommu/riscv: Command and fault queue support") Signed-off-by: Fangyu Yu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit bdd288b16aaad86aad5b2f111b747635e251306f Author: Jason Gunthorpe Date: Fri Feb 27 11:25:40 2026 -0400 iommu/riscv: Add missing GENERIC_MSI_IRQ [ Upstream commit c70d20b25ca30d68b377b9363a2adca6eb2538e3 ] The commit below added MSI related calls to the driver that depends on GENERIC_MSI_IRQ. It is possible to build RISC-V without this selected. This is also necessary to make the driver COMPILE_TEST. Fixes: d5f88acdd6ff ("iommu/riscv: Add support for platform msi") Tested-by: Vincent Chen Tested-by: Tomasz Jeznach Signed-off-by: Jason Gunthorpe Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 6dd182e50431d465705f6e4fa0c52cf3199aeedf Author: Yaxing Guo Date: Fri Jan 30 14:54:20 2026 +0800 iommu/riscv: Skip IRQ count check when using MSI interrupts [ Upstream commit 7217cee35aadbb07e12673bcf1dcf729e1b2f6c9 ] In RISC-V IOMMU platform devices that use MSI interrupts (indicated by the presence of 'msi-parent' in the device tree), there are no wired interrupt lines, so calling platform_get_irq_count() returns 0 or -ENXIO, causing the driver to fail during probe. However, MSI interrupts are allocated dynamically via the MSI subsystem and do not appear in the device tree 'interrupts' property. Therefore, the driver should not require a non-zero IRQ count when 'msi-parent' is present. This patch fixes the bug where probe fails when using MSI interrupts (which do not have an 'interrupts' property in the device tree).. Fixes: ("iommu/riscv: Add support for platform msi") Signed-off-by: Yaxing Guo Reviewed-by: Andrew Jones Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit d99d1c13faa793ff1abab0d20ab6473c838081b3 Author: Fangyu Yu Date: Thu Jan 22 22:32:24 2026 +0800 iommu/riscv: Add IOTINVAL after updating DDT/PDT entries [ Upstream commit f5c262b544975e067ea265fc7403aefbbea8563e ] Add riscv_iommu_iodir_iotinval() to perform required TLB and context cache invalidations after updating DDT or PDT entries, as mandated by the RISC-V IOMMU specification (Section 6.3.1 and 6.3.2). Fixes: 488ffbf18171 ("iommu/riscv: Paging domain support") Signed-off-by: Fangyu Yu Reviewed-by: Andrew Jones Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 1e0f65d3421ce05050bd618e7ed37ad892fb4d35 Author: John Madieu Date: Fri Mar 6 15:34:12 2026 +0100 dt-bindings: PCI: renesas,r9a08g045s33-pcie: Fix naming properties [ Upstream commit bb1b0f47f6822864c1689f46348efa42c5d4074c ] Fix a typo in interrupt-names: "ser_cor" should be "serr_cor" (System Error Correctable). Also convert interrupt-names, clock-names, and reset-names properties from "description" to "const" to enable proper validation with dtbs_check. Fixes: e7534e790557 ("dt-bindings: PCI: Add Renesas RZ/G3S PCIe controller binding") Signed-off-by: John Madieu Signed-off-by: Manivannan Sadhasivam Tested-by: Lad Prabhakar # RZ/V2N EVK Tested-by: Claudiu Beznea Reviewed-by: Claudiu Beznea Acked-by: Conor Dooley Link: https://patch.msgid.link/20260306143423.19562-6-john.madieu.xa@bp.renesas.com Signed-off-by: Sasha Levin commit 913b65c62afece7c0a841f9abd5e610a79ed2f55 Author: John Madieu Date: Fri Mar 6 15:34:09 2026 +0100 PCI: rzg3s-host: Reorder reset assertion during suspend [ Upstream commit 34735f63748daa2ea27544259c3042b4948376bf ] Reorder the reset assertion sequence during suspend from power_resets -> cfg_resets to cfg_resets -> power_resets. This change ensures the suspend sequence follows the reverse order of the probe/init sequence, where power_resets are deasserted first followed by cfg_resets. Additionally, this ordering is required for RZ/G3E support where cfg resets are controlled through PCIe AXI registers (offset 0x310h). According to the RZ/G3E hardware manual (Rev.1.15, section 6.6.6.1.1 "Changing the Initial Values of the Registers"), AXI register access requires ARESETn to be de-asserted and the clock to be supplied. Since ARESETn is part of power_resets, cfg_resets must be asserted before power_resets, otherwise the AXI registers become inaccessible. Fixes: 7ef502fb35b2 ("PCI: Add Renesas RZ/G3S host controller driver") Signed-off-by: John Madieu Signed-off-by: Manivannan Sadhasivam Tested-by: Lad Prabhakar # RZ/V2N EVK Tested-by: Claudiu Beznea Reviewed-by: Claudiu Beznea Link: https://patch.msgid.link/20260306143423.19562-3-john.madieu.xa@bp.renesas.com Signed-off-by: Sasha Levin commit 8e10e3ebdc7837e5103e099158766a0832e9d270 Author: John Madieu Date: Fri Mar 6 15:34:08 2026 +0100 PCI: rzg3s-host: Fix reset handling in probe error path [ Upstream commit d284389d4576e7c8040dc4cbb66876e539c6d064 ] Fix incorrect reset_control_bulk_deassert() call in the probe error path. When unwinding from a failed pci_host_probe(), the configuration resets should be asserted to restore the hardware to its initial state, not deasserted again. Fixes: 7ef502fb35b2 ("PCI: Add Renesas RZ/G3S host controller driver") Signed-off-by: John Madieu Signed-off-by: Manivannan Sadhasivam Tested-by: Lad Prabhakar # RZ/V2N EVK Tested-by: Claudiu Beznea Reviewed-by: Claudiu Beznea Link: https://patch.msgid.link/20260306143423.19562-2-john.madieu.xa@bp.renesas.com Signed-off-by: Sasha Levin commit 3399a3e2faa0af617415d4f47a1457ece7db348a Author: Aleksander Jan Bajkowski Date: Fri Mar 6 23:17:40 2026 +0100 crypto: inside-secure/eip93 - register hash before authenc algorithms [ Upstream commit 5377032914b29b4643adece0ff1dfc67e36700f4 ] Register hash before hmac and authenc algorithms. This will ensure selftests pass at startup. Previously, selftests failed on the crypto_alloc_ahash() function since the associated algorithm was not yet registered. Fixes following error: ... [ 18.375811] alg: self-tests for authenc(hmac(sha1),cbc(aes)) using authenc(hmac(sha1-eip93),cbc(aes-eip93)) failed (rc=-2) [ 18.382140] alg: self-tests for authenc(hmac(sha224),rfc3686(ctr(aes))) using authenc(hmac(sha224-eip93),rfc3686(ctr(aes-eip93))) failed (rc=-2) [ 18.395029] alg: aead: authenc(hmac(sha256-eip93),cbc(des-eip93)) setkey failed on test vector 0; expected_error=0, actual_error=-2, flags=0x1 [ 18.409734] alg: aead: authenc(hmac(md5-eip93),cbc(des3_ede-eip93)) setkey failed on test vector 0; expected_error=0, actual_error=-2, flags=0x1 ... Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 69a26b96f04567e098eac8cf0daf701730493139 Author: Ethan Tidmore Date: Thu Feb 26 10:38:36 2026 -0600 drm/sun4i: Fix resource leaks [ Upstream commit 127367ad2e0f4870de60c6d719ae82ecf68d674c ] Three clocks are not being released in devm_regmap_init_mmio() error path. Add proper goto and set ret to the error code. Fixes: 8270249fbeaf0 ("drm/sun4i: backend: Create regmap after access is possible") Signed-off-by: Ethan Tidmore Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260226163836.10335-1-ethantidmore06@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 3f3bc812e91ad3a05b341ac51b636351e46651c7 Author: Maíra Canal Date: Fri Mar 6 08:30:33 2026 -0300 drm/v3d: Handle error from drm_sched_entity_init() [ Upstream commit 8cf1bec37b27846ad3169744c9f1a89a06dcb3fa ] drm_sched_entity_init() can fail but its return value is currently being ignored in v3d_open(). Check the return value and properly unwind on failure by destroying any already-initialized scheduler entities. Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260306-v3d-reset-locking-improv-v3-1-49864fe00692@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit a01d904fee652e003605de086ba8ac9f3338f775 Author: David Carlier Date: Fri Mar 13 05:17:55 2026 +0000 selftests/sched_ext: Add missing error check for exit__load() [ Upstream commit 1d02346fec8d13b05e54296ddc6ae29b7e1067df ] exit__load(skel) was called without checking its return value. Every other test in the suite wraps the load call with SCX_FAIL_IF(). Add the missing check to be consistent with the rest of the test suite. Fixes: a5db7817af78 ("sched_ext: Add selftests") Signed-off-by: David Carlier Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 39dda24962b2599bf29d2e67d9673f31bc9f40bf Author: Pei Xiao Date: Thu Mar 12 10:47:55 2026 +0800 spi: atcspi200: fix mutex initialization order [ Upstream commit 869d5b4b2a8012f6ef6058a1055cac6922c2cb55 ] The atcspi_exec_mem_op() function may call mutex_lock() on the driver's mutex before it is properly initialized if a SPI memory operation is initiated immediately after devm_spi_register_controller() is called. The mutex initialization currently occurs after the controller registration, which leaves a window where the mutex could be used uninitialized. Move the mutex initialization to the beginning of the probe function, before any registration or resource allocation. Fixes: 34e3815ea459 ("spi: atcspi200: Add ATCSPI200 SPI controller driver") Signed-off-by: Pei Xiao Link: https://patch.msgid.link/15a71241affc25108a97d40d9d3dd1bc3d2d69ed.1773282905.git.xiaopei01@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5f1844d224bf23a33a65a5fc21473e59b1151843 Author: Lijo Lazar Date: Mon Mar 9 15:17:00 2026 +0530 drm/amd/pm: Fix xgmi max speed reporting [ Upstream commit da16822ce5c32b5aca848eaea521936d4410d48c ] Fix XGMI max bitrate/width reporting on SMUv13.0.12 SOCs. The data format got changed when moved to static table from dynamic metrics table. Fixes: 1bec2f270766 ("drm/amd/pm: Fetch SMUv13.0.12 xgmi max speed/width") Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0b13013e96c29169a9c0f594ec4e292601a0a271 Author: Geert Uytterhoeven Date: Tue Jan 27 20:10:09 2026 +0100 media: synopsys: VIDEO_DW_MIPI_CSI2RX should depend on ARCH_ROCKCHIP [ Upstream commit 942435a62d67035394340cfcbaa534145d638bf0 ] The Synopsys DesignWare MIPI CSI-2 Receiver is currently only supported on Rockchip RK3568 SoCs. Hence add a dependency on ARCH_ROCKCHIP, to prevent asking the user about this driver when configuring a kernel without Rockchip platform support. The dependency can be relaxed later, when adding support for appropriate SoCs from other vendors (if any). Fixes: 355a110040665e43 ("media: synopsys: add driver for the designware mipi csi-2 receiver") Signed-off-by: Geert Uytterhoeven Acked-by: Michael Riesch Reviewed-by: Frank Li Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1f511bbc5ff4aa51176e8c6b29eef84f93a69c36 Author: Vladimir Zapolskiy Date: Thu Feb 26 15:37:34 2026 +0200 media: i2c: og01a1b: Fix V4L2 subdevice data initialization on probe [ Upstream commit 535b7f106991c7d8f0e5b8e1769bfb8b1ce9d3d6 ] It's necessary to finalize the camera sensor subdevice initialization on driver probe and clean V4L2 subdevice data up on error paths and driver removal. The change fixes a previously reported by v4l2-compliance issue of the failed VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT test: fail: v4l2-test-controls.cpp(1104): subscribe event for control 'User Controls' failed Fixes: 472377febf84 ("media: Add a driver for the og01a1b camera sensor") Signed-off-by: Vladimir Zapolskiy Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6a0afc792d620249baa1d31608c61da89fdd6349 Author: Felix Gu Date: Sat Mar 7 15:47:15 2026 +0800 spi: axiado: Remove redundant pm_runtime_mark_last_busy() call [ Upstream commit ec6c2e15a42fc8fb63baadee0e8a3257e37fa90c ] The pm_runtime_mark_last_busy() call is redundant in the probe function as pm_runtime_put_autosuspend() already calls pm_runtime_mark_last_busy() internally to update the last access time of the device before queuing autosuspend. Fixes: e75a6b00ad79 ("spi: axiado: Add driver for Axiado SPI DB controller") Signed-off-by: Felix Gu Signed-off-by: Mark Brown Link: https://patch.msgid.link/20260307-axiado-1-v1-1-e90aa1b6dd9b@gmail.com Signed-off-by: Sasha Levin commit 14da5ae4f92585d612682443cb0da7bbcb328e92 Author: Felix Gu Date: Wed Mar 4 20:47:21 2026 +0800 spi: fsl-qspi: Use reinit_completion() for repeated operations [ Upstream commit 981b080a79724738882b0af1c5bb7ade30d94f24 ] The driver currently calls init_completion() during every spi_mem_op. Tchnically it may work, but it's not the recommended pattern. According to the kernel documentation: Calling init_completion() on the same completion object twice is most likely a bug as it re-initializes the queue to an empty queue and enqueued tasks could get "lost" - use reinit_completion() in that case, but be aware of other races. So moves the initial initialization to probe function and uses reinit_completion() for subsequent operations. Fixes: 84d043185dbe ("spi: Add a driver for the Freescale/NXP QuadSPI controller") Signed-off-by: Felix Gu Reviewed-by: Haibo Chen Link: https://patch.msgid.link/20260304-spi-nxp-v2-3-cd7d7726a27e@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 67e802dc7011f349aa51c2ae999dbf3bed8d7a63 Author: Felix Gu Date: Wed Mar 4 20:47:20 2026 +0800 spi: nxp-fspi: Use reinit_completion() for repeated operations [ Upstream commit 68c8c93fdb0de7e528dc3dfb1d17eb0f652259b8 ] The driver currently calls init_completion() during every spi_mem_op. Tchnically it may work, but it's not the recommended pattern. According to the kernel documentation: Calling init_completion() on the same completion object twice is most likely a bug as it re-initializes the queue to an empty queue and enqueued tasks could get "lost" - use reinit_completion() in that case, but be aware of other races. So moves the initial initialization to probe function and uses reinit_completion() for subsequent operations. Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller") Signed-off-by: Felix Gu Reviewed-by: Haibo Chen Link: https://patch.msgid.link/20260304-spi-nxp-v2-2-cd7d7726a27e@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7336060f68b1c462945a7bc722fd8981dfc1ca41 Author: Felix Gu Date: Wed Mar 4 20:47:19 2026 +0800 spi: nxp-xspi: Use reinit_completion() for repeated operations [ Upstream commit 40f9bc646db5aa89fb85f2cda1e55a2bf9d6a30c ] The driver currently calls init_completion() during every spi_mem_op. Tchnically it may work, but it's not the recommended pattern. According to the kernel documentation: Calling init_completion() on the same completion object twice is most likely a bug as it re-initializes the queue to an empty queue and enqueued tasks could get "lost" - use reinit_completion() in that case, but be aware of other races. So moves the initial initialization to probe function and uses reinit_completion() for subsequent operations. Fixes: 29c8c00d9f9d ("spi: add driver for NXP XSPI controller") Reviewed-by: Haibo Chen Signed-off-by: Felix Gu Link: https://patch.msgid.link/20260304-spi-nxp-v2-1-cd7d7726a27e@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5005424b0235fa358247f961d784ba02231ae5fa Author: Harikrishna Shenoy Date: Tue Dec 9 17:33:29 2025 +0530 drm/bridge: cadence: cdns-mhdp8546-core: Handle HDCP state in bridge atomic check [ Upstream commit 4a8edd658489ec2a3d7e20482fa9e8d366153d8d ] Now that we have DRM_BRIDGE_ATTACH_NO_CONNECTOR framework, handle the HDCP state change in bridge atomic check as well to enable correct functioning for HDCP in both DRM_BRIDGE_ATTACH_NO_CONNECTOR and !DRM_BRIDGE_ATTACH_NO_CONNECTOR case. Without this patch, when using DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, HDCP state changes would not be properly handled during atomic commits, potentially leading to HDCP authentication failures or incorrect protection status for content requiring HDCP encryption. Fixes: 6a3608eae6d33 ("drm: bridge: cdns-mhdp8546: Enable HDCP") Signed-off-by: Harikrishna Shenoy Reviewed-by: Luca Ceresoli Reviewed-by: Tomi Valkeinen Link: https://patch.msgid.link/20251209120332.3559893-4-h-shenoy@ti.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit 8efb51ca94603429910def88aa3598e14ec3d637 Author: Jayesh Choudhary Date: Tue Dec 9 17:33:28 2025 +0530 drm/bridge: cadence: cdns-mhdp8546-core: Add mode_valid hook to drm_bridge_funcs [ Upstream commit 6dbff34016052b099558b76632e4983e2df13fed ] Add cdns_mhdp_bridge_mode_valid() to check if specific mode is valid for this bridge or not. In the legacy usecase with !DRM_BRIDGE_ATTACH_NO_CONNECTOR we were using the hook from drm_connector_helper_funcs but with DRM_BRIDGE_ATTACH_NO_CONNECTOR we need to have mode_valid() in drm_bridge_funcs. Without this patch, when using DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, the cdns_mhdp_bandwidth_ok() function would not be called during mode validation, potentially allowing modes that exceed the bridge's bandwidth capabilities to be incorrectly marked as valid. Fixes: c932ced6b585 ("drm/tidss: Update encoder/bridge chain connect model") Reviewed-by: Tomi Valkeinen Signed-off-by: Jayesh Choudhary Signed-off-by: Harikrishna Shenoy Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20251209120332.3559893-3-h-shenoy@ti.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit 1af3b42e08a957e53bab8e1897393fe0a27d9fbf Author: Jayesh Choudhary Date: Tue Dec 9 17:33:27 2025 +0530 drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomic_enable() [ Upstream commit 43d6508ddbf9fb974fbc359a033154f78c9d4c8b ] In case if we get errors in cdns_mhdp_link_up() or cdns_mhdp_reg_read() in atomic_enable, we will go to cdns_mhdp_modeset_retry_fn() and will hit NULL pointer while trying to access the mutex. We need the connector to be set before that. Unlike in legacy cases with flag !DRM_BRIDGE_ATTACH_NO_CONNECTOR, we do not have connector initialised in bridge_attach(), so add the mhdp->connector_ptr in device structure to handle both cases with DRM_BRIDGE_ATTACH_NO_CONNECTOR and !DRM_BRIDGE_ATTACH_NO_CONNECTOR, set it in atomic_enable() earlier to avoid possible NULL pointer dereference in recovery paths like modeset_retry_fn() with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set. Fixes: c932ced6b585 ("drm/tidss: Update encoder/bridge chain connect model") Signed-off-by: Jayesh Choudhary Signed-off-by: Harikrishna Shenoy Reviewed-by: Luca Ceresoli Reviewed-by: Tomi Valkeinen Link: https://patch.msgid.link/20251209120332.3559893-2-h-shenoy@ti.com Signed-off-by: Luca Ceresoli Signed-off-by: Sasha Levin commit 9a9a284a81f2dc1e6215266a25975492b43455ff Author: Randy Dunlap Date: Fri Mar 6 14:10:32 2026 -0800 iopoll: fix function parameter names in read_poll_timeout_atomic() [ Upstream commit 878004e2852bc22ce0687c5597d6fe3909fb59f3 ] Correct the function parameter names to avoid kernel-doc warnings and to emphasize this function is atomic (non-sleeping). Warning: include/linux/iopoll.h:169 function parameter 'sleep_us' not described in 'read_poll_timeout_atomic' Warning: ../include/linux/iopoll.h:169 function parameter 'sleep_before_read' not described in 'read_poll_timeout_atomic' Fixes: 9df8043a546d ("iopoll: Generalize read_poll_timeout() into poll_timeout_us()") Signed-off-by: Randy Dunlap Reviewed-by: Jani Nikula Link: https://patch.msgid.link/20260306221033.2357305-1-rdunlap@infradead.org Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 4ec8323b9f0764a14d532b1ae9b87f8a9fecb867 Author: Junrui Luo Date: Thu Mar 5 20:05:48 2026 +0800 dm log: fix out-of-bounds write due to region_count overflow [ Upstream commit c20e36b7631d83e7535877f08af8b0af72c44b1a ] The local variable region_count in create_log_context() is declared as unsigned int (32-bit), but dm_sector_div_up() returns sector_t (64-bit). When a device-mapper target has a sufficiently large ti->len with a small region_size, the division result can exceed UINT_MAX. The truncated value is then used to calculate bitset_size, causing clean_bits, sync_bits, and recovering_bits to be allocated far smaller than needed for the actual number of regions. Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) use region indices derived from the full untruncated region space, causing out-of-bounds writes to kernel heap memory allocated by vmalloc. This can be reproduced by creating a mirror target whose region_count overflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0' The status output confirms the truncation (sync_count=1 instead of 4294967297, because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ... This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive fault but reboot is needed! Fix by widening the local region_count to sector_t and adding an explicit overflow check before the value is assigned to lc->region_count. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang Signed-off-by: Junrui Luo Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 4311ca59a1891d33c4c8b7946f98c34f167fe833 Author: Ming-Hung Tsai Date: Wed Mar 4 19:56:28 2026 +0800 dm cache metadata: fix memory leak on metadata abort retry [ Upstream commit 044ca491d4086dc5bf233e9fcb71db52df32f633 ] When failing to acquire the root_lock in dm_cache_metadata_abort because the block_manager is read-only, the temporary block_manager created outside the root_lock is not properly released, causing a memory leak. Reproduce steps: This can be reproduced by reloading a new table while the metadata is read-only. While the second call to dm_cache_metadata_abort is caused by lack of support for table preload in dm-cache, mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), it exposes the memory leak in dm_cache_metadata_abort when the function is called multiple times. Specifically, dm-cache fails to sync the new cache object's mode during preresume, creating the reproducer condition. This issue could also occur through concurrent metadata_operation_failed calls due to races in cache mode updates, but the table preload scenario below provides a reliable reproducer. 1. Create a cache device with some faulty trailing metadata blocks dmsetup create cmeta < unreferenced object 0xffff8880080c2010 (size 16): comm "dmsetup", pid 132, jiffies 4294982580 hex dump (first 16 bytes): 00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ... backtrace (crc 3118f31c): kmemleak_alloc+0x28/0x40 __kmalloc_cache_noprof+0x3d9/0x510 dm_block_manager_create+0x51/0x140 dm_cache_metadata_abort+0x85/0x320 metadata_operation_failed+0x103/0x1e0 cache_preresume+0xacd/0xe70 dm_table_resume_targets+0xd3/0x320 __dm_resume+0x1b/0xf0 dm_resume+0x127/0x170 Fixes: 352b837a5541 ("dm cache: Fix ABBA deadlock between shrink_slab and dm_cache_metadata_abort") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit ece450a5ee81f254431ed7ae97684b899a8b030e Author: Manivannan Sadhasivam Date: Thu Feb 26 19:09:51 2026 +0530 PCI: dwc: Perform cleanup in the error path of dw_pcie_resume_noirq() [ Upstream commit edb5ca3262e2255cf938a5948709d3472d4871ad ] If the dw_pcie_resume_noirq() API fails, it just returns the errno without doing cleanup in the error path, leading to resource leak. So perform cleanup in the error path. Fixes: 4774faf854f5 ("PCI: dwc: Implement generic suspend/resume functionality") Reported-by: Senchuan Zhang Closes: https://lore.kernel.org/linux-pci/78296255.3869.19c8eb694d6.Coremail.zhangsenchuan@eswincomputing.com Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260226133951.296743-1-mani@kernel.org Signed-off-by: Sasha Levin commit 70fc9134b5f07040cdd80702e8ac82f182b72d8a Author: Aksh Garg Date: Tue Feb 24 14:08:17 2026 +0530 PCI: dwc: ep: Mirror the max link width and speed fields to all functions [ Upstream commit 94cbea0f636b55602a9a10583670976680ecea67 ] PCIe r7.0, section 7.5.3.6 states that for multi-function devices, the Max Link Width and Max Link Speed fields in the Link Capabilities Register must report the same values for all functions. Currently, dw_pcie_setup() programs these fields only for Function 0 via dw_pcie_link_set_max_speed() and dw_pcie_link_set_max_link_width(). For multi-function endpoint configurations, Function 1 and beyond retain their default values, violating the PCIe specification. Fix this by reading the Max Link Width and Max Link Speed fields from Link Capabilities Register of Function 0 after dw_pcie_setup() completes, then mirroring these values to all other functions. Fixes: 24ede430fa49 ("PCI: designware-ep: Add multiple PFs support for DWC") Fixes: 89db0793c9f2 ("PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling") Signed-off-by: Aksh Garg [mani: renamed ref_lnkcap to func0_lnkcap] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260224083817.916782-3-a-garg7@ti.com Signed-off-by: Sasha Levin commit 2579d2db9cfa3c9e31153a87e3eef712ed4e7264 Author: Aksh Garg Date: Tue Feb 24 14:08:16 2026 +0530 PCI: dwc: ep: Fix MSI-X Table Size configuration in dw_pcie_ep_set_msix() [ Upstream commit 271d0b1f058ae9815e75233d04b23e3558c3e4f4 ] In dw_pcie_ep_set_msix(), while updating the MSI-X Table Size value for individual functions, Message Control register is read from the passed function number register space using dw_pcie_ep_readw_dbi(), but always written back to the Function 0's register space using dw_pcie_writew_dbi(). This causes incorrect MSI-X configuration for the rest of the functions, other than Function 0. Fix this by using dw_pcie_ep_writew_dbi() to write to the correct function's register space, matching the read operation. Fixes: 70fa02ca1446 ("PCI: dwc: Add dw_pcie_ep_{read,write}_dbi[2] helpers") Signed-off-by: Aksh Garg [mani: commit log] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260224083817.916782-2-a-garg7@ti.com Signed-off-by: Sasha Levin commit f598c2580138e4390270ebefb08c61b2bb75142d Author: Alexandre Courbot Date: Fri Mar 6 13:52:46 2026 +0900 gpu: nova-core: firmware: fix and explain v2 header offsets computations [ Upstream commit 17d7c97f73c7a0bd90bd22cd7441269a6f8a1d72 ] There are no offsets in `FalconUCodeDescV2` to give the non-secure and secure IMEM sections start offsets relative to the beginning of the firmware object. The start offsets for both sections were set to `0`, but that is obviously incorrect since two different sections cannot start at the same offset. Since these offsets were not used by the bootloader, this doesn't prevent proper function but is incorrect nonetheless. Fix this by computing the start of the secure IMEM section relatively to the start of the firmware object and setting it properly. Also add and improve comments to explain how the values are obtained. Fixes: dbfb5aa41f16 ("gpu: nova-core: add FalconUCodeDescV2 support") Reviewed-by: Eliot Courtney Link: https://patch.msgid.link/20260306-turing_prep-v11-9-8f0042c5d026@nvidia.com Signed-off-by: Alexandre Courbot Signed-off-by: Sasha Levin commit a8efb5d27c59c84890e3b32e668c319a45b9ff94 Author: Alexandre Courbot Date: Fri Mar 6 13:52:40 2026 +0900 gpu: nova-core: falcon: rename load parameters to reflect DMA dependency [ Upstream commit 8a623869b8269dbf52d52711cd7b9355044b6b53 ] The current `FalconLoadParams` and `FalconLoadTarget` types are fit for DMA loading, but not so much for PIO loading which will require its own types. Start by renaming them to something that indicates that they are indeed DMA-related. Reviewed-by: Eliot Courtney Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260306-turing_prep-v11-3-8f0042c5d026@nvidia.com [acourbot@nvidia.com: fixup order of import items.] Signed-off-by: Alexandre Courbot Stable-dep-of: 17d7c97f73c7 ("gpu: nova-core: firmware: fix and explain v2 header offsets computations") Signed-off-by: Sasha Levin commit 1303afda3439beebafdfc95e8ea9698d542174de Author: Alexandre Courbot Date: Fri Mar 6 13:52:38 2026 +0900 gpu: nova-core: create falcon firmware DMA objects lazily [ Upstream commit bc9de9e1af2f05461460e1b215a6d209ee62d65a ] When DMA was the only loading option for falcon firmwares, we decided to store them in DMA objects as soon as they were loaded from disk and patch them in-place to avoid having to do an extra copy. This decision complicates the PIO loading patch considerably, and actually does not even stand on its own when put into perspective with the fact that it requires 8 unsafe statements in the code that wouldn't exist if we stored the firmware into a `KVVec` and copied it into a DMA object at the last minute. The cost of the copy is, as can be expected, imperceptible at runtime. Thus, switch to a lazy DMA object creation model and simplify our code a bit. This will also have the nice side-effect of being more fit for PIO loading. Reviewed-by: Eliot Courtney Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260306-turing_prep-v11-1-8f0042c5d026@nvidia.com [acourbot@nvidia.com: add TODO item to switch back to a coherent allocation when it becomes convenient to do so.] Signed-off-by: Alexandre Courbot Stable-dep-of: 17d7c97f73c7 ("gpu: nova-core: firmware: fix and explain v2 header offsets computations") Signed-off-by: Sasha Levin commit 4b7204bfedc92b3819967c087f1f7073c39e3f21 Author: Joel Fernandes Date: Mon Jan 26 15:23:01 2026 -0500 gpu: nova-core: use checked arithmetic in FWSEC firmware parsing [ Upstream commit 0568b376a0b13da6582bce1f2e2bbb2eae7fc266 ] Use checked_add() and checked_mul() when computing offsets from firmware-provided values in new_fwsec(). Without checked arithmetic, corrupt firmware could cause integer overflow. The danger is not just wrapping to a huge value, but potentially wrapping to a small plausible offset that passes validation yet accesses entirely wrong data, causing silent corruption or security issues. Reviewed-by: Zhi Wang Signed-off-by: Joel Fernandes Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260126202305.2526618-2-joelagnelf@nvidia.com [acourbot@nvidia.com: rewrap commit message to make checkpatch happy.] [acourbot@nvidia.com: add missing empty lines after new code blocks.] [acourbot@nvidia.com: move SAFETY comments to the unsafe statement they describe.] [acourbot@nvidia.com: remove obvious computation comments and use `CALC:` for the remaining ones.] Signed-off-by: Alexandre Courbot Stable-dep-of: 17d7c97f73c7 ("gpu: nova-core: firmware: fix and explain v2 header offsets computations") Signed-off-by: Sasha Levin commit 6110d99cf74b89849c2d489fb039853c1aaeb063 Author: Rafael J. Wysocki Date: Thu Mar 5 20:47:03 2026 +0100 platform/chrome: chromeos_tbmc: Drop wakeup source on remove [ Upstream commit 5d441a4bc93642ed6f41da87327a39946b4e1455 ] The wakeup source added by device_init_wakeup() in chromeos_tbmc_add() needs to be dropped during driver removal, so add a .remove() callback to the driver for this purpose. Fixes: 0144c00ed86b ("platform/chrome: chromeos_tbmc: Report wake events") Signed-off-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/6151957.MhkbZ0Pkbq@rafael.j.wysocki Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 020b8fe443433004c5a3e8be6c34c7fc61415650 Author: Philip Yang Date: Thu Feb 26 15:15:51 2026 -0500 drm/amdgpu: GFX12.1 scratch memory limit up to 57-bit [ Upstream commit b2d13a41da94008fdd3786b396a6375c12454522 ] The scratch aperture or gmc private aperture in flat memory contains 57 bits of data on gfx v12.1.0 compared to the 32 bits from previous. Add new helper kfd_init_apertures_v12 for gfx version >= v12.1.0 which supports 57-bit VA space. v2: - update pdd->scratch_limit (Yu, Lang) - update fixes tag (Felix Kuehling) - add helper kfd_init_apertures_v12 Fixes: db1882b3ff0c ("drm/amdkfd: Update LDS, Scratch base for 57bit address") Signed-off-by: Philip Yang Reviewed-by: Lang Yu Acked-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9c98072b90ea590ea35d55bcf4d051a295079bf4 Author: Huan He Date: Thu Feb 26 17:26:14 2026 +0800 dt-bindings: mmc: dwcmshc-sdhci: Fix resets array validation [ Upstream commit 5f7ac24ba232180caf77e9ddd6ccad61b9948706 ] The binding defines tuple-style reset-names items for some compatibles, which implicitly enforces a fixed array length via JSON Schema. Defining global maxItems for resets and reset-names causes these constraints to be intersected via allOf, resulting in an effective minItems equal to the global maxItems. This leads to dtbs_check failures reporting reset arrays as too short, even when the DTS provides the correct number of entries. Fixes: 30009a21f257 ("dt-bindings: mmc: sdhci-of-dwcmshc: Add Eswin EIC7700") Co-developed-by: Pritesh Patel Signed-off-by: Pritesh Patel Signed-off-by: Huan He Acked-by: Conor Dooley Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit d8f3d78ca63cacfe3d8c117023dff3c8f0e9a846 Author: Kees Cook Date: Wed Feb 25 09:47:03 2026 -0800 drm/amd/ras: Fix type size of remainder argument [ Upstream commit 9f3d543a9f7371622aff389e69010ac6bac69ef8 ] Forcing an int to be dereferenced at uint64_t for div64_u64_rem() runs the risk of endian confusion and stack overflowing writes. Seen while preparing to enable -Warray-bounds globally: In file included from ../arch/x86/include/asm/processor.h:35, from ../include/linux/sched.h:13, from ../include/linux/ratelimit.h:6, from ../include/linux/dev_printk.h:16, from ../drivers/gpu/drm/amd/amdgpu/../ras/ras_mgr/ras_sys.h:29, from ../drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras.h:27, from ../drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_core.c:24: In function 'div64_u64_rem', inlined from 'ras_core_convert_timestamp_to_time' at ../drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_core.c:72:9: ../include/linux/math64.h:56:20: error: array subscript 'u64 {aka long long unsigned int}[0]' is partly outside array bounds of 'int[1]' [-Werror=array-bounds=] 56 | *remainder = dividend % divisor; | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_core.c: In function 'ras_core_convert_timestamp_to_time': ../drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_core.c:70:19: note: object 'remaining_seconds' of size 4 70 | int days, remaining_seconds; | ^~~~~~~~~~~~~~~~~ Use a 64-bit type for the remainder calculation, but leave remaining_seconds as 32-bit to avoid 64-bit division later. The value of remainder will always be less than seconds_per_day, so there's no truncation risk. Fixes: ace232eff50e ("drm/amdgpu: Add ras module files into amdgpu") Signed-off-by: Kees Cook Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9ae5f147775b0eec00076039ab2cd3f7c4c55f30 Author: Benjamin Marzinski Date: Thu Feb 12 13:05:41 2026 -0500 dm-mpath: don't stop probing paths at presuspend [ Upstream commit 51d81e14fe6788dc6463064c7517480f2acd2724 ] Commit 5c977f102315 ("dm-mpath: Don't grab work_mutex while probing paths"), added code to make multipath quit probing paths early, if it was trying to suspend. This isn't necessary. It was just an optimization to try to keep path probing from delaying a suspend. However it causes problems with the intended user of this code, qemu. The path probing code was added because failed ioctls to multipath devices don't cause paths to fail in cases where a regular IO failure would. If an ioctl to a path failed because the path was down, and the multipath device had passed presuspend, the M_MPATH_PROBE_PATHS ioctl would exit early, without probing the path. The caller would then retry the original ioctl, hoping to use a different path. But if there was only one path in the pathgroup, it would pick the same non-working path again, even if there were working paths in other pathgroups. ioctls to a suspended dm device will return -EAGAIN, notifying the caller that the device is suspended, but ioctls to a device that is just preparing to suspend won't (and in general, shouldn't). This means that the caller (qemu in this case) would get into a tight loop where it would issue an ioctl that failed, skip probing the paths because the device had already passed presuspend, and start over issuing the ioctl again. This would continue until the multipath device finally fully suspended, or the caller gave up and failed the ioctl. multipath's path probing code could return -EAGAIN in this case, and the caller could delay a bit before retrying, but the whole purpose of skipping the probe after presuspend was to speed things up, and that would just slow them down. Instead, remove the is_suspending flag, and check dm_suspended() instead to decide whether to exit the probing code early. This means that when the probing code exits early, future ioctls will also be delayed, because the device is fully suspended. Fixes: 5c977f102315 ("dm-mpath: Don't grab work_mutex while probing paths") Signed-off-by: Benjamin Marzinski Reviewed-by: Martin Wilck Reviewed-by: Hanna Czenczek Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 01b22656d8a68dbeae59f8b80866e7b11936b20a Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:10 2026 +0800 dm cache: fix dirty mapping checking in passthrough mode switching [ Upstream commit 322586745bd1a0e5f3559fd1635fdeb4dbd1d6b8 ] As mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), dm-cache assumed table reload occurs after suspension, while LVM's table preload breaks this assumption. The dirty mapping check for passthrough mode was designed around this assumption and is performed during table creation, causing the check to fail with preload while metadata updates are ongoing. This risks loading dirty mappings into passthrough mode, resulting in data loss. Reproduce steps: 1. Create a writeback cache with zero migration_threshold to produce dirty mappings dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writeback smq \ 2 migration_threshold 0" 2. Preload a table in passthrough mode dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" 3. Write to the first cache block to make it dirty fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 4. Resume the inactive table. Now it's possible to load the dirty block into passthrough mode. dmsetup resume cache Fix by moving the checks to the preresume phase to support table preloading. Also remove the unused function dm_cache_metadata_all_clean. Fixes: 2ee57d587357 ("dm cache: add passthrough mode") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 21e6cd462ff67963a015e7476077c7cbbba7d498 Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:09 2026 +0800 dm cache: fix concurrent write failure in passthrough mode [ Upstream commit e4f66341779d0cf4c83c74793753a84094286d9e ] When bio prison cell lock acquisition fails due to concurrent writes to the same block in passthrough mode, dm-cache incorrectly returns an I/O error instead of properly handling the concurrency. This can occur in both process and workqueue contexts when invalidate_lock() is called for exclusive access to a data block. Fix this by deferring the write bios to ensure proper block device behavior. Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first cached block concurrently. Sometimes one of the processes will receive I/O errors. fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --numjobs=2 --size 64k fio-3.41 fio: io_u error on file /dev/mapper/cache: Input/output error: write offset=4096, buflen=4096 fio: pid=106, err=5/file:io_u.c:2008, func=io_u error, error=Input/output error test: (groupid=0, jobs=1): err= 0: pid=105 test: (groupid=0, jobs=1): err= 5 (file:io_u.c:2008, func=io_u error, error=Input/output error): pid=106 Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 2b62d0611c9af14a16bddf22df2612b4f40eb5a1 Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:08 2026 +0800 dm cache policy smq: fix missing locks in invalidating cache blocks [ Upstream commit 2d1f7b65f5deedd2e6b09fdc6ea27f8375f24b45 ] In passthrough mode, the policy invalidate_mapping operation is called simultaneously from multiple workers, thus it should be protected by a lock. Otherwise, we might end up with data races on the allocated blocks counter, or even use-after-free issues with internal data structures when doing concurrent writes. Note that the existing FIXME in smq_invalidate_mapping() doesn't affect passthrough mode since migration tasks don't exist there, but would need attention if supporting fast device shrinking via suspend/resume without target reloading. Reproduce steps: 1. Create a cache device consisting of 1024 cache entries dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Populate the cache, and record the number of cached blocks fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the passthrough cache. By setting multiple jobs with I/O size equal to the cache block size, cache blocks are invalidated concurrently from different workers. fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \ --direct=1 --numjobs=2 --randrepeat=0 --size=64m 5. Check if demoted matches cached block count. These numbers should match but may differ due to the data race. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted" Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 05798d091ebcfb6d68228890e593f209e8ac940d Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:07 2026 +0800 dm cache: fix write hang in passthrough mode [ Upstream commit 4ca8b8bd952df7c3ccdc68af9bd3419d0839a04b ] The invalidate_remove() function has incomplete logic for handling write hit bios after cache invalidation. It sets up the remapping for the overwrite_bio but then drops it immediately without submission, causing write operations to hang. Fix by adding a new invalidate_committed() continuation that submits the remapped writes to the cache origin after metadata commit completes, while using the overwrite_endio hook to ensure proper completion sequencing. This maintains existing coherency. Also improve error handling in invalidate_complete() to preserve the original error status instead of using bio_io_error() unconditionally. Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 2ed94c87759c618fd307fbaaccd4b13da37f512a Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:06 2026 +0800 dm cache: fix write path cache coherency in passthrough mode [ Upstream commit 0c5eef0aad508231d8e43ff8392692925e131b68 ] In passthrough mode, dm-cache defers write bio submission until cache invalidation completes to maintain existing coherency, requiring the target map function to return DM_MAPIO_SUBMITTED. The current map_bio() returns DM_MAPIO_REMAPPED, violating the required ordering constraint. Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into the cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first data block, and check io ordering using ftrace echo 1 > /sys/kernel/debug/tracing/events/block/block_bio_queue/enable echo 1 > /sys/kernel/debug/tracing/events/block/block_bio_complete/enable echo 1 > /sys/kernel/debug/tracing/events/block/block_rq_complete/enable fio --filename=/dev/mapper/cache --name=test --rw=write --bs=64k \ --direct=1 --size 64k 5. ftrace logs show that write operations to the cache origin (252:2) and metadata operations (252:0) are unsynchronized: the origin write occurs before metadata commit. fio-146 [000] ..... 420.139562: block_bio_queue: 252,3 WS 0 + 128 [fio] fio-146 [000] ..... 420.149395: block_bio_queue: 252,2 WS 0 + 128 [fio] fio-146 [000] ..... 420.149763: block_bio_queue: 8,32 WS 262144 + 128 [fio] fio-146 [000] dNh1. 420.151446: block_rq_complete: 8,32 WS () 262144 + 128 be,0,4 [0] fio-146 [000] dNh1. 420.152731: block_bio_complete: 252,2 WS 0 + 128 [0] fio-146 [000] dNh1. 420.154229: block_bio_complete: 252,3 WS 0 + 128 [0] kworker/0:0-9 [000] ..... 420.160530: block_bio_queue: 252,0 W 408 + 8 [kworker/0:0] kworker/0:0-9 [000] ..... 420.161641: block_bio_queue: 8,32 W 408 + 8 [kworker/0:0] kworker/0:0-9 [000] ..... 420.162533: block_bio_queue: 252,0 W 416 + 8 [kworker/0:0] kworker/0:0-9 [000] ..... 420.162821: block_bio_queue: 8,32 W 416 + 8 [kworker/0:0] Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit df3b8ef06cc62de4fca5d2108e285085b3cffd44 Author: Ming-Hung Tsai Date: Mon Feb 9 15:54:05 2026 +0800 dm cache: fix null-deref with concurrent writes in passthrough mode [ Upstream commit 7d1f98d668ee34c1d15bdc0420fdd062f24a27c0 ] In passthrough mode, when dm-cache starts to invalidate a cache entry and bio prison cell lock fails due to concurrent write to the same cached block, mg->cell remains NULL. The error path in invalidate_complete() attempts to unlock and free the cell unconditionally, causing a NULL pointer dereference: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPT RIP: 0010:dm_cell_unlock_v2+0x3f/0x210 Call Trace: invalidate_complete+0xef/0x430 map_bio+0x130f/0x1a10 cache_map+0x320/0x6b0 __map_bio+0x458/0x510 dm_submit_bio+0x40e/0x16d0 __submit_bio+0x419/0x870 Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first cached block concurrently fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --numjobs=2 --size 64k Fix by checking if mg->cell is valid before attempting to unlock it. Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 7422a11a753daacbc2409513cf65e1de0d17c291 Author: Sander Vanheule Date: Fri Feb 20 16:26:34 2026 +0100 ASoC: sti: use managed regmap_field allocations [ Upstream commit 1696fad8b259a2d46e51cd6e17e4bcdbe02279fa ] The regmap_field objects allocated at player init are never freed and may leak resources if the driver is removed. Switch to devm_regmap_field_alloc() to automatically limit the lifetime of the allocations the lifetime of the device. Fixes: 76c2145ded6b ("ASoC: sti: Add CPU DAI driver for playback") Signed-off-by: Sander Vanheule Link: https://patch.msgid.link/20260220152634.480766-3-sander@svanheule.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e5c1e7ef60d710be8a62498abd1f50a35b391fd9 Author: Sander Vanheule Date: Fri Feb 20 16:26:33 2026 +0100 ASoC: sti: Return errors from regmap_field_alloc() [ Upstream commit 272aabef50bc3fe58edd26de000f4cdd41bdbe60 ] When regmap_field_alloc() fails, it can return an error. Specifically, it will return PTR_ERR(-ENOMEM) when the allocation returns a NULL pointer. The code then uses these allocations with a simple NULL check: if (player->clk_sel) { // May dereference invalid pointer (-ENOMEM) err = regmap_field_write(player->clk_sel, ...); } Ensure initialization fails by forwarding the errors from regmap_field_alloc(), thus avoiding the use of the invalid pointers. Fixes: 76c2145ded6b ("ASoC: sti: Add CPU DAI driver for playback") Signed-off-by: Sander Vanheule Link: https://patch.msgid.link/20260220152634.480766-2-sander@svanheule.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c3195830c2c651f371ff0f525da95cdf4a6814bf Author: Aleksander Jan Bajkowski Date: Sun Feb 8 11:35:53 2026 +0100 crypto: inside-secure/eip93 - fix register definition [ Upstream commit b7abbc8c7acaeb60c114b038f1fa91bbedb3d16a ] Checked the register definitions with the documentation[1]. Turns out that the PKTE_INBUF_CNT register has a bad offset. It's used in Direct Host Mode (DHM). The driver uses Autonomous Ring Mode (ARM), so it causes no harm. 1. ADSP-SC58x/ADSP-2158x SHARC+ Processor Hardware Reference Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ce4bcd22f51354f97871d6f83ff2d47219e99509 Author: Charles Keepax Date: Wed Feb 25 14:01:16 2026 +0000 ASoC: SDCA: Update counting of SU/GE DAPM routes [ Upstream commit 1fb720d33eecdb9a90ee340b3000ba378d49f5ca ] Device Layer Selector Unit's are controlled by a Group Entity control rather than by the host directly. For the purposes of the ASoC class driver the number of input routes to the SU is controlled by the number of options within the Group Entity Selected Mode Control. ie. One valid DAPM route for each valid route defined in the Group Entity. Currently the code assumes that a Device Layer SU will have a number of routes equal to the number of potential sources for the SU. ie. it counts the routes using the SU, but then creates the routes using the GE. However, this isn't actually true, it is perfectly allowed for the GE to only define options for some of the potential sources of the SU.o In such a case the number of routes return will not match those created, leading to either an overflow of the routes array or undefined routes to be past to the ASoC core, both of which generally lead to the sound card failing to probe. Update the handling for the counting of routes to count the connected routes on the GE itself and then ignore the source routes on the SU. This makes it match the logic generating the routes and ensuring that both remain in sync. Fixes: 2c8b3a8e6aa8 ("ASoC: SDCA: Create DAPM widgets and routes from DisCo") Reviewed-by: Pierre-Louis Bossart Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260225140118.402695-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 55f1b6d2533b7fc316f15f8ed52ca6c2a79c4381 Author: Charles Keepax Date: Wed Feb 25 14:01:15 2026 +0000 ASoC: SDCA: Add default value for mipi-sdca-function-reset-max-delay [ Upstream commit 1bbbda5b178a1399339139eb3c326300008b72d6 ] Add a default value for the function reset timeout since version 1.0 of the SDCA specification doesn't actually include this property, it was added later. Fixes: 7b6be935e7ef ("ASoC: SDCA: Parse Function Reset max delay") Reviewed-by: Pierre-Louis Bossart Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260225140118.402695-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f57b6c5400bf642ce969263ef49dc8a3f36b6bba Author: Felix Gu Date: Sat Jan 24 23:42:45 2026 +0800 PCI: imx6: Fix device node reference leak in imx_pcie_probe() [ Upstream commit 3b55079d6387805ede687e234d84669aeb0f7e98 ] In imx_pcie_probe(), of_parse_phandle() returns the device node pointer with increased refcount. The pointer reference must be dropped by the caller when it's no longer needed. However, imx_pcie_probe() doesn't drop the reference, causing reference leak. Fix this by using the __free(device_node) cleanup handler to drop the reference when the function goes out of scope. Fixes: 1df82ec46600 ("PCI: imx: Add workaround for e10728, IMX7d PCIe PLL failure") Signed-off-by: Felix Gu [mani: commit log] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Acked-by: Richard Zhu Link: https://patch.msgid.link/20260124-pci_imx6-v2-1-acb8d5187683@gmail.com Signed-off-by: Sasha Levin commit a6805ca44884d20d6381a88d76d21a96704f4d1a Author: Andrew Martin Date: Mon Feb 23 16:08:16 2026 -0500 drm/amdkfd: Removed commented line for MQD queue priority [ Upstream commit bfe60e539cf7690a6739466b41fb6be250bb783e ] Missed deleting the commented line in the original patch. Fixes: 73463e26f7e2 ("drm/amdkfd: Disable MQD queue priority") Signed-off-by: Andrew Martin Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 13960a89a636ec85746409440afb9396438b3b13 Author: Eliot Courtney Date: Thu Jan 29 16:45:02 2026 +0900 gpu: nova-core: gsp: fix improper handling of empty slot in cmdq [ Upstream commit f64caf673cb5add9ac2065609a52049e2317c498 ] The current code hands out buffers that go all the way up to and including `rx - 1`, but we need to maintain an empty slot to prevent the ring buffer from wrapping around into having 'tx == rx', which means empty. Also add more rigorous no-panic proofs. Fixes: 75f6b1de8133 ("gpu: nova-core: gsp: Add GSP command queue bindings and handling") Signed-off-by: Eliot Courtney Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260129-nova-core-cmdq1-v3-4-2ede85493a27@nvidia.com Signed-off-by: Alexandre Courbot Signed-off-by: Sasha Levin commit 50f750250dadf443961b231050eac4bd65690555 Author: Eliot Courtney Date: Thu Jan 29 16:45:01 2026 +0900 gpu: nova-core: gsp: use empty slices instead of [0..0] ranges [ Upstream commit f6f072d8ef06ff5d29a6bb1bade3da29a1aafeec ] The current code unnecessarily uses, for example, &before_rx[0..0] to return an empty slice. Instead, just use an empty slice. Signed-off-by: Eliot Courtney Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260129-nova-core-cmdq1-v3-3-2ede85493a27@nvidia.com Signed-off-by: Alexandre Courbot Stable-dep-of: f64caf673cb5 ("gpu: nova-core: gsp: fix improper handling of empty slot in cmdq") Signed-off-by: Sasha Levin commit 221c5569401ca19c2b9fe7ac81af057baf5186a7 Author: Matt Roper Date: Mon Feb 23 16:11:33 2026 -0800 drm/xe/xe2_hpg: Drop invalid workaround Wa_15010599737 [ Upstream commit 1046bc7b416814833a43af8e66c52b0ea71c2021 ] Wa_15010599737 was a workaround originally proposed (and ultimately rejected) for DG2-G10. There's no record of it ever being relevant or even considered for any other platforms. The specific bit this workaround was setting is documented as "This bit should be set to 1 for the DX9 API and 0 for all other APIs" which means that it should almost always be left at the default value of 0 on Linux. The register itself is directly accessible from userspace, so in the special cases where it might be relevant (e.g., Wine/Proton running Windows DX9 apps), the userspace drivers already have the ability to change the setting without involvement of the kernel. Fixes: 7f3ee7d88058 ("drm/xe/xe2hpg: Add initial GT workarounds") Reviewed-by: Balasubramani Vivekanandan Link: https://patch.msgid.link/20260223-forupstream-wa_cleanup-v3-2-7f201eb2f172@intel.com Signed-off-by: Matt Roper Signed-off-by: Sasha Levin commit bb051b9d4ad87b8331c79eed4adcf2cda8787038 Author: Matt Roper Date: Fri Feb 20 09:27:39 2026 -0800 drm/xe: Consolidate workaround entries for Wa_14019386621 [ Upstream commit f0d6d356f8ac427d1f3eb8fb783a64ac3efd6fc7 ] Wa_14019386621 applies to all graphics versions from 20.01 through 20.04 (inclusive). Consolidate the RTP entries into a single range-based entry. Reviewed-by: Shuicheng Lin Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-17-b12005a05af6@intel.com Signed-off-by: Matt Roper Stable-dep-of: 1046bc7b4168 ("drm/xe/xe2_hpg: Drop invalid workaround Wa_15010599737") Signed-off-by: Sasha Levin commit 543aa42adee16f77ae6a9442d46be38645877c62 Author: Matt Roper Date: Fri Feb 20 09:27:38 2026 -0800 drm/xe: Consolidate workaround entries for Wa_14019877138 [ Upstream commit 55b19abb6c44db40fe1ebd01e9c16aa02c4cf663 ] Wa_14019877138 applies to all graphics versions from 12.55 through 20.04 (inclusive) that have a render engine. Consolidate the RTP entries into a single range-based entry. Note that the DG2 entry for this workaround was missing an ENGINE_CLASS(RENDER) rule; that mistake is fixed by this consolidation. Reviewed-by: Shuicheng Lin Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-16-b12005a05af6@intel.com Signed-off-by: Matt Roper Stable-dep-of: 1046bc7b4168 ("drm/xe/xe2_hpg: Drop invalid workaround Wa_15010599737") Signed-off-by: Sasha Levin commit e9bef62f1bb9fcb38223730657af20f4c6283c16 Author: Ethan Tidmore Date: Mon Feb 16 19:48:01 2026 -0600 drm/sun4i: backend: fix error pointer dereference [ Upstream commit 06277983eca4a31d3c2114fa33d99a6e82484b11 ] The function drm_atomic_get_plane_state() can return an error pointer and is not checked for it. Add error pointer check. Detected by Smatch: drivers/gpu/drm/sun4i/sun4i_backend.c:496 sun4i_backend_atomic_check() error: 'plane_state' dereferencing possible ERR_PTR() Fixes: 96180dde23b79 ("drm/sun4i: backend: Add a custom atomic_check for the frontend") Signed-off-by: Ethan Tidmore Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260217014801.60760-1-ethantidmore06@gmail.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 85c32772bc5157f4b638e570bd0a0d0f32046be4 Author: Jernej Skrabec Date: Wed Feb 18 19:34:54 2026 +0100 drm/sun4i: mixer: Fix layer init code [ Upstream commit 744629904c68bde847c31819f23482d09152f810 ] Code refactoring dropped extra NULL sentinel entry at the end of the drm planes array. Add it back. Reported-by: Chen-Yu Tsai Closes: https://lore.kernel.org/linux-sunxi/CAGb2v65wY2pF6sR+0JgnpLa4ysvjght5hAKDa1RUyo=zEKXreg@mail.gmail.com/ Fixes: 4fa45b04a47d ("drm/sun4i: layer: move num of planes calc out of layer code") Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260218183454.7881-1-jernej.skrabec@gmail.com [wens@kernel.org: Fix "Fixes" commit hash] Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 3c25587fbf8797b92090b064a6d239a873e55fb1 Author: Koichiro Den Date: Tue Feb 17 15:38:56 2026 +0900 PCI: endpoint: pci-ep-msi: Fix error unwind and prevent double alloc [ Upstream commit 1cba96c0a795124c3229293ed7b5b5765e66f259 ] pci_epf_alloc_doorbell() stores the allocated doorbell message array in epf->db_msg/epf->num_db before requesting MSI vectors. If MSI allocation fails, the array is freed but the EPF state may still point to freed memory. Clear epf->db_msg and epf->num_db on the MSI allocation failure path so that later cleanup cannot double-free the array and callers can retry allocation. Also return -EBUSY when doorbells have already been allocated to prevent leaking or overwriting an existing allocation. Fixes: 1c3b002c6bf6 ("PCI: endpoint: Add RC-to-EP doorbell support using platform MSI controller") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260217063856.3759713-4-den@valinux.co.jp Signed-off-by: Sasha Levin commit f33315de16590ff68f0850ae336483ea8bff6bd4 Author: Koichiro Den Date: Tue Feb 17 15:38:55 2026 +0900 PCI: endpoint: pci-epf-test: Don't free doorbell IRQ unless requested [ Upstream commit e81fa70179aac6ac3a6636565d5d35968dca3900 ] pci_epf_test_doorbell_cleanup() unconditionally calls free_irq() for the doorbell virq, which can trigger "Trying to free already-free IRQ" warnings when the IRQ was never requested or when request_threaded_irq() failed. Move free_irq() out of pci_epf_test_doorbell_cleanup() and invoke it only after a successful request, so that free_irq() is not called for an unrequested IRQ. Fixes: eff0c286aa91 ("PCI: endpoint: pci-epf-test: Add doorbell test support") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260217063856.3759713-3-den@valinux.co.jp Signed-off-by: Sasha Levin commit 917646aa08ccae1c6f9937c3a9597b7717fd11fd Author: Koichiro Den Date: Tue Feb 17 15:38:54 2026 +0900 PCI: endpoint: pci-epf-vntb: Fix MSI doorbell IRQ unwind [ Upstream commit cc04f2bfb9dae60b6e34d6bff75c26d4ec3237ce ] epf_ntb_db_bar_init_msi_doorbell() requests ntb->db_count doorbell IRQs and then performs additional MSI doorbell setup that may still fail. The error path unwinds the requested IRQs, but it uses a loop variable that is reused later in the function. When a later step fails, the unwind can run with an unexpected index value and leave some IRQs requested. Track the number of successfully requested IRQs separately and use that counter for the unwind so all previously requested IRQs are freed on failure. Fixes: dc693d606644 ("PCI: endpoint: pci-epf-vntb: Add MSI doorbell support") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20260217063856.3759713-2-den@valinux.co.jp Signed-off-by: Sasha Levin commit 769b8f19d3acbe9554f7edfd6d712bd2af1211d8 Author: George Abraham P Date: Fri Jan 9 10:59:23 2026 +0530 PCI/TPH: Allow TPH enable for RCiEPs [ Upstream commit d3e996a596967a62c8a13a279221513461f6ab97 ] Previously, pcie_enable_tph() only enabled TLP Processing Hints (TPH) if both the Endpoint and its Root Port advertised TPH support. Root Complex Integrated Endpoints (RCiEPs) are directly integrated into a Root Complex and do not have an associated Root Port, so pcie_enable_tph() never enabled TPH for RCiEPs. PCIe r7.0 doesn't seem to include a way to learn whether a Root Complex supports TPH, but sec 2.2.7.1.1 says Functions that lack TPH support should ignore TPH, and maybe the same is true for Root Complexes: A Function that does not support the TPH Completer or Routing capability and receives a transaction with the TH bit [which indicates the presence of TPH in the TLP header] Set is required to ignore the TH bit and handle the Request in the same way as Requests of the same transaction type without the TH bit Set. Allow drivers to enable TPH for any RCiEP with a TPH Requester Capability. Fixes: f69767a1ada3 ("PCI: Add TLP Processing Hints (TPH) support") Signed-off-by: George Abraham P [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260109052923.1170070-1-george.abraham.p@intel.com Signed-off-by: Sasha Levin commit 6501d9746f30faa92cac5ed16c5a9338e0ac67a6 Author: Kuninori Morimoto Date: Thu Feb 19 04:53:52 2026 +0000 ASoC: soc-compress: use function to clear symmetric params [ Upstream commit 07c774dd64ba0c605dbf844132122e3edbdbea93 ] Current soc-compress.c clears symmetric_rate, but it clears rate only, not clear other symmetric_channels/sample_bits. static int soc_compr_clean(...) { ... if (!snd_soc_dai_active(cpu_dai)) => cpu_dai->symmetric_rate = 0; if (!snd_soc_dai_active(codec_dai)) => codec_dai->symmetric_rate = 0; ... }; This feature was added when v3.7 kernel [1], and there was only symmetric_rate, no symmetric_channels/sample_bits in that timing. symmetric_channels/sample_bits were added in v3.14 [2], but I guess it didn't notice that soc-compress.c is updating symmetric_xxx. We are clearing symmetry_xxx by soc_pcm_set_dai_params(), but is soc-pcm.c local function. Makes it global function and clear symmetry_xxx by it. [1] commit 1245b7005de02 ("ASoC: add compress stream support") [2] commit 3635bf09a89cf ("ASoC: soc-pcm: add symmetry for channels and sample bits") Fixes: 3635bf09a89c ("ASoC: soc-pcm: add symmetry for channels and sample bits") Cc: Nicolin Chen Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/87ms15e3kv.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 87f5cb3f5124810998951239ee2a5fa01f5aa9dc Author: Val Packett Date: Wed Dec 10 12:39:23 2025 -0300 drm/virtio: Allow importing prime buffers when 3D is enabled [ Upstream commit df4dc947c46bb9f80038f52c6e38cb2d40c10e50 ] This functionality was added for using a KMS-only virtgpu with a physical (or SR-IOV) headless GPU in passthrough, but it should not be restricted to KMS-only mode. It can be used with cross-domain to pass guest memfds to the host compositor with zero copies (using udmabuf on both sides). Drop the check for the absence of virgl_3d to allow for more use cases. Fixes: ca77f27a2665 ("drm/virtio: Import prime buffers from other devices as guest blobs") Signed-off-by: Val Packett Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20251210154755.1119861-2-val@invisiblethingslab.com Signed-off-by: Sasha Levin commit 8efaa47a871662a8c21b819cec60786f7ef17ab4 Author: Maciej Patelczyk Date: Mon Feb 9 13:34:33 2026 +0100 drm/gpusvm: Fix unbalanced unlock in drm_gpusvm_scan_mm() [ Upstream commit d287dee565c3c32e1ed76ec1847af46809c29b90 ] There is a unbalanced lock/unlock to gpusvm notifier lock: [ 931.045868] ===================================== [ 931.046509] WARNING: bad unlock balance detected! [ 931.047149] 6.19.0-rc6+xe-**************** #9 Tainted: G U [ 931.048150] ------------------------------------- [ 931.048790] kworker/u5:0/51 is trying to release lock (&gpusvm->notifier_lock) at: [ 931.049801] [] drm_gpusvm_scan_mm+0x188/0x460 [drm_gpusvm_helper] [ 931.050802] but there are no more locks to release! [ 931.051463] The drm_gpusvm_notifier_unlock() sits under err_free label and the first jump to err_free is just before calling the drm_gpusvm_notifier_lock() causing unbalanced unlock. Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state") Signed-off-by: Maciej Patelczyk Cc: Thomas Hellström Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260209123433.1271053-1-maciej.patelczyk@intel.com Signed-off-by: Sasha Levin commit 1b6bc5bef00764858bf5f0ebd3ce2df964756d1b Author: Tvrtko Ursulin Date: Mon Jun 16 16:59:52 2025 +0100 dma-fence: Fix sparse warnings due __rcu annotations [ Upstream commit 62918542b7bf08860a60ebbde7654486e0ac0776 ] __rcu annotations on the return types from dma_fence_driver_name() and dma_fence_timeline_name() cause sparse to complain because both the constant signaled strings, and the strings return by the dma_fence_ops are not __rcu annotated. For a simple fix it is easiest to cast them with __rcu added and undo the smarts from the tracpoints side of things. There is no functional change since the rest is left in place. Later we can consider changing the dma_fence_ops return types too, and handle all the individual drivers which define them. Signed-off-by: Tvrtko Ursulin Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202506162214.1eA69hLe-lkp@intel.com/ Reviewed-by: Christian König Link: https://lore.kernel.org/r/20250616155952.24259-1-tvrtko.ursulin@igalia.com Signed-off-by: Christian König Signed-off-by: Sasha Levin commit 872d923b852705054bc099af663da862fdc1097d Author: Alexander Konyukhov Date: Tue Feb 3 16:48:46 2026 +0300 drm/komeda: fix integer overflow in AFBC framebuffer size check [ Upstream commit 779ec12c85c9e4547519e3903a371a3b26a289de ] The AFBC framebuffer size validation calculates the minimum required buffer size by adding the AFBC payload size to the framebuffer offset. This addition is performed without checking for integer overflow. If the addition oveflows, the size check may incorrectly succed and allow userspace to provide an undersized drm_gem_object, potentially leading to out-of-bounds memory access. Add usage of check_add_overflow() to safely compute the minimum required size and reject the framebuffer if an overflow is detected. This makes the AFBC size validation more robust against malformed. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 65ad2392dd6d ("drm/komeda: Added AFBC support for komeda driver") Signed-off-by: Alexander Konyukhov Acked-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://lore.kernel.org/r/20260203134907.1587067-1-Alexander.Konyukhov@kaspersky.com Signed-off-by: Sasha Levin commit d159493e1cb0d23cbce15d2e5ec9fe6b477bc886 Author: Yuwen Chen Date: Wed Jan 28 10:03:10 2026 +0800 selftests/futex: Fix incorrect result reporting of futex_requeue test item [ Upstream commit d317e2ef9dcf673c9f37cda784284af7c6812757 ] When using the TEST_HARNESS_MAIN macro definition to declare the main function, it is required to use the EXPECT*() and ASSERT*() macros in conjunction and not ksft_test_result_*(). Otherwise, even if a test item fails, the test will still return a success result because ksft_test_result_*() does not affect the test harness state. Convert the code to use EXPECT/ASSERT() variants, which ensures that the overall test result is fail if one of the EXPECT()s fails. [ tglx: Massaged change log to explain _why_ ksft_test_result*() is the wrong choice ] Fixes: f341a20f6d7e ("selftests/futex: Refactor futex_requeue with kselftest_harness.h") Signed-off-by: Yuwen Chen Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/tencent_51851B741CC4B5EC9C22AFF70BA82BB60805@qq.com Signed-off-by: Sasha Levin commit eaa8457e12df1ad002dbe9bca65ae16573268052 Author: Maíra Canal Date: Thu Jan 15 09:50:48 2026 -0300 drm/panel: ilitek-ili9882t: Select DRM_DISPLAY_DSC_HELPER [ Upstream commit 68e28facbc8ab3e701e1814323d397a75b400865 ] The panel-ilitek-ili9882t driver uses drm_dsc_pps_payload_pack() which is provided by the DRM_DISPLAY_DSC_HELPER. Add the missing Kconfig select to fix the following build error: ERROR: modpost: "drm_dsc_pps_payload_pack" [drivers/gpu/drm/panel/panel-ilitek-ili9882t.ko] undefined! Fixes: 65ce1f5834e9 ("drm/panel: ilitek-ili9882t: Switch Tianma TL121BVMS07 to DSC 120Hz mode") Reviewed-by: Neil Armstrong Tested-by: Nicolas Frattaroli Reviewed-by: Nicolas Frattaroli Link: https://patch.msgid.link/20260115125136.64866-1-mcanal@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit 2f3ed29e5beb0e6de088b7628b05f5dc893e9bdf Author: Lorenzo Bianconi Date: Sun Apr 12 10:43:26 2026 +0200 net: airoha: Add missing PPE configurations in airoha_ppe_hw_init() [ Upstream commit b9d8b856689d2b968495d79fe653d87fcb8ad98c ] Add the following PPE configuration in airoha_ppe_hw_init routine: - 6RD hw offloading is currently not supported by Netfilter flowtable. Disable explicitly PPE 6RD offloading in order to prevent PPE to learn 6RD flows and eventually interrupt the traffic. - Add missing PPE bind rate configuration for L3 and L2 traffic. PPE bind rate configuration specifies the pps threshold to move a PPE entry state from UNBIND to BIND. Without this configuration this value is random. - Set ageing thresholds to the values used in the vendor SDK in order to improve connection stability under load and avoid packet loss caused by fast aging. Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260412-airoha_ppe_hw_init-missing-bits-v1-1-06ac670819e3@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit dcc4d544fe8c1224f2e4bf38ef97d77cd6e92421 Author: Lorenzo Bianconi Date: Sun Apr 12 09:57:29 2026 +0200 net: airoha: Fix VIP configuration for AN7583 SoC [ Upstream commit 1acdfbdb516b32165a8ecd1d5f8c68e4eac64637 ] EN7581 and AN7583 SoCs have different VIP definitions. Introduce get_vip_port callback in airoha_eth_soc_data struct in order to take into account EN7581 and AN7583 VIP register layout and definition differences. Introduce nbq parameter in airoha_gdm_port struct. At the moment nbq is set statically to value previously used in airhoha_set_gdm2_loopback routine and it will be read from device tree in subsequent patches. Fixes: e4e5ce823bdd ("net: airoha: Add AN7583 SoC support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260412-airoha-7583-vip-fix-v1-1-c35e02b054bb@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ea690b3b6e58ae00979af8195b4cc24df466b65e Author: Jiayuan Chen Date: Sat Apr 11 08:55:19 2026 +0800 net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master [ Upstream commit 1921f91298d1388a0bb9db8f83800c998b649cb3 ] syzkaller reported a kernel panic in bond_rr_gen_slave_id() reached via xdp_master_redirect(). Full decoded trace: https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73 bond_rr_gen_slave_id() dereferences bond->rr_tx_counter, a per-CPU counter that bonding only allocates in bond_open() when the mode is round-robin. If the bond device was never brought up, rr_tx_counter stays NULL. The XDP redirect path can still reach that code on a bond that was never opened: bpf_master_redirect_enabled_key is a global static key, so as soon as any bond device has native XDP attached, the XDP_TX -> xdp_master_redirect() interception is enabled for every slave system-wide. The path xdp_master_redirect() -> bond_xdp_get_xmit_slave() -> bond_xdp_xmit_roundrobin_slave_get() -> bond_rr_gen_slave_id() then runs against a bond that has no rr_tx_counter and crashes. Fix this in the generic xdp_master_redirect() by refusing to call into the master's ->ndo_xdp_get_xmit_slave() when the master device is not up. IFF_UP is only set after ->ndo_open() has successfully returned, so this reliably excludes masters whose XDP state has not been fully initialized. Drop the frame with XDP_ABORTED so the exception is visible via trace_xdp_exception() rather than silently falling through. This is not specific to bonding: any current or future master that defers XDP state allocation to ->ndo_open() is protected. Fixes: 879af96ffd72 ("net, core: Add support for XDP redirection to slave device") Reported-by: syzbot+80e046b8da2820b6ba73@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/698f84c6.a70a0220.2c38d7.00cc.GAE@google.com/T/ Suggested-by: Daniel Borkmann Acked-by: Daniel Borkmann Signed-off-by: Jiayuan Chen Link: https://patch.msgid.link/20260411005524.201200-2-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a9a05e604803d9417077cdae9feeea8c497cb03c Author: Christian Brauner Date: Tue Mar 31 10:58:58 2026 +0200 selftests/namespaces: remove unused utils.h include from listns_efault_test [ Upstream commit cad3bf1c330274d11f25f1b7afae9b9dba13fbd3 ] Remove the inclusion of ../filesystems/utils.h from listns_efault_test.c. The test doesn't use any symbols from that header. Including it alongside ../pidfd/pidfd.h causes a build failure because both headers define wait_for_pid() with conflicting linkage: ../filesystems/utils.h: extern int wait_for_pid(pid_t pid); ../pidfd/pidfd.h: static inline int wait_for_pid(pid_t pid) All symbols the test actually uses (create_child, read_nointr, write_nointr, sys_pidfd_send_signal) come from pidfd.h. Reported-by: Mark Brown Link: https://lore.kernel.org/all/acPV19IY3Gna6Ira@sirena.org.uk Fixes: 07d7ad46dad4 ("selftests/namespaces: test for efault") Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 790093245e35040c2adb15f48970020425aa3f47 Author: Xin Long Date: Sun Apr 12 14:15:27 2026 -0400 sctp: disable BH before calling udp_tunnel_xmit_skb() [ Upstream commit 2cd7e6971fc2787408ceef17906ea152791448cf ] udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda ("add xmit recursion limit to tunnel xmit functions"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver Fixes: 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions") Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Link: https://patch.msgid.link/c874a8548221dcd56ff03c65ba75a74e6cf99119.1776017727.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 773ece4de79f0406836073d4fe44d087dbb934a6 Author: Xin Long Date: Sun Apr 12 14:13:51 2026 -0400 sctp: fix missing encap_port propagation for GSO fragments [ Upstream commit bf6f95ae3b8b2638c0e1d6d802d50983ce5d0f45 ] encap_port in SCTP_INPUT_CB(skb) is used by sctp_vtag_verify() for SCTP-over-UDP processing. In the GSO case, it is only set on the head skb, while fragment skbs leave it 0. This results in fragment skbs seeing encap_port == 0, breaking SCTP-over-UDP connections. Fix it by propagating encap_port from the head skb cb when initializing fragment skbs in sctp_inq_pop(). Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Link: https://patch.msgid.link/ea65ed61b3598d8b4940f0170b9aa1762307e6c3.1776017631.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3e45b1c2f3b2c87db070b650bd573c355c216f37 Author: Kuniyuki Iwashima Date: Fri Apr 10 23:53:27 2026 +0000 tcp: Don't set treq->req_usec_ts in cookie_tcp_reqsk_init(). [ Upstream commit c058bbf05b1197c33df7204842665bd8bc70b3a8 ] Commit de5626b95e13 ("tcp: Factorise cookie-independent fields initialisation in cookie_v[46]_check().") miscategorised tcp_rsk(req)->req_usec_ts init to cookie_tcp_reqsk_init(), which is used by both BPF/non-BPF SYN cookie reqsk. Rather, it should have been moved to cookie_tcp_reqsk_alloc() by commit 8e7bab6b9652 ("tcp: Factorise cookie-dependent fields initialisation in cookie_v[46]_check()") so that only non-BPF SYN cookie sets tcp_rsk(req)->req_usec_ts to false. Let's move the initialisation to cookie_tcp_reqsk_alloc() to respect bpf_tcp_req_attrs.usec_ts_ok. Fixes: e472f88891ab ("bpf: tcp: Support arbitrary SYN Cookie.") Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260410235328.1773449-1-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dd03fcffd3f1fbe7def71747935a5669f3e850ab Author: Gabriel Krisman Bertazi Date: Fri Apr 10 11:59:36 2026 -0400 udp: Force compute_score to always inline [ Upstream commit b80a95ccf1604a882bb153c45ccb4056e44c8edb ] Back in 2024 I reported a 7-12% regression on an iperf3 UDP loopback thoughput test that we traced to the extra overhead of calling compute_score on two places, introduced by commit f0ea27e7bfe1 ("udp: re-score reuseport groups when connected sockets are present"). At the time, I pointed out the overhead was caused by the multiple calls, associated with cpu-specific mitigations, and merged commit 50aee97d1511 ("udp: Avoid call to compute_score on multiple sites") to jump back explicitly, to force the rescore call in a single place. Recently though, we got another regression report against a newer distro version, which a team colleague traced back to the same root-cause. Turns out that once we updated to gcc-13, the compiler got smart enough to unroll the loop, undoing my previous mitigation. Let's bite the bullet and __always_inline compute_score on both ipv4 and ipv6 to prevent gcc from de-optimizing it again in the future. These functions are only called in two places each, udpX_lib_lookup1 and udpX_lib_lookup2, so the extra size shouldn't be a problem and it is hot enough to be very visible in profilings. In fact, with gcc13, forcing the inline will prevent gcc from unrolling the fix from commit 50aee97d1511, so we don't end up increasing udpX_lib_lookup2 at all. I haven't recollected the results myself, as I don't have access to the machine at the moment. But the same colleague reported 4.67% inprovement with this patch in the loopback benchmark, solving the regression report within noise margins. Eric Dumazet reported no size change to vmlinux when built with clang. I report the same also with gcc-13: scripts/bloat-o-meter vmlinux vmlinux-inline add/remove: 0/2 grow/shrink: 4/0 up/down: 616/-416 (200) Function old new delta udp6_lib_lookup2 762 949 +187 __udp6_lib_lookup 810 975 +165 udp4_lib_lookup2 757 906 +149 __udp4_lib_lookup 871 986 +115 __pfx_compute_score 32 - -32 compute_score 384 - -384 Total: Before=35011784, After=35011984, chg +0.00% Fixes: 50aee97d1511 ("udp: Avoid call to compute_score on multiple sites") Reviewed-by: Eric Dumazet Acked-by: Willem de Bruijn Signed-off-by: Gabriel Krisman Bertazi Link: https://patch.msgid.link/20260410155936.654915-1-krisman@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ca8a1c109bc1e81c08995f5389691e9a0f62916d Author: Maxime Chevallier Date: Fri Apr 10 19:10:20 2026 +0200 net: phy: qcom: at803x: Use the correct bit to disable extended next page [ Upstream commit e7a62edd34b1b4bc5f979988efc2f81c075733fd ] As noted in the blamed commit, the AR8035 and other PHYs from this family advertise the Extended Next Page support by default, which may be understood by some partners as this PHY being multi-gig capable. The fix is to disable XNP advertising, which is done by setting bit 12 of the Auto-Negotiation Advertisement Register (MII_ADVERTISE). The blamed commit incorrectly uses MDIO_AN_CTRL1_XNP, which is bit 13 as per 802.3 : 45.2.7.1 AN control register (Register 7.0) BIT 12 in MII_ADVERTISE is wrapped by ADVERTISE_RESV, used by some drivers such as the aquantia one. 802.3 Clause 28 defines bit 12 as Extended Next Page ability, at least in recent versions of the standard. Let's add a define for it and use it in the at803x driver. Fixes: 3c51fa5d2afe ("net: phy: ar803x: disable extended next page bit") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260410171021.1277138-1-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ea5ca4c3bf49e784e84923c6c9c2aff152c48ef Author: Stefan Metzmacher Date: Tue Apr 7 17:13:45 2026 +0200 Bluetooth: SCO: check for codecs->num_codecs == 1 before assigning to sco_pi(sk)->codec [ Upstream commit 4e10a9ebbf081c16517cdd9366ac618bf38d7d0c ] copy_struct_from_sockptr() fill 'buffer' in sco_sock_setsockopt() with zeros, so there's no real problem. But it actually looks strange to do this, without checking all of codecs->codecs[0] really comes from userspace: sco_pi(sk)->codec = codecs->codecs[0]; As only optlen < sizeof(struct bt_codecs) is checked and codecs->num_codecs is not checked against != 1, but only <= 1, and the space for the additional struct bt_codec is not checked. Note I don't understand bluetooth and I didn't do any runtime tests with this! I just found it when debugging a problem in copy_struct_from_sockptr(). I just added this to check the size is as expected: BUILD_BUG_ON(struct_size(codecs, codecs, 0) != 1); BUILD_BUG_ON(struct_size(codecs, codecs, 1) != 8); And made sure it still compiles using this: make CF=-D__CHECK_ENDIAN__ W=1ce C=1 net/bluetooth/sco.o Fixes: 3e643e4efa1e ("Bluetooth: Improve setsockopt() handling of malformed user input") Cc: Michal Luczaj Cc: Luiz Augusto von Dentz Cc: Luiz Augusto von Dentz Cc: Marcel Holtmann Cc: David Wei Cc: linux-bluetooth@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Metzmacher Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5501d055a1ce3c747141e3955ba8cf034d193f3e Author: Dudu Lu Date: Sun Apr 5 23:47:41 2026 +0800 Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp [ Upstream commit 42776497cdbc9a665b384a6dcb85f0d4bd927eab ] l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it. Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del(). Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Dudu Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c27224daf0b08efbb2b24ed64b6139b294f5473a Author: Pauli Virtanen Date: Sun Mar 29 16:42:59 2026 +0300 Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER [ Upstream commit 5c7209a341ff2ac338b2b0375c34a307b37c9ac2 ] When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF. Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen, and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred listening socket code paths, hci_connect_cfm(conn) is called with hdev->lock held. Fix by holding the lock. Fixes: 70c464256310 ("Bluetooth: Refactor connection request handling") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 194f029a4d7f739e44ebc1f473120187b4de5104 Author: Jonathan Rissanen Date: Fri Mar 27 11:47:20 2026 +0100 Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error [ Upstream commit 68d39ea5e0adc9ecaea1ce8abd842ec972eb8718 ] When hci_register_dev() fails in hci_uart_register_dev() HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hci_uart_tty_receive() after resources are freed. Clear HCI_UART_PROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed. This allows the protocol-specific recv functions to remove the "HCI_UART_REGISTERED" guard without risking a null pointer dereference if hci_register_dev() fails. Fixes: 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization") Signed-off-by: Jonathan Rissanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f98446e91ce93f97df7da704c894b3987d9b46cb Author: Luiz Augusto von Dentz Date: Mon Mar 16 14:34:13 2026 -0400 Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds MTU [ Upstream commit 15bf35a660eb82a49f8397fc3d3acada8dae13db ] The code was printing skb->len and sdu_len in the places where it should be sdu_len and chan->imtu respectively to match the if conditions. Link: https://lore.kernel.org/linux-bluetooth/20260315132013.75ab40c5@kernel.org/T/#m1418f9c82eeff8510c1beaa21cf53af20db96c06 Fixes: e1d9a6688986 ("Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU") Signed-off-by: Luiz Augusto von Dentz Reviewed-by: Paul Menzel Signed-off-by: Sasha Levin commit 6def5fe753cbe5b279ee5fd10327b2611cbddaca Author: Sun Jian Date: Wed Apr 8 11:46:22 2026 +0800 bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb [ Upstream commit 12bec2bd4b76d81c5d3996bd14ec1b7f4d983747 ] bpf_prog_test_run_skb() calls eth_type_trans() first and then uses skb->protocol to initialize sk family and address fields for the test run. For IPv4 and IPv6 packets, it may access ip_hdr(skb) or ipv6_hdr(skb) even when the provided test input only contains an Ethernet header. Reject the input earlier if the Ethernet frame carries IPv4/IPv6 EtherType but the L3 header is too short. Fold the IPv4/IPv6 header length checks into the existing protocol switch and return -EINVAL before accessing the network headers. Fixes: fa5cb548ced6 ("bpf: Setup socket family and addresses in bpf_prog_test_run_skb") Reported-by: syzbot+619b9ef527f510a57cfc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=619b9ef527f510a57cfc Signed-off-by: Sun Jian Link: https://lore.kernel.org/r/20260408034623.180320-2-sun.jian.kdev@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 69f9a63216de804db0f08bd8be89454242716185 Author: Konstantin Khorenko Date: Fri Apr 10 19:21:49 2026 +0300 net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL [ Upstream commit c0b4382c86e3d92f79b71c9ed55654db520d7b36 ] When CONFIG_GCOV_PROFILE_ALL=y is enabled, the kernel fails to build: In file included from : In function 'skb_extensions_init', inlined from 'skb_init' at net/core/skbuff.c:5214:2: ././include/linux/compiler_types.h:706:45: error: call to '__compiletime_assert_1490' declared with attribute error: BUILD_BUG_ON failed: skb_ext_total_length() > 255 CONFIG_GCOV_PROFILE_ALL adds -fprofile-arcs -ftest-coverage -fno-tree-loop-im to CFLAGS globally. GCC inserts branch profiling counters into the skb_ext_total_length() loop and, combined with -fno-tree-loop-im (which disables loop invariant motion), cannot constant-fold the result. BUILD_BUG_ON requires a compile-time constant and fails. The issue manifests in kernels with 5+ SKB extension types enabled (e.g., after addition of SKB_EXT_CAN, SKB_EXT_PSP). With 4 extensions GCC can still unroll and fold the loop despite GCOV instrumentation; with 5+ it gives up. Mark skb_ext_total_length() with __no_profile to prevent GCOV from inserting counters into this function. Without counters the loop is "clean" and GCC can constant-fold it even with -fno-tree-loop-im active. This allows BUILD_BUG_ON to work correctly while keeping GCOV profiling for the rest of the kernel. This also removes the CONFIG_KCOV_INSTRUMENT_ALL preprocessor guard introduced by d6e5794b06c0. That guard was added as a precaution because KCOV instrumentation was also suspected of inhibiting constant folding. However, KCOV uses -fsanitize-coverage=trace-pc, which inserts lightweight trace callbacks that do not interfere with GCC's constant folding or loop optimization passes. Only GCOV's -fprofile-arcs combined with -fno-tree-loop-im actually prevents the compiler from evaluating the loop at compile time. The guard is therefore unnecessary and can be safely removed. Fixes: 96ea3a1e2d31 ("can: add CAN skb extension infrastructure") Signed-off-by: Konstantin Khorenko Reviewed-by: Thomas Weissschuh Link: https://patch.msgid.link/20260410162150.3105738-2-khorenko@virtuozzo.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a11e4bd3b48e320e3257c07877b236449712aa4 Author: Daniel Golle Date: Fri Apr 10 03:57:52 2026 +0100 net: ethernet: mtk_eth_soc: initialize PPE per-tag-layer MTU registers [ Upstream commit 2dddb34dd0d07b01fa770eca89480a4da4f13153 ] The PPE enforces output frame size limits via per-tag-layer VLAN_MTU registers that the driver never initializes. The hardware defaults do not account for PPPoE overhead, causing the PPE to punt encapsulated frames back to the CPU instead of forwarding them. Initialize the registers at PPE start and on MTU changes using the maximum GMAC MTU. This is a conservative approximation -- the actual per-PPE requirement depends on egress path, but using the global maximum ensures the limits are never too small. Fixes: ba37b7caf1ed2 ("net: ethernet: mtk_eth_soc: add support for initializing the PPE") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/ec995ab8ce8be423267a1cc093147a74d2eb9d82.1775789829.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 42dc87b185a6f1175756fae045eacf79a1573842 Author: Gal Pressman Date: Thu Apr 9 23:28:52 2026 +0300 net/mlx5e: IPsec, fix ASO poll timeout with read_poll_timeout_atomic() [ Upstream commit edccdd1eb94712da97a6ce71123ec27890add754 ] The do-while poll loop uses jiffies for its timeout: expires = jiffies + msecs_to_jiffies(10); jiffies is sampled at an arbitrary point within the current tick, so the first partial tick contributes anywhere from a full tick down to nearly zero real time. For small msecs_to_jiffies() results this is significant, the effective poll window can be much shorter than the requested 10ms, and in the worst case the loop exits after a single iteration (e.g., when HZ=100), well before the device has delivered the CQE. Replace the loop with read_poll_timeout_atomic(), which counts elapsed time via udelay() accounting rather than jiffies, guaranteeing the full poll window regardless of HZ. Additionally, read_poll_timeout_atomic() executes the poll operation one more time after the timeout has expired, giving the CQE a final chance to be detected. The old do-while loop could exit without a final poll if the timeout expired during the udelay() between iterations. Fixes: 76e463f6508b ("net/mlx5e: Overcome slow response for first IPsec ASO WQE") Signed-off-by: Gal Pressman Reviewed-by: Jianbo Liu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260409202852.158059-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7bb5c689266486b559e44add561eeed542c6c2a2 Author: Gal Pressman Date: Thu Apr 9 23:28:51 2026 +0300 net/mlx5e: Fix features not applied during netdev registration [ Upstream commit 9994ad4df82d64e57135c0f0906897685f5a9e87 ] mlx5e_fix_features() returns early when the netdevice is not present. This is correct during profile transitions where priv is cleared, but it also incorrectly blocks feature fixups during register_netdev(), when the device is also not yet present. It is not trivial to distinguish between both cases as we cannot use priv to carry state, and in both cases reg_state == NETREG_REGISTERED. Force a netdev features update after register_netdev() completes, where the device is present and fix_features() can actually work. This is not a pretty solution, as it results in an additional features update call (register_netdevice() already calls __netdev_update_features() internally), but it is the simplest, cleanest, and most robust way I found to fix this issue after multiple attempts. This fixes an issue on systems where CQE compression is enabled by default, RXHASH remains enabled after registration despite the two features being mutually exclusive. Fixes: ab4b01bfdaa6 ("net/mlx5e: Verify dev is present for fix features ndo") Signed-off-by: Gal Pressman Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260409202852.158059-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b2c49fbeb1b493c364b8bb0895d4e82bcc8771d0 Author: Charles Perry Date: Thu Apr 9 06:36:54 2026 -0700 net: phy: fix a return path in get_phy_c45_ids() [ Upstream commit 6f533abe7bbad2eef1e42c639b6bb9dad2b02362 ] The return value of phy_c45_probe_present() is stored in "ret", not "phy_reg", fix this. "phy_reg" always has a positive value if we reach this return path (since it would have returned earlier otherwise), which means that the original goal of the patch of not considering -ENODEV fatal wasn't achieved. Fixes: 17b447539408 ("net: phy: c45 scanning: Don't consider -ENODEV fatal") Signed-off-by: Charles Perry Reviewed-by: Andrew Lunn Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/20260409133654.3203336-1-charles.perry@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b1a9e427f3ff0e91a3b6ca3d62775690e01fc668 Author: Josua Mayer Date: Thu Apr 9 14:34:33 2026 +0200 dt-bindings: net: dsa: nxp,sja1105: make spi-cpol optional for sja1110 [ Upstream commit 600f01dc4bd0c736b3ffea9f7976136d8bf1b136 ] Currently, the binding requires 'spi-cpha' for SJA1105 and 'spi-cpol' for SJA1110. However, the SJA1110 supports both SPI modes 0 and 2. Mode 2 (cpha=0, cpol=1) is used by the NXP LX2160 Bluebox 3. On the SolidRun i.MX8DXL HummingBoard Telematics, mode 0 is stable, while forcing mode 2 introduces CRC errors especially during bursts. Drop the requirement on spi-cpol for SJA1110. Fixes: af2eab1a8243 ("dt-bindings: net: nxp,sja1105: document spi-cpol/cpha") Signed-off-by: Josua Mayer Acked-by: Conor Dooley Link: https://patch.msgid.link/20260409-imx8dxl-sr-som-v2-1-83ff20629ba0@solid-run.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cdde69041f09f51e64400f764cf8cfb4bac62b88 Author: Luca Weiss Date: Thu Apr 9 10:13:32 2026 +0200 net: ipa: Fix decoding EV_PER_EE for IPA v5.0+ [ Upstream commit 1335b903cf2e8aeaca87fd665683384c731ec941 ] Initially 'reg' and 'val' are assigned from HW_PARAM_2. But since IPA v5.0+ takes EV_PER_EE from HW_PARAM_4 (instead of NUM_EV_PER_EE from HW_PARAM_2), we not only need to re-assign 'reg' but also read the register value of that register into 'val' so that reg_decode() works on the correct value. Fixes: f651334e1ef5 ("net: ipa: add HW_PARAM_4 GSI register") Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=2 Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260409-ipa-fixes-v1-2-a817c30678ac@fairphone.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 24145d0dc248e10f7873bf66b1aada9a441ba9c4 Author: Luca Weiss Date: Thu Apr 9 10:13:31 2026 +0200 net: ipa: Fix programming of QTIME_TIMESTAMP_CFG [ Upstream commit de08f9585692813bd41ee654fca0487664c4de30 ] The 'val' variable gets overwritten multiple times, discarding previous values. Looking at the git log shows these should be combined with |= instead. Fixes: 9265a4f0f0b4 ("net: ipa: define even more IPA register fields") Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=4 Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260409-ipa-fixes-v1-1-a817c30678ac@fairphone.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1a8a51ce85075a56a743b6f142606dd2696a391c Author: Taegu Ha Date: Thu Apr 9 16:11:15 2026 +0900 ppp: require CAP_NET_ADMIN in target netns for unattached ioctls [ Upstream commit 2bb6379416fd19f44c3423a00bfd8626259f6067 ] /dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns. As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace. Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls. This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case. Fixes: 273ec51dd7ce ("net: ppp_generic - introduce net-namespace functionality v2") Signed-off-by: Taegu Ha Link: https://patch.msgid.link/20260409071117.4354-1-hataegu0826@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 634a793d0e1c822412095d25a1338f8831ad894c Author: Lang Xu Date: Thu Apr 2 15:42:35 2026 +0800 bpf: Fix OOB in pcpu_init_value [ Upstream commit 576afddfee8d1108ee299bf10f581593540d1a36 ] An out-of-bounds read occurs when copying element from a BPF_MAP_TYPE_CGROUP_STORAGE map to another pcpu map with the same value_size that is not rounded up to 8 bytes. The issue happens when: 1. A CGROUP_STORAGE map is created with value_size not aligned to 8 bytes (e.g., 4 bytes) 2. A pcpu map is created with the same value_size (e.g., 4 bytes) 3. Update element in 2 with data in 1 pcpu_init_value assumes that all sources are rounded up to 8 bytes, and invokes copy_map_value_long to make a data copy, However, the assumption doesn't stand since there are some cases where the source may not be rounded up to 8 bytes, e.g., CGROUP_STORAGE, skb->data. the verifier verifies exactly the size that the source claims, not the size rounded up to 8 bytes by kernel, an OOB happens when the source has only 4 bytes while the copy size(4) is rounded up to 8. Fixes: d3bec0138bfb ("bpf: Zero-fill re-used per-cpu map element") Reported-by: Kaiyan Mei Closes: https://lore.kernel.org/all/14e6c70c.6c121.19c0399d948.Coremail.kaiyanm@hust.edu.cn/ Link: https://lore.kernel.org/r/420FEEDDC768A4BE+20260402074236.2187154-1-xulang@uniontech.com Signed-off-by: Lang Xu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b6a54f5e9ce9b97ae641855378d71c5154a085c0 Author: Greg Jumper Date: Wed Apr 8 01:04:20 2026 -0700 net/rds: Restrict use of RDS/IB to the initial network namespace [ Upstream commit ebf71dd4aff46e8e421d455db3e231ba43d2fa8a ] Prevent using RDS/IB in network namespaces other than the initial one. The existing RDS/IB code will not work properly in non-initial network namespaces. Fixes: d5a8ac28a7ff ("RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net") Reported-by: syzbot+da8e060735ae02c8f3d1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=da8e060735ae02c8f3d1 Signed-off-by: Greg Jumper Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260408080420.540032-3-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5605cde35bc50f695c11dc533b0e24868d7a61ee Author: Håkon Bugge Date: Wed Apr 8 01:04:19 2026 -0700 net/rds: Optimize rds_ib_laddr_check [ Upstream commit 236f718ac885965fa886440b9898dfae185c9733 ] rds_ib_laddr_check() creates a CM_ID and attempts to bind the address in question to it. This in order to qualify the allegedly local address as a usable IB/RoCE address. In the field, ExaWatcher runs rds-ping to all ports in the fabric from all local ports. This using all active ToS'es. In a full rack system, we have 14 cell servers and eight db servers. Typically, 6 ToS'es are used. This implies 528 rds-ping invocations per ExaWatcher's "RDSinfo" interval. Adding to this, each rds-ping invocation creates eight sockets and binds the local address to them: socket(AF_RDS, SOCK_SEQPACKET, 0) = 3 bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 4 bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 5 bind(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 6 bind(6, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 7 bind(7, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 8 bind(8, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 9 bind(9, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 socket(AF_RDS, SOCK_SEQPACKET, 0) = 10 bind(10, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.36.2")}, 16) = 0 So, at every interval ExaWatcher executes rds-ping's, 4224 CM_IDs are allocated, considering this full-rack system. After the a CM_ID has been allocated, rdma_bind_addr() is called, with the port number being zero. This implies that the CMA will attempt to search for an un-used ephemeral port. Simplified, the algorithm is to start at a random position in the available port space, and then if needed, iterate until an un-used port is found. The book-keeping of used ports uses the idr system, which again uses slab to allocate new struct idr_layer's. The size is 2092 bytes and slab tries to reduce the wasted space. Hence, it chooses an order:3 allocation, for which 15 idr_layer structs will fit and only 1388 bytes are wasted per the 32KiB order:3 chunk. Although this order:3 allocation seems like a good space/speed trade-off, it does not resonate well with how it used by the CMA. The combination of the randomized starting point in the port space (which has close to zero spatial locality) and the close proximity in time of the 4224 invocations of the rds-ping's, creates a memory hog for order:3 allocations. These costly allocations may need reclaims and/or compaction. At worst, they may fail and produce a stack trace such as (from uek4): [] __inc_zone_page_state+0x35/0x40 [] page_add_file_rmap+0x57/0x60 [] remove_migration_pte+0x3f/0x3c0 [ksplice_6cn872bt_vmlinux_new] [] rmap_walk+0xd8/0x340 [] remove_migration_ptes+0x40/0x50 [] migrate_pages+0x3ec/0x890 [] compact_zone+0x32d/0x9a0 [] compact_zone_order+0x6d/0x90 [] try_to_compact_pages+0x102/0x270 [] __alloc_pages_direct_compact+0x46/0x100 [] __alloc_pages_nodemask+0x74b/0xaa0 [] alloc_pages_current+0x91/0x110 [] new_slab+0x38b/0x480 [] __slab_alloc+0x3b7/0x4a0 [ksplice_s0dk66a8_vmlinux_new] [] kmem_cache_alloc+0x1fb/0x250 [] idr_layer_alloc+0x36/0x90 [] idr_get_empty_slot+0x28c/0x3d0 [] idr_alloc+0x4d/0xf0 [] cma_alloc_port+0x4d/0xa0 [rdma_cm] [] rdma_bind_addr+0x2ae/0x5b0 [rdma_cm] [] rds_ib_laddr_check+0x83/0x2c0 [ksplice_6l2xst5i_rds_rdma_new] [] rds_trans_get_preferred+0x5b/0xa0 [rds] [] rds_bind+0x212/0x280 [rds] [] SYSC_bind+0xe6/0x120 [] SyS_bind+0xe/0x10 [] system_call_fastpath+0x18/0xd4 To avoid these excessive calls to rdma_bind_addr(), we optimize rds_ib_laddr_check() by simply checking if the address in question has been used before. The rds_rdma module keeps track of addresses associated with IB devices, and the function rds_ib_get_device() is used to determine if the address already has been qualified as a valid local address. If not found, we call the legacy rds_ib_laddr_check(), now renamed to rds_ib_laddr_check_cm(). Signed-off-by: Håkon Bugge Signed-off-by: Somasundaram Krishnasamy Signed-off-by: Gerd Rausch Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260408080420.540032-2-achender@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: ebf71dd4aff4 ("net/rds: Restrict use of RDS/IB to the initial network namespace") Signed-off-by: Sasha Levin commit b6c5a4bf1067e32cdc6a8afde78cc6209b705167 Author: Paul Chaignon Date: Wed Apr 8 22:40:50 2026 +0200 selftests/bpf: Fix reg_bounds to match new tnum-based refinement [ Upstream commit 2fefa9c81a25534464911447d51ddb44b04a8e5b ] Commit efc11a667878 ("bpf: Improve bounds when tnum has a single possible value") improved the bounds refinement to detect when the tnum and u64 range overlap in a single value (and the bounds can thus be set to that value). Eduard then noticed that it broke the slow-mode reg_bounds selftests because they don't have an equivalent logic and are therefore unable to refine the bounds as much as the verifier. The following test case illustrates this. ACTUAL TRUE1: scalar(u64=0xffffffff00000000,u32=0,s64=0xffffffff00000000,s32=0) EXPECTED TRUE1: scalar(u64=[0xfffffffe00000001; 0xffffffff00000000],u32=0,s64=[0xfffffffe00000001; 0xffffffff00000000],s32=0) [...] #323/1007 reg_bounds_gen_consts_s64_s32/(s64)[0xfffffffe00000001; 0xffffffff00000000] (s32) S64_MIN:FAIL with the verifier logs: [...] 19: w0 = w6 ; R0=scalar(smin=0,smax=umax=0xffffffff, var_off=(0x0; 0xffffffff)) R6=scalar(smin=0xfffffffe00000001,smax=0xffffffff00000000, umin=0xfffffffe00000001,umax=0xffffffff00000000, var_off=(0xfffffffe00000000; 0x1ffffffff)) 20: w0 = w7 ; R0=0 R7=0x8000000000000000 21: if w6 == w7 goto pc+3 [...] from 21 to 25: [...] 25: w0 = w6 ; R0=0 R6=0xffffffff00000000 ; ^ ; unexpected refined value 26: w0 = w7 ; R0=0 R7=0x8000000000000000 27: exit When w6 == w7 is true, the verifier can deduce that the R6's tnum is equal to (0xfffffffe00000000; 0x100000000) and then use that information to refine the bounds: the tnum only overlap with the u64 range in 0xffffffff00000000. The reg_bounds selftest doesn't know about tnums and therefore fails to perform the same refinement. This issue happens when the tnum carries information that cannot be represented in the ranges, as otherwise the selftest could reach the same refined value using just the ranges. The tnum thus needs to represent non-contiguous values (ex., R6's tnum above, after the condition). The only way this can happen in the reg_bounds selftest is at the boundary between the 32 and 64bit ranges. We therefore only need to handle that case. This patch fixes the selftest refinement logic by checking if the u32 and u64 ranges overlap in a single value. If so, the ranges can be set to that value. We need to handle two cases: either they overlap in umin64... u64 values matching u32 range: xxx xxx xxx xxx |--------------------------------------| u64 range: 0 xxxxx UMAX64 or in umax64: u64 values matching u32 range: xxx xxx xxx xxx |--------------------------------------| u64 range: 0 xxxxx UMAX64 To detect the first case, we decrease umax64 to the maximum value that matches the u32 range. If that happens to be umin64, then umin64 is the only overlap. We proceed similarly for the second case, increasing umin64 to the minimum value that matches the u32 range. Note this is similar to how the verifier handles the general case using tnum, but we don't need to care about a single-value overlap in the middle of the range. That case is not possible when comparing two ranges. This patch also adds two test cases reproducing this bug as part of the normal test runs (without SLOW_TESTS=1). Fixes: efc11a667878 ("bpf: Improve bounds when tnum has a single possible value") Reported-by: Eduard Zingerman Closes: https://lore.kernel.org/bpf/4e6dd64a162b3cab3635706ae6abfdd0be4db5db.camel@gmail.com/ Signed-off-by: Paul Chaignon Link: https://lore.kernel.org/r/ada9UuSQi2SE2IfB@mail.gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7c92ea9ee042db70d02b3a3c9319b687179ef352 Author: Emil Tsalapatis Date: Sun Apr 12 13:45:38 2026 -0400 bpf: Allow instructions with arena source and non-arena dest registers [ Upstream commit ac61bffe91d4bda08806e12957c6d64756d042db ] The compiler sometimes stores the result of a PTR_TO_ARENA and SCALAR operation into the scalar register rather than the pointer register. Relax the verifier to allow operations between a source arena register and a destination non-arena register, marking the destination's value as a PTR_TO_ARENA. Signed-off-by: Emil Tsalapatis Acked-by: Song Liu Fixes: 6082b6c328b5 ("bpf: Recognize addr_space_cast instruction in the verifier.") Link: https://lore.kernel.org/r/20260412174546.18684-2-emil@etsalapatis.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 18e3ffde1822f0b48b1753bf34aa97ce839df1d8 Author: Jiayuan Chen Date: Tue Apr 7 10:26:27 2026 +0800 bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops [ Upstream commit 10f86a2a5c91fc4c4d001960f1c21abe52545ef6 ] When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp. Fixes: fd09af010788 ("bpf: sock_ops ctx access may stomp registers in corner case") Fixes: 84f44df664e9 ("bpf: sock_ops sk access may stomp registers when dst_reg = src_reg") Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn> Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reported-by: Dongliang Mu Reviewed-by: Emil Tsalapatis Closes: https://lore.kernel.org/bpf/6fe1243e-149b-4d3b-99c7-fcc9e2f75787@std.uestc.edu.cn/T/#u Signed-off-by: Jiayuan Chen Acked-by: Martin KaFai Lau Link: https://patch.msgid.link/20260407022720.162151-2-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bf26ad92ffda7884825d67b46bd5efe615c3babf Author: Fernando Fernandez Mancera Date: Wed Apr 8 12:00:44 2026 +0200 net_sched: fix skb memory leak in deferred qdisc drops [ Upstream commit a6bd339dbb3514bce690fdcf252e788dfab4ee76 ] When the network stack cleans up the deferred list via qdisc_run_end(), it operates on the root qdisc. If the root qdisc do not implement the TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and gets stranded on the child's local to_free list. Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If the flag is present, the packet is appended directly to the root's to_free list. Otherwise, drop it directly as it was done before the optimization was implemented. Fixes: a6efc273ab82 ("net_sched: use qdisc_dequeue_drop() in cake, codel, fq_codel") Reported-by: Damilola Bello Closes: https://lore.kernel.org/netdev/CAPgFtOLaedBMU0f_BxV2bXftTJSmJr018Q5uozOo5vVo6b9tjw@mail.gmail.com/ Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260408100044.4530-1-fmancera@suse.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ca564da039e20f2d36427e8ac21c83b19e80b1f Author: Lorenzo Bianconi Date: Wed Apr 8 20:26:56 2026 +0200 net: airoha: Add missing RX_CPU_IDX() configuration in airoha_qdma_cleanup_rx_queue() [ Upstream commit 656121b155030086b01cfce9bd31b0c925ee6860 ] When the descriptor index written in REG_RX_CPU_IDX() is equal to the one stored in REG_RX_DMA_IDX(), the hw will stop since the QDMA RX ring is empty. Add missing REG_RX_CPU_IDX() configuration in airoha_qdma_cleanup_rx_queue routine during QDMA RX ring cleanup. Fixes: 514aac359987 ("net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260408-airoha-cpu-idx-airoha_qdma_cleanup_rx_queue-v1-1-8efa64844308@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b752e14ea7cc719c8c3a2084c3b69744a66ea996 Author: Erni Sri Satya Vennela Date: Wed Apr 8 01:12:20 2026 -0700 net: mana: Move current_speed debugfs file to mana_init_port() [ Upstream commit 3b7c7fc97aea7b4048001d12f45777201c74a17f ] Move the current_speed debugfs file creation from mana_probe_port() to mana_init_port(). The file was previously created only during initial probe, but mana_cleanup_port_context() removes the entire vPort debugfs directory during detach/attach cycles. Since mana_init_port() recreates the directory on re-attach, moving current_speed here ensures it survives these cycles. Fixes: 75cabb46935b ("net: mana: Add support for net_shaper_ops") Signed-off-by: Erni Sri Satya Vennela Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260408081224.302308-3-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9211eb97e8f8c28bf9313ab97862d143dbbbef97 Author: Erni Sri Satya Vennela Date: Wed Apr 8 01:12:19 2026 -0700 net: mana: Use pci_name() for debugfs directory naming [ Upstream commit c116f07ab9d22bb6f355f3cf9e44c1e6a47fe559 ] Use pci_name(pdev) for the per-device debugfs directory instead of hardcoded "0" for PFs and pci_slot_name(pdev->slot) for VFs. The previous approach had two issues: 1. pci_slot_name() dereferences pdev->slot, which can be NULL for VFs in environments like generic VFIO passthrough or nested KVM, causing a NULL pointer dereference. 2. Multiple PFs would all use "0", and VFs across different PCI domains or buses could share the same slot name, leading to -EEXIST errors from debugfs_create_dir(). pci_name(pdev) returns the unique BDF address, is always valid, and is unique across the system. Fixes: 6607c17c6c5e ("net: mana: Enable debugfs files for MANA device") Signed-off-by: Erni Sri Satya Vennela Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260408081224.302308-2-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 894f40bdac09ca7948c5d77a2a190ccf15642fa2 Author: Florian Westphal Date: Fri Apr 10 00:45:02 2026 +0200 selftests: netfilter: nft_tproxy.sh: adjust to socat changes [ Upstream commit 61119542663cac70898aef532eb57ee41ea9b477 ] Like e65d8b6f3092 ("selftests: drv-net: adjust to socat changes") we need to add shut-none for this test too. The extra 0-packet can trigger a second (unexpected) reply from the server. Fixes: 7e37e0eacd22 ("selftests: netfilter: nft_tproxy.sh: add tcp tests") Reported-by: Jakub Kicinski Closes: https://lore.kernel.org/netdev/20260408152432.24b8ad0d@kernel.org/ Suggested-by: Jakub Kicinski Signed-off-by: Florian Westphal Link: https://patch.msgid.link/20260409224506.27072-1-fw@strlen.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3e20e1b3058e0b94638e7b931c138e840e266724 Author: Jamal Hadi Salim Date: Fri Apr 10 07:16:27 2026 -0400 net/sched: act_ct: Only release RCU read lock after ct_ft [ Upstream commit f462dca0c8415bf0058d0ffa476354c4476d0f09 ] When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1] Fixes: 138470a9b2cc2 ("net/sched: act_ct: fix lockdep splat in tcf_ct_flow_table_get") Reported-by: zdi-disclosures@trendmicro.com Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260410111627.46611-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4fabcfea7a9dd159df32c5df6587fe858cb0d748 Author: Davide Caratti Date: Wed Apr 8 17:24:36 2026 +0200 net/sched: cls_fw: fix NULL dereference of "old" filters before change() [ Upstream commit 65782b2db7321d5f97c16718c4c7f6c7205a56be ] Like pointed out by Sashiko [1], since commit ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the "old" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \ > -A 4.3.2.1 -B 1.2.3.4 -t udp "dp=1234" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip "old-style" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw "old-style" filters. [1] https://sashiko.dev/#/patchset/20260331050217.504278-1-xmei5%40asu.edu [2] https://elixir.bootlin.com/linux/v7.0-rc6/source/include/net/pkt_cls.h#L86 Fixes: faeea8bbf6e9 ("net/sched: cls_fw: fix NULL pointer dereference on shared blocks") Fixes: ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex") Acked-by: Jamal Hadi Salim Signed-off-by: Davide Caratti Link: https://patch.msgid.link/e39cbd3103a337f1e515d186fe697b4459d24757.1775661704.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9bc02b8532742978421d5ecb2079d348374c96e0 Author: Eduard Zingerman Date: Sat Apr 11 00:33:44 2026 -0700 selftests/bpf: fix __jited_unpriv tag name [ Upstream commit cdd54fe98c00549264a92613af6bb0e9a5fd0d1c ] __jited_unpriv was using "test_jited=" as its tag name, same as the priv variant __jited. Fix by using "test_jited_unpriv=". Fixes: 7d743e4c759c ("selftests/bpf: __jited test tag to check disassembly after jit") Acked-by: Ihor Solodrai Reviewed-by: Puranjay Mohan Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/20260410-selftests-global-tags-ordering-v2-1-c566ec9781bf@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7d73c72cccac651acc891377a5e623e4021c6380 Author: Daniel Borkmann Date: Sat Apr 11 01:26:50 2026 +0200 bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars [ Upstream commit 2f2ec8e7730e21fc9bd49e0de9cdd58213ea24d0 ] When regsafe() compares two scalar registers that both carry BPF_ADD_CONST, check_scalar_ids() maps their full compound id (aka base | BPF_ADD_CONST flag) as one idmap entry. However, it never verifies that the underlying base ids, that is, with the flag stripped are consistent with existing idmap mappings. This allows construction of two verifier states where the old state has R3 = R2 + 10 (both sharing base id A) while the current state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap creates two independent entries: A->B (for R2) and A|flag->C|flag (for R3), without catching that A->C conflicts with A->B. State pruning then incorrectly succeeds. Fix this by additionally verifying base ID mapping consistency whenever BPF_ADD_CONST is set: after mapping the compound ids, also invoke check_ids() on the base IDs (flag bits stripped). This ensures that if A was already mapped to B from comparing the source register, any ADD_CONST derivative must also derive from B, not an unrelated C. Fixes: 98d7ca374ba4 ("bpf: Track delta between "linked" registers.") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260410232651.559778-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 888ab1297fd9a648351caee0321b8c56a6566230 Author: Lorenzo Bianconi Date: Wed Apr 8 12:20:09 2026 +0200 net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available [ Upstream commit 02f72964395911e7a09bb2ea2fe6f79eda4ea2c2 ] airoha_fe_set routine is used to set specified bits to 1 in the selected register. In the FE_PSE_BUF_SET case this can due to a overestimation of the required buffers for I/O queues since we can miss to set some bits of PSE_ALLRSV_MASK subfield to 0. Fix the issue relying on airoha_fe_rmw routine instead. Fixes: 8e38e08f2c560 ("net: airoha: fix PSE memory configuration in airoha_fe_pse_ports_init()") Tested-by: Xuegang Lu Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260408-airoha-reg_fe_pse_buf_set-v1-1-0c4fa8f4d1d9@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 578f3aba427c938fecfa0d8c83d9acb213a9b24a Author: Mashiro Chen Date: Wed Apr 8 01:31:01 2026 +0800 net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf [ Upstream commit bf9a38803b2626b01cc769aaf13485d8650f576f ] sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose. Reported-by: syzbot+ecdb8c9878a81eb21e54@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ecdb8c9878a81eb21e54 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Mashiro Chen Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260407173101.107352-1-mashiro.chen@mailbox.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 67bdb4b0d26f2d6bbf1798a925ef5a3b9ed7357a Author: Sechang Lim Date: Tue Apr 7 10:38:23 2026 +0000 bpf: Fix RCU stall in bpf_fd_array_map_clear() [ Upstream commit 4406942e65ca128c56c67443832988873c21d2e9 ] Add a missing cond_resched() in bpf_fd_array_map_clear() loop. For PROG_ARRAY maps with many entries this loop calls prog_array_map_poke_run() per entry which can be expensive, and without yielding this can cause RCU stalls under load: rcu: Stack dump where RCU GP kthread last ran: CPU: 0 UID: 0 PID: 30932 Comm: kworker/0:2 Not tainted 6.14.0-13195-g967e8def1100 #2 PREEMPT(undef) Workqueue: events prog_array_map_clear_deferred RIP: 0010:write_comp_data+0x38/0x90 kernel/kcov.c:246 Call Trace: prog_array_map_poke_run+0x77/0x380 kernel/bpf/arraymap.c:1096 __fd_array_map_delete_elem+0x197/0x310 kernel/bpf/arraymap.c:925 bpf_fd_array_map_clear kernel/bpf/arraymap.c:1000 [inline] prog_array_map_clear_deferred+0x119/0x1b0 kernel/bpf/arraymap.c:1141 process_one_work+0x898/0x19d0 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x770/0x10b0 kernel/workqueue.c:3400 kthread+0x465/0x880 kernel/kthread.c:464 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x19/0x30 arch/x86/entry/entry_64.S:245 Reviewed-by: Sun Jian Fixes: da765a2f5993 ("bpf: Add poke dependency tracking for prog array maps") Signed-off-by: Sechang Lim Link: https://lore.kernel.org/r/20260407103823.3942156-1-rhkrqnwk98@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 13860ca37b8df0b856ee1ce3bdbd7c327d5f53e8 Author: Puranjay Mohan Date: Wed Apr 8 08:45:37 2026 -0700 bpf: return VMA snapshot from task_vma iterator [ Upstream commit 4cbee026db54cad39c39db4d356100cb133412b3 ] Holding the per-VMA lock across the BPF program body creates a lock ordering problem when helpers acquire locks that depend on mmap_lock: vm_lock -> i_rwsem -> mmap_lock -> vm_lock Snapshot the VMA under the per-VMA lock in _next() via memcpy(), then drop the lock before returning. The BPF program accesses only the snapshot. The verifier only trusts vm_mm and vm_file pointers (see BTF_TYPE_SAFE_TRUSTED_OR_NULL in verifier.c). vm_file is reference- counted with get_file() under the lock and released via fput() on the next iteration or in _destroy(). vm_mm is already correct because lock_vma_under_rcu() verifies vma->vm_mm == mm. All other pointers are left as-is by memcpy() since the verifier treats them as untrusted. Fixes: 4ac454682158 ("bpf: Introduce task_vma open-coded iterator kfuncs") Signed-off-by: Puranjay Mohan Acked-by: Andrii Nakryiko Acked-by: Mykyta Yatsenko Link: https://lore.kernel.org/r/20260408154539.3832150-4-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5d0ee981ac341bc6297a52049118a5a93f86d013 Author: Puranjay Mohan Date: Wed Apr 8 08:45:36 2026 -0700 bpf: switch task_vma iterator from mmap_lock to per-VMA locks [ Upstream commit bee9ef4a40a277bf401be43d39ba7f7f063cf39c ] The open-coded task_vma iterator holds mmap_lock for the entire duration of iteration, increasing contention on this highly contended lock. Switch to per-VMA locking. Find the next VMA via an RCU-protected maple tree walk and lock it with lock_vma_under_rcu(). lock_next_vma() is not used because its fallback takes mmap_read_lock(), and the iterator must work in non-sleepable contexts. lock_vma_under_rcu() is a point lookup (mas_walk) that finds the VMA containing a given address but cannot iterate across gaps. An RCU-protected vma_next() walk (mas_find) first locates the next VMA's vm_start to pass to lock_vma_under_rcu(). Between the RCU walk and the lock, the VMA may be removed, shrunk, or write-locked. On failure, advance past it using vm_end from the RCU walk. Because the VMA slab is SLAB_TYPESAFE_BY_RCU, vm_end may be stale; fall back to PAGE_SIZE advancement when it does not make forward progress. Concurrent VMA insertions at addresses already passed by the iterator are not detected. CONFIG_PER_VMA_LOCK is required; return -EOPNOTSUPP without it. Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260408154539.3832150-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Stable-dep-of: 4cbee026db54 ("bpf: return VMA snapshot from task_vma iterator") Signed-off-by: Sasha Levin commit 43683bb280330f3d36f0f2a3932a4867b9603e9c Author: Puranjay Mohan Date: Wed Apr 8 08:45:35 2026 -0700 bpf: fix mm lifecycle in open-coded task_vma iterator [ Upstream commit d8e27d2d22b6e2df3a0125b8c08e9aace38c954c ] The open-coded task_vma iterator reads task->mm locklessly and acquires mmap_read_trylock() but never calls mmget(). If the task exits concurrently, the mm_struct can be freed as it is not SLAB_TYPESAFE_BY_RCU, resulting in a use-after-free. Safely read task->mm with a trylock on alloc_lock and acquire an mm reference. Drop the reference via bpf_iter_mmput_async() in _destroy() and error paths. bpf_iter_mmput_async() is a local wrapper around mmput_async() with a fallback to mmput() on !CONFIG_MMU. Reject irqs-disabled contexts (including NMI) up front. Operations used by _next() and _destroy() (mmap_read_unlock, bpf_iter_mmput_async) take spinlocks with IRQs disabled (pool->lock, pi_lock). Running from NMI or from a tracepoint that fires with those locks held could deadlock. A trylock on alloc_lock is used instead of the blocking task_lock() (get_task_mm) to avoid a deadlock when a softirq BPF program iterates a task that already holds its alloc_lock on the same CPU. Fixes: 4ac454682158 ("bpf: Introduce task_vma open-coded iterator kfuncs") Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20260408154539.3832150-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 4e70ba147405420f408c6311461a86b321df871e Author: Florian Westphal Date: Thu Apr 9 13:30:41 2026 +0200 netfilter: nft_fwd_netdev: check ttl/hl before forwarding [ Upstream commit 1dfd95bdf4d18d263aa8fad06bfb9f4d9c992b18 ] Drop packets if their ttl/hl is too small for forwarding. Fixes: d32de98ea70f ("netfilter: nft_fwd_netdev: allow to forward packets via neighbour layer") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 439117ca7285a5fa4e6ff878b5e451ee6dd24e0e Author: Florian Westphal Date: Sat Apr 4 12:12:59 2026 +0200 netfilter: xt_socket: enable defrag after all other checks [ Upstream commit 542be3fa5aff54210a02954c38f07e53ea9bdafd ] Originally this did not matter because defrag was enabled once per netns and only disabled again on netns dismantle. When this got changed I should have adjusted checkentry to not leave defrag enabled on error. Fixes: de8c12110a13 ("netfilter: disable defrag once its no longer needed") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit fde99f69f7f1ecf5ecc354de20db8fa033929b39 Author: Mohsin Bashir Date: Tue Apr 7 17:24:15 2026 -0700 eth: fbnic: Use wake instead of start [ Upstream commit 12ff2a4aee6c86746623d5aed24389dbf6dffded ] fbnic_up() calls netif_tx_start_all_queues(), which only clears __QUEUE_STATE_DRV_XOFF. If qdisc backlog has accumulated on any TX queue before the reconfiguration (e.g. ring resize via ethtool -G), start does not call __netif_schedule() to kick the qdisc, so the pending backlog is never drained and the queue stalls. Switch to netif_tx_wake_all_queues(), which clears DRV_XOFF and also calls __netif_schedule() on every queue, ensuring any backlog that built up before the down/up cycle is promptly dequeued. Fixes: bc6107771bb4 ("eth: fbnic: Allocate a netdevice and napi vectors with queues") Signed-off-by: Mohsin Bashir Link: https://patch.msgid.link/20260408002415.2963915-1-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f1cac6ba5aba25dd4da03651c2540cec33c4fceb Author: Lorenzo Bianconi Date: Tue Apr 7 08:48:04 2026 +0200 net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process() [ Upstream commit 4ae0604a0673e11e2075b178387151fcad5111b5 ] Add missing dma_rmb() in airoha_qdma_rx_process routine to make sure the DMA read operations are completed when the NIC reports the processing on the current descriptor is done. Moreover, add missing READ_ONCE() in airoha_qdma_rx_process() for DMA descriptor control fields in order to avoid any compiler reordering. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260407-airoha_qdma_rx_process-fix-reordering-v3-1-91c36e9da31f@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7ce1c26aac3b318886a57425f64b522da7389153 Author: Justin Chen Date: Mon Apr 6 10:57:56 2026 -0700 net: bcmgenet: fix racing timeout handler [ Upstream commit 5393b2b5bee2ac51a0043dc7f4ac3475f053d08d ] The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue. Fixes: 13ea657806cf ("net: bcmgenet: improve TX timeout") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Reviewed-by: Nicolai Buchwitz Tested-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260406175756.134567-4-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ac4a29c331ecb5b10240c44247a8e010c95bc15b Author: Justin Chen Date: Mon Apr 6 10:57:55 2026 -0700 net: bcmgenet: fix leaking free_bds [ Upstream commit 3f3168300efb839028328d720ab3962f91d6a0d0 ] While reclaiming the tx queue we fast forward the write pointer to drop any data in flight. These dropped frames are not added back to the pool of free bds. We also need to tell the netdev that we are dropping said data. Fixes: f1bacae8b655 ("net: bcmgenet: support reclaiming unsent Tx packets") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Reviewed-by: Nicolai Buchwitz Tested-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260406175756.134567-3-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 72df896e31ddd06fcc5a789f025ad7a62a18bc9b Author: Justin Chen Date: Mon Apr 6 10:57:54 2026 -0700 net: bcmgenet: fix off-by-one in bcmgenet_put_txcb [ Upstream commit 57f3f53d2c9c5a9e133596e2f7bc1c50688a6d38 ] The write_ptr points to the next open tx_cb. We want to return the tx_cb that gets rewinded, so we must rewind the pointer first then return the tx_cb that it points to. That way the txcb can be correctly cleaned up. Fixes: 876dbadd53a7 ("net: bcmgenet: Fix unmapping of fragments in bcmgenet_xmit()") Signed-off-by: Justin Chen Reviewed-by: Nicolai Buchwitz Link: https://patch.msgid.link/20260406175756.134567-2-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7c484a214db2282dfc6b62c052016cdbd57d95ac Author: Cosmin Ratiu Date: Wed Apr 8 14:52:40 2026 +0300 macsec: Support VLAN-filtering lower devices [ Upstream commit a363b1c8be879c79a688eaf93ba01b63f8b0e63c ] VLAN-filtering is done through two netdev features (NETIF_F_HW_VLAN_CTAG_FILTER and NETIF_F_HW_VLAN_STAG_FILTER) and two netdev ops (ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid). Implement these and advertise the features if the lower device supports them. This allows proper VLAN filtering to work on top of MACsec devices, when the lower device is capable of VLAN filtering. As a concrete example, having this chain of interfaces now works: vlan_filtering_capable_dev(1) -> macsec_dev(2) -> macsec_vlan_dev(3) Before the mentioned commit this used to accidentally work because the MACsec device (and thus the lower device) was put in promiscuous mode and the VLAN filter was not used. But after commit [1] correctly made the macsec driver expose the IFF_UNICAST_FLT flag, promiscuous mode was no longer used and VLAN filters on dev 1 kicked in. Without support in dev 2 for propagating VLAN filters down, the register_vlan_dev -> vlan_vid_add -> __vlan_vid_add -> vlan_add_rx_filter_info call from dev 3 is silently eaten (because vlan_hw_filter_capable returns false and vlan_add_rx_filter_info silently succeeds). For MACsec, VLAN filters are only relevant for offload, otherwise the VLANs are encrypted and the lower devices don't care about them. So VLAN filters are only passed on to lower devices in offload mode. Flipping between offload modes now needs to offload/unoffload the filters with vlan_{get,drop}_rx_*_filter_info(). To avoid the back-and-forth filter updating during rollback, the setting of macsec->offload is moved after the add/del secy ops. This is safe since none of the code called from those requires macsec->offload. In case adding the filters fails, the added ones are rolled back and an error is returned to the operation toggling the offload state. Fixes: 0349659fd72f ("macsec: set IFF_UNICAST_FLT priv flag") Signed-off-by: Cosmin Ratiu Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20260408115240.1636047-5-cratiu@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a51e7fbe94a87e236631a83973d4f558310b2cd2 Author: Jiayuan Chen Date: Thu Apr 9 10:37:32 2026 +0800 bpf: Fix use-after-free in offloaded map/prog info fill [ Upstream commit a0c584fc18056709c8e047a82a6045d6c209f4ce ] When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed. Fixes: 675fc275a3a2d ("bpf: offload: report device information for offloaded programs") Fixes: 52775b33bb507 ("bpf: offload: report device information about offloaded maps") Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reviewed-by: Dongliang Mu Closes: https://lore.kernel.org/bpf/f0aa3678-79c9-47ae-9e8c-02a3d1df160a@hust.edu.cn/ Signed-off-by: Jiayuan Chen Acked-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260409023733.168050-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e00ad1f50cc84f52c09226b88c41336ebce854ff Author: Paolo Abeni Date: Tue Apr 7 10:45:17 2026 +0200 mptcp: better mptcp-level RTT estimator [ Upstream commit d2000361e4ddf5047d660a902a3b0ed7520be1e5 ] The current MPTCP-level RTT estimator has several issues. On high speed links, the MPTCP-level receive buffer auto-tuning happens with a frequency well above the TCP-level's one. That in turn can cause excessive/unneeded receive buffer increase. On such links, the initial rtt_us value is considerably higher than the actual delay, and the current mptcp_rcv_space_adjust() updates msk->rcvq_space.rtt_us with a period equal to the such field previous value. If the initial rtt_us is 40ms, its first update will happen after 40ms, even if the subflows see actual RTT orders of magnitude lower. Additionally: - setting the msk RTT to the maximum among all the subflows RTTs makes DRS constantly overshooting the rcvbuf size when a subflow has considerable higher latency than the other(s). - during unidirectional bulk transfers with multiple active subflows, the TCP-level RTT estimator occasionally sees considerably higher value than the real link delay, i.e. when the packet scheduler reacts to an incoming ACK on given subflow pushing data on a different subflow. - currently inactive but still open subflows (i.e. switched to backup mode) are always considered when computing the msk-level RTT. Address the all the issues above with a more accurate RTT estimation strategy: the MPTCP-level RTT is set to the minimum of all the subflows actually feeding data into the MPTCP receive buffer, using a small sliding window. While at it, also use EWMA to compute the msk-level scaling_ratio, to that MPTCP can avoid traversing the subflow list is mptcp_rcv_space_adjust(). Use some care to avoid updating msk and ssk level fields too often. Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning") Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260407-net-next-mptcp-reduce-rbuf-v2-1-0d1d135bf6f6@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 909cda163abc5d6bc1f10747926710b6db3177a8 Author: Daniel Borkmann Date: Wed Apr 8 21:12:41 2026 +0200 bpf: Remove static qualifier from local subprog pointer [ Upstream commit 9dba0ae973e75051b63cbdd5b3532bb24aa63b3f ] The local subprog pointer in create_jt() and visit_abnormal_return_insn() was declared static. It is unconditionally assigned via bpf_find_containing_subprog() before every use. Thus, the static qualifier serves no purpose and rather creates confusion. Just remove it. Fixes: e40f5a6bf88a ("bpf: correct stack liveness for tail calls") Fixes: 493d9e0d6083 ("bpf, x86: add support for indirect jumps") Signed-off-by: Daniel Borkmann Acked-by: Anton Protopopov Link: https://lore.kernel.org/r/20260408191242.526279-3-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d846d83bdacbd8f14fc45c63b8c1d22608452e1c Author: Daniel Borkmann Date: Wed Apr 8 21:12:40 2026 +0200 bpf: Fix ld_{abs,ind} failure path analysis in subprogs [ Upstream commit ee861486e377edc55361c08dcbceab3f6b6577bd ] Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side. Fixes: 09b28d76eac4 ("bpf: Add abnormal return checks.") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260408191242.526279-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 945816e63c8677cf4bfde963a0774432ce8afc85 Author: Daniel Borkmann Date: Wed Apr 8 21:12:39 2026 +0200 bpf: Propagate error from visit_tailcall_insn [ Upstream commit 6bd96e40f31dde8f8cd79772b4df0f171cf8a915 ] Commit e40f5a6bf88a ("bpf: correct stack liveness for tail calls") added visit_tailcall_insn() but did not check its return value. Fixes: e40f5a6bf88a ("bpf: correct stack liveness for tail calls") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260408191242.526279-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b4c8370b76fe90b6dc72c0bde6cf6269afcf2987 Author: Wang Wensheng Date: Sun Apr 5 19:42:31 2026 +0800 arm64: kexec: Remove duplicate allocation for trans_pgd [ Upstream commit ee020bf6f14094c9ae434bb37e6957a1fdad513c ] trans_pgd would be allocated in trans_pgd_create_copy(), so remove the duplicate allocation before calling trans_pgd_create_copy(). Fixes: 3744b5280e67 ("arm64: kexec: install a copy of the linear-map") Signed-off-by: Wang Wensheng Reviewed-by: Pasha Tatashin Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 797a93ac0aaddefbb90b57f80991eb353226313a Author: Haoyu Lu Date: Tue Apr 7 11:31:15 2026 +0800 ACPI: AGDI: fix missing newline in error message [ Upstream commit b178330b67abb7293b6de28b2a49d49c83962db5 ] Add the missing trailing newline to the dev_err() message printed when SDEI event registration fails. This keeps the error output as a properly terminated log line. Fixes: a2a591fb76e6 ("ACPI: AGDI: Add driver for Arm Generic Diagnostic Dump and Reset device") Reviewed-by: Ilkka Koskinen Signed-off-by: Haoyu Lu Reviewed-by: Hanjun Guo Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 9a1b9826e4d6507e9ad26ca628a930003429f82f Author: Mark Rutland Date: Tue Apr 7 14:16:46 2026 +0100 arm64: entry: Don't preempt with SError or Debug masked [ Upstream commit 2371bd83b3df9d833191fe58dadb0e69a794a1cd ] On arm64, involuntary kernel preemption has been subtly broken since the move to the generic irqentry code. When preemption occurs, the new task may run with SError and Debug exceptions masked unexpectedly, leading to a loss of RAS events, breakpoints, watchpoints, and single-step exceptions. Prior to moving to the generic irqentry code, involuntary preemption of kernel mode would only occur when returning from regular interrupts, in a state where interrupts were masked and all other arm64-specific exceptions (SError, Debug, and pseudo-NMI) were unmasked. This is the only state in which it is valid to switch tasks. As part of moving to the generic irqentry code, the involuntary preemption logic was moved such that involuntary preemption could occur when returning from any (non-NMI) exception. As most exception handlers mask all arm64-specific exceptions before this point, preemption could occur in a state where arm64-specific exceptions were masked. This is not a valid state to switch tasks, and resulted in the loss of exceptions described above. As a temporary bodge, avoid the loss of exceptions by avoiding involuntary preemption when SError and/or Debug exceptions are masked. Practically speaking this means that involuntary preemption will only occur when returning from regular interrupts, as was the case before moving to the generic irqentry code. Fixes: 99eb057ccd67 ("arm64: entry: Move arm64_preempt_schedule_irq() into __exit_to_kernel_mode()") Reported-by: Ada Couprie Diaz Reported-by: Vladimir Murzin Signed-off-by: Mark Rutland Cc: Andy Lutomirski Cc: Jinjie Ruan Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Reviewed-by: Jinjie Ruan Acked-by: Peter Zijlstra (Intel) Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 9d4f5c68f5ad4ab425f3ce1500c97c9f9743999a Author: Eric Dumazet Date: Fri Apr 3 22:15:40 2026 +0000 net: pull headers in qdisc_pkt_len_segs_init() [ Upstream commit 7fb4c19670110f052c04e1ec1d2b953b9f4f57e4 ] Most ndo_start_xmit() methods expects headers of gso packets to be already in skb->head. net/core/tso.c users are particularly at risk, because tso_build_hdr() does a memcpy(hdr, skb->data, hdr_len); qdisc_pkt_len_segs_init() already does a dissection of gso packets. Use pskb_may_pull() instead of skb_header_pointer() to make sure drivers do not have to reimplement this. Some malicious packets could be fed, detect them so that we can drop them sooner with a new SKB_DROP_REASON_SKB_BAD_GSO drop_reason. Fixes: e876f208af18 ("net: Add a software TSO helper API") Signed-off-by: Eric Dumazet Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260403221540.3297753-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6f9b0fe005c0f898c3d8a95f686f4cf4df956ad8 Author: Eric Dumazet Date: Fri Apr 3 22:15:39 2026 +0000 net: qdisc_pkt_len_segs_init() cleanup [ Upstream commit 30e02ec3b4b6bd429a4824f125eb843a291dcccf ] Reduce indentation level by returning early if the transport header was not set. Add an unlikely() clause as this is not the common case. No functional change. Signed-off-by: Eric Dumazet Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260403221540.3297753-2-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()") Signed-off-by: Sasha Levin commit 1f6a09058779c7aaa8d8f64a29d7de5373ba9ba3 Author: Eric Dumazet Date: Thu Mar 12 20:18:24 2026 +0000 net: plumb drop reasons to __dev_queue_xmit() [ Upstream commit 045f977dd4ebdd3ad8e96cf684917adfc5805adb ] Add drop reasons to __dev_queue_xmit(): - SKB_DROP_REASON_DEV_READY : device is not UP. - SKB_DROP_REASON_RECURSION_LIMIT : recursion limit on virtual device is hit. Also add an unlikely() for the SKB_DROP_REASON_DEV_READY case, and reduce indentation level. Signed-off-by: Eric Dumazet Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260312201824.203093-3-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()") Signed-off-by: Sasha Levin commit 576759658e9cdee678b8a2467af80c4042632d9a Author: Eric Dumazet Date: Thu Mar 12 20:18:23 2026 +0000 net: dropreason: add SKB_DROP_REASON_RECURSION_LIMIT [ Upstream commit d15d3de94a4766fb43d7fe7a72ed0479fb268131 ] ip[6]tunnel_xmit() can drop packets if a too deep recursion level is detected. Add SKB_DROP_REASON_RECURSION_LIMIT drop reason. We will use this reason later in __dev_queue_xmit(). Signed-off-by: Eric Dumazet Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260312201824.203093-2-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()") Signed-off-by: Sasha Levin commit cc86a8b0a1c54d2bccf6f68cf49b82dea91b84de Author: Daniel Borkmann Date: Tue Apr 7 21:24:18 2026 +0200 bpf: Fix linked reg delta tracking when src_reg == dst_reg [ Upstream commit d7f14173c0d5866c3cae759dee560ad1bed10d2e ] Consider the case of rX += rX where src_reg and dst_reg are pointers to the same bpf_reg_state in adjust_reg_min_max_vals(). The latter first modifies the dst_reg in-place, and later in the delta tracking, the subsequent is_reg_const(src_reg)/reg_const_value(src_reg) reads the post-{add,sub} value instead of the original source. This is problematic since it sets an incorrect delta, which sync_linked_regs() then propagates to linked registers, thus creating a verifier-vs-runtime mismatch. Fix it by just skipping this corner case. Fixes: 98d7ca374ba4 ("bpf: Track delta between "linked" registers.") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260407192421.508817-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fc0da559ae5adc0948b02e809cb74fbf99dca34b Author: Baochen Qiang Date: Wed Mar 25 11:05:01 2026 +0800 wifi: ath10k: fix station lookup failure during disconnect [ Upstream commit 9a34a59c6086ae731a06b3e61b0951feef758648 ] Recent commit [1] moved station statistics collection to an earlier stage of the disconnect flow. With this change in place, ath10k fails to resolve the station entry when handling a peer stats event triggered during disconnect, resulting in log messages such as: wlp58s0: deauthenticating from 74:1a:e0:e7:b4:c8 by local choice (Reason: 3=DEAUTH_LEAVING) ath10k_pci 0000:3a:00.0: not found station for peer stats ath10k_pci 0000:3a:00.0: failed to parse stats info tlv: -22 The failure occurs because ath10k relies on ieee80211_find_sta_by_ifaddr() for station lookup. That function uses local->sta_hash, but by the time the peer stats request is triggered during disconnect, mac80211 has already removed the station from that hash table, leading to lookup failure. Before commit [1], this issue was not visible because the transition from IEEE80211_STA_NONE to IEEE80211_STA_NOTEXIST prevented ath10k from sending a peer stats request at all: ath10k_mac_sta_get_peer_stats_info() would fail early to find the peer and skip requesting statistics. Fix this by switching the lookup path to ath10k_peer_find(), which queries ath10k's internal peer table. At the point where the firmware emits the peer stats event, the peer entry is still present in the driver's list, ensuring lookup succeeds. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1 Fixes: a203dbeeca15 ("wifi: mac80211: collect station statistics earlier when disconnect") # [1] Reported-by: Paul Menzel Closes: https://lore.kernel.org/ath10k/57671b89-ec9f-4e6c-992c-45eb8e75929c@molgen.mpg.de Signed-off-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Reviewed-by: Paul Menzel Tested-by: Paul Menzel Link: https://patch.msgid.link/20260325-ath10k-station-lookup-failure-v1-1-2e0c970f25d5@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b5114367ae678f6b389a2c8adba2e6c0fcaa7ae2 Author: Andrey Grodzovsky Date: Tue Apr 7 16:39:11 2026 -0400 bpf: Prefer vmlinux symbols over module symbols for unqualified kprobes [ Upstream commit 1870ddcd94b061f54613b90d6300a350f29fc2f4 ] When an unqualified kprobe target exists in both vmlinux and a loaded module, number_of_same_symbols() returns a count greater than 1, causing kprobe attachment to fail with -EADDRNOTAVAIL even though the vmlinux symbol is unambiguous. When no module qualifier is given and the symbol is found in vmlinux, return the vmlinux-only count without scanning loaded modules. This preserves the existing behavior for all other cases: - Symbol only in a module: vmlinux count is 0, falls through to module scan as before. - Symbol qualified with MOD:SYM: mod != NULL, unchanged path. - Symbol ambiguous within vmlinux itself: count > 1 is returned as-is. Fixes: 926fe783c8a6 ("tracing/kprobes: Fix symbol counting logic by looking at modules as well") Fixes: 9d8616034f16 ("tracing/kprobes: Add symbol counting check when module loads") Suggested-by: Ihor Solodrai Acked-by: Jiri Olsa Acked-by: Ihor Solodrai Signed-off-by: Andrey Grodzovsky Link: https://lore.kernel.org/r/20260407203912.1787502-2-andrey.grodzovsky@crowdstrike.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 99dbab7b5a12d8f58d5b0aa2f7a1fe656a70f4b2 Author: Weiming Shi Date: Sun Apr 5 00:12:20 2026 +0800 bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() [ Upstream commit 1c22483a2c4bbf747787f328392ca3e68619c4dc ] CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. "0:1:2" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf("%d"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing. Fixes: ddc7c3042614 ("libbpf: implement BPF CO-RE offset relocation algorithm") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Emil Tsalapatis Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260404161221.961828-2-bestswngs@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 989f1b93907de1753a814996222da375f07e579b Author: Jiayuan Chen Date: Tue Apr 7 20:23:33 2026 +0800 bpf: Drop task_to_inode and inet_conn_established from lsm sleepable hooks [ Upstream commit beaf0e96b1da74549a6cabd040f9667d83b2e97e ] bpf_lsm_task_to_inode() is called under rcu_read_lock() and bpf_lsm_inet_conn_established() is called from softirq context, so neither hook can be used by sleepable LSM programs. Fixes: 423f16108c9d8 ("bpf: Augment the set of sleepable LSM hooks") Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn> Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reported-by: Dongliang Mu Closes: https://lore.kernel.org/bpf/3ab69731-24d1-431a-a351-452aafaaf2a5@std.uestc.edu.cn/T/#u Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260407122334.344072-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit b151c936cc197ae296cb2ab8bd55836fdeea29e0 Author: Nicolas Escande Date: Fri Mar 27 11:02:56 2026 +0100 wifi: mac80211: handle VHT EXT NSS in ieee80211_determine_our_sta_mode() [ Upstream commit b5b8e295973083abf823fb66647a7c702a8db8a7 ] A station which has a NSS ratio on the number of streams it is capable of in 160MHz VHT operation is supposed to use the 'Extended NSS BW Support' as defined by section '9.4.2.156.2 VHT Capabilities Information field'. This was missing in ieee80211_determine_our_sta_mode() and so we would wrongfully downgrade our bandwidth when connecting to an AP that supported 160MHz with messages such as: [ 37.638346] wlan1: AP XX:XX:XX:XX:XX:XX changed bandwidth in assoc response, new used config is 5280.000 MHz, width 3 (5290.000/0 MHz) Fixes: 310c8387c638 ("wifi: mac80211: clean up connection process") Signed-off-by: Nicolas Escande Link: https://patch.msgid.link/20260327100256.3101348-1-nico.escande@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 334c68750eee84c2327db1d152be83ff5ad8e20b Author: Ethan Tidmore Date: Mon Feb 16 20:30:43 2026 -0600 wifi: brcmfmac: Fix error pointer dereference [ Upstream commit dd8592fc6007a451c3e4b9025de365e39de8178a ] The function brcmf_chip_add_core() can return an error pointer and is not checked. Add checks for error pointer. Detected by Smatch: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() Fixes: cb7cf7be9eba7 ("brcmfmac: make chip related functions host interface independent") Signed-off-by: Ethan Tidmore Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260217023043.73631-1-ethantidmore06@gmail.com [add missing wifi: prefix] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 99187ab458063d3ae3a03516958c2e1dd10c7ca2 Author: Arnd Bergmann Date: Thu Apr 2 20:46:54 2026 +0200 net: ethernet: ti-cpsw: fix linking built-in code to modules [ Upstream commit df75bd552a8790e83d4aeb5f112050cf3dc687bf ] There are six variants of the cpsw driver, sharing various parts of the code: davinci-emac, cpsw, cpsw-switchdev, netcp, netcp_ethss and am65-cpsw-nuss. I noticed that this means some files can be linked into more than one loadable module, or even part of vmlinux but also linked into a loadable module, both of which mess up assumptions of the build system, and causes warnings: scripts/Makefile.build:279: cpsw_ale.o is added to multiple modules: ti-am65-cpsw-nuss ti_cpsw ti_cpsw_new scripts/Makefile.build:279: cpsw_priv.o is added to multiple modules: ti_cpsw ti_cpsw_new scripts/Makefile.build:279: cpsw_sl.o is added to multiple modules: ti-am65-cpsw-nuss ti_cpsw ti_cpsw_new scripts/Makefile.build:279: cpsw_ethtool.o is added to multiple modules: ti_cpsw ti_cpsw_new scripts/Makefile.build:279: davinci_cpdma.o is added to multiple modules: ti_cpsw ti_cpsw_new ti_davinci_emac Change this back to having separate modules for each portion that can be linked standalone, exporting symbols as needed: - ti-cpsw-common.ko now contains both cpsw-common.o and davinci_cpdma.o as they are always used together - ti-cpsw-priv.ko contains cpsw_priv.o, cpsw_sl.o and cpsw_ethtool.o, which are the core of the cpsw and cpsw-new drivers. - ti-cpsw-sl.ko contains the cpsw-sl.o object and is used on ti-am65-cpsw-nuss.ko in addition to the two other cpsw variants. - ti-cpsw-ale.o is the one standalone module that is used by all except davinci_emac. Each of these will be built-in if any of its users are built-in, otherwise it's a loadable module if there is at least one module using it. I did not bring back the separate Kconfig symbols for this, but just handle it using Makefile logic. Note: ideally this is something that Kbuild complains about, but usually we just notice when something using THIS_MODULE misbehaves in a way that a user notices. Fixes: 99f6297182729 ("net: ethernet: ti: cpsw: drop TI_DAVINCI_CPDMA config option") Link: https://lore.kernel.org/lkml/20240417084400.3034104-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260402184726.3746487-2-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9104ae36d6ed0d9802efb9b5bf30747910a416e4 Author: Arnd Bergmann Date: Thu Apr 2 20:46:53 2026 +0200 net: ethernet: ti-cpsw:: rename soft_reset() function [ Upstream commit 961f3c535608df64553f61d64ca086aa9f371bdd ] While looking at the glob symbols shared between the cpsw drivers, I noticed that soft_reset() is the only one that is missing a proper namespace prefix, and will pollute the kernel namespace, so rename it to be consistent with the other symbols. Reviewed-by: Alexander Sverdlin Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260402184726.3746487-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: df75bd552a87 ("net: ethernet: ti-cpsw: fix linking built-in code to modules") Signed-off-by: Sasha Levin commit c79f8503d83d4665be461fb9e45e215d0380c67b Author: MingTao Huang Date: Thu Apr 2 20:18:50 2026 +0800 bpf: Fix stale offload->prog pointer after constant blinding [ Upstream commit a1aa9ef47c299c5bbc30594d3c2f0589edf908e6 ] When a dev-bound-only BPF program (BPF_F_XDP_DEV_BOUND_ONLY) undergoes JIT compilation with constant blinding enabled (bpf_jit_harden >= 2), bpf_jit_blind_constants() clones the program. The original prog is then freed in bpf_jit_prog_release_other(), which updates aux->prog to point to the surviving clone, but fails to update offload->prog. This leaves offload->prog pointing to the freed original program. When the network namespace is subsequently destroyed, cleanup_net() triggers bpf_dev_bound_netdev_unregister(), which iterates ondev->progs and calls __bpf_prog_offload_destroy(offload->prog). Accessing the freed prog causes a page fault: BUG: unable to handle page fault for address: ffffc900085f1038 Workqueue: netns cleanup_net RIP: 0010:__bpf_prog_offload_destroy+0xc/0x80 Call Trace: __bpf_offload_dev_netdev_unregister+0x257/0x350 bpf_dev_bound_netdev_unregister+0x4a/0x90 unregister_netdevice_many_notify+0x2a2/0x660 ... cleanup_net+0x21a/0x320 The test sequence that triggers this reliably is: 1. Set net.core.bpf_jit_harden=2 (echo 2 > /proc/sys/net/core/bpf_jit_harden) 2. Run xdp_metadata selftest, which creates a dev-bound-only XDP program on a veth inside a netns (./test_progs -t xdp_metadata) 3. cleanup_net -> page fault in __bpf_prog_offload_destroy Dev-bound-only programs are unique in that they have an offload structure but go through the normal JIT path instead of bpf_prog_offload_compile(). This means they are subject to constant blinding's prog clone-and-replace, while also having offload->prog that must stay in sync. Fix this by updating offload->prog in bpf_jit_prog_release_other(), alongside the existing aux->prog update. Both are back-pointers to the prog that must be kept in sync when the prog is replaced. Fixes: 2b3486bc2d23 ("bpf: Introduce device-bound XDP programs") Signed-off-by: MingTao Huang Link: https://lore.kernel.org/r/tencent_BCF692F45859CCE6C22B7B0B64827947D406@qq.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fc39753b7f92e09177777e9c648afe5aa3abb81f Author: Weiming Shi Date: Fri Apr 3 21:29:50 2026 +0800 bpf: fix end-of-list detection in cgroup_storage_get_next_key() [ Upstream commit 5828b9e5b272ecff7cf5d345128d3de7324117f7 ] list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries. Fixes: de9cbbaadba5 ("bpf: introduce cgroup storage maps") Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: Sun Jian Acked-by: Paul Chaignon Link: https://lore.kernel.org/r/20260403132951.43533-2-bestswngs@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5584db6425cf570cad36ce005ab3d4379055b912 Author: Mykyta Yatsenko Date: Wed Apr 1 06:50:36 2026 -0700 bpf: Use copy_map_value_locked() in alloc_htab_elem() for BPF_F_LOCK [ Upstream commit 07738bc566c38e0a8c82084e962890d1d59715c8 ] When a BPF_F_LOCK update races with a concurrent delete, the freed element can be immediately recycled by alloc_htab_elem(). The fast path in htab_map_update_elem() performs a lockless lookup and then calls copy_map_value_locked() under the element's spin_lock. If alloc_htab_elem() recycles the same memory, it overwrites the value with plain copy_map_value(), without taking the spin_lock, causing torn writes. Use copy_map_value_locked() when BPF_F_LOCK is set so the new element's value is written under the embedded spin_lock, serializing against any stale lock holders. Fixes: 96049f3afd50 ("bpf: introduce BPF_F_LOCK flag") Reported-by: Aaron Esau Closes: https://lore.kernel.org/all/CADucPGRvSRpkneb94dPP08YkOHgNgBnskTK6myUag_Mkjimihg@mail.gmail.com/ Signed-off-by: Mykyta Yatsenko Link: https://lore.kernel.org/r/20260401-bpf_map_torn_writes-v1-1-782d071c55e7@meta.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 584a5e48dba6df8f842bb1d34b1219db8b8a345c Author: Eric Dumazet Date: Wed Apr 1 10:38:08 2026 +0000 macvlan: annotate data-races around port->bc_queue_len_used [ Upstream commit 1ef5789d9906df3771c99b7f413caaf2bf473ca5 ] port->bc_queue_len_used is read and written locklessly, add READ_ONCE()/WRITE_ONCE() annotations. While WRITE_ONCE() in macvlan_fill_info() is not yet needed, it is a prereq for future RTNL avoidance. Fixes: d4bff72c8401 ("macvlan: Support for high multicast packet rate") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260401103809.3038139-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9836cadbd96c7e0dbb0018fa60e7872dd31ac4f8 Author: Leon Hwang Date: Tue Mar 31 22:53:52 2026 +0800 bpf: Fix abuse of kprobe_write_ctx via freplace [ Upstream commit 611fe4b79af72d00d80f2223354284447daafae9 ] uprobe programs are allowed to modify struct pt_regs. Since the actual program type of uprobe is KPROBE, it can be abused to modify struct pt_regs via kprobe+freplace when the kprobe attaches to kernel functions. For example, SEC("?kprobe") int kprobe(struct pt_regs *regs) { return 0; } SEC("?freplace") int freplace_kprobe(struct pt_regs *regs) { regs->di = 0; return 0; } freplace_kprobe prog will attach to kprobe prog. kprobe prog will attach to a kernel function. Without this patch, when the kernel function runs, its first arg will always be set as 0 via the freplace_kprobe prog. To fix the abuse of kprobe_write_ctx=true via kprobe+freplace, disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values. Fixes: 7384893d970e ("bpf: Allow uprobe program to change context registers") Acked-by: Jiri Olsa Acked-by: Song Liu Signed-off-by: Leon Hwang Link: https://lore.kernel.org/r/20260331145353.87606-2-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7fe0d99f6848e1adb89a2f717debc374addd69df Author: Amit Machhiwal Date: Fri Mar 13 22:24:26 2026 +0530 selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15 [ Upstream commit 6e65886fceb23605eff952d6b1975737b4c4b154 ] GCC 15 reports the below false positive '-Wmaybe-uninitialized' warning in vphn_unpack_associativity() when building the powerpc selftests. # make -C tools/testing/selftests TARGETS="powerpc" [...] CC test-vphn In file included from test-vphn.c:3: In function ‘vphn_unpack_associativity’, inlined from ‘test_one’ at test-vphn.c:371:2, inlined from ‘test_vphn’ at test-vphn.c:399:9: test-vphn.c:10:33: error: ‘be_packed’ may be used uninitialized [-Werror=maybe-uninitialized] 10 | #define be16_to_cpup(x) bswap_16(*x) | ^~~~~~~~ vphn.c:42:27: note: in expansion of macro ‘be16_to_cpup’ 42 | u16 new = be16_to_cpup(field++); | ^~~~~~~~~~~~ In file included from test-vphn.c:19: vphn.c: In function ‘test_vphn’: vphn.c:27:16: note: ‘be_packed’ declared here 27 | __be64 be_packed[VPHN_REGISTER_COUNT]; | ^~~~~~~~~ cc1: all warnings being treated as errors When vphn_unpack_associativity() is called from hcall_vphn() in kernel the error is not seen while building vphn.c during kernel compilation. This is because the top level Makefile includes '-fno-strict-aliasing' flag always. The issue here is that GCC 15 emits '-Wmaybe-uninitialized' due to type punning between __be64[] and __b16* when accessing the buffer via be16_to_cpup(). The underlying object is fully initialized but GCC 15 fails to track the aliasing due to the strict aliasing violation here. Please refer [1] and [2]. This results in a false positive warning which is promoted to an error under '-Werror'. This problem is not seen when the compilation is performed with GCC 13 and 14. An issue [1] has also been created on GCC bugzilla. The selftest compiles fine with '-fno-strict-aliasing'. Since this GCC flag is used to compile vphn.c in kernel too, the same flag should be used to build vphn tests when compiling vphn.c in the selftest as well. Fix this by including '-fno-strict-aliasing' during vphn.c compilation in the selftest. This keeps the build working while limiting the scope of the suppression to building vphn tests. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124427 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99768 Fixes: 58dae82843f5 ("selftests/powerpc: Add test for VPHN") Reviewed-by: Vaibhav Jain Signed-off-by: Amit Machhiwal Tested-by: Venkat Rao Bagalkote Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260313165426.43259-1-amachhiw@linux.ibm.com Signed-off-by: Sasha Levin commit 2c381add6809a25550479b79bc3f201a262d8ff4 Author: Sourabh Jain Date: Thu Mar 12 14:00:50 2026 +0530 powerpc/crash: Update backup region offset in elfcorehdr on memory hotplug [ Upstream commit f53b24d1fa263f56155213eabab734c18d884aff ] When elfcorehdr is prepared for kdump, the program header representing the first 64 KB of memory is expected to have its offset point to the backup region. This is required because purgatory copies the first 64 KB of the crashed kernel memory to this backup region following a kernel crash. This allows the capture kernel to use the first 64 KB of memory to place the exception vectors and other required data. When elfcorehdr is recreated due to memory hotplug, the offset of the program header representing the first 64 KB is not updated. As a result, the capture kernel exports the first 64 KB at offset 0, even though the data actually resides in the backup region. Fix this by calling sync_backup_region_phdr() to update the program header offset in the elfcorehdr created during memory hotplug. sync_backup_region_phdr() works for images loaded via the kexec_file_load syscall. However, it does not work for kexec_load, because image->arch.backup_start is not initialized in that case. So introduce machine_kexec_post_load() to process the elfcorehdr prepared by kexec-tools and initialize image->arch.backup_start for kdump images loaded via kexec_load syscall. Rename update_backup_region_phdr() to sync_backup_region_phdr() and extend it to synchronize the backup region offset between the kdump image and the ELF core header. The helper now supports updating either the kdump image from the ELF program header or updating the ELF program header from the kdump image, avoiding code duplication. Define ARCH_HAS_KIMAGE_ARCH and struct kimage_arch when CONFIG_KEXEC_FILE or CONFIG_CRASH_DUMP is enabled so that kimage->arch.backup_start is available with the kexec_load system call. This patch depends on the patch titled "powerpc/crash: fix backup region offset update to elfcorehdr". Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support") Reviewed-by: Aditya Gupta Signed-off-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260312083051.1935737-3-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit ba84b18160e5a2348bded7b1a0471ba59bc641ac Author: Sourabh Jain Date: Thu Mar 12 14:00:49 2026 +0530 powerpc/crash: fix backup region offset update to elfcorehdr [ Upstream commit 789335cacdf37da93bb7c70322dff8c7e82881df ] update_backup_region_phdr() in file_load_64.c iterates over all the program headers in the kdump kernel’s elfcorehdr and updates the p_offset of the program header whose physical address starts at 0. However, the loop logic is incorrect because the program header pointer is not updated during iteration. Since elfcorehdr typically contains PT_NOTE entries first, the PT_LOAD program header with physical address 0 is never reached. As a result, its p_offset is not updated to point to the backup region. Because of this behavior, the capture kernel exports the first 64 KB of the crashed kernel’s memory at offset 0, even though that memory actually lives in the backup region. When a crash happens, purgatory copies the first 64 KB of the crashed kernel’s memory into the backup region so the capture kernel can safely use it. This has not caused problems so far because the first 64 KB is usually identical in both the crashed and capture kernels. However, this is just an assumption and is not guaranteed to always hold true. Fix update_backup_region_phdr() to correctly update the p_offset of the program header with a starting physical address of 0 by correcting the logic used to iterate over the program headers. Fixes: cb350c1f1f86 ("powerpc/kexec_file: Prepare elfcore header for crashing kernel") Reviewed-by: Aditya Gupta Signed-off-by: Sourabh Jain Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260312083051.1935737-2-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit 3f76e232e6e259d63bc537cc86a20102cace8150 Author: Masami Hiramatsu (Google) Date: Tue Feb 10 18:54:22 2026 +0900 selftests/tracing: Fix to check awk supports non POSIX strtonum() [ Upstream commit 3d0b8e45075d398369eb07e11f529c17a63cf5e1 ] Check the awk command supports non POSIX strtonum() function in the trace_marker_raw test case. Fixes: 37f46601383a ("selftests/tracing: Add basic test for trace_marker_raw file") Signed-off-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/177071726229.2369897.11506524546451139051.stgit@mhiramat.tok.corp.google.com Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 86f5197f3e746592249774f79213aff67b931a8b Author: Masami Hiramatsu (Google) Date: Tue Feb 10 18:54:12 2026 +0900 selftests/tracing: Fix to make --logdir option work again [ Upstream commit e011853dd78f97898ae8e0b0b949603987e24c4b ] Since commit a0aa283c53a7 ("selftest/ftrace: Generalise ftracetest to use with RV") moved the default LOG_DIR setting after --logdir option parser, it overwrites the user given LOG_DIR. This fixes it to check the --logdir option parameter when setting new default LOG_DIR with a new TOP_DIR. Fixes: a0aa283c53a7 ("selftest/ftrace: Generalise ftracetest to use with RV") Signed-off-by: Masami Hiramatsu (Google) Tested-by: Gabriele Monaco Link: https://lore.kernel.org/r/177071725191.2369897.14781037901532893911.stgit@mhiramat.tok.corp.google.com Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit e06b8763600211a1fea3085bef61a2863aab5ac5 Author: Chih Kai Hsu Date: Thu Mar 26 15:39:23 2026 +0800 r8152: fix incorrect register write to USB_UPHY_XTAL [ Upstream commit 48afd5124fd6129c46fd12cb06155384b1c4a0c4 ] The old code used ocp_write_byte() to clear the OOBS_POLLING bit (BIT(8)) in the USB_UPHY_XTAL register, but this doesn't correctly clear a bit in the upper byte of the 16-bit register. Fix this by using ocp_write_word() instead. Fixes: 195aae321c82 ("r8152: support new chips") Signed-off-by: Chih Kai Hsu Reviewed-by: Hayes Wang Link: https://patch.msgid.link/20260326073925.32976-454-nic_swsd@realtek.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 69d0f1fff365b844d2cd4098bde4faf0cd105a5d Author: Ritesh Harjani (IBM) Date: Mon Mar 9 18:08:37 2026 +0530 drivers/vfio_pci_core: Change PXD_ORDER check from switch case to if/else block [ Upstream commit 948b71aa81cd89b222942db6055e8d9c51c54e78 ] Architectures like PowerPC uses runtime defined values for PMD_ORDER/PUD_ORDER. This is because it can use either RADIX or HASH MMU at runtime using kernel cmdline. So the pXd_index_size is not known at compile time. Without this fix, when we add huge pfn support on powerpc in the next patch, vfio_pci_core driver compilation can fail with the following errors. CC [M] drivers/vfio/vfio_main.o CC [M] drivers/vfio/group.o CC [M] drivers/vfio/container.o CC [M] drivers/vfio/virqfd.o CC [M] drivers/vfio/vfio_iommu_spapr_tce.o CC [M] drivers/vfio/pci/vfio_pci_core.o CC [M] drivers/vfio/pci/vfio_pci_intrs.o CC [M] drivers/vfio/pci/vfio_pci_rdwr.o CC [M] drivers/vfio/pci/vfio_pci_config.o CC [M] drivers/vfio/pci/vfio_pci.o AR kernel/built-in.a ../drivers/vfio/pci/vfio_pci_core.c: In function ‘vfio_pci_vmf_insert_pfn’: ../drivers/vfio/pci/vfio_pci_core.c:1678:9: error: case label does not reduce to an integer constant 1678 | case PMD_ORDER: | ^~~~ ../drivers/vfio/pci/vfio_pci_core.c:1682:9: error: case label does not reduce to an integer constant 1682 | case PUD_ORDER: | ^~~~ make[6]: *** [../scripts/Makefile.build:289: drivers/vfio/pci/vfio_pci_core.o] Error 1 make[6]: *** Waiting for unfinished jobs.... make[5]: *** [../scripts/Makefile.build:546: drivers/vfio/pci] Error 2 make[5]: *** Waiting for unfinished jobs.... make[4]: *** [../scripts/Makefile.build:546: drivers/vfio] Error 2 make[3]: *** [../scripts/Makefile.build:546: drivers] Error 2 Fixes: f9e54c3a2f5b7 ("vfio/pci: implement huge_fault support") Signed-off-by: Ritesh Harjani (IBM) Tested-by: Venkat Rao Bagalkote Reviewed-by: Alex Williamson Reviewed-by: Christophe Leroy (CS GROUP) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/b155e19993ee1f5584c72050192eb468b31c5029.1773058761.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit 2c23b309c04d780cf8d75355ab9e8515eb5f143a Author: Alexey Velichayshiy Date: Mon Mar 23 17:05:53 2026 +0300 wifi: rtw89: phy: fix uninitialized variable access in rtw89_phy_cfo_set_crystal_cap() [ Upstream commit 047cddf88c611e616d49a00311d4722e46286234 ] In the rtw89_phy_cfo_set_crystal_cap() function, for chips other than RTL8852A/RTL8851B, the values read by rtw89_mac_read_xtal_si() are stored into the local variables sc_xi_val and sc_xo_val. If either read fails, these variables remain uninitialized, they are later used to update cfo->crystal_cap and in debug print statements. This can lead to undefined behavior. Fix the issue by initializing sc_xi_val and sc_xo_val to zero, like is implemented in vendor driver. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 8379fa611536 ("rtw89: 8852c: add write/read crystal function in CFO tracking") Signed-off-by: Alexey Velichayshiy Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260323140613.1615574-1-a.velichayshiy@ispras.ru Signed-off-by: Sasha Levin commit f2d65e4ba4ead28e5ecbae1fd0710fb906d290a5 Author: haoyu.lu Date: Tue Mar 24 20:27:02 2026 +0800 bpf,arc_jit: Fix missing newline in pr_err messages [ Upstream commit b6b5e0ebd429d66ce37ae5af649a74ea1f041d92 ] Add missing newline to pr_err messages in ARC JIT. Fixes: f122668ddcce ("ARC: Add eBPF JIT support") Signed-off-by: haoyu.lu Link: https://lore.kernel.org/r/20260324122703.641-1-hechushiguitu666@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 72480ec9b0955fc2398834970015cf4009f0db6e Author: Ben Horgan Date: Fri Mar 13 14:45:39 2026 +0000 arm_mpam: Reset when feature configuration bit unset [ Upstream commit a1cb6577f575ba5ec2583caf4f791a86754dbf69 ] To indicate that the configuration, of the controls used by resctrl, in a RIS need resetting to driver defaults the reset flags in mpam_config are set. However, these flags are only ever set temporarily at RIS scope in mpam_reset_ris() and hence mpam_cpu_online() will never reset these controls to default. As the hardware reset is unknown this leads to unknown configuration when the control values haven't been configured away from the defaults. Use the policy that an unset feature configuration bit means reset. In this way the mpam_config in the component can encode that it should be in reset state and mpam_reprogram_msc() will reset controls as needed. Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online") Signed-off-by: Ben Horgan Reviewed-by: Gavin Shan Reviewed-by: James Morse Tested-by: Gavin Shan Tested-by: Shaopeng Tan Tested-by: Jesse Chick [ morse: Removed unused reset flags from config structure ] Signed-off-by: James Morse Signed-off-by: Sasha Levin commit 98c522c9b17c89011038fda2f2b342ca4c5e9bf3 Author: Zeng Heng Date: Fri Mar 13 14:45:38 2026 +0000 arm_mpam: Ensure in_reset_state is false after applying configuration [ Upstream commit f91e913355f49c878fc77f995fd71b7800352bd2 ] The per-RIS flag, in_reset_state, indicates whether or not the MSC registers are in reset state, and allows avoiding resetting when they are already in reset state. However, when mpam_apply_config() updates the configuration it doesn't update the in_reset_state flag and so even after the configuration update in_reset_state can be true and mpam_reset_ris() will skip the actual register restoration on subsequent resets. Once resctrl has a MPAM backend it will use resctrl_arch_reset_all_ctrls() to reset the MSC configuration on unmount and, if the in_reset_state flag is bogusly true, fail to reset the MSC configuration. The resulting non-reset MSC configuration can lead to persistent performance restrictions even after resctrl is unmounted. Fix by clearing in_reset_state to false immediately after successful configuration application, ensuring that the next reset operation properly restores MSC register defaults. Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online") Signed-off-by: Zeng Heng Acked-by: Ben Horgan [Horgan: rewrite commit message to not be specific to resctrl unmount] Signed-off-by: Ben Horgan Reviewed-by: Gavin Shan Reviewed-by: Jonathan Cameron Reviewed-by: James Morse Tested-by: Gavin Shan Tested-by: Shaopeng Tan Tested-by: Jesse Chick Signed-off-by: James Morse Signed-off-by: Sasha Levin commit 02bddee68a53a26e67de89882035a3836fd01dba Author: Alexei Starovoitov Date: Tue Mar 24 14:59:36 2026 -0700 bpf: Fix variable length stack write over spilled pointers [ Upstream commit 4639eb9e30ab10c7935c7c19e872facf9a94713f ] Scrub slots if variable-offset stack write goes over spilled pointers. Otherwise is_spilled_reg() may == true && spilled_ptr.type == NOT_INIT and valid program is rejected by check_stack_read_fixed_off() with obscure "invalid size of register fill" message. Fixes: 01f810ace9ed ("bpf: Allow variable-offset stack access") Acked-by: Eduard Zingerman Acked-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20260324215938.81733-1-alexei.starovoitov@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7027e705062482a8cea43a1c13ede3c35653966f Author: David Carlier Date: Fri Mar 20 07:26:45 2026 +0000 bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path [ Upstream commit 8ed82f807bb09d2c8455aaa665f2c6cb17bc6a19 ] The DEVMAP_HASH branch in dev_map_redirect_multi() uses hlist_for_each_entry_safe() to iterate hash buckets, but this function runs under RCU protection (called from xdp_do_generic_redirect_map() in softirq context). Concurrent writers (__dev_map_hash_update_elem, dev_map_hash_delete_elem) modify the list using RCU primitives (hlist_add_head_rcu, hlist_del_rcu). hlist_for_each_entry_safe() performs plain pointer dereferences without rcu_dereference(), missing the acquire barrier needed to pair with writers' rcu_assign_pointer(). On weakly-ordered architectures (ARM64, POWER), a reader can observe a partially-constructed node. It also defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race detection. Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held() as the lockdep condition, consistent with the rcu_dereference_check() used in the DEVMAP (non-hash) branch of the same functions. Also fix the same incorrect lockdep_is_held(&dtab->index_lock) condition in dev_map_enqueue_multi(), where the lock is not held either. Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support") Signed-off-by: David Carlier Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/20260320072645.16731-1-devnexen@gmail.com Signed-off-by: Sasha Levin commit bfa998d8b1aafc4b32af5f5b214e18f694a81bd5 Author: Jiayuan Chen Date: Thu Mar 12 15:25:44 2026 +0800 selftests/bpf: Fix sockmap_multi_channels reliability [ Upstream commit d9d7125e445dc06c2d9bd3dbd070dcbcd41a540f ] Previously I added a FIONREAD test for sockmap, but it can occasionally fail in CI [1]. The test sends 10 bytes in two segments (2 + 8). For UDP, FIONREAD only reports the length of the first datagram, not the total queued data. The original code used recv_timeout() expecting all 10 bytes, but under high system load, the second datagram may not yet be processed by the protocol stack, so recv would only return the first 2-byte datagram, causing a size mismatch failure. Fix this by receiving exactly the expected bytes (matching FIONREAD) in the first recv. The remaining datagram is then consumed in a second recv block, which is only reachable for UDP since TCP's expected already equals sizeof(buf). Test: ./test_progs -a sockmap_basic 410/1 sockmap_basic/sockmap create_update_free:OK ... Summary: 1/35 PASSED, 0 SKIPPED, 0 FAILED [1] https://github.com/kernel-patches/bpf/actions/runs/22919385910/job/66515395423 Cc: Jiayuan Chen Fixes: 17e2ce02bf56 ("selftests/bpf: Add tests for FIONREAD and copied_seq") Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20260312072549.6766-1-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 8697bfcca38d09b8a18a66c56b8a050e6004fadb Author: Keisuke Nishimura Date: Fri Mar 20 14:02:20 2026 +0100 bpf: Fix refcount check in check_struct_ops_btf_id() [ Upstream commit 25e3e1f1096089a64901ae1faa7b7b13446653db ] The current implementation only checks whether the first argument is refcounted. Fix this by iterating over all arguments. Signed-off-by: Keisuke Nishimura Fixes: 38f1e66abd184 ("bpf: Do not allow tail call in strcut_ops program with __ref argument") Reviewed-by: Emil Tsalapatis Acked-by: Amery Hung Link: https://lore.kernel.org/r/20260320130219.63711-1-keisuke.nishimura@inria.fr Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 906321e6720a6ac76854410bb80eb8e3ba4cd5d3 Author: Peter Chiu Date: Thu Mar 12 17:57:19 2026 +0800 wifi: mt76: mt7996: fix RRO EMU configuration [ Upstream commit 73b46379e5231138025b271ce8e158d2a8aa0768 ] Use the correct helper to update specific bitfields instead of overwriting the entire register. Fixes: eedb427eb260 ("wifi: mt76: mt7996: Enable HW RRO for MT7992 chipset") Signed-off-by: Peter Chiu Signed-off-by: Shayne Chen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260312095724.2117448-1-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 18461d78d2d976c476fab8710f8464ae3051c2bf Author: Chad Monroe Date: Mon Mar 9 06:07:21 2026 +0000 wifi: mt76: support upgrading passive scans to active [ Upstream commit 360552c8592dab3c69e0bbff786b55137f1a81bb ] On channels with NO_IR or RADAR flags, wait for beacon before sending probe requests. Allows active scanning and WPS on restricted channels if another AP is already present. Fixes: c56d6edebc1f ("wifi: mt76: mt7996: use emulated hardware scan support") Tested-by: Piotr Kubik Signed-off-by: Chad Monroe Link: https://patch.msgid.link/20251118102723.47997-2-nbd@nbd.name Link: https://patch.msgid.link/20260309060730.87840-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3ac404b184eca27f9cfc7e027d3c15922f6e2c8d Author: Chad Monroe Date: Mon Mar 9 06:07:20 2026 +0000 wifi: mt76: fix multi-radio on-channel scanning [ Upstream commit 0420180df092419a96351fb2afec1e2a74d385c3 ] avoid unnecessary channel switch when performing an on-channel scan using a multi-radio device. Fixes: c56d6edebc1f ("wifi: mt76: mt7996: use emulated hardware scan support") Signed-off-by: Chad Monroe Link: https://patch.msgid.link/20251118102723.47997-1-nbd@nbd.name Link: https://patch.msgid.link/20260309060730.87840-1-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 575bc4ff893564e698f067568eea50c14a667641 Author: Lorenzo Bianconi Date: Sun Mar 8 14:25:20 2026 +0100 wifi: mt76: mt7996: Decrement sta counter removing the link in mt7996_mac_reset_sta_iter() [ Upstream commit e648051d52afbdb360bd586218961f5fffff63e8 ] Fixes tracking per-phy stations for offchannel switching. Fixes: ace5d3b6b49e8 ("wifi: mt76: mt7996: improve hardware restart reliability") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260308-mt7996_mac_reset_vif_iter-fix-v1-1-57f640aa2dcf@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ed66bd266e50c0da95961db08af38b9d2f88db11 Author: Lorenzo Bianconi Date: Fri Mar 6 11:27:52 2026 +0100 wifi: mt76: mt7996: Remove link pointer dependency in mt7996_mac_sta_remove_links() [ Upstream commit 569ce4340268915911fc356ec9ad27e92fb82289 ] Remove link pointer dependency in mt7996_mac_sta_remove_links routine to get the mt7996_phy pointer since the link can be already offchannel running mt7996_mac_sta_remove_links(). Rely on __mt7996_phy routine instead. Fixes: 344dd6a4c919 ("wifi: mt76: mt7996: Move num_sta accounting in mt7996_mac_sta_{add,remove}_links") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260306-mt7996-deflink-lookup-link-remove-v1-1-7162b332873c@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 27727119a47ff580438d7dd46e3038ad1fe5ea46 Author: Lorenzo Bianconi Date: Sun Sep 28 18:27:01 2025 +0200 wifi: mt76: mt7996: Add missing CHANCTX_STA_CSA property [ Upstream commit c0a47ffc4caaf5161955add553322112c3a211b0 ] Enable missing CHANCTX_STA_CSA property required for MLO. Fixes: f5160304d57c ("wifi: mt76: mt7996: Enable MLO support for client interfaces") Signed-off-by: Lorenzo Bianconi Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20250928-mt7996_chanctx_sta_csa-v1-1-82e455185990@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5ec9b088dcdd02a483952ac720fd8456470d46ac Author: Michael Lo Date: Wed Feb 11 17:50:25 2026 +0800 wifi: mt76: mt7921: fix 6GHz regulatory update on connection [ Upstream commit 3dc0c40d7806c72cfe88cf4e1e2650c1673f9db4 ] Call mt7921_regd_update() instead of mt7921_mcu_set_clc() when setting the 6GHz power type after connection, so that regulatory limits and SAR power are also applied. Fixes: 51ba0e3a15eb ("wifi: mt76: mt7921: add 6GHz power type support for clc") Signed-off-by: Michael Lo Link: https://patch.msgid.link/20260211095025.2415624-1-leon.yen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 188e10f9ea3109d23c6b7643aa6ec2f5cb0faa6d Author: Duoming Zhou Date: Sat Jan 31 10:47:31 2026 +0800 wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work() [ Upstream commit c8f62f73bbced3a79894655bdb0b625462d956fc ] When the mt7996 pci chip is detaching, the mt7996_crash_data is released in mt7996_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7996_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7996_pci_remove() | mt7996_sys_recovery_set() mt7996_unregister_device() | mt7996_reset() mt7996_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7996_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7996_unregister_device() to synchronize with any pending or executing dump work. Fixes: 878161d5d4a4 ("wifi: mt76: mt7996: enable coredump support") Signed-off-by: Duoming Zhou Link: https://patch.msgid.link/20260131024731.18741-1-duoming@zju.edu.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 21ce6d867867645fff0ef657be18f61d9f39dcd8 Author: Duoming Zhou Date: Fri Jan 30 22:57:59 2026 +0800 wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work() [ Upstream commit 1146d0946b5358fad24812bd39d68f31cd40cc34 ] When the mt7915 pci chip is detaching, the mt7915_crash_data is released in mt7915_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7915_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7915_pci_remove() | mt7915_sys_recovery_set() mt7915_unregister_device() | mt7915_reset() mt7915_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7915_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7915_unregister_device() to synchronize with any pending or executing dump work. Fixes: 4dbcb9125cc3 ("wifi: mt76: mt7915: enable coredump support") Signed-off-by: Duoming Zhou Link: https://patch.msgid.link/20260130145759.84272-1-duoming@zju.edu.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 45d9133523f2bb71c6cb41744026f0e50a7bdc9a Author: StanleyYP Wang Date: Tue Feb 3 23:55:30 2026 +0800 wifi: mt76: mt7996: fix struct mt7996_mcu_uni_event [ Upstream commit efbd5bf395f4e6b45a87f3835d4c2e28170c77c5 ] The cid field is defined as a two-byte value in the firmware. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: StanleyYP Wang Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260203155532.1098290-2-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 44dee15fb86de12925b573a1ab19b4b7ef72c467 Author: Shayne Chen Date: Tue Feb 3 23:55:29 2026 +0800 wifi: mt76: mt7996: fix wrong DMAD length when using MAC TXP [ Upstream commit 97b9f9831bf297f3ffa62018721601ed2736f2c3 ] The struct mt76_connac_fw_txp is used for HIF TXP. Change to use the struct mt76_connac_hw_txp to fix the wrong DMAD length for MAC TXP. Fixes: cb6ebbdffef2 ("wifi: mt76: mt7996: support writing MAC TXD for AddBA Request") Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260203155532.1098290-1-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f74fce43dbc059e059b5346a670f697c0e97b1d0 Author: Carlos Llamas Date: Thu Mar 12 18:38:17 2026 +0000 bpf: Switch CONFIG_CFI_CLANG to CONFIG_CFI [ Upstream commit 9b0cf064ea0a6bac5e1a5fb43b004fd52fbe2b3b ] This was renamed in commit 23ef9d439769 ("kcfi: Rename CONFIG_CFI_CLANG to CONFIG_CFI") as it is now a compiler-agnostic option. Using the wrong name results in the code getting compiled out. Meaning the CFI failures for btf_dtor_kfunc_t would still trigger. Fixes: 99fde4d06261 ("bpf, btf: Enforce destructor kfunc type with CFI") Signed-off-by: Carlos Llamas Reviewed-by: Sami Tolvanen Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20260312183818.2721750-1-cmllamas@google.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7a34682a4c7e21d7b6dbc3a3d22a60a07e028f33 Author: James Clark Date: Thu Mar 5 16:28:18 2026 +0000 arm64: cpufeature: Make PMUVer and PerfMon unsigned [ Upstream commit d1dcc20bcc40efe1f1c71639376c91dafa489222 ] On the host, this change doesn't make a difference because the fields are defined as FTR_EXACT. However, KVM allows userspace to set these fields for a guest and overrides the type to be FTR_LOWER_SAFE. And while KVM used to do an unsigned comparison to validate that the new value is lower than what the hardware provides, since the linked commit it uses the generic sanitization framework which does a signed comparison. Fix it by defining these fields as unsigned. In theory, without this fix, userspace could set a higher PMU version than the hardware supports by providing any value with the top bit set. Fixes: c118cead07a7 ("KVM: arm64: Use generic sanitisation for ID_(AA64)DFR0_EL1") Signed-off-by: James Clark Reviewed-by: Marc Zyngier Reviewed-by: Colton Lewis Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 02a87ef490dec333597d3945295077dbc4ac2200 Author: Allen Ye Date: Wed Feb 18 16:30:27 2026 -0800 wifi: mt76: fix backoff fields and max_power calculation [ Upstream commit 37d5b68ab57c5b4fb1c40e62c6b32376c6a2ca2c ] The maximum power value may exist in either the data or backoff field. Previously, backoff power limits were not considered in txpower reporting. This patch ensures mt76 also considers backoff values in the SKU table. Also, each RU entry (RU26, RU52, RU106, BW20, ...) in the DTS corresponds to 10 stream combinations (1T1ss, 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss, 4T3ss, 4T4ss). For beamforming tables: - In connac2, beamforming entries for BW20~BW160, and OFDM do not include 1T1ss. - In connac3, beamforming entries for BW20~BW160, and RU include 1T1ss, but OFDM beamforming does not include 1T1ss. Non-beamforming and RU entries for both connac2 and connac3 include 1T1ss. Fixes: b05ab4be9fd7 ("wifi: mt76: mt7915: add bf backoff limit table support") Signed-off-by: Allen Ye Co-developed-by: Ryder Lee Signed-off-by: Ryder Lee Link: https://patch.msgid.link/8fa8ec500b3d4de7b1966c6887f1dfbe5c46a54c.1771205424.git.ryder.lee@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7a89c245d203aa0ed5ff2d68ac05b48b2ef9fa3f Author: Chad Monroe Date: Mon Dec 8 14:31:32 2025 +0000 wifi: mt76: fix deadlock in remain-on-channel [ Upstream commit 6939b97ddad3cf3dfbb3b5a0a12ef79cb886747e ] mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel() while already holding dev->mutex. Since mt76_set_channel() also acquires dev->mutex, this results in a deadlock. Use __mt76_set_channel() instead of mt76_set_channel(). Add cancel_delayed_work_sync() for mac_work before acquiring the mutex in mt76_remain_on_channel() to prevent a secondary deadlock with the mac_work workqueue. Fixes: a8f424c1287c ("wifi: mt76: add multi-radio remain_on_channel functions") Signed-off-by: Chad Monroe Link: https://patch.msgid.link/ace737e7b621af7c2adb33b0188011a5c1de2166.1765204256.git.chad@monroe.io Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 91e77840bf13de3add125060cf8b32ca24a52c8c Author: Sean Wang Date: Mon Jan 26 12:00:13 2026 -0600 wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync [ Upstream commit d5059e52fd8bc624ec4255c9fa01a266513d126b ] roc_abort_sync() can deadlock with roc_work(). roc_work() holds dev->mt76.mutex, while cancel_work_sync() waits for roc_work() to finish. If the caller already owns the same mutex, both sides block and no progress is possible. This deadlock can occur during station removal when mt76_sta_state() -> mt76_sta_remove() -> mt7921_mac_sta_remove() -> mt7921_roc_abort_sync() invokes cancel_work_sync() while roc_work() is still running and holding dev->mt76.mutex. This avoids the mutex deadlock and preserves exactly-once work ownership. Fixes: 352d966126e6 ("wifi: mt76: mt7921: fix a potential association failure upon resuming") Co-developed-by: Quan Zhou Signed-off-by: Quan Zhou Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260126180013.8167-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f3be8313a14c7c6516bf1db290dd98d002d215ac Author: Leon Yen Date: Wed Jan 21 00:31:52 2026 +0800 wifi: mt76: mt7925: fix tx power setting failure after chip reset [ Upstream commit aae89dc4a1608da9060bada757f650ac94b7f184 ] After the chip reset, the procedure to set the tx power will not be successful because the previous region setting is still remains. Clear the region setting during MAC initialization and allow it to be reset to finalize the TX power setting. Fixes: 3bc62aa4484d ("wifi: mt76: mt7925: add auto regdomain switch support") Signed-off-by: Leon Yen Link: https://patch.msgid.link/20260120163152.3694116-1-leon.yen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit eb466406d2094deefadc2cd6ddb4f6eeb086d1b4 Author: Zilin Guan Date: Fri Jan 16 14:49:19 2026 +0000 wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req() [ Upstream commit c41075ce8cf05ed8c0e7b7efef000dce548ffc42 ] mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to be freed eventually by mt76_mcu_skb_send_msg(). However, currently if an intermediate function fails before sending, the allocated skb is leaked. Specifically, mt76_connac_mcu_sta_wed_update() and mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory leak in the error path. Fix this by explicitly freeing the skb in these error paths. Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on mt7996_mcu_sta_key_tlv error") made a similar change. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: d1369e515efe ("wifi: mt76: connac: introduce mt76_connac_mcu_sta_wed_update utility routine") Fixes: 6683d988089c ("mt76: connac: move mt76_connac_mcu_add_key in connac module") Fixes: 4f831d18d12d ("wifi: mt76: mt7915: enable WED RX support") Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Zilin Guan Link: https://patch.msgid.link/20260116144919.1482558-1-zilin@seu.edu.cn Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2d8e0053bca29143ace51e08c980ff076844a4b0 Author: Sean Wang Date: Mon Dec 15 19:38:49 2025 -0600 wifi: mt76: mt7925: fix potential deadlock in mt7925_roc_abort_sync [ Upstream commit dd08ca3f092f4185ece69ce2a835c23198b1628a ] roc_abort_sync() can deadlock with roc_work(). roc_work() holds dev->mt76.mutex, while cancel_work_sync() waits for roc_work() to finish. If the caller already owns the same mutex, both sides block and no progress is possible. This deadlock can occur during station removal when mt76_sta_state() -> mt76_sta_remove() -> mt7925_mac_sta_remove_link() -> mt7925_mac_link_sta_remove() -> mt7925_roc_abort_sync() invokes cancel_work_sync() while roc_work() is still running and holding dev->mt76.mutex. This avoids the mutex deadlock and preserves exactly-once work ownership. Fixes: 45064d19fd3a ("wifi: mt76: mt7925: fix a potential association failure upon resuming") Co-developed-by: Quan Zhou Signed-off-by: Quan Zhou Signed-off-by: Sean Wang Link: https://patch.msgid.link/20251216013849.17976-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 909f9b6c513019dbae46903aec5066c9868da199 Author: Sean Wang Date: Mon Dec 15 20:20:17 2025 -0600 wifi: mt76: mt7925: drop puncturing handling from BSS change path [ Upstream commit 59a1864509d084a4b34117e693951c06b846b00a ] IEEE80211_CHANCTX_CHANGE_PUNCTURING is a channel context change flag and should not be checked in the BSS change handler, where the changed mask represents enum ieee80211_bss_change. Remove the puncturing handling from the BSS path and rely on mt7925_change_chanctx() to update puncturing configuration. Fixes: cadebdad959b ("wifi: mt76: mt7925: add EHT preamble puncturing") Signed-off-by: Sean Wang Link: https://patch.msgid.link/20251216022017.23870-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b3d397ff70df08c5d5013ad0c00049749e0de1bc Author: Lorenzo Bianconi Date: Thu Jan 22 11:39:46 2026 +0100 wifi: mt76: npu: Add missing rx_token_size initialization [ Upstream commit 25e3203a2192f2b0d697b2410126bad87e62d4f0 ] Add missing rx_token_size initialization for NPU offloading. Fixes: 7fb554b1b623 ("wifi: mt76: Introduce the NPU generic layer") Tested-by: Kang Yang Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260122-mt76-npu-eagle-offload-v2-2-2374614c0de6@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8b6d4c635348b3c126eec1cb294c955b8cda8723 Author: Lorenzo Bianconi Date: Thu Jan 22 11:39:45 2026 +0100 wifi: mt76: mt7996: Fix NPU stop procedure [ Upstream commit 7aed20bd9fe427b192cce80a164429584b298bbe ] Move mt7996_npu_hw_stop routine before disabling rx NAPIs in order to fix NPU stop procedure used during device L1 SER recovery. Add missing usleep_range in mt7996_npu_hw_stop(). Fixes: 377aa17d2aedc ("wifi: mt76: mt7996: Add NPU offload support to MT7996 driver") Tested-by: Kang Yang Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260122-mt76-npu-eagle-offload-v2-1-2374614c0de6@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4b7c92fd8b8700fac387ff43c6f6e0c4e05ec93f Author: Lorenzo Bianconi Date: Mon Dec 8 19:54:08 2025 +0100 wifi: mt76: Fix memory leak destroying device [ Upstream commit 6b470f36616e3448d44b0ef4b1de2a3e3a31b5be ] All MT76 rx queues have an associated page_pool even if the queue is not associated to a NAPI (e.g. WED RRO queues with WED enabled). Destroy the page_pool running mt76_dma_cleanup routine during module unload. Moreover returns pages to the page pool if WED is not enabled for WED RRO queues. Fixes: 950d0abb5cd94 ("wifi: mt76: mt7996: add wed rx support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251208-mt76-fix-memory-leak-v1-1-cba813fc62b8@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1a4b802afe15c5b33b2dcb37a594aba2fa215d52 Author: Rory Little Date: Wed Sep 3 17:07:11 2025 -0700 wifi: mt76: mt7921: Place upper limit on station AID [ Upstream commit 4d0bf21e3e20619d51d06c0c36207aabab8b712c ] Any station configured with an AID over 20 causes a firmware crash. This situation occurred in our testing using an AP interface on 7922 hardware, with a modified hostapd, sourced from Mediatek's OpenWRT feeds. In stock hostapd, station AIDs begin counting at 1, and this configuration is prevented with an upper limit on associated stations. However, the modified hostapd began allocation at 65, which caused the firmware to crash. This fix does not allow these AIDs to work, but will prevent the firmware crash. This crash was only seen on IFTYPE_AP interfaces, and the fix does not appear to have an effect on IFTYPE_STATION behavior. Fixes: 5c14a5f944b9 ("mt76: mt7921: introduce mt7921e support") Signed-off-by: Rory Little Link: https://patch.msgid.link/20250904000711.3033860-1-rory@candelatech.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 63a85068b3588cafc128a6a909bdb499bd4ad9ee Author: Alok Tiwari Date: Mon Oct 13 02:08:24 2025 -0700 wifi: mt76: mt7996: fix FCS error flag check in RX descriptor [ Upstream commit d8db56142e531f060c938fa0b5175ed6c8cabb11 ] The mt7996 driver currently checks the MT_RXD3_NORMAL_FCS_ERR bit in rxd1 whereas other Connac3-based drivers(mt7925) correctly check this bit in rxd3. Since the MT_RXD3_NORMAL_FCS_ERR bit is defined in the fourth RX descriptor word (rxd3), update mt7996 to use the proper descriptor field. This change aligns mt7996 with mt7925 and the rest of the Connac3 family. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Alok Tiwari Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20251013090826.753992-1-alok.a.tiwari@oracle.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5d5bdea4ffcf54a6c4e751df713f95a1d783f298 Author: Ming Yen Hsieh Date: Thu Sep 4 11:06:47 2025 +0800 wifi: mt76: mt7925: prevent NULL vif dereference in mt7925_mac_write_txwi [ Upstream commit 962eb04e67552be406c906c83099c1d736aae3b6 ] Check for a NULL `vif` before accessing `ieee80211_vif_is_mld(vif)` to avoid a potential kernel panic in scenarios where `vif` might not be initialized. Fixes: ebb1406813c6 ("wifi: mt76: mt7925: add link handling to txwi") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250904030649.655436-3-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b0332428a8d4cf93752eda9e2b0d5585525e689f Author: Ming Yen Hsieh Date: Thu Sep 4 11:06:48 2025 +0800 wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr() [ Upstream commit 83ae3a18ba957257b4c406273d2da2caeea2b439 ] Move the NULL check for 'sta' before dereferencing it to prevent a possible crash. Fixes: 44eb173bdd4f ("wifi: mt76: mt7925: add link handling in mt7925_txwi_free") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250904030649.655436-4-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit cd85db49aae6db0989f2d5fec884c473e5a08c41 Author: Ryder Lee Date: Wed Jan 21 09:41:57 2026 -0800 wifi: mt76: mt7915: fix use_cts_prot support [ Upstream commit 8b2c26562b95c6397e132d21f2bd3d73aaee0c0a ] With this fix, when driver needs to adjust its behavior for compatibility, especially concerning older 11g/n devices, by enabling or disabling CTS protection frames, often for hidden SSIDs or to manage legacy clients. Fixes: 150b91419d3d ("wifi: mt76: mt7915: enable use_cts_prot support") Signed-off-by: Ryder Lee Link: https://patch.msgid.link/eb8db4d0bf1c89b7486e89facb788ae3e510dd8b.1768879119.git.ryder.lee@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit cc7b819b0eecbc3515e936062d30720c38f60c16 Author: Ryder Lee Date: Wed Jan 21 09:41:56 2026 -0800 wifi: mt76: mt7615: fix use_cts_prot support [ Upstream commit 1974a67d9b65c29a0a9426e32e8cd8c056de48b7 ] Driver should not directly write WTBL to prevent overwritten issues. With this fix, when driver needs to adjust its behavior for compatibility, especially concerning older 11g/n devices, by enabling or disabling CTS protection frames, often for hidden SSIDs or to manage legacy clients. Fixes: e34235ccc5e3 ("wifi: mt76: mt7615: enable use_cts_prot support") Signed-off-by: Ryder Lee Link: https://patch.msgid.link/edb87088b0111b32fafc6c4179f54a5286dd37d8.1768879119.git.ryder.lee@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a46426ff522e58244288de479b76f602e3d05689 Author: Leon Yen Date: Thu Dec 11 20:38:36 2025 +0800 wifi: mt76: mt7925: Fix incorrect MLO mode in firmware control [ Upstream commit 1695f662329faa07c860c73453c097823852df28 ] The selection of MLO mode should depend on the capabilities of the STA rather than those of the peer AP to avoid compatibility issues with certain APs, such as Xiaomi BE5000 WiFi7 router. Fixes: 69acd6d910b0c ("wifi: mt76: mt7925: add mt7925_change_vif_links") Signed-off-by: Leon Yen Link: https://patch.msgid.link/20251211123836.4169436-1-leon.yen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 42cbe787dd6594fcff708c1bbb05897f8b76fff1 Author: Sean Wang Date: Mon Dec 15 18:59:30 2025 -0600 wifi: mt76: mt7921: Reset ampdu_state state in case of failure in mt76_connac2_tx_check_aggr() [ Upstream commit 53ffffeb9624ffab6d9a3b1da8635a23f1172b5e ] Reset ampdu_state if ieee80211_start_tx_ba_session() fails in mt76_connac2_tx_check_aggr(), otherwise the driver may incorrectly assume aggregation is active and skip future BA setup attempts. Fixes: 163f4d22c118 ("mt76: mt7921: add MAC support") Signed-off-by: Sean Wang Link: https://patch.msgid.link/20251216005930.9412-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 811fc63c16e1726e627541d666b46654b7770477 Author: Lorenzo Bianconi Date: Sun Dec 14 10:55:30 2025 +0100 wifi: mt76: mt7996: Reset ampdu_state state in case of failure in mt7996_tx_check_aggr() [ Upstream commit c0747db7c10c2dfbdcff0e8e97021e3df1f1e362 ] Reset the ampdu_state configured state if ieee80211_start_tx_ba_session routine fails in mt7996_tx_check_aggr() Fixes: 98686cd21624c ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251214-mt7996-aggr-check-fix-v1-1-33a8b62ec0fc@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c575459b485c47615491b1fd29f04b43fdc3da56 Author: Lorenzo Bianconi Date: Fri Dec 5 11:24:39 2025 +0100 wifi: mt76: mt7996: Clear wcid pointer in mt7996_mac_sta_deinit_link() [ Upstream commit 88973240dc7c976dd320b36a9e6d925c9be083ae ] Clear WCID pointer removing the sta link in mt7996_mac_sta_deinit_link routine. Fixes: dd82a9e02c054 ("wifi: mt76: mt7996: Rely on mt7996_sta_link in sta_add/sta_remove callbacks") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251205-mt76-txq-wicd-fix-v2-4-f19ba48af7c1@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ae0bb96dc00d8c1f378acb5c28173f7a73958369 Author: Lorenzo Bianconi Date: Fri Dec 5 11:24:38 2025 +0100 wifi: mt76: mt7996: Switch to the secondary link if the default one is removed [ Upstream commit 5ef44c200618430b004233cbfc1b0929a13d5ac8 ] Switch to the secondary link if available in mt7996_mac_sta_remove_links routine if the primary one is removed. Moreover reset secondary link index for single link scenario. Fixes: 85cd5534a3f2e ("wifi: mt76: mt7996: use correct link_id when filling TXD and TXP") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251205-mt76-txq-wicd-fix-v2-3-f19ba48af7c1@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a5e60ef046579535333885cdf22bc6847364af64 Author: Lorenzo Bianconi Date: Fri Dec 5 11:24:37 2025 +0100 wifi: mt76: mt7996: Reset mtxq->idx if primary link is removed in mt7996_vif_link_remove() [ Upstream commit 751a2679b15e3a0fa8fc9175862f0ec40643db68 ] Reset WCID index in mt76_txq struct if primary link is removed in mt7996_vif_link_remove routine. Fixes: a3316d2fc669f ("wifi: mt76: mt7996: set vif default link_id adding/removing vif links") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251205-mt76-txq-wicd-fix-v2-2-f19ba48af7c1@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9fd2f2332537df1f4389f5773c99eb0be4a8cdde Author: Lorenzo Bianconi Date: Fri Dec 5 11:24:36 2025 +0100 wifi: mt76: mt7996: Set mtxq->wcid just for primary link [ Upstream commit 654abcbe4528f74428b69292fad5c4224414fa1b ] Set WCID index in mt76_txq struct just for the primary link in mt7996_vif_link_add routine. Fixes: 69d54ce7491d0 ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20251205-mt76-txq-wicd-fix-v2-1-f19ba48af7c1@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c36f39a4b929b7b909b3e8ca854e48c4d0bb18c8 Author: Shayne Chen Date: Mon Dec 15 14:37:28 2025 +0800 wifi: mt76: mt7996: fix iface combination for different chipsets [ Upstream commit 5ef0e8e2653b1ba325eb883ffb94073f19cb669a ] MT7992 and MT7990 support up to 19 interfaces per band and 32 in total. Fixes: 8df63a4bbe3d ("wifi: mt76: mt7996: adjust interface num and wtbl size for mt7992") Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20251215063728.3013365-7-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit efdf1f03a4495099514980b9e87c89a672007348 Author: StanleyYP Wang Date: Mon Dec 15 14:37:23 2025 +0800 wifi: mt76: mt7996: fix the behavior of radar detection [ Upstream commit 45a09251d610f3b8a1fb02039146e42f1f4efe90 ] RDD_DET_MODE is a firmware command intended for testing and does not pause TX after radar detection, so remove it from the normal flow; instead, use the MAC_ENABLE_CTRL firmware command to resume TX after the radar-triggered channel switch completes. Fixes: 1529e335f93d ("wifi: mt76: mt7996: rework radar HWRDD idx") Co-developed-by: Shayne Chen Signed-off-by: Shayne Chen Signed-off-by: StanleyYP Wang Link: https://patch.msgid.link/20251215063728.3013365-2-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 12e349bc229c31a79e0cee164701fa5193fa7bb9 Author: Thomas Weißschuh Date: Wed Mar 18 17:12:42 2026 +0100 tools/nolibc: avoid -Wundef warning for __STDC_VERSION__ [ Upstream commit 3eb97c4cbd4d874e7e327ec512f6169934e12b8a ] With -std=c89 the macro __STDC_VERSION__ is not defined. While undefined identifiers in '#if' directives are assumed to be '0', with -Wundef a warning is emitted. Avoid the warning by explicitly falling back to '0' if __STDC_VERSION__ is not provided by the preprocessor. Fixes: 37219aa5b123 ("tools/nolibc: add __nolibc_static_assert()") Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260318-nolibc-wundef-v1-1-fcb7f9ac7298@weissschuh.net Signed-off-by: Sasha Levin commit 9e371c37cc8cd688a1c4925272cd8244cc0e1160 Author: Thomas Weißschuh Date: Tue Mar 17 09:40:36 2026 +0100 tools/nolibc: MIPS: fix clobbers of 'lo' and 'hi' registers on different ISAs [ Upstream commit e83b07dc8c05a55d02057b1484724a0b188f6f8d ] All MIPS ISAs before r6 use the 'lo' and 'hi' special registers. These are clobbered by system calls and need to be marked as such to avoid miscompilations. Currently nolibc ties the clobbers to the ABI. But this is wrong and leads to ISA<->ABI combinations which are not handled correctly, leading to compiler errors or miscompilations. Handle all different combinations of ABI and ISA. Fixes: a6a2a8a42972 ("tools/nolibc: MIPS: add support for N64 and N32 ABIs") Fixes: 66b6f755ad45 ("rcutorture: Import a copy of nolibc") Suggested-by: Maciej W. Rozycki Link: https://lore.kernel.org/lkml/alpine.DEB.2.21.2603141744240.55200@angie.orcam.me.uk/ Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20260317-nolibc-mips-clobber-v2-1-5b9a97761a9e@linutronix.de Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit ab61bd33bffdbb602d5f4a6840a46c04d7aff677 Author: David Laight Date: Mon Mar 2 10:17:54 2026 +0000 tools/nolibc/printf: Move snprintf length check to callback [ Upstream commit 4045e7b19bbf7338452cda11e64cfe7ae3361964 ] Move output truncation to the snprintf() callback. This simplifies the main code and fixes truncation of padded fields. Add a zero length callback to 'finalise' the buffer rather than doing it in snprintf() itself. Fixes: e90ce42e81381 ("tools/nolibc: implement width padding in printf()") Signed-off-by: David Laight Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260302101815.3043-3-david.laight.linux@gmail.com [Thomas: clean up Fixes trailer] Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit e23746a77200f3bc9c57c147e28636b6d65ec497 Author: David Laight Date: Mon Feb 23 10:17:24 2026 +0000 tools/nolibc/printf: Change variables 'c' to 'ch' and 'tmpbuf[]' to 'outbuf[]' [ Upstream commit f675ae28fcdf7db93a8c1a6964f062725b1e06a0 ] Changing 'c' makes the code slightly easier to read because the variable stands out from the single character literals (especially 'c'). Change tmpbuf[] to outbuf[] because 'out' points into it. The following patches pretty much rewrite the function so the churn is limited. Signed-off-by: David Laight Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260223101735.2922-7-david.laight.linux@gmail.com Signed-off-by: Thomas Weißschuh Stable-dep-of: 4045e7b19bbf ("tools/nolibc/printf: Move snprintf length check to callback") Signed-off-by: Sasha Levin commit 8e7f0e341e929b340a7e653711cdeecf6a4d43a8 Author: David Laight Date: Mon Feb 23 10:17:21 2026 +0000 selftests/nolibc: Fix build with host headers and libc [ Upstream commit 27532c645e61da541173d43fbe03d234f68232f9 ] Many systems don't have strlcpy() or strlcat() and readdir_r() is deprecated. This makes the tests fail to build with the host headers. Disable the 'directories' test and define strlcpy(), strlcat() and readdir_r() using #defines so that the code compiles. Fixes: 6fe8360b16acb ("selftests/nolibc: also test libc-test through regular selftest framework") Signed-off-by: David Laight Link: https://patch.msgid.link/20260223101735.2922-4-david.laight.linux@gmail.com Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit 57ce8a81d05f00029cb3d520a09f8d4499523b94 Author: Thomas Weißschuh Date: Wed Mar 18 18:00:33 2026 +0100 selftests/nolibc: fix test_file_stream() on musl libc [ Upstream commit 8ba600aa577f73cc551747fdf121afc7d04afcea ] fwrite() modifying errno is non-standard. Only validate this behavior on those libc implementations which implement it. Fixes: a5f00be9b3b0 ("tools/nolibc: Add a simple test for writing to a FILE and reading it back") Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit e84acaf936970b5b0be2c93bbf255295ba9406df Author: Amery Hung Date: Wed Mar 18 19:57:16 2026 -0700 bpf: Do not allow deleting local storage in NMI [ Upstream commit 350de5b8a9befaa2a68861c51f671d4f5f751ca5 ] Currently, local storage may deadlock when deferring freeing selem or local storage through kfree_rcu(), call_rcu() or call_rcu_tasks_trace() in NMI or reentrant. Since deleting selem in NMI is an unlikely use case, partially mitigate it by returning error when calling from bpf_xxx_storage_delete() helpers in NMI. Note that, it is still possible to deadlock through reentrant. A full mitigation requires returning error when irqs_disabled() is true, which, however is too heavy-handed for bpf_xxx_storage_delete(). The long-term solution requires _nolock versions of call_rcu. Another possible solution is to defer the free through irq_work [0], but it would grow the size of selem, which is non-ideal. The check is only needed in bpf_selem_unlink(), which is used by helpers and syscalls. bpf_selem_unlink_nofail() is fine as it is called during map and owner tear down that never run in NMI or reentrant. [0] https://lore.kernel.org/bpf/20260205190233.912-1-alexei.starovoitov@gmail.com/ Fixes: a10787e6d58c ("bpf: Enable task local storage for tracing programs") Signed-off-by: Amery Hung Signed-off-by: Martin KaFai Lau Acked-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260319025716.2361065-1-ameryhung@gmail.com Signed-off-by: Sasha Levin commit 4f273d3f98ebc60c30bbfb3ed4a7f0477d3eaed2 Author: Heitor Alves de Siqueira Date: Fri Mar 13 18:27:58 2026 -0300 wifi: libertas: don't kill URBs in interrupt context [ Upstream commit 7c5c2b661bdb78c1472b8833265c9ed1ee880039 ] Serialization for the TX path was enforced by calling usb_kill_urb()/usb_kill_anchored_urbs(), to prevent transmission before a previous URB was completed. usb_tx_block() can be called from interrupt context (e.g. in the HCD giveback path), so we can't always use it to kill in-flight URBs. Prevent sleeping during interrupt context by checking the tx_submitted anchor for existing URBs. We now return -EBUSY, to indicate there's a pending request. Reported-by: syzbot+74afbb6355826ffc2239@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=74afbb6355826ffc2239 Fixes: d66676e6ca96 ("wifi: libertas: fix WARNING in usb_tx_block") Signed-off-by: Heitor Alves de Siqueira Link: https://patch.msgid.link/20260313-libertas-usb-anchors-v1-2-915afbe988d7@igalia.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5318f0d2d9007d590ac3a78369b1043f2283a2b5 Author: Heitor Alves de Siqueira Date: Fri Mar 13 18:27:57 2026 -0300 wifi: libertas: use USB anchors for tracking in-flight URBs [ Upstream commit a57f35fc19add4dfe33703af575a2c19c2cef9c7 ] The libertas driver currently handles URB lifecycles manually, which makes it non-trivial to check if specific URBs are pending or not. Add anchors for TX/RX URBs, and use those to track in-flight requests. Signed-off-by: Heitor Alves de Siqueira Link: https://patch.msgid.link/20260313-libertas-usb-anchors-v1-1-915afbe988d7@igalia.com Signed-off-by: Johannes Berg Stable-dep-of: 7c5c2b661bdb ("wifi: libertas: don't kill URBs in interrupt context") Signed-off-by: Sasha Levin commit 4e32e4d970b333b069797b77d8ac6da5e9b38d33 Author: Petr Pavlu Date: Fri Mar 13 14:48:02 2026 +0100 module: Fix freeing of charp module parameters when CONFIG_SYSFS=n [ Upstream commit deffe1edba626d474fef38007c03646ca5876a0e ] When setting a charp module parameter, the param_set_charp() function allocates memory to store a copy of the input value. Later, when the module is potentially unloaded, the destroy_params() function is called to free this allocated memory. However, destroy_params() is available only when CONFIG_SYSFS=y, otherwise only a dummy variant is present. In the unlikely case that the kernel is configured with CONFIG_MODULES=y and CONFIG_SYSFS=n, this results in a memory leak of charp values when a module is unloaded. Fix this issue by making destroy_params() always available when CONFIG_MODULES=y. Rename the function to module_destroy_params() to clarify that it is intended for use by the module loader. Fixes: e180a6b7759a ("param: fix charp parameters set via sysfs") Signed-off-by: Petr Pavlu Signed-off-by: Sami Tolvanen Signed-off-by: Sasha Levin commit 829367e55012c053738ebe7db20c4a90d6609ece Author: Ritesh Harjani (IBM) Date: Mon Mar 9 23:44:25 2026 +0530 powerpc/64s: Fix unmap race with PMD migration entries [ Upstream commit bbcbf045d6c778e82b47a35fc8728387708e9a3d ] The following race is possible with migration swap entries or device-private THP entries. e.g. when move_pages is called on a PMD THP page, then there maybe an intermediate state, where PMD entry acts as a migration swap entry (pmd_present() is true). Then if an munmap happens at the same time, then this VM_BUG_ON() can happen in pmdp_huge_get_and_clear_full(). This patch fixes that. Thread A: move_pages() syscall add_folio_for_migration() mmap_read_lock(mm) folio_isolate_lru(folio) mmap_read_unlock(mm) do_move_pages_to_node() migrate_pages() try_to_migrate_one() spin_lock(ptl) set_pmd_migration_entry() pmdp_invalidate() # PMD: _PAGE_INVALID | _PAGE_PTE | pfn set_pmd_at() # PMD: migration swap entry (pmd_present=0) spin_unlock(ptl) [page copy phase] # <--- RACE WINDOW --> Thread B: munmap() mmap_write_downgrade(mm) unmap_vmas() -> zap_pmd_range() zap_huge_pmd() __pmd_trans_huge_lock() pmd_is_huge(): # !pmd_present && !pmd_none -> TRUE (swap entry) pmd_lock() -> # spin_lock(ptl), waits for Thread A to release ptl pmdp_huge_get_and_clear_full() VM_BUG_ON(!pmd_present(*pmdp)) # HITS! [ 287.738700][ T1867] ------------[ cut here ]------------ [ 287.743843][ T1867] kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:187! cpu 0x0: Vector: 700 (Program Check) at [c00000044037f4f0] pc: c000000000094ca4: pmdp_huge_get_and_clear_full+0x6c/0x23c lr: c000000000645dec: zap_huge_pmd+0xb0/0x868 sp: c00000044037f790 msr: 800000000282b033 current = 0xc0000004032c1a00 paca = 0xc000000004fe0000 irqmask: 0x03 irq_happened: 0x09 pid = 1867, comm = a.out kernel BUG at :187! Linux version 6.19.0-12136-g14360d4f917c-dirty (powerpc64le-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #27 SMP PREEMPT Sun Feb 22 10:38:56 IST 2026 enter ? for help [link register ] c000000000645dec zap_huge_pmd+0xb0/0x868 [c00000044037f790] c00000044037f7d0 (unreliable) [c00000044037f7d0] c000000000645dcc zap_huge_pmd+0x90/0x868 [c00000044037f840] c0000000005724cc unmap_page_range+0x176c/0x1f40 [c00000044037fa00] c000000000572ea0 unmap_vmas+0xb0/0x1d8 [c00000044037fa90] c0000000005af254 unmap_region+0xb4/0x128 [c00000044037fb50] c0000000005af400 vms_complete_munmap_vmas+0x138/0x310 [c00000044037fbe0] c0000000005b0f1c do_vmi_align_munmap+0x1ec/0x238 [c00000044037fd30] c0000000005b3688 __vm_munmap+0x170/0x1f8 [c00000044037fdf0] c000000000587f74 sys_munmap+0x2c/0x40 [c00000044037fe10] c000000000032668 system_call_exception+0x128/0x350 [c00000044037fe50] c00000000000d05c system_call_vectored_common+0x15c/0x2ec ---- Exception: 3000 (System Call Vectored) at 0000000010064a2c SP (7fff9b1ee9c0) is in userspace 0:mon> zh commit a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages"), enabled migration for device-private PMD entries. Hence this is one other path where this warning could get trigger from. ------------[ cut here ]------------ WARNING: arch/powerpc/mm/book3s64/hash_pgtable.c:199 at hash__pmd_hugepage_update+0x48/0x284, CPU#3: hmm-tests/1905 Modules linked in: test_hmm CPU: 3 UID: 0 PID: 1905 Comm: hmm-tests Tainted: G B W L N 7.0.0-rc1-01438-g7e2f0ee7581c #21 PREEMPT Tainted: [B]=BAD_PAGE, [W]=WARN, [L]=SOFTLOCKUP, [N]=TEST Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries NIP [c000000000096b70] hash__pmd_hugepage_update+0x48/0x284 LR [c000000000096e7c] hash__pmdp_huge_get_and_clear+0xd0/0xd4 Call Trace: [c000000604707670] [c000000004e102b8] 0xc000000004e102b8 (unreliable) [c000000604707700] [c00000000064ec3c] set_pmd_migration_entry+0x414/0x498 [c000000604707760] [c00000000063e5a4] migrate_vma_collect_pmd+0x12e8/0x16c4 [c000000604707890] [c00000000059282c] walk_pgd_range+0x7fc/0xd2c [c000000604707990] [c000000000592e40] __walk_page_range+0xe4/0x2ac [c000000604707a10] [c000000000593534] walk_page_range_mm_unsafe+0x204/0x2a4 [c000000604707ab0] [c00000000063af10] migrate_vma_setup+0x1dc/0x2e8 [c000000604707b10] [c008000006a21838] dmirror_migrate_to_system.constprop.0+0x210/0x4b0 [test_hmm] [c000000604707c30] [c008000006a245b0] dmirror_fops_unlocked_ioctl+0x454/0xa5c [test_hmm] [c000000604707d20] [c0000000006aab84] sys_ioctl+0x4ec/0x1178 [c000000604707e10] [c0000000000326a8] system_call_exception+0x128/0x350 [c000000604707e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fffbe44f50c Fixes: 75358ea359e7c ("powerpc/mm/book3s64: Fix MADV_DONTNEED and parallel page fault race") Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") Reported-by: Pavithra Prakash Signed-off-by: Ritesh Harjani (IBM) Tested-by: Venkat Rao Bagalkote Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/9437e5ef28d1e2f5cbdd7f8286350ce93c1d43c5.1773078178.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit a32db6fca3c74b4eb8bae5470f0680deb4cbac6f Author: Ritesh Harjani (IBM) Date: Mon Mar 9 23:44:24 2026 +0530 powerpc/pgtable-frag: Fix bad page state in pte_frag_destroy [ Upstream commit fda4d71651f71c44b35829d13f3c8bf920032f77 ] powerpc uses pt_frag_refcount as a reference counter for tracking it's pte and pmd page table fragments. For PTE table, in case of Hash with 64K pagesize, we have 16 fragments of 4K size in one 64K page. Patch series [1] "mm: free retracted page table by RCU" added pte_free_defer() to defer the freeing of PTE tables when retract_page_tables() is called for madvise MADV_COLLAPSE on shmem range. [1]: https://lore.kernel.org/all/7cd843a9-aa80-14f-5eb2-33427363c20@google.com/ pte_free_defer() sets the active flag on the corresponding fragment's folio & calls pte_fragment_free(), which reduces the pt_frag_refcount. When pt_frag_refcount reaches 0 (no active fragment using the folio), it checks if the folio active flag is set, if set, it calls call_rcu to free the folio, it the active flag is unset then it calls pte_free_now(). Now, this can lead to following problem in a corner case... [ 265.351553][ T183] BUG: Bad page state in process a.out pfn:20d62 [ 265.353555][ T183] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20d62 [ 265.355457][ T183] flags: 0x3ffff800000100(active|node=0|zone=0|lastcpupid=0x7ffff) [ 265.358719][ T183] raw: 003ffff800000100 0000000000000000 5deadbeef0000122 0000000000000000 [ 265.360177][ T183] raw: 0000000000000000 c0000000119caf58 00000000ffffffff 0000000000000000 [ 265.361438][ T183] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set [ 265.362572][ T183] Modules linked in: [ 265.364622][ T183] CPU: 0 UID: 0 PID: 183 Comm: a.out Not tainted 6.18.0-rc3-00141-g1ddeaaace7ff-dirty #53 VOLUNTARY [ 265.364785][ T183] Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries [ 265.364908][ T183] Call Trace: [ 265.364955][ T183] [c000000011e6f7c0] [c000000001cfaa18] dump_stack_lvl+0x130/0x148 (unreliable) [ 265.365202][ T183] [c000000011e6f7f0] [c000000000794758] bad_page+0xb4/0x1c8 [ 265.365384][ T183] [c000000011e6f890] [c00000000079c020] __free_frozen_pages+0x838/0xd08 [ 265.365554][ T183] [c000000011e6f980] [c0000000000a70ac] pte_frag_destroy+0x298/0x310 [ 265.365729][ T183] [c000000011e6fa30] [c0000000000aa764] arch_exit_mmap+0x34/0x218 [ 265.365912][ T183] [c000000011e6fa80] [c000000000751698] exit_mmap+0xb8/0x820 [ 265.366080][ T183] [c000000011e6fc30] [c0000000001b1258] __mmput+0x98/0x300 [ 265.366244][ T183] [c000000011e6fc80] [c0000000001c81f8] do_exit+0x470/0x1508 [ 265.366421][ T183] [c000000011e6fd70] [c0000000001c95e4] do_group_exit+0x88/0x148 [ 265.366602][ T183] [c000000011e6fdc0] [c0000000001c96ec] pid_child_should_wake+0x0/0x178 [ 265.366780][ T183] [c000000011e6fdf0] [c00000000003a270] system_call_exception+0x1b0/0x4e0 [ 265.366958][ T183] [c000000011e6fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec The bad page state error occurs when such a folio gets freed (with active flag set), from do_exit() path in parallel. ... this can happen when the pte fragment was allocated from this folio, but when all the fragments get freed, the pte_frag_refcount still had some unused fragments. Now, if this process exits, with such folio as it's cached pte_frag in mm->context, then during pte_frag_destroy(), we simply call pagetable_dtor() and pagetable_free(), meaning it doesn't clear the active flag. This, can lead to the above bug. Since we are anyway in do_exit() path, then if the refcount is 0, then I guess it should be ok to simply clear the folio active flag before calling pagetable_dtor() & pagetable_free(). Fixes: 32cc0b7c9d50 ("powerpc: add pte_free_defer() for pgtables sharing page") Reviewed-by: Christophe Leroy (CS GROUP) Signed-off-by: Ritesh Harjani (IBM) Tested-by: Venkat Rao Bagalkote Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/ee13e7f99b8f258019da2b37655b998e73e5ef8b.1773078178.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin commit 834918a77be51419383bf1dda9f02b81ecf26b34 Author: Ilya Leoshkevich Date: Fri Mar 13 18:46:25 2026 +0100 s390/bpf: Zero-extend bpf prog return values and kfunc arguments [ Upstream commit 202e42e4aa890172366354b233c42c73107a3f59 ] s390x ABI requires callers to zero-extend unsigned arguments and sign-extend signed arguments, and callees to zero-extend unsigned return values and sign-extend signed return values. s390 BPF JIT currently implements only sign extension. Fix this omission and implement zero extension too. Fixes: 528eb2cb87bc ("s390/bpf: Implement arch_prepare_bpf_trampoline()") Reported-by: Hari Bathini Closes: https://lore.kernel.org/bpf/20260312080113.843408-1-hbathini@linux.ibm.com/ Signed-off-by: Ilya Leoshkevich Tested-by: Ihor Solodrai Link: https://lore.kernel.org/r/20260313174807.581826-1-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 8fa106e938c82422d0b60166f0ad5534e5040736 Author: Cai Xinchen Date: Thu Mar 12 06:59:07 2026 +0000 dpaa2: compile dpaa2 even CONFIG_FSL_DPAA2_ETH=n [ Upstream commit 97daf00745f7f9f261b0e91418de6e79d7826c36 ] CONFIG_FSL_DPAA2_ETH and CONFIG_FSL_DPAA2_SWITCH are not associated, but the compilation of FSL_DPAA2_SWITCH depends on the compilation of the dpaa2 folder. The files controlled by CONFIG_FSL_DPAA2_SWITCH in the dpaa2 folder are not controlled by CONFIG_FSL_DPAA2_ETH, except for the files controlled by CONFIG_FSL_DPAA2_SWITCH. Therefore, removing the restriction will not affect the compilation of the files in the directory. Fixes: f48298d3fbfaa ("staging: dpaa2-switch: move the driver out of staging") Suggested-by: Ioana Ciornei Signed-off-by: Cai Xinchen Link: https://patch.msgid.link/20260312065907.476663-3-caixinchen1@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 50b44b1612ac503dbb27adb1e45ccad8c3c5e760 Author: Cai Xinchen Date: Thu Mar 12 06:59:06 2026 +0000 dpaa2: add independent dependencies for FSL_DPAA2_SWITCH [ Upstream commit 12589892f41c4c645c80ef9f036f7451a6045624 ] Since the commit 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support") included dpaa2-mac.o in the driver, but it didn't select PCS_LYNX, PHYLINK and FSL_XGMAC_MDIO. it will lead to link error, such as undefined reference to `phylink_ethtool_ksettings_set' undefined reference to `lynx_pcs_create_fwnode' And the same reason as the commit d2624e70a2f53 ("dpaa2-eth: select XGMAC_MDIO for MDIO bus support"), enable the FSL_XGMAC_MDIO Kconfig option in order to have MDIO access to internal and external PHYs. Because dpaa2-switch uses fsl_mc_driver APIs, add depends on FSL_MC_BUS && FSL_MC_DPIO as FSL_DPAA2_SWITCH do. FSL_XGMAC_MDIO and FSL_MC_BUS depend on OF, thus the dependence of FSL_MC_BUS can satisfy FSL_XGMAC_MDIO's OF requirement. Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support") Suggested-by: Ioana Ciornei Signed-off-by: Cai Xinchen Link: https://patch.msgid.link/20260312065907.476663-2-caixinchen1@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8388fb6760cc1be6582ce282e7236b1614e792bd Author: Shayne Chen Date: Fri Mar 13 14:21:49 2026 +0800 wifi: ieee80211: fix definition of EHT-MCS 15 in MRU [ Upstream commit cb0caadb64ca0894c4a24e1a34841f260d462f90 ] According to the definition in IEEE Std 802.11be-2024, Table 9-417r, each bit indicates support for the transmission and reception of EHT-MCS 15 in: - B0: 52+26-tone and 106+26-tone MRUs. - B1: a 484+242-tone MRU if 80 MHz is supported. - B2: a 996+484-tone MRU and a 996+484+242-tone MRU if 160 MHz is supported. - B3: a 3×996-tone MRU if 320 MHz is supported. Fixes: 6239da18d2f9 ("wifi: mac80211: adjust EHT capa when lowering bandwidth") Signed-off-by: Shayne Chen Link: https://patch.msgid.link/20260313062150.3165433-1-shayne.chen@mediatek.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a61c7cec3e0c102620636471d864b0602c843876 Author: Alan Maguire Date: Tue Mar 10 11:13:29 2026 +0000 selftests/bpf: Handle !CONFIG_SMC in bpf_smc.c [ Upstream commit e95e85b8914be1c951a1ead34b1353592719e26e ] Currently BPF selftests will fail to compile if CONFIG_SMC is not set. Use BPF CO-RE to work around the case where CONFIG_SMC is not set; use ___local variants of relevant structures and utilize bpf_core_field_exists() for net->smc. The test continues to pass where CONFIG_SMC=y CONFIG_SMC_HS_CTRL_BPF=y but these changes allow the selftests to build in the absence of CONFIG_SMC=y. Also ensure that we get a pure skip rather than a skip+fail by removing the SMC is unsupported part from the ASSERT_FALSE() in get_smc_nl_family(); doing this means we get a skip without a fail when CONFIG_SMC is not set: $ sudo ./test_progs -t bpf_smc Summary: 1/0 PASSED, 1 SKIPPED, 0 FAILED Fixes: beb3c67297d9 ("bpf/selftests: Add selftest for bpf_smc_hs_ctrl") Reported-by: Colm Harrington Signed-off-by: Alan Maguire Signed-off-by: Martin KaFai Lau Tested-by: Kumar Kartikeya Dwivedi Link: https://patch.msgid.link/20260310111330.601765-1-alan.maguire@oracle.com Signed-off-by: Sasha Levin commit a230aa27f7d4cf547749c5afb8765d0b29e41c64 Author: P Praneesh Date: Mon Feb 9 11:19:24 2026 +0530 wifi: ath12k: Fix legacy rate mapping for monitor mode capture [ Upstream commit 616217a989e09c55398db8555e5ef0c64504cb66 ] The current implementation incorrectly reports legacy CCK and OFDM rates in monitor mode radiotap headers. The rate field displays wrong values, for example showing 11 Mbps when the actual rate is 1 Mbps. This occurs because the HAL layer uses a unified enum for both CCK and OFDM rates without distinguishing between long/short preamble variants and proper rate mapping to hardware rate indices. The root cause is threefold: 1. The hal_rx_legacy_rate enum conflates CCK and OFDM rates into a single enumeration, making it impossible to differentiate between 802.11b CCK rates (with long/short preamble variants) and 802.11a/g OFDM rates. 2. The L-SIG-B parsing function maps hardware rate values to the wrong enum values. For CCK rates, it incorrectly combines long and short preamble cases (e.g., cases 2 and 5 both map to 2 Mbps), losing preamble information critical for proper rate identification. 3. The mac layer's rate-to-index conversion function does not properly handle the precedence between long preamble, short preamble, and OFDM rates when matching hardware rate values. Split the hal_rx_legacy_rate enum into two separate enumerations: hal_rx_legacy_rate for CCK rates with explicit long preamble (LP) and short preamble (SP) variants, and hal_rx_legacy_rates_ofdm for OFDM rates. This separation allows proper identification of rate types and preamble modes. Introduce a new mapping ath12k_wifi7_hal_mon_map_legacy_rate_to_hw_rate() that converts HAL CCK rate enums to hardware rate indices defined in ath12k_hw_rate_cck. This ensures the rate field in ppdu_info contains the correct hardware rate index that matches the mac layer's expectations. Update the L-SIG-B parsing to map each hardware rate value (1-7) to its corresponding CCK rate enum with proper preamble designation: - Cases 1-4: Long preamble (1, 2, 5.5, 11 Mbps) - Cases 5-7: Short preamble (2, 5.5, 11 Mbps) Update the L-SIG-A parsing to use the new OFDM-specific enum values, maintaining the existing rate mapping for 802.11a/g OFDM rates. Refactor the mac layer's ath12k_mac_hw_rate_to_idx() function to implement proper matching precedence: 1. First match OFDM rates using the IEEE80211_RATE_MANDATORY_A flag 2. Then match CCK short preamble rates 3. Finally match CCK long preamble rates as fallback Add helper macros ATH12K_MAC_RATE_A_M and ATH12K_MAC_RATE_B to improve readability of the rate table initialization and ensure the mandatory flag is set for OFDM rates. This fix ensures monitor mode captures display accurate rate information in the radiotap header, correctly distinguishing between 1 Mbps and 11 Mbps, and properly identifying preamble types for CCK rates. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh Signed-off-by: Thiraviyam Mariyappan Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260209054924.2713072-1-thiraviyam.mariyappan@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d2602a0889e6a679e70c2aa0350f6eb45e368559 Author: Sarika Sharma Date: Thu Feb 26 10:49:47 2026 +0530 wifi: ath12k: account TX stats only when ACK/BA status is present [ Upstream commit 1635ecc61a24597f893d057d004051a535c1c643 ] The fields tx_retry_failed, tx_retry_count, and tx_duration are currently updated outside the HTT_PPDU_STATS_TAG_USR_COMPLTN_ACK_BA_STATUS flag check. In certain scenarios, firmware delivers multiple PPDU statistics for the same PPDU, first without BA/ACK information, and later with BA/ACK status once it becomes available. As the same PPDU is processed again, these counters are updated a second time, resulting in duplicate TX statistics. To address this, move the accounting of tx_retry_failed and tx_retry_count under the ACK/BA status flag check, and similarly gate tx_duration on the same path. This ensures that each PPDU contributes to these counters exactly once, avoids double counting, and provides consistent reporting in userspace tools such as station dump. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Fixes: a0b963e1da5b ("wifi: ath12k: fetch tx_retry and tx_failed from htt_ppdu_stats_user_cmpltn_common_tlv") Signed-off-by: Sarika Sharma Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260226051947.1379716-1-sarika.sharma@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 94f95328b9070909b5b875c647b17a11d3d85567 Author: Feng Yang Date: Wed Mar 4 17:44:28 2026 +0800 bpf: test_run: Fix the null pointer dereference issue in bpf_lwt_xmit_push_encap [ Upstream commit 972787479ee73006fddb5e59ab5c8e733810ff42 ] The bpf_lwt_xmit_push_encap helper needs to access skb_dst(skb)->dev to calculate the needed headroom: err = skb_cow_head(skb, len + LL_RESERVED_SPACE(skb_dst(skb)->dev)); But skb->_skb_refdst may not be initialized when the skb is set up by bpf_prog_test_run_skb function. Executing bpf_lwt_push_ip_encap function in this scenario will trigger null pointer dereference, causing a kernel crash as Yinhao reported: [ 105.186365] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 105.186382] #PF: supervisor read access in kernel mode [ 105.186388] #PF: error_code(0x0000) - not-present page [ 105.186393] PGD 121d3d067 P4D 121d3d067 PUD 106c83067 PMD 0 [ 105.186404] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 105.186412] CPU: 3 PID: 3250 Comm: poc Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 105.186423] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 105.186427] RIP: 0010:bpf_lwt_push_ip_encap+0x1eb/0x520 [ 105.186443] Code: 0f 84 de 01 00 00 0f b7 4a 04 66 85 c9 0f 85 47 01 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8b 73 58 48 83 e6 fe <48> 8b 36 0f b7 be ec 00 00 00 0f b7 b6 e6 00 00 00 01 fe 83 e6 f0 [ 105.186449] RSP: 0018:ffffbb0e0387bc50 EFLAGS: 00010246 [ 105.186455] RAX: 000000000000004e RBX: ffff94c74e036500 RCX: ffff94c74874da00 [ 105.186460] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff94c74e036500 [ 105.186463] RBP: 0000000000000001 R08: 0000000000000002 R09: 0000000000000000 [ 105.186467] R10: ffffbb0e0387bd50 R11: 0000000000000000 R12: ffffbb0e0387bc98 [ 105.186471] R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000002 [ 105.186484] FS: 00007f166aa4d680(0000) GS:ffff94c8b7780000(0000) knlGS:0000000000000000 [ 105.186490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 105.186494] CR2: 0000000000000000 CR3: 000000015eade001 CR4: 0000000000770ee0 [ 105.186499] PKRU: 55555554 [ 105.186502] Call Trace: [ 105.186507] [ 105.186513] bpf_lwt_xmit_push_encap+0x2b/0x40 [ 105.186522] bpf_prog_a75eaad51e517912+0x41/0x49 [ 105.186536] ? kvm_clock_get_cycles+0x18/0x30 [ 105.186547] ? ktime_get+0x3c/0xa0 [ 105.186554] bpf_test_run+0x195/0x320 [ 105.186563] ? bpf_test_run+0x10f/0x320 [ 105.186579] bpf_prog_test_run_skb+0x2f5/0x4f0 [ 105.186590] __sys_bpf+0x69c/0xa40 [ 105.186603] __x64_sys_bpf+0x1e/0x30 [ 105.186611] do_syscall_64+0x59/0x110 [ 105.186620] entry_SYSCALL_64_after_hwframe+0x76/0xe0 [ 105.186649] RIP: 0033:0x7f166a97455d Temporarily add the setting of skb->_skb_refdst before bpf_test_run to resolve the issue. Fixes: 52f278774e79 ("bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap") Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Closes: https://groups.google.com/g/hust-os-kernel-patches/c/8-a0kPpBW2s Signed-off-by: Yun Lu Signed-off-by: Feng Yang Signed-off-by: Martin KaFai Lau Tested-by: syzbot@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260304094429.168521-2-yangfeng59949@163.com Signed-off-by: Sasha Levin commit 3c0e8a3179e6325a7dc6ce221aef0e03d854ab4b Author: Duoming Zhou Date: Mon Feb 23 12:55:22 2026 +0800 wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet [ Upstream commit 039cd522dc70151da13329a5e3ae19b1736f468a ] The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet(). Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released. The issue was identified through static analysis. Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Duoming Zhou Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260223045522.48377-1-duoming@zju.edu.cn Signed-off-by: Sasha Levin commit 749310a43d99fb342cc1300e0e44e9c29a6ce792 Author: Zilin Guan Date: Mon Jan 19 09:26:25 2026 +0000 wifi: mwifiex: Fix memory leak in mwifiex_11n_aggregate_pkt() [ Upstream commit 990a73dec3fdc145fef6c827c29205437d533ece ] In mwifiex_11n_aggregate_pkt(), skb_aggr is allocated via mwifiex_alloc_dma_align_buf(). If mwifiex_is_ralist_valid() returns false, the function currently returns -1 immediately without freeing the previously allocated skb_aggr, causing a memory leak. Since skb_aggr has not yet been queued via skb_queue_tail(), no other references to this memory exist. Therefore, it has to be freed locally before returning the error. Fix this by calling mwifiex_write_data_complete() to free skb_aggr before returning the error status. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Zilin Guan Reviewed-by: Jeff Chen Link: https://patch.msgid.link/20260119092625.1349934-1-zilin@seu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5d63aa38d5ca85206d9699ffdd616b58780dba07 Author: Zilin Guan Date: Fri Jan 30 08:44:51 2026 +0000 wifi: ath11k: fix memory leaks in beacon template setup [ Upstream commit ff49eba595df500e4ddccc593088c8a4ab5f2c27 ] The functions ath11k_mac_setup_bcn_tmpl_ema() and ath11k_mac_setup_bcn_tmpl_mbssid() allocate memory for beacon templates but fail to free it when parameter setup returns an error. Since beacon templates must be released during normal execution, they must also be released in the error handling paths to prevent memory leaks. Fix this by using unified exit paths with proper cleanup in the respective error paths. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 3a415daa3e8b ("wifi: ath11k: add P2P IE in beacon template") Fixes: 335a92765d30 ("wifi: ath11k: MBSSID beacon support") Suggested-by: Baochen Qiang Signed-off-by: Zilin Guan Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260130084451.110768-1-zilin@seu.edu.cn Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit a086857d078a48bd9e33a5dfc713f8f46d5a78f3 Author: Michal Koutný Date: Mon Mar 23 13:39:37 2026 +0100 sched/rt: Skip group schedulable check with rt_group_sched=0 [ Upstream commit 8b016dcec9365675be81d26be88f2c09cf983bd4 ] The warning from the commit 87f1fb77d87a6 ("sched: Add RT_GROUP WARN checks for non-root task_groups") is wrong -- it assumes that only task_groups with rt_rq are traversed, however, the schedulability check would iterate all task_groups even when rt_group_sched=0 is disabled at boot time but some non-root task_groups exist. The schedulability check is supposed to validate: a) that children don't overcommit its parent, b) no RT task group overcommits global RT limit. but with rt_group_sched=0 there is no (non-trivial) hierarchy of RT groups, therefore skip the validation altogether. Otherwise, writes to the global sched_rt_runtime_us knob will be rejected with incorrect validation error. This fix is immaterial with CONFIG_RT_GROUP_SCHED=n. Fixes: 87f1fb77d87a6 ("sched: Add RT_GROUP WARN checks for non-root task_groups") Signed-off-by: Michal Koutný Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260323-sched-rert_groups-v3-1-1e7d5ed6b249@suse.com Signed-off-by: Sasha Levin commit 965fa822b3d43a9ffa2614301024bb7ddecfb045 Author: John Stultz Date: Tue Mar 24 19:13:16 2026 +0000 sched: Make class_schedulers avoid pushing current, and get rid of proxy_tag_curr() [ Upstream commit e0ca8991b2de6c9dfe6fcd8a0364951b2bd56797 ] With proxy-execution, the scheduler selects the donor, but for blocked donors, we end up running the lock owner. This caused some complexity, because the class schedulers make sure to remove the task they pick from their pushable task lists, which prevents the donor from being migrated, but there wasn't then anything to prevent rq->curr from being migrated if rq->curr != rq->donor. This was sort of hacked around by calling proxy_tag_curr() on the rq->curr task if we were running something other then the donor. proxy_tag_curr() did a dequeue/enqueue pair on the rq->curr task, allowing the class schedulers to remove it from their pushable list. The dequeue/enqueue pair was wasteful, and additonally K Prateek highlighted that we didn't properly undo things when we stopped proxying, leaving the lock owner off the pushable list. After some alternative approaches were considered, Peter suggested just having the RT/DL classes just avoid migrating when task_on_cpu(). So rework pick_next_pushable_dl_task() and the rt pick_next_pushable_task() functions so that they skip over the first pushable task if it is on_cpu. Then just drop all of the proxy_tag_curr() logic. Fixes: be39617e38e0 ("sched: Fix proxy/current (push,pull)ability") Closes: https://lore.kernel.org/lkml/e735cae0-2cc9-4bae-b761-fcb082ed3e94@amd.com/ Reported-by: K Prateek Nayak Suggested-by: Peter Zijlstra Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260324191337.1841376-2-jstultz@google.com Signed-off-by: Sasha Levin commit c2e02bc7ae32e7a50e87fd48505e852cb9f46f76 Author: Aaron Tomlin Date: Tue Mar 24 20:11:58 2026 -0400 fs/resctrl: Report invalid domain ID when parsing io_alloc_cbm [ Upstream commit d06b8e7c97c3290e61006e30b32beb9e715fab82 ] The last_cmd_status file is intended to report details about the most recent resctrl filesystem operation, specifically to aid in diagnosing failures. However, when parsing io_alloc_cbm, if a user provides a domain ID that does not exist in the resource, the operation fails with -EINVAL without updating last_cmd_status. This results in inconsistent behaviour where the system call returns an error, but last_cmd_status misleadingly reports "ok", leaving the user unaware that the failure was caused by an invalid domain ID. Write an error message to last_cmd_status when the target domain ID cannot be found. Fixes: 28fa2cce7a83 ("fs/resctrl: Introduce interface to modify io_alloc capacity bitmasks") Suggested-by: Reinette Chatre Signed-off-by: Aaron Tomlin Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Reinette Chatre Reviewed-by: Babu Moger Tested-by: Babu Moger Link: https://patch.msgid.link/20260325001159.447075-2-atomlin@atomlin.com Signed-off-by: Sasha Levin commit bd3606a5b01c6cf1233614186f50bb4951f1d1e7 Author: Mario Limonciello (AMD) Date: Sat Mar 7 08:10:20 2026 -0600 firmware: dmi: Correct an indexing error in dmi.h [ Upstream commit c064abc68e009d2cc18416e7132d9c25e03125b6 ] The entries later in enum dmi_entry_type don't match the SMBIOS specification¹. The entry for type 33: `64-Bit Memory Error Information` is not present and thus the index for all later entries is incorrect. Add it. Also, add missing entry types 43-46, while at it. ¹ Search for "System Management BIOS (SMBIOS) Reference Specification" [ bp: Drop the flaky SMBIOS spec URL. ] Fixes: 93c890dbe5287 ("firmware: Add DMI entry types to the headers") Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Jean Delvare Reviewed-by: Yazen Ghannam Link: https://patch.msgid.link/20260307141024.819807-2-superm1@kernel.org Signed-off-by: Sasha Levin commit 1f90211816490c6c587c59f14428484699de72b1 Author: Thomas Weißschuh Date: Mon Mar 30 14:07:55 2026 +0200 x86/vdso: Clean up remnants of VDSO32_NOTE_MASK [ Upstream commit 6517f293b2c6774d21b6e7e26a55fae60c6ec4cf ] VDSO32_NOTE_MASK is not used or provided anymore, remove it. Fixes: a13f2ef168cb ("x86/xen: remove 32-bit Xen PV guest support") Signed-off-by: Thomas Weißschuh Signed-off-by: Ingo Molnar Cc: H. Peter Anvin Cc: Boris Ostrovsky Cc: Juergen Gross Link: https://patch.msgid.link/20260330-vdso-x86-vdso32_note_mask-v1-1-2f5c473327bf@linutronix.de Signed-off-by: Sasha Levin commit 0e308c95354c7efb20670e5e5900f1f1760c21a4 Author: Ahmed S. Darwish Date: Fri Mar 27 03:15:16 2026 +0100 ASoC: Intel: avs: Include CPUID header at file scope [ Upstream commit 7f78e0b46e9984e955cb73ffada8dace8b4dd059 ] Commit cbe37a4d2b3c ("ASoC: Intel: avs: Configure basefw on TGL-based platforms") includes the main CPUID header from within a C function. This works by luck and forbids valid refactoring inside that header. Include the CPUID header at file scope instead. Remove the COMPILE_TEST build flag so that the CONFIG_X86 conditionals can be removed. The driver gets enough compilation testing already on x86. For clarity, refactor the CPUID(0x15) code into its own function without changing any of the driver's logic. Fixes: cbe37a4d2b3c ("ASoC: Intel: avs: Configure basefw on TGL-based platforms") Suggested-by: Borislav Petkov # CONFIG_X86 removal Signed-off-by: Ahmed S. Darwish Signed-off-by: Borislav Petkov (AMD) Acked-by: Cezary Rojewski Link: https://lore.kernel.org/all/20250612234010.572636-3-darwi@linutronix.de Signed-off-by: Sasha Levin commit 6fcaf2ae9eeaec2bc2ffd62084bcbfebe3814dd2 Author: Ahmed S. Darwish Date: Fri Mar 27 03:15:15 2026 +0100 ASoC: Intel: avs: Check maximum valid CPUID leaf [ Upstream commit 93a1f0e61329f538cfc7122d7fa0e7a1803e326d ] The Intel AVS driver queries CPUID(0x15) before checking if the CPUID leaf is available. Check the maximum-valid CPU standard leaf beforehand. Use the CPUID_LEAF_TSC macro instead of the custom local one for the CPUID(0x15) leaf number. Fixes: cbe37a4d2b3c ("ASoC: Intel: avs: Configure basefw on TGL-based platforms") Signed-off-by: Ahmed S. Darwish Signed-off-by: Borislav Petkov (AMD) Acked-by: Cezary Rojewski Link: https://patch.msgid.link/20260327021645.555257-2-darwi@linutronix.de Signed-off-by: Sasha Levin commit 6e2712cd9a0d75b4c66df81a0b32d0550b4b901f Author: Biju Das Date: Wed Mar 25 19:24:18 2026 +0000 irqchip/renesas-rzg2l: Fix error path in rzg2l_irqc_common_probe() [ Upstream commit fb74e35f78105efd8635c89b39f4389f567edbdc ] Replace pm_runtime_put() with pm_runtime_put_sync() when irq_domain_create_hierarchy() fails to ensure the device suspends synchronously before devres cleanup disables runtime PM via pm_runtime_disable(). [ tglx: Fix up subject and change log to be precise ] Fixes: 7de11369ef30 ("irqchip/renesas-rzg2l: Use devm_pm_runtime_enable()") Signed-off-by: Biju Das Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260325192451.172562-4-biju.das.jz@bp.renesas.com Signed-off-by: Sasha Levin commit ee935b05a82fa327288609b021acc2a97b634c86 Author: Peter Zijlstra Date: Mon Mar 23 10:36:27 2026 +0100 sched/topology: Fix sched_domain_span() [ Upstream commit e379dce8af11d8d6040b4348316a499bfd174bfb ] Commit 8e8e23dea43e ("sched/topology: Compute sd_weight considering cpuset partitions") ends up relying on the fact that structure initialization should not touch the flexible array. However, the official GCC specification for "Arrays of Length Zero" [*] says: Although the size of a zero-length array is zero, an array member of this kind may increase the size of the enclosing type as a result of tail padding. Additionally, structure initialization will zero tail padding. With the end result that since offsetof(*type, member) < sizeof(*type), array initialization will clobber the flex array. Luckily, the way flexible array sizes are calculated is: sizeof(*type) + count * sizeof(*type->member) This means we have the complete size of the flex array *outside* of sizeof(*type), so use that instead of relying on the broken flex array definition. [*] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Fixes: 8e8e23dea43e ("sched/topology: Compute sd_weight considering cpuset partitions") Reported-by: Nathan Chancellor Debugged-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Tested-by: Jon Hunter Tested-by: Chen Yu Tested-by: K Prateek Nayak Tested-by: Nathan Chancellor Link: https://patch.msgid.link/20260323093627.GY3738010@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit fe1be0254f4815fad971a91d58ea1e28ff5b3043 Author: Juergen Gross Date: Mon Jan 19 19:26:27 2026 +0100 x86/irqflags: Preemptively move include paravirt.h directive where it belongs [ Upstream commit 36c1eb9531e0c9bdcb3494142123f1c1e128367b ] Commit 22cc5ca5de52 ("x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT") moved some paravirt hooks from the CONFIG_PARAVIRT_XXL umbrella to CONFIG_PARAVIRT, but missed to move the associated "#include " in irqflags.h from CONFIG_PARAVIRT_XXL to CONFIG_PARAVIRT. This hasn't resulted in build failures yet, as all use cases of irqflags.h had paravirt.h included via other header files, even without CONFIG_PARAVIRT_XXL being set. In order to allow changing those other header files, e.g. by no longer including paravirt.h, fix irqflags.h by moving inclusion of paravirt.h under the CONFIG_PARAVIRT umbrella. [ bp: Massage commit message. ] Fixes: 22cc5ca5de52 ("x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT") Closes: https://lore.kernel.org/oe-kbuild-all/202601152203.plJOoOEF-lkp@intel.com/ Reported-by: kernel test robot Signed-off-by: Juergen Gross Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20260119182632.596369-2-jgross@suse.com Signed-off-by: Sasha Levin commit c232eab5219361ee09e2327d8eb09ca60284cc00 Author: K Prateek Nayak Date: Thu Mar 12 04:44:26 2026 +0000 sched/topology: Compute sd_weight considering cpuset partitions [ Upstream commit 8e8e23dea43e64ddafbd1246644c3219209be113 ] The "sd_weight" used for calculating the load balancing interval, and its limits, considers the span weight of the entire topology level without accounting for cpuset partitions. For example, consider a large system of 128CPUs divided into 8 * 16CPUs partition which is typical when deploying virtual machines: [ PKG Domain: 128CPUs ] [Partition0: 16CPUs][Partition1: 16CPUs] ... [Partition7: 16CPUs] Although each partition only contains 16CPUs, the load balancing interval is set to a minimum of 128 jiffies considering the span of the entire domain with 128CPUs which can lead to longer imbalances within the partition although balancing within is cheaper with 16CPUs. Compute the "sd_weight" after computing the "sd_span" considering the cpu_map covered by the partition, and set the load balancing interval, and its limits accordingly. For the above example, the balancing intervals for the partitions PKG domain changes as follows: before after balance_interval 128 16 min_interval 128 16 max_interval 256 32 Intervals are now proportional to the CPUs in the partitioned domain as was intended by the original formula. Fixes: cb83b629bae03 ("sched/numa: Rewrite the CONFIG_NUMA sched domain support") Signed-off-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Shrikanth Hegde Reviewed-by: Chen Yu Reviewed-by: Valentin Schneider Reviewed-by: Dietmar Eggemann Tested-by: Dietmar Eggemann Link: https://patch.msgid.link/20260312044434.1974-2-kprateek.nayak@amd.com Signed-off-by: Sasha Levin commit 5ebef9e47c7ae4ae2b5a84555fa040c24a7eac7a Author: Bart Van Assche Date: Fri Mar 13 10:15:07 2026 -0700 locking: Fix rwlock support in [ Upstream commit 756a0e011cfca0b45a48464aa25b05d9a9c2fb0b ] Architecture support for rwlocks must be available whether or not CONFIG_DEBUG_SPINLOCK has been defined. Move the definitions of the arch_{read,write}_{lock,trylock,unlock}() macros such that these become visbile if CONFIG_DEBUG_SPINLOCK=n. This patch prepares for converting do_raw_{read,write}_trylock() into inline functions. Without this patch that conversion triggers a build failure for UP architectures, e.g. arm-ep93xx. I used the following kernel configuration to build the kernel for that architecture: CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=n CONFIG_ATAGS=y CONFIG_MMU=y CONFIG_ARCH_MULTI_V4T=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_ARCH_EP93XX=y Fixes: fb1c8f93d869 ("[PATCH] spinlock consolidation") Signed-off-by: Bart Van Assche Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260313171510.230998-2-bvanassche@acm.org Signed-off-by: Sasha Levin commit 2eea1b12bb804ad025fe93bed1218aebad3f2538 Author: Thomas Weißschuh (Schneider Electric) Date: Wed Mar 11 11:15:10 2026 +0100 scripts/gdb: timerlist: Adapt to move of tk_core [ Upstream commit 5aa9383813aca45b914d4a7481ca417ef13114df ] tk_core is a macro today which cannot be resolved by gdb. Use the correct symbol expression to reference tk_core. Fixes: 22c62b9a84b8 ("timekeeping: Introduce auxiliary timekeepers") Signed-off-by: Thomas Weißschuh (Schneider Electric) Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260311-hrtimer-cleanups-v1-1-095357392669@linutronix.de Signed-off-by: Sasha Levin commit 1d567c4bf2dcb705989c0bfb7253ebe50417deec Author: Thomas Weißschuh Date: Wed Mar 4 08:49:01 2026 +0100 sparc64: vdso: Link with -z noexecstack [ Upstream commit acc4f131d5d57c2aa89db914aeb6f7bb0ab4eb4a ] The vDSO stack does not need to be executable. Prevent the linker from creating executable. For more background see commit ffcf9c5700e4 ("x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments"). Also prevent the following warning from the linker: sparc64-linux-ld: warning: arch/sparc/vdso/vdso-note.o: missing .note.GNU-stack section implies executable stack sparc64-linux-ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker Fixes: 9a08862a5d2e ("vDSO for sparc") Suggested-by: Arnd Bergmann Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Tested-by: Andreas Larsson Reviewed-by: Andreas Larsson Acked-by: Andreas Larsson Link: https://lore.kernel.org/lkml/20250707144726.4008707-1-arnd@kernel.org/ Link: https://patch.msgid.link/20260304-vdso-sparc64-generic-2-v6-4-d8eb3b0e1410@linutronix.de Signed-off-by: Sasha Levin commit d0b8029f5d9d94566b91907993825d8fd3d76c72 Author: Boqun Feng Date: Tue Mar 3 12:16:49 2026 -0800 rust: sync: atomic: Remove bound `T: Sync` for `Atomic::from_ptr()` [ Upstream commit 4a5dc632e0b603ec1cbbf87b78de86b4b6359cff ] Originally, `Atomic::from_ptr()` requires `T` being a `Sync` because I thought having the ability to do `from_ptr()` meant multiplle `&Atomic`s shared by different threads, which was identical (or similar) to multiple `&T`s shared by different threads. Hence `T` was required to be `Sync`. However this is not true, since `&Atomic` is not the same at `&T`. Moreover, having this bound makes `Atomic::<*mut T>::from_ptr()` impossible, which is definitely not intended. Therefore remove the `T: Sync` bound. [boqun: Fix title typo spotted by Alice & Gary] Fixes: 29c32c405e53 ("rust: sync: atomic: Add generic atomics") Signed-off-by: Boqun Feng Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Alice Ryhl Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260120115207.55318-2-boqun.feng@gmail.com Link: https://patch.msgid.link/20260303201701.12204-2-boqun@kernel.org Signed-off-by: Sasha Levin commit 88a07a5787dd9566cdd77943753d5835db8b8e25 Author: Xiaoyao Li Date: Tue Mar 3 11:03:32 2026 +0800 x86/tdx: Fix the typo in TDX_ATTR_MIGRTABLE [ Upstream commit 3aecb2e7b948400354399b26f3f1653bd2c1bae0 ] The TD scoped TDCS attributes are defined by bit positions. In the guest side of the TDX code, the 'tdx_attributes' string array holds pretty print names for these attributes, which are generated via macros and defines. Today these pretty print names are only used to print the attribute names to dmesg. Unfortunately there is a typo in the define for the migratable bit. Change the defines TDX_ATTR_MIGRTABLE* to TDX_ATTR_MIGRATABLE*. Update the sole user, the tdx_attributes array, to use the fixed name. Since these defines control the string printed to dmesg, the change is user visible. But the risk of breakage is almost zero since it is not exposed in any interface expected to be consumed programmatically. Fixes: 564ea84c8c14 ("x86/tdx: Dump attributes and TD_CTLS on boot") Signed-off-by: Xiaoyao Li Signed-off-by: Dave Hansen Reviewed-by: Kirill A. Shutemov Reviewed-by: Kai Huang Acked-by: Sean Christopherson Link: https://patch.msgid.link/20260303030335.766779-2-xiaoyao.li@intel.com Signed-off-by: Sasha Levin commit 0584e74fa2b27e9e722cfb5b579f79263df20040 Author: Ravi Bangoria Date: Mon Feb 16 04:22:15 2026 +0000 perf/amd/ibs: Avoid calling perf_allow_kernel() from the IBS NMI handler [ Upstream commit b0a09142622a994c4f4088c3f61db5da87cfc711 ] Calling perf_allow_kernel() from the NMI context is unsafe and could be fatal. Capture the permission at event-initialization time by storing it in event->hw.flags, and have the NMI handler rely on that cached flag instead of making the call directly. Fixes: 50a53b60e141d ("perf/amd/ibs: Prevent leaking sensitive data to userspace") Reported-by: Sadasivan Shaiju Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Acked-by: Namhyung Kim Link: https://patch.msgid.link/20260216042216.1440-5-ravi.bangoria@amd.com Signed-off-by: Sasha Levin commit 55da177654e0dff2098838f56e30d6861ea3312e Author: Ravi Bangoria Date: Mon Feb 16 04:22:14 2026 +0000 perf/amd/ibs: Preserve PhyAddrVal bit when clearing PhyAddr MSR [ Upstream commit 723a290326e015b07931eabc603d3735999377be ] Commit 50a53b60e141 ("perf/amd/ibs: Prevent leaking sensitive data to userspace") zeroed the physical address and also cleared the PhyAddrVal flag before copying the value into a perf sample to avoid exposing physical addresses to unprivileged users. Clearing PhyAddrVal, however, has an unintended side-effect: several other IBS fields are considered valid only when this bit is set. As a result, those otherwise correct fields are discarded, reducing IBS functionality. Continue to zero the physical address, but keep the PhyAddrVal bit intact so the related fields remain usable while still preventing any address leak. Fixes: 50a53b60e141 ("perf/amd/ibs: Prevent leaking sensitive data to userspace") Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Acked-by: Namhyung Kim Link: https://patch.msgid.link/20260216042216.1440-4-ravi.bangoria@amd.com Signed-off-by: Sasha Levin commit 07aa8f3d16ba85cb6243788f7a31e8d817742fb1 Author: Ravi Bangoria Date: Mon Feb 16 04:22:12 2026 +0000 perf/amd/ibs: Account interrupt for discarded samples [ Upstream commit 01336b5559785a136de1cac49705f63a70a755bc ] Add interrupt throttling accounting for below cases: o IBS Op PMU: A software filter (in addition to the hardware filter) drops samples whose load latency is below the user-specified threshold. o IBS Fetch PMU: Samples discarded due to the zero-RIP erratum (#1197). Although these samples are discarded, the NMI cost is still incurred, so they should be counted for interrupt throttling. Fixes: 26db2e0c51fe83e1dd852c1321407835b481806e ("perf/x86/amd/ibs: Work around erratum #1197") Fixes: d20610c19b4a22bc69085b7eb7a02741d51de30e ("perf/amd/ibs: Add support for OP Load Latency Filtering") Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Acked-by: Namhyung Kim Link: https://patch.msgid.link/20260216042216.1440-2-ravi.bangoria@amd.com Signed-off-by: Sasha Levin commit 10e88340539a0282b7af08f1a3921d3710671cca Author: Bart Van Assche Date: Wed Feb 25 10:32:43 2026 -0800 ww-mutex: Fix the ww_acquire_ctx function annotations [ Upstream commit 3dcef70e41ab13483803c536ddea8d5f1803ee25 ] The ww_acquire_done() call is optional. Reflect this in the annotations of ww_acquire_done(). Fixes: 47907461e4f6 ("locking/ww_mutex: Support Clang's context analysis") Signed-off-by: Bart Van Assche Signed-off-by: Peter Zijlstra (Intel) Acked-by: Maarten Lankhorst Acked-by: Marco Elver Link: https://patch.msgid.link/20260225183244.4035378-4-bvanassche@acm.org Signed-off-by: Sasha Levin commit 803991361235bc06d7fd7a6c8bca9c4816cf69e4 Author: Bart Van Assche Date: Wed Feb 25 10:32:42 2026 -0800 signal: Fix the lock_task_sighand() annotation [ Upstream commit 39be7b21af24d1d2ed3b18caac57dd219fef226e ] lock_task_sighand() may return NULL. Make this clear in its lock context annotation. Fixes: 04e49d926f43 ("sched: Enable context analysis for core.c and fair.c") Signed-off-by: Bart Van Assche Signed-off-by: Peter Zijlstra (Intel) Acked-by: Marco Elver Link: https://patch.msgid.link/20260225183244.4035378-3-bvanassche@acm.org Signed-off-by: Sasha Levin commit 51731e863619a4cf91a34ef6157e047696477035 Author: Bart Van Assche Date: Wed Feb 25 10:32:41 2026 -0800 locking: Fix rwlock and spinlock lock context annotations [ Upstream commit 38e18d825f7281fdc16d3241df5115ce6eaeaf79 ] Fix two incorrect rwlock_t lock context annotations. Add the raw_spinlock_t lock context annotations that are missing. Fixes: f16a802d402d ("locking/rwlock, spinlock: Support Clang's context analysis") Signed-off-by: Bart Van Assche Signed-off-by: Peter Zijlstra (Intel) Acked-by: Marco Elver Link: https://patch.msgid.link/20260225183244.4035378-2-bvanassche@acm.org Signed-off-by: Sasha Levin commit 74fe3904e1749d5644e76829055e1373944133a7 Author: Thomas Gleixner Date: Tue Feb 24 17:36:59 2026 +0100 hrtimer: Reduce trace noise in hrtimer_start() [ Upstream commit f2e388a019e4cf83a15883a3d1f1384298e9a6aa ] hrtimer_start() when invoked with an already armed timer traces like: -.. [032] d.h2. 5.002263: hrtimer_cancel: hrtimer= .... -.. [032] d.h1. 5.002263: hrtimer_start: hrtimer= .... Which is incorrect as the timer doesn't get canceled. Just the expiry time changes. The internal dequeue operation which is required for that is not really interesting for trace analysis. But it makes it tedious to keep real cancellations and the above case apart. Remove the cancel tracing in hrtimer_start() and add a 'was_armed' indicator to the hrtimer start tracepoint, which clearly indicates what the state of the hrtimer is when hrtimer_start() is invoked: -.. [032] d.h1. 6.200103: hrtimer_start: hrtimer= .... was_armed=0 -.. [032] d.h1. 6.200558: hrtimer_start: hrtimer= .... was_armed=1 Fixes: c6a2a1770245 ("hrtimer: Add tracepoint for hrtimers") Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260224163430.208491877@kernel.org Signed-off-by: Sasha Levin commit ed2d49c781b4586bb8cd694c77632eaeaedde693 Author: Peter Zijlstra Date: Tue Feb 24 17:35:37 2026 +0100 hrtimer: Avoid pointless reprogramming in __hrtimer_start_range_ns() [ Upstream commit d19ff16c11db38f3ee179d72751fb9b340174330 ] Much like hrtimer_reprogram(), skip programming if the cpu_base is running the hrtimer interrupt. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Reviewed-by: Thomas Gleixner Link: https://patch.msgid.link/20260224163429.069535561@kernel.org Stable-dep-of: f2e388a019e4 ("hrtimer: Reduce trace noise in hrtimer_start()") Signed-off-by: Sasha Levin commit 235683ae0c51c0502c4edaaa35dbb2227be69568 Author: Brian Masney Date: Sun Feb 22 18:43:44 2026 -0500 irqchip/irq-pic32-evic: Address warning related to wrong printf() formatter [ Upstream commit 86be659415b0ddefebc3120e309091aa215a9064 ] This driver is currently only build on 32 bit MIPS systems. When building it on x86_64, the following warning occurs: drivers/irqchip/irq-pic32-evic.c: In function ‘pic32_ext_irq_of_init’: ./include/linux/kern_levels.h:5:25: error: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Werror=format=] Update the printf() formatter in preparation for allowing this driver to be compiled on all architectures. Fixes: aaa8666ada780 ("IRQCHIP: irq-pic32-evic: Add support for PIC32 interrupt controller") Signed-off-by: Brian Masney Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260222-irqchip-pic32-v1-1-37f50d1f14af@redhat.com Signed-off-by: Sasha Levin commit 612d36263bdaaea35ae68864c4f924a55937cb8b Author: Davidlohr Bueso Date: Tue Feb 17 11:15:11 2026 -0800 locking/mutex: Fix wrong comment for CONFIG_DEBUG_LOCK_ALLOC [ Upstream commit babcde3be8c9148aa60a14b17831e8f249854963 ] ... that endif block should be CONFIG_DEBUG_LOCK_ALLOC, not CONFIG_LOCKDEP. Fixes: 51d7a054521d ("locking/mutex: Redo __mutex_init() to reduce generated code size") Signed-off-by: Davidlohr Bueso Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260217191512.1180151-3-dave@stgolabs.net Signed-off-by: Sasha Levin commit e658ed8223f1484b3ff230c886d696fa110cbfaf Author: Davidlohr Bueso Date: Tue Feb 17 11:15:10 2026 -0800 locking/mutex: Rename mutex_init_lockep() [ Upstream commit 8b65eb52d93e4e496bd26e6867152344554eb39e ] Typo, this wants to be _lockdep(). Fixes: 51d7a054521d ("locking/mutex: Redo __mutex_init() to reduce generated code size") Signed-off-by: Davidlohr Bueso Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260217191512.1180151-2-dave@stgolabs.net Signed-off-by: Sasha Levin commit 60bfb563a399c4597dc80588a1109758a8908b97 Author: Danilo Krummrich Date: Tue Mar 24 01:59:06 2026 +0100 bus: fsl-mc: use generic driver_override infrastructure [ Upstream commit 6c8dfb0362732bf1e4829867a2a5239fedc592d0 ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Tested-by: Ioana Ciornei Acked-by: Ioana Ciornei Acked-by: Christophe Leroy (CS GROUP) Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: 1f86a00c1159 ("bus/fsl-mc: add support for 'driver_override' in the mc-bus") Link: https://patch.msgid.link/20260324005919.2408620-3-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 8f2eca0570438b94602da1297353eb7b10dcb6cb Author: Danilo Krummrich Date: Tue Mar 24 01:59:14 2026 +0100 s390/ap: use generic driver_override infrastructure [ Upstream commit 81d6f7c3a70b10ff757ee8b5f8114a190871cf1e ] When the AP masks are updated via apmask_store() or aqmask_store(), ap_bus_revise_bindings() is called after ap_attr_mutex has been released. This calls __ap_revise_reserved(), which accesses the driver_override field without holding any lock, racing against a concurrent driver_override_store() that may free the old string, resulting in a potential UAF. Fix this by using the driver-core driver_override infrastructure, which protects all accesses with an internal spinlock. Note that unlike most other buses, the AP bus does not check driver_override in its match() callback; the override is checked in ap_device_probe() and __ap_revise_reserved() instead. Also note that we do not enable the driver_override feature of struct bus_type, as AP - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n". Additionally, AP has a custom counter that is modified in the corresponding custom driver_override_store(). Fixes: d38a87d7c064 ("s390/ap: Support driver_override for AP queue devices") Tested-by: Holger Dengler Reviewed-by: Holger Dengler Reviewed-by: Harald Freudenberger Link: https://patch.msgid.link/20260324005919.2408620-11-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit b660ba045b2b22cf3b4be72773de00cb48f47be5 Author: Danilo Krummrich Date: Tue Mar 24 01:59:13 2026 +0100 s390/cio: use generic driver_override infrastructure [ Upstream commit ac4d8bb6e2e13e8684a76ea48d13ebaaaf5c24c4 ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: ebc3d1791503 ("s390/cio: introduce driver_override on the css bus") Reviewed-by: Vineeth Vijayan Link: https://patch.msgid.link/20260324005919.2408620-10-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit fb5cb4913ce333cc4647722e8c2b8378e12f2464 Author: Danilo Krummrich Date: Tue Mar 24 01:59:12 2026 +0100 vdpa: use generic driver_override infrastructure [ Upstream commit 85bb534ff12aab6916058897b39c748940a7a4c6 ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: 539fec78edb4 ("vdpa: add driver_override support") Acked-by: Eugenio Pérez Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260324005919.2408620-9-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 4dc755d86deed88789540d960e421124bad4c568 Author: Danilo Krummrich Date: Tue Mar 24 01:59:10 2026 +0100 platform/wmi: use generic driver_override infrastructure [ Upstream commit 8a700b1fc94df4d847a04f14ebc7f8532592b367 ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: 12046f8c77e0 ("platform/x86: wmi: Add driver_override support") Reviewed-by: Armin Wolf Acked-by: Ilpo Järvinen Link: https://patch.msgid.link/20260324005919.2408620-7-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit c5b2c5755495507e14f310c2653c85de0a309b1f Author: Danilo Krummrich Date: Tue Mar 24 01:59:09 2026 +0100 PCI: use generic driver_override infrastructure [ Upstream commit 10a4206a24013be4d558d476010cbf2eb4c9fa64 ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override") Acked-by: Bjorn Helgaas Acked-by: Alex Williamson Tested-by: Gui-Dong Han Reviewed-by: Gui-Dong Han Link: https://patch.msgid.link/20260324005919.2408620-6-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 970960f867ceb53b529cc5e96151133984c80ffc Author: K Prateek Nayak Date: Mon Mar 16 08:18:49 2026 +0000 cpufreq: Pass the policy to cpufreq_driver->adjust_perf() [ Upstream commit c03791085adcd61fa9b766ab303c7d0941d7378d ] cpufreq_cpu_get() can sleep on PREEMPT_RT in presence of concurrent writer(s), however amd-pstate depends on fetching the cpudata via the policy's driver data which necessitates grabbing the reference. Since schedutil governor can call "cpufreq_driver->update_perf()" during sched_tick/enqueue/dequeue with rq_lock held and IRQs disabled, fetching the policy object using the cpufreq_cpu_get() helper in the scheduler fast-path leads to "BUG: scheduling while atomic" on PREEMPT_RT [1]. Pass the cached cpufreq policy object in sg_policy to the update_perf() instead of just the CPU. The CPU can be inferred using "policy->cpu". The lifetime of cpufreq_policy object outlasts that of the governor and the cpufreq driver (allocated when the CPU is onlined and only reclaimed when the CPU is offlined / the CPU device is removed) which makes it safe to be referenced throughout the governor's lifetime. Closes:https://lore.kernel.org/all/20250731092316.3191-1-spasswolf@web.de/ [1] Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State") Reported-by: Bert Karwatzki Acked-by: Viresh Kumar Signed-off-by: K Prateek Nayak Acked-by: Gary Guo # Rust Reviewed-by: Gautham R. Shenoy Reviewed-by: Zhongqiu Han Link: https://lore.kernel.org/r/20260316081849.19368-3-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 7f5555a427bcba7b4f6da234f578491e3305282c Author: Gautham R. Shenoy Date: Thu Mar 26 17:17:46 2026 +0530 amd-pstate: Update cppc_req_cached in fast_switch case [ Upstream commit fcc25a291fbdca2c06c2c6602532050873f0c9de ] The function msr_update_perf() does not cache the new value that is written to MSR_AMD_CPPC_REQ into the variable cpudata->cppc_req_cached when the update is happening from the fast path. Fix that by caching the value everytime the MSR_AMD_CPPC_REQ gets updated. This issue was discovered by Claude Opus 4.6 with the aid of Chris Mason's AI review-prompts (https://github.com/masoncl/review-prompts/tree/main/kernel). Assisted-by: Claude:claude-opus-4.6 review-prompts/linux Reviewed-by: Mario Limonciello (AMD) Fixes: fff395796917 ("cpufreq/amd-pstate: Always write EPP value when updating perf") Signed-off-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 7f9aa2359742eaa6ea65ec0d20dafdfd0add9b8b Author: Gautham R. Shenoy Date: Thu Mar 26 17:17:45 2026 +0530 amd-pstate: Fix memory leak in amd_pstate_epp_cpu_init() [ Upstream commit beda3b363546a423e4e29a7395e04c0ac4ff677e ] On failure to set the epp, the function amd_pstate_epp_cpu_init() returns with an error code without freeing the cpudata object that was allocated at the beginning of the function. Ensure that the cpudata object is freed before returning from the function. This memory leak was discovered by Claude Opus 4.6 with the aid of Chris Mason's AI review-prompts (https://github.com/masoncl/review-prompts/tree/main/kernel). Assisted-by: Claude:claude-opus-4.6 review-prompts/linux Fixes: f9a378ff6443 ("cpufreq/amd-pstate: Set different default EPP policy for Epyc and Ryzen") Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 3ba6997cb3114ef6eff7790f7312bdfdad20032a Author: Gui-Dong Han Date: Mon Mar 23 16:58:46 2026 +0800 soundwire: debugfs: initialize firmware_file to empty string [ Upstream commit 7215e4552f31e53595eae56a834f7e286beecccc ] Passing NULL to debugfs_create_str() causes a NULL pointer dereference, and creating debugfs nodes with NULL string pointers is no longer permitted. Additionally, firmware_file is a global pointer. Previously, adding every new slave blindly overwrote it with NULL. Fix these issues by initializing firmware_file to an allocated empty string once in the subsystem init path (sdw_debugfs_init), and freeing it in the exit path. Existing driver code handles empty strings correctly. Fixes: fe46d2a4301d ("soundwire: debugfs: add interface to read/write commands") Reported-by: yangshiguang Closes: https://lore.kernel.org/lkml/17647e4c.d461.19b46144a4e.Coremail.yangshiguang1011@163.com/ Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260323085930.88894-4-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 73eba8a64ded5ab650d39a9bdb9c0a4604d2bf1f Author: Gui-Dong Han Date: Mon Mar 23 16:58:45 2026 +0800 debugfs: fix placement of EXPORT_SYMBOL_GPL for debugfs_create_str() [ Upstream commit 4afc929c0f74c4f22b055a82b371d50586da58ca ] The EXPORT_SYMBOL_GPL() for debugfs_create_str was placed incorrectly away from the function definition. Move it immediately below the debugfs_create_str() function where it belongs. Fixes: d60b59b96795 ("debugfs: Export debugfs_create_str symbol") Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260323085930.88894-3-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ba41ee2a59c783843fafd4f5ff7e5119b39c549a Author: Gui-Dong Han Date: Mon Mar 23 16:58:44 2026 +0800 debugfs: check for NULL pointer in debugfs_create_str() [ Upstream commit 31de83980d3764d784f79ff1bc93c42b324f4013 ] Passing a NULL pointer to debugfs_create_str() leads to a NULL pointer dereference when the debugfs file is read. Following upstream discussions, forbid the creation of debugfs string files with NULL pointers. Add a WARN_ON() to expose offending callers and return early. Fixes: 9af0440ec86e ("debugfs: Implement debugfs_create_str()") Reported-by: yangshiguang Closes: https://lore.kernel.org/lkml/2025122221-gag-malt-75ba@gregkh/ Suggested-by: Greg Kroah-Hartman Signed-off-by: Gui-Dong Han Link: https://patch.msgid.link/20260323085930.88894-2-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fc9157111d7c5ea8859e92dc1030284c1dc11ce2 Author: Gopi Krishna Menon Date: Fri Mar 27 14:35:24 2026 +0530 thermal/drivers/spear: Fix error condition for reading st,thermal-flags [ Upstream commit da2c4f332a0504d9c284e7626a561d343c8d6f57 ] of_property_read_u32 returns 0 on success. The current check returns -EINVAL if the property is read successfully. Fix the check by removing ! from of_property_read_u32 Fixes: b9c7aff481f1 ("drivers/thermal/spear_thermal.c: add Device Tree probing capability") Signed-off-by: Gopi Krishna Menon Signed-off-by: Daniel Lezcano Suggested-by: Daniel Baluta Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/20260327090526.59330-1-krishnagopi487@gmail.com Signed-off-by: Sasha Levin commit 876ecd61267c2bb97ac8435e6b863dbba8594572 Author: Danilo Krummrich Date: Tue Feb 3 00:48:14 2026 +0100 devres: fix missing node debug info in devm_krealloc() [ Upstream commit f813ec9e84b4d0ca81ec1da94ab07bfb4a29266c ] Fix missing call to set_node_dbginfo() for new devres nodes created by devm_krealloc(). Fixes: f82485722e5d ("devres: provide devm_krealloc()") Reviewed-by: Greg Kroah-Hartman Link: https://patch.msgid.link/20260202235210.55176-2-dakr@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 63ecfc56702713343c90d5845897c8e49ef7ff15 Author: Rafael J. Wysocki Date: Mon Feb 23 16:28:57 2026 +0100 ACPI: x86: cmos_rtc: Improve coordination with ACPI TAD driver [ Upstream commit 6cee29ad9d7e400d39ae0b1a54447fedcb62eecd ] If a CMOS RTC (PNP0B00/PNP0B01/PNP0B02) device coexists with an ACPI TAD (timer and event alarm device, ACPI000E), the ACPI TAD driver will attempt to install the CMOS RTC address space hanlder that has been installed already and the TAD probing will fail. Avoid that by changing acpi_install_cmos_rtc_space_handler() to return zero and acpi_remove_cmos_rtc_space_handler() to do nothing if the CMOS RTC address space handler has been installed already. Fixes: 596ca52a56da ("ACPI: TAD: Install SystemCMOS address space handler for ACPI000E") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2415111.ElGaqSPkdT@rafael.j.wysocki Signed-off-by: Sasha Levin commit b813e411caffa0414765623f9d872268f1cb6259 Author: Rafael J. Wysocki Date: Mon Feb 23 16:28:15 2026 +0100 ACPI: x86: cmos_rtc: Clean up address space handler driver [ Upstream commit ba0b236736dde4059bdcb8e99beaa50d6e5b6e7e ] Make multiple changes that do not alter functionality to the CMOS RTC ACPI address space handler driver, including the following: - Drop the unused .detach() callback from cmos_rtc_handler. - Rename acpi_cmos_rtc_attach_handler() to acpi_cmos_rtc_attach(). - Rearrange acpi_cmos_rtc_space_handler() to reduce the number of redundant checks and make white space follow the coding style. - Adjust an error message in acpi_install_cmos_rtc_space_handler() and make the white space follow the coding style. - Rearrange acpi_remove_cmos_rtc_space_handler() and adjust an error message in it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5094429.31r3eYUQgx@rafael.j.wysocki Stable-dep-of: 6cee29ad9d7e ("ACPI: x86: cmos_rtc: Improve coordination with ACPI TAD driver") Signed-off-by: Sasha Levin commit 5c5cca59e664634d45b4a47bbea003356c28a4c8 Author: Viresh Kumar Date: Mon Feb 23 11:05:59 2026 +0530 OPP: Move break out of scoped_guard in dev_pm_opp_xlate_required_opp() [ Upstream commit 3d2398f44a2d48fb1c575a6e0bc6b38f3e689e22 ] The commit ff9c512041f2 ("OPP: Use mutex locking guards") unintentionally made the for loop run longer than required. scoped_guard() is implemented as a for loop. The break statement now breaks out out the scoped_guard() and not out of the outer for loop. The outer loop always iterates to completion. Fix it. Fixes: ff9c512041f2 ("OPP: Use mutex locking guards") Reported-by: David Lechner Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 31b6aaf8432cb208bb76ce769798c860368e1e51 Author: Manivannan Sadhasivam Date: Fri Jan 30 12:49:40 2026 +0530 OPP: debugfs: Use performance level if available to distinguish between rates [ Upstream commit e560083c0467f86b72aecac377b27bd1e7d16c49 ] Some OPP tables have entries with same rate and different performance level. For these entries, using only the rate as the debugfs directory name causes below error: debugfs: 'opp:5000000' already exists in 'soc@0-1c00000.pci' Fix it by appending the performance level to the dir name if available. Reported-by: Bjorn Andersson Closes: https://lore.kernel.org/linux-arm-msm/75lzykd37zdvrks5i2bb4zb2yzjtm25kv3hegmikndkbr772mz@w2ykff3ny45u/ Fixes: 05db35963eef ("OPP: Add support to find OPP for a set of keys") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 2d9e16ab83f3f98a3eeebe9d01314d628089b581 Author: Qu Wenruo Date: Wed Apr 1 09:32:57 2026 +1030 btrfs: do not reject a valid running dev-replace [ Upstream commit 3c0c45a4dff73845ba93d41365fc14e45ee32bd7 ] [BUG] There is a bug report that a btrfs with running dev-replace got rejected with the following messages: BTRFS error (device sdk1): devid 0 path /dev/sdk1 is registered but not found in chunk tree BTRFS error (device sdk1): remove the above devices or use 'btrfs device scan --forget ' to unregister them before mount BTRFS error (device sdk1): open_ctree failed: -117 [CAUSE] The tree and super block dumps show the fs is completely sane, except one thing, there is no dev item for devid 0 in chunk tree. However this is not a bug, as we do not insert dev item for devid 0 in the first place. Since the devid 0 is only there temporarily we do not really need to insert a dev item for it and then later remove it again. It is the commit 34308187395f ("btrfs: add extra device item checks at mount") adding a overly strict check that triggers a false alert and rejected the valid filesystem. [FIX] Add a special handling for devid 0, and doesn't require devid 0 to have a device item in chunk tree. Reported-by: Jaron Viëtor Link: https://lore.kernel.org/linux-btrfs/CAF1bhLVYLZvD=j2XyuxXDKD-NWNJAwDnpVN+UYeQW-HbzNRn1A@mail.gmail.com/ Fixes: 34308187395f ("btrfs: add extra device item checks at mount") Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6f0f9c0a368aa1fe078109091322d3b0632d9380 Author: Filipe Manana Date: Mon Mar 23 15:50:13 2026 +0000 btrfs: fix deadlock between reflink and transaction commit when using flushoncommit [ Upstream commit b48c980b6a7e409050bb3067165db31cc6205e3e ] When using the flushoncommit mount option, we can have a deadlock between a transaction commit and a reflink operation that copied an inline extent to an offset beyond the current i_size of the destination node. The deadlock happens like this: 1) Task A clones an inline extent from inode X to an offset of inode Y that is beyond Y's current i_size. This means we copied the inline extent's data to a folio of inode Y that is beyond its EOF, using a call to copy_inline_to_page(); 2) Task B starts a transaction commit and calls btrfs_start_delalloc_flush() to flush delalloc; 3) The delalloc flushing sees the new dirty folio of inode Y and when it attempts to flush it, it ends up at extent_writepage() and sees that the offset of the folio is beyond the i_size of inode Y, so it attempts to invalidate the folio by calling folio_invalidate(), which ends up at btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it tries to lock the folio's range in inode Y's extent io tree, but it blocks since it's currently locked by task A - during a reflink we lock the inodes and the source and destination ranges after flushing all delalloc and waiting for ordered extent completion - after that we don't expect to have dirty folios in the ranges, the exception is if we have to copy an inline extent's data (because the destination offset is not zero); 4) Task A then attempts to start a transaction to update the inode item, and then it's blocked since the current transaction is in the TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the current transaction to become unblocked (its state >= TRANS_STATE_UNBLOCKED). So task A is waiting for the transaction commit done by task B, and the later waiting on the extent lock of inode Y that is currently held by task A. Syzbot recently reported this with the following stack traces: INFO: task kworker/u8:7:1053 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000 Workqueue: writeback wb_workfn (flush-btrfs-46) Call Trace: context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914 btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline] btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704 extent_writepage fs/btrfs/extent_io.c:1852 [inline] extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline] btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713 do_writepages+0x32e/0x550 mm/page-writeback.c:2554 __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750 writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042 wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227 wb_do_writeback fs/fs-writeback.c:2374 [inline] wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414 process_one_work kernel/workqueue.c:3276 [inline] process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 INFO: task syz.4.64:6910 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.64 state:D stack:22752 pid:6910 tgid:6905 ppid:5944 task_flags:0x400140 flags:0x00080002 Call Trace: context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wait_current_trans+0x39f/0x590 fs/btrfs/transaction.c:535 start_transaction+0x6a7/0x1650 fs/btrfs/transaction.c:705 clone_copy_inline_extent fs/btrfs/reflink.c:299 [inline] btrfs_clone+0x128a/0x24d0 fs/btrfs/reflink.c:529 btrfs_clone_files+0x271/0x3f0 fs/btrfs/reflink.c:750 btrfs_remap_file_range+0x76b/0x1320 fs/btrfs/reflink.c:903 vfs_copy_file_range+0xda7/0x1390 fs/read_write.c:1600 __do_sys_copy_file_range fs/read_write.c:1683 [inline] __se_sys_copy_file_range+0x2fb/0x480 fs/read_write.c:1650 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f73afc799 RSP: 002b:00007f5f7315e028 EFLAGS: 00000246 ORIG_RAX: 0000000000000146 RAX: ffffffffffffffda RBX: 00007f5f73d75fa0 RCX: 00007f5f73afc799 RDX: 0000000000000005 RSI: 0000000000000000 RDI: 0000000000000005 RBP: 00007f5f73b92c99 R08: 0000000000000863 R09: 0000000000000000 R10: 00002000000000c0 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5f73d76038 R14: 00007f5f73d75fa0 R15: 00007fff138a5068 INFO: task syz.4.64:6975 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.64 state:D stack:24736 pid:6975 tgid:6905 ppid:5944 task_flags:0x400040 flags:0x00080002 Call Trace: context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wb_wait_for_completion+0x3e8/0x790 fs/fs-writeback.c:227 __writeback_inodes_sb_nr+0x24c/0x2d0 fs/fs-writeback.c:2838 try_to_writeback_inodes_sb+0x9a/0xc0 fs/fs-writeback.c:2886 btrfs_start_delalloc_flush fs/btrfs/transaction.c:2175 [inline] btrfs_commit_transaction+0x82e/0x31a0 fs/btrfs/transaction.c:2364 btrfs_ioctl+0xca7/0xd00 fs/btrfs/ioctl.c:5206 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xff/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f73afc799 RSP: 002b:00007f5f7313d028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f5f73d76090 RCX: 00007f5f73afc799 RDX: 0000000000000000 RSI: 0000000000009408 RDI: 0000000000000004 RBP: 00007f5f73b92c99 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5f73d76128 R14: 00007f5f73d76090 R15: 00007fff138a5068 Fix this by updating the i_size of the destination inode of a reflink operation after we copy an inline extent's data to an offset beyond the i_size and before attempting to start a transaction to update the inode's item. Reported-by: syzbot+63056bf627663701bbbf@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/69bba3fe.050a0220.227207.002f.GAE@google.com/ Fixes: 05a5a7621ce6 ("Btrfs: implement full reflink support for inline extents") Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 639d20e0230085f0796a38de70ab69964efd05d9 Author: Qu Wenruo Date: Mon Feb 9 10:51:09 2026 +1030 btrfs: fix the inline compressed extent check in inode_need_compress() [ Upstream commit 883adb6dcff0f96dbbdb6488842a38b121ebd68c ] [BUG] Since commit 59615e2c1f63 ("btrfs: reject single block sized compression early"), the following script will result the inode to have NOCOMPRESS flag, meanwhile old kernels don't: # mkfs.btrfs -f $dev # mount $dev $mnt -o max_inline=2k,compress=zstd # truncate -s 8k $mnt/foobar # xfs_io -f -c "pwrite 0 2k" $mnt/foobar # sync Before that commit, the inode will not have NOCOMPRESS flag: item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160 generation 9 transid 9 size 8192 nbytes 4096 block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0 sequence 3 flags 0x0(none) But after that commit, the inode will have NOCOMPRESS flag: item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160 generation 9 transid 10 size 8192 nbytes 4096 block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0 sequence 3 flags 0x8(NOCOMPRESS) This will make a lot of files no longer to be compressed. [CAUSE] The old compressed inline check looks like this: if (total_compressed <= blocksize && (start > 0 || end + 1 < inode->disk_i_size)) goto cleanup_and_bail_uncompressed; That inline part check is equal to "!(start == 0 && end + 1 >= inode->disk_i_size)", but the new check no longer has that disk_i_size check. Thus it means any single block sized write at file offset 0 will pass the inline check, which is wrong. Furthermore, since we have merged the old check into inode_need_compress(), there is no disk_i_size based inline check anymore, we will always try compressing that single block at file offset 0, then later find out it's not a net win and go to the mark_incompressible tag. This results the inode to have NOCOMPRESS flag. [FIX] Add back the missing disk_i_size based check into inode_need_compress(). Now the same script will no longer cause NOCOMPRESS flag. Fixes: 59615e2c1f63 ("btrfs: reject single block sized compression early") Reported-by: Chris Mason Link: https://lore.kernel.org/linux-btrfs/20260208183840.975975-1-clm@meta.com/ Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 13ac062c45e436737b27f5e98c65d9154b79a6a1 Author: Aleksa Sarai Date: Wed Apr 1 01:46:21 2026 +1100 dcache: permit dynamic_dname()s up to NAME_MAX [ Upstream commit 97b67e64affb0e709eeecc50f6a9222fc20bd14b ] dynamic_dname() has had an implicit limit of 64 characters since it was introduced in commit c23fbb6bcb3e ("VFS: delay the dentry name generation on sockets and pipes"), however it seems that this was a fairly arbitrary number (suspiciously it was double the previously hardcoded buffer size). NAME_MAX seems like a more reasonable and consistent limit for d_name lengths. While we're at it, we can also remove the unnecessary stack-allocated array and just memmove() the formatted string to the end of the buffer. It should also be noted that at least one driver (in particular, liveupdate's usage of anon_inode for session files) already exceeded this limit without noticing that readlink(/proc/self/fd/$n) always returns -ENAMETOOLONG, so this fixes those drivers as well. Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support") Fixes: c23fbb6bcb3e ("VFS: delay the dentry name generation on sockets and pipes") Signed-off-by: Aleksa Sarai Link: https://patch.msgid.link/20260401-dynamic-dname-name_max-v1-1-8ca20ab2642e@amutable.com Tested-by: Luca Boccassi Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 8ae3e14d7f3df58f7f49c02d74344e3dcd5f84f0 Author: Yu Kuai Date: Fri Mar 27 22:07:29 2026 +0800 md: wake raid456 reshape waiters before suspend [ Upstream commit cf86bb53b9c92354904a328e947a05ffbfdd1840 ] During raid456 reshape, direct IO across the reshape position can sleep in raid5_make_request() waiting for reshape progress while still holding an active_io reference. If userspace then freezes reshape and writes md/suspend_lo or md/suspend_hi, mddev_suspend() kills active_io and waits for all in-flight IO to drain. This can deadlock: the IO needs reshape progress to continue, but the reshape thread is already frozen, so the active_io reference is never dropped and suspend never completes. raid5_prepare_suspend() already wakes wait_for_reshape for dm-raid. Do the same for normal md suspend when reshape is already interrupted, so waiting raid456 IO can abort, drop its reference, and let suspend finish. The mdadm test tests/25raid456-reshape-deadlock reproduces the hang. Fixes: 714d20150ed8 ("md: add new helpers to suspend/resume array") Link: https://lore.kernel.org/linux-raid/20260327140729.2030564-1-yukuai@fnnas.com/ Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 498ff507ac48862a5720ca1deac940cd5b6fee17 Author: Abd-Alrhman Masalkhi Date: Sat Mar 28 22:35:22 2026 +0300 md: remove unused static md_wq workqueue [ Upstream commit e4979f4fac4d6bbe757be50441b45e28e6bf7360 ] The md_wq workqueue is defined as static and initialized in md_init(), but it is not used anywhere within md.c. All asynchronous and deferred work in this file is handled via md_misc_wq or dedicated md threads. Fixes: b75197e86e6d3 ("md: Remove flush handling") Signed-off-by: Abd-Alrhman Masalkhi Link: https://lore.kernel.org/linux-raid/20260328193522.3624-1-abd.masalkhi@gmail.com/ Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit ab2f07bf4520e604963b16f316c5e5ab3e7ddb24 Author: Zhan Xusheng Date: Fri Apr 3 14:36:58 2026 +0800 erofs: handle 48-bit blocks/uniaddr for extra devices [ Upstream commit 63c2f06198ca7513433f1c92f2c654869d72417e ] erofs_init_device() only reads blocks_lo and uniaddr_lo from the on-disk device slot, ignoring blocks_hi and uniaddr_hi that were introduced alongside the 48-bit block addressing feature. For the primary device (dif0), erofs_read_superblock() already handles this correctly by combining blocks_lo with blocks_hi when 48-bit layout is enabled. But the same logic was not applied to extra devices. With a 48-bit EROFS image using extra devices whose uniaddr or blocks exceed 32-bit range, the truncated values cause erofs_map_dev() to compute wrong physical addresses, leading to silent data corruption. Fix this by reading blocks_hi and uniaddr_hi in erofs_init_device() when 48-bit layout is enabled, consistent with the primary device handling. Also fix the erofs_deviceslot on-disk definition where blocks_hi was incorrectly declared as __le32 instead of __le16. Fixes: 61ba89b57905 ("erofs: add 48-bit block addressing on-disk support") Suggested-by: Gao Xiang Signed-off-by: Zhan Xusheng Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit fd7a982657077469802594a5165bc30b9a55af70 Author: Yuto Ohnuki Date: Mon Mar 16 07:03:59 2026 +0000 blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default() [ Upstream commit e9b004ff83067cdf96774b45aea4b239ace99a2f ] wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from wbt_alloc() and wbt_init(). However, both are expected failure paths: - wbt_alloc() can return NULL under memory pressure (-ENOMEM) - wbt_init() can fail with -EBUSY if wbt is already registered syzbot triggers this by injecting memory allocation failures during MTD partition creation via ioctl(BLKPG), causing a spurious warning. wbt_init_enable_default() is a best-effort initialization called from blk_register_queue() with a void return type. Failure simply means the disk operates without writeback throttling, which is harmless. Replace WARN_ON_ONCE with plain if-checks, consistent with how wbt_set_lat() in the same file already handles these failures. Add a pr_warn() for the wbt_init() failure to retain diagnostic information without triggering a full stack trace. Reported-by: syzbot+71fcf20f7c1e5043d78c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=71fcf20f7c1e5043d78c Fixes: 41afaeeda509 ("blk-wbt: fix possible deadlock to nest pcpu_alloc_mutex under q_usage_counter") Signed-off-by: Yuto Ohnuki Reviewed-by: Yu Kuai Reviewed-by: Nilay Shroff Link: https://patch.msgid.link/20260316070358.65225-2-ytohnuki@amazon.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 63335e5a67d89bb7cb9b023bbb3785896587a648 Author: Uday Shankar Date: Sun Apr 5 22:25:30 2026 -0600 ublk: reset per-IO canceled flag on each fetch [ Upstream commit 0842186d2c4e67d2f8c8c2d1d779e8acffd41b5b ] If a ublk server starts recovering devices but dies before issuing fetch commands for all IOs, cancellation of the fetch commands that were successfully issued may never complete. This is because the per-IO canceled flag can remain set even after the fetch for that IO has been submitted - the per-IO canceled flags for all IOs in a queue are reset together only once all IOs for that queue have been fetched. So if a nonempty proper subset of the IOs for a queue are fetched when the ublk server dies, the IOs in that subset will never successfully be canceled, as their canceled flags remain set, and this prevents ublk_cancel_cmd from actually calling io_uring_cmd_done on the commands, despite the fact that they are outstanding. Fix this by resetting the per-IO cancel flags immediately when each IO is fetched instead of waiting for all IOs for the queue (which may never happen). Signed-off-by: Uday Shankar Fixes: 728cbac5fe21 ("ublk: move device reset into ublk_ch_release()") Reviewed-by: Ming Lei Reviewed-by: zhang, the-essence-of-life Link: https://patch.msgid.link/20260405-cancel-v2-1-02d711e643c2@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 92ad0ec509ffb188d8f849b63148664df37b4a52 Author: Yu Kuai Date: Mon Mar 30 13:52:13 2026 +0800 md: fix array_state=clear sysfs deadlock [ Upstream commit 2aa72276fab9851dbd59c2daeb4b590c5a113908 ] When "clear" is written to array_state, md_attr_store() breaks sysfs active protection so the array can delete itself from its own sysfs store method. However, md_attr_store() currently drops the mddev reference before calling sysfs_unbreak_active_protection(). Once do_md_stop(..., 0) has made the mddev eligible for delayed deletion, the temporary kobject reference taken by sysfs_break_active_protection() can become the last kobject reference protecting the md kobject. That allows sysfs_unbreak_active_protection() to drop the last kobject reference from the current sysfs writer context. kobject teardown then recurses into kernfs removal while the current sysfs node is still being unwound, and lockdep reports recursive locking on kn->active with kernfs_drain() in the call chain. Reproducer on an existing level: 1. Create an md0 linear array and activate it: mknod /dev/md0 b 9 0 echo none > /sys/block/md0/md/metadata_version echo linear > /sys/block/md0/md/level echo 1 > /sys/block/md0/md/raid_disks echo "$(cat /sys/class/block/sdb/dev)" > /sys/block/md0/md/new_dev echo "$(($(cat /sys/class/block/sdb/size) / 2))" > \ /sys/block/md0/md/dev-sdb/size echo 0 > /sys/block/md0/md/dev-sdb/slot echo active > /sys/block/md0/md/array_state 2. Wait briefly for the array to settle, then clear it: sleep 2 echo clear > /sys/block/md0/md/array_state The warning looks like: WARNING: possible recursive locking detected bash/588 is trying to acquire lock: (kn->active#65) at __kernfs_remove+0x157/0x1d0 but task is already holding lock: (kn->active#65) at sysfs_unbreak_active_protection+0x1f/0x40 ... Call Trace: kernfs_drain __kernfs_remove kernfs_remove_by_name_ns sysfs_remove_group sysfs_remove_groups __kobject_del kobject_put md_attr_store kernfs_fop_write_iter vfs_write ksys_write Restore active protection before mddev_put() so the extra sysfs kobject reference is dropped while the mddev is still held alive. The actual md kobject deletion is then deferred until after the sysfs write path has fully returned. Fixes: 9e59d609763f ("md: call del_gendisk in control path") Reviewed-by: Xiao Ni Link: https://lore.kernel.org/linux-raid/20260330055213.3976052-1-yukuai@fnnas.com/ Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit a43d77bac0b76105e90a72b281d1b0fa5111317c Author: Zhan Xusheng Date: Wed Apr 1 14:13:42 2026 +0800 erofs: include the trailing NUL in FS_IOC_GETFSLABEL [ Upstream commit d6250d49da4d8f11afc0d8991c84e0307949f92e ] erofs_ioctl_get_volume_label() passes strlen(sbi->volume_name) as the length to copy_to_user(), which copies the label string without the trailing NUL byte. Since FS_IOC_GETFSLABEL callers expect a NUL-terminated string in the FSLABEL_MAX-sized buffer and may not pre-zero the buffer, this can cause userspace to read past the label into uninitialised stack memory. Fix this by using strlen() + 1 to include the NUL terminator, consistent with how ext4 and xfs implement FS_IOC_GETFSLABEL. Signed-off-by: Zhan Xusheng Fixes: 1cf12c717741 ("erofs: Add support for FS_IOC_GETFSLABEL") Reviewed-by: Gao Xiang Reviewed-by: Chunhai Guo Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 46168395c43b70b7a2c953167c91cde99b93baec Author: Cole Leavitt Date: Wed Feb 25 16:54:06 2026 -0700 pstore/ram: fix resource leak when ioremap() fails [ Upstream commit 2ddb69f686ef7a621645e97fc7329c50edf5d0e5 ] In persistent_ram_iomap(), ioremap() or ioremap_wc() may return NULL on failure. Currently, if this happens, the function returns NULL without releasing the memory region acquired by request_mem_region(). This leads to a resource leak where the memory region remains reserved but unusable. Additionally, the caller persistent_ram_buffer_map() handles NULL correctly by returning -ENOMEM, but without this check, a NULL return combined with request_mem_region() succeeding leaves resources in an inconsistent state. This is the ioremap() counterpart to commit 05363abc7625 ("pstore: ram_core: fix incorrect success return when vmap() fails") which fixed a similar issue in the vmap() path. Fixes: 404a6043385d ("staging: android: persistent_ram: handle reserving and mapping memory") Signed-off-by: Cole Leavitt Link: https://patch.msgid.link/20260225235406.11790-1-cole@unwrap.rs Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 000e8454692cab9d1f1b80130e2870e355301d06 Author: Jackie Liu Date: Tue Mar 31 16:50:54 2026 +0800 blk-cgroup: fix disk reference leak in blkcg_maybe_throttle_current() [ Upstream commit 23308af722fefed00af5f238024c11710938fba3 ] Add the missing put_disk() on the error path in blkcg_maybe_throttle_current(). When blkcg lookup, blkg lookup, or blkg_tryget() fails, the function jumps to the out label which only calls rcu_read_unlock() but does not release the disk reference acquired by blkcg_schedule_throttle() via get_device(). Since current->throttle_disk is already set to NULL before the lookup, blkcg_exit() cannot release this reference either, causing the disk to never be freed. Restore the reference release that was present as blk_put_queue() in the original code but was inadvertently dropped during the conversion from request_queue to gendisk. Fixes: f05837ed73d0 ("blk-cgroup: store a gendisk to throttle in struct task_struct") Signed-off-by: Jackie Liu Acked-by: Tejun Heo Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260331085054.46857-1-liu.yun@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 94094e70fe292c9566502772d4d4d6d6a99204b1 Author: Deepanshu Kartikey Date: Wed Apr 1 02:52:09 2026 +0900 nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() [ Upstream commit be3e5d10643d3be1cbac9d9939f220a99253f980 ] nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy] Fixes: 7942b919f732 ("nilfs2: ioctl operations") Reported-by: syzbot+98a040252119df0506f8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=98a040252119df0506f8 Suggested-by: Ryusuke Konishi Signed-off-by: Deepanshu Kartikey Reported-by: syzbot+466a45fcfb0562f5b9a0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=466a45fcfb0562f5b9a0 Cc: Junjie Cao Signed-off-by: Ryusuke Konishi Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 29153d128384fa7c48a8ca8d34094b1cbe2d5bdc Author: Jackie Liu Date: Tue Mar 31 19:12:16 2026 +0800 block: fix zones_cond memory leak on zone revalidation error paths [ Upstream commit 2a2f520fda824b5a25c93f2249578ea150c24e06 ] When blk_revalidate_disk_zones() fails after disk_revalidate_zone_resources() has allocated args.zones_cond, the memory is leaked because no error path frees it. Fixes: 6e945ffb6555 ("block: use zone condition to determine conventional zones") Suggested-by: Damien Le Moal Signed-off-by: Jackie Liu Link: https://patch.msgid.link/20260331111216.24242-1-liu.yun@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9e19f817940113ecfe33b1f1440407c826586b5c Author: Daan De Meyer Date: Tue Mar 31 10:51:28 2026 +0000 loop: fix partition scan race between udev and loop_reread_partitions() [ Upstream commit 267ec4d7223a783f029a980f41b93c39b17996da ] When LOOP_CONFIGURE is called with LO_FLAGS_PARTSCAN, the following sequence occurs: 1. disk_force_media_change() sets GD_NEED_PART_SCAN 2. Uevent suppression is lifted and a KOBJ_CHANGE uevent is sent 3. loop_global_unlock() releases the lock 4. loop_reread_partitions() calls bdev_disk_changed() to scan There is a race between steps 2 and 4: when udev receives the uevent and opens the device before loop_reread_partitions() runs, blkdev_get_whole() in bdev.c sees GD_NEED_PART_SCAN set and calls bdev_disk_changed() for a first scan. Then loop_reread_partitions() does a second scan. The open_mutex serializes these two scans, but does not prevent both from running. The second scan in bdev_disk_changed() drops all partition devices from the first scan (via blk_drop_partitions()) before re-adding them, causing partition block devices to briefly disappear. This breaks any systemd unit with BindsTo= on the partition device: systemd observes the device going dead, fails the dependent units, and does not retry them when the device reappears. Fix this by removing the GD_NEED_PART_SCAN set from disk_force_media_change() entirely. None of the current callers need the lazy on-open partition scan triggered by this flag: - floppy: sets GENHD_FL_NO_PART, so disk_has_partscan() is always false and GD_NEED_PART_SCAN has no effect. - loop (loop_configure, loop_change_fd): when LO_FLAGS_PARTSCAN is set, loop_reread_partitions() performs an explicit scan. When not set, GD_SUPPRESS_PART_SCAN prevents the lazy scan path. - loop (__loop_clr_fd): calls bdev_disk_changed() explicitly if LO_FLAGS_PARTSCAN is set. - nbd (nbd_clear_sock_ioctl): capacity is set to zero immediately after; nbd manages GD_NEED_PART_SCAN explicitly elsewhere. With GD_NEED_PART_SCAN no longer set by disk_force_media_change(), udev opening the loop device after the uevent no longer triggers a redundant scan in blkdev_get_whole(), and only the single explicit scan from loop_reread_partitions() runs. A regression test for this bug has been submitted to blktests: https://github.com/linux-blktests/blktests/pull/240. Fixes: 9f65c489b68d ("loop: raise media_change event") Signed-off-by: Daan De Meyer Acked-by: Christian Brauner Link: https://patch.msgid.link/20260331105130.1077599-1-daan@amutable.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1f112240531f0a0b437b2e001c1d89e8b25a8328 Author: Bart Van Assche Date: Thu Mar 26 14:40:54 2026 -0700 drbd: Balance RCU calls in drbd_adm_dump_devices() [ Upstream commit 2b31e86387e60b3689339f0f0fbb4d3623d9d494 ] Make drbd_adm_dump_devices() call rcu_read_lock() before rcu_read_unlock() is called. This has been detected by the Clang thread-safety analyzer. Tested-by: Christoph Böhmwalder Reviewed-by: Christoph Hellwig Cc: Andreas Gruenbacher Fixes: a55bbd375d18 ("drbd: Backport the "status" command") Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20260326214054.284593-1-bvanassche@acm.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 02ae1c053df43bcd49495a0762dc6ef8181535c1 Author: Christoph Hellwig Date: Mon Mar 23 08:01:44 2026 +0100 fs: fix archiecture-specific compat_ftruncate64 [ Upstream commit e43dce8a0bc09083ea1145a1a0c61d83cbe72d97 ] The "small" argument to do_sys_ftruncate indicates if > 32-bit size should be reject, but all the arch-specific compat ftruncate64 implementations get this wrong. Merge do_sys_ftruncate and ksys_ftruncate, replace the integer as boolean small flag with a descriptive one about LFS semantics, and use it correctly in the architecture-specific ftruncate64 implementations. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 3dd681d944f6 ("arm64: 32-bit (compat) applications support") Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260323070205.2939118-2-hch@lst.de Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 92d875a9c6608f4fd89abf33e6416c9f86ea53fe Author: Xiao Ni Date: Thu Mar 5 09:18:33 2026 +0800 md/raid1: fix the comparing region of interval tree [ Upstream commit de3544d2e5ea99064498de3c21ba490155864657 ] Interval tree uses [start, end] as a region which stores in the tree. In raid1, it uses the wrong end value. For example: bio(A,B) is too big and needs to be split to bio1(A,C-1), bio2(C,B). The region of bio1 is [A,C] and the region of bio2 is [C,B]. So bio1 and bio2 overlap which is not right. Fix this problem by using right end value of the region. Fixes: d0d2d8ba0494 ("md/raid1: introduce wait_for_serialization") Signed-off-by: Xiao Ni Link: https://lore.kernel.org/linux-raid/20260305011839.5118-2-xni@redhat.com/ Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit b25fd3523bef88fb7ffd4c5b63bbe9c08f73bb4c Author: HyungJung Joo Date: Tue Mar 17 14:45:56 2026 +0900 fs/mbcache: cancel shrink work before destroying the cache [ Upstream commit d227786ab1119669df4dc333a61510c52047cce4 ] mb_cache_destroy() calls shrinker_free() and then frees all cache entries and the cache itself, but it does not cancel the pending c_shrink_work work item first. If mb_cache_entry_create() schedules c_shrink_work via schedule_work() and the work item is still pending or running when mb_cache_destroy() runs, mb_cache_shrink_worker() will access the cache after its memory has been freed, causing a use-after-free. This is only reachable by a privileged user (root or CAP_SYS_ADMIN) who can trigger the last put of a mounted ext2/ext4/ocfs2 filesystem. Cancel the work item with cancel_work_sync() before calling shrinker_free(), ensuring the worker has finished and will not be rescheduled before the cache is torn down. Fixes: c2f3140fe2ec ("mbcache2: limit cache size") Signed-off-by: Hyungjung Joo Link: https://patch.msgid.link/20260317054556.1821600-1-jhj140711@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 817f16ed62bc58a168417bfb5e859c2a370bab03 Author: HyungJung Joo Date: Tue Mar 17 14:48:27 2026 +0900 fs/omfs: reject s_sys_blocksize smaller than OMFS_DIR_START [ Upstream commit 0621c385fda1376e967f37ccd534c26c3e511d14 ] omfs_fill_super() rejects oversized s_sys_blocksize values (> PAGE_SIZE), but it does not reject values smaller than OMFS_DIR_START (0x1b8 = 440). Later, omfs_make_empty() uses sbi->s_sys_blocksize - OMFS_DIR_START as the length argument to memset(). Since s_sys_blocksize is u32, a crafted filesystem image with s_sys_blocksize < OMFS_DIR_START causes an unsigned underflow there, wrapping to a value near 2^32. That drives a ~4 GiB memset() from bh->b_data + OMFS_DIR_START and overwrites kernel memory far beyond the backing block buffer. Add the corresponding lower-bound check alongside the existing upper-bound check in omfs_fill_super(), so that malformed images are rejected during superblock validation before any filesystem data is processed. Fixes: a3ab7155ea21 ("omfs: add directory routines") Signed-off-by: Hyungjung Joo Link: https://patch.msgid.link/20260317054827.1822061-1-jhj140711@gmail.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit ca5b1ce081b007d16b39c8bbbce7ea8c2475f16e Author: Chen Cheng Date: Tue Feb 10 21:38:47 2026 +0800 md: suppress spurious superblock update error message for dm-raid [ Upstream commit eff0d74c6c8fd358bc9474c05002e51fa5aa56ad ] dm-raid has external metadata management (mddev->external = 1) and no persistent superblock (mddev->persistent = 0). For these arrays, there's no superblock to update, so the error message is spurious. The error appears as: md_update_sb: can't update sb for read-only array md0 Fixes: 8c9e376b9d1a ("md: warn about updating super block failure") Reported-by: Tj Closes: https://lore.kernel.org/all/20260128082430.96788-1-tj.iam.tj@proton.me/ Signed-off-by: Chen Cheng Reviewed-by: Paul Menzel Link: https://lore.kernel.org/linux-raid/20260210133847.269986-1-chencheng@fnnas.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 1f71ea04e6bda891c4269e601a467fb9dfb8b52d Author: Ming Lei Date: Wed Mar 11 11:28:37 2026 +0800 blk-cgroup: wait for blkcg cleanup before initializing new disk [ Upstream commit 3dbaacf6ab68f81e3375fe769a2ecdbd3ce386fd ] When a queue is shared across disk rebind (e.g., SCSI unbind/bind), the previous disk's blkcg state is cleaned up asynchronously via disk_release() -> blkcg_exit_disk(). If the new disk's blkcg_init_disk() runs before that cleanup finishes, we may overwrite q->root_blkg while the old one is still alive, and radix_tree_insert() in blkg_create() fails with -EEXIST because the old blkg entries still occupy the same queue id slot in blkcg->blkg_tree. This causes the sd probe to fail with -ENOMEM. Fix it by waiting in blkcg_init_disk() for root_blkg to become NULL, which indicates the previous disk's blkcg cleanup has completed. Fixes: 1059699f87eb ("block: move blkcg initialization/destroy into disk allocation/release handler") Cc: Yi Zhang Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260311032837.2368714-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin