commit 9a66fdc0d7fd55f54235524a73435af99051e46f Author: Greg Kroah-Hartman Date: Fri Sep 25 16:37:14 2026 +0200 Linux 7.2.8 Link: https://lore.kernel.org/r/20260923140644.756254324@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Salvatore Bonaccorso Tested-by: Ron Economos Tested-by: Pavel Machek (CIP) Tested-by: Takeshi Ogasawara Tested-by: Markus Reichelt Tested-by: Justin M. Forbes Tested-by: Wentao Guan Tested-by: Benjamin Boortz Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman commit 070cfdcabe8a961aebd2b9074b47c9843a699be7 Author: Namjae Jeon Date: Wed Sep 9 09:58:22 2026 +0900 ksmbd: fix partial normalized name responses commit f4fafaf02174c32bce2f9bb4196fadf13f1fd96e upstream. Windows may request FILE_NORMALIZED_NAME_INFORMATION with an output buffer that only fits the fixed portion of the variable-length response. Treat the fixed portion as FILE_NORMALIZED_NAME_INFORMATION_SIZE so ksmbd returns STATUS_BUFFER_OVERFLOW instead of STATUS_INFO_LENGTH_MISMATCH. This avoids rejecting valid partial normalized-name responses. Fixes: 6b8b79226bc3 ("ksmbd: fix partial file information responses") Reported-by: Mobin Aydinfar Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 5612934c255ad9352d07181f14981cfabd7b7a95 Author: Mario Limonciello Date: Wed Aug 26 13:51:02 2026 -0500 drm/amdgpu: restrict BAR0 fallback read to SR-IOV VFs only commit bd1f08246b8a2564d8ac61df715b6bcd5f994729 upstream. The BAR0 fallback read path was introduced as a workaround for SR-IOV VFs where the VRAM aperture is not available during early init. Restrict this workaround to only SR-IOV VFs where it's needed. Reported-by: gloveless@jqluv.com Fixes: cba4928cdffa ("drm/amdgpu: reduce early full GPU access during SR-IOV init") Acked-by: Alex Deucher Link: https://patch.msgid.link/20260826185102.2269511-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit d8a0affd207c813bd063fa2c27786f449eaf92b8) Signed-off-by: Greg Kroah-Hartman commit 1169fe8c11ca45e3f91d59a73eb271d0ca8a7fb0 Author: Vadim Nikitushkin Date: Wed Sep 9 23:50:28 2026 +0300 drm/ttm: fix swapped-out resources never leaving their bulk_move range commit 3db7d7d583419f7b1f2e141e36418802dbb25cf8 upstream. ttm_tt_swapout() returns the number of pages swapped out on success and a negative error code on failure; for a populated ttm it never returns zero. Commit b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") moved the bulk_move bookkeeping in ttm_bo_swapout_cb() under "if (!ret)", so the ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() pair is now skipped on every successful swapout. The equivalent change for the shrinker in commit 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") tests "lret > 0", which is what was intended here as well. Before b2ed01e7ad3d the resource was taken off the bulk_move before the swapout; since then a swapped-out resource stays inside its BO's bulk_move range (and on the manager LRU) although it is unevictable. When it is later freed or the BO leaves the bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()), ttm_resource_del_bulk_move() skips it because of its !ttm_resource_unevictable() guard, so a range endpoint in pos->first / pos->last is left pointing at freed memory. The next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor is a use-after-free, seen as the resv WARN in ttm_lru_bulk_move_add(), "list_del corruption" in ttm_resource_move_to_lru_tail() or a NULL dereference in ttm_resource_manager_next() -- minutes to hours after a hibernation, or at process exit / reboot following one. Samuel Ainsworth's analysis of drm/amd issue 5387 (see Link) identified the dangling cursor; the missing removal at swapout time is the reason it dangles. Testing the condition for success restores the removal. On an AMD Phoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on a 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31) the bug crashed 5 of 18 hibernation cycles; a function profile of one hibernation showed 336 ttm_tt_swapout() calls and zero ttm_resource_del_bulk_move_unevictable() calls. With this change the removal happens for every swapped-out resource and 12 further cycles were clean. Fixes: b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") Cc: stable@vger.kernel.org # v7.1+ Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5387 Link: https://lore.kernel.org/dri-devel/CAHYiNPa6aVacJoLOje-qZ1GyYx-9p0tN4NuP8D_eSL+UJeevXw@mail.gmail.com/ Signed-off-by: Vadim Nikitushkin Reviewed-by: Thomas Hellström Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260909205028.13799-1-bub4z0r@gmail.com [ Squashed with commit fcfe64715b425262af1b36f498f9197f3537ceed ("drm/ttm: apply the swapout bulk_move fix to the intended condition"): upstream 3db7d7d58341 was applied to the "if (ret)" after ttm_resource_try_charge() in ttm_bo_alloc_at_place() instead of the "if (!ret)" after ttm_tt_swapout() in ttm_bo_swapout_cb(), and fcfe64715b42 restored the former and changed the latter. 7.2.y has no ttm_resource_try_charge() (dmem cgroup charging is 7.3 material), so neither commit applies on its own; the net effect of the two is the single hunk below, which is the change the changelog describes. ] Signed-off-by: Greg Kroah-Hartman commit 6971a8a7acf19e653565c760e2fd23bc0ad3645f Author: Iván Ezequiel Rodriguez Date: Thu Jul 23 15:12:59 2026 -0500 ntsync: reject wait ioctls with zero owner commit 61611481f7b599e0526a3782c626b1a9deeb48bd upstream. setup_wait() already validates pad and flags but not owner, while Documentation/userspace-api/ntsync.rst requires EINVAL when owner is zero. Reject early before queueing waiters. Signed-off-by: Iván Ezequiel Rodriguez Signed-off-by: Griffin Kroah-Hartman Reviewed-by: Elizabeth Figura Signed-off-by: Elizabeth Figura Link: https://patch.msgid.link/20260723201301.11826-4-zfigura@codeweavers.com Cc: Alice Ryhl Signed-off-by: Greg Kroah-Hartman commit 9a7b2bd590252115772130b66ea5f142a259a349 Author: Mario Limonciello Date: Tue Sep 22 15:34:00 2026 -0400 drm/amdgpu: Fix GPU PCIe link capability reporting [ Upstream commit 04de4007d32385b8b6a5dd72bff3146dfdc592c3 ] Commit eb53125a7ad9 ("drm/amd: Add dedicated helper for amdgpu_device_find_parent()") made amdgpu_device_gpu_bandwidth() query the first device outside the dGPU. That is the host side of the physical link, not the GPU side. As a result, the ASIC and platform capability masks can both be based on the host port. drm_amdgpu_info_device then exposes the host capabilities to userspace, such as Gen5 x16 for a Gen4 x8 GPU. Cache both ends of the physical link during device initialization. Use link_dev for the GPU capability and link_partner for the platform capability and _PR3 detection. Reported-by: "Marek Olšák" Closes: https://lore.kernel.org/amd-gfx/CAAxE2A4VhsAzzO1QjBjUg+NgnbD04ZzMyN6xsUJxjKJHH6hxiw@mail.gmail.com/ Suggested-by: Lijo Lazar Fixes: eb53125a7ad9 ("drm/amd: Add dedicated helper for amdgpu_device_find_parent()") Reviewed-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 7ea6a47224e2c6e89a3a682d7fbaace4817a55aa) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 95eccb9be68df6449d854242b5fcdfd063a2fac1 Author: chong li Date: Tue Sep 22 15:33:59 2026 -0400 drm/amdgpu: reduce early full GPU access during SR-IOV init [ Upstream commit cba4928cdffaa0f9012acff0ec4f896320107077 ] Allow early FB reads to fall back to BAR0 when the VRAM aperture is not ready. This lets SR-IOV VFs consume host-provided init data before requesting full GPU access. For ASICs that support request_init_data, defer full GPU access until after non-GPU early init to shorten the full-access window. Legacy ASICs(before NV12) do not send request_init_data; the host dumps init data only during full GPU access, so keep the original early full-access request path for them. Signed-off-by: chong li Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Stable-dep-of: 04de4007d323 ("drm/amdgpu: Fix GPU PCIe link capability reporting") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 085264d580bc90deac4b496c7b27b11584a4ac79 Author: Arun Easi Date: Tue Sep 22 11:23:12 2026 -0400 scsi: fnic: Fix missed link-up when critical IRQ targets offline CPU [ Upstream commit 0cb1fd924126f1f581621a5e804df98a02be9dff ] When CPU Hyper Threading is disabled, sibling CPUs remain present but are reported offline. Managed MSI-X IRQs can still receive affinity masks that include those offline CPUs. If a driver-critical vector is managed, it can be parked on an offline CPU and the driver may miss critical events such as link-up. Keep driver-critical vectors unmanaged so they can be migrated by the IRQ core when their target CPU is offlined. Since HWQ-0 is unmanaged now, in some queue combinations there can be no mappings to it in mq_map. So without the blk-mq fix mentioned below, system may crash during cpu offline/online tests. Fixes: 8a8449ca5e33 ("scsi: fnic: Modify ISRs to support multiqueue (MQ)") Cc: stable@vger.kernel.org Depends-on: commit 10845a105bbc ("blk-mq: skip CPU offline notify on unmapped hctx") Reviewed-by: Sesidhar Baddela Reviewed-by: Arulprabhu Ponnusamy Reviewed-by: Gian Carlo Boffa Reviewed-by: Karan Tilak Kumar Signed-off-by: Arun Easi Reviewed-by: Laurence Oberman Link: https://patch.msgid.link/20260903175547.57971-1-aeasi@cisco.com Signed-off-by: Martin K. Petersen (Oracle) [ Inlined fnic_mq_init_queue_map() into fnic_mq_map_queues_cpus() using the existing cpu variable. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fb6b90807d593d70d59ee9ce367f29592069daca Author: Karan Tilak Kumar Date: Tue Sep 22 11:23:11 2026 -0400 scsi: fnic: Bump up version number [ Upstream commit 2265541d221dc550dc89b52e49e9d9eb2f824996 ] Bump up version number to 1.9.0.0. Reviewed-by: Sesidhar Baddela Reviewed-by: Arulprabhu Ponnusamy Reviewed-by: Gian Carlo Boffa Reviewed-by: Arun Easi Reviewed-by: Hannes Reinecke Reviewed-by: Lee Duncan Tested-by: Karan Tilak Kumar Signed-off-by: Karan Tilak Kumar Co-developed-by: Hannes Reinecke Link: https://patch.msgid.link/20260724174811.5118-14-kartilak@cisco.com Signed-off-by: Martin K. Petersen Stable-dep-of: 0cb1fd924126 ("scsi: fnic: Fix missed link-up when critical IRQ targets offline CPU") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cb2781062c3c8e994d1ee8d9cd18d7c56e689222 Author: Karan Tilak Kumar Date: Tue Sep 22 11:23:10 2026 -0400 scsi: fnic: Make debug logging protocol independent [ Upstream commit b93c38a9f2ce5441c90de55776f8df97679cf8a2 ] Make the fnic debug macros take struct fnic instead of struct Scsi_Host so FCP and NVMe initiator roles can share the same logging interface. Add fnic_printk() to route FCP initiator messages through shost_printk() and non-SCSI role messages through printk(). Add role and non-SCSI role messages through printk(). Add role predicates and separate FDLS, FIP, and NVMe logging masks. Convert FCS, FIP, SCSI, ISR, and main debug call sites to pass the fnic instance directly, and keep FIP VLAN MAC descriptors skipped while reporting unexpected descriptor types. Reviewed-by: Sesidhar Baddela Reviewed-by: Arulprabhu Ponnusamy Reviewed-by: Gian Carlo Boffa Reviewed-by: Arun Easi Reviewed-by: Hannes Reinecke Reviewed-by: Lee Duncan Signed-off-by: Karan Tilak Kumar Co-developed-by: Hannes Reinecke Link: https://patch.msgid.link/20260724174811.5118-2-kartilak@cisco.com Signed-off-by: Martin K. Petersen Stable-dep-of: 0cb1fd924126 ("scsi: fnic: Fix missed link-up when critical IRQ targets offline CPU") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7e218f10253a3420b17a47def418a578577f8ade Author: Qi Zheng Date: Tue Sep 22 08:19:25 2026 -0400 fs: fix missed removal of super_fs_objects_eligible() [ Upstream commit 641aade99f06df0037e52b5c81645461b7132947 ] Commit 0ef8faff490be ("fs: push nr_cached_objects memcg gating into individual filesystems") was meant to drop the blanket memcg gate in fs/super.c and let each ->nr_cached_objects() implementation decide for itself whether it is meaningful in per-memcg reclaim. However, when that patch was applied the removal of super_fs_objects_eligible() and its two call sites in super_cache_scan() / super_cache_count() was lost, so the helper is still gating every ->nr_cached_objects() hook and 0ef8faff490be is effectively a no-op. Consequences of the leftover gate: - XFS's inode-reclaim hook, which is intentionally driven from per-memcg contexts to free memcg-charged slab, is still short-circuited in fs/super.c exactly the regression from commit 0baad6f9b997 ("fs/super: skip non-memcg-aware nr_cached_objects in memcg slab shrink") that 0ef8faff490be was written to undo. Memcg-charged XFS inode slab therefore keeps piling up under per-memcg pressure until global reclaim kicks in. - Any future ->nr_cached_objects()/->free_cached_objects() that grows memcg awareness is likewise blocked before it can run, so filesystems cannot opt in to per-memcg reclaim on their own defeating the whole point of pushing the gating decision down into the callbacks. Drop the leftover helper and its call sites so the intent of 0ef8faff490be actually takes effect. Link: https://lore.kernel.org/cover.1786955972.git.zhengqi.arch@bytedance.com Link: https://lore.kernel.org/3b038d373c70ebac7cdabfb0035bb91d1d6e6cfe.1786955972.git.zhengqi.arch@bytedance.com Link: https://lore.kernel.org/all/20260715103516.2410175-1-usama.arif@linux.dev/ [0] Fixes: 0ef8faff490b ("fs: push nr_cached_objects memcg gating into individual filesystems") Signed-off-by: Qi Zheng Acked-by: Usama Arif Cc: Baolin Wang Cc: Christian Brauner Cc: David Hildenbrand Cc: Hugh Dickins Cc: Johannes Weiner Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cb1848884445c80c2a724e56be958458f6f002ef Author: Usama Arif Date: Tue Sep 22 08:19:24 2026 -0400 fs/super: skip non-memcg-aware nr_cached_objects in memcg slab shrink [ Upstream commit 0baad6f9b9970c6e3f1d33dbfd17d1a77702771d ] The super_block shrinker is registered with SHRINKER_MEMCG_AWARE because its dentry and inode LRUs are memcg-aware (via list_lru). But the optional ->nr_cached_objects() hooks that the shrinker also drives are not memcg-aware: btrfs extent maps and xfs inode reclaim operate on filesystem-global state, and shmem's unused-huge shrinker walks a per-superblock shrinklist. None of them filter by sc->memcg. The mismatch shows up under memcg-heavy slab reclaim. shrink_slab_memcg() calls do_shrink_slab() once per (memcg, NUMA node) pair for every memcg whose bit is set in the per-superblock shrinker bitmap, which on a busy host means hundreds of calls per reclaim pass. Each scan queues the same global shrinker work item that's already kicked from the root path. Because btrfs/xfs global count is typically non-zero on any in-use filesystem, the returned total stays positive even if a memcg's own dentry/inode LRUs are empty. shrink_slab_memcg() therefore never clears the SB shrinker bit in the memcg bitmap, so subsequent reclaim passes from the same memcg re-enter super_cache_count() and pay for the global counter walk again. Restrict ->nr_cached_objects() to the global shrink path (sc->memcg NULL or root). The memcg-aware dentry/inode LRUs keep being counted and scanned per memcg as before; only the global fs-specific hooks are skipped. The root/global shrink path still drives those hooks; only their invocation from non-root memcg slab reclaim is removed. Signed-off-by: Usama Arif Link: https://patch.msgid.link/20260609123047.1948242-1-usama.arif@linux.dev Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: 641aade99f06 ("fs: fix missed removal of super_fs_objects_eligible()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit eac6917a42899aad0617bbf04798c5dd946a1fe5 Author: Frank Sorenson Date: Wed Sep 16 16:33:58 2026 -0500 smb: client: fix missing iov bounds check in parse_posix_sids() commit b09d092eb24ad0110f16a9b7c1ed5d2a0c1733dc upstream. In parse_posix_sids(), sidsbuf_end is calculated using the server-supplied out_len without being validated against the actual length of the received iov (iov_len). If a server provides an inflated out_len, sidsbuf_end will point past the end of the iov. This defeats the bounds guards in posix_info_sid_size(), allowing out-of-bounds reads into adjacent kernel memory. Fix this by rejecting responses where the calculated sidsbuf_end would exceed the received iov boundaries or cause pointer wraparound. Fixes: a90f37e3d7ac ("smb: client: parse owner/group when creating reparse points") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit f03178db2c260104b8790d068265d725810c2d5c Author: Frank Sorenson Date: Wed Sep 16 16:33:55 2026 -0500 smb: client: fix missing lower-bound check on DFS referral string offsets commit e83330c55edc0c3ac08aa6c95e49e4694c65523b upstream. parse_dfs_referrals() checks that DfsPathOffset and NetworkAddressOffset do not exceed the buffer end, but fails to check that they don't point inside the referral header itself. If a server provides an offset smaller than sizeof(struct dfs_referral_level_3), the derived string pointer overlaps with the struct fields, causing cifs_strndup_from_utf16() to interpret header data as UTF-16 strings. Fix this by enforcing that string offsets are at least sizeof(*ref). Fixes: 4ecce920e13a ("CIFS: move DFS response parsing out of SMB1 code") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 282b72f9a7ef31296c48366db4128882999cc048 Author: Frank Sorenson Date: Wed Sep 16 16:33:54 2026 -0500 smb: client: fix server->total_read for compound encrypted PDUs commit f73726b83e4756fdaa099e1bc1143293bd57ad79 upstream. In receive_encrypted_standard(), server->total_read is left at the full decrypted frame size when walking sub-PDUs of a compound encrypted frame. As a result, cifs_handle_standard() passes this full size to smb2_check_message(), causing the PDU length guards to incorrectly validate the entire compound frame instead of the current sub-PDU. This allows truncated non-last sub-PDUs to bypass length validation, leading to out-of-bounds reads in smb2_get_data_area_len(). Fix this by setting server->total_read to the true length of the current sub-PDU: next_cmd for non-last sub-PDUs, and the remaining pdu_length for the last one. Fixes: b24df3e30cbf ("cifs: update receive_encrypted_standard to handle compounded responses") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 8dc5db3a0e583ea8d31d0613cefd99e93e095c3c Author: Frank Sorenson Date: Wed Sep 16 16:34:00 2026 -0500 smb: client: fix reparse buffer bounds in cifs_query_reparse_point() commit 5f0306e731e2f46e91419eae57eee3a241c055e0 upstream. In cifs_query_reparse_point(), the start >= end check before casting to struct reparse_data_buffer * only ensures the start pointer is within the response. It fails to verify that there is enough space remaining for the fixed 8-byte header of the structure. If a server provides a DataOffset that leaves less than 8 bytes remaining, the check passes, but subsequent reads of ReparseTag and ReparseDataLength will occur out-of-bounds. Fix this by ensuring the remaining space is at least the size of the reparse_data_buffer structure before accessing its fields. Fixes: 56e84c64fc25 ("cifs: Fix validation of SMB1 query reparse point response") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit dbe452a905dfe2804647530a9ff3d7e3826ed04d Author: Frank Sorenson Date: Wed Sep 16 16:33:59 2026 -0500 smb: client: fix potential OOB read in smb3_enum_snapshots() commit 4775c3b7a597907e0b97556c7986fda238a377ae upstream. If snapshot_array_size is smaller than GMT_TOKEN_SIZE, smb3_enum_snapshots() sets ret_data_len to sizeof(struct smb_snapshot_array) without verifying the actual length of the server's reply. Because SMB2_ioctl() places no lower bound on the server-supplied OutputCount and allocates retbuf to exactly that length, a short reply results in ret_data_len exceeding the size of retbuf. The subsequent copy_to_user() then reads past the end of retbuf, leaking adjacent slab memory to userspace. The subsequent clamp check is ineffective as it only reduces ret_data_len. Fix this by rejecting replies shorter than sizeof(struct smb_snapshot_array) with -EIO. Note that the bound is set to the 12-byte struct size rather than the 16-byte MIN_SNAPSHOT_ARRAY_SIZE defined in MS-SMB2 3.3.5.15.1, because 12 bytes is exactly what copy_to_user() attempts to read. Fixes: e02789a53d71 ("smb3: enumerating snapshots was leaving part of the data off end") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 13efcd37a9b3d6ffa1579c3dda3e29c893ed9bca Author: Frank Sorenson Date: Wed Sep 16 16:33:57 2026 -0500 smb: client: fix OOB struct field reads in move_smb2_ea_to_cifs() commit eeb5ef6083e1cefa2ef75041b5597ff228b8d7bb upstream. In move_smb2_ea_to_cifs(), the while (src_size > 0) loop condition is insufficient. It allows iteration to continue even if the remaining src_size is too small to contain a complete smb2_ea_info structure. Consequently, reads of ea_name_length and ea_value_length can occur out-of-bounds. Fix this by ensuring src_size >= sizeof(*src) before attempting to read any structure fields. Additionally, reject any next_entry_offset that is smaller than sizeof(*src) or that would advance the pointer beyond the available buffer. Note that for calls where the server returns a malformed EA list, the error returned to userspace changes from -ENODATA (getxattr) or -ERANGE (listxattr) to -EIO. This correctly signals a server protocol error rather than misleadingly indicating "attribute not present" or "output buffer too small". Fixes: 95907fea4fd8 ("cifs: Add support for reading attributes on SMB2+") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 858d5ac22cb889266993e7670f9f0c4f4aeedd78 Author: Frank Sorenson Date: Wed Sep 16 16:33:52 2026 -0500 smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs commit 05762c5bc1cfdcac36747994fde2c04387a457f1 upstream. Fix several related bounds checking and pointer lifecycle issues in receive_encrypted_standard()'s handling of compound encrypted frames: - Clear next_buffer after assigning it to server->bigbuf. A stale next_buffer pointer can lead to a use-after-free on subsequent error paths. - Update pdu_length to the decrypted plaintext size (buf_size). Using the pre-decryption length allows NextCommand to point into stale ciphertext residue. - Reject next_cmd values smaller than MID_HEADER_SIZE(server). - Fix an integer overflow in the upper bound check by verifying pdu_length - next_cmd < MID_HEADER_SIZE(server), ensuring the trailing slice is large enough for a header. Fixes: b24df3e30cbf ("cifs: update receive_encrypted_standard to handle compounded responses") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 3630dfc729b15b887ad47b088d57944cae769150 Author: Paulo Alcantara Date: Sun Sep 13 21:15:41 2026 -0300 smb: client: fix fattr leaking on wsl_to_fattr() failure commit e1253a82bb4c0fed6706a5839fc8b6e01be1abe2 upstream. wsl_to_fattr() mutates fattr fields as it parses each WSL EA. If validation later fails, the function returns false with partially mutated fattr fields that callers do not reset. Fix this by parsing into local variables and only committing them to fattr on success. Closes: https://sashiko.dev/#/patchset/20260906200517.725015-1-pc%40manguebit.org Fixes: 78e26bec4d6d ("smb: client: parse uid, gid, mode and dev from WSL reparse points") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Tom Talpey Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 13e43cf5e47e7bc2189abd93ee246c6defa5f89f Author: Paulo Alcantara Date: Sun Sep 13 21:09:15 2026 -0300 smb: client: fix unaligned access in WSL reparse point parser commit e1aeaf79dea51e6065da56924bc07e22d59012ac upstream. When wsl_to_fattr() parses WSL extended attributes, it computes a payload pointer from ea->ea_data + ea_name_length + 1. Since the smb2_file_full_ea_info struct is __packed and all WSL xattr names are 6 bytes long, the value pointer always lands at an odd byte offset, never satisfying __le32 or __le64 alignment requirements. The code then casts this pointer to __le32 * or __le64 * and dereferences it directly, which may cause alignment faults on some architectures. Replace all such casts with get_unaligned_le32() and get_unaligned_le64() in reparse_mkdev(), wsl_make_kuid(), wsl_make_kgid() and wsl_to_fattr(). Closes: https://sashiko.dev/#/patchset/20260906200517.725015-1-pc%40manguebit.org Fixes: 78e26bec4d6d ("smb: client: parse uid, gid, mode and dev from WSL reparse points") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Tom Talpey Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b26a3fcf2f1c2cadba400290b639f01395db8fc8 Author: Paulo Alcantara Date: Sat Sep 12 14:20:08 2026 -0300 smb: client: fix smbd_connection leak on cifs_get_tcp_session() error commit e75c96157d45e498970158c8f7373d90102e33b9 upstream. When an RDMA connection is successfully established via smbd_get_connection() but cifs_get_tcp_session() later fails (e.g. kthread_create() returns an error), the error path frees tcp_ses without first destroying the smbd_connection. Fix this by calling smbd_destroy() in the out_err cleanup path before kfree(tcp_ses). smbd_destroy() safely handles the case where smbd_conn is NULL, so it can be called unconditionally. Closes: https://sashiko.dev/#/patchset/20260912165503.521597-1-pc%40manguebit.org Fixes: 2f8946464b11 ("CIFS: SMBD: Upper layer connects to SMBDirect session") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Tom Talpey Cc: Stefan Metzmacher Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1e6be99a50e8786c09c3e60e6574ee81682eb57c Author: Frank Sorenson Date: Wed Sep 16 16:33:56 2026 -0500 smb: client: reject short Next offsets in parse_server_interfaces() commit 1b3221bb121079ad79a1f3c3aa360ba649832e7a upstream. In parse_server_interfaces(), the server-supplied Next offset is validated against bytes_left, but not against the size of the interface structure itself. A small, non-zero Next value can pass the bounds check but advance the pointer by less than sizeof(*p). This causes the next iteration of the loop to read misaligned, overlapping structure fields. Fix this by ensuring the Next offset is at least sizeof(*p). Fixes: 7d34ec36abb8 ("smb3: fix for slab out of bounds on mount to ksmbd") Cc: stable@vger.kernel.org Signed-off-by: Frank Sorenson Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit ec36b38e65596950e6c29bed7dfc90b98707c19c Author: Joseph Qi Date: Tue Sep 1 09:04:13 2026 +0800 smb: client: fix use-after-free of iface in cifs_try_adding_channels() commit d034e836eefd7ce75e588f7031cffbeec594f5ac upstream. cifs_try_adding_channels() iterates ses->iface_list with list_for_each_entry_safe_from(), which captures the next entry (niface) under iface_lock. The loop body then drops iface_lock for the whole duration of cifs_ses_add_channel(). A concurrent interface refresh (SMB3_request_interfaces() -> parse_server_interfaces()) marks all ifaces inactive and removes and frees any that are not re-advertised via list_del() + kref_put(), where release_iface() is a bare kfree(). Since niface typically has no channel holding a reference, the list reference is its last and it can be freed inside the unlocked window. On continue, the iterator advance step then dereferences niface->iface_head.next, and the loop body reads iface->rdma_capable/is_active, both on freed memory. Fix this by never keeping an unreferenced list pointer across the unlocked window. Each channel attempt now re-scans the list from the head under iface_lock, takes a kref on the selected candidate, and passes only that referenced candidate to cifs_ses_add_channel(). weight_fulfilled still tracks selection progress, so restarting the scan preserves the original weighted distribution and the weight_fulfilled-before-kref_put ordering on the failure path. Add a per-pass attempts cap so a flapping interface refresh cannot keep the inner loop spinning within a single tries increment. Fixes: aa45dadd34e4 ("cifs: change iface_list from array to sorted linked list") Cc: stable@vger.kernel.org Assisted-by: Qoder:Qwen3.8-Max Signed-off-by: Joseph Qi Acked-by: Shyam Prasad N Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit c037d6bde3dd5fa00b017b6b98a5389ec0ebc02f Author: Paulo Alcantara Date: Wed Sep 9 13:52:14 2026 -0300 smb: client: fix rlist race and missing initialization commit 5f270f091256da1338c3631083e15d7f83cc05e1 upstream. TCP_Server_Info.rlist is allocated via kzalloc which zeros both ->next and ->prev to NULL instead of pointing to itself, making list_empty() always return false and list_add() dereference a NULL ->prev pointer. Also, cifs_signal_cifsd_for_reconnect() can be called concurrently from multiple cifsd threads, allowing the same server's rlist node to be added twice into the local list, corrupting it. Closes: https://sashiko.dev/#/patchset/20260911204446.1719356-1-pc%40manguebit.org Fixes: df0e03a4fb94 ("smb: client: fix potential deadlock when reconnecting channels") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Tom Talpey Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 73df937d9cb984d1719b000f7ea6b344e5799416 Author: April Cardenas Date: Thu Sep 10 00:16:49 2026 -0500 smb/client: send lease break ACKs thru correct session for multiuser mounts commit ebc5660132ddd244b57f03ed324922013a3d7363 upstream. Currently, when cifs_oplock_break handles a break request from the server it searches for the appropriate tlink to handle the request but incorrectly uses the current fsuid as the search key, eventually causing read errors for users with multiuser mounts on NetApp. Fix this by using the tlink from the cfile struct instead to respond through the correct session. As breaks are handled in a worker thread, the current fsuid isn't guaranteed to match the session that the break is intended for. This means that cifs_sb_tlink may search the rbtree using the wrong fsuid, and return a tlink with an incorrect session than the lease break was intended for. As a result, the breaks may be ACKed through an incorrect session. While it seems that Samba/Windows Servers 2016-2025 ignore this as long as the lease key is correct, we ran into a case where if you're using NetApp ONTAP or Azure NetApp Files they will reject the ACK and return `STATUS_LOCK_NOT_GRANTED` errors on any future read requests a user may initiate through their still held open file handle, and the server will eventually close the file. In the dmesg logs, the user may see errors like these: CIFS: Status code returned 0xc0000128 STATUS_FILE_CLOSED CIFS: VFS: Send error in read = -9 With a multiuser mount using NetApp, this issue is really easy for users to hit on a wide variety of kernel versions by attempting to copy a file from the share to the local machine through GNOME Files/Nautilus. This copy will always result in Nautilus throwing a `Bad File Descriptor` error to the user and fail. With this fix, you can copy files through Nautilus without issue. >From looking at the traces, it seems that glib will open the file first, and call listxattr before actually attempting to copy the file data. The listxattr call always triggers a break, causing the copy to fail. The proposed fix returns to the way the client grabbed the tlink before commit e8f5f849ffce2 ("cifs: fix potential oops in cifs_oplock_break"). The bulk of that commit (checking for list empty) remains untouched, and I think the change to using cifs_sb_tlink was intended to avoid a NULL/ERR deference on the tlink as well as update the reference count. I believe this fix should preserve those safety properties, but of course I'd appreciate any corrections here. Fixes: e8f5f849ffce2 ("cifs: fix potential oops in cifs_oplock_break") Cc: stable@vger.kernel.org Signed-off-by: April Cardenas Reviewed-by: Namjae Jeon Reviewed-by: Bharath S M Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 2e5103e11a17c274715dd56cf185eeedccf686b8 Author: Paulo Alcantara Date: Fri Sep 11 22:38:04 2026 -0300 smb: client: cancel reconnect work in clean_demultiplex_info() commit c65eae6f61d1778ff7a82e4aae4080e26f486af1 upstream. clean_demultiplex_info() cancels server->echo delayed work but not server->reconnect, which can cause a use-after-free when the demultiplex thread exits while a reconnect work is still queued: cifs_demultiplex_thread() cifs_readv_from_socket() cifs_reconnect() __cifs_reconnect() cifs_queue_server_reconn() mod_delayed_work(cifsiod_wq, &server->reconnect, 0) clean_demultiplex_info() cancel_delayed_work_sync(&server->echo) // echo canceled // reconnect NOT canceled kfree_sensitive(server) // server freed ...later, on cifsiod_wq: smb2_reconnect_server() server->srv_count // UAF read of freed server Fix this by canceling server->reconnect delayed work in clean_demultiplex_info() before the server is freed, the same way cifs_put_tcp_session() already does. Reported-by: syzbot+5003556314abc915a71f@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/6aa4a12d.f81106d8.2ab401.0023.GAE@google.com Fixes: 53e0e11efe92 ("CIFS: Fix a possible memory corruption during reconnect") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Shyam Prasad N Cc: Ronnie Sahlberg Cc: Tom Talpey Cc: Bharath SM Cc: Namjae Jeon Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6f5319bbaef2b5f93225ace074e140d5b618123c Author: Vladimir Marioukhine Date: Wed Aug 12 13:19:46 2026 -0400 drm/amdkfd: implement restore_mqd callbacks for GFX12/12.1 commit 5f28bb1c2cd9dcdb76a20d61b3ea069b85893c59 upstream. kfd_mqd_manager_v12.c (GFX 12.0) and kfd_mqd_manager_v12_1.c (GFX 12.1) do not implement restore_mqd callbacks, leaving the function pointers NULL and causing CRIU restore to return -EOPNOTSUPP on GFX12. Implement restore_mqd for both compute and SDMA queues in kfd_mqd_manager_v12.c and kfd_mqd_manager_v12_1.c, modeled after the GFX 11 implementation with the following improvements: - update cp_mqd_base_addr_lo/hi to the newly allocated MQD address, fixing a pre-existing gap shared with v11 where the in-MQD copy still pointed at the old checkpoint-time address after restore - memset the full allocation before memcpy for compute queues to avoid stale data in the GTT sub-allocator tail; SDMA MQDs use sizeof(*m) since they are packed at mqd_size stride in a shared BO checkpoint_mqd registration is deferred to a follow-up patch that also implements get_checkpoint_info, so that checkpoint and restore are enabled together as a complete and testable unit. Note: GFX12.1 restore handles XCC0 only. Multi-XCC CRIU restore is currently unreachable due to a separate validation issue in kfd_criu_restore_queue(). A pr_warn_once() is emitted if a multi-XCC device is encountered. Signed-off-by: Vladimir Marioukhine Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit b1f9601237d050f5df478464cf51bf1fff29a256) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 82e1b8299c6da02ce02185c208d2fdf7572b5ea1 Author: David Francis Date: Wed Aug 5 09:51:35 2026 -0400 drm/amdkfd: Avoid integer underflow with ffs in EOP ring size calc commit c883d0a132d430ef7ebb23fd94323be94d0fbdb8 upstream. The low 6 bits of cp_hqd_eop_control store the base-2 logarithm of the EOP ring size. This was calculated as ffs(q->eop_ring_buffer_size / sizeof(unsigned int)) - 1 - 1 But ffs can in theory return 1 or 0, so this could underflow (although in practice the ring buffer size cannot be less than 4096). Change this to ffs(q->eop_ring_buffer_size / sizeof(unsigned int) / 4) using properties of logarithms. Reviewed-by: Kent Russell Signed-off-by: David Francis Signed-off-by: Alex Deucher (cherry picked from commit 4f18c56630383c14bfc6b2d65f88f2f895d2121a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 287a34c4d712e0bdb67751e21316d9c8d75a528a Author: David Francis Date: Wed Aug 5 09:16:51 2026 -0400 drm/amdkfd: Avoid integer underflow in EOP ring size calculation. commit 8ee521b8b189799e361d4233c5180ba56656d4d4 upstream. The low 6 bits of cp_hqd_eop_control store the base-2 logarithm of the EOP ring size. This was calculated as order_base_2(q->eop_ring_buffer_size / 4) - 1 But order_base_2 can in theory return 0, so this could underflow (although in practice the ring buffer size cannot be less than 4096). Change this to order_base_2(q->eop_ring_buffer_size / 8) using properties of logarithms. Also add to the above comment to make the mathematics more clear. Reviewed-by: Kent Russell Signed-off-by: David Francis Signed-off-by: Alex Deucher (cherry picked from commit f0f43fcf8b2b3a924cad9444340921c96ed5f634) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 157d3f1db7e7e6f320daa221fae84a4c13555b6f Author: Mario Limonciello Date: Tue Sep 15 12:51:24 2026 -0500 drm/amdgpu: Skip KFD mapping clear before initialization commit 7f9caa70aef0950e06d395ca0035831214d88187 upstream. amdgpu_amdkfd_clear_kfd_mapping() assumes that a non-NULL kfd_dev has a fully populated node array. This is not true when KFD device initialization fails after probe. For example, kgd2kfd_device_init() sets num_nodes before checking PCIe atomics support. On Polaris systems without the required atomics, it returns before allocating nodes[0], but the kfd_dev remains attached to the amdgpu device. A later GPU reset then dereferences nodes[0]->id. Require the authoritative KFD initialization flag before walking the node array, matching the existing KFD reset and teardown paths. Fixes: 70cadefcc616 ("drm/amdgpu: unmap all user mappings of framebuffer and doorbell before mode1 reset") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5833 Reviewed-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 4ac1835823c47903fbb278bbf474773c46f59edc) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1b63348329e0dff309e0f587ca51c114b12e645b Author: Mike Lothian Date: Sat Sep 12 00:29:08 2026 +0100 drm/amdgpu: hold a runtime PM reference for P2P dma-buf attachments commit 636139603b99d2e3a18a46cf3f8d39313ce8042e upstream. amdgpu_dma_buf_map() adds VRAM to the allowed domains for a peer2peer attachment. GTT is only a fallback placement when VRAM is preferred, so ttm_bo_validate() migrates the buffer from GTT into VRAM. While the exporting device is runtime suspended its SDMA rings are down and the move fails: amdgpu: Move buffer fallback to memcpy unavailable An importer on a second GPU reaches this holding no runtime PM reference on the exporter, e.g. a compositor on the APU submitting a frame that references a buffer exported by an idle dGPU: amdgpu_cs_ioctl -> amdgpu_cs_parser_bos -> amdgpu_cs_bo_validate -> ttm_bo_validate -> amdgpu_bo_move -> dma_buf_map_attachment -> amdgpu_dma_buf_map -> ttm_bo_validate -> amdgpu_bo_move Pinning a dma-buf into VRAM has the same requirement, which commit 030631e97b20 ("drm/amdgpu: revert "take runtime pm reference when we attach a buffer" v2") called out as the one case that would need the reference back. Take it in attach and drop it in detach. pm_runtime_get_if_active() never resumes the device, so it cannot deadlock against the reservation taken during resume, which is why the old pm_runtime_get_sync() had to go. If the device is not active, clear peer2peer instead: the buffer then stays in GTT, which remains accessible while the GPU is powered down. If runtime PM is disabled, take a plain reference so the put in detach stays balanced. Fixes: 030631e97b20 ("drm/amdgpu: revert "take runtime pm reference when we attach a buffer" v2") Suggested-by: Christian König Reviewed-by: Christian König Signed-off-by: Mike Lothian Assisted-by: Claude:Opus-5 [Claude Code] Signed-off-by: Alex Deucher (cherry picked from commit 062ff15e30a48d14fb7d7558eba84f8dc97197f0) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a645584c3ccc493ee835f77155829442bd7578c3 Author: Chengjun Yao Date: Tue Sep 8 10:15:43 2026 +0800 drm/amdgpu: fix rmmio iounmap skipped on device removal commit 5155002b03b24ba3ef91c5c313b8cf0171b24904 upstream. amdgpu_pci_remove() calls drm_dev_unplug() before fini_sw(), so drm_dev_enter() is already false there and the iounmap() guarded by it is skipped. This .remove path runs on both hot-unplug and plain rmmod, so the register BAR ioremap mapping leaks one instance per unload. Unmap rmmio unconditionally (guard only on non-NULL) and drop the now unused idx. Fixes: 62d5f9f7110a ("drm/amdgpu: Unmap MMIO mappings when device is not unplugged") Signed-off-by: Chengjun Yao Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher (cherry picked from commit dd6f86a97260e5207d3329ad03aa89fdad61b1e6) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e89900c441fec90644baf49c3f46ce76d91c51e4 Author: Tvrtko Ursulin Date: Tue Sep 15 16:05:57 2026 +0100 drm/sched: Fix virtual runtime race commit 2ab510e63197360945f915dd5631a77c63ac6b27 upstream. Prevent pushing a new job to an entity seeing it being the first in the queue, and hence entering the drm_sched_rq_add_entity() path, if the pop side in drm_sched_entity_pop_job() has just de-queued the job but not yet updated the saved virtual time. Restoring the unsaved virtual time, which is at this point not a delta but still an absolute value, pushes the said entity to the rear of the run queue for a potentially very long time. We close this race by pulling the locked sections out to encompass both the queue push/pop and corresponding rbtree management. This is aligned with the future direction to replace the current lockless job queue with one of the fully locked standard list primitives. Signed-off-by: Tvrtko Ursulin Fixes: 2fa4d8e2c109 ("drm/sched: Add fair scheduling policy") Suggested-by: Luke.Wildhardt@proton.me # via Claude Opus Tested-by: Luke.Wildhardt@proton.me Cc: Christian König Cc: Danilo Krummrich Cc: Philipp Stanner Cc: Pierre-Eric Pelloux-Prayer Cc: Matthew Brost Cc: Vitaly Prosyak Cc: stable@vger.kernel.org # v7.2+ [phasta: commit title] Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260915150557.62847-1-tvrtko.ursulin@igalia.com Signed-off-by: Greg Kroah-Hartman commit 713abac5c04ccbae67f9ac68c3921845535388e7 Author: Jonghyuk Kim(MalHyuk) Date: Wed Sep 2 10:27:20 2026 +0900 drm/msm: RCU-free the scheduler-containing ring and VM objects commit 01c8d1f385f788f1bbbbb7687c4386d614281218 upstream. Both struct msm_ringbuffer and struct msm_gem_vm embed a struct drm_gpu_scheduler. msm_ringbuffer_destroy() and the VM free callback msm_gem_vm_free() call drm_sched_fini() on the embedded scheduler and then free the containing object with plain kfree(). drm_sched_fence_get_timeline_name() returns fence->sched->name, and the scheduler fence keeps a .release callback so it is not ops-detached on signalling. A finished fence exported to userspace (the submit out-fence, or a VM_BIND fence, via sync_file / drm_syncobj) keeps pointing at the embedded scheduler after the ring/VM is freed, so a later get_timeline_name() -- reachable unprivileged through SYNC_IOC_FILE_INFO -- dereferences freed slab memory (KASAN slab-use-after-free read). Per the dma-fence lifetime contract the exporter must keep the data backing a signalled fence alive for an RCU grace period. Free the scheduler-containing objects with kfree_rcu() instead of kfree(). Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler") Fixes: 92395af63a99 ("drm/msm: Add VM_BIND submitqueue") Cc: stable@vger.kernel.org Signed-off-by: Jonghyuk Kim(MalHyuk) Patchwork: https://patchwork.freedesktop.org/patch/750234/ Message-ID: <20260902012720.880783-1-malhyuk97@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit ad4fd6cfac9def17500be722f0e3df182e414c5c Author: Guangshuo Li Date: Sun Sep 13 16:58:14 2026 +0800 drm/msm/hdmi_phy: fix runtime PM cleanup on probe failure commit f4fae975db08a9aeec0b15e145c7d4d0fe02a0ec upstream. msm_hdmi_phy_probe() enables runtime PM before enabling the PHY resources and initializing the PLL, but failures from either operation return without calling the matching pm_runtime_disable(). The remove path disables runtime PM, but it is not called when probe fails. As a result, runtime PM remains enabled after an unsuccessful probe. Route failures after pm_runtime_enable() through a common error path and disable runtime PM before returning. This issue was found by manual code inspection. Fixes: 15b4a4523859 ("drm/msm/hdmi: Create a separate HDMI PHY driver") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Krzysztof Kozlowski Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/753043/ Link: https://lore.kernel.org/r/20260913085814.1509352-1-lgs201920130244@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit fd25668f96ff68193acbc222e0e1b8eed1211110 Author: Saim Shujah Date: Fri Aug 28 11:54:40 2026 +0500 drm/msm/dpu: clear pending peripheral flush state commit a5b5cc909931572aec446e129c035b76b3f0c1fa upstream. dpu_hw_ctl_clear_pending_flush() resets the cached per-block state after a flush transaction, but misses pending_periph_flush_mask. The peripheral flush updater accumulates interface bits in this mask. A later transaction which sets the top-level peripheral flush bit can write stale interface bits to CTL_PERIPH_FLUSH together with the current state. Peripheral flush support was added after the helper started clearing every individual pending flush mask. Clear the peripheral mask together with the other cached child masks. Fixes: 64f7b81f0358 ("drm/msm/dpu: add support of new peripheral flush mechanism") Cc: stable@vger.kernel.org Signed-off-by: Saim Shujah Patchwork: https://patchwork.freedesktop.org/patch/748968/ Link: https://lore.kernel.org/r/20260828065440.140410-1-saimzst@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit ebc273b45d58a0fd8cb1d028ac4c4f64821b331b Author: Guangshuo Li Date: Sat Aug 8 21:16:24 2026 +0800 drm/msm/adreno: fix autosuspend cleanup during teardown commit 6fbbf1e152f34ad3913e4a6476680aba672c5068 upstream. adreno_gpu_init() calls pm_runtime_use_autosuspend(), but adreno_gpu_cleanup() does not call the matching pm_runtime_dont_use_autosuspend() during teardown. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to adreno_gpu_cleanup(). This issue was found by manual code inspection. Fixes: eeb754746b14 ("drm/msm/gpu: use pm-runtime") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/745110/ Link: https://lore.kernel.org/r/20260808131624.2854412-1-lgs201920130244@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman commit 1826bbee68f9600918851603f8c9b00b9858a904 Author: Sophie D Date: Wed Sep 9 21:49:10 2026 -0400 drm/gud: Ignore damage clips in full update mode commit effce1cb87ee0d8b3a8cbe7722968f4ea7efd360 upstream. When running in full update mode, previously small updates (such as moving the mouse across the screen) would cause many full frames to be generated. This would bog down the bus and lower the effective framerate significantly - I was seeing a drop from 60 FPS to 2 FPS. Set ignore_damage_clips in full update mode so the damage iterator yields a single full-plane rectangle instead of one per clip. Fixes: 73cfd166e045 ("drm/gud: Replace simple display pipe with DRM atomic helpers") Cc: # 6.18.x Signed-off-by: Sophie D Reviewed-by: Thomas Zimmermann Acked-by: Ruben Wauters Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260910014910.8564-1-patches@scd31.com Signed-off-by: Greg Kroah-Hartman commit ea57100955c1c2a525ba1a98c18d9a05b25aeedb Author: Sajal Gupta Date: Wed Sep 2 18:00:57 2026 +0530 drm/gud: fix out-of-bounds write in gud_plane_atomic_check() commit 59ced288fcba9e91bd38e61a972ad782c4edb7d0 upstream. The plane property loop uses req->properties[num_properties + i] as write index while simultaneously incrementing `num_properties` inside the loop. At iteration i, num_properties has also incremented by i, so the write is done at `initial_num_properties + 2*i`, skipping every other index and advancing by 2 per iteration. With just 2 connector and 32 plane properties the last write happens at index 64, one slot past the end of the 64-slot (indices 0–63) allocation. A USB device can trigger OOB by advertising the maximum number of properties. Fix by dropping the redundant `+ i`; num_properties is already the correct running index, as gud_connector_fill_properties() fills the preceding slots. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/20260821071812.16500-1-sajal2005gupta%40gmail.com?part=1 Signed-off-by: Sajal Gupta Cc: Acked-by: Ruben Wauters Signed-off-by: Ruben Wauters Link: https://patch.msgid.link/20260902123254.36987-1-sajal2005gupta@gmail.com Signed-off-by: Greg Kroah-Hartman commit 46c223468537a05a404699771cd3e68532dab5e6 Author: Devin Wittmayer Date: Fri Sep 4 13:03:38 2026 -0700 wifi: mac80211: refuse to make a monitor active when it has no queue commit 2b04d6556964ae9f89819b86a0a7801e39c3aae5 upstream. A monitor interface only gets a TXQ if it's created active, and one can't be added later. Setting the flag on a down interface is still allowed, so the driver is handed a monitor with no queue. ath9k dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000066 RIP: 0010:ath_tx_node_init+0x49/0x170 [ath9k] ath9k_add_interface+0x10c/0x140 [ath9k] drv_add_interface+0x54/0x250 [mac80211] ieee80211_do_open+0x32f/0x800 [mac80211] Reached with CAP_NET_ADMIN by "iw dev X set monitor active" followed by "ip link set X up". RTNL is held, so netlink operations block behind it. Refuse the flag when there is no queue to give. Fixes: 79af1f866193 ("mac80211: avoid allocating TXQs that won't be used") Cc: stable@vger.kernel.org Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260904200338.10829-1-lucid_duck@justthetip.ca Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 3beddbd56946577478fd5e649f556aaaebe15b0a Author: Ivan Pustogarov Date: Thu Sep 3 17:26:16 2026 +0200 wifi: mac80211: avoid out-of-bounds read for empty PREQ elements commit e6031f02269c0f51cf67886d177f02bc300b47cd upstream. ieee80211_mesh_preq_size_ok() derives the location of the PREQ bottom fields before checking whether the element contains even the fixed header. ieee80211_mesh_hwmp_preq_get_bottom() reads the flags byte to account for the optional Address Extension field. Consequently, an empty PREQ element causes a one-byte read beyond its declared payload. Move the helper call after both size checks, so the bottom fields are only accessed when they are present. Fixes: 8b40b1d24a60 ("wifi: mac80211: Fix overread in PREQ frame processing") Cc: stable@vger.kernel.org Signed-off-by: Ivan Pustogarov Link: https://patch.msgid.link/20260903152616.1646637-1-ivan@ipust.net Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit c4ee5685af444024e6222ce29f6ed36adc44ffc3 Author: Rik van Riel Date: Sat Aug 8 10:47:55 2026 -0400 wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver commit da2ca406f45a6e21760243152ed8d2e8e72915c2 upstream. ieee80211_set_bitrate_mask() checks if the interface is running via ieee80211_sdata_running(), but it does not check if the interface is still present in the driver. When sdata is running but IEEE80211_SDATA_IN_DRIVER is not set, the call reaches drv_set_bitrate_mask() in driver-ops.h which hits wlan1: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.h:884 at drv_set_bitrate_mask Syzkaller triggers this via wext SIOCSIWRATE ioctl. The Call Trace shows wext_ioctl_dispatch() in wext-core.c dispatching the ioctl, calling ioctl_standard_call() for SIOCSIWRATE, which calls cfg80211_wext_siwrate() in wext-compat.c. That builds a bitrate mask and calls rdev_set_bitrate_mask() which ends up in ieee80211_set_bitrate_mask() in cfg.c. The interface is marked running via SDATA_STATE_RUNNING but flags is 0, so check_sdata_in_driver() fails. When the interface is being torn down, or when wext ioctl is issued during interface bringup before drv_add_interface() sets IN_DRIVER, the running check passes while IN_DRIVER is clear. Check IEEE80211_SDATA_IN_DRIVER in ieee80211_set_bitrate_mask() before calling the driver, returning -ENETDOWN. This avoids the WARN_ONCE in driver-ops.h and matches other cfg.c operations that bail early when not in driver. This change should be safe because wiphy mutex is held in cfg80211_wext_siwrate() via guard(wiphy), and IN_DRIVER is set/cleared under RTNL and wiphy paths in drv_add_interface() and drv_remove_interface() in driver-ops.c, so the check is race-free against driver add/remove. Returning -ENETDOWN is the same error other not-running paths use and does not introduce new locking. Reported-by: syzbot+af177aa139efdd13a9da@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=af177aa139efdd13a9da Link: https://lore.kernel.org/all/6a75205c.59b6c763.2bba34.00c3.GAE@google.com/ Fixes: 554a43d5e77e ("mac80211: check sdata_running on ieee80211_set_bitrate_mask") Cc: stable@vger.kernel.org Assisted-by: Hermes:muse-spark-1.2 syzkaller Signed-off-by: Rik van Riel Link: https://patch.msgid.link/20260808104755.319c686e@fangorn Reported-by: syzbot+dcaca020ca8377e7ced0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dcaca020ca8377e7ced0 [also add second syzbot report] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4832e202c6b6b3f7cfcabdbca15b2e9589372e95 Author: Zhao Li Date: Tue Aug 25 19:25:23 2026 +0800 wifi: mwifiex: validate action frame fixed fields commit 1c25bfad93e69ce13f744a2fb919f02ea396a985 upstream. mwifiex_process_mgmt_packet() accepts an rx_pkt_length as small as a four-address struct ieee80211_hdr plus the two-byte firmware length prefix. After stripping the prefix, mwifiex_parse_mgmt_packet() can receive a frame equal to sizeof(struct ieee80211_hdr). For action frames, the parser reads the category byte immediately after that header and, for a public action frame, reads the following action code byte without verifying that either field is present. A truncated frame can therefore make the parser consume up to two bytes past the firmware-declared frame length. If those bytes look like a TDLS discovery response, the malformed frame can spuriously update peer signal state. Require the category and public action-code fields before reading them. Use sizeof(*ieee_hdr) so the checks and field accesses directly match the firmware four-address layout being parsed before address4 is removed. Suggested-by: Johannes Berg Suggested-by: Brian Norris Fixes: 72e5aa8d2a6d ("mwifiex: support for parsing TDLS discovery frames") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/66f148d83eb9f0970b9abbccc85d1b61244e54ad.camel@sipsolutions.net/ Link: https://lore.kernel.org/all/20260708195911.84365-8-enderaoelyther@gmail.com/ Link: https://lore.kernel.org/all/20260723011013.76968-1-enderaoelyther@gmail.com/ Link: https://lore.kernel.org/all/20260723202257.688-1-enderaoelyther@gmail.com/ Link: https://lore.kernel.org/all/anuWyiPQja6_5vly@google.com/ Assisted-by: Codex:gpt-5 Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260825112523.95774-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 877b61a67d5eb3e616478daf3908114b57feff1e Author: Linmao Li Date: Thu Aug 20 14:21:55 2026 +0800 wifi: mwifiex: prevent authentication frame length truncation commit fa00193eb991f92b007aefe7afb6a7566976dacf upstream. mwifiex_cfg80211_authenticate() derives the authentication frame length from req->ie_len and req->auth_data_len, both of type size_t, but stores it in a u16. NL80211_ATTR_AUTH_DATA only has a minimum length policy. Since nla_len is a u16, a single attribute can carry up to 65531 bytes of payload, so the sum can exceed U16_MAX before it is assigned to pkt_len. The truncated pkt_len determines the skb frame area, while the copy length remains req->auth_data_len - 4, resulting in a heap buffer overflow. For example, with auth_data_len equal to 65510 and no IEs, the sum is 65546. It is truncated to 10 and then reduced by four to 6. The driver appends only six bytes to the skb with skb_put(), but then copies 65506 user-provided bytes into the authentication body. Reaching this path requires CAP_NET_ADMIN in the user namespace owning the network namespace, an up station netdev, and a suitable BSS/SAE authentication request. Compute the length in size_t, reject values that cannot be represented by the firmware's u16 frame length field, and only then assign it to pkt_len. Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode") Cc: stable@vger.kernel.org # 6.12+ Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260820062155.3981976-1-lilinmao@kylinos.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 7106ad8b74f50cca1ef36131f327d2c78f556daa Author: Pengpeng Hou Date: Sat Aug 15 21:52:27 2026 +0800 wifi: mwifiex: validate scan response extents commit 3687d7d48070838cc2953431b3a27717cab0aaf6 upstream. mwifiex_ret_802_11_scan() subtracts the fixed response fields and the firmware-provided BSS length from resp->size without first proving that either extent fits. A short response or oversized BSS length can therefore underflow tlv_buf_size and make the TLV parser walk beyond the command response. Compute the fixed extent from the selected normal or background scan response. Validate that the fixed fields and BSS data fit before deriving the TLV extent and entering the parser. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260815135227.50392-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 46cda9d42f0d6ec3057d878ddb1f38c0ab9f51df Author: Doruk Tan Ozturk Date: Fri Aug 14 15:47:04 2026 +0200 wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length commit e667aee1c192d67d27c803007bfa9c6e0873e959 upstream. mwifiex_search_oui_in_ie() reads a pairwise-cipher (PTK) count from a beacon/probe-response RSN or WPA information element and then walks that many 4-byte OUIs, comparing each with memcmp(). The count comes straight from the (attacker-supplied) IE and is never checked against the element's own length, and the callers admit the element on element_id alone (has_ieee_hdr() / has_vendor_hdr(), no length check). A crafted RSN/WPA IE with a large pairwise count therefore makes the walk read up to 255 * 4 bytes past the element -- an out-of-bounds read of the kmemdup()'d beacon buffer, reachable from any AP whose beacon/probe response is processed during scan-result parsing. Pass the number of IE bytes available at the OUI list and bound the walk to the element. Keep the length signed and reject a negative value before any unsigned arithmetic, so a small or zero IE length cannot underflow to a large size_t and defeat the bound. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Cc: stable@vger.kernel.org Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk Link: https://patch.msgid.link/20260814134704.85902-1-doruk@0sec.ai Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit d82492fd0a3fb61963c236521852763238ad3898 Author: Shengzhuo Wei Date: Mon Aug 31 02:42:13 2026 +0800 wifi: p54: require a full exp_if record in PDR_INTERFACE_LIST commit d8efd84f49379ed28624098821f80e992657d935 upstream. The PDR_INTERFACE_LIST loop only checks that the record start is within the entry before reading an entire struct exp_if from it. A truncated trailing record makes the if_id/variant reads cross the entry boundary into the heap beyond the EEPROM buffer (verified with a KASAN reproducer of the loop). The variant also feeds the synth front-end selection, so this is not only a leak. Advance only while a full record still fits in the entry. Fixes: eff1a59c48e3 ("[P54]: add mac80211-based driver for prism54 softmac hardware") Cc: stable@vger.kernel.org Acked-by: Christian Lamparter Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Link: https://patch.msgid.link/20260831-p54-pda-validation-v2-2-dae566b388c8@cherr.cc Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit b0c906107150b16925ee66da09127259864c7f36 Author: Shengzhuo Wei Date: Mon Aug 31 02:42:12 2026 +0800 wifi: p54: validate curve data length in the calibration curve converters commit ce858fa6b8a214dee5adb82358885fa024cdd887 upstream. p54_convert_rev0() and p54_convert_rev1() read calibration curve data from the device-supplied EEPROM entry using channel and points-per-channel counts taken verbatim from that same entry, so an entry that declares more data than it carries drives an out-of-bounds read past the EEPROM buffer (verified with a KASAN reproducer of the conversion loop). The sibling converters p54_convert_output_limits() and p54_convert_db() already validate their counts against the entry length; this path was missed. Reject the entry when the counts do not fit in the entry data. Fixes: eff1a59c48e3 ("[P54]: add mac80211-based driver for prism54 softmac hardware") Cc: stable@vger.kernel.org Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Link: https://patch.msgid.link/20260831-p54-pda-validation-v2-1-dae566b388c8@cherr.cc Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 14dcf4c3d74c878175b19d3da5986f83f26b1dd5 Author: Tianchu Chen Date: Fri Sep 4 13:39:34 2026 +0000 wifi: wilc1000: fix RX buffer OOB-write in wilc_wlan_handle_isr_ext() commit c1ba7f7f18465e259cf1b4d9c73fc73853d7f790 upstream. wilc_wlan_handle_isr_ext() takes the RX transfer size from the device-reported interrupt status register (a 15-bit field shifted left by 2, up to 131068 bytes) and reads that many bytes from the device into rx_buffer, which is only WILC_RX_BUFF_SIZE (96K) large. The wrap check only handles the current offset; the size itself is never compared against the buffer, so a bogus SDIO device can make the driver OOB-write rx_buffer by up to ~32K with data it controls. The oversized transfer also leaves rx_buffer_offset past the end of the buffer, after which the unsigned wrap check stops working and the overflow can repeat. Drop any transfer whose size exceeds the RX buffer, acknowledging the data interrupt and re-arming the RX engine so the bogus frame is discarded and reception can continue. This also restores the rx_buffer_offset <= WILC_RX_BUFF_SIZE invariant the wrap check relies on. This is not expected to change driver behavior in most cases: without this check, an oversized transfer would most likely corrupt neighboring kernel memory instead of completing anyway, and the drop path performs the same interrupt acknowledgment and RX engine re-arming as the normal path, so subsequent transfers are received unaffected. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/7c971924c6bdccf6c2f75704a5a746e9303aaf64@linux.dev Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 6fbe76eb2796d2aee45cc6a2dd16e85d3cc96304 Author: Ali Ahmet Memis Date: Fri Aug 7 11:52:30 2026 +0000 wifi: wilc1000: fix out-of-bounds read in P2P public action frames commit ba6cb7c0868a412c2eb68e8efd5aa38bfb258a14 upstream. wilc_wfi_p2p_rx() and mgmt_tx() start parsing a frame once ieee80211_is_public_action() returns true. That helper only verifies the frame is long enough for the action category field, that is offsetofend(struct ieee80211_mgmt, u.action.category), 25 bytes. Both functions then read the P2P public action header up to oui_subtype at offset 30 and pass "size - ie_offset" to cfg80211_find_vendor_ie(), where ie_offset is offsetof(struct ieee80211_mgmt, u) + sizeof(*d), i.e. 32. A public action frame of 25 to 31 bytes passes the check but is shorter than that 32 byte header, so oui_subtype can be read out of bounds, and because the length is unsigned, "size - ie_offset" underflows to a value close to 4 GiB. cfg80211_find_vendor_ie() takes an unsigned int length, so even the size_t subtraction in mgmt_tx() is truncated to the same value. It then walks far past the buffer searching for a vendor element until it reaches unmapped memory. In the receive path the frame arrives over the air and needs no association, so a nearby unauthenticated device can crash the host while it is in P2P listen. Reject frames shorter than the P2P public action header in both paths before dereferencing it. Fixes: 4fb8b5aa2a11 ("staging: wilc1000: refactor p2p action frames handling API's") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Link: https://patch.msgid.link/20260807115230.136767-1-ali@iusegentoo.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a6bb6ad517a0d4db33a0cac9448e3ae9f4008fb4 Author: Runyu Xiao Date: Thu Aug 20 20:51:26 2026 +0800 wifi: wlcore: release runtime PM ref on regdomain config failure commit 8a1f3cf89ddcc700e25afe42cfad333059adcc94 upstream. wlcore_regdomain_config() gets a runtime PM reference before sending the regulatory-domain command. When wlcore_cmd_regdomain_config_locked() fails, the function queues recovery and returns without dropping that reference. Release the reference after handling the command result so both success and failure paths balance the preceding pm_runtime_resume_and_get(). The recovery worker takes a separate runtime PM reference and cannot release the reference held here. Fixes: fa2648a34e73 ("wlcore: Add support for runtime PM") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260820125126.12757-1-runyu.xiao@seu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit c0df0878e9110909cf0bec6080d72d36401a0c89 Author: Fan Wu Date: Thu Sep 10 02:09:07 2026 +0000 wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown commit d9be5e75530772fc31637070d51e5717d6aeaa2a upstream. wcn36xx_dxe_deinit() tears down the TX ack timer with timer_delete(), which only dequeues the timer and does not wait for a callback that is already executing; the preceding free_irq() calls synchronize the interrupt handlers only. The callback, wcn36xx_dxe_tx_timer(), can therefore be running past the teardown and use the wcn freed along with the ieee80211_hw in wcn36xx_remove(): it takes wcn->dxe_lock, reads wcn->tx_ack_skb and passes wcn->hw to ieee80211_tx_status_irqsafe(). Fix this by using timer_shutdown_sync(), which waits for a running callback and also prevents the timer from being rearmed again. The timer is set up again by wcn36xx_dxe_init() on the next start, so the start/stop cycle is unaffected. This issue was found by an in-house static analysis tool. Fixes: fdf21cc37149 ("wcn36xx: Add TX ack support") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20260910020907.3353-1-fanwu01@zju.edu.cn Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 8dab6ee020b2cd951b670626ba44a95cd4deac3d Author: Tianchu Chen Date: Fri Sep 4 14:24:45 2026 +0000 wifi: rsi: fix heap OOB write on key removal commit e6c5ed7a98d7bc8b0f7918246f1c90ddb3f79dfa upstream. When a key is removed (data == NULL), rsi_hal_load_key() runs: memset(&set_key[FRAME_DESC_SZ], 0, frame_len - FRAME_DESC_SZ); set_key is a struct rsi_set_key *, so the subscript is scaled by sizeof(struct rsi_set_key) (160 bytes): &set_key[FRAME_DESC_SZ] is skb->data + 2560, and the memset writes 144 zero bytes starting 2.4KB past the end of the 160-byte skb data buffer, corrupting unrelated heap objects. The intended byte offset would have been (u8 *)set_key + FRAME_DESC_SZ. The write fires on every DISABLE_KEY callback, so plain disconnects, roams and interface teardowns trigger it on real networks. The memset is redundant: the whole buffer is zeroed right after allocation, so the frame sent to the device is byte-identical without it. Drop the else branch; normal operation is unaffected. Discovered by Atuin - Automated Vulnerability Discovery Engine. Fixes: dad0d04fa7ba ("rsi: Add RS9113 wireless driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tianchu Chen Link: https://patch.msgid.link/90bb2b07007942064c04aa3729cedd9eb1e930b1@linux.dev Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit bb7ae8910cc886885aea95abb7c2e578a2341646 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Wed Sep 9 15:11:24 2026 +0900 wifi: libipw: reject TKIP frames without a full MIC commit 06f42accaf3c6aecab1dcc57f68dde6c06c8b380 upstream. libipw_michael_mic_verify() assumes that an skb contains an eight-byte Michael MIC. A short TKIP frame makes the unsigned payload length wrap, causing michael_mic() to read past the skb. Check that the MIC is present before verifying it, and use the existing MICHAEL_MIC_LEN constant for all MIC lengths in the verifier. Fixes: b453872c35cf ("[NET] ieee80211 subsystem") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Link: https://patch.msgid.link/20260909061124.3802517-1-4ncienth@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 04c837d413dc11a91e0275b08b9e35a6c111175e Author: Jiangshan Yi Date: Sat Aug 15 19:57:24 2026 +0800 wifi: libertas_tf: fix UAF in lbtf_free_adapter() commit bbb9a0ab96d44a64529aafc7a16de460a1712f6a upstream. lbtf_free_adapter() calls lbtf_free_cmd_buffer() to free the command buffers before calling timer_delete_sync() to wait for the command timer callback. If the timer callback (command_timer_fn) is already running when lbtf_free_cmd_buffer() frees the command array, the callback dereferences priv->cur_cmd->cmdbuf which points to freed memory. Swap the order so that timer_delete_sync() runs first, ensuring any in-flight callback has completed before the command buffers are freed. Fixes: 06b16ae53192 ("libertas_tf: main.c, data paths and mac80211 handlers") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Link: https://patch.msgid.link/20260815115724.920628-1-yijiangshan@kylinos.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a9176fe666af1730cab92350f9c8cf67ebf14439 Author: Stanislaw Gruszka Date: Thu Aug 20 11:30:59 2026 +0200 wifi: iwlegacy: fix broadcast stations deallocation commit b5526b780f8b297a76030410b96ba29153afb98f upstream. On the error path of __il4965_up(), il_dealloc_bcast_stations() clears only IL_STA_UCODE_ACTIVE, leaving IL_STA_BCAST set. This causes the same broadcast stations to be deallocated again by __il4965_down(). This can occur when RF_KILL is toggled during driver startup. To fix clear the entire 'used' field, since we will not do any other operations on the station. Reported-and-tested-by: Martin-Éric Racine Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221733 Fixes: c2fd34469d16 ("iwl4965: Fix a memory leak in error handling code of __il4965_up") Cc: # 7.1.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check Cc: # 6.x.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check Cc: # 5.x.x: 57aa1718d595 wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check Signed-off-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260820093059.18779-1-stf_xl@wp.pl Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 777cb6bba59e875b16a1d8897a483a5fecfcd5d2 Author: Jiangshan Yi Date: Sat Aug 15 20:10:43 2026 +0800 wifi: brcmsmac: fix UAF in brcms_free_timer() commit 1eeca1d5e0920fbdad6449768fd2d4364e714180 upstream. brcms_free_timer() calls brcms_del_timer() which uses the non-synchronous cancel_delayed_work() to cancel the timer's underlying delayed work. If the work callback (_brcms_timer) is already running, cancel_delayed_work() returns false without waiting, and brcms_free_timer() proceeds to kfree(t) while the callback still accesses t through container_of(). Add an explicit cancel_delayed_work_sync() after brcms_del_timer() to guarantee that any in-flight callback has completed before the timer structure is freed. Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260815121043.938414-1-yijiangshan@kylinos.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit fbc3b55175a113a5c16af885c3c16ae6503c790e Author: Wentao Liang Date: Wed Sep 16 17:07:04 2026 +0000 watchdog: starfive-wdt: Fix runtime PM leak in starfive_wdt_pm_start() commit 8f0ca55016a7647109ae2bc91bcb346fc8b13785 upstream. starfive_wdt_pm_start() takes a runtime PM reference with pm_runtime_get_sync(), which increments the usage counter even when it fails, and returns the error without dropping it again. The watchdog core does not invoke the stop callback when start fails, so the reference taken on the error path is leaked. Use pm_runtime_resume_and_get() instead, which keeps the usage counter balanced when the resume fails. Fixes: db728ea9c7be ("drivers: watchdog: Add StarFive Watchdog driver") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260916170704.2086331-1-vulab@iscas.ac.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit cbd298c2dcd5d9f2fcde0d7bf77235b88c664c2d Author: Wentao Liang Date: Wed Sep 16 17:05:11 2026 +0000 watchdog: sp5100_tco: Fix pci_dev reference leak in sp5100_tco_init() commit 88f113634028ca90a857031837d8061d1a9e1a7b upstream. sp5100_tco_init() stores the PCI device matched by for_each_pci_dev() in the global sp5100_tco_pci and keeps its reference for the lifetime of the driver, but neither sp5100_tco_exit() nor the error paths of sp5100_tco_init() call pci_dev_put(), leaking the reference on driver registration failure and on every module load/unload cycle. Drop the reference when the platform driver or device registration fails and when the module is unloaded. Fixes: 15e28bf13008 ("watchdog: Add support for sp5100 chipset TCO") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260916170511.2086199-1-vulab@iscas.ac.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 0dd78d9d9b546de08e2ae391541f48cea0a9b842 Author: Tzung-Bi Shih Date: Sun Sep 13 14:48:51 2026 +0800 watchdog: rzv2h: Avoid division by zero commit 6274281c41efa8dd1aa5234c59ad904ff89d7af4 upstream. clk_get_rate() could return 0. Avoid a division by zero panic. Fixes: f6febd0a30b6 ("watchdog: Add Watchdog Timer driver for RZ/V2H(P)") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260913064851.8239-4-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 8a12e049d517d7dee78500633f8f0e47262a67e0 Author: Tzung-Bi Shih Date: Sun Sep 13 14:48:50 2026 +0800 watchdog: rtd119x: Avoid division by zero commit 5af7d2cbd20f893def03c8310a460ade66a5d822 upstream. clk_get_rate() could return 0. Avoid a division by zero panic. Fixes: 2bdf6acbfead ("watchdog: Add Realtek RTD1295") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260913064851.8239-3-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 68a7e322a56b6b65e8cfe0f2bbe02f333b18c2dc Author: Tzung-Bi Shih Date: Sun Sep 13 00:33:34 2026 +0800 watchdog: msc313e: Propagate error code in resume() commit 1d9763f34a85680db1e8233d654fdb85e5f897cc upstream. If msc313e_wdt_start() fails during system resume, the error is currently ignored. Consequently, the watchdog isn't running without the user's knowledge. Propagate the error code and print a message if msc313e_wdt_start() fails. Signed-off-by: Tzung-Bi Shih Fixes: e9800b7994642 ("watchdog: Add Mstar MSC313e WDT driver") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260912163334.28636-1-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 57ebb0cb6e6f4ed202411789d06589736b79156c Author: Tzung-Bi Shih Date: Sun Sep 13 14:51:26 2026 +0800 watchdog: msc313e: Fix premature reset during timeout update commit 22737cfced627ffcb4b5c36d63bb3d4476f63213 upstream. Updating the 32-bit hardware timeout requires writing to two 16-bit registers sequentially. If the watchdog is actively running, this non-atomic update might trigger a premature system reset. Clear the watchdog counter before updating the registers to prevent the timer from timing out prematurely against an intermediate threshold. Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260913065126.8350-1-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit fae3b59f4b71f6f876caa6f4e19b052bba5e75a7 Author: Tzung-Bi Shih Date: Sun Sep 13 14:48:49 2026 +0800 watchdog: digicolor: Avoid division by zero commit 400cb663ca019bae6eb878f06f1094ddf7c0b0df upstream. clk_get_rate() could return 0. Avoid a division by zero panic. Since get_timeleft() cannot propagate errors, check the clock rate early in probe() and cache the rate in the driver data as it is unlikely to change at runtime. Fixes: 336694a01dae ("watchdog: digicolor: driver for Conexant Digicolor CX92755 SoC") Cc: stable@vger.kernel.org Signed-off-by: Tzung-Bi Shih Acked-by: Baruch Siach Link: https://patch.msgid.link/20260913064851.8239-2-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 1db134d0d2a51a136296584854570e5e04adedb0 Author: Li Jun Date: Thu Sep 17 09:37:10 2026 +0800 watchdog: da9063: fix suspend/resume handling of HW_RUNNING watchdog commit 7cb575b71ab98194d2e040bded3a7281e089c5ed upstream. da9063_wdt_suspend() and da9063_wdt_resume() only check watchdog_active(), when the watchdog is left running by the driver sets WDOG_HW_RUNNING in da9063_wdt_probe() but userspace never opens the device, so WDOG_ACTIVE remains cleared, the wdt_disable() will not be executed in da9063_wdt_suspend. In this case, the suspend callback is a no-op and the watchdog keeps counting during system suspend, leading to an unexpected system reset. Check WDOG_HW_RUNNING and wdd，can fix this issue. Fixes: a7ceca4398bc8 ("watchdog: da9063: optionally disable watchdog during suspend") Cc: stable@vger.kernel.org Signed-off-by: Li Jun Link: https://patch.msgid.link/20260917013710.2754679-1-lijun01@kylinos.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 89dda34123a7ccf18a8753617948290cd1d1a804 Author: Thomas Richard (congatec GmbH) Date: Fri Sep 11 19:31:59 2026 +0200 hwmon: (cgbc-hwmon) Add missing sensors commit 3550d1dbbcb9f51b77e077e8958423ee2c401c6c upstream. Add the following sensors: - Alternate Board Temperature (temp11_input) - Top DIMM 1-7 Temperature (temp12_input to temp18_input) - Bottom DIMM 1 Temperature (temp19_input) - 12V Standby Voltage (in14_input) This fixes the following warning on conga-SA7: Board Controller returned an unknown sensor (bc_type=1, bc_id=11), ignore it Also update existing labels to match Congatec documentation. Cc: stable@kernel.org Fixes: 08ebc9def79f ("hwmon: Add Congatec Board Controller monitoring driver") Signed-off-by: Thomas Richard (congatec GmbH) Link: https://patch.msgid.link/20260911-cgbc-hwmon-fix-and-new-sensors-v2-2-0c6bf078d173@bootlin.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 1eaf83055f655955d13ed7fb02925a7d831e5b53 Author: Thomas Richard (congatec GmbH) Date: Fri Sep 11 19:31:58 2026 +0200 hwmon: (cgbc-hwmon) Fix current sensors ID lookup commit 7bae83ffb133bc373d098fa6828cef2ef4da49fe upstream. Current sensors on the Congatec Board Controller don't use consecutive IDs, unlike other sensor types (voltage, temperature, fan). The driver assumed consecutive IDs and performed a simple lookup, which caused an unknown sensor warning. Define current sensor IDs explicitly. Changes the warning on conga-SA7 (type and channel are correct now). Before: Board Controller returned an unknown sensor (type=2, channel=17), ignore it After: Board Controller returned an unknown sensor (bc_type=1, bc_id=11), ignore it Cc: stable@kernel.org Fixes: 08ebc9def79f ("hwmon: Add Congatec Board Controller monitoring driver") Signed-off-by: Thomas Richard (congatec GmbH) Link: https://patch.msgid.link/20260911-cgbc-hwmon-fix-and-new-sensors-v2-1-0c6bf078d173@bootlin.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 62f6df2038eda371b1e66ab5c27cd74dc66d5678 Author: Guangshuo Li Date: Mon Sep 14 15:36:38 2026 +0800 hwmon: (w83793) release probe data through kref commit c702a5f18b780e477eccbbab558e590e9673e4cb upstream. w83793_probe() initializes data->kref to manage the lifetime of the driver data. The normal remove path drops the driver-owned reference with kref_put(), while watchdog users take and release additional references through the same kref. However, the probe error path still frees data directly with kfree(). This bypasses the kref-managed lifetime and discards the initial reference without a matching kref_put(), leaving the reference accounting unbalanced. Drop the probe-owned reference with kref_put() instead and let w83793_release_resources() perform the final free, matching the normal remove path. This issue was found by manual code inspection. Fixes: 5852f9609d21 ("hwmon: (w83793) Add watchdog functionality") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260914073638.1662500-1-lgs201920130244@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 583e04e88e75b8d57304015d83c38e82a9531600 Author: Guangshuo Li Date: Mon Sep 14 14:28:09 2026 +0800 hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on remove commit 0ff9c7775e51ac6d47b1bb5c46f06b1434fe58a8 upstream. When the fan/pwm 4-5 pins are not used as GPIO, w83791d_probe() creates the w83791d_group_fanpwm45 sysfs group on the I2C client device. The probe error path removes this group when a later initialization step fails, but the normal remove path only removes w83791d_group. As a result, the optional fan/pwm 4-5 sysfs files can remain after the driver is unbound. The callbacks associated with these files access the driver data, which is devm allocated and released after driver unbind. Leaving the sysfs files behind can therefore result in accesses to stale driver data. Remove w83791d_group_fanpwm45 during normal teardown as well. This issue was found by manual code inspection. Fixes: 6e1ecd9b8f13 ("hwmon: (w83791d) fan 4/5 pins can also be used for gpio") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260914062809.1650538-1-lgs201920130244@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit b48339b0a577783e4590a69e4cd2f2760ce33154 Author: Yibo Tan Date: Fri Sep 11 15:18:09 2026 +0800 hwmon: (pwm-fan) Stop RPM timer before freeing tach data commit 26d5ff79768548efb1e604bb6e8697c101e06269 upstream. sample_timer() rearms the RPM timer and accesses the devm-managed ctx->tachs and ctx->pulses_per_revolution arrays. The cleanup action which stops the timer is registered before those arrays are allocated. Since devres releases entries in reverse order, driver detach can free the arrays before pwm_fan_cleanup() shuts down the timer. A timer expiry in that window accesses the freed tach data. With a KASAN kernel, a test-only kprobe delayed entry to pwm_fan_cleanup() while normal sysfs unbind ran. Each of three runs reported three four-byte reads and two four-byte writes in sample_timer() after its backing devm allocations had been freed. The helper did not invoke the timer callback, cleanup actions or free functions. With the fix, three matching unbind runs completed without KASAN, BUG, WARNING, Oops or panic. Instrumentation confirmed that timer retirement completed before the first timer backing allocation was released. Split timer retirement from the power cleanup and register its devres action after the timer backing data and IRQ actions are installed. This preserves the early power rollback action while ensuring the timer is retired before its backing data is released. Use timer_shutdown_sync() because the callback can rearm itself. Fixes: 01695410d452 ("hwmon: (pwm-fan) Store tach data separately") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Yibo Tan Link: https://patch.msgid.link/20260911071809.130151-1-lhfff@tju.edu.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit b5e6f3477e4de584c00b81aa3286c893d2237f9d Author: Sanman Pradhan Date: Wed Sep 16 23:54:17 2026 +0000 hwmon: (pmbus/tps53679) Select page 0 for single-page TPS53676 commit 089070b51ccbac411462a30a454690274c6e4270 upstream. tps53676_identify() derives the number of PMBus pages but does not ensure that page 0 is selected for single-page configurations. pmbus_set_page() does not update the PAGE register when info->pages is 1, so if boot firmware leaves PAGE set to another value subsequent register accesses may target the wrong page. For single-page devices, select page 0 explicitly. Fixes: cb3d37b59012 ("hwmon: (pmbus/tps53679) Add support for TI TPS53676") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://patch.msgid.link/20260916235406.681131-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 36f9b74bd970c57fd715ec348baea6e4389d7b53 Author: Sanman Pradhan Date: Tue Sep 15 16:48:35 2026 +0000 hwmon: (pmbus/tps53679) Fix TPS53676 phase page decoding commit 1d12fb94ac0975566545871dda100df34df5f845 upstream. tps53676_identify() reads the USER_DATA_03 phase configuration to count the phases assigned to each channel and derive the number of PMBus pages. In each 16-bit phase descriptor the channel (PAGE) is encoded in bit 4 and the firing order in bits 3:0, but the code tested bit 3 (0x08), which is part of the firing-order field. TPS53676 supports up to seven phases, so firing-order bit 3 is never set. As a result the existing test classifies every enabled phase as channel A. On a dual-channel configuration the phases assigned to channel B are therefore miscounted as channel A and page 1 is not exposed. Test the PAGE field (bit 4) instead. Fixes: cb3d37b59012 ("hwmon: (pmbus/tps53679) Add support for TI TPS53676") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan Link: https://patch.msgid.link/20260915164823.160977-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit b49f100a15b8876deccf8c59f41af92b8e25fd74 Author: Nuno Sá Date: Fri Sep 11 14:53:37 2026 +0100 hwmon: (pmbus/core) increase number of phases and add new mask commit 06bd6794b5fd2163880ac3bfe973d4cc61f359f3 upstream. Increase the number of phases to 16 as a new upcoming device supports such a number. While at it, add a new mask for controlling the source of the output voltage. Note (groeck): This patch was meant to prepare for support of MAX20826 and compatible devices, which support more than 10 phases per page. However, Sashiko reports that the mp2975 driver already supports up to 14 phases, and the mp2856 driver supports up to 12 phases. This already has the potential for out-of-bounds writes when probing the affected chips, making this patch a bug fix. Fixes: 2c6fcbb21149 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controller") Fixes: f9e5f289b686 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2856/mp2857 controller") Signed-off-by: Nuno Sá Link: https://patch.msgid.link/20260911-hwmon-max20826-support-v2-1-5e30cbd97d84@analog.com Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 9c1e65bc79ff104914b11e6ad972139296ec86fe Author: Muhammad Bilal Date: Wed Sep 16 05:29:26 2026 +0500 hwmon: (hp-wmi-sensors) Fix use-after-free in fungible_show() commit e6cb0b4d4ecb8e71fd2200d907ab2e9663356f69 upstream. nsensor->current_state is dynamically replaced as the sensor's state changes. update_numeric_sensor_from_wobj() does this by freeing the old string and installing a new one: if (strcmp(trimmed, nsensor->current_state)) { new_string = hp_wmi_strdup(dev, trimmed); if (new_string) { devm_kfree(dev, nsensor->current_state); nsensor->current_state = new_string; } } This function is only ever called from hp_wmi_update_info() while state->lock is held, so the free-and-replace itself is properly serialized against concurrent updates. fungible_show(), however, reads the same pointer after the lock has already been dropped: err = hp_wmi_update_info(state, info); if (err) return err; switch (prop) { ... case HP_WMI_PROPERTY_CURRENT_STATE: seq_printf(seqf, "%s\n", nsensor->current_state); break; hp_wmi_update_info() takes state->lock internally and releases it before returning, so by the time fungible_show() dereferences nsensor->current_state in seq_printf(), no lock is held. Two processes reading a sensor's current_state debugfs entry at overlapping times (or one reading it while another read of the same sensor triggers a refresh) can race: one thread's seq_printf() can be part-way through printing the string at the moment another thread's call into update_numeric_sensor_from_wobj() frees it with devm_kfree() and installs a new pointer, causing a use-after-free read. Take state->lock around the read in fungible_show() as well, so it can never run concurrently with the free-and-replace in update_numeric_sensor_from_wobj(). Fixes: 23902f98f8d4 ("hwmon: add HP WMI Sensors driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Acked-by: James Seo Link: https://patch.msgid.link/20260916002926.161595-1-meatuni001@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit ed0406e490f48ed180df140fe2a81be26bccb1a9 Author: Iván Ezequiel Rodriguez Date: Tue Sep 1 10:06:28 2026 -0300 Input: zero ff_effect before compat copy in input_ff_effect_from_user commit f84819ef8d66931ee3998fee3c4f03230f4cb6cc upstream. In the compat path input_ff_effect_from_user() aliases the caller's native struct ff_effect with the smaller struct ff_effect_compat and copies only the compat sized prefix: compat_effect = (struct ff_effect_compat *)effect; if (copy_from_user(compat_effect, buffer, sizeof(struct ff_effect_compat))) The tail of the native structure is never written. Callers pass an uninitialized on-stack object, for example evdev_do_ioctl() for EVIOCSFF, so those bytes keep their previous stack contents. input_ff_upload() then stores the full native structure in ff->effects[id], from where a uinput based force feedback daemon can read it back via UI_BEGIN_FF_UPLOAD, disclosing kernel stack memory to userspace. Zero the effect before the compat copy. Fixes: 2d56f3a32c0e ("Input: refactor evdev 32bit compat to be shareable with uinput") Cc: stable@vger.kernel.org Signed-off-by: Iván Ezequiel Rodriguez Link: https://patch.msgid.link/20260901130629.24078-3-ivanrwcm25@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 942b06a19252908d0f952c0590caf20e47f88252 Author: Dmitry Torokhov Date: Wed Aug 5 22:44:23 2026 -0700 Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound commit fe10579b6dc3f0dac61e51e1797cacbba5039ac2 upstream. Transport drivers (such as rmi_i2c and rmi_spi) invoke rmi_driver_suspend() and rmi_driver_resume() on their child rmi_dev device during system power management events. However, transport drivers are fully registered and operational even if the physical RMI driver failed to bind or probe the rmi_dev device. When rmi_driver_suspend() or rmi_driver_resume() is called on an unbound rmi_dev, dev_get_drvdata() returns NULL. Calling rmi_disable_irq() or rmi_enable_irq() without driver data attached causes a NULL pointer dereference and General Protection Fault when attempting to lock data->enabled_mutex. Fix this by checking if driver data is attached to rmi_dev in rmi_driver_suspend() and rmi_driver_resume(), exiting early if no driver data is present. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices") Reported-by: syzbot+09103639e39c989e3ed3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=09103639e39c989e3ed3 Cc: stable@vger.kernel.org Assisted-by: LLM Link: https://patch.msgid.link/anQe8UiyUR4x0flD@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 6614868f1a781541527d1af522de7d22a45f30c4 Author: Raphaël Larocque Date: Thu Sep 10 12:44:25 2026 -0400 Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722) commit 26eb3d92c7a4d7adb1ae1740ca6e8e100b11d1ec upstream. The Lenovo ThinkPad T440p (PNP ID LEN0036, board id 2722) has a Synaptics touchpad whose SMBus companion is not ready at boot and takes roughly 200 seconds to appear. During this window the touchpad and TrackPoint are completely unresponsive on approximately 50% of boots, making the machine unusable until the companion finally registers. The device is in the topbuttonpad_pnp_ids[] SMBus allowlist, so the kernel attempts to use SMBus/RMI4 mode by default. When the companion is not ready, psmouse_smbus_init() leaves breadcrumbs and returns -EAGAIN, the PS/2 fallback path is taken, but the device does not function properly until the companion appears and RMI4 takes over. Disable SMBus InterTouch for board id 2722 so the touchpad and TrackPoint work immediately via PS/2 from boot. Users can still force SMBus with psmouse.synaptics_intertouch=1 if needed. Tested-by: Raphaël Larocque Signed-off-by: Raphaël Larocque Link: https://patch.msgid.link/20260910164425.12832-1-rlarocque@disroot.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 12d80e6351556cfecbdd09416e5e4c73d6ca08ba Author: Hans de Goede Date: Wed Sep 9 11:39:34 2026 +0200 Input: soc_button_array - check btns_desc->package.count commit fb5022278b6ea7f1838e3ef78028d5d5e3375f65 upstream. Check that btns_desc->package.count is not 0 before accessing btns_desc->package.elements[0]. Fixes: 4c3362f44980 ("Input: soc_button_array - add support for ACPI 6.0 Generic Button Device") Cc: stable@vger.kernel.org Reported-by: Shashiko Closes: https://lore.kernel.org/linux-input/20260909091440.3384C1F00A3A@smtp.kernel.org/ Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20260909093934.29411-2-johannes.goede@oss.qualcomm.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 74607b440aa3a67b7f47399558a5bcbe088667a8 Author: Hans de Goede Date: Wed Sep 9 11:39:33 2026 +0200 Input: soc_button_array - fix MS Surface Pro 11 probe failure commit ed22ad5fdbdbf9b4cb4ad3003f60314b5a5eb89d upstream. On the MS Surface Pro 11 soc_button_array probing races with the GPIO driver probing. If soc_button_array wins the race then gpiod_get() returns EPROBE_DEFER, which should normally take care of retrying later, but the soc_button_array code deliberately ignores EPROBE_DEFER causing it to fail its probe() which causes the volume and power buttons to now work. The ignoring of EPROBE_DEFER is there to deal with a problem specific to older Bay Trail (BYT) and Cherry Trail (CHT) tablets which often use this driver. Modify the error handling to only ignore EPROBE_DEFER on BYT and CHT platforms and propagate EPROBE_DEFER normally on other platforms. Fixes: bcf059578980 ("Input: soc_button_array - partial revert of support for newer surface devices") Cc: stable@vger.kernel.org Reported-by: Sergey Lebedev Closes: https://lore.kernel.org/lkml/20260830141355.55898-1-lsa.uz@pm.me/ Signed-off-by: Hans de Goede Tested-by: Sergey Lebedev Link: https://patch.msgid.link/20260909093934.29411-1-johannes.goede@oss.qualcomm.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 9f0ce5e162eed8b68345abe839c59768bc60f99a Author: Dmitry Torokhov Date: Tue Aug 4 22:08:54 2026 -0700 Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block() commit 51cfe54f815ae175c7d1126b983d4d7c89715004 upstream. When chunking writes into SMBus blocks in rmi_smb_write_block(), the loop calculates block_len using the original total length (len) instead of the remaining length (cur_len). If len is greater than 32 bytes (SMB_MAX_COUNT), block_len remains 32 for every iteration, even on the final partial chunk where fewer than 32 bytes remain. This causes smb_block_write() to read 32 bytes from the advanced data buffer pointer, reading past the end of the input buffer. Fix this by calculating block_len using cur_len and advancing the buffer and address pointers by block_len. Fixes: 82264d0cf7ae ("Input: synaptics-rmi4 - add SMBus support") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Assisted-by: LLM Link: https://patch.msgid.link/anLFSMKSoKyyZ272@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit e098a019e9940d851e196ea2531b4e861fa83c7a Author: Chris Sommers Date: Mon Sep 7 11:27:23 2026 -0700 Input: i8042 - add quirk for Acer Aspire Go 15 AG15-42P commit 25e424eb4ae1a662d9c3573218d06ac32f797fc5 upstream. On the Acer Aspire Go 15 (AG15-42P), the internal keyboard drops out ~5 seconds after boot on both Linux and Linux-LTS kernels. Keystrokes on the built-in keyboard stop registering while the trackpad and external keyboards remain functional. Testing confirms that booting with the i8042.reset kernel parameter resolves the issue and keeps the internal keyboard responsive. Add SERIO_QUIRK_RESET_ALWAYS to i8042_dmi_quirk_table for the Acer Aspire AG15-42P to automatically apply this quirk on boot. Signed-off-by: Chris Sommers Link: https://patch.msgid.link/20260907182723.2709981-1-chris.sommers@icloud.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d012dc31f91190a9a8e8f873d2b095c0fa25fbcb Author: Runyu Xiao Date: Wed Sep 2 23:40:04 2026 +0800 Input: hp_sdc - shut down kicker timer on module exit commit 309731e95917125bbd13626a7a5600490a5bf44f upstream. hp_sdc_kicker() rearms hp_sdc.kicker with mod_timer() after scheduling the tasklet. The module exit path uses timer_delete_sync(). That waits for a callback already running but can still leave the timer rearmed. A callback can therefore leave the timer pending while hp_sdc_exit() tears down the driver, allowing timer activity to access dismantled driver state. Use timer_shutdown_sync() for final teardown. It waits for a running callback and prevents rearming after module exit begins. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Acked-by: Helge Deller Link: https://patch.msgid.link/20260902154004.3595416-1-runyu.xiao@seu.edu.cn Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3dfe48d5307a1ba22c58231d04257737015569ca Author: Iván Ezequiel Rodriguez Date: Tue Sep 1 10:06:27 2026 -0300 Input: evdev - zero absinfo before partial copy in EVIOCSABS commit 8b852965b8eaf910c314dc346967ed82c8d4f235 upstream. The EVIOCSABS handler copies at most the user supplied ioctl size into an uninitialized on-stack struct input_absinfo: if (copy_from_user(&abs, p, min_t(size_t, size, sizeof(struct input_absinfo)))) The size comes from _IOC_SIZE() of the ioctl command and is therefore fully controlled by userspace. A short size leaves the trailing part of the structure holding whatever was on the kernel stack, and the whole structure is then stored into the device: dev->absinfo[t] = abs; EVIOCGABS hands that back to userspace, disclosing the stale stack bytes. Only the resolution field is currently cleared, which covers the legacy struct layout but not an arbitrarily short size. Zero the structure before the copy so any part not supplied by the caller reads back as zero. The existing resolution fixup is kept, since it also handles a size that partially overlaps that field. Fixes: 448cd1664a57 ("Input: evdev - rearrange ioctl handling") Cc: stable@vger.kernel.org Signed-off-by: Iván Ezequiel Rodriguez Link: https://patch.msgid.link/20260901130629.24078-2-ivanrwcm25@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 495955feb57750de4a641da13d7e51fb4d0a9764 Author: Linkai Gong Date: Tue Sep 1 20:26:49 2026 +0800 Input: cyttsp5 - clamp the HID report size before memcpy commit 85f080fb87ed5cd3e46121be677f52c82f26a0ab upstream. The size field comes from the device and is used as the memcpy() length into response_buf, which is CY_MAX_INPUT bytes. Fixes: 5b0c03e24a06 ("Input: Add driver for Cypress Generation 5 touchscreen") Signed-off-by: Linkai Gong Link: https://patch.msgid.link/20260901122649.1173066-1-gonglinkai@kylinos.cn Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f9be4db0281bbb476f9f8b34ea4aa6119c5a563a Author: Alexei Turtanov <9alexei9@gmail.com> Date: Fri Aug 28 14:22:39 2026 +0300 Input: atkbd - skip deactivate for Xiaomi Redmi Book Pro 16 2026 commit aefbda23eeba234c3ff0f135dc5be6e294bd25a6 upstream. The internal keyboard of the Xiaomi Redmi Book Pro 16 2026 (board TM2425) does not work: atkbd_probe() succeeds and every command is ACKed, but no scancodes ever arrive afterwards. Testing on the hardware through serio_raw shows that ATKBD_CMD_RESET_DIS (0xF5) is the culprit. After 0xF5 the embedded controller keeps ACKing commands but stops delivering scancodes, and neither ATKBD_CMD_ENABLE (0xF4) nor ATKBD_CMD_RESET_BAT (0xFF) bring them back. Only re-enabling the keyboard interface at the controller level (i8042 command 0xAE, or rewriting the command byte as i8042_port_close() does) revives it. Running the init sequence without 0xF5 (0xED 0x00, 0xF3 0x00, 0xF4) keeps the keyboard working. 'i8042.dumbkbd=1' also works around this, but then the driver never writes to the keyboard and the LEDs cannot be controlled. Use the existing atkbd_deactivate_fixup quirk instead, as done for the sibling TM2424 by commit 3a046db33bb9 ("Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal keyboard"). Tested on v7.2: keyboard, Caps Lock LED and s2idle suspend/resume all work. DMI: XIAOMI REDMI Book Pro 16 2026/TM2425, BIOS RMAPT6B0P0909 05/22/2026 Fixes: 9cf6e24c9fbf ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Cc: stable@vger.kernel.org Signed-off-by: Alexei Turtanov <9alexei9@gmail.com> Link: https://patch.msgid.link/20260828112239.18081-1-9alexei9@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ccd6b7003cd5c549e0fc1d0d4a7f520207ced241 Author: Alvin Šipraga Date: Tue Aug 18 18:00:02 2026 +0200 Input: adp5588-keys - cache GPIO state before registering the gpiochip commit 21efadc62272cabee9bec27777ae75d84a9ca8a8 upstream. So as not to clobber any pre-programmed GPIO state in the execution of its gpiochip ops, the driver caches things during probe time. However, since those ops can be called both during and immediately after the call to devm_gpiochip_add_data(), it is imperative that things are cached before that. That's not the case right now, so reorder the two steps to prevent any clobbering. In the concrete example which motivated this change, a bootloader was preconfiguring an important GPIO output to HIGH before booting the kernel. Linux would then inadvertently set that output to LOW while configuring a GPIO hog on a discrete GPIO line within the same 8-bit bank (because the cached value was 0=LOW). Fixes: ba9f507a1bea ("Input: adp5588-keys - export unused GPIO pins") Signed-off-by: Alvin Šipraga Reviewed-by: Nuno Sá Link: https://patch.msgid.link/20260818-adp5588-gpio-cache-v1-1-650a2674fc0d@analog.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit be402133d11190c0f366fed9dde49344153cdcbf Author: Diogo Ivo (Schneider Electric) Date: Fri Aug 7 13:07:00 2026 +0200 mmc: sdhci_am654: Fallback to DT-provided itap delay on DDR50 tuning failure commit 308d05225281d86150d88141990d6caf8c902349 upstream. DDR50 mode is not required to support the tuning command CMD19, meaning that calibration may fail on cards that do not implement it, in which case a known-good itap delay value should be programmed into the host controller. Do this by reading the (already defined) itap delay DT property for DDR50 and, if tuning fails for this mode, fall back to the DT-provided itap delay value. If the DT does not provide a value for DDR50 fallback then this simply disables using itapdly. Fixes: 901d16e46296 ("mmc: sdhci_am654: Add retry tuning") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo (Schneider Electric) Acked-by: Adrian Hunter Reviewed-by: Judith Mendez Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 3aaeacf8e995d260bd1a44ea3522b23cdbab8b05 Author: Diogo Ivo (Schneider Electric) Date: Fri Aug 7 13:06:59 2026 +0200 mmc: sdhci_am654: Clear ITAPDLY on tuning failure commit c9f47cc8c37f7659897142ffe216c250fbc1d4ed upstream. When tuning fails, stale ITAPDLY values can persist and interfere with subsequent I/O accesses, for example in DDR50 mode in cards with no tuning support. Move the ITAPDLY enable setting out of the tuning loop to after successful tuning, and explicitly clear ITAPDLY (delay and enable) when tuning fails so that we are sure only working values are actually left in hardware. Fixes: 901d16e46296 ("mmc: sdhci_am654: Add retry tuning") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo (Schneider Electric) Reviewed-by: Judith Mendez Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4e5d765f4582f5f530af0e444a91126f4c817192 Author: Diogo Ivo (Schneider Electric) Date: Fri Aug 7 13:06:58 2026 +0200 mmc: sdhci_am654: Reset command and data lines on failed tuning commit 7197d9107d9545730153b82ea5a411c5208b443f upstream. The CMD/DATA reset after tuning should be performed regardless of whether tuning succeeded or failed, since tuning data may remain in the buffer in either case. Move the error return after the reset so that the controller is always cleaned up. Fixes: de31f6ab68a3 ("mmc: sdhci_am654: Reset Command and Data line after tuning") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo (Schneider Electric) Reviewed-by: Judith Mendez Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d62d03755724b2be9f46920b63d65a42daa5a8cd Author: Diogo Ivo (Schneider Electric) Date: Fri Aug 7 13:06:57 2026 +0200 mmc: sdhci_am654: Move tuning_loop to local variable commit ff894dced1a7ad7523f9c65dbdb53d02474cca0f upstream. The tuning_loop field in struct sdhci_am654_data is only used within sdhci_am654_platform_execute_tuning() as a loop counter that is initialized to 0 in sdhci_am654_init(). Since it shouldn't persist across function calls, otherwise every failure expends its "budget", move it to a local variable and remove the struct field along with the now-unnecessary initialization. Signed-off-by: Diogo Ivo (Schneider Electric) Reviewed-by: Judith Mendez Acked-by: Adrian Hunter Fixes: de31f6ab68a3 ("mmc: sdhci_am654: Reset Command and Data line after tuning") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 3ae80c1fb7de4d3331427a955a44807745ac5a33 Author: Xu Rao Date: Tue Aug 18 19:31:53 2026 +0800 mmc: spi: reset bytes_xfered before retrying CRC failures commit 8b0cc8707f65e0f51912e764e1b309b2559db1ec upstream. mmc_spi_data_do() updates data->bytes_xfered after each block has been transferred successfully. If a later block in the same data request fails with a CRC error, data->bytes_xfered may therefore contain the number of bytes completed before the failing block. mmc_spi_request() has a private recovery path for such CRC failures. It sends STOP_TRANSMISSION, clears data->error and jumps back to crc_recover to issue the same command and data request again. However, it does not clear data->bytes_xfered before the retry. If the retry succeeds, the request is completed with the bytes from the failed attempt still included in data->bytes_xfered. For a multi-block request this can make the completed request report more bytes than were transferred by the successful retry, and can even exceed the request size when most blocks completed before the CRC error. This is most likely to be observed on MMC-over-SPI systems where long multi-block transfers occasionally hit a data CRC error but the mmc_spi-internal retry succeeds. The data itself is retried, but the completion accounting is not. Clear data->bytes_xfered together with data->error before repeating the request so the final completion reports only the bytes transferred by the successful attempt. Fixes: 061c6c847eeb ("mmc_spi: Recover from CRC errors for r/w operation over SPI.") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 22f2d28a92ee9e2aeb58489a1abea1211f7d3d6b Author: Runyu Xiao Date: Wed Sep 2 22:09:26 2026 +0800 mmc: sh_mmcif: initialize IRQ-thread mutex before requesting interrupt commit d5ea0d226e8f0801d78702142a124d78c317d822 upstream. The threaded IRQ handler can run before devm_request_threaded_irq() returns, but thread_lock was initialized afterwards. Initialize it before requesting either interrupt. Fixes: 8047310ee984 ("mmc: sh_mmcif: fix a race, causing an Oops on SMP") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 5e142adbbdc54afbd01fad476c91cded41d22594 Author: Felix Gu Date: Sat Aug 22 02:58:47 2026 +0800 mmc: sdio_uart: fix xmit_fifo leak when the port table is full commit 53823e25793a97d07e6e98e0904bbf74cac8bc76 upstream. sdio_uart_add_port() allocates the transmit fifo before claiming a slot in sdio_uart_table[]. When all UART_NR slots are taken, it returns -EBUSY with the fifo still allocated, but the probe error path only kfree()s the port, leaking the transmit fifo. Free the fifo in the failure path of sdio_uart_add_port() itself so the function retains nothing on error. Fixes: 8b197a5ce7a7 ("sdio_uart: Use kfifo instead of the messy circ stuff") Signed-off-by: Felix Gu Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 356b4b3b28a8ecd2a6c66d3b9666686315337df1 Author: Myeonghun Pak Date: Sun Sep 13 18:35:38 2026 -0400 mmc: sdhci-of-aspeed: Remove children before releasing SDC resources commit 4396d70bb7fec531bcf934fed016b2f3300c670b upstream. Probe failure and removal leave SDHCI child devices registered after the parent clock and managed resources are released. Unregister the OF children in reverse order before disabling the parent clock on both paths. Use of_platform_device_destroy() because manual child creation does not set the flag required by of_platform_depopulate(). This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: bb7b8ec62dfb ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Assisted-by: OpenAI:GPT-5.6 Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4f2867a29d60ddf6d0ee2272300702df68255612 Author: Florian Maillard Date: Mon Aug 24 08:57:55 2026 +0200 mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260 commit 9c182bc5d7817437a7d04ab96133f9191846d93d upstream. The Realtek RTS522A card reader in the Lenovo ThinkPad X260 (subsystem 17aa:504a) incorrectly reports inserted SD cards as write-protected. This causes the MMC core to expose the card as read-only: mmcblk0: mmc0:aaaa SN256 238 GiB (ro) and /sys/block/mmcblk0/ro reports 1. Setting MMC_CAP2_NO_WRITE_PROTECT makes the card writable again. Limit the quirk to the affected Lenovo subsystem. Assisted-by: ChatGPT:GPT-5.6 Sol Signed-off-by: Florian Maillard Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e2948c4232209e87c861a680f20f1e3cf8a57fec Author: Fan Wu Date: Fri Aug 7 03:26:54 2026 +0000 mmc: mxcmmc: cancel data work and watchdog on remove commit d3a421c82412344022982d5b91ba23194a0a6f29 upstream. mxcmci_remove() frees the host through the devm tail, but neither it nor mmc_remove_host() drains the driver's own asynchronous state. host->watchdog, a 10 s timer armed on the DMA path in mxcmci_setup_data(), is deleted only by the DMA- and IRQ-complete paths, which the remove path does not explicitly drain; it can therefore fire after the host is freed and dereference it in mxcmci_watchdog(). host->datawork, armed from the IRQ handler on the PIO path, is not cancelled by the remove path either. Free the devm-registered IRQ, then cancel datawork and delete the watchdog in mxcmci_remove(), before dma_release_channel(). Freeing the IRQ first keeps a trailing handler from re-arming datawork between the cancel and the host free. Both callbacks are non-self-rearming. This issue was found by an in-house static analysis tool. Fixes: f6ad0a481342 ("mmc: mxcmmc: fix bug that may block a data transfer forever") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 432b98c1f5daecf04a33c8e1688d26e7ac221e23 Author: Fan Wu Date: Fri Aug 14 08:25:50 2026 +0000 mmc: mmci: Fix use-after-free in busy-timeout work commit 2b19cf3e50cddaff07b657dae1a8f30f06032852 upstream. ux500_busy_complete() can queue ux500_busy_timeout_work for an R1b command, but mmci_remove() never cancels it. The work can subsequently dereference the devm-allocated mmci_host after it has been released. Mask the controller interrupts and disable the delayed work during removal. This drains any queued instance and stops an IRQ handler that is still in progress from queueing the work again once it has been disabled. This issue was found by an in-house static analysis tool. Fixes: b1a665932dc2 ("mmc: mmci: Add support for SW busy-end timeouts") Cc: stable@vger.kernel.org # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Linus Walleij Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 45341b341642c377192c95e4d48e0a859cf85f42 Author: Fan Wu Date: Fri Aug 14 08:23:54 2026 +0000 mmc: hsq: Fix use-after-free in retry work commit 5d132990475f02cfa1debe03d50b479432864ebd upstream. mmc_hsq_pump_requests() queues retry_work when request_atomic() returns -EBUSY; today sdhci-sprd is the only consumer that implements request_atomic(). The work is embedded in a devm-allocated mmc_hsq, but is never cancelled during driver removal. Work still pending at unbind can therefore run after the devm allocation has been released and dereference hsq->mmc and hsq->mrq. Use devm_work_autocancel() to cancel and drain retry_work before the devm allocation is released. By the time devres cleanup begins, mmc_remove_host() has already stopped the host, so no new requests can arm the work. This issue was found by an in-house static analysis tool. Fixes: 6db96e5810e0 ("mmc: host: Introduce the request_atomic() for the host") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit dac0895c20624c201993dd797383adf3eb1cad9a Author: Zhu Ling Date: Fri Sep 4 17:07:46 2026 +0800 mmc: core: Fix OF node reference leak on card add failure commit 08b54e16d547d5c1aa61bf7a3595bb1620975eeb upstream. mmc_of_find_child_device() returns a device node with its reference count incremented. mmc_add_card() stores the reference before calling device_add(), while the card is marked present only after device_add() succeeds. If device_add() fails, the callers release the card through mmc_remove_card(). However, mmc_remove_card() only drops the OF node reference for a present card, leaking the reference on this error path. Move of_node_put() outside the present-card conditional so the reference is released for both registered cards and card-add failures. Fixes: 25185f3f31c9 ("mmc: Add SDIO function devicetree subnode parsing") Cc: stable@vger.kernel.org Signed-off-by: Zhu Ling Reviewed-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2a863458828ade0671c2bc2e469bbd7f2340eb03 Author: Fan Wu Date: Thu Aug 6 13:02:33 2026 +0000 mmc: core: Cancel SDIO IRQ work before freeing host commit 6feadbecdae60a6324c967f3b1493741083793a3 upstream. A host controller that uses sdio_signal_irq() schedules host->sdio_irq_work from its interrupt handler. That work is only cancelled on the suspend path (mmc_sdio_suspend()), not on the remove/free path, so a worker armed just before the controller freed its IRQ can run after mmc_host_classdev_release() has freed the host and dereference it through container_of(). Cancel host->sdio_irq_work in mmc_free_host(), like the existing host->detect drain added by commit 1036f69e2513 ("mmc: core: Cancel delayed work before releasing host"). This issue was found by an in-house static analysis tool. Fixes: 682696605c70 ("mmc: sdio: Add API to manage SDIO IRQs from a workqueue") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit efe21a5c5bfe23bd30a8e4ba4e2b04ae265348bb Author: Bartosz Golaszewski Date: Wed Sep 9 14:37:09 2026 +0200 power: sequencing: fix NULL-pointer dereference in pwrseq_device_register() commit 242da4318d97380741516b595af3920207b2f0f1 upstream. If dev_set_name() fails in pwrseq_device_register(), we jump to the err_put_pwrseq label before initializing pwrseq->targets. pwrseq_release() will try to iterate over targets unconditionally and subsequently dereference an invalid pointer. Move the call to dev_set_name() after the list head is initialized. Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Cc: stable@vger.kernel.org Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260903-pwrseq-kunit-v1-0-1f893d2cabc2%40oss.qualcomm.com?part=2 Link: https://patch.msgid.link/20260909-pwrseq-kunit-v2-3-ef496afc89d2@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 6e571aea60de7f4c62b77510495d1bcc7df406a1 Author: Bartosz Golaszewski Date: Wed Sep 9 14:37:08 2026 +0200 power: sequencing: fix NULL-pointer dereference in pwrseq_unit_new() commit 115b303e8e093d964089ec6f3c40d984d77b33d0 upstream. If memory allocation fails in pwrseq_unit_setup_deps(), pwrseq_unit_put() is called to release the partially initialized unit. However, we've never initialized unit->list and pwrseq_unit_release() will unconditionally call list_del() on it. Initialize unit->list right after allocating the unit struct. Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Cc: stable@vger.kernel.org Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260903-pwrseq-kunit-v1-0-1f893d2cabc2%40oss.qualcomm.com?part=1 Link: https://patch.msgid.link/20260909-pwrseq-kunit-v2-2-ef496afc89d2@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit ffa52ec238ea1b3b4b382186fc7cbdff5c0cf022 Author: Bartosz Golaszewski Date: Wed Sep 9 14:37:07 2026 +0200 power: sequencing: don't call .post_enable() if pwrseq_unit_enable() failed commit 5f90f85eae4e9d2e9628b2019870994ba830b533 upstream. If the call to pwrseq_unit_enable() failed in pwrseq_enable(), bail out instead of calling target->post_enable() which assumes the target was successfully enabled. Fixes: 249ebf3f65f8 ("power: sequencing: implement the pwrseq core") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260909-pwrseq-kunit-v2-1-ef496afc89d2@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 835133337c2ce200db56f62d018c79087dee2603 Author: Christian Göttsche Date: Thu Sep 3 13:43:38 2026 +0200 selinux: always fill AVC decision in avc_has_perm_noaudit() commit 8861db305103107199b1426f25fde1fb6d465583 upstream. avc_has_perm_noaudit() is documented to return a copy of the access decision in @avd, but its early return for an empty requested permission set leaves the buffer untouched. All callers pass an uninitialized stack variable and afterwards feed it to avc_audit(), and the inode hook even stores it in the per-task decision cache. Fill in a deny-all, audit-all decision, similar to avd_init(), so every caller receives a defined value at no cost on the hot path. Cc: stable@vger.kernel.org Fixes: e6f2f381e4015386 ("selinux: replace BUG_ONs with WARN_ONs in avc.c") Signed-off-by: Christian Göttsche Reviewed-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit c2bbb905af2293549651b614a52ad91e0b462b60 Author: Karl Mehltretter Date: Sat Aug 29 23:32:56 2026 +0200 selinux: recheck intermediate backing files on mprotect() commit 78fc54b934bfb2c18aad8154c7302067146946f9 upstream. mprotect() can be used to bypass the SELinux checks that mmap() performs against the intermediate layers of a stacked filesystem. mmap() checks every backing layer as the request descends through the stack. mprotect() only has the lowest backing file in vma->vm_file, so it rechecks the top-level user and the lowest mounter, but skips the mounters of every layer in between. With two nested overlayfs mounts and a policy denying mounter_t -> middle_file_t:file { execute }, a direct mmap(PROT_EXEC) is denied: avc: denied { execute } for pid=71 comm="nested_exec" path="/payload" dev="overlay" ino=9 scontext=user_u:base_r:mounter_t tcontext=user_u:object_r:middle_file_t tclass=file permissive=0 while mmap(PROT_NONE) followed by mprotect(PROT_EXEC) succeeds. Preserve each intermediate path, mounter SID and file-description SID in the backing-file security blob, copying the saved entries when another backing layer is opened. Allocate the array only for nested backing files, and release it and the path references in the backing_file_free hook. During mprotect(), recheck fd { use } and the requested inode permissions for every saved mounter, and include the intermediate layers in the execmod checks. Policy for nested stacking may then need to grant intermediate mounters what a direct mmap() already requires, and execmod on intermediate labels for binaries using text relocations. Tested on arm64 QEMU with a small BusyBox initramfs and a purpose-built SELinux policy, on a mainline tree containing commit f2381b546e7e ("fs: fix user path of nested backing files"). Cc: stable@vger.kernel.org Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Stephen Smalley [PM: subject tweak] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit ff20d16b2e8230c034e21540043df47222dcc09b Author: Karl Mehltretter Date: Sat Aug 29 23:32:55 2026 +0200 selinux: preserve user SID across nested backing files commit 8c0c602202b9a4909b00bc3354e3c0355bc69e65 upstream. SELinux saves the user file SID in a backing-file security blob so it remains available after mmap() replaces vma->vm_file with a backing file. For nested backing files (overlayfs over overlayfs, or FUSE passthrough backed by overlayfs), user_file may itself be a backing file. Its fsec->sid is the SID of the mounter that opened it, rather than the user that opened the top-level file. mprotect() then checks fd { use } against the mounter SID. This can incorrectly deny access without a domain transition, or check the wrong target SID after one. Copy the saved user SID when user_file is a backing file. Keep using the regular file SID for the first backing layer. With two nested overlayfs mounts and SELinux enforcing, mprotect(PROT_READ) returns EACCES with an fd { use } denial against the mounter SID. With this change, mprotect() succeeds. Tested on arm64 QEMU with a small BusyBox initramfs and a purpose-built SELinux policy. The original test was also repeated with Fedora Cloud Base 44 userspace and gave the same result. Cc: stable@vger.kernel.org Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Amir Goldstein Reviewed-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit bafeac9ce5d1ce5256bcf7e5702e831e9aaf419b Author: Shuhei Takeshita Date: Sun Aug 9 12:27:43 2026 +0900 IB/hfi1: Fix the PIO_CRED credit-return mmap commit 62f0f34fbd2b2d5653d33d3b9d42fdcabb1c0101 upstream. hfi1_file_mmap()'s PIO_CRED case must hand user space the single credit-return page that holds this context's entry. That page is the second or third page of the per-node credit-return allocation once the hardware send context index reaches 64 or 128, so the failure below is intermittent: when the entry lands on the first page the offset is zero and everything works. Two things are wrong. First, cr_page_offset is a byte offset but .va is a struct credit_return *, so adding it is pointer arithmetic and scales the offset by sizeof(struct credit_return) == 64. memvirt then lands 256 KiB or 512 KiB past a 10240-byte allocation. With an IOMMU translating, that address is inside the vmalloc range but in no vm_area, so dma_mmap_coherent() -> iommu_dma_mmap() finds no pages, vmalloc_to_pfn() returns page_to_pfn(NULL), and remap_pfn_range() installs a frame above MAXPHYADDR. The first user read then takes: psm2_ep_open_pr: Corrupted page table at address 7a14d007e000 PGD 800000013886a067 P4D 800000013886a067 PUD 13886b067 PMD 13886c067 PTE 800049168e911235 Oops: Bad pagetable: 000d [#1] SMP PTI Second, and still wrong once the arithmetic is corrected, dma_mmap_coherent() describes a whole coherent buffer and selects the page within it with vma->vm_pgoff. Offsetting cpu_addr has no effect: for a vmap'd allocation iommu_dma_mmap() uses cpu_addr only to locate the vm_area and then maps pages[vm_pgoff], which hfi1_file_mmap() has just set to 0. User space therefore always receives the first credit-return page, every credit read is for the wrong context, and send PIO stalls forever. Use the DMA API as intended: pass the base of the allocation with its full length and select the page with vm_pgoff. A separate length is needed because memlen must keep describing the VMA for the existing size check. The dma-direct path stays correct as well, since dma_direct_mmap() adds the same vm_pgoff to the base pfn. Tested on a Dell T7610 (Xeon E5-2650 v2, Intel IOMMU in DMA-FQ mode) against a Threadripper PRO 3995WX peer, both Omni-Path 100. Before this change psm2_ep_open() Oopses the kernel; with only the arithmetic corrected psm2_ep_open() succeeds but any transfer that uses send PIO hangs, PSM2_SDMA=2 (send PIO disabled) completing normally while PSM2_SDMA=0 (send PIO only) hangs every time. With this change send PIO, send DMA and the default mixed mode all work. Fixes: 1ec82317a1da ("IB/hfi1: Use dma_mmap_coherent for matching buffers") Cc: stable@vger.kernel.org Signed-off-by: Shuhei Takeshita Link: https://patch.msgid.link/20260809032743.2671579-3-jyohuku.alterego@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit dab8b64fbd9a4c74512589a9d4ef48460fbf1d3a Author: Shuhei Takeshita Date: Sun Aug 9 12:27:42 2026 +0900 IB/hfi1: Resolve the credit-return buffer through the send context's node commit 975396b9e5a4028e649f4b9a6a5ca5dfb76a824b upstream. hfi1_file_mmap()'s PIO_CRED case derives this context's credit-return page offset, and the DMA handle for it, from dd->cr_base[uctxt->numa_id]. uctxt->numa_id is the node of whichever CPU the process happened to be running on, but the entry itself lives in the credit-return allocation of the send context's own node: sc->hw_free = &sc->dd->cr_base[sc->node].va[gc].cr[index]; and user send contexts are allocated with sc_alloc(dd, SC_USER, ..., dd->node), the HFI-local node. On a multi-socket host with the process running off that node the two allocations differ, so the subtraction produces an offset into an unrelated buffer and the DMA handle belongs to the wrong allocation. Use the send context's own node for all three references. The continuation lines are reindented at the same time; they mixed spaces and tabs. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Cc: stable@vger.kernel.org Signed-off-by: Shuhei Takeshita Link: https://patch.msgid.link/20260809032743.2671579-2-jyohuku.alterego@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit ced1186fea7c77e16681c7ef4802897885989c3b Author: Shuangpeng Bai Date: Sun Aug 16 00:45:10 2026 -0400 IB/mlx4: Fix use-after-free on pkey sysfs registration failure commit 1af874e9f4ce22ccf8b10ab5462f32c70d3be21a upstream. register_pkey_tree() ignores errors from register_one_pkey_tree() and continues registering the remaining slaves. The per-slave error path has already released the pkey parent kobjects, but their pointers remain stored in the device. A later device cleanup therefore passes the stale pointers to kobject_put(), causing a use-after-free. Clear the parent pointers after releasing a failed slave tree and skip unregistered trees during device cleanup. This preserves the existing best-effort registration behavior while preventing a second cleanup of the failed tree. Fixes: c1e7e466120b ("IB/mlx4: Add iov directory in sysfs under the ib device") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai Link: https://patch.msgid.link/20260816044510.3848996-1-shuangpeng.kernel@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 657ef16c6a3d2cbbfaa3cb96f1ccd1570cac9b85 Author: Guangshuo Li Date: Mon Sep 14 17:15:44 2026 +0800 i2c: imx: disable autosuspend on remove commit e0c3e9d76adbe522dd420a766ce42d03ce887c29 upstream. i2c_imx_probe() enables runtime PM autosuspend with pm_runtime_use_autosuspend(). The probe error path correctly undoes this setting with pm_runtime_dont_use_autosuspend(), but the normal remove path only disables runtime PM. The runtime PM API requires pm_runtime_use_autosuspend() to be undone with pm_runtime_dont_use_autosuspend() at driver exit unless runtime PM was enabled with devm_pm_runtime_enable(). Leaving the autosuspend flag set therefore leaves the runtime PM state incompletely cleaned up after the driver is unbound. Add the missing pm_runtime_dont_use_autosuspend() call to the remove path. This issue was found by manual code inspection. Fixes: 588eb93ea49f ("i2c: imx: add runtime pm support to improve the performance") Signed-off-by: Guangshuo Li Cc: # v4.5+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260914091544.1667137-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman commit f1cc745295bc1f8c46fda185e708934c6c65a383 Author: Shengzhuo Wei Date: Thu Aug 27 23:43:02 2026 +0800 i2c: imx: release DMA channels on probe error commit e9f03b9625e2eeaca357b065c92d5b14064a1583 upstream. i2c_imx_dma_request() acquires exclusive tx/rx DMA channels and is optional: on errors other than -EPROBE_DEFER the driver falls back to PIO mode and probe continues. If i2c_add_numbered_adapter() then fails, probe returns through clk_notifier_unregister without releasing the channels, because the remove callback is not invoked after a failed probe. Release the channels on the probe error path, mirroring i2c_imx_remove(). Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver") Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Cc: # v3.19+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260827-i2c-dma-channel-leak-v1-2-271d4adc03a0@cherr.cc Signed-off-by: Greg Kroah-Hartman commit d45306b574a26f81234cd198dfc7c106d90cbf06 Author: Liu Zhenlong Date: Wed Aug 19 01:57:50 2026 +0800 i2c: qcom-cci: fix device_node refcount leak in cci_probe()/cci_remove() commit 7362a1553eb09a8cdf8be7e509bd5309a8342486 upstream. The of_node_put() matching of_node_get() runs after i2c_del_adapter(), whose trailing memset() zeroes adap->dev and thus adap->dev.of_node, making the put a no-op and leaking the node on every adapter removal and error cleanup. Use a devm action: the pointer is captured at registration, out of reach of that memset(), and devres runs the put once on probe failure and detach, replacing the three manual of_node_put() calls. The setup loop uses the scoped iterator form so the child node is released automatically if devm_add_action_or_reset() fails mid-loop. Suggested-by: Konrad Dybcio Fixes: 02a4a69667a2 ("i2c: qcom-cci: don't put a device tree node before i2c_add_adapter()") Assisted-by: Claude:claude-opus-5 Signed-off-by: Liu Zhenlong Cc: # v5.17+ Reviewed-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260818175750.4205-1-dragonliu2018@gmail.com Signed-off-by: Greg Kroah-Hartman commit a57d9592714506556e30188af72dd3bdb9f647b5 Author: Linkai Gong Date: Mon Sep 7 15:11:02 2026 +0800 i2c: atr: fix dangling adapter pointer on add failure commit ad34235808b63a70ca4989b7a2852923193d06ef upstream. i2c_atr_add_adapter() stores atr->adapter[chan_id] before i2c_add_adapter() so that the I2C bus notifier can match child clients during registration. On failure the channel is freed but the slot was left pointing at freed memory, which can lead to use-after-free in i2c_atr_del_adapter() / cleanup and also block reuse with -EEXIST. Clear the slot on the i2c_add_adapter() error path before freeing chan. Fixes: a076a860acae ("media: i2c: add I2C Address Translator (ATR) support") Signed-off-by: Linkai Gong Cc: # v6.6+ Reviewed-by: Andy Shevchenko Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260907071102.1080840-1-gonglinkai@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 5a9d85a2f4ca687d36720b8de384b650145ccd70 Author: Shengzhuo Wei Date: Thu Aug 27 23:43:01 2026 +0800 i2c: at91: release DMA channels on remove and probe error commit f7eeb1af8537b05953fb1c88ab8b59d94059a381 upstream. at91_twi_configure_dma() requests exclusive tx/rx DMA channels, but nothing ever releases them on driver detach, and the probe error path after the channels are acquired (i2c_add_numbered_adapter() failure) returns without releasing them either, because the remove callback is not invoked after a failed probe. Move the release into a helper, call it from the existing configure-failure path, the adapter-registration failure path, and at91_twi_remove(). Fixes: 60937b2cdbf9 ("i2c: at91: add dma support") Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Cc: # v3.8+ Acked-by: Mukesh Kumar Savaliya Signed-off-by: Andi Shyti Link: https://patch.msgid.link/20260827-i2c-dma-channel-leak-v1-1-271d4adc03a0@cherr.cc Signed-off-by: Greg Kroah-Hartman commit 959c66dc4a915be306c35691095c787c61dc7df9 Author: fangqiurong Date: Sat Sep 12 21:15:18 2026 +0800 sched_ext: Close the pre-enable ops error claim window commit c7a1c6e8004ab12a9c9bfdcb603f60f9bf4a3cee upstream. scx_alloc_and_add_sched() publishes ops->priv before scx_root_enable_workfn() switches the state to SCX_ENABLING. An error claimed via scx_bpf_error_bstr() from an associated BPF program in that window is consumed by scx_disable_workfn(), which takes the pre-enable shortcut in scx_root_disable(). The shortcut returns without any teardown and restores SCX_DISABLED with an unconditional scx_set_enable_state() xchg racing the enable workfn's own transition. The enable then completes with the claim consumed: the scheduler stays up but can never be disabled again, and bpf_scx_unreg() frees it while still in use, resulting in a use-after-free. Both WARN_ON_ONCE()s fire back to back: WARNING: kernel/sched/ext/ext.c:7522 at scx_root_enable_workfn+0xeec/0x1be0, CPU#3: scx_enable_help/276 WARNING: kernel/sched/ext/ext.c:6398 at scx_root_disable+0xb50/0xdb8, CPU#0: sched_ext_helpe/664 scx_root_enable_workfn() switches to SCX_ENABLING before the scheduler allocation, so ops->priv is never visible while SCX_DISABLED. The allocation failure path restores SCX_DISABLED. Fixes: 105dcd005be2 ("sched_ext: Introduce scx_prog_sched()") Cc: stable@vger.kernel.org Signed-off-by: fangqiurong Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 589f0945bf3ebf0790fd51e28c7f0d04ed3d8b78 Author: Wanwu Li Date: Thu Sep 3 14:06:26 2026 +0800 sched_ext: Fix NULL sched deref in kfunc sub-sched error paths commit 0a85182723b65ad8bee8131bc38fcf0347d6679b upstream. When the root scheduler has sub-scheds attached, the COMPAT kfunc wrappers scx_bpf_select_cpu_and() and scx_bpf_dsq_insert_vtime() refuse the call and report to @p's scheduler: scx_error(scx_task_sched(p), "... must be used"); The wrappers are reachable with tasks that have no scheduler. scx_bpf_select_cpu_and() is in the select_cpu kfunc group, which scx_kfunc_context_filter() opens to BPF_PROG_TYPE_SYSCALL programs; scx_bpf_dsq_insert_vtime() is in the enqueue_dispatch group, which ops.enqueue() and ops.dispatch() may call with any KF_RCU task -- the group has no kf_tasks validation, and scx_dsq_insert_preamble() checks task ownership with scx_task_on_sched() precisely because @p may be an arbitrary task. scx_task_sched(p) is p->scx.sched, which is NULL for tasks past sched_ext_dead() -- which clears it via scx_disable_and_exit_task() on exit -- and for idle tasks, which the enable paths skip as they are never scheduled through SCX. It is also an rcu_dereference_protected() that expects @p's pi_lock or rq lock, which neither wrapper holds. Passing NULL to scx_error() reaches scx_vexit(), which dereferences sch->exit_info, oopsing the kernel. One concrete trigger exercised while developing the fix: a BPF_PROG_TYPE_SYSCALL program calling the select_cpu_and wrapper on an exited-but-not-reaped task while a sub-scheduler was attached (its pid stays findable while the zombie is unreaped; faulting instruction is the scx_vexit() prologue "mov r15,[rdi+0x398]" with RDI=NULL and 0x398 the offset of sch->exit_info): sched_ext: BPF scheduler "kfunc_subsched_null" enabled sched_ext: BPF sub-scheduler "kfunc_subsched_null" enabled sched_ext: Unassociated program run_select_cpu_ (id 76) BUG: kernel NULL pointer dereference, address: 0000000000000398 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 8201 Comm: kfunc_test_runn Tainted: G W RIP: 0010:scx_vexit+0x25/0xa0 Code: ... <4c> 8b bf 98 03 00 00 ... CR2: 0000000000000398 Call Trace: __scx_exit+0x4f/0x70 scx_bpf_select_cpu_and+0xab/0xb0 bpf_prog_430ed61a7b66e03a_run_select_cpu_and+0x9c/0xe7 ? __x64_sys_bpf+0x2c/0x40 bpf_prog_test_run_syscall+0x130/0x2f0 __sys_bpf+0x930/0x10d0 ? __x64_sys_bpf+0x2c/0x40 __x64_sys_bpf+0x2c/0x40 do_syscall_64+0xbc/0x460 entry_SYSCALL_64_after_hwframe+0x76/0x7e Read @p's scheduler under RCU instead, which the wrappers can do from their guard(rcu)(): fault it when it can be determined, and when it can't be determined -- @p is a task past sched_ext_dead() or an idle task -- there is nothing obviously wrong to report, so just refuse the call as before without faulting any scheduler. These COMPAT wrappers are scheduled for eventual removal once the deprecation grace period elapses, but until then -- and regardless of their removal timeline -- they must not oops the kernel on a task they are handed. Cc: stable@vger.kernel.org # v7.1+ Fixes: a5fa0708cbfd ("sched_ext: Enforce scheduling authority in dispatch and select_cpu operations") Suggested-by: Andrea Righi Signed-off-by: Wanwu Li Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 134825dfc971fbf2b1d0f58f0b3bce8332ad0afb Author: Jarkko Sakkinen Date: Tue Sep 1 23:58:06 2026 +0300 KEYS: trusted: Fix tpm2_load_cmd() boundary check commit 114f00d738f15dd8c7318369edcdc53dd6d08763 upstream. tpm2_load_cmd() does boundary checks against the ASN.1 size i.e., payload->blob_len. Address this by passing the decoded blob size to tpm2_load_cmd(), and use it for the boundary checks. Cc: stable@vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Reported-by: co+6a581c4284f721d4@bugs.sh Closes: https://bugs.sh/b/6a581c4284f721d4/ Reviewed-by: Stefano Garzarella Tested-by: Srish Srinivasan Link: https://lore.kernel.org/r/20260901205809.2028454-1-jarkko@kernel.org Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 60f381111937437f7a64bb006a0164d3023c0b40 Author: Maoyi Xie Date: Fri Aug 21 17:59:35 2026 +0800 keys: translate request_key_auth pid for the reading procfs instance commit 0d6a4268b06084baafd8ee5d66955c7e1c2e053b upstream. request_key_auth_describe() prints rka->pid into /proc/keys as a raw pid_t in the initial pid namespace. A reader can open /proc/keys through a mount in another pid namespace. That reader sees a number with no meaning there. The number can even name an unrelated task. The line needs VIEW on the key. So the reader either shares the key owner's uid or possesses the key. The fix keeps a struct pid. Commit 4f82f45730c6 ("net ip6 flowlabel: Make owner a union of struct pid * and kuid_t") gave /proc/net/ip6_flowlabel the same storage. The print goes through pid_nr_ns(). It renders against the pid namespace of the procfs instance the line is read through. Commit ad08978ab41c ("ipv6/flowlabel: simplify pid namespace lookup") moved that print to the same anchor. Output through an initial namespace /proc does not change. The line shows 0 for a requestor with no number in that namespace. Translating at read time was the alternative. find_pid_ns() can resolve a recycled number. The line would then name a live task with no connection to the key. A stored struct pid gives 0 instead when the requestor has no number there. Link: https://lore.kernel.org/keyrings/20260809110202.2180410-1-maoyixie.tju@gmail.com/ Fixes: 78b7280cce23 ("KEYS: Improve /proc/keys") Cc: stable@vger.kernel.org # v5.10+ Assisted-by: Claude:claude-opus-5 codeql Signed-off-by: Maoyi Xie Link: https://lore.kernel.org/r/20260821095935.1864998-1-maoyixie.tju@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit cca38f2102a4cd35eda8d48950df4817b4b24757 Author: Cen Zhang Date: Sat Sep 12 00:31:16 2026 +0300 KEYS: encrypted: fix integer overflow of datablob_len commit 8697c431e297eb0d0ab13dda6bc172b48a34f05c upstream. encrypted_key_alloc() stores datablob_len in a u16. It is computed from multiple string and payload lengths. If the result exceeds U16_MAX, the assignment truncates the allocation size. KASAN reports a 32760-byte slab-out-of-bounds write when __ekey_init() copies the master key description into the undersized buffer. The total payload length stored in key->datalen is also a u16. Use check_add_overflow() to reject values that do not fit either destination, and use kzalloc_flex() for the flexible-array allocation. Fixes: 7e70cb497850 ("keys: add new key-type encrypted") Cc: stable@vger.kernel.org Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Cen Zhang Signed-off-by: Francis Perron Reviewed-by: Jarkko Sakkinen Tested-by: R Nageswara Sastry Link: https://lore.kernel.org/r/20260909153433.83117-1-cenzhang@linux.microsoft.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 77c0fade37c80e8aa16ac048a9828249055e3f66 Author: Wenjie Qi Date: Sun Aug 30 01:36:12 2026 +0800 mm: filemap: retain mapped dropbehind folios commit 848d2ce2fce15fbdc083fbf9691bfa72911033c4 upstream. Fault-around can map ready dropbehind folios without going through the normal page-cache lookup that clears dropbehind. A mapping represents a competing cached user, so retain the folio instead of forcibly unmapping it when writeback completes. For a mapped folio, folio_unmap_invalidate() can call unmap_mapping_folio(), which takes i_mmap_rwsem and may sleep. Retaining mapped folios avoids this path when folio_end_dropbehind() runs in non-preemptible task context. Tal was able to trigger a sleeping-in-atomic warning due to this [1]. Unmapped dropbehind folios continue through the existing invalidation path. Link: https://lore.kernel.org/4aba05e1a2c3b61cb337d373eb9b7a8db4ddd822.1788024049.git.qiwenjie@xiaomi.com Link: https://lore.kernel.org/076bb01b-6fcf-4691-be8c-0e8507c9fe64@columbia.edu [1] Fixes: fb7d3bc41493 ("mm/filemap: drop streaming/uncached pages when writeback completes") Signed-off-by: Wenjie Qi Reviewed-by: Matthew Wilcox (Oracle) Reviewed-by: Tal Zussman Tested-by: Tal Zussman Cc: Barry Song Cc: Jan Kara Cc: Jens Axboe Cc: Trond Myklebust Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8fdc521d438fbf0d22c13d51d55d5dd82d7202b2 Author: Lorenzo Stoakes (ARM) Date: Wed Sep 2 19:08:08 2026 +0100 mm/vma: correctly unaccount on mmap_prepare() failure commit 6cc27d82196385fe06853319f74312a7d8019726 upstream. __mmap_setup() accounts memory for relevant mappings via: security_vm_enough_memory_mm() -> __vm_enough_memory() -> vm_acct_memory() If __mmap_setup() fails, this indicates that this accounting did not take place, and thus it's appropriate for __mmap_region() to jump to abort_munmap. However if call_mmap_prepare() fails, it also jumps there and any accounted memory is not correctly unaccounted. Fix this by handling each error separately. Link: https://lore.kernel.org/20260902-fix-unaccount-mmap_prepare-v1-1-ea070189fdfb@kernel.org Fixes: c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file callback") Signed-off-by: Lorenzo Stoakes (ARM) Cc: Jann Horn Cc: Liam R. Howlett Cc: Pedro Falcato Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 469c12a69ab1842a9090b6c074ffedbfd9584f9c Author: Jiayuan Chen Date: Wed Sep 2 15:37:59 2026 +0800 mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem commit 932cfb25e7ce98d1f93895671ec186a3087e4f80 upstream. With cgroup.memory=nokmem, shrinker_memcg_alloc() bails out early and never allocates an id, so shrinker->id keeps the 0 it got from the kzalloc() in shrinker_alloc(). __list_lru_init() then copies that 0 into lru->shrinker_id, where it looks like a valid bit index. Nothing calls expand_shrinker_info() on nokmem either, so shrinker_nr_max stays 0 and every memcg ends up with an empty map (map_nr_max == 0). deferred_split_folio() hands a real memcg to __list_lru_add() regardless of whether the lru is memcg aware, so the first THP queued in a cgroup does set_shrinker_bit(memcg, nid, 0) and trips the bounds check: WARNING: mm/shrinker.c:212 at set_shrinker_bit+0x7d/0x90, CPU#126 Call Trace: deferred_split_folio+0x18c/0x220 map_anon_folio_pmd_nopf+0xdd/0x130 map_anon_folio_pmd_pf+0x14/0xb0 do_huge_pmd_anonymous_page+0x1a1/0x620 __handle_mm_fault+0xea9/0x10d0 handle_mm_fault+0xe5/0x320 do_user_addr_fault+0x1cc/0x870 exc_page_fault+0x81/0x1b0 asm_exc_page_fault+0x27/0x30 Harmless, the WARN_ON_ONCE() is what keeps the out of bounds unit[] read from happening, but the id should not look valid in the first place. Clear it before returning. Two other spots could paper over this: drop the id in __list_lru_init() when nokmem turns memcg_aware off, or make deferred_split_folio() pass NULL like list_lru_add_obj() does. Both leave shrinker->id lying around for the next caller, so fix it where the id is handed out. Link: https://lore.kernel.org/20260902073800.305481-1-jiayuan.chen@linux.dev Fixes: fafaeceb89a5 ("mm: switch deferred split shrinker to list_lru") Signed-off-by: Jiayuan Chen Acked-by: Shakeel Butt Cc: Usama Arif Cc: Dave Chinner Cc: Johannes Weiner Cc: Kairui Song Cc: Muchun Song Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d9d3ed93d792f129465c5b2f1c9aff6f2c653126 Author: Lorenzo Stoakes (ARM) Date: Fri Aug 28 12:20:37 2026 +0100 mm/mremap: account mm->locked_vm correctly for MREMAP_DONTUNMAP commit 397432cab17bccb600fd6c16ed593f1149042268 upstream. When a VMA is mremap()'d with MREMAP_DONTUNMAP set, that results in the VMA being copied, but the source VMA not being unmapped. If the VMA is mlock()'d this is a legal operation, though the source VMA has its VMA_LOCKED_BIT cleared. However this is done in dontunmap_complete(), after mm->locked_vm was incremented via vrm_stat_account(), resulting in double-counting. Worse, this is not even corrected when source VMA is unmapped, due to the VMA_LOCKED_BIT flag having been cleared. This all works fine in the usual mremap() case (without MREMAP_DONTUNMAP), as the source VMA is unmapped with VMA_LOCKED_BIT intact, at which time mm->locked_vm is decremented accordingly. Resolve the issue by invoking vrm_stat_account() only after dontunmap_complete() has run. Note that MREMAP_DONTUNMAP requires old_len == new_len, so no need to account for a delta in size in this case. The bug was introduced by commit b714ccb02a76 ("mm/mremap: complete refactor of move_vma()") which incorrectly reordered the accounting and the clearing of the VMA_LOCKED_BIT flag. Link: https://lore.kernel.org/20260828-mremap-fix-locked-vm-v1-1-c80be7505d1e@kernel.org Fixes: b714ccb02a76 ("mm/mremap: complete refactor of move_vma()") Signed-off-by: Lorenzo Stoakes (ARM) Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260825-fix-mremap-dontunmap-pgoff-v1-1-39a40b2c98b3@kernel.org Reported-by: Kunwu Chan Closes: https://lore.kernel.org/all/20260828094823.594279-1-kunwu.chan@linux.dev/ Acked-by: Vlastimil Babka (SUSE) Tested-by: Kunwu Chan Reviewed-by: Kunwu Chan Cc: Jann Horn Cc: Liam R. Howlett Cc: Pedro Falcato Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5f3f71941c3a0c9300f3faaa4344628bf149e522 Author: Shakeel Butt Date: Tue Sep 1 11:01:09 2026 -0700 mm/mlock: use the IRQ-safe accessor for NR_MLOCK in __munlock_folio() commit e14a3454806468b086fe2e4ca2e1bff95b528531 upstream. NR_MLOCK is updated from interrupt context. __free_pages_prepare() clears a stray PG_mlocked and adjusts NR_MLOCK, and a folio can reach it with the flag still set from a bio completion handler: __free_pages_ok+0x6af/0x7a0 __bio_release_pages+0xde/0x260 __iomap_dio_bio_end_io+0x16e/0x1a0 blk_update_request+0x14b/0x3d0 blk_mq_end_request+0x18/0x30 blk_done_softirq+0x49/0x60 The folio gets there like this. A MAP_SHARED file mapping is mlocked, so its page cache folios carry PG_mlocked, and an O_DIRECT write sourced from that mapping GUP-pins those same folios. munlock() then runs mlock_vma_pages_range(), which clears VM_LOCKED before walking the page tables to munlock each folio. A concurrent hole punch reaches the folio through the rmap (i_mmap_rwsem, not mmap_lock) and can land inside that window: __folio_remove_rmap() -> munlock_vma_folio() sees VM_LOCKED already clear, so it neither queues the folio on the mlock batch nor takes a reference, and the pte it clears makes the pending mlock_pte_range() walk skip the folio at its !pte_present() check. filemap_remove_folio() then drops the page cache reference, leaving the bio's pin as the last one, released from the completion handler above. So __zone_stat_mod_folio() here needs interrupts disabled, not merely preemption, and __munlock_folio() has a path where they are not: when the folio has already been taken off the LRU by somebody else the function jumps straight to the counter update without taking the lruvec lock. The read-modify-write of the per-CPU NR_MLOCK diff can then be interrupted by the softirq above, and one of the two decrements is lost, leaving Mlocked in /proc/meminfo permanently overstated. Use zone_stat_mod_folio(). mod_zone_state()'s this_cpu_try_cmpxchg() is atomic against a same-CPU interrupt and retries, and on the path where the lruvec lock is held its cost is negligible next to the lock itself. The UNEVICTABLE_PG* events are deliberately left on the __ accessors: they occupy different vm_event_states slots from the UNEVICTABLE_PGCLEARED that __free_pages_prepare() bumps, and nothing updates those two from interrupt context. Link: https://lore.kernel.org/20260901180109.3797944-1-shakeel.butt@linux.dev Fixes: 2fbb0c10d1e8 ("mm/munlock: mlock_page() munlock_page() batch by pagevec") Signed-off-by: Shakeel Butt Reported-by: syzbot+cd2073ee6d958a8d0fcd@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-mm/6a931c5a.08e933ee.dbf97.0093.GAE@google.com/ Acked-by: Hugh Dickins Cc: Jann Horn Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Pedro Falcato Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 244185c31b9a328fda76435d08b06bb46db71aef Author: Lorenzo Stoakes (ARM) Date: Thu Aug 27 20:55:57 2026 +0100 mm/huge_memory: bypass THP tuneables for huge pfnmap mappings commit e384abeb559d10d6505aec053ede9368d81d4c71 upstream. The sysfs THP tuneables at /sys/kernel/mm/transparent_huge_pages/ rather confusingly only control the behaviour of THP in some instances. They are not applicable to MADV_COLLAPSE operations, nor to DAX mappings. Long-term, THP is predicated upon compaction being able to obtain large folios to populate THP ranges. However, vm_normal_folio() returns NULL for PFN map mappings, thus their reference count is maintained by the driver, not core mm. As a consequence, the folios are not subject to reclaim nor compaction, so are not truly part of the THP mechanism at all. However, since commit 5dd40721f147 ("mm: allow THP orders for PFNMAPs") introduced the ability to establish huge PFN maps, they have been subject to THP tuneables. This is incorrect - if a huge PFN map is available (defined by vma->vm_ops->huge_fault being non-NULL for a VMA_PFNMAP_BIT VMA), then it should be mapped huge upon fault-in. Correct this by explicitly checking for this while ensuring that smaps continues to accurately report THPeligible statistics. While here, abstract the entire file-backed THP check in vma_can_map_huge_file(), with sensible separation of logic into helper functions. Note that drm_gem_shmem_mmap() and panthor_gem_mmap() establish huge PFN maps of shmem folios, however they are marked unevictable in drm_gem_get_pages(), and in any case would fail the reference check in __remove_mapping() even if they weren't. Failing to map huge PFN maps has resulted in significant real-world performance degradation, see links for details. [ziy@nvidia.com: rename some functions] Link: https://lore.kernel.org/DL1HIHWYJ7TB.1CY76SJS0V03L@nvidia.com Link: https://lore.kernel.org/20260827-hugepfn-allowable-orders-v1-1-94819c8807c8@kernel.org Fixes: 5dd40721f147 ("mm: allow THP orders for PFNMAPs") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Zi Yan Reported-by: Cedric Le Goater Closes: https://lore.kernel.org/linux-mm/20260805055544.1568534-1-clg@redhat.com/ Reported-by: Saravanan D Closes: https://lore.kernel.org/linux-mm/20260821070520.25759-1-saravanand@crusoe.ai/ Reviewed-by: Zi Yan Tested-by: Saravanan D Tested-by: Lance Yang Reviewed-by: SJ Park Reviewed-by: Baolin Wang Cc: Barry Song Cc: David Hildenbrand Cc: Dev Jain Cc: Jason Gunthorpe Cc: Liam R. Howlett Cc: Peter Xu Cc: Ryan Roberts Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7c0d0d6de46076b43a2acaf1026b6648f8434c39 Author: Nhat Pham Date: Fri Aug 28 12:14:33 2026 -0700 mm, swap: fix SWAP_USAGE_OFFLIST_BIT collision with real usage count commit 12e9ac7bc5b254048f886bf421e3a15491106c1f upstream. SWAP_USAGE_OFFLIST_BIT is embedded in the si->inuse_pages usage counter, and is meant to sit above any value that counter can reach. However, it is defined from BITS_PER_TYPE(atomic_t), so it is bit 30. On a system with 4 KiB pages the flag collides with the usage count once that count reaches 4 TiB. swap_usage_in_pages() masks bit 30 out, so whenever the real count has that bit set, every caller of it reads 4 TiB low: * /proc/swaps understates Used by 4 TiB. * A raw count of exactly 2^30 masks to zero, so try_to_unuse() takes its "if (!swap_usage_in_pages(si)) goto success;" early exit and swapoff tears the device down while pages are still swapped out. Nothing in the rest of swapoff aborts the teardown, so those pages are lost. Independently of swapoff, the collision also corrupts the counter and the plist. On a device in normal use, a free that leaves bit 30 set in the count makes swap_usage_sub() see the flag where there is only count, and call add_to_avail_list(). It clears the bit with fetch_and(~SWAP_USAGE_OFFLIST_BIT), leaving the stored count 4 TiB below the real one, and calls plist_add() on a device that is already listed, tripping the WARN_ON(!plist_node_empty(node)) in plist_add() and linking the node a second time. Change the definition of SWAP_USAGE_OFFLIST_BIT to be based on atomic_long_t instead. Note that the usage counter field itself is of this same type, so it is still a valid bit. Link: https://lore.kernel.org/20260828191433.3304458-1-nphamcs@gmail.com Fixes: b228386cf237 ("mm, swap: clean up plist removal and adding") Signed-off-by: Nhat Pham Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260825153238.2695446-1-nphamcs%40gmail.com Suggested-by: Andrew Morton Reviewed-by: Andrew Morton Acked-by: Kairui Song Cc: Baoquan He Cc: Barry Song Cc: Chris Li Cc: Gregory Price Cc: Johannes Weiner Cc: Joshua Hahn Cc: Kemeng Shi Cc: Shakeel Butt Cc: Youngjun Park Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f222bb8c30cf5699c560b29179ff2bddcac1f950 Author: Yifei Gao Date: Tue Aug 4 21:34:56 2026 +0000 memstick: ms_block: destroy io_queue workqueue on removal commit 90af7fde083e1b22c349c3a8b1626728e44e474c upstream. msb_init_disk() creates the per-card ordered workqueue msb->io_queue with alloc_ordered_workqueue(). It is torn down with destroy_workqueue() only on the init error path; msb_remove() never destroys it. msb_stop() merely flushes the queue, and neither msb_data_clear() nor put_disk() free it. As a result every card insert/remove cycle leaks the workqueue and its kworker, exhausting kernel memory over repeated cycles. Destroy the workqueue in msb_remove() after the disk has been removed and the queue drained. Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit ecc03877b1b05cb1e3a72175ccb868383eccc518 Author: Shakeel Butt Date: Fri Aug 28 19:32:51 2026 -0700 memcg: avoid charging the root memcg from obj_cgroup_charge_pages() commit 6e673d0879ef78c395cfe0d3ba316690a60055d8 upstream. obj_cgroup_charge_pages() resolves the objcg to its memcg and calls try_charge_memcg(), which does not short circuit the root memcg. That memcg can be the root memcg: obj_cgroup_is_root() reflects the memcg the objcg was created for and is never updated, while memcg_reparent_objcgs() does redirect objcg->memcg to the parent on rmdir. An objcg of a dying child of root therefore passes every obj_cgroup_is_root() filter but resolves to the root memcg. Folios keep the objcg they were charged with, so this is easy to reach through zswap: allocate anon memory in a cgroup, move the task out, remove the cgroup, then write to the root cgroup's memory.reclaim. The reclaimed folios are charged through the reparented objcg and end up in refill_stock() with the root memcg: WARNING: mm/memcontrol.c:2198 at refill_stock+0x644/0x940 refill_stock+0x644/0x940 try_charge_memcg+0x12d6/0x1570 __obj_cgroup_charge+0x35/0xf0 obj_cgroup_charge+0x1de/0x210 obj_cgroup_charge_zswap+0x83/0x270 zswap_store+0x1620/0x2000 swap_writeout+0x94c/0x14c0 shrink_folio_list+0x3388/0x52b0 [...] try_to_free_mem_cgroup_pages+0x30d/0x830 user_proactive_reclaim+0x504/0x840 memory_reclaim+0x1f/0x30 Beyond the warning, the charge is asymmetric: obj_cgroup_uncharge_pages() skips refill_stock() for the root memcg, so the root's page counter grows and is never uncharged. It is not user visible, since memory.current is not exposed on the root, but it is a leak. Use try_charge(), which returns early for the root memcg, restoring the symmetry with obj_cgroup_uncharge_pages(). The above sequence was scripted into a standalone reproducer (zswap on, swap on a virtio disk, 512MB of anon memory faulted in inside a child of the root cgroup, the task then migrated to the root cgroup, the child removed, followed by "echo 600M swappiness=max > memory.reclaim" on the root) and run in a CONFIG_DEBUG_VM=y VM. It reproduces the splat on the first zswap store of a reparented folio, with the same call chain as the report. With this patch applied the splat is gone while the zswap store count over the run is unchanged, so the same path is still exercised. cgroup selftests test_zswap, test_kmem and test_memcontrol show no new failures. Link: https://lore.kernel.org/20260829023251.474083-1-shakeel.butt@linux.dev Fixes: 20d6c1725228 ("memcg: avoid refill_stock for root memcg") Signed-off-by: Shakeel Butt Reported-by: Farhad Alemi Closes: https://lore.kernel.org/all/CA+0ovCgWzUMK+nNbbtH7eV65Ca=fDN4Ozu7iASgryjvv8Tk8zQ@mail.gmail.com/ Reviewed-by: Muchun Song Reviewed-by: Johannes Weiner Cc: Michal Hocko Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3f017c2ca8c31a1e135dd87be647096866d6b196 Author: Théo Lebrun Date: Fri Aug 28 16:07:33 2026 +0200 mips: select CONFIG_WEAK_REORDERING_BEYOND_LLSC from CONFIG_EYEQ commit bbc448c541ed90d52f9ec22f17394304e3bf170e upstream. On I6500 CPU cores, lld and scd give no ordering guarantees (same as all other instructions). To respect the assumption that arch_cmpxchg() is fully ordered, we must inject sync instructions above and below our lld/scd loops using the already in place WEAK_REORDERING_BEYOND_LLSC infrastructure. Otherwise, bad things can happen: [ 34.054496] CPU 3 Unable to handle kernel paging request at virtual address 0000000000000000, epc == a80000080838e01c, ra == a80000080838dfc4 [ 34.054559] Oops[#1]: [ 34.069561] CPU: 3 UID: 0 PID: 170 Comm: pipe_race Not tainted 7.2.0-rc6-01553-gb73c35220968-dirty #103 VOLUNTARY [ 34.079932] Hardware name: Mobile EyeQ5 MP5 Evaluation board [ 34.085592] $ 0 : 0000000000000000 0000000000000001 0000000000000000 0000000000000000 [ 34.093616] $ 4 : a800000808ee2618 000000000b7a879d 0000000000001000 0000000000000000 [ 34.101638] $ 8 : 0000000000e3f2c9 0000000000000000 a800000808a2a9f8 0000000000000000 [ 34.109660] $12 : a8000008139ffcd8 ffffffff84080018 a80000080837fae0 7878787878787878 [ 34.117682] $16 : a800000807e82940 0000000000001000 0000000000000000 0000000000000000 [ 34.125704] $20 : a800000802920e00 a8000008139ffdf8 a800000802649400 0000000000e3f2c9 [ 34.133726] $24 : 0000000000000006 00000001200406e0 [ 34.141783] $28 : a8000008139fc000 a8000008139ffd10 0000000000e3f2c8 a80000080838dfc4 [ 34.149837] epc : a80000080838e01c anon_pipe_read+0xd4/0x428 [ 34.155697] ra : a80000080838dfc4 anon_pipe_read+0x7c/0x428 [ 34.161549] Status: 140000e3 KX SX UX KERNEL EXL IE [ 34.166551] Cause : 40800408 (ExcCode 02) [ 34.170574] BadVA : 0000000000000000 [ 34.174161] PrId : 0001b028 (MIPS I6500) [ 34.178183] Process pipe_race (pid: 170, threadinfo=000000005ca35720, task=00000000e1013890, tls=000000014ebbb780) [ 34.188568] Stack : a800000802649400 0000000000000000 0000000000000000 a8000008139ffdd0 [ 34.196623] 0000000000000fba a800000808ee0000 0000000000000001 a8000008130c3e80 [ 34.204676] a8000008080d1280 a8000008139ffd58 a8000008139ffd58 1dbd2b22ea1dd500 [ 34.212729] a800000802649400 a800000808ee0000 ffffffffffffffea 0000000000000001 [ 34.220783] 0000000000001000 0000000000000000 00000001200ae518 ffffffffffffffff [ 34.228836] 000000fffbe0e530 a80000080837edf4 000000fffbe0e530 0000000000000000 [ 34.236890] 0000000000000000 0000000000000000 000000014ebb55a0 0000000000001000 [ 34.244943] 0000000000000001 a800000802649400 0000000000000000 0000000000000000 [ 34.252996] 0000000000000000 0000400400000000 0000000000000000 1dbd2b22ea1dd500 [ 34.261049] 00000000140000e3 a800000802649400 a800000802649400 a800000808ee0000 [ 34.269103] ... [ 34.271568] Call Trace: [ 34.274026] [] anon_pipe_read+0xd4/0x428 [ 34.279533] [] vfs_read+0x25c/0x318 [ 34.284607] [] ksys_read+0x104/0x138 [ 34.289763] [] syscall_common+0x44/0x68 [ 34.295187] [ 34.296689] Code: f84000cf 02209825 de020010 d8400004 02002825 0040f809 02802025 f84000c3 [ 34.306504] [ 34.308099] ---[ end trace 0000000000000000 ]--- My initial reproducer was the xdp-tools test suite. A standalone reproducer would be an lld/scd loop that, when the read is reordered by the CPU, triggers a fault. We can achieve this from userspace by stressing an anonymous pipe, which uses a mutex. Program used: // SPDX-License-Identifier: GPL-2.0 // pipe_race.c - reproducer for MIPS LL/SC reordering vs fs/pipe.c // // Two userspace processes on an anonymous pipe: // parent = writer: tight write() loop // child = reader: tight read() loop #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include int main(void) { long wrsize = 70; // bytes per write() long rdsize = 4096; // bytes per read() int pfd[2]; char *buf; pid_t pid; int ret; ret = pipe(pfd); assert(!ret); pid = fork(); assert(pid >= 0); if (pid == 0) { /* reader */ close(pfd[1]); buf = malloc(rdsize); assert(buf); for (;;) { ssize_t n = read(pfd[0], buf, rdsize); if (n < 0 && errno == EINTR) continue; if (n <= 0) _exit(n < 0 ? 1 : 0); } } close(pfd[0]); /* writer */ buf = malloc(wrsize); assert(buf); memset(buf, 'x', wrsize); for (;;) { ssize_t n = write(pfd[1], buf, wrsize); if (n < 0 && errno == EINTR) continue; if (n != wrsize) break; } kill(pid, SIGKILL); wait(NULL); return 0; } Fixes: fbe0fae601b7 ("MIPS: mobileye: Add EyeQ6H support") Cc: stable@vger.kernel.org Signed-off-by: Théo Lebrun Reviewed-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 164313e24cb0f51528bc2099c5564174ead11d8a Author: Alexey Klimov Date: Thu Sep 17 10:16:42 2026 +0200 soc: samsung: exynos-pmu: fix use-after-free of interrupt generator node commit 4dd1999783d7d12434006289338373e49492dc96 upstream. The setup_cpuhp_and_cpuidle() parses the device tree node for the interrupt generation block via of_parse_phandle() and decrements its reference count using of_node_put() immediately after fetching the resource address. However, later the intr_gen_node pointer is passed into of_syscon_register_regmap(). Fix this by declaring intr_gen_node with __free() and removing of_node_put(). Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=3 Fixes: 78b72897a5c8 ("soc: samsung: exynos-pmu: Enable CPU Idle for gs101") Cc: stable@vger.kernel.org Signed-off-by: Alexey Klimov Link: https://patch.msgid.link/20260828-exynos-pmu-cpuhp-idle-fixes-v2-1-06bce6107bd6@linaro.org Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260917081641.72291-2-krzk@kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 537a5ae18b2be70f8eb0aca843682e81a69aab91 Author: Zhiling Zou Date: Sat Aug 29 17:24:24 2026 +0800 xfrm: save input state data before secpath resets commit 3cf5cdecd99c9c186a5ea518d93bbf3045b6e3aa upstream. xfrm_input() stores the current xfrm_state in the skb secpath while it continues receive-side processing. Some input paths can reset that secpath before xfrm_input() has finished dereferencing the state. Receive callback users such as VTI and XFRM interfaces can reset the secpath. The VTI receive path does so before checking whether the packet crosses network namespaces, while the XFRM interface path does so only for cross-network-namespace packets. The XFRM_MAX_DEPTH error path can also reset the secpath before the final drop callback reports the current state's protocol. If secpath_reset() drops the last state reference while the state is concurrently deleted, xfrm_input() can still dereference the freed state when selecting transport_finish() or reporting the drop callback protocol. Save the state protocol on the stack while the state is still valid, and use the already saved address family for transport_finish(). A larval XFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This preserves the existing drop-path fallback while avoiding the post-reset state dereferences without adding an extra state reference to every received packet. Fixes: df3893c176e9 ("vti: Update the ipv4 side to use it's own receive hook.") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 9b74a47a4cbd0d29faff4f3b199212c73e6b6220 Author: Siwei Zhang Date: Thu Jul 30 19:40:08 2026 +0800 xfrm: use hlist_del_init_rcu for state_cache and state_cache_input commit 2afb8dc1f4390f164db8352f8e685e126e9db566 upstream. Commit 14acf9652e56 ("xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete") converted bydst/bysrc/byseq/byspi from hlist_del_rcu() to hlist_del_init_rcu() so that a second __xfrm_state_delete() on the same object becomes a no-op rather than a write through LIST_POISON pprev. It missed state_cache and state_cache_input, which kept hlist_del_rcu(): - hlist_del_rcu() leaves pprev = LIST_POISON2 (non-NULL), so hlist_unhashed() returns false. - hlist_del_init_rcu() leaves pprev = NULL, so hlist_unhashed() returns true. A second __xfrm_state_delete() therefore enters __hlist_del() on the already-deleted state_cache/state_cache_input nodes and does WRITE_ONCE(*pprev, next) through LIST_POISON2 — a write use-after-free once the slab is reused. The corruption can in turn cause a subsequent hlist_for_each_entry_rcu traversal to follow a dangling next pointer, producing the read use-after-free reported in xfrm_input_state_lookup(). Switch state_cache and state_cache_input to hlist_del_init_rcu() to match the other four lists, closing the write use-after-free and, with it, the read use-after-free it spawns. Assisted-by: CodeBuddy:GLM-5.2 Fixes: 0045e3d80613 ("xfrm: Cache used outbound xfrm states at the policy.") Fixes: 81a331a0e72d ("xfrm: Add an inbound percpu state cache.") Cc: stable@vger.kernel.org Signed-off-by: Siwei Zhang Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 84e378395494963b1e581cf223a7cbeec8c0e2d6 Author: Chengfeng Ye Date: Thu Jul 30 18:35:43 2026 +0800 xfrm: serialize state GC with device state flush commit 89fefad9f971bc637fb22373078144f2563c4be9 upstream. The deferred-device pass in xfrm_dev_state_flush() finds states under xfrm_state_dev_gc_lock, but drops the lock before calling xfrm_dev_state_free() because the driver callback may sleep. The device GC list does not hold an xfrm_state reference, so the state GC worker can destroy the same state concurrently. The race can proceed as follows: CPU 0 CPU 1 find x on the device GC list drop xfrm_state_dev_gc_lock read x->xso.dev xfrm_state_gc_destroy(x) xfrm_dev_state_free(x) xfrm_state_free(x) continue xfrm_dev_state_free(x) Both paths can invoke the driver callback and drop the device reference. CPU 0 can also access the xfrm_state after CPU 1 has freed it. KASAN reported: BUG: KASAN: slab-use-after-free in xfrm_dev_state_free+0x24c/0x2a0 Read of size 8 at addr ffff88810bbaa960 by task poc/102 Call Trace: xfrm_dev_state_free+0x24c/0x2a0 xfrm_dev_state_flush+0x353/0x400 xfrm_dev_event+0x26d/0x3a0 notifier_call_chain+0xc0/0x280 __dev_notify_flags+0x169/0x250 netif_change_flags+0xe7/0x160 dev_change_flags+0x96/0x220 devinet_ioctl+0x7f4/0x1880 Allocated by task 87: xfrm_state_alloc+0x1e/0x5c0 xfrm_add_sa+0xe7f/0x5820 xfrm_user_rcv_msg+0x4f3/0x940 Freed by task 57: kmem_cache_free+0xcb/0x3d0 xfrm_state_gc_task+0x4a8/0x650 process_one_work+0x63a/0x1070 Serialize xfrm_state destruction against the deferred-device pass with a mutex. Keep xfrm_state_dev_gc_lock limited to list operations and retain the existing callback and device-reference release ordering. Fixes: 07b87f9eea0c ("xfrm: Fix unregister netdevice hang on hardware offload.") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 99a6e4a9176da456904b67dcbae6e77d122782b7 Author: Alberto Carboneri Date: Fri Sep 4 13:54:37 2026 +0000 scsi: core: Validate MODE SENSE lengths in scsi_cdl_enable() commit 3d676e458fe0c566f5a62753dc696b6a862fc412 upstream. scsi_cdl_enable() uses length fields returned by MODE SENSE to locate the ATA feature mode page in a 64-byte stack buffer. A target can report a total length shorter than its mode header and block descriptors. The unsigned subtraction used for the MODE SELECT length can wrap, and the separately computed buf_data can point beyond buf. During automatic scan, enable is false, so the read-modify-write of buf_data[4] can clear the low two bits of a target-selected out-of-bounds stack byte. scsi_mode_select() can then copy up to 64 bytes from outside the buffer into the outgoing MODE SELECT payload, disclosing stack contents to the target. This is reachable while scanning a USB storage device that identifies as an ATA device and advertises CDL support. No filesystem mount or userspace access to the block device is required. On upstream commit cee9395acd80 ("Linux 7.3-rc1"), a build-specific, one-vCPU QEMU/Raw Gadget proof using QEMU-only multi-UDC allocator sampling executed a fixed proof command inside the guest and created a UID-0-owned marker during automatic enumeration, with KASLR and NX enabled. The issue was independently found during security research at Drivesec S.r.l. Cap the available length to the buffer size. Validate and consume the mode header and block descriptor lengths before using the page, and require the five bytes needed to access the CDL field. Fixes: 1b22cfb14142 ("scsi: core: Allow enabling and disabling command duration limits") Reported-by: Sashiko AI Review Closes: https://lore.kernel.org/linux-scsi/20260717192313.93D791F000E9@smtp.kernel.org/ Link: https://lore.kernel.org/linux-scsi/20260717222931.AC4EE1F000E9@smtp.kernel.org/ Link: https://lore.kernel.org/linux-scsi/df13ec87ac9b28e3b0a2d9eb26477e276ff0278a.camel@HansenPartnership.com/ Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Pimen Flavian Dei (Drivesec S.r.l.) Signed-off-by: Pimen Flavian Dei (Drivesec S.r.l.) Signed-off-by: Alberto Carboneri (Drivesec S.r.l.) Link: https://lore.kernel.org/linux-scsi/20260717192313.93D791F000E9@smtp.kernel.org/ Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/20260904135410.360314-1-acarboneri@drivesec.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit a0ff05906ebcaa1f5b56dbf74222a965595692cb Author: Mark Amirkan Date: Sun Sep 13 10:31:08 2026 +0000 net/packet: avoid truncating TPACKET_V3 private size commit 37213e61120297920ae4c937fcb326a360da5084 upstream. tpacket_req3.tp_sizeof_priv is an unsigned int, and packet_set_ring() validates the full value against the block size. init_prb_bdqc() then stores it in the unsigned short blk_sizeof_priv field. Commit 2b6867c2ce76 ("net/packet: fix overflow in check for priv area size") fixed the validation arithmetic, but an accepted value above USHRT_MAX still narrows when it is stored. For a 131072-byte block, tp_sizeof_priv=65536 is valid. The narrowing makes offset_to_first_pkt 48 instead of 65584, so packet records can be placed in the private area that userspace asked the kernel to preserve. blk_sizeof_priv is internal state, so widen it to hold the validated UAPI value. Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260913-b4-send-packet-private-v1-1-925eab2cd388@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 693209a237fc548791cf402441db8b68d1da7d38 Author: Mark Amirkan Date: Sun Sep 13 10:28:08 2026 +0000 net/packet: clear RX owner on VNET header error commit 33ff111d7ba3beb86e28938d6382bb5beabd865a upstream. Commit 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race condition") added rx_owner_map and made tpacket_rcv() claim a V1 or V2 ring slot before converting the virtio-net header. If the conversion fails, the drop path leaves the slot claimed. With a one-frame TPACKET_V2 ring, an unsupported UDP GSO packet leaves the only slot unavailable, so the ring also drops the next valid packet. Clear the ownership bit on this error path. TPACKET_V3 already clears its block state here. Fixes: 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race condition") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260913-b4-send-packet-vnet-v1-1-5545ffb528ae@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f6547d27ce2093c5627636fb63dd0b7523c466f9 Author: Jamal Hadi Salim Date: Sat Sep 12 14:09:19 2026 -0400 net/sched: hhf: cap hh_flows_limit at change time commit 2cef2588c995722a901368def30befeef9ae55c6 upstream. hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge hh_flows_limit lets each new heavy-hitter flow pass the hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory growth. Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the hhf_init() default) and report the rejected value via extack. The deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on TCA_OPTIONS. Configs relying on hh_limit above the default were relying on unbounded, unsafe behaviour and are not supported going forward. hhf_init() also ran hhf_change() before setting the default hh_flows_limit, so a user-supplied hh_limit at add time was clobbered back to 2048. Set the default before hhf_change() so the configured value sticks. This is a follow-up to commit eb56a495f59b ("net/sched: hhf: clamp quantum in change and init paths"), which bounded the quantum of the same qdisc; the hh_flows_limit bound is the remaining unbounded knob of that series' scope. Conditions to recreate the bug: CAP_NET_ADMIN in a user namespace; tc qdisc change dev X root hhf hh_limit 4294967295 succeeds and the value is echoed by tc qdisc show, unbounding heavy-hitter flow allocations; also tc qdisc add dev X root hhf hh_limit 500 stores 2048 instead of 500. Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Cc: stable@vger.kernel.org Reported-by: Sashiko (gemini) Closes: https://sashiko.dev/#/patchset/20260822195509.112717-1-jhs@mojatatu.com Reviewed-by: Victor Nogueira Tested-by: hybris Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-B855.v1.20260911153152@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 57b477e46ef2df3483f3488cc713c61c4b384aab Author: Xuanqiang Luo Date: Thu Sep 10 17:34:12 2026 +0800 net/sched: act_api: release tail references on DELACTION failure commit 6e05e46fa821a5c1b281355f1f622ac76cb6080a upstream. A batched RTM_DELACTION request takes a temporary reference on each action before attempting any deletion. tcf_action_delete() clears each processed slot and drops its temporary reference before attempting the deletion. If deletion fails, tca_action_gd() calls tcf_action_put_many() to release the remaining references, but its tcf_act_for_each_action() iterator stops at the first NULL slot. When a batch stops at an action bound to a filter, this leaks a reference on each subsequent action. A later delete of an unbound action can then return success without removing it from the IDR. Walk the full array in tcf_action_put_many() and skip NULL slots to release the references held on the unprocessed actions. Fixes: a0e947c9ccff ("net/sched: act_api: avoid non-contiguous action array") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260910093413.34509-2-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7e98216e9da08b79e07a514d2a4f7646f8c9ccb9 Author: Guanglei Zhu Date: Fri Sep 11 10:17:33 2026 +0800 net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value commit 31550d585589fde1ae95bf7f7a8188b2d2fdf1c7 upstream. mhi_mbim_rx() ignores the return value of skb_copy_bits() when it copies each datagram out of the NTB. The datagram offset and length come from the DPE, which is only checked to lie within the NTB itself, so a modem can point a datagram outside the received skb. The copy then fails and the freshly allocated skbn is passed to netif_rx() with its uninitialized contents still in place, leaking kernel heap memory into the network stack. Free the skb and account an error when the copy fails. Fixes: aa730a9905b7 ("net: wwan: Add MHI MBIM network driver") Cc: stable@vger.kernel.org Suggested-by: Loic Poulain Signed-off-by: Guanglei Zhu Signed-off-by: Greg Kroah-Hartman Verified in a QEMU guest with a fault injector pointing a DPE outside the received NTB: the copy fails, and the unpatched driver hands the uninitialized skbn to the network stack (observed as "unknown protocol" on bytes that were never written). With this check the failed datagram is dropped and counted as an rx error. Changes in v2: factor the free-and-count sequence out into mhi_mbim_rx_drop(), shared with the unknown-protocol path, as suggested by Loic Poulain. Link: https://patch.msgid.link/20260911021734.1396599-2-zhugl3@xiaopeng.com Signed-off-by: Jakub Kicinski commit 829fec45122da58d77a55a3b7ca514dafab98e77 Author: Guanglei Zhu Date: Fri Sep 11 10:17:32 2026 +0800 net: wwan: mhi_wwan_mbim: guard against a cyclic NDP chain commit 5d063822ac5184939c1ed377a339a01d8ae814e8 upstream. The NDP traversal in mhi_mbim_rx() only stops when wNextNdpIndex is zero. Nothing requires the offsets to advance, so a modem that points an NDP at itself, or at an earlier NDP, keeps the loop spinning forever on one CPU. Break out when the next NDP offset is not larger than the current one. Fixes: aa730a9905b7 ("net: wwan: Add MHI MBIM network driver") Cc: stable@vger.kernel.org Suggested-by: Loic Poulain Signed-off-by: Guanglei Zhu Signed-off-by: Greg Kroah-Hartman Verified in a QEMU guest with a fault injector feeding the driver's receive callback an NTB whose single NDP points at itself: the unpatched driver spins in mhi_mbim_rx() with one CPU pinned at 100% and the thread never returns. With this check the loop terminates within one iteration. Changes in v2: move the non-increasing check to the wNextNdpIndex retrieval site, as suggested by Loic Poulain, instead of tracking the previous offset in a separate variable. Link: https://patch.msgid.link/20260911021734.1396599-1-zhugl3@xiaopeng.com Signed-off-by: Jakub Kicinski commit d28aa2de9654e8024922775520a2665e00c04ad5 Author: Guanglei Zhu Date: Fri Sep 11 10:17:34 2026 +0800 net: wwan: t7xx: validate the netif index in t7xx_ccmni_recv_skb() commit c7ead9704249d57d4693a04697e3bbd285138fa9 upstream. The netif index carried in the DPMAIF PIT header is five bits wide, but ccmni_inst[] only has room for NIC_DEV_MAX (21) entries. t7xx_ccmni_recv_skb() indexes the array without a bounds check, so indexes 21 to 31 read past it. The out-of-bounds value lands in the callback table that follows the array, which is never NULL, so the existing !ccmni check does not catch it and the driver dereferences whatever sits there as a struct t7xx_ccmni. Drop the skb when the index is out of range. Fixes: 05d19bf500f8 ("net: wwan: t7xx: Add WWAN network interface") Cc: stable@vger.kernel.org Signed-off-by: Guanglei Zhu Signed-off-by: Greg Kroah-Hartman Verified in a QEMU guest with a fault injector setting the netif index to 25: the unpatched driver reads a value past ccmni_inst[], which lands in the callback table, and dereferences it far enough to queue the skb. With this check the packet is dropped. Well-formed traffic on index 0 is unaffected. Changes in v2: none. Link: https://patch.msgid.link/20260911021734.1396599-3-zhugl3@xiaopeng.com Signed-off-by: Jakub Kicinski commit 0ee66c62c4e91619d104278ed52b35deb415f18c Author: Ahmed Naseef Date: Sat Sep 12 17:43:06 2026 +0400 net: phy: mediatek: do not report link and per-speed LED rules together commit bde5212360bd44506edec073ebbd6d0c72f75820 upstream. mtk_phy_led_hw_ctrl_get() reports TRIGGER_NETDEV_LINK whenever any of the speed bits in on_set is on, and in addition reports every individual TRIGGER_NETDEV_LINK_* bit that is set. The netdev trigger refuses that combination: netdev_led_attr_store() rejects TRIGGER_NETDEV_LINK together with any per-speed rule, and it validates the whole resulting mode rather than just the bit being written. Once the hardware has any link bit programmed, every write to the trigger attributes of that LED therefore fails with -EINVAL and the LED can no longer be configured. The rules are also fed back into the hardware: the trigger stores what is read back, and a later write of device_name programs it again, expanding TRIGGER_NETDEV_LINK to every speed in on_set. An LED configured for a single speed is thereby silently widened to "on at any link speed". Both are easy to see on the EcoNet EN7528, whose four PHYs share one LED block. The first LED programs the block correctly, the second reads those rules back and rewrites them widened, and the remaining two then read the widened value, so an LED configured for "link_10 link_100" ends up lit on a 1000 Mbps link. on_set holds every speed the LED can indicate and is exactly what mtk_phy_led_hw_ctrl_set() programs for TRIGGER_NETDEV_LINK, so report the speed independent rule only when all of them are on, and the individual speeds otherwise. The mapping is then the inverse of the one used when programming the LED and round trips without changing the register. Fixes: c66937b0f8db ("net: phy: mediatek-ge-soc: support PHY LEDs") Cc: stable@vger.kernel.org Signed-off-by: Ahmed Naseef Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260912134306.3544329-1-naseefkm@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 161a403c8625e152de03d1da22bbf9cda6dc9f9f Author: Mark Amirkan Date: Sun Sep 13 17:14:09 2026 -0700 net: lan743x: fix RX checksum use-after-free commit a9ce4053dc945c5372dedba5017ee675b30dc0c5 upstream. lan743x_rx_process_buffer() adds each non-first receive buffer to the head skb's frag_list. On the last descriptor, lan743x_rx_trim_skb() linearizes the head and frees the fragment skb metadata. The checksum-success path then writes ip_summed through the local skb pointer, which still points to the final fragment. This causes a use-after-free write when a packet spans more than one receive buffer. Set ip_summed on the surviving head skb instead. Multi-buffer receive can occur after a live MTU increase because existing ring entries keep their old buffer size until they are replenished. A KUnit test invoking lan743x_rx_process_buffer() with a two-buffer packet produced a one-byte KASAN use-after-free write before this change. The same test passed after the change. The driver object also builds with W=1. This was not tested on physical LAN743x hardware. Fixes: cd6910501cfd ("net: lan743x: Add support for Rx IP & TCP checksum offload") Cc: stable@vger.kernel.org Signed-off-by: Mark Amirkan Reviewed-by: Chenguang Zhao Link: https://patch.msgid.link/20260913-b4-send-lan743x-uaf-v1-1-73d563d08ba9@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0f6a6beb01c068fcd5274eabf22c260039749fea Author: Gris Ge Date: Sun Sep 13 17:08:50 2026 +0800 net: ip_tunnel: initialize `options_len` before referencing options commit 455ebeadf714f51e1dbbd6a022c74c9215b1cd76 upstream. The following command triggers a kernel panic: ip link add d0 type dummy; ip link set d0 up ip route add 10.30.0.0/16 \ encap ip id 300 geneve_opts 4660:66:11223344 dev d0 memcpy: detected buffer overflow: 4 byte write of buffer size 0 kernel BUG at lib/string_helpers.c:1044! ... ip_tun_parse_opts.part.0.cold+0x10/0x10 ip_tun_build_state+0x116/0x2a0 On kernels built with GCC 15+ and `CONFIG_FORTIFY_SOURCE`, the fortified `memcpy()` got 0 sized destination with request of 4 bytes length: static int ip_tun_parse_opts_geneve(...) { ... attr = tb[LWTUNNEL_IP_OPT_GENEVE_DATA]; data_len = nla_len(attr); /* == 4 */ struct geneve_opt *opt = ip_tunnel_info_opts(info) + opts_len; memcpy(opt->opt_data, nla_data(attr), data_len); /* ^^^^^^^^^^^^^ 0 since options_len is assigned afterwards */ Fixed by initializing the counter before the options are referenced. Matching what `tunnel_key_opts_set()` already does. Fixes: bb5e62f2d547 ("net: Add options as a flexible array to struct ip_tunnel_info") Cc: stable@vger.kernel.org Signed-off-by: Gris Ge Reviewed-by: Hangbin Liu Reviewed-by: Gustavo A. R. Silva Link: https://patch.msgid.link/20260913090851.468216-1-cnfourt@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c21f3f7fbfeda7c5794f606cb0ffcc2d9001eef8 Author: Zhiling Zou Date: Mon Aug 3 21:28:58 2026 +0800 ipv6: xfrm: use full sockets in local error paths commit 6973a21ee73c5567f883813c8ef414774b45892f upstream. xfrm6_local_rxpmtu() and xfrm6_local_error() dereference skb->sk as if it always pointed at a full IPv6 socket. That is not guaranteed. TCP SYN-ACK skbs can be owned by a TCP_NEW_SYN_RECV request_sock while the output path itself is driven by the full listener. If rerouting selects an IPv6 XFRM tunnel route with a lower MTU, the local PMTU/error handling path can reach these callbacks with that mini-socket still attached to the skb. The callbacks then miscast the request socket as a full inet/IPv6 socket and can read beyond the request_sock allocation when they access inet_sock or ipv6_pinfo state. Resolve the owner with skb_to_full_sk() in both callbacks and bail out when no full socket is attached. This matches the surrounding XFRM IPv6 PMTU/error logic, which already reasons about full sockets with skb_to_full_sk(). Fixes: dd767856a36e ("xfrm6: Don't call icmpv6_send on local error") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit c383815568b6a465506486699bf5b27a6e338fc2 Author: David Hu Date: Tue Sep 1 17:08:49 2026 +0000 dma-buf: Split sgl by largest page-aligned chunk commit 06dd5e1ae8ce4e129791087c8c66594950f0ba03 upstream. Currently, `fill_sg_entry()` splits the scatterlist using `UINT_MAX`. This creates a non-page-aligned DMA length (`0xFFFFFFFF`) for the first entry, resulting in non-page-aligned DMA addresses for all subsequent entries. While the underlying IOMMU mapping may be contiguous, hardware DMA engines often require explicit address alignment (e.g., page, cacheline, or storage sector boundaries). Passing unaligned addresses and lengths can cause explicit failures in DMA descriptor creation or silent data corruption if lower unaligned bits are truncated. In addition, a non-page-aligned sgl length will trigger an edge case in `ib_umem_find_best_pgsz()`. In case of a discontinuity in later buffers, we will have a `va` with lowest bit set to 1. That will lead to `ib_umem_find_best_pgsz()` always return 0, and break the promise to find best page size for the mapping on the NIC side. Fix this by splitting the scatterlist by the largest possible page aligned chunk within `UINT_MAX` (`ALIGN_DOWN(UINT_MAX, PAGE_SIZE)`). This ensures all scatterlist DMA addresses and lengths remain page aligned, while minimizing the total number of sgl entries. Page-aligned entries allow the system to cleanly chunk payloads into PCIe MaxPayloadSize (MPS) (e.g., 128 bytes, 256 bytes, 512 bytes). As a result, this may help reduce TLP fragmentation in P2P transfers and alleviate potential congestion within a logical PCIe switch partition, especially when Relaxed Ordering is not possible due to hardware constraints. Reported-by: sashiko-bot Closes: https://lore.kernel.org/all/20260609165431.778061F00893@smtp.kernel.org/ Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable@vger.kernel.org Reviewed-by: Leon Romanovsky Signed-off-by: David Hu Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260901170849.4052816-3-dhu@x6u.co Signed-off-by: Greg Kroah-Hartman commit 6b98fd7106d4e486f432664893dcd4d6fa3a9693 Author: David Hu Date: Tue Sep 1 17:08:48 2026 +0000 dma-buf: Fix silent overflow for phys vec to sgt commit b344ca94e8cc85796f16ea25e2e5a8e0303fe813 upstream. In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `check_add_overflow()` for `nents` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable@vger.kernel.org Cc: iommu@lists.linux.dev Reviewed-by: Pranjal Shrivastava Reviewed-by: Kevin Tian Reviewed-by: Leon Romanovsky Signed-off-by: David Hu Signed-off-by: Christian König Link: https://lore.kernel.org/r/20260901170849.4052816-2-dhu@x6u.co Signed-off-by: Greg Kroah-Hartman commit a4db25b8949d6ff9c1a685a1273a015e8bab29db Author: Christian König Date: Fri Sep 4 10:26:13 2026 +0200 dma-buf/dma-fence: fix checking signaling bit for timeline and driver name v3 commit 3ed11c671ff7ec58c8fd96410233c677df23f407 upstream. The patch "dma-buf: dma-fence: Fix potential NULL pointer dereference" changed the check to test for the ops pointer instead of the signaled bit to avoid a potential NULL dereference when the ops pointer has been cleared. The problem is now that the ops pointer is cleared only when neither the release nor the wait callback is implemented and this isn't true for a lot of dma_fence implementations yet. So those implementations lost the RCU protection after signaling of the returned string resulting in potential use after free. Add the signaling check additional to the ops pointer check so that we have both the protection against NULL dereference as well as the RCU protection after signaling for the returned string. v2: improve comments to note RCU protection and explain why we check both signaling state and ops pointer v3: some comment improvements suggested by Philip Signed-off-by: Christian König Fixes: 035219a760ed ("dma-buf: dma-fence: Fix potential NULL pointer dereference") CC: stable@vger.kernel.org # 7.2+ Reported-by: Jonghyuk Kim(MalHyuk) Tested-by: Jonghyuk Kim(MalHyuk) Reviewed-by: Philipp Stanner Link: https://lore.kernel.org/r/20260914182740.1587-1-christian.koenig@amd.com Signed-off-by: Greg Kroah-Hartman commit 5b2d92b7b177226e1dca2e80dc8369131276c2a4 Author: Alexander Chesnokov Date: Wed Aug 12 08:34:26 2026 +0300 dmaengine: ti: k3-udma-glue: fix NULL dereference in k3_udma_glue_release_rx_chn() commit 0294b6dd515256c03ea2dbf508ddd3826d788579 upstream. If devm_kcalloc() for rx_chn->flows fails in a channel request function, the error path calls k3_udma_glue_release_rx_chn(), which dereferences the NULL rx_chn->flows pointer in k3_udma_glue_release_rx_flow(). Skip the flow release loop in k3_udma_glue_release_rx_chn() when rx_chn->flows is not allocated. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d70241913413 ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine users") Cc: stable@vger.kernel.org Reported-by: Pavel Zhigulin Signed-off-by: Alexander Chesnokov Reviewed-by: Frank Li Link: https://patch.msgid.link/20260812053426.3521589-1-Alexander.Chesnokov@kaspersky.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit e2c46d25c13b32a40ad5470bde7db993dd35b421 Author: Christian Lugnberg Date: Mon Aug 17 15:51:23 2026 +0200 dmaengine: sun6i: fix undefined behaviour in sun6i_dma_tx_status commit 9096bdc8d930147f7c39a493a859acbd3a8485d8 upstream. sun6i_dma_tx_status() calls vchan_find_desc() to look up the virtual descriptor for a given cookie, before checking whether the pointer vd is NULL: vd = vchan_find_desc(&vchan->vc, cookie); txd = to_sun6i_desc(&vd->tx); /* vd may be NULL here */ if (vd) { for (lli = txd->v_lli; ...) vchan_find_desc() returns NULL when the descriptor has already been completed or is in-flight on a physical channel and no longer present in the virtual channel's descriptor list. When vd is NULL, to_sun6i_desc() is called unconditionally on &vd->tx before the NULL check, which is undefined behaviour. Move the call inside the if (vd) guard to ensure it is only reached with a valid pointer. vd = vchan_find_desc(&vchan->vc, cookie); if (vd) { struct sun6i_desc *txd = to_sun6i_desc(&vd->tx); for (lli = txd->v_lli; ...) Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Christian Lugnberg Reviewed-by: Frank Li Link: https://patch.msgid.link/20260817135723.12807-3-christian.lugnberg@soundtrack.io Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 9eb91f821db98fa954ed4c5a4c6085bfc86907ca Author: Christian Lugnberg Date: Mon Aug 17 15:51:22 2026 +0200 dmaengine: sun6i: fix non-atomic read of DMA position registers commit c90b6973daa37f4c283342dff881ae001dea4fe6 upstream. sun6i_get_chan_size() reads DMA_CHAN_LLI_ADDR and DMA_CHAN_CUR_CNT in two separate readl() calls with no synchronisation between them: pos = readl(pchan->base + DMA_CHAN_LLI_ADDR); bytes = readl(pchan->base + DMA_CHAN_CUR_CNT); DMA_CHAN_LLI_ADDR holds the physical address of the *next* descriptor the engine will load once the current one completes. DMA_CHAN_CUR_CNT holds the remaining byte count for the *current* descriptor. If the DMA engine advances to the next LLI entry between the two reads, pos becomes stale: it still points to what was the next descriptor at the time of the first read, but that descriptor is now the current one and CUR_CNT reflects its initial (full) byte count. The subsequent virtual-chain walk starts one entry too early and accumulates an extra full period's worth of bytes into the residue estimate. Fix this by re-reading DMA_CHAN_LLI_ADDR after DMA_CHAN_CUR_CNT and retrying if the value changed. This double-read pattern guarantees that both registers were sampled during the same descriptor interval. The cost is at most one extra readl() pair per call in the racy case, which occurs only at descriptor boundaries (~every 2 ms) and is negligible. Fixes: a90e173f3faf ("dmaengine: sun6i: Add cyclic capability") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Christian Lugnberg Reviewed-by: Frank Li Link: https://patch.msgid.link/20260817135723.12807-2-christian.lugnberg@soundtrack.io Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 877bfe1b236d4ec44d983aeca9c33f7b769a1bb4 Author: Abdurrahman Hussain Date: Sat Aug 15 13:44:19 2026 -0700 gpiolib: of: don't mark hog nodes OF_POPULATED before a chip is found commit 1f1d0812f6a8ab8e6f709c599f137c99646512cc upstream. When a gpio-hog node is attached by a device-tree overlay before its parent GPIO chip has been registered, of_gpio_notify() sets OF_POPULATED on the node via of_node_test_and_set_flag() and only then discovers that there is no gpio_device for the parent, returning NOTIFY_DONE without clearing the flag. Since gpiochip_hog_lines() skips any hog child whose of_node carries OF_POPULATED, the leaked flag makes the hog silently ignored when the chip is registered later. Applying an overlay containing both a GPIO controller node and its hog children - and populating devices only after the overlay apply completes - hits this on every boot; the hog is only applied if the chip driver is unbound (which clears the flag in the remove path) and rebound. Look up the parent gpio_device before claiming the node so that a hog attached ahead of its chip stays unclaimed and is picked up normally by gpiochip_hog_lines() at registration time. Signed-off-by: Abdurrahman Hussain Fixes: a23226b7c1f6 ("gpiolib: handle gpio-hogs only once") Cc: stable@vger.kernel.org Reviewed-by: Daniel Drake Link: https://patch.msgid.link/20260815-gpiolib-of-hog-flag-leak-v1-1-6126aac5f6f3@nexthop.ai Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 274c73769bc13c7dffacbfa8246c67e4e27999a5 Author: Michail Tatas Date: Thu Aug 13 20:36:50 2026 +0300 gpiolib: Put fwnode reference on failure commit 16b10f64c63f78220c3b4035f1ed6cd3bdcb0b02 upstream. We get a reference to the fwnode handle which we pass to gpio_shared_make_ref. In case it fails we do not put the reference. Fix by putting the reference in the failure case Fixes: 49416483a953 ("gpio: shared: allow sharing a reset-gpios pin between reset-gpio and gpiolib") Cc: stable@vger.kernel.org Signed-off-by: Michail Tatas Link: https://patch.msgid.link/an4Asr4tx3D2QvLD@michalis-linux Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit b1df2997d0cd2be7bef7b4ab64ccfd1019dedc81 Author: Guanghui Yang <3497809730@qq.com> Date: Wed Sep 16 05:16:38 2026 +0000 btrfs: clear free space tree creation state on rebuild failure commit 3565893cc72cdf6b795cf6a33e7ff9605322334d upstream. btrfs_rebuild_free_space_tree() sets BTRFS_FS_CREATING_FREE_SPACE_TREE before rebuilding the free space tree. Several error paths return without clearing this flag. The transaction restart failure path can leave the flag set on a live filesystem, causing delayed reference processing to be skipped. Clear it on all free space tree rebuild failure paths. Keep BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED set, since a failed rebuild leaves the free space tree untrusted. Callers must fall back to extent-tree caching. Fixes: 882af9f13e83 ("btrfs: handle free space tree rebuild in multiple transactions") CC: stable@vger.kernel.org # 6.14+ Assisted-by: LLM Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Guanghui Yang <3497809730@qq.com> Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 5132f05d3c7b3c164a935e20465fdff19797f19e Author: Anand Jain Date: Sun Sep 13 02:06:28 2026 +0800 btrfs: derive f_fsid with dev_t only when temp_fsid is active commit 72de4807ba84da485dda1a91572d66da9149e95a upstream. Commit c2a74ed0494c ("btrfs: derive f_fsid from on-disk fsid and dev_t") mixed dev_t into f_fsid for all single-device setups to avoid f_fsid collisions with cloned filesystems. However, doing this unconditionally breaks backward compatibility. statfs(2) f_fsid changes after a kernel upgrade, and also can shift across reboots or dev re-attaches as dev_t values change. Fix this by only mixing dev_t when temp_fsid is active. This means for non-temp_fsid setups or the original mount, we use the old method of deriving fsid based on the UUID. So in the case of a cloned Btrfs filesystem, we won't be able to maintain the same fsid across mount recycle if the mount order changes. Reported-by: Dave Hansen Link: https://lore.kernel.org/linux-btrfs/be0c08f5-2f31-40f5-8a3b-f2f58b3e00ff@intel.com Fixes: c2a74ed0494c ("btrfs: derive f_fsid from on-disk fsid and dev_t") CC: stable@vger.kernel.org # 7.2 Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 93dd8226e59873fc518aee4c7a24650b33c33d63 Author: Filipe Manana Date: Mon Sep 14 18:11:30 2026 +0100 btrfs: fix creation of compressed inline extents that don't save space commit cc337324cc6be1ce0ae7e5a068dcb7e99ae1b59c upstream. If the compressed data of an inline extent is larger than or equals to the size of the uncompressed data, we are still allowing the creation of the compressed inline extent, which does not result in any benefits, quite the contrary as we waste metadata space and have to decompress when reading. This is a recent regression introduced in commit 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper"). It happens because we are passing the block size to btrfs_compress_bio(), so we don't get -E2BIG from the compression code anymore, but we can not pass i_size either, because if i_size is smaller than sector size, we end up never creating lzo compressed inline extent for such small i_size values. So refuse the compressed result at run_delalloc_inline() if its size is not smaller than the uncompressed size (i_size). Reported-by: Hanabishi Link: https://lore.kernel.org/linux-btrfs/c97652a5-ac6b-4de6-aa23-3cdebc01d00b@gmail.com/ Fixes: 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper") CC: stable@vger.kernel.org # 7.1+ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c32490c6d3f3a9f2d177d57c7eb8bbc347561d08 Author: Hongling Zeng Date: Mon Aug 31 13:38:01 2026 +0800 btrfs: take commit root semaphore when iterating in mark_block_group_to_copy() commit 0594e3423f4ba3137c734371169491f9a98e9af4 upstream. mark_block_group_to_copy() iterates over the commit root with skip_locking=true. A concurrent transaction commit can swap and free the commit root during iteration, causing use-after-free when accessing extent buffers. Fix it by using path->need_commit_sem to protect the commit root search. Fixes: 78ce9fc269af ("btrfs: zoned: mark block groups to copy for device-replace") CC: stable@vger.kernel.org Assisted-by: Codex:gpt-5.5 Reviewed-by: Johannes Thumshirn Signed-off-by: Hongling Zeng Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit aae553129ff7ad38bf478935fbf63b68fe20e30f Author: Radek Podgorny Date: Sun Sep 13 22:28:02 2026 +0200 Bluetooth: keep dst_type with dst when reusing an LE connection commit 555cd2bd860e7c4bdc3f4e4405b05515b0d9bc87 upstream. hci_connect_le() swaps the caller's identity address for the peer's cached RPA when one is known, and stamps the matching ADDR_LE_DEV_RANDOM on the local dst_type. On the conn-reuse path only the address is copied into the connection: if (conn) { bacpy(&conn->dst, dst); so conn->dst ends up holding an RPA while conn->dst_type still names the identity it was resolved from, and hci_le_create_conn_sync() puts that pair on air unchanged. An RPA declared as a public address is not something any peer can answer. Measured on a CYW43438 against a peer advertising an RPA the host holds the IRK for, connecting to the identity address over a raw L2CAP socket. The first attempt creates the connection, the second takes the reuse path: LE Create Connection 3C:78:95:78:37:C3 type public LE Create Connection 5B:75:A2:26:D6:18 type public LE Connection Complete: Unknown Connection Identifier (0x02) The second address is the peer's RPA. btmon annotates it with an OUI lookup rather than "(Resolvable)" precisely because the command declares it public; the same bit pattern annotates as resolvable once the type is right. The mistyped pair is also why nothing downstream repairs it. hci_bdaddr_is_rpa() tests the type before the address, so an RPA carrying a public type is not recognised as one, and hci_find_irk_by_addr() then searches for an identity address that does not match it either. Copy the type along with the address. The assignment used to be unconditional just below this block and covered both paths; it moved into hci_conn_add_unset(), which the reuse path does not go through. Cc: stable@vger.kernel.org Fixes: 14b06c3a88f7 ("Bluetooth: HCI: Always use the identity address when initializing a connection") Assisted-by: Claude:claude-opus-5 Signed-off-by: Radek Podgorny Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 1276c2fafd18499769a28f96f45c5a76d6fc990e Author: Chengfeng Ye Date: Sat Aug 22 01:43:50 2026 +0800 Bluetooth: hci_sync: Serialize local codec list cleanup commit 9a10987a2f160a44a638c9a35994ca6e3089696e upstream. hci_dev_close_sync() clears hdev->local_codecs after releasing hdev->lock. Codec list additions and both traversals in sco_sock_getsockopt() use that lock, but the close path does not. A close and BT_CODEC query can therefore interleave as follows: hci_dev_close_sync() sco_sock_getsockopt() hci_dev_lock() fetch codec entry hci_codec_list_clear() kfree(entry) read entry->id The reader then accesses an entry which the close path has freed. KASAN reported: BUG: KASAN: slab-use-after-free in sco_sock_getsockopt+0xfa0/0xfe0 Read of size 1 at addr ffff8881001c3450 Call Trace: sco_sock_getsockopt+0xfa0/0xfe0 do_sock_getsockopt+0x537/0x7b0 __sys_getsockopt+0xf2/0x170 Allocated by task 92: hci_codec_list_add.isra.0+0x2c/0x440 hci_read_codec_capabilities+0x224/0x590 hci_read_supported_codecs+0x2c2/0x640 Freed by task 92: kfree+0x131/0x3c0 hci_codec_list_clear+0xd8/0x160 hci_dev_close_sync+0x92a/0xfa0 Take hdev->lock around the clear operation at its existing point in the close path. This makes the clear wait for active readers and prevents a new traversal until the list is empty without changing teardown ordering. Fixes: b938790e7054 ("Bluetooth: hci_codec: Fix leaking content of local_codecs") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 12a82819b0cada6e304790b1097f8f9006eb6123 Author: Laxman Acharya Padhya Date: Mon Aug 24 21:42:36 2026 +0545 Bluetooth: hci_codec: validate vendor codec count length commit d0795cfd6f655f4de84868a4f4bb41a03f037b3d upstream. The Read Local Supported Codecs parsers consume the variable-sized standard codec array before parsing the vendor codec count. Although the initial reply-size check includes a vendor count byte in the fixed layout, it does not guarantee that the byte remains after the standard codec array. If a controller reply ends immediately after that array, calculating the vendor codec array size reads vnd_codecs->num beyond the skb data. Use skb_pull_data() to validate and consume each codec header before using its count in both command variants. Fixes: 8961987f3f5f ("Bluetooth: Enumerate local supported codec and cache details") Fixes: 9ae664028a9e ("Bluetooth: Add support for Read Local Supported Codecs V2") Cc: stable@vger.kernel.org Suggested-by: Luiz Augusto von Dentz Signed-off-by: Laxman Acharya Padhya Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 2e4f594a2baee9a0fb28043843aa269aaa4cd0dd Author: Aamir Ahmed Date: Mon Sep 7 00:37:43 2026 +0100 Bluetooth: eir: validate service data length before reading UUID commit e8241766794cf551d787fa3a77c0d54bbea6f6aa upstream. eir_get_service_data() reads a 16-bit UUID from the service data using get_unaligned_le16() without first checking that the data is long enough to hold a UUID16 (2 bytes). If a malformed EIR entry has a service data field with only 1 byte of payload (field_len=2), eir_get_data() returns dlen=1. The subsequent get_unaligned_le16() then reads 1 byte past the field boundary. Additionally, if the corrupted UUID happens to match, the length calculation "dlen - 2" underflows to SIZE_MAX since dlen is size_t. Current callers either pass NULL for the length parameter or bounds-check the returned length, but future callers may not. Add a check that dlen >= sizeof(u16) and skip fields that are too short to contain a valid UUID16. Fixes: 8f9ae5b3ae80 ("Bluetooth: eir: Add helpers for managing service data") Cc: stable@vger.kernel.org Signed-off-by: Aamir Ahmed Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit e34ec86ee02474dcb4b331c2179ba8f9dc2c7a7c Author: Nicolas Thibert Date: Tue Sep 8 10:01:08 2026 +0200 Bluetooth: btusb: fix NXP IW610 composite device handling commit 2b50adefed9808a56d84d1de803cad882cc787fa upstream. The NXP IW610 module exposes itself as a composite USB device (0471:0215) with three interfaces: two real Bluetooth HCI interfaces (class 0xe0) and one vendor-specific WiFi interface (class 0xff) used by mwifiex-nxp. The composite device's whole USB descriptor reports class 0xe0/01/01 (Bluetooth), so btusb_table's generic USB_DEVICE_INFO(0xe0, 0x01, 0x01) entry matches every interface, not just the two real HCI ones -- btusb ends up binding the WiFi interface too, and mwifiex-nxp never gets it. Fix: 1. In btusb_table (the table the USB core actually matches against), explicitly ignore the WiFi interface via BTUSB_IGNORE, ahead of the generic entry. 2. In quirks_table, scope the existing BTUSB_MARVELL entry to the BT interface class instead of matching the whole device by VID/PID (harmless either way since quirks_table isn't consulted for initial binding, but keep it correct). Not upstream anywhere: checked NXP's own i.MX kernel fork (nxp-imx/linux-imx), no IW610 references in btusb.c on any branch -- their reference designs wire this chip differently (WiFi over SDIO per their release notes), so they never hit this. Signed-off-by: Nicolas Thibert Cc: stable@vger.kernel.org Assisted-by: LLM (Claude Sonnet 5, Anthropic) Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 843ace1d0a39e9b1cfcbfb3856a7b0fbdd9cd003 Author: Mark Rutland Date: Tue Sep 8 16:17:23 2026 +0100 arm64: percpu: Fix LSE operations on {8,16}-bit types commit 8cf2093f5372952a9ebc805c418d45df7112cd14 upstream. The assembly for __percpu_##name##_case_##sz() and __percpu_##name##_return_case_##sz() doesn't use the 'sfx' macro argument to form the LSE instruction. Without 'sfx', a W register argument will imply a 32-bit memory location, and consequently {8,16}-bit ops will erroneously read and write 32 bits of memory when the LSE instruction is used. Fix this by appending 'sfx' to 'op_lse' to LSE instruction. It is not necessary (and not valid) to append 'sfx' to 'op_llsc', as 'op_llsc' is a register-register operation which does not access memory (and does not take a size suffix). Fixes: 959bf2fd03b5 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics") Signed-off-by: Mark Rutland Reviewed-by: Jinjie Ruan Cc: Ada Couprie Diaz Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: James Morse Cc: Marc Zyngier Cc: Peter Zijlstra Cc: Vladimir Murzin Cc: Will Deacon Cc: Yang Shi Cc: stable@vger.kernel.org Reviewed-by: Vladimir Murzin Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 39c1cfbe9b1e9f8a2b1baecbaf11a8163be57e9b Author: Mark Rutland Date: Tue Sep 8 16:17:22 2026 +0100 arm64: percpu: Fix this_cpu_and() mask generation commit 44274c657256b4911de82f8104e9e22f054cf742 upstream. The arm64 implementation of this_cpu_and(pcp, val) is built in terms of ANDNOT operations, which requires the 'val' argument to be bitwise negated. The bitwise negation is not implemented correctly, with two bugs described below. (1) The bitwise negation is performed as '~val' rather than '~(val)'. This won't always generate the expected value when 'val' is an expression. For example, for this_cpu_and(pcp, 1 - 1): * 'val' is '1 - 1' ===> (int) 0x00000000 * '~val' is '~1 - 1' ===> (int) 0xfffffffd * '~(val)' is '~(1 - 1)' ===> (int) 0xffffffff ... and thus bit[1] of 'pcp' would be preserved unexpectedly by the ANDNOT operation. (2) The bitwise negation is performed on 'val' before it has been cast to (at least) the width of 'pcp'. This won't always generate the expected value for the upper bits. For example, for this_cpu_and(pcp, zero), where 'pcp' is a u64 and 'zero' is a u32: * 'zero' ===> (u32) 0x00000000 * '~(zero)' ===> (u32) 0xffffffff * '(u64)~(zero)' ===> (u64) 0x00000000ffffffff * '~((u64)(zero))' ===> (u64) 0xffffffffffffffff ... and thus bits[63:32] of 'pcp' would be preserved unexpectedly by the ANDNOT operation. Fix these issues by adding brackets around 'val', and by casting 'val' to an appropriately-sized type before bitwise negation. Fixes: 959bf2fd03b5 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics") Signed-off-by: Mark Rutland Reviewed-by: Jinjie Ruan Tested-by: Muhammad Usama Anjum Acked-by: Christopher Lameter (Ampere) Cc: Ada Couprie Diaz Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: James Morse Cc: Marc Zyngier Cc: Peter Zijlstra Cc: Vladimir Murzin Cc: Will Deacon Cc: Yang Shi Cc: stable@vger.kernel.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 2f85540c561a4443aed17aefa82266a7a07bcf84 Author: Mark Rutland Date: Tue Sep 8 16:17:21 2026 +0100 arm64: percpu: Fix this_cpu_write() casting commit 885bff055a0f251a51a0d4fd4f0a7b525582a3de upstream. The arm64 implementation of this_cpu_write() casts 'val' to unsigned long. This is necessary to handle cases where 'val' is a pointer type, and to avoid spurious compiler warnings for the (unreachable!) cases where the pointer type would be cast to a smaller integer type. Unfortunately, the cast is applied to 'val' rather than '(val)', which won't always generate the expected value when 'val' is an expression. For example, for this_cpu_write(pcp, zero - 1), where 'pcp' is a u64 and 'zero' is a u32: * 'zero' ===> (u32) 0x00000000 * 'zero - 1' ===> (u32) 0xffffffff * '(unsigned long)zero - 1' ===> (u64) 0xffffffffffffffff * '(unsigned long)(zero - 1)' ===> (u64) 0x00000000ffffffff Fix this by adding brackets around 'val'. Fixes: 959bf2fd03b5 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics") Reported-by: David Laight Signed-off-by: Mark Rutland Reviewed-by: David Laight Reviewed-by: Jinjie Ruan Tested-by: Muhammad Usama Anjum Acked-by: Christopher Lameter (Ampere) Cc: Ada Couprie Diaz Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: James Morse Cc: Marc Zyngier Cc: Peter Zijlstra Cc: Vladimir Murzin Cc: Will Deacon Cc: Yang Shi Cc: stable@vger.kernel.org Reviewed-by: Lorenzo Stoakes (ARM) Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit cc32bef6f7fea2d727533efdd56a298f88217225 Author: Dinh Nguyen Date: Fri Aug 28 10:31:29 2026 +0800 arm64: dts: socfpga: change access permission from 755 to 644 commit 5f8cb07d7a8573753c5d31dc76b51cab8e5e9460 upstream. These files have an incorrect access permission of 755 instead of 644. Change them to the correct access permission of 644. Fixes: 4bc04eb90b7c ("arm64: dts: socfpga: stratix10: Add emmc support") Cc: # v7.1+ Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit e94f9c07ced312cafa13dae2dea6523558997749 Author: Koichiro Den Date: Fri Sep 11 16:30:58 2026 +0900 arm64: dts: renesas: r8a779f0: Set UFS lane count commit 8dc2615d5702059b2b71fca6f93c0d7d10ae54cb upstream. Since commit e72323f3b09f ("scsi: ufs: core: Configure only active lanes during link"), the following error is observed on R-Car S4: ufshcd-renesas e6860000.ufs: Tx lane mismatch [config,reported] [2,1] ufshcd-renesas e6860000.ufs: link startup failed -67 ufshcd-renesas e6860000.ufs: error -ENOLINK: Initialization failed with error -67 ufshcd-renesas e6860000.ufs: probe with driver ufshcd-renesas failed with error -67 R-Car S4 has one UFS lane per direction, as described in section 152.1 of its hardware manual. Without lanes-per-direction, the UFS platform driver defaults to two lanes. Previously, the core used PA_CONNECTEDRXDATALANES and PA_CONNECTEDTXDATALANES to configure the link without checking them against lanes-per-direction, so the missing property did not prevent initialization. Explicitly set lanes-per-direction to 1, now that the validation is in place. Fixes: 5235d551779d ("arm64: dts: renesas: r8a779f0: Add UFS node") Cc: stable@vger.kernel.org # 7.2+ Signed-off-by: Koichiro Den Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260911073058.253000-1-den@valinux.co.jp Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit d3f8f773312af69eaf4dda106d76d6d42e4362e5 Author: Bradley Morgan Date: Sun Aug 9 21:36:15 2026 +0000 arm64: hibernate: pass HVC_SET_VECTORS args to the resume hvc commit 955d86e5f3b95b731991fdb84966c50b16314629 upstream. swsusp_arch_suspend_exit() reinstalls the restored kernel's hyp stub vectors with an hvc, but never passes the arguments. x0 is not set to HVC_SET_VECTORS and x1 is not set to the vector address, so the stub dispatch falls through and returns without writing vbar_el2. EL2 is left pointing at the trans_pgd copy of the vectors, a page that swsusp_free() releases right after resume. Set the arguments up the same way __hyp_set_vectors() does. Without this fix, Vladimir was able to trigger a hang when resuming from hibernation with CONFIG_PAGE_POISONING=y and page_poison=on. Fixes: 788bfdd97434 ("arm64: trans_pgd: hibernate: Add trans_pgd_copy_el2_vectors") Cc: stable@vger.kernel.org Signed-off-by: Bradley Morgan Reviewed-by: Vladimir Murzin Tested-by: Vladimir Murzin Acked-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 502130544a899b3fc2a975643825c0e45840f3a0 Author: Thomas Huth Date: Wed Sep 9 17:57:07 2026 +0200 kselftest/arm64: Fix size of thread_data values for pthread_join() commit 3d1ba5cbfb622025690c218d8f20da92a9ecb383 upstream. pthread_join() stores the thread's return value (a "void *", i.e. 8 bytes on 64 bit computers) into the address that is passed as second parameter. However, the entries of thread_data are only normal "int"s, i.e. only 4 bytes. The additional 4 bytes of the return value clobber whatever is adjacent on the stack, i.e. other members of the thread_data array (which will be re-written in the next iteration of the for-loop, so that nobody noticed this problem), or another other local variable on the stack for the last iteration. Use "intptr_t" to declare the thread_data array entries with the correct size. Fixes: 29f080881601c ("kselftest/arm64: check GCR_EL1 after context switch") Cc: stable@vger.kernel.org Signed-off-by: Thomas Huth Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 206f396f46149dc8bc4dfd2b54b9879ba3ee1d7d Author: Wyatt Feng Date: Sat Aug 29 23:44:32 2026 +0800 net: xfrm: reject unrepresentable espintcp transport headers commit 96f01b53c2d05e003b040892256de54a586e8529 upstream. ESP-in-TCP can hand xfrm packets whose transport header offset no longer fits after the stream parser trims the TCP envelope. The plain transport header reset truncates that offset and triggers the skb warning path. Use the careful transport-header helper and drop the skb through the existing XFRM error path when the offset cannot be represented. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 30335038d4e25cf017abb0562f4f4eace4f58f96 Author: Jeff Layton Date: Tue Apr 14 07:18:05 2026 -0700 nfsd: fix handling of NFSEXP_PNFS in the netlink codepath commit f76017a7663c4ce5e379f8a8d39f032bdb1fd865 upstream. The rework of how block layouts were checked moved the check for NFSEXP_PNFS out of nfsd4_setup_layout_type() and into the callers. That patch didn't account for the new call in nfsd4_setup_layout_type(). Cc: Christoph Hellwig Fixes: da9baa5470dc ("exportfs,nfsd: rework checking for layout-based block device access support") Cc: stable@vger.kernel.org Reported-by: Olga Kornievskaia Signed-off-by: Jeff Layton Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260414-pnfs-exp-fix-v1-1-9face14c16c2@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 8c9fcc6c33950d3db551af664d1fd3d998bfee56 Author: Zhiling Zou Date: Sat Sep 12 21:22:43 2026 +0800 openvswitch: avoid reallocating confirmed conntrack labels commit 3f118c8217c109fd13ca61caa301d72c483897ef upstream. ovs_ct_get_conn_labels() adds the labels extension when a conntrack entry does not have one. Confirmed conntracks can be read locklessly, so adding an extension may reallocate and free the extension block while another CPU accesses it. Only add the extension for unconfirmed conntracks. A confirmed conntrack without labels now fails the caller's label operation instead of reallocating its extension storage. Fixes: c2ac66735870 ("openvswitch: Allow matching on conntrack label") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Reviewed-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/372fbb062b40ae6723684f55484be86ff0064f8e.1789218015.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 117871cdb8927542abd7b65ce5995bf0265a8c05 Author: Jeffin Philip Date: Fri Sep 4 18:44:37 2026 +0530 RDMA/core: fix refcount bug in iwpm_get_nlmsg_request() commit 33fb59da49c4c3f5c2ec9f9d4447a56857a02c02 upstream. iwpm_get_nlmsg_request() initializes refcount _after_ list_add_tail() making it accessible to global list where another CPU can kref_get() on nlmsg_request causing a refcount "addition on 0" bug. Fix this by initializing kref _before_ list_add_tail() so refcount for nlmsg_request can be incremented/decremented normally. In addition, also initialize every field before list_add_tail(). Reported-by: syzbot+bd317784d628820741b5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bd317784d628820741b5 Fixes: 30dc5e63d6a5 ("RDMA/core: Add support for iWARP Port Mapper user space service") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip Link: https://patch.msgid.link/20260904131437.12917-1-jeffinphilip14@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 83610ee5e498fa5bfcb80031d2b959baea276bf6 Author: Quanye Yang Date: Mon Aug 31 20:30:58 2026 +0800 RDMA/ucma: Serialize join and leave on copy_to_user failure commit 662ade4de9ff5eceb0820a9f8e9fac70ba6a815b upstream. rdma_join_multicast() queues RoCE work that later reads the ucma_multicast through event->param.ud.private_data, then list_add()s the CMA multicast at the head of id_priv->mc_list. rdma_leave_multicast() matches only by sockaddr and destroys the first hit. ucma_process_join() used to drop ctx->mutex after a successful join and retake it only if copy_to_user() failed. Two concurrent JOIN_MCAST calls with the same address can therefore insert a second CMA entry before the first thread's leave. leave then cancels the newer work and the older worker still dereferences the ucma_multicast that the first thread frees. Keep ctx->mutex held from rdma_join_multicast() through copy_to_user() and, on -EFAULT, through rdma_leave_multicast() so leave cannot miss this join. Do not leave if join itself failed: that path never published this address on mc_list, and a leave-by-addr would destroy an earlier successful join. Reported-by: syzbot+a6ffe86390c8a6afc818@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a6ffe86390c8a6afc818 Fixes: fe454dc31e84 ("RDMA/ucma: Fix use-after-free bug in ucma_create_uevent") Cc: stable@vger.kernel.org Signed-off-by: Quanye Yang Link: https://patch.msgid.link/20260831-rdma-ucma-mc-uaf-v1-1-b8eeb7046aff@proton.me Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit e06c431afd269c2779aa73e6c9fd9aa0b91c3a3e Author: Hao-Qun Huang Date: Sun Sep 13 03:20:49 2026 +0800 spi: virtio: Use the per-transfer bits per word commit 095858324f063dba830041f067872f0a08765d2f upstream. virtio_spi_transfer_one() puts spi->bits_per_word into the request header, so a transfer that sets its own word size reaches the backend with the device default instead. The SPI core has already copied that default into xfer->bits_per_word when the transfer leaves it at zero, the same way it does for xfer->speed_hz, which this function already uses. Per-transfer word sizes are ordinary SPI usage. mipi_dbi, for one, sends a 9-bit command and reads the reply as 8-bit data in the same message. With a 16-bit device default, a one-byte transfer asking for 8 bits goes out as a partial 16-bit word, which the backend may reject. Fixes: f98cabe3f6cf ("SPI: Add virtio SPI driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Hao-Qun Huang Link: https://patch.msgid.link/20260913032049.11209.alvinhuang0603@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2c9baaf03e9d3939644a1add485887a8189da2d5 Author: Itai Handler Date: Thu Sep 10 20:48:32 2026 +0300 spi: spi-zynqmp-gqspi: stop the controller on shutdown commit e922bad8b2d5028c51a096d083fea41cd0987154 upstream. The driver has no ->shutdown, and platform_drv_shutdown() has no fallback of its own. Unlike pci_device_shutdown(), which clears bus mastering when kexec_in_progress, nothing on the platform bus disarms a device that can still write to memory. The normal kexec path never calls ->suspend either, so the quiesce in zynqmp_qspi_suspend() is not reached. A controller that is still executing a DMA read may therefore keep writing to memory across a kexec. QSPIDMA_DST_ADDR still points at memory owned by the kernel that called kexec, DST_SIZE is non-zero and the flash is still clocked, so data can keep landing in RAM while the new kernel is being relocated, and after it has started executing. That destination is a physical address which means nothing to the new kernel, so the writes can corrupt whatever now occupies it: kernel text or data, page tables, or the initrd. Nothing reports an error and the resulting behaviour is undefined. This can be observed by reading GQSPI_EN (offset 0x114) and QSPIDMA_DST_ADDR/SIZE/STS/CTRL (offsets 0x800 to 0x80c) early in the new kernel, before the driver probes: without this patch GQSPI_EN reads 1 and QSPIDMA_DST_ADDR still points into the previous kernel's memory. Add a ->shutdown that stops the controller the way zynqmp_qspi_suspend() already does. spi_controller_suspend() stops the queue, waits for a message that is already executing and makes any later transfer fail with -ESHUTDOWN, so nothing can be cut short by the register write that follows. It may sleep, which is fine here: device_shutdown() runs in process context. Unlike ->suspend this cannot abort on error, because a controller left mastering the bus is worse than a truncated transfer, so a failure to drain is only logged. GQSPI_EN_OFST is then cleared, as zynqmp_qspi_remove() and zynqmp_qspi_suspend() already do. Skip that write only when pm_runtime_get_if_in_use() returns 0, i.e. runtime suspended: the clocks are gated, so the registers are unreachable and the controller cannot be mastering the bus. A negative return is not the same thing - it is what the CONFIG_PM=n stub always returns, and there probe() has enabled pclk and refclk for good, so the controller is running and must be stopped. Fixes: dfe11a11d523 ("spi: Add support for Zynq Ultrascale+ MPSoC GQSPI controller") Cc: stable@vger.kernel.org Signed-off-by: Itai Handler Link: https://patch.msgid.link/20260910174832.873352-1-itai.handler@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit bf3e3ba6dd54679a720379ec3c4202a821eb3b20 Author: Frieder Schrempf Date: Thu Sep 17 16:10:15 2026 +0200 spi: fsl-qspi: Reprogram the clock rate when the operation frequency changes commit 3d743adf090cd4c9a2120c1e02b0482e88aa0d2d upstream. fsl_qspi_select_mem() returns early when the chip select has not changed, which happens before it reaches clk_set_rate(). Since the rate is now taken from the spi-mem operation rather than from the SPI device, the controller honours op->max_freq exactly once per chip select and ignores it for every operation after that. q->selected is only reset to -1 in fsl_qspi_default_setup(), i.e. at probe and on resume, so on the common single chip select board the very first operation latches a rate that all subsequent operations inherit, whatever frequency they asked for. This results in operations being issued with the wrong frequency. Cache the operation frequency the clock was programmed for next to the selected chip select, and redo the clock setup when either changes. Fixes: 2438db5253eb ("spi: fsl-qspi: Support per spi-mem operation frequency switches") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Frieder Schrempf Acked-by: Han Xu Link: https://patch.msgid.link/20260917-fsl-qspi-freq-op-fix-v1-1-5fbe6b02f738@kontron.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 96bb28b3f28ff2e1be3f9d4d3c691ce56f0502ce Author: Ian Luites Date: Mon Aug 31 08:25:47 2026 +0000 soundwire: dmi-quirks: Disable ghost Realtek on Asus GX651AX commit 6d49beec658f61801e79019fd73691b17252dee3 upstream. The Asus ROG Zephyrus Duo GX651AX exposes a Realtek RT722 device in ACPI which does not exist in the physical hardware. The device remains unattached while the CS42L43 and both CS35L56 devices attach successfully. This confuses the function topology machine driver into creating duplicate DAI links named SDW3-Playback-SimpleJack, and the sof_sdw probe fails with error -12. Add a model-specific quirk to remove the ghost RT722 device. Fixes: 45cf24da0a10 ("ASoC: Intel: soc-acpi-intel-ptl-match: Remove unnecessary cs42l43 match") Cc: stable@vger.kernel.org # 7.2.x Assisted-by: LLM Signed-off-by: Ian Luites Reviewed-by: Charles Keepax Link: https://patch.msgid.link/20260831082534.224716-1-ian@luites.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 0219b72f5c209732b2f03a8cc0d7240b5e428a99 Author: Donggeun Yoo Date: Sat Sep 5 17:42:10 2026 +0900 swiotlb: use the adjusted address for the highmem page lookup commit b7d7914a9ae3097e63d113007e4fb44d33d515b1 upstream. swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it. Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset non-zero. The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then hands a highmem address to phys_to_virt(). Take both from orig_addr once it is final and keep pfn in the branch that uses it. PhysHighMem() asks the question straight from the address, as dma-debug already does. Fixes: 5f89468e2f06 ("swiotlb: manipulate orig_addr when tlb_addr has offset") Cc: stable@vger.kernel.org Signed-off-by: Donggeun Yoo Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20260905084210.148255-1-donggeunyoo.kernel@gmail.com Signed-off-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman commit 8205ac5ddb42a1843fa8d6a8c295b5c7f4f8c6ed Author: Inbal Schussheim Date: Mon Sep 14 12:04:07 2026 +0300 tcp: exclude old ACKs from tcp fast path commit f81e6c3fb06327bc49cdd6e559845293ba06a704 upstream. Exclude old ACKs before SND.UNA from the tcp fast path as well as ACKs after SND.NXT. Such ACKs will fall through to the slow path, where tcp_ack() performs the appropriate validation and challenge ACK handling according to RFC5961 and Commit 3d501dd326fb1c7 ("tcp: do not accept ACK of bytes we never sent"). This prevents old ACKs from being accepted or modifying connection state as part of the fast path before appropriate ACK validation is applied. In particular, this prevents payload carried by a segment with an excessively old ACK from advancing RCV.NXT before the ACK is rejected. Fixes: 31770e34e43d ("tcp: Revert "tcp: remove header prediction"") Reported-by: Amit Klein Reported-by: Tamir Shahar Reported-by: Inbal Schussheim Suggested-by: Eric Dumazet Cc: stable@vger.kernel.org Signed-off-by: Inbal Schussheim Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260914090408.1435080-2-inbal.lipshtat@mail.huji.ac.il Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 00e0cb1c2916893378802282c0a2cdfc1da799da Author: Chang S. Bae Date: Wed Sep 16 22:59:39 2026 +0000 x86/microcode/intel: Reject problematic loading on Granite Rapids systems commit e7d3e2f46dd5a69046e6d95a0f189155a5516b93 upstream. Microcode updates can usually jump revisions. However, there is an erratum on Granite Rapids systems. If they "jump over" revision 0x1000405, they result in an #MC. Avoid it. Signed-off-by: Chang S. Bae Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Dave Hansen Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260916225939.1144524-1-chang.seok.bae@intel.com Signed-off-by: Greg Kroah-Hartman commit c961ce3ac1420e786e2b18d04011efd9ec460e05 Author: Chang S. Bae Date: Wed Sep 16 23:00:03 2026 +0000 x86/build/64: Prevent native builds from generating EGPR use commit 63edf5a009ae366369a1b484cd9ae4ee7c51946c upstream. Omar reports that CONFIG_X86_NATIVE_CPU=y allows builds to opportunistically emit instructions using %r16-%r31 (EGPRs) when the build host supports APX since the commit: ea1dcca1de12 ("x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'") But the kernel is not yet prepared to use new registers internally. For example, there is no context-switch support for general in-kernel use. Explicitly disable EGPR use when building with -march=native. For C, since GCC 14 and Clang 18, both compilers support suppressing EGPR use with -mno-apx-features=egpr, whose availability can be detected via cc-option. For Rust, pass features=-apxf through the generated JSON to avoid unstable-feature warnings, see https://github.com/rust-lang/rust/issues/139284 Note Rust only accepts the option to disable APX instructions entirely or not. Support for this gating also depends on the Rust/LLVM combination. Rust 1.88 introduced the `apxf` feature option, but versions prior to 1.93 may emit an `apxf` attribute to the backend that only LLVM 23 or later can interpret. Restrict native Rust builds accordingly. Fixes: ea1dcca1de12 ("x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'") Reported-by: Omar Avelar Signed-off-by: Chang S. Bae Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nathan Chancellor Acked-by: Miguel Ojeda Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260916230003.1144622-1-chang.seok.bae@intel.com Signed-off-by: Greg Kroah-Hartman commit 82a15e57ee02b0cee1a8bfad769ee0e4f83dec3b Author: Lyude Paul Date: Fri Aug 14 15:43:50 2026 -0400 drm/nouveau/gsp/r570: Enable S/R Display workaround in GSP commit 24fbd6d4bcf3363ef13ebe0d36dea93f30396c6d upstream. There's two flags that we've never been setting when asking GSP to suspend the GPU, which OpenRM does set: GPU_STATE_FLAGS_PRESERVING GPU_STATE_FLAGS_PM_TRANSITION These flags aren't -supposed- to do much in GSP, they're mostly used by OpenRM itself for state tracking. The only thing they do from GSP's side is control whether or not a single display related workaround is applied during suspend. But as it turns out, that single workaround is actually quite crucial for getting runtime PM working with nouveau - and without it set we end up seeing a lot more failures with runtime PM resume. So, let's start setting it. Signed-off-by: Lyude Paul Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144") Cc: # v6.16+ Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260814194542.781955-4-lyude@redhat.com (cherry picked from commit ca57629b3eb912c77bc4357178a2130ea6c2d6df) Signed-off-by: Lyude Paul Signed-off-by: Greg Kroah-Hartman commit 1e7f89e7c67c8bd1c608b8d8cb6bd8728d026282 Author: Lyude Paul Date: Fri Aug 14 15:43:49 2026 -0400 drm/nouveau/gsp/r570: Set GcOff = 0 in fbsr commit 12f6eff11ccf9cad3b2dfcdd94184fdb9ffface2 upstream. Previously, it looked as if we were able to fix suspend/resume on some desktops by setting Gcoff based on whether or not we were entering runtime PM. This was a mistake though - the only time suspend/resume would end up actually working was if Gcoff = 0. It seems like it's likely the main reason for this is the FBSR GcOff argument actually controls GSP's behavior with regards to which buffers it decides to save across suspend/resume. When GcOff = 1, RM reserved regions are saved unless they are marked as LOST_ON_SUSPEND, and RM channel-context and kernel-client buffers are also saved -including- when they are LOST_ON_SUSPEND. This means with GcOff = 1, we end up having GSP save and restore buffers that actually need to be reinitialized on resume - causing the failures we're setting. Thanks to John Hubbard from Nvidia for providing some background on what these options do in the GSP firmware do! Signed-off-by: Lyude Paul Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144") Cc: # v6.16+ Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260814194542.781955-3-lyude@redhat.com (cherry picked from commit c7abe771e013848970421e5ca29c6b2f05c31965) Signed-off-by: Lyude Paul Signed-off-by: Greg Kroah-Hartman commit b66bc6fc7799eb830b42832225096b6d636aeef6 Author: Lyude Paul Date: Fri Aug 14 15:43:51 2026 -0400 drm/nouveau/gsp: Increase delay for magic sleep in r535_gsp_fini() commit bbb9293c9bb792f3f16c842f223b8c97bdbaf227 upstream. As it turns out, Turing isn't the only architecture that needs this. On this Dell Precision 7780 with an AD103 GPU, along with pretty much every other laptop I tested, runtime PM is still somewhat unreliable. At first glance it seems as if it's fixed, but lowering the autosuspend delay to 500ms and then doing a stress test of suspend/resume cycles on the GPU ends up causing everything to start timing out. After quite a lot of digging, I eventually landed back on this magic timeout in r535_gsp_fini(). As it turns out, increasing the timeout ends up fixing the runtime PM issues as far as I can tell, even during intense stress testing. Unfortunately after spending quite a bit of time trying to dig through OpenRM to figure out what this magic sleep is actually doing, I've also come up short with any reasonable explanation. In lieu of that, I'm going to include the observations I did make while trying to figure this out in hopes someone eventually does figure this out: * The magic sleep has to occur after fbsr is initialized. Performing it at any time before that doesn't appear to work. * In situations where runtime PM starts getting flaky, some rather interesting visual effects end up happening on occasion before the GPU fully falls over. In particular, squares that look like the result of an incomplete blitting operation to a tiled buffer end up showing up on applications like vkcube. Interestingly enough, they remain in precisely the same place between runtime PM cycles until the GPU falls over - even when restarting vkcube multiple times, and even when vkcube is actively updating the screen. Even more interestingly, they're not limited to a specific framebuffer - you can see the squares changing as the cube rotates around. We cannot however, say that this is likely to be a incomplete fbsr operation. The magic sleep happens before fbsr is actually saved (which happens on the GSP unload), so it's something else. * During a short bit of testing with a desktop that I have, the magic sleep seemed to make no difference to whether or not suspend/resume works. It seems to generally work almost always. So we can assume this is likely exclusive to runtime PM, not S3. As well, here's a list of the things I tried before settling on the magic sleep: * Hooking up NV2080_CTRL_CMD_INTERNAL_GCX_ENTRY_PREREQUISITE and then blocking runtime PM until OpenRM signals that GC6/GCOFF is ready appears to make no difference. * Hooking up some (maybe not all, unsure about that part) bits of comptag saving including: * Fetching static memsys information from GSP * Adding the size of the comptag storage to the fbsr data * Adding a GA103+ workaround for disabling raw compression mode during fbsr (it doesn't seem like it applies for any systems I tried it on anyhow) * Setting bPreserveVideoMemoryAllocations=1 in GspSystemInfo So, until we can figure this out properly - just sleep for longer. Signed-off-by: Lyude Paul Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144") Cc: # v6.16+ Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260814194542.781955-5-lyude@redhat.com (cherry picked from commit 09b47186a4164f3aaa3591313f80794443117342) Signed-off-by: Lyude Paul Signed-off-by: Greg Kroah-Hartman commit db87c5b8957a7546c1816aa5345fba1a80878e16 Author: Lyude Paul Date: Fri Aug 14 15:43:48 2026 -0400 Revert "nouveau/gsp: fix suspend/resume regression on r570 firmware" commit a5c41fa7f925fda2db394329fa0b26243fa63a81 upstream. This reverts commit 8302d0afeaec0bc57d951dd085e0cffe997d4d18. It turns out this looked like the right fix on some systems, but it's not - as this causes runtime PM to actually fail on many a laptop. Fixes: 8302d0afeaec ("nouveau/gsp: fix suspend/resume regression on r570 firmware") Cc: # v6.19+ Signed-off-by: Lyude Paul Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260814194542.781955-2-lyude@redhat.com (cherry picked from commit 94097122bfd701976bc1a62ccd434c13f3f67cde) Signed-off-by: Lyude Paul Signed-off-by: Greg Kroah-Hartman commit 09f78e638768cbae64a824cb5ad5548f05ff50da Author: Chunfeng Song Date: Thu Sep 10 05:51:10 2026 +0000 rust: net: phy: fix off-by-one bit positions in device status accessors commit 6fb0a9d9071f1ff0cc5cfc0782302d9c90d642cb upstream. The hand-written bitfield offsets in is_link_up(), is_autoneg_enabled() and is_autoneg_completed() were correct when the abstraction was merged: at that time autoneg, link, and autoneg_complete were at bits 13, 14, and 15 of struct phy_device's first bitfield unit. Commit 2796ff1e3dca ("net: phy: add flag is_genphy_driven to struct phy_device") later inserted is_genphy_driven just before autoneg, shifting the three fields up by one, so the accessors now read: is_link_up() reads bit 14 = autoneg is_autoneg_enabled() reads bit 13 = is_genphy_driven is_autoneg_completed() reads bit 15 = link The official ax88796b Rust driver uses all three accessors in its read_status() implementation, so it inherits the bug. phy_attach_direct() sets is_genphy_driven only when it falls back to the generic driver, and ax88796b has a real driver, so is_genphy_driven stays 0. The broken is_autoneg_enabled() therefore reads bit 13 as 0, compares it against AUTONEG_ENABLE (1), and always returns false, so read_status() never reaches the resolve_aneg_linkmode() call. The ordinary bindgen accessors take &self. Calling them through (*phydev).link() would create a shared reference to the complete bindings::phy_device, which is not appropriate for an object wrapped in Opaque. Use the bindgen-generated raw accessors (link_raw(), autoneg_raw(), and autoneg_complete_raw()) instead. They retain the bit positions and endianness handling generated from the C layout without creating a Rust reference to the complete phy_device. Drop the hand-written numbers together with the TODO comment that marked them as a stopgap. The raw accessors are only emitted by bindgen 0.71 and later, and were added at the Rust-for-Linux project's request, so this fix can only be backported to stable branches whose minimum bindgen version is at least that, hence the scope on the Cc: stable line below. Found by a static equivalence audit (C2RustDrv, a C-to-Rust driver migration tool) that compares hand-written bitfield offsets against the bindgen layout of struct phy_device. Verified by building the bindings and checking the generated accessors; no runtime testing was possible without PHY hardware. Fixes: 2796ff1e3dca ("net: phy: add flag is_genphy_driven to struct phy_device") Cc: stable@vger.kernel.org # Only 7.1.y and later (requires bindgen's raw pointer accessors). Link: https://github.com/rust-lang/rust-bindgen/issues/2674 Signed-off-by: Chunfeng Song Reviewed-by: FUJITA Tomonori Link: https://patch.msgid.link/20260910055110.167110-1-springbreeze@stu.pku.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 934bd95f1a6404dbb845951b823547abab05a649 Author: Thomas Gleixner Date: Fri Sep 11 11:09:12 2026 +0200 signal: Prevent exec() race commit d2710c8d938ae6a825a6463158e6e6f31eac792a upstream. Hyunwoo debugged the following KASAN UAF splat: BUG: KASAN: slab-use-after-free in __send_signal_locked+0xb27/0xba0 Write of size 8 at addr ffff888007ed80c8 by task poc/79 ... Call Trace: __send_signal_locked+0xb27/0xba0 do_send_sig_info+0xa7/0x160 do_send_specific+0x76/0xa0 __x64_sys_tgkill+0x193/0x270 ... Allocated by task 80: do_timer_create+0x1a4/0x1030 __x64_sys_timer_create+0x145/0x190 ... Freed by task 12: kmem_cache_free_bulk+0x1f8/0x4a0 kvfree_rcu_bulk+0x14f/0x1c0 kfree_rcu_work+0x128/0x1a0 ... Last potentially related work creation: kvfree_call_rcu+0x39/0x390 __flush_itimer_signals+0x211/0x320 flush_itimer_signals+0x47/0x90 begin_new_exec+0xa6b/0x28c0 It turned out that this happens with a non-leader exec() as Hyunwoo explained: de_thread() calls exchange_tids() before release_task(leader), so the struct pid held by a SIGEV_THREAD_ID timer created against the leader's tid now points to the thread which called execve(). pid_task() returns that thread and lock_task_sighand() on it succeeds. If the timer signal is blocked, its sigqueue stays queued on the leader's task::pending. The next expiry of that timer can then run while release_task() flushes the queue. posixtimer_send_sigqueue() checks whether the sigqueue is already queued with a plain list_empty(), which only reads list_head::next. list_del_init() is not atomic and INIT_LIST_HEAD() stores list_head::next before list_head::prev, so the check can pass in between. list_add_tail() queues the entry on the task::pending of the live thread, and the list_head::prev store from the flush then overwrites the list_head::prev link that list_add_tail() has just set. __flush_itimer_signals() does not undo that either. With list_head::prev pointing at the entry itself, its list_del_init() only stores the same values again, so the entry is not removed from the list. It is still there after the last reference is dropped and the timer is freed by RCU, and the list_add_tail() of a later tgkill() follows that list_head::prev into the freed timer. This problem surfaced with the recent commit which moved the sigqueue flush out of the sighand lock held region. Hyonwoo proposed to fix this by using list_del_init_careful(), but that just papers over the problem. After some disucssions and various attempts to solve it, Eric pointed out that there is no reason to flush task::pending late in release_task() and it should be done in exit_signals() already. As nothing can collect and deliver signals which are queued in a dying task's pending queue, there is no reason to delay it further. But it has to be ensured that no signals can be queued into it after that point. exit_signals() sets PF_EXITING in task::flags, which can be used as an indicator for this. Cure it by: - Preventing signal queueing for task private signals (PIDTYPE_PID) when the task has PF_EXITING set in __send_signal_locked() and in posixtimer_send_sigqueue(). - Protecting the unlocked setting of PF_EXITING in exit_signals() for the task group empty and the group exit case with sighand lock - Flushing task::pending signals right there. Optimize that by moving the whole pending list to an on-stack list head under sighand lock and free the signals without the lock held. There has been quite some discussion about the lockless flush and the non-leader exec case on weakly ordered systems. The problem is that a third party which tries to send a posix timer signal relies on the PID lookup to find the target task and that lookup might result in the new leader when the signal was originaly directed to the old leader. In case that the signal was queued on the old leader then the lockless flush raised a concern over the following situation: old_leader new_leader third party A: flush_list() // list_del_init() stores to sigqueue LOCK (tasklist) old_leader->exit_state = EXIT_ZOMBIE; B: UNLOCK (tasklist) C: LOCK (tasklist) if (old_leader->exit_state) transfer_tids() D: store PID posix_timer_send_sigqueue() // Observes #D so t = new_leader E: t = get_target() F: LOCK (sighand) G: if (list_empty(sigqueue)) list_add(sigqueue) The concern was that the third party might observe #D but not observe #A and therefore would proceed to #G while the list_del() stores (#A) in flush_list() are not visible yet, which could result in list corruption. That would be possible if looking at it solely from a RELEASE+ACQUIRE ordering point of view, but B-C is a UNLOCK+LOCK hand-over, which is not the same as RELEASE+ACQUIRE: RELEASE+ACQUIRE: RCpc, only the CPUs involved agree on the ordering UNLOCK+LOCK: RCtso, the hand-over is store-ordering As B-C is UNLOCK+LOCK, which is RCtso and that does impose store order, A stores must happen before the D store. Combine with E-F, which has a data dependency from the LOAD to the LOCK and thereby constraints later LOADs, those sigqueue loads in G that come after F must in fact observe the A stores. Fixes: fb3bbcfe344e ("exit: change the release_task() paths to call flush_sigqueue() lockless") Reported-by: Hyunwoo Kim Debugged-by: Hyunwoo Kim Suggested-by: "Eric W. Biederman" Signed-off-by: Thomas Gleixner Tested-by: Kijo Park Reviewed-by: Oleg Nesterov Reviewed-by: Frederic Weisbecker Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260911090541.572536604@kernel.org Closes: https://patch.msgid.link/aok1rdkBgZsynHZB@v4bel Signed-off-by: Greg Kroah-Hartman commit 7d8c22cb2cb1efb5e830a4545c76abf7b35cc2e8 Author: Aohan Mei Date: Fri Sep 11 15:34:32 2026 +0800 rds: ib: use rds_conn_drop() on protocol version mismatch commit f97d8c7bab7843631206a114986c9059da03efeb upstream. rds_ib_cm_connect_complete() runs from the RDMA-CM event handler with conn->c_cm_lock held. When the peer negotiates a protocol version older than RDS_PROTOCOL_COMPAT_VERSION, the handler calls rds_conn_destroy(), which is only safe in the rmmod path: it synchronously tears the connection down and flush_work()es the shutdown work cp_down_w. That shutdown work (rds_conn_shutdown()) needs cp_cm_lock, which is the very lock the event handler still holds, so the flush never completes: the two workers wait on each other and the RDS connection workqueues stall for good. All other RDMA-CM failure paths (REJECTED, CONNECT_ERROR, DISCONNECTED) use rds_conn_drop(), which marks the connection RDS_CONN_ERROR and schedules the shutdown work asynchronously. Use it here as well. Fixes: f147dd9ecabf ("RDS/IB: Disallow connections less than RDS 3.1") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Reviewed-by: Allison Henderson Signed-off-by: Aohan Mei Link: https://patch.msgid.link/20260911073436.3542080-1-ljp1205831794@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4336e3f47d9d516441066e9a65eaf076790d8d45 Author: Thomas Gleixner Date: Wed Sep 16 20:48:30 2026 +0200 posix-cpu-timers: Prevent freeing a timer which is queued on the expiry list commit c21eaa72f02fc6e85621cbe09d303d8fb8bd39cd upstream. Kijo analyzed another race in the POSIX CPU timer code: Commit bf635681c906 converted cpu_timer::firing from a tristate value to a boolean. This lost the distinction between "not owned by the firing list" and "still owned, but delivery was canceled". The resulting race is: expiry handler timer_settime() timer_delete() -------------- --------------- -------------- collect timer onto private firing list firing = true observes firing = true firing = false return TIMER_RETRY wait for handler observes firing = false finish deletion unhash and free timer resume list traversal read freed elist.next -> UAF The firing bit is clearly the wrong indicator since that commit. Check whether the timer is queued on the expiry list or not instead. If it is queued clear the firing bit to prevent signal delivery as before and return TIMER_RETRY so the caller unlocks the timer which allows the expiry code to make progress and remove it from the list. Fixes: bf635681c906 ("posix-cpu-timers: Cleanup the firing logic") Reported-by: Kijo Park Debugged-by: Kijo Park Signed-off-by: Thomas Gleixner Tested-by: Kijo Park Reviewed-by: Frederic Weisbecker Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5895cebc8b20d43aa473bf0b57a6c549add6f4be Author: Claudiu Beznea Date: Thu Jul 16 21:32:46 2026 +0300 phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context commit 48e97c59a49c9e90270f5e3d221db253b76de5da upstream. The OTG PHY initialization sequence needs to wait for 20 ms at a specific step, as described in commit 72c0339c115b ("phy: renesas: rcar-gen3-usb2: follow the hardware manual procedure"). Commit 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data") tried to address various problems in the rcar-gen3-usb2 driver and converted the mutex protecting HW register accesses to a spin lock, leaving, however, a long delay in the critical section protected by the spin lock. This may become a problem, especially on RT kernels. To address this, release the spin lock before sleeping for 20 ms as required by the HW manual and reacquire it afterwards. To avoid other threads entering the critical section and configuring the HW while the software is waiting for the OTG initialization to complete, introduce the otg_initializing variable alongside the otg_init_done wait queue. Any other thread trying to configure the HW while the OTG PHY initialization is in progress waits for the wait queue instead of immediately returning errors to PHY users. The IRQs were also disabled while waiting for the OTG PHY initialization to complete, as the interrupt handler may also apply HW settings. The OTG can only be initialized once. It is initialized by the first PHY that calls struct phy_ops::rcar_gen3_phy_usb2_init(). To avoid failures when multiple PHYs call struct phy_ops::rcar_gen3_phy_usb2_init() simultaneously, and the PHY responsible for initializing the OTG either fails or deinit quiqly and another PHY takes over the PHY init role), the code waiting for the channel->otg_init_done wait queue retries up to NUM_OF_PHYS times. Fixes: 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data") Cc: stable@vger.kernel.org Reported-by: Pavel Machek Closes: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz Reported-by: Nobuhiro Iwamatsu Closes: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz Signed-off-by: Claudiu Beznea Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz Link: https://patch.msgid.link/20260716183246.3183877-1-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 848297e6121e5d424b644c51b3fa60b87114d678 Author: Richard Zhu Date: Thu Aug 13 17:50:03 2026 +0800 PCI: imx6: Move clock enable after core reset assertion commit c9dc7d730319ad64b51570c5387f1fee7b07b510 upstream. Commit 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators") inadvertently moved clock enablement before core reset assertion, breaking PCI device initialization on i.MX6Q Apalis platforms with ASM1061/ASM1062 SATA controllers connected: imx6q-pcie 1ffc000.pcie: host bridge /soc/pcie@1ffc000 ranges: imx6q-pcie 1ffc000.pcie: IO 0x0001f80000..0x0001f8ffff -> 0x0000000000 imx6q-pcie 1ffc000.pcie: MEM 0x0001000000..0x0001efffff -> 0x0001000000 imx6q-pcie 1ffc000.pcie: config reg[1] 0x01f00000 == cpu 0x01f00000 imx6q-pcie 1ffc000.pcie: iATU: unroll F, 4 ob, 4 ib, align 64K, limit 4G imx6q-pcie 1ffc000.pcie: Link: Only Gen1 is enabled imx6q-pcie 1ffc000.pcie: Link failed to come up. LTSSM: POLL_CONFIG imx6q-pcie 1ffc000.pcie: probe with driver imx6q-pcie failed with error -110 NOTE: It is not 100% clear if the issue is specific to the ASM1061/ASM1062 device or on the specific power-up sequence (reset vs cold-power-on). To fix this regression, restore the original sequence where clocks are enabled after asserting core reset and configuring the controller type. Fixes: 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators") Reported-by: Leonardo Costa Closes: https://lore.kernel.org/all/bl7i3obu2clzsgeoct2a4mtfhv6typcjdqmgneropf3hpgwve6@n2m5uhlduw57/T/#u Reported-by: Franz Schnyder Closes: https://lore.kernel.org/all/t65y5d54axtksbfs7r4olcefqhwm6m4dz3njgnrnf7fcotj74i@o7avoznlafbj/ Signed-off-by: Richard Zhu Signed-off-by: Manivannan Sadhasivam [bhelgaas: move to pci/for-linus for v7.3] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # 7.2+ Link: https://patch.msgid.link/20260813095003.356062-1-hongxing.zhu@oss.nxp.com Signed-off-by: Greg Kroah-Hartman commit 185cd2f5fe1e3319853cf065905b2885ad0bcbf8 Author: Seunguk Shin Date: Mon Aug 3 13:34:55 2026 +0100 fs/dax: check zero or empty entry before converting xarray entry commit 8e2b8614039853e68d5338e37821e8bcee9fc05f upstream. Calling dax_to_folio() with empty entry causes kernel panic below when booting a VM with DAX enabled storage. This patch checks empty entry before calling dax_to_folio() on dax_associate_entry(), dax_disassociate_entry(), and dax_busy_page(). Commit 98c183a4fccf ("fs/dax: don't disassociate zero page entries") added guards in the associate and disassociate paths, but the guards still come after dax_to_folio(), and dax_busy_page() still has the same problem. [ 0.737679] EXT4-fs (pmem0p1): mounted filesystem 79676804-7c8b-491a-b2a6-9bae3c72af70 ro with ordered data mode. Quota mode: disabled. [ 0.737891] VFS: Mounted root (ext4 filesystem) readonly on device 259:1. [ 0.739119] devtmpfs: mounted [ 0.739476] Freeing unused kernel memory: 1920K [ 0.740156] Run /sbin/init as init process [ 0.740229] with arguments: [ 0.740286] /sbin/init [ 0.740321] with environment: [ 0.740369] HOME=/ [ 0.740400] TERM=linux [ 0.743162] Unable to handle kernel paging request at virtual address fffffdffbf000008 [ 0.743285] Mem abort info: [ 0.743316] ESR = 0x0000000096000006 [ 0.743371] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.743444] SET = 0, FnV = 0 [ 0.743489] EA = 0, S1PTW = 0 [ 0.743545] FSC = 0x06: level 2 translation fault [ 0.743610] Data abort info: [ 0.743656] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 0.743720] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 0.743785] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 0.743848] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000b9d17000 [ 0.743931] [fffffdffbf000008] pgd=10000000bfa3d403, p4d=10000000bfa3d403, pud=1000000040bfe403, pmd=0000000000000000 [ 0.744070] Internal error: Oops: 0000000096000006 [#1] SMP [ 0.748888] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 6.18.4 #1 NONE [ 0.749421] pstate: 004000c5 (nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.749969] pc : dax_disassociate_entry.constprop.0+0x20/0x50 [ 0.750444] lr : dax_insert_entry+0xcc/0x408 [ 0.750802] sp : ffff80008000b9e0 [ 0.751083] x29: ffff80008000b9e0 x28: 0000000000000000 x27: 0000000000000000 [ 0.751682] x26: 0000000001963d01 x25: ffff0000004f7d90 x24: 0000000000000000 [ 0.752264] x23: 0000000000000000 x22: ffff80008000bcc8 x21: 0000000000000011 [ 0.752836] x20: ffff80008000ba90 x19: 0000000001963d01 x18: 0000000000000000 [ 0.753407] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 0.753970] x14: ffffbf3154b9ae70 x13: 0000000000000000 x12: ffffbf3154b9ae70 [ 0.754548] x11: ffffffffffffffff x10: 0000000000000000 x9 : 0000000000000000 [ 0.755122] x8 : 000000000000000d x7 : 000000000000001f x6 : 0000000000000000 [ 0.755707] x5 : 0000000000000000 x4 : 0000000000000000 x3 : fffffdffc0000000 [ 0.756287] x2 : 0000000000000008 x1 : 0000000040000000 x0 : fffffdffbf000000 [ 0.756871] Call trace: [ 0.757107] dax_disassociate_entry.constprop.0+0x20/0x50 (P) [ 0.757592] dax_iomap_pte_fault+0x4fc/0x808 [ 0.757951] dax_iomap_fault+0x28/0x30 [ 0.758258] ext4_dax_huge_fault+0x80/0x2dc [ 0.758594] ext4_dax_fault+0x10/0x3c [ 0.758892] __do_fault+0x38/0x12c [ 0.759175] __handle_mm_fault+0x530/0xcf0 [ 0.759518] handle_mm_fault+0xe4/0x230 [ 0.759833] do_page_fault+0x17c/0x4dc [ 0.760144] do_translation_fault+0x30/0x38 [ 0.760483] do_mem_abort+0x40/0x8c [ 0.760771] el0_ia+0x4c/0x170 [ 0.761032] el0t_64_sync_handler+0xd8/0xdc [ 0.761371] el0t_64_sync+0x168/0x16c [ 0.761677] Code: f9453021 f2dfbfe3 cb813080 8b001860 (f9400401) [ 0.762168] ---[ end trace 0000000000000000 ]--- [ 0.762550] note: init[1] exited with irqs disabled [ 0.762631] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Link: https://lore.kernel.org/m2y0enxtzk.fsf@arm.com Fixes: 38607c62b34b ("fs/dax: properly refcount fs dax pages") Signed-off-by: Seunguk Shin Reviewed-by: Jan Kara Reviewed-by: Alistair Popple Reported-by: Kiara Grouwstra Cc: Al Viro Cc: Christian Brauner Cc: Matthew Wilcox (Oracle) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d602877baf36c43c788a5f472c977e0be414029f Author: Hyunwoo Kim Date: Fri Sep 11 11:09:17 2026 +0200 exec: Cleanup POSIX timers right after de_thread() commit acb03d3881818581052924a9bbbe92b8741ed448 upstream. A per-thread CPU timer holds a reference to the PID of the thread it is attached to and, while it is armed, its node is queued in that thread's posix_cputimers. The task is looked up by that PID. When a non-leader thread exec()s, de_thread() changes which task owns that PID. pid_task(timer->it.cpu.pid, PIDTYPE_PID) then returns NULL, but the node is still queued on tsk, which is alive. timer_lock_sighand() takes a failed lookup to mean that the node is already dequeued, so it has nothing to undo. begin_new_exec() calls posix_cpu_timers_exit(me) right after exec_task_namespaces() and that removes the leftover node, so the state normally stays invisible. But bprm->point_of_no_return is set before de_thread(), so if unshare_files(), set_mm_exe_file(), exec_mmap() or exec_task_namespaces() fails, the task dies before it gets there. exit_itimers() then frees the k_itimer while its node is still queued, and reaping tsk later erases that freed node from the rbtree. In short: the non-leader thread B the parent timer_create(CLOCK_THREAD_CPUTIME_ID) timer_settime() arm_timer() // the node is queued on B execve() de_thread(B) exchange_tids(B, leader) // B's PID now belongs to the leader release_task(leader) __exit_signal(leader) posix_cpu_timers_exit(leader) // cleans leader's queue, not B's __unhash_process(leader) // that PID has no task anymore exec_mmap() mmap_read_lock_killable(old_mm) kill(B, SIGKILL) // -EINTR get_signal() do_exit() exit_itimers() posix_timer_delete() posix_cpu_timer_del() posix_timer_unhash_and_free() // freed while still queued wait4() release_task(B) posix_cpu_timers_exit(B) cleanup_timerqueue() timerqueue_del() // use-after-free Move the POSIX timer cleanup right after de_thread() before any of the later failure conditions brings the task into do_exit(). [ tglx: Move the cleanup right after de_thread() ] Fixes: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") Signed-off-by: Hyunwoo Kim Signed-off-by: Thomas Gleixner Tested-by: Kijo Park Reviewed-by: Oleg Nesterov Reviewed-by: Frederic Weisbecker Cc: stable@vger.kernel.org Link: https://patch.msgid.link/ao7Q8miiuLAPVnWv@v4bel Link: https://patch.msgid.link/20260911090541.627712075@kernel.org Signed-off-by: Greg Kroah-Hartman commit 7a1b27780b113583a94256d58dabfe7c0d9286e7 Author: Wentao Liang Date: Thu Sep 17 16:34:39 2026 +0000 cifs: Fix server use-after-free in cifs_chan_skip_or_disable() commit 717e0a25036b6c92cecace30913b2d874a4c22b8 upstream. When a secondary channel is no longer supported by the server, cifs_chan_skip_or_disable() drops the channel reference with cifs_put_tcp_session() and then continues to use the server pointer by calling cifs_signal_cifsd_for_reconnect() on it and reading its primary_server pointer. cifs_put_tcp_session() can drop the last reference of the channel and tear it down, so both the channel and the primary server (whose reference is also dropped by cifs_put_tcp_session()) can be freed before they are signaled for reconnect. Signal the channel and the primary server and capture the primary server pointer before dropping the channel reference with cifs_put_tcp_session(). Fixes: f591062bdbf4 ("cifs: handle servers that still advertise multichannel after disabling") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit cec7cfb57dc6bedba432492ff043a35e7d81e56a Author: Wentao Liang Date: Tue Sep 15 06:59:33 2026 +0000 ata: libahci_platform: Fix device reference leak in ahci_platform_get_resources() commit 0d1cb83337f13af082afb68b28d3fdfe29cde7fb upstream. of_find_device_by_node() takes a reference on the port platform device, which is only used to look up its port regulator and is never released, neither on success nor on the error paths. Drop the reference with put_device() once the regulator has been obtained, which covers both the success and error paths. Fixes: c7d7ddee7e24 ("ata: libahci: Allow using multiple regulators") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://lore.kernel.org/r/20260915065933.1733061-1-vulab@iscas.ac.cn Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 7912ad8fb5233bb8cfe21d50df639c7f4854ff9d Author: Niklas Cassel Date: Fri Sep 4 15:43:11 2026 +0200 ata: libahci: clear PxCLBU and PxFBU for AHCI_HFLAG_32BIT_ONLY commit 82e47533221d4746947b74d2e79a478c36c6433a upstream. A user reported that commit 105c42566a55 ("ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585") made the JMicron JMB585 unusable on his board. The failure is seen as soon as the ahci driver is probed, and booting with iommu=off does not solve the problem. Looking at the AHCI specification, PxCLBU and PxFBU are both read only '0' for HBAs that do not support 64-bit addressing. For HBAs that do support 64-bit addressing, the registers are read write, with a reset value that is Implementation Specific. When using the AHCI_HFLAG_32BIT_ONLY flag, the HBA does support 64-bit addressing, and a 32-bit DMA mask is set by simply clearing HOST_CAP_64. Thus, in this case, we need to explicitly clear the registers to 0. Fixes: 105c42566a55 ("ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585") Fixes: c7a42156d99b ("ahci: disable 64bit dma on sb600") Cc: stable@vger.kernel.org Reported-by: Roland Waltersson Closes: https://lore.kernel.org/linux-ide/IA0PR17MB668730A4ECCD65F7A1DC3EDC9EB62@IA0PR17MB6687.namprd17.prod.outlook.com/ Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260904134310.1465051-2-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 828938118d6c2bb711301748c3e39e4bed6a62f5 Author: Michal Koutný Date: Mon Sep 14 14:19:10 2026 +0200 cgroup: Avoid iteration of dying tasks with zero refcount commit 057dac23d329d5c5ed62352f2659a39fd46c6d4a upstream. The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") extended the lifetime of tasks on the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration. The repeat: loop in css_task_iter_advance() doesn't consider ->usage count, so add a new loop to css_task_iter_next() to skip de-used tasks on the dying_list. Rough illustration of the possible race R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader && signal->live != 0 => it->task_pos = &L->cg_list release css_set_lock T exits --signal->live == 0 cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU... put_task_struct(L) L->usage = 0 /* L still on dying_tasks */ ...RCU... __put_task_struct(L) css_task_iter_next() // another iteration take css_set_lock it->task_pos = &L->cg_list get_task_struct(L) => addition on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // dying skip comes too late free_task(L) cgroup_procs_show() task_pid_vnr(L) Fixes: 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") Cc: stable@vger.kernel.org # v6.19+ Link: https://lists.debian.org/debian-kernel/2026/08/msg00220.html Reported-by: Noah Elias Feldt Reported-by: Salvatore Bonaccorso Tested-by: Salvatore Bonaccorso Signed-off-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit a318ee718e7448cd6bf62d9b3197b6a6a8d4701e Author: Jiangshan Yi Date: Mon Sep 14 18:47:12 2026 +0800 ASoC: codecs: rt712-sdca-dmic: fix uninitialized stream_config->type commit 03a5699a0a04309c597683967aaaf25d1e555ea2 upstream. stream_config is not initialized before being passed to sdw_stream_add_slave(). The type field may contain garbage and is later copied to stream->type by sdw_config_stream(). Zero-initialize stream_config so type defaults to SDW_STREAM_PCM. While at it, use snd_sdw_params_to_config() helper instead of open-coding the same logic. Fixes: 63a511284c9e ("ASoC: rt712-sdca: Add RT712 SDCA driver for Mic topology") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260914104712.379574-1-yijiangshan@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f070cce7cb361d5389b18f3ff6bd3d25a7596369 Author: Yuho Choi Date: Thu Sep 10 23:11:21 2026 -0400 ALSA: virtio: reset device before deleting virtqueues commit 6c05d00af307560e6a9f1631d6270d3df5aa2272 upstream. virtsnd_remove() and virtsnd_freeze() delete the virtqueues before resetting the device. del_vqs() frees the vring backing, but does not provide a generic device quiesce operation. In particular, modern virtio-pci keeps enabled queues active until the device is reset. Reset the device before deleting the virtqueues so it can no longer access the vring memory when that memory is released. This also covers probe failures after DRIVER_OK, which unwind through virtsnd_remove(). Fixes: de3a9980d8c3 ("ALSA: virtio: add virtio sound driver") Fixes: 575483e90a32 ("ALSA: virtio: introduce device suspend/resume support") Cc: stable@vger.kernel.org Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260911031121.1542502-1-oss.patchbox@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ab77e3f453c5f2499c08d6e8e218501d25bab39e Author: Xiang Mei Date: Sat Sep 12 13:05:30 2026 -0700 ALSA: usb-audio: Clamp implicit feedback packet count to URB capacity commit 76a986c980bb502c7688d605ac7a67fd257a9a1b upstream. data_ep_set_params() allocates each data URB for exactly u->packets isochronous frames, so urb->iso_frame_desc[] has u->packets slots and ctx->packets is the driver's only record of that limit. For an implicit feedback sink, snd_usb_queue_pending_output_urbs() overwrites it with the sync source's packet count, which is calculated independently from the capture endpoint's parameters. When that count is larger, prepare_playback_urb() and prepare_silent_urb() can write iso_frame_desc[] past the allocation; their existing bounds limit payload bytes, not the descriptor index. The reproducer uses a high-speed UAC2 device declaring bInterval 1 for implicit feedback capture (8 packets) and bInterval 4 for playback (1 packet). On the first capture completion after the stream starts, it accesses seven descriptors spanning 112 bytes beyond the one-packet URB: BUG: KASAN: slab-out-of-bounds in prepare_playback_urb (sound/usb/pcm.c:1560) Write of size 4 at addr ffff88801e696ad0 by task vhci_rx/178 prepare_playback_urb (sound/usb/pcm.c:1560) prepare_outbound_urb (sound/usb/endpoint.c:340) snd_usb_queue_pending_output_urbs (sound/usb/endpoint.c:501) snd_complete_urb (sound/usb/endpoint.c:1834) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741) vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107) kthread (kernel/kthread.c:436) The buggy address belongs to the object at ffff88801e696a00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of allocated 208-byte region [ffff88801e696a00, ffff88801e696ad0) Record the allocated packet count per endpoint and clamp both the adopted count and the packet-size copy to it. Fold the Format Type II delimiter into urb_packs before the allocation loop so the recorded limit matches every URB. Fixes: cf044e441902 ("ALSA: usb-audio: Update the number of packets properly at receiving") Reported-by: co+8eacd4fa193b1b28@bugs.sh Closes: https://lore.kernel.org/all/22xPn8drvIUtYgVeQnBiNqXuevOTpBAjepLz%40bugs.sh/ Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260912200530.1955491-1-xmei5@asu.edu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 398b21608955c9712a012355b69a39407367edc9 Author: Takashi Iwai Date: Sat Sep 12 18:21:42 2026 +0200 ALSA: core: Fix potential UAF after asynchronous card release commit fd95e68df6fe66344161a1329cbe5e5805e7b704 upstream. Usually a sound driver releases the resources assigned to the card via snd_card_free(), and it synchronizes with the whole release procedure. However, when the card is released asynchronously via snd_card_free_when_closed() like USB-audio driver, the situation is slightly different; although the snd_card_disconnect() call at the disconnection guarantees that any newer accesses will be gated, the in-flight tasks might be still accessing to the underlying card->dev device even after the disconnection, which would cause a use-after-free in the end, as reported by fuzzers. For addressing the bug above, this patch takes the refcount of card->dev at initialization of the card object, and releases at its destructor. This assures the availability of the card->dev in its whole lifecycle. Reported-by: Farhad Alemi Closes: https://lore.kernel.org/CA+0ovChexj4TrZL_2iG_P0WBEbZc5+73GfB3DkciQi=R8pZOnA@mail.gmail.com Closes: https://lore.kernel.org/CA+0ovCgQUQNN=Z1tJTouiCsDaXR5M-3-SQEGk-cpPXQkM5Xh+w@mail.gmail.com Cc: Link: https://patch.msgid.link/20260912162150.455144-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9cd92e3392bdd14568e9e44aec1ac05e1fcd62e5 Author: David Howells Date: Fri Sep 11 10:25:04 2026 +0100 9p: Fix v9fs_issue_write() to update i_size and remote_i_size commit c60ae98c5aa64021751b38ab1313b19d620bf640 upstream. Fix v9fs_issue_write() to update i_size and remote_i_size to the new size of the server file if we made it larger, using the start fpos and the count returned by p9_client_write() to calculate the new minimum file size. This assumes that if the 9P server makes a short write (say it hits ENOSPC), a reduced count is returned. Fixes: 5fb70e7275a6 ("netfs, 9p: Implement helpers for new write code") Reported-by: Michael Mulqueen Closes: https://lore.kernel.org/r/fbb9e395-1e07-4212-8f70-23f3cd498074@method-b.uk/ Cc: stable@vger.kernel.org Signed-off-by: David Howells Message-ID: <2226525.1789118704@warthog.procyon.org.uk> Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit e8c6f660f3525845ed729916d391bd21fc531e62 Author: Jeremy Nyberg Date: Sun Sep 13 17:43:02 2026 -0700 Input: xpad - fix PDP Marvel Xbox 360 controller commit 7bc369cb3d3f3656eb77285628ee264264d28ad4 upstream. The PDP Marvel Xbox 360 controller with USB ID 0e6f:0147 is incorrectly classified as an Xbox One controller. With the current XTYPE_XBOXONE classification, the controller is detected but produces no input, while its four player LEDs continue blinking indefinitely. Classify USB ID 0e6f:0147 as an Xbox 360 controller instead. Tested on a PDP Marvel Xbox 360 controller with USB ID 0e6f:0147. All inputs register correctly and the player LED indicates the current player. Fixes: c225370e01b8 ("Input: xpad - sync supported devices with 360Controller") Cc: stable@vger.kernel.org Signed-off-by: Jeremy Nyberg Link: https://patch.msgid.link/20260910071627.236014-1-SlickStretch3.0@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit a3ce17bea1fe2ffa84c823a97cd928150a459c0c Author: Roberts Kursitis Date: Sun Sep 6 17:30:40 2026 +0300 Input: xpad - add support for Azeron devices commit cba76c0f47af1a389d718c5bb69e75cbd67bba98 upstream. Azeron controllers (Cyro, Cyborg, Classic/Compact, Cyro Lefty, Cyborg II and Keyzen) present a standard Xbox 360 controller interface, so they work with the existing xpad driver once their USB IDs are added. The 0x16d0 vendor ID is a shared block, but this is safe because xpad only binds interfaces that match the Xbox 360 signature. Tested with an Azeron Keyzen. Signed-off-by: Roberts Kursitis Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260906143040.162418-1-roberts.kursitis@azeron.eu Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f55d5503a7394b31f19b1df1a238adf2d31f147e Author: Erich Sartison Date: Thu Sep 3 12:31:37 2026 +0200 Input: xpad - add support for Victrix Pro BFG Controller commit 971fa7ea8621e123feb9c8d7dc61be1c656bd945 upstream. The controller doesn't currently work via USB-cable. Signed-off-by: Erich Sartison Link: https://patch.msgid.link/20260903103137.630170-1-byt.es@mailbox.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 797ca8906d424233b84e1fd0386ff3e43020b979 Author: Li Jun Date: Mon Sep 14 14:23:53 2026 +0800 watchdog: da9062: fix suspend/resume handling of HW_RUNNING watchdog [ Upstream commit 5071122bf5a628494db16d98d253f622a5aab074 ] da9062_wdt_suspend() and da9062_wdt_resume() only check watchdog_active(), when the watchdog is left running by the driver sets WDOG_HW_RUNNING in da9062_wdt_probe() but userspace never opens the device, so WDOG_ACTIVE remains cleared, the wdt_disable() will not be executed in da9062_wdt_suspend. In this case, the suspend callback is a no-op and the watchdog keeps counting during system suspend, leading to an unexpected system reset. Check WDOG_HW_RUNNING and wdt->wdd，can fix this issue. Fixes: f6c98b08381c7 ("watchdog: da9062: add power management ops") Cs: stable@vger.kernel.org Signed-off-by: Li Jun Link: https://patch.msgid.link/20260914062353.582205-1-lijun01@kylinos.cn Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit feaffce0a440716ec03128380ad976fc8bcf7d01 Author: James Seo Date: Wed Sep 16 15:19:15 2026 -0700 hwmon: (hp-wmi-sensors) Improve raw WMI string handling [ Upstream commit 92b68492eae701e5b0e9d142ffe229921af7b1fa ] Commit c9ba59258094 ("hwmon: (hp-wmi-sensors) Fix failure to load on EliteDesk 800 G6") left out some logic for recognizing raw WMI strings in check_numeric_sensor_wobj(). This issue was reported by a user along with an incomplete and unsuitable proposed solution [1]. Add the missing logic and properly remedy the issue. Also slightly refactor how raw WMI strings are recognized elsewhere to make the intent that they should be treated as regular ACPI strings clearer. Reported-by: Muhammad Bilal Link: https://lore.kernel.org/linux-hwmon/20260916002907.161210-1-meatuni001@gmail.com/ [1] Fixes: c9ba59258094 ("hwmon: (hp-wmi-sensors) Fix failure to load on EliteDesk 800 G6") Signed-off-by: James Seo Link: https://patch.msgid.link/20260916221912.434119-5-james@equiv.tech Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 0758b77ed24eed9b3c939830a159a623499d0231 Author: Cong Nguyen Date: Mon Sep 14 17:41:36 2026 +0700 hwmon: (gpio-fan) return IRQ_HANDLED from the shared alarm IRQ handler [ Upstream commit bdf5f731957de48acada392f28e82bc019713adb ] fan_alarm_irq_handler() always schedules alarm_work but returns IRQ_NONE, so the kernel treats every alarm interrupt as unhandled. On a shared line that risks the whole line being disabled as spurious. v1 just fixed that, but it was still IRQF_SHARED, and always returning IRQ_HANDLED there defeats spurious-interrupt detection for the line -- if the interrupt ever fires without a real event, nothing catches it, and a fault could spin the CPU in the handler. Sashiko flagged this in v1, and Guenter confirmed: this interrupt must not be shared. So v2 drops IRQF_SHARED too. Fixes: d6fe1360f42e ("hwmon: add generic GPIO fan driver") Reported-by: Sashiko AI review Link: https://lore.kernel.org/r/20260901160931.DD3811F00A3D@smtp.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Link: https://patch.msgid.link/20260914104136.1797979-1-congnt264@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 39236f046205e327d8e55848bc40f3af341594a5 Author: hpp.iscas Date: Sat Sep 5 21:40:04 2026 +0800 Input: eeti_ts - publish the OF module alias [ Upstream commit a52ae68a937efc353251aec27fc995ff66cbe1ca ] The EETI driver matches eeti,exc3000-i2c Device Tree clients, but only publishes the legacy eeti_ts I2C ID. The I2C core emits an OF modalias for a Device Tree client. Publish the existing OF match table within its CONFIG_OF guard. Fixes: e32d7f1b246c ("Input: eeti - add device tree matching table") Signed-off-by: hpp.iscas Link: https://patch.msgid.link/20260905134004.66336-1-hppiscas@163.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 00fe76665d8800d371b1cfe866eb415e1073afc4 Author: Matthew Schwartz Date: Thu Sep 17 16:09:06 2026 -0700 x86/fred: Reconstruct the #GP context for rejected INT instructions [ Upstream commit 93f53499d0b945e8ae447f497faf743d60069f61 ] FRED event delivery does not use the IDT, so the gate DPL check that rejects a user INT n falls to software (Intel FRED specification [1], section 8.3). fred_intx() rejects the same vectors as IDT delivery, but reports a zero error code and the IP after the INT. This breaks the signal ABI. Wine uses the error code to recognize INT 0x2d, so the changed context turns a handled breakpoint into an access violation in Elden Ring. Rewind IP using the instruction length in the augmented SS and synthesize the IDT selector error code, (vector << 3) | 2. Set RF in the saved flags, as the CPU does for a #GP fault. Section 5.2.1 defines the saved vector, instruction length and RF state. The supplied length handles prefixes without reading user memory. Limit the changes to already-rejected software interrupts, preserving the accepted INT3, INT4 and enabled INT80 paths and hardware exceptions. With IA32 emulation disabled, INT 0x80 now reports the same #GP as the DPL 0 gate IDT installs there. The rewound IP also stops fixup_iopl_exception() from inspecting the byte after the INT. Also clear the software event flag. Section 6.2.3 specifies that ERETU with this flag and TF set traps before executing any user instruction. A tracer that suppresses SIGSEGV and resumes with TF set expects the next instruction to run first, as after IRET. The sigreturn path clears the same flag for this reason in prevent_single_step_upon_eretu(). [1] Intel Flexible Return and Event Delivery (FRED) Specification, revision 9.0 (346446-009US), sections 5.2.1, 6.2.3 and 8.3. Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15745 Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16132 Reported-by: Paul Gofman Signed-off-by: Matthew Schwartz Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: H. Peter Anvin Link: https://cdrdv2.intel.com/v1/dl/getContent/678938 # [1] Link: https://patch.msgid.link/20260917230907.2080792-2-matthew.schwartz@linux.dev Signed-off-by: Sasha Levin commit e4a442da49fff7619b3cb2988e477022dcea6688 Author: Andrea Righi Date: Tue Sep 15 20:41:01 2026 +0200 sched/core: Avoid false migration warning for proxy donors [ Upstream commit fe3c73d7bc769e7afc252f867a3421fe168b898d ] Proxy execution can move a blocked donor's scheduling context to the lock owner's CPU even when the donor is migration-disabled. The donor does not execute there, and its original execution CPU remains recorded in wake_cpu. set_task_cpu() warns unconditionally for migration-disabled tasks, so a subsequent proxy migration or the wakeup path returning the donor home triggers a false positive: moving a blocked scheduling context does not violate the migration-disabled execution context. For example, creating a mutex owner on CPU1 and a migration-disabled waiter on CPU0 can trigger the following warning: proxy_migrate_repro: donor blocking on CPU0 with migration disabled proxy_migrate_repro: donor moved from CPU0 to CPU1 WARNING: kernel/sched/core.c:3389 at set_task_cpu+0x1d3/0x280 ... Call Trace: try_to_wake_up+0x43f/0x780 __mutex_unlock_slowpath+0x330/0x540 owner_fn+0x9f/0xc0 [proxy_migrate_repro] ... proxy_migrate_repro: donor woke on CPU0, task_cpu=0 proxy_migrate_repro: completed Exclude blocked proxy donors from the warning. The proxy wakeup path restores an executable placement before clearing the blocked state. Fixes: b049b81bdff6 ("sched: Handle blocked-waiter migration (and return migration)") Signed-off-by: Andrea Righi Signed-off-by: Peter Zijlstra (Intel) Acked-by: John Stultz Link: https://patch.msgid.link/20260915184101.2621252-1-arighi@nvidia.com Signed-off-by: Sasha Levin commit 7fa9a465ae8f07c0e4685db6edb6a6f984dbd784 Author: Vinay Belgaumkar Date: Fri Sep 4 11:16:24 2026 -0700 perf: Fix null pointer access in is_include_guest_event() [ Upstream commit 88aed0422f39b22406f35f1e758cea25e7bbcfb5 ] A typical module unload occurring event when there is an active perf connection leads to freeing of the pmu pointer. The call log is something like: .. __pmu_detach_event pmu_detach_event pmu_detach_events perf_pmu_unregister .. __pmu_detach_event() sets event->pmu to null. When the perf connection finally is closed, the following stack trace is observed: Oops: general protection fault, kernel NULL pointer dereference ... RIP: 0010:_free_event+0x3e/0x370 ... Call Trace: ... perf_event_release_kernel+0x260/0x2d0 perf_release+0x12/0x20 A call to mediated_pmu_unaccount_event() inside _free_event() is the root cause of this crash. Adding a check inside is_include_guest_event() ensures we don't accidentally access a null pmu ptr. In addition to this, we will now call mediated_pmu_unaccount_event() before clearing the pmu ptr so that nr_include_guest_events counts are maintained correctly. Fixes: eff95e170275 ("perf: Add APIs to create/release mediated guest vPMUs") Assisted-by: Claude:Claude-Sonnet-5 Signed-off-by: Vinay Belgaumkar Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://patch.msgid.link/20260904181625.1394082-1-vinay.belgaumkar@intel.com Signed-off-by: Sasha Levin commit cf8c95d79b5469a4cbec9f82696ad13b89a1852f Author: Filipe Manana Date: Wed Sep 16 16:49:37 2026 +0100 btrfs: check if there is space for chunk item when validating sys chunk array [ Upstream commit aeab4c62875748ecfd390a47ac1d91ea7c9a6abb ] We checked if have enough remaining space for a key before dereferencing a key, but we then dereference a chunk item, to get the number of stripes, without checking if there is space for the item. So add a check to see if there is enough space for a chunk item before dereferencing the item to extract the stripe count. Fixes: 2a9bb78cfd36 ("btrfs: validate system chunk array at btrfs_validate_super()") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 36c68dc909845c049e0286d229bc502947239452 Author: Filipe Manana Date: Wed Sep 16 15:43:41 2026 +0100 btrfs: abort transaction on failure to update inode for hole punching and reflinking [ Upstream commit 97fcd34aa9fd73cefe3120ac9a82ca9d7763922f ] If we fail to update the inode we error out without aborting the transaction, which can result in a persistent inconsistency if after the failure the transaction is committed, as we have dropped file extent items from a range and either punched a hole or insert a new file extent item for that range (for reflinks). So add the missing transaction abort. Fixes: 2aaa66558172 ("Btrfs: add hole punching") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8fa32e7a21657ac68780b3ee931834ac59eaf9d7 Author: Francis Marlou Pacaro Date: Fri Sep 4 08:20:21 2026 +0800 drm/amd/display: fix MALL hysteresis timer underflow at high refresh rates [ Upstream commit 2ac2fe765ef475f409616ac0b57c4a3922749b0f ] dcn30_apply_idle_power_optimizations() derives the MALL frame cache hysteresis timer with tmr_delay = (uint32_t)(div_u64(..., denom) - 64LL); div_u64() returns a u64, so when the quotient is smaller than 64 the subtraction wraps instead of going negative and tmr_delay ends up huge. The loop that follows tries to squeeze it into the 6 bit register field by doubling denom, but that only makes the quotient smaller, so tmr_delay can never converge. tmr_scale is bumped past 3 and the function gives up with /* Delay exceeds range of hysteresis timer */ ASSERT(false); even though the requested delay is too *short* to encode, not too long. With mall_additional_timer_percent left at its default of 0, the quotient drops below 64 once the refresh rate used for the calculation goes above ~243 Hz. Every DCN 3.0 display above that loses MALL static screen entirely and splats a WARN once per boot. Reproduced on Navi 23 (RX 6600) driving 1920x1080, resetting /sys/kernel/debug/clear_warn_once between modes: refresh MALL ASSERT 144 Hz enabled no 240 Hz enabled no 280 Hz skipped yes 360 Hz skipped yes Commit 3bb68cec4db8 ("drm/amd/display: Add Overflow check to skip MALL") already covered the other end of the range, where a large stutter period makes the delay too long to encode. Cover the short end by clamping to 0, which selects the shortest hysteresis the register can express, 65.28us * 64 = ~4.18ms. That is marginally longer than what the formula asks for at these refresh rates, and erring long is the safe direction: it only delays MALL entry, it can never enter early. The numerator does not change between iterations, only denom does, so compute it once and keep both call sites inside 100 columns. The genuinely out of range case at very low refresh rates still reaches the ASSERT, which is where it belongs. Fixes: 52f2e83e2fe5 ("drm/amdgpu/display: add MALL support (v2)") Signed-off-by: Francis Marlou Pacaro Reviewed-by: Leo Li Signed-off-by: Alex Deucher (cherry picked from commit 387550e53e1405f1f960b62b22f8783db17c8e1d) Signed-off-by: Sasha Levin commit 315c22712715491f0dfafdaf2c2b437540e68702 Author: Dmitriy Chumachenko Date: Mon Sep 14 17:33:03 2026 +0300 drm/amdgpu: check ras and obj before dereference [ Upstream commit 723d4dc628d764b19cf9efca14b82cca5ff020c9 ] nbio_v7_9_handle_ras_controller_intr_no_bifring() dereferences ras and obj without checking either for NULL. Both amdgpu_ras_get_context() and amdgpu_ras_find_obj() can return NULL, e.g. during the window between adev->nbio.ras being set (early in amdgpu_ras_init(), by design, to enable the fatal-error interrupt as soon as possible) and the PCIE_BIF ras object actually being created in RAS late_init. Any interrupt in that window crashes in hard-IRQ context. This is analogous to commit d190b459b2a4 ("drm/amdgpu: the warning dereferencing obj for nbio_v7_4"), which fixed the same issue in the nbio_v7_4 handler. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 7692e1ee2446 ("drm/amdgpu: add RAS fatal error handler for NBIO v7.9") Reviewed-by: Tao Zhou Signed-off-by: Dmitriy Chumachenko Signed-off-by: Alex Deucher (cherry picked from commit c7071767a50a32ed727cf800ac84372429e3b4b3) Signed-off-by: Sasha Levin commit 12929ed66a5166177ef5f06d3da81e4f99993e90 Author: Eric Dumazet Date: Tue Sep 15 13:04:23 2026 +0000 net: skbuff: do not leave stale header offsets after pskb_carve() [ Upstream commit a5117e1eccac6ee3bd4aed7cacf8ebcb6b3eb309 ] pskb_carve_inside_header() and pskb_carve_inside_nonlinear() remove the first bytes of a packet and reallocate skb->head. All the headers that were present before the operation are gone, but both functions call skb_headers_offset_update(skb, 0), which is a no-op : skb->mac_header, skb->network_header, skb->transport_header and skb->csum_start keep their old values and now describe bytes which are no longer there. Both helpers size the new head from the old skb_end_offset(), so the stale offsets still land inside the new allocation. They point past skb_tail_pointer() though, to bytes that were never initialized. pskb_carve_inside_nonlinear() is the worst case, because it leaves a zombie skb with an empty linear part (skb->data == skb_tail_pointer(skb), skb_headlen(skb) == 0), while skb_mac_header_was_set() is still true and skb->mac_header is way ahead of skb->data. The only user of pskb_extract() is rds_tcp_data_recv(), and the carved skb is queued on tinc->ti_skb_list. When the RDS incoming message is released, rds_tcp_inc_free() calls skb_queue_purge(), which frees the skbs with SKB_DROP_REASON_QUEUE_PURGE. This is visible from drop_monitor, which then tries to pull back to the (bogus) mac header : skbuff: __skb_pull(len=234) skb len=6968 data_len=6968 headroom=0 headlen=0 tailroom=0 end-tail=384 mac=(234,14) mac_len=14 net=(248,40) trans=288 shinfo(txflags=0 nr_frags=1 gso(size=1428 type=16 segs=5)) csum(0x100120 start=288 offset=16 ip_summed=3 complete_sw=0 valid=1 level=0) hash(0x7b446c6c sw=0 l4=1) proto=0x86dd pkttype=0 iif=60 kernel BUG at ./include/linux/skbuff.h:2847! Add skb_carve_reset_headers() to mark the mac and transport headers as not set, reset the network header, clear skb->mac_len, and drop a now meaningless CHECKSUM_PARTIAL (csum_start no longer describes anything). Invalidate the inner offsets as well. Unlike mac_header and transport_header they have no "unset" sentinel, so a leftover non-zero value still looks like a real header. Zero skb->inner_mac_header, skb->inner_network_header, skb->inner_transport_header, skb->inner_protocol and skb->encapsulation, so that all the header state is invalidated in one place. v2: fixed an inaccurate changelog. The stale offsets stay inside the new skb->head, which is never smaller than the old one, they simply point past skb_tail_pointer() to bytes that are gone. Thanks to Xuanqiang Luo for insisting on this. Also invalidate the inner header state, as suggested by the netdev AI review : https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260911114922.621937-1-edumazet%40google.com Fixes: 6fa01ccd8830 ("skbuff: Add pskb_extract() helper function") Reported-by: syzbot+586af68eb819833c2d91@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6aa3e9d3.f2639fcc.29487d.0028.GAE@google.com/ Cc: Xuanqiang Luo Cc: Allison Henderson Cc: rds-devel@oss.oracle.com Signed-off-by: Eric Dumazet Reviewed-by: Xuanqiang Luo Link: https://patch.msgid.link/20260915130423.3956471-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1734c3fc0066e228ce1c11e434b7c2527f0a949a Author: Dmitriy Okunev Date: Mon Sep 14 12:15:57 2026 +0300 net: mvpp2: prevent buffer overflow in page_pool allocation [ Upstream commit 14cb1e7702e5cb3c58888f6aed498381a73927d2 ] The per‑processor buffering scheme is supported only if the number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS (8). This is already checked in mvpp2_probe() during the initial activation of percpu_pools. However, mvpp2_change_mtu() may later call mvpp2_bm_switch_buffers(priv, true) without this check, which can lead to an out-of-bounds access in the priv->page_pool array in mvpp2_bm_init(). The array is sized to hold MVPP2_PORT_MAX_RXQ entries, and mvpp2_get_nrxqs() may return exactly that value. The per-CPU scheme then doubles it to nrxqs * 2, exceeding the array bounds. Check that the hardware version is MVPP22 or newer and that the number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS before switching to per-CPU mode. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 7d04b0b13b11 ("mvpp2: percpu buffers") Signed-off-by: Dmitriy Okunev Link: https://patch.msgid.link/20260914091557.71769-1-dokunevdmitriy@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1fe8df0141e2b875d9f27b07df5feb33c6c38605 Author: James Clark Date: Tue Sep 15 11:58:17 2026 +0700 net: macb: fix ordering around PTP timestamp read [ Upstream commit 9ca4ba24259183ce15665be86b2956cd896c4687 ] PTP_SYS_OFFSET_EXTENDED returns system timestamps that do not correctly bracket the PHC register read on MACB/GEM. On a Raspberry Pi 5, the returned interval can be as short as 37 ns, while an ordered register read takes approximately 1 us. This biases the midpoint used by phc2sys, causing CLOCK_REALTIME to run approximately 0.5 us ahead when synchronized to the PHC. gem_tsu_get_time() reads the nanoseconds register using the driver's relaxed MMIO accessor. On weakly ordered systems, the subsequent system timestamp can be taken before the register read completes. The internal smp_rmb() in the pre-timestamp path also does not guarantee ordering against the subsequent MMIO read. Add rmb() before and after the bracketed nanoseconds read in both the normal and seconds rollover paths so the system timestamps bracket the PHC read. Adding the post-read barrier increases the minimum interval on the same Raspberry Pi 5 to approximately 1 us. Fixes: e51bb5c2784c ("net: macb: ptp: Switch to gettimex64() interface") Tested-by: Nicolai Buchwitz # Raspberry Pi CM5, min bracket 37 ns -> 981 ns Reviewed-by: Nicolai Buchwitz Reviewed-by: Théo Lebrun Assisted-by: LLM Signed-off-by: James Clark Link: https://patch.msgid.link/20260915045823.76100-1-jjc@jclark.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d8c6a18c0552135cbf0c696c9019b2979d0862c9 Author: Jinke Han Date: Tue Sep 8 15:37:42 2026 +0800 x86/kprobes: Fix crash when probing CS CALL instructions [ Upstream commit a5f7a5bb3b7f28ba7e4fa246775b29a0e5537255 ] When using eBPF to probe CS CALL instructions within a function, a crash can be triggered. The eBPF tool probes offset 257 of the __hrtimer_run_queues() function: <__hrtimer_run_queues+249>: nopl 0x0(%rax,%rax,1) <__hrtimer_run_queues+254>: mov %r14,%rdi <__hrtimer_run_queues+257>: cs call <__x86_indirect_thunk_r12> <__hrtimer_run_queues+263>: mov %eax,%r12d <__hrtimer_run_queues+266>: xchg %ax,%ax <__hrtimer_run_queues+268>: mov %r13,%rdi Which triggers this crash: BUG: unable to handle page fault for address: 00000000000f41c9 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: P RIP: 0010:__hrtimer_run_queues+0x106/0x230 Note that __hrtimer_run_queues+0x106 is __hrtimer_run_queues+262, which is at the 6th byte of the above CS CALL instruction. Since the CS CALL instruction occupies 6 bytes, the exception occurred in the middle of that call instruction. The root cause is that when using eBPF tools to probe in the middle of a function, a kprobe with INT3 is used as the underlying implementation. During single-step emulation of the original CALL instruction, int3_emulate_call() assumes that the probed CALL instruction is 5 bytes long. However, the actual CS-prefixed CALL instruction occupies 6 bytes, so it constructs an incorrect exception return address. When the CPU returns from the kprobe handler, the next instruction to be executed is at the address of the last byte of that CS CALL instruction. Coincidentally, starting from that address, the CPU fetches and decodes a completely different instruction, which ultimately triggers a kernel crash. Fix the issue by using the actual instruction length obtained from the instruction decoder when constructing the exception return address, rather than relying on the hardcoded CALL_INSN_SIZE macro. [ mingo: Refined the changelog ] Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step") Suggested-by: Masami Hiramatsu (Google) Signed-off-by: Jinke Han Signed-off-by: Ingo Molnar Reviewed-by: Masami Hiramatsu (Google) Acked-by: Yafang Shao Acked-by: Borislav Petkov Cc: Peter Zijlstra Link: https://patch.msgid.link/20260908073742.GA10517@didi-ThinkCentre-M920t-N000 Signed-off-by: Sasha Levin commit c8c8c18862337c469e325c207601de3279847809 Author: Daniel Zahka Date: Tue Sep 15 16:11:37 2026 -0700 net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb() [ Upstream commit a41f24c612c3f5139a3143307eb85bbcf1bd4d07 ] PSP conflicts with TLS ULP in its usage of both skb->decrypted and sk->sk_validate_xmit_skb(). Make PSP mutually exclusive with TLS ULP, the only other user of either of these. As other users of skb->decrypted come along, they can be added to sk_has_decrypt_user(). It would make sense to also assert that sk->sk_validate_xmit_skb() is also NULL in both of these setup paths for similar future proofing, but the PSP listener/sk_clone() path is still broken and it could be seen as a regression to not allow rx assoc to run on a child of a listener socket with PSP tx assoc state. Include all TCP ULPs in the sk_has_decrypt_user() check, even though TLS is the only one that conflicts with PSP via the decrypted bit. This is intentional because PSP was not designed to be used with ULPs. It is best to close off surface area that may make bugs reachable, until someone wishes to design and test an actual user of PSP with ULPs. Fixes: 6b46ca260e22 ("net: psp: add socket security association code") Signed-off-by: Daniel Zahka Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260915-psp-ktls-fix-v2-1-0eedc3b148ec@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 175683534383bb8150d83ecf75afba66c42f2aa6 Author: Lorenzo Bianconi Date: Fri Sep 11 10:58:30 2026 +0200 net: stmmac: preserve real_num_tx_queues on mqprio setup failure [ Upstream commit 02fffd1939f6b45892f61822459953ce95e42948 ] With the FPE preemption-class mapping error now propagated from stmmac_fpe_map_preemption_class(), tc_setup_dwmac510_mqprio() can fail on the mapping step. The error path used to call stmmac_reset_tc_mqprio(), which resets the number of real TX queues to priv->plat->tx_queues_to_use (the platform maximum), overwriting the value that was active before the offload was attempted (for example a lower count left over from a previous mqprio configuration). The issue can be triggered using the following configuration: # First mqprio config lowers the hw queue count below the platform # default (e.g. 8 TX queues). $tc qdisc add dev eth0 root handle 1: mqprio queues 2@0 2@2 # Replace mqprio configuration with a second one that fails FPE # preemption-class mapping. stmmac driver resets the real_num_tx_queues # to the platform maximum, losing the previous configuration. $tc qdisc replace dev eth0 root handle 2: mqprio queues 2@0 2@2 fp E P Save ndev->real_num_tx_queues before lowering it and restore it, together with the TC-to-queue and priority-to-TC mappings, when the FPE preemption-class mapping fails, instead of resetting the queue count to the platform maximum. Note that a failed setup makes the qdisc layer run mqprio_destroy() on the new qdisc. Because priv->hw_offload is only assigned after ndo_setup_tc() succeeds, mqprio_destroy() calls netdev_set_num_tc(dev, 0), so dev->num_tc ends up 0 regardless of the driver-side restore and the previous qdisc is not reactivated. The restore is still needed to keep real_num_tx_queues and to avoid leaving the failed configuration's TC-to-queue and priority-to-TC mappings in place. Fixes: 195e4f409a40 ("net: stmmac: support fp parameter of tc-mqprio") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260911-stmmac-tc_setup_dwmac510_mqprio-error-path-v3-2-a76b1e2547c1@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ff8c49b2760a16bcf1618b1566452a13b7e77b49 Author: Eric Dumazet Date: Wed Aug 12 08:54:38 2026 +0000 net: prevent torn reads in netdev_tc_txq [ Upstream commit 21ef2d065ad3f0cfbf2ae51260bf962a9fa2c643 ] netdev_set_tc_queue() (and related helpers/drivers such as netdev_bind_sb_channel_queue(), netdev_reset_tc(), and netdev_unbind_sb_channel()) perform separate 16-bit writes to dev->tc_to_txq[tc].count and dev->tc_to_txq[tc].offset. Furthermore, memset() in netdev_reset_tc() and netdev_unbind_sb_channel() provides no guarantee of performing full 32-bit word stores. Concurrent lockless readers (e.g. skb_tx_hash(), netdev_txq_to_tc(), ixgbe_select_queue(), taprio, mqprio, FPE drivers) can observe torn values where offset and count belong to inconsistent configurations. Redefine struct netdev_tc_txq to embed count and offset inside a union with a u32 combined field, allowing atomic manipulation via READ_ONCE() and WRITE_ONCE(). Update all lockless readers and writers across the kernel to use READ_ONCE() and WRITE_ONCE() on the combined field. Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260812085440.3917924-2-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 02fffd1939f6 ("net: stmmac: preserve real_num_tx_queues on mqprio setup failure") Signed-off-by: Sasha Levin commit c0ad9a0aa8ebe584411b168f13ed5fc66a2806dc Author: Lorenzo Bianconi Date: Fri Sep 11 10:58:29 2026 +0200 net: stmmac: propagate FPE preemption-class mapping errors [ Upstream commit 90e4b849dfa6fc8e6c050bcfe1b331b69c015d28 ] stmmac_fpe_map_preemption_class() dispatches through the stmmac_do_void_callback() helper, which forces the callback's return value to 0 whenever the op pointer is populated. As a result the -EINVAL returned by dwmac5_fpe_map_preemption_class() (e.g. when a preemptible TC owns more than one TXQ under SP scheduling) is silently swallowed by every caller. Switch the dispatch macro to stmmac_do_callback() so the callback's real result is propagated, and honour it in the taprio and mqprio qdisc offload. Note that the taprio "if (ret)" check in tc_taprio_configure() used to be dead code and now becomes live: a preemptible TC spanning more than one TXQ under SP scheduling cannot be programmed in hardware, so a taprio or mqprio configuration that previously returned success while leaving the preemption-class register unprogrammed now fails with -EINVAL. For taprio, the failure also runs the disable path, tearing down the schedule that was just installed; this is the intended behaviour. Fixes: 195e4f409a40 ("net: stmmac: support fp parameter of tc-mqprio") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260911-stmmac-tc_setup_dwmac510_mqprio-error-path-v3-1-a76b1e2547c1@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d4bd670454390aab72ab9fb7b73bce2966c33fe3 Author: Linus Walleij Date: Mon Sep 14 23:26:41 2026 +0200 net: ethernet: cortina: Ack RX overrun interrupt correctly [ Upstream commit 1dd85662fee6e2ac580b1c4f9a0c0a7ae6e31f0e ] The RX overrun interrupt is reported in interrupt status register 4, but gmac_irq() acknowledges it using the RX descriptor error bit from status register 0. For GMAC0 this writes the GMAC1 overrun bit, while for GMAC1 the shift leaves no bit in the 32-bit register. Acknowledge the same per-port RX overrun bit that was detected. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20260914-b4-gemini-ethernet-fixes-2-v2-1-5ab39a047b90@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 899650bbf985b7bfd2a7b808357df9b16e6d6959 Author: Eric Dumazet Date: Tue Sep 15 04:30:54 2026 +0000 net: lock the socket in sock_gettstamp() [ Upstream commit 9ed55f3dbef4f4adfe65eb03b0c35c53229a8490 ] sk->sk_flags must only be changed while holding the socket lock, because sock_set_flag() and sock_reset_flag() use non atomic operations (__set_bit() and __clear_bit()). sock_gettstamp() is one of the last places where a bit of sk->sk_flags is changed from a syscall without owning the socket lock, through sock_enable_timestamp(sk, SOCK_TIMESTAMP). sk_set_memalloc() and sk_clear_memalloc() also change sk->sk_flags without the socket lock, but their callers (nbd, iscsi_tcp, nvme-tcp, sunrpc, wireguard) need a careful audit, this will be addressed in a separate patch. Jungwoo Lee and Wongi Lee reported an UDP socket use-after-free caused by this bug: a SIOCGSTAMPNS_NEW ioctl racing with bind() can cancel the SOCK_RCU_FREE bit that udp_lib_get_port() just set, because both threads perform a read-modify-write on the same word. CPU 0 (bind) CPU 1 (SIOCGSTAMPNS_NEW) -------------------------------- ---------------------------- read sk_flags = F read sk_flags = F compute F | BIT(SOCK_RCU_FREE) compute F | BIT(SOCK_TIMESTAMP) store F | BIT(SOCK_RCU_FREE) sk_add_node_rcu(sk, ...) store F | BIT(SOCK_TIMESTAMP) After the lost update, SOCK_RCU_FREE is clear while the socket is visible to lockless UDP receive lookups. sk_destruct() then frees the socket immediately instead of waiting for a RCU grace period, while the receive path still holds a reference-less pointer to it: BUG: KASAN: slab-use-after-free in ipv4_pktinfo_prepare+0x30/0x410 Read of size 8 at addr ffff888008806610 by task exploit/207 CPU: 0 UID: 1000 PID: 207 Comm: exploit Not tainted 6.12.95+ #1 ipv4_pktinfo_prepare+0x30/0x410 udp_queue_rcv_one_skb+0x51c/0x1180 udp_unicast_rcv_skb+0x109/0x350 ip_protocol_deliver_rcu+0x14b/0x310 ip_local_deliver_finish+0x29d/0x390 ip_local_deliver+0x24d/0x2a0 Only grab the socket lock when SOCK_TIMESTAMP has to be set, to keep the common case lockless. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Jungwoo Lee Reported-by: Wongi Lee Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260915043055.3441600-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 28fb764d670aa22dcbd2a02fd8fd87ae8d3563a9 Author: Jakub Kicinski Date: Mon Sep 14 19:23:27 2026 -0700 eth: fbnic: ring the doorbell if a burst ends in a drop [ Upstream commit 490599ab23134962a6d18a024e84541d77bdb999 ] fbnic_tx_map() skips the doorbell write, and the completion request, for every packet handed to it with xmit_more set, counting on the packet which ends the burst to publish them all. When that packet is dropped instead - skb_put_padto(), skb_cow_head() or a DMA mapping failure - nothing rings. The descriptors of the preceding packets stay invisible to the HW until the next transmit on that queue, which for a burst-then-idle workload may never come. Remember the meta descriptor of the last packet left without a doorbell and flush it from the error paths. The completion request has to be set on that descriptor rather than simply writing the tail, otherwise the HW would transmit the packets but never report a head, and the ring would fill up and stall for good. This is very similar to Joe's recent series of fixes for bnxt. Not seen in real life, reproduced under QEMU with failure injection. Fixes: 9a57bacd574b ("eth: fbnic: Add basic Tx handling") Reviewed-by: Alexander Duyck Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260915022327.913218-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c87c82e40824c7d710c2270fbe160427f8761293 Author: Yige Jiang Date: Sun Sep 13 14:41:02 2026 +0800 net: netsec: fix device_node reference leak on phy_np [ Upstream commit 5ae916fabca141b79b32e2e57f3c915c0f1e1b2e ] netsec_of_probe() takes a reference on the PHY device_node with of_parse_phandle() and stores it in priv->phy_np, but the driver never drops it. One device_node reference is leaked per probe, on the success path as well as on every error path reached after netsec_of_probe(). Neither consumer takes ownership. of_mdio_parse_addr() is a static inline taking a const struct device_node * that only reads the "reg" property. of_phy_connect() borrows as well: of_phy_get_and_connect() in drivers/net/mdio/of_mdio.c brackets its own call with of_node_get() at :364 and of_node_put() at :373, which would be a double put if of_phy_connect() consumed the reference. The node is still in use at netsec_netdev_open() time, where it is passed to of_phy_connect(), so it has device lifetime. Release it at the probe error label, which every failure path after the acquire funnels through, and in netsec_remove(). Both releases precede free_netdev(), since priv is netdev_priv(ndev). The ACPI probe path leaves priv->phy_np NULL and of_node_put(NULL) is a no-op. There is no end-user visible symptom on currently supported platforms: a device_node is only freed once OF_DYNAMIC is enabled and the node has been detached, so on a static device tree the imbalance is inert. It is observable as a refcount that grows across bind/unbind cycles, and would matter under device tree overlays. Found by static analysis of reference acquire/release pairing rather than from a runtime report. No reproducer was produced and the change has not been runtime tested; it is compile-tested only (arm64, CONFIG_SNI_NETSEC=m via COMPILE_TEST). Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Yige Jiang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260913064102.37452-1-yigejiang86@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d8eb177632dacda28bc6130c2105afbf5b791eb0 Author: Farhad Alemi Date: Sat Sep 12 07:40:09 2026 +0000 net: remove WARN_ON_ONCE() from the dev_fill_forward_path() loop check [ Upstream commit 150dba2c69e93302af24a0c868eebe4871e2e107 ] ipip_fill_forward_path() and ip6_tnl_fill_forward_path() look up the route to the tunnel's remote endpoint and set ctx->dev to its device, which is the tunnel itself when that route resolves back to the tunnel. dev_fill_forward_path() then makes no progress and trips WARN_ON_ONCE(last_dev == ctx->dev) as soon as a flowtable tries to offload a flow through the tunnel. That routing loop is a configuration any CAP_NET_ADMIN user can set up, and ip_tunnel_xmit() and ip6_tnl_xmit() already treat it as a tx error, so remove the warning and just fail the walk, as commit 008e7a7c293b ("net: remove WARN_ON_ONCE when accessing forward path array") did for the path stack overflow. Fixes: ab427db17885 ("netfilter: flowtable: Add IPIP rx sw acceleration") Fixes: d98103575dcd ("netfilter: flowtable: Add IP6IP6 rx sw acceleration") Closes: https://lore.kernel.org/all/CA+0ovCgaRvbd0Udj70b2xxG8Cx3CaCpNhnf1V4RWQuDveZYZhA@mail.gmail.com/ Suggested-by: Pablo Neira Ayuso Signed-off-by: Farhad Alemi Reviewed-by: Xuanqiang Luo Link: https://patch.msgid.link/CA+0ovCgKDOk+Bg6Gh5Lwx94u_jJjQ30-vY1JcY2BYfhnWJJbPA@mail.gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3c33b7feadd45495682ac67ec39f247d2e87b9eb Author: Lorenzo Bianconi Date: Thu Aug 6 23:09:03 2026 +0200 net: pass net_device_path_ctx to dev_fill_forward_path() [ Upstream commit 95133a416809c7e822da4023b7f4193ef2620796 ] Refactor dev_fill_forward_path() to take a struct net_device_path_ctx pointer instead of a (dev, daddr) pair, so the caller can build and populate the context up front and keep it after the forward path walk. This allows additional fields (e.g. vlan and ether_type) to be carried in the context and shared with ndo_fill_forward_path implementations, instead of being reconstructed on the stack inside the core helper. Update the mtk_ppe_offload, airoha_ppe and nf_flow_table_path callers to allocate and fill the context before invoking dev_fill_forward_path(). The network topology resolution behaviour is unchanged. This is a preliminary patch to enable HW flowtable offload for IPv4 over IPv6 tunnels. Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 150dba2c69e9 ("net: remove WARN_ON_ONCE() from the dev_fill_forward_path() loop check") Signed-off-by: Sasha Levin commit b6a0451b096820970520894e84f8fd6b2b0d7504 Author: Pablo Neira Ayuso Date: Tue Jul 28 18:30:48 2026 +0200 net: pass dst via net_device_path in dev_fill_forward_path() [ Upstream commit 0ad8404e776698de4dac5cc0df3be68d344e741c ] Add dst_entry to tunnel device path, this will allow us to remove a duplicated route lookup. This is a preparation patch to retrieve the tunnel route directly from the .fill_forward_path. This new dst_entry in the tunnel will be used by a follow up patch. Since dst_release() works fine on NULL interface, this is still noop until the flowtable starts using this. Add a new dev_fill_forward_path_release() function to drop the refcount on the tunnel device route and use it in case of error out. Export it so to drop the refcount on the tunnel route at a later stage. Adjust existing drivers that recycle dev_fill_forward_path() to call dev_fill_forward_path_release() for safety reasons. Acked-by: Lorenzo Bianconi Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 150dba2c69e9 ("net: remove WARN_ON_ONCE() from the dev_fill_forward_path() loop check") Signed-off-by: Sasha Levin commit 17f528ffa7545b38a5a39d7284e5669b3f19f5e3 Author: Pablo Neira Ayuso Date: Tue Jul 28 18:30:46 2026 +0200 net: do not advance stack index from dev_fwd_path() [ Upstream commit 5deda60c56eeeab25beb10cf4d48e07587076b11 ] Update stack index from dev_fill_forward_path() instead, once the forward path slot has been populated. Acked-by: Lorenzo Bianconi Signed-off-by: Pablo Neira Ayuso Stable-dep-of: 150dba2c69e9 ("net: remove WARN_ON_ONCE() from the dev_fill_forward_path() loop check") Signed-off-by: Sasha Levin commit bacd72289d34d8c05b7de5a12448b87b6dd93878 Author: Jamal Hadi Salim Date: Sat Sep 12 14:08:30 2026 -0400 net/sched: codel: bound the dropping loop per dequeue call [ Upstream commit 7f4a5ec6258fd7c92633ec4b0493fc51166d9398 ] The CoDel control law schedules the next drop one interval/sqrt(count) after the previous drop, using the configured interval (codel_params.interval). For very small intervals the scheduled step rounds down to zero, so the dropping loop in codel_dequeue() never advances and drains the entire backlog under the qdisc lock in one call - an unprivileged user can trigger a soft lockup this way. Fix in the shared codel code used by both codel and fq_codel: 1. Make the control-law step at least 1 tick so the dropping loop always moves forward. 2. Cap the dropping loop at CODEL_MAX_DROPS_PER_DEQUEUE (256) drops per codel_dequeue() call, resyncing drop_next to now when the cap is hit: the catch-up owed to the loop grows with the idle gap and the backlog, which no interval threshold can bound. This is a deliberate behaviour change after long idle gaps. The cap applies to fq_codel (4b549a2ef4be) and the mac80211 TXQ path (fixed interval, cap only). The target sojourn delay (codel_params.target) is not validated: it does not feed the control law, so a sub-tick value is aggressive rather than deadlock-prone. Conditions to recreate the bug: - tc qdisc add dev lo root handle 1: tbf rate 1kbit burst 2kb limit 1000000 - tc qdisc add dev lo parent 1:1 handle 10: codel interval 2us target 1ms noecn limit 1000000 (same for fq_codel) - unpatched kernel: tc accepts it; a UDP flood under the 1kbit tbf soft-lockups (watchdog: BUG: soft lockup) while one codel_dequeue() call drops the backlog under the qdisc lock - patched kernel: same setup, at most 256 drops per dequeue call, no soft lockup Testing: claim reproducer and interval 2us/3us variants run clean; tdc qdisc category passes (see the selftests patch). Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Reported-by: Vega Reviewed-by: Eric Dumazet Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/QDISC-1L5H.v1.20260912080102@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 70561730726b02ecb90357b1fac5796d2b5e65af Author: Vijendar Mukunda Date: Thu Sep 10 21:46:48 2026 +0530 ASoC: amd: acp: fix ffs() operator precedence for SoundWire link ID [ Upstream commit 27098aaf28b96ab4e6891709062c343566d4882b ] ffs(link_mask - 1) computes ffs on (link_mask - 1) instead of subtracting 1 from the result of ffs(link_mask). For a typical power-of-2 link_mask this returns the wrong link ID, causing cpu_pin_id lookup to select the incorrect SoundWire manager. Fix the operator precedence to ffs(link_mask) - 1 in both acp-sdw-sof-mach.c and acp-sdw-legacy-mach.c. Fixes: 6d8348ddc56e ("ASoC: amd: acp: refactor SoundWire machine driver code") Signed-off-by: Vijendar Mukunda Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260910161728.1452808-4-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 255c391c7135d9846390f6c32affef2b075e3246 Author: Vijendar Mukunda Date: Thu Sep 10 21:46:47 2026 +0530 ASoC: amd: acp: refactor codec config count in SOF SoundWire machine driver [ Upstream commit 0b7d55d3a91200f2b1ed710f525a944b0a7d6369 ] num_devs was used both as the endpoint count and as the output for asoc_sdw_parse_sdw_endpoints(), which overwrites it with the codec configuration count. Introduce a separate num_confs variable to hold the codec conf count so the two values remain distinct across codec_conf allocation and card->num_configs assignment. Fixes: 6d8348ddc56e ("ASoC: amd: acp: refactor SoundWire machine driver code") Signed-off-by: Vijendar Mukunda Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260910161728.1452808-3-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 83ce3fb63171e6496ae37bf8ca2026b2d8159693 Author: Kuninori Morimoto Date: Fri Jun 26 05:45:15 2026 +0000 ASoC: sdw_utils: tidyup asoc_sdw_parse_sdw_endpoints() [ Upstream commit a1332be2a07090cf422507ec812ce2b9ba0a558a ] We can avoid to use *card. Tidyup it. Current code makes old style / new style conversion difficult. To make future conversions easier to understand, this patch clean up the code a little. but no functional change. Signed-off-by: Kuninori Morimoto Reviewed-by: Cezary Rojewski Reviewed-by: Vijendar Mukunda Link: https://patch.msgid.link/87ik75etxw.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Stable-dep-of: 0b7d55d3a912 ("ASoC: amd: acp: refactor codec config count in SOF SoundWire machine driver") Signed-off-by: Sasha Levin commit b34214b6c962e4e1de6bb6bf8bd7bde89ec73143 Author: Kuninori Morimoto Date: Fri Jun 26 05:45:10 2026 +0000 ASoC: sdw_utils: tidyup .count_sidecar [ Upstream commit c97f0bf5f705b16d150f2b0d5ce0ee24eee4f68a ] count_sidecar() is not using *card. Tidyup it. Current code makes old style / new style conversion difficult. To make future conversions easier to understand, this patch clean up the code a little. but no functional change. Signed-off-by: Kuninori Morimoto Reviewed-by: Cezary Rojewski Link: https://patch.msgid.link/87jyrlety1.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Stable-dep-of: 0b7d55d3a912 ("ASoC: amd: acp: refactor codec config count in SOF SoundWire machine driver") Signed-off-by: Sasha Levin commit 0bd12e2ab2059550a5b608a251ce9b66fab3089e Author: Vijendar Mukunda Date: Thu Sep 10 21:46:46 2026 +0530 ASoC: amd: acp: bounds-check SoundWire link ID in machine drivers [ Upstream commit 29218a4d11a31a8157389bc2b9e62dd768d7ea42 ] Add a bounds check in create_sdw_dailink() to validate that the SoundWire link ID derived from link_mask does not exceed the maximum supported by the platform. If the link ID is out of range or link_mask is zero, log an error and return -EINVAL to prevent accessing invalid CPU pin ID tables. Applied to both acp-sdw-sof-mach.c and acp-sdw-legacy-mach.c. Fixes: 6d8348ddc56e ("ASoC: amd: acp: refactor SoundWire machine driver code") Signed-off-by: Vijendar Mukunda Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260910161728.1452808-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 03588d05a105c85992c027711929615784388d5b Author: Richard Fitzgerald Date: Mon Sep 14 13:26:11 2026 +0100 ASoC: cs-amp-lib: Prevent NULL pointer if efi variable is zero length [ Upstream commit 3482062c786ce4233f8ed3224d824184f53ec154 ] In cs_amp_alloc_get_efi_variable() the first call to cs_amp_get_efi_variable() might return EFI_SUCCESS if the variable exists with zero length. Trap this and return -ENOENT to prevent returning an unexpected NULL pointer. The first cs_amp_get_efi_variable() call was assumed to return EFI_BUFFER_TOO_SMALL if the variable existed, but if instead it returned EFI_SUCCESS this would be converted to 0 by cs_amp_convert_efi_status() and then be returned as a NULL pointer. Fixes: 00fd40bc7acec ("ASoC: cs-amp-lib: Support Dell SSIDExV2 UEFI variable") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260914122611.2783563-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 165ab330321f8a802a8185b23ab072226acfab96 Author: HyeongJun An Date: Tue Sep 15 18:25:15 2026 +0900 ASoC: hdmi-codec: Report a change when the channel status moves [ Upstream commit c17ae8c26eac16ad244daef44044d714f68a2ddc ] The put() callback of "IEC958 Playback Default" stores all 24 channel status bytes and then returns 0. The core notifies userspace only on a positive return, so a write that changes what the get() callback hands back is never announced, and a mixer holding the control open keeps showing the old value. Compare the stored bytes and return 1 when they move, the way snd_hda_spdif_default_put() does. The same shape is in img-spdif-out and uniperif_player. No board with this codec was to hand. The change is a comparison of driver state with no hardware behaviour in it, and mixer-test counts the missing notification as event_missing. Fixes: 7a8e1d44211e ("ASoC: hdmi-codec: Add iec958 controls") Signed-off-by: HyeongJun An Assisted-by: Claude:claude-opus-5 Link: https://patch.msgid.link/20260915092515.2638542-1-sammiee5311@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d9803c64bb1b50b4c79618ad894d53ce7ac47a57 Author: Sasha Levin Date: Sun Sep 13 13:31:32 2026 -0400 ASoC: ux500: Parenthesize MSP_{RX,TX}_CLKPOL_BIT() arguments [ Upstream commit 11fc0048a6930f4fca44fe3bd16a0023e78846a2 ] arm allmodconfig fails to build with gcc: In file included from sound/soc/ux500/ux500_msp_i2s.c:20: sound/soc/ux500/ux500_msp_i2s.h:151:38: error: suggest parentheses around arithmetic in operand of '^' [-Werror=parentheses] sound/soc/ux500/ux500_msp_i2s.c:204:21: note: in expansion of macro 'MSP_TX_CLKPOL_BIT' cc1: all warnings being treated as errors The macros never parenthesized their argument: #define MSP_TX_CLKPOL_BIT(n) ((n & TCKPOL_MASK) << TCKPOL_SHIFT) That went unnoticed while every caller passed a plain variable, but configure_protocol() now passes an XOR expression, which binds as "a ^ (b & MASK)" rather than "(a ^ b) & MASK", and gcc rightly complains. No functional change: tx_clk_pol and rx_clk_pol only ever hold MSP_FALLING_EDGE (0) or MSP_RISING_EDGE (1), and bclk_inverted is a bool, so masking before or after the XOR gives the same 0/1 result. Parenthesize the argument anyway - it fixes the build and stops the macros from silently mis-evaluating a future composite argument. Fixes: 9ccbacf5a012 ("ASoC: ux500: Validate MSP DAI configuration") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202609051547.G9SJp8UQ-lkp@intel.com/ Assisted-by: LLM Signed-off-by: Sasha Levin Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260913173132.1172003-1-sashal@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit efa5780b84f066f419a667f6b9542368b2f62074 Author: Daniel Linjama Date: Wed Sep 16 09:15:56 2026 +0300 btrfs: handle lack of space when cleaning up verity items [ Upstream commit 76bf149cd0298544631e756670b89c399c7acbca ] When enable_verity() hits the qgroup limit, rollback_verity() needs its own metadata reservation. When the qgroup limit or lack of space refuses the rollback, the whole filesystem is forced read-only even though the qgroup limit was for one subvolume only. Also orphan cleanup at the next mount fails the same way, so the leftover items are never removed: with -EDQUOT the subvolume stays unreachable, and with -ENOSPC on a full filesystem the next read-write mount fails. Start transactions with btrfs_start_transaction_fallback_global_rsv() in btrfs_orphan_cleanup(), drop_verity_items() and rollback_verity(). Those calls only delete items and free the space in the end, so they may use the global reserve and skip the qgroup limit, which avoids -ENOSPC and -EDQUOT. Fixes: 146054090b08 ("btrfs: initial fsverity support") Reviewed-by: Qu Wenruo Signed-off-by: Daniel Linjama Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 571ccbc801aa4d22a22d9f924b826c77052330f0 Author: Raag Jadav Date: Fri Sep 11 17:45:47 2026 +0530 drm/xe/i2c: Disable IRQ on unbind [ Upstream commit f0e9f963a3d209d7dc7ddd61116118ab5da2797d ] Currently, struct xe_i2c is freed before SGUnit IRQ is disabled in unbind path, leaving a potential UAF in case I2C IRQ is hit during this small window. Explicitly disable I2C IRQ in xe_i2c_remove() and fix this. Fixes: 0bb78ce09926 ("drm/xe/i2c: Wire up reset/postinstall for I2C IRQ") Signed-off-by: Raag Jadav Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260911121547.2407261-1-raag.jadav@intel.com Signed-off-by: Matt Roper (cherry picked from commit 8ba5c8b8ab3fd362267c11df2cd5a90ee46f6e24) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit eecbafa8cabbc4d1482f6a5e2acc25a8f934681b Author: Peter Zijlstra Date: Fri Sep 11 11:04:47 2026 +0200 futex: Also allocate private hash on vfork() [ Upstream commit b61b6f95d6722ddbbbd09e689fa41b55fd36f9a5 ] As Jann demonstrated, it is entirely feasible to access the mm through vfork(). Therefore we need to allocate a private hash on vfork() as well as any other CLONE_VM user. Specifically, it must be avoided to have (private) futex waiters before allocating the private hash. Fixes: ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private default hash alloc") Reported-by: Jann Horn Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260911090447.GT788244@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 41ed0080181cdbcaee8965de6452cdcb05b0521e Author: Nemesa Garg Date: Wed Sep 9 16:33:31 2026 +0530 Revert "drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable" [ Upstream commit a26204be587c57bd5c54fa513be26c4fd7bf252d ] This reverts commit 7f1172a2ac0d7e50850785e2e65789c8aac8411a. This commit replaced the crtc_state->enable_psr2_sel_fetch guard in icl_plane_disable_sel_fetch_arm() and i9xx_cursor_disable_sel_fetch_arm() with HAS_PSR2_SEL_FETCH(). This is a display version check and says nothing about the pipe, so every plane and cursor disable on a display 12+ platform started writing SEL_FETCH_PLANE_CTL() / SEL_FETCH_CUR_CTL(), including on pipes that do not implement them. It shows up as an unclaimed register access on pipes driving HDMI where selective fetch was never enabled. The stale selective fetch enable bit that commit addressed is handled in the next patch. Fixes: 7f1172a2ac0d ("drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16876 Signed-off-by: Nemesa Garg Reviewed-by: Jouni Högander Signed-off-by: Suraj Kandpal Link: https://patch.msgid.link/20260909110332.3528029-2-nemesa.garg@intel.com (cherry picked from commit d393529394167e0f5f706657eebe84d8529ce4fc) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 314091243159f8e3749bc719bb129f423f72fd86 Author: Shivaprasad G Bhat Date: Tue Sep 15 22:04:17 2026 +0530 powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba [ Upstream commit 0b271f7d7f5ed45bc498a03ce0aa9cfd8402fc71 ] The commit b1af23d836f8 ("KVM: PPC: iommu: Unify TCE checking") unified IOBA parameter checking across KVM and VFIO into iommu_tce_check_ioba(). While doing so, the passed in argument npages is ignored and constant value '1' is used leaving out a possible overflow as the callers can legitimately be using npages > 1 for H_STUFF_TCE or H_PUT_TCE_INDIRECT cases. Fix this by accounting for 'npages', checking for arithmetic overflow, and verifying that the entire requested range (ioba - offset + npages) does not exceed the table capacity 'size'. Fixes: b1af23d836f8 ("KVM: PPC: iommu: Unify TCE checking") Reviewed-by: Ritesh Harjani (IBM) Tested-by: R Nageswara Sastry Signed-off-by: Shivaprasad G Bhat Signed-off-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan Signed-off-by: Sasha Levin commit fcbff8008b0e08cd53b611bd0ff7e01f5b962f80 Author: Amit Machhiwal Date: Tue Sep 15 22:04:16 2026 +0530 KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure [ Upstream commit 0a416ee20bcccddf91ca5b63696a23b9d11d73aa ] In kvmppc_svm_page_in(), if uv_page_in() fails after kvmppc_uvmem_get_page() has succeeded, the secure device page is never released. kvmppc_uvmem_get_page() sets a bit in kvmppc_uvmem_bitmap, allocates a kvmppc_uvmem_page_pvt struct, marks the GFN as KVMPPC_GFN_UVMEM_PFN, and calls zone_device_page_init() which sets refcount=1 and locks the page. The subsequent goto out_finalize skips the *mig.dst assignment, so migrate_vma_finalize() is a no-op for the page, and none of those resources are ever reclaimed. Each occurrence permanently consumes one entry from the firmware-bounded secure memory pool (kvmppc_uvmem_bitmap), leaks pvt, and leaves the GFN marked as secure — making it unusable for the lifetime of the VM. The twin __kvmppc_svm_page_out() already handles the analogous uv_page_out() failure correctly with unlock_page(dpage); __free_page(dpage). Apply the same pattern here: unlock_page() followed by put_page(), which chains through free_zone_device_folio() into kvmppc_uvmem_folio_free() to clear the bitmap bit, free pvt, and reset the GFN state. Reachable whenever uv_page_in() returns an error (e.g. UV pool exhaustion) on any POWER9/10 + Ultravisor/PEF system. Fixes: ca9f4942670c ("KVM: PPC: Book3S HV: Support for running secure guests") Reviewed-by: Ritesh Harjani (IBM) Tested-by: R Nageswara Sastry Signed-off-by: Amit Machhiwal Signed-off-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan Signed-off-by: Sasha Levin commit ec2d7a52b3996ae81131617b4afc0af31583c1b4 Author: Amit Machhiwal Date: Tue Sep 15 22:04:15 2026 +0530 KVM: PPC: Book3S HV: fix use-after-free in kvmhv_emulate_tlbie_all_lpid() [ Upstream commit 51938dfa8a51a4f85328413fca9b6e21f9d2d088 ] kvmhv_emulate_tlbie_all_lpid() iterates the nested-guest IDR and drops mmu_lock before calling kvmhv_emulate_tlbie_lpid(), but does not hold a reference on the kvm_nested_guest pointer obtained from the IDR. A concurrent vCPU issuing a single-LPID tlbie (is=2, ric=2) can race through kvmhv_flush_nested() -> kvmhv_remove_nested() -> idr_remove / --refcnt -> kvmhv_release_nested() -> kfree(gp) in that window, leaving the iterating vCPU with a dangling pointer. The subsequent mutex_lock(&gp->tlb_lock) and accesses to gp->shadow_pgtable, gp->shadow_lpid and gp->l1_host all touch freed memory. The free path is fully L1-controlled. Fix this by incrementing gp->refcnt inside the loop before dropping mmu_lock, mirroring what kvmhv_get_nested() does, and releasing the reference with kvmhv_put_nested() after the per-guest work completes. This is the same get/put discipline already used at every other call site that drops mmu_lock while holding a nested-guest pointer. Fixes: e3b6b4661527 ("KVM: PPC: Book3S HV: Implement H_TLB_INVALIDATE hcall") Reviewed-by: Ritesh Harjani (IBM) Tested-by: R Nageswara Sastry Signed-off-by: Amit Machhiwal Signed-off-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan Signed-off-by: Sasha Levin commit 22f313e211d58a66786c81487c3905fa5d4b2a8f Author: Eric Dumazet Date: Fri Sep 11 16:08:04 2026 +0000 netlink: do not free nlk->groups while lockless readers can use it [ Upstream commit ceac0de741bfb47ca255eee075257b3bb31f0651 ] netlink_realloc_groups() uses krealloc() under netlink_table_grab(). Whenever NLGRPSZ(groups) lands in a different kmalloc bucket, the old bitmap is freed immediately. Two readers of nlk->groups / nlk->ngroups do not hold the netlink table lock: 1) sk_diag_dump_groups(). Hashed (bound) sockets are dumped from the rhashtable walk in __netlink_diag_dump(), which only holds RCU. Only the mc_list part of the dump takes nl_table_lock. 2) netlink_native_seq_show() (/proc/net/netlink), whose walk has been lockless since commit 21e4902aea80 ("netlink: Lockless lookup with RCU grace period in socket release"). Both can read a freed buffer, and sk_diag_dump_groups() can also read past the end of the old (smaller) buffer if it happens to load the old @groups pointer together with the new @ngroups value, copying the result into a NETLINK_DIAG_GROUPS attribute. This is the same class of bug that commit f773608026ee ("netlink: access nlk groups safely in netlink bind and getname") fixed for bind() and getname(); these two readers were missed. Simply grabbing the table lock in sk_diag_dump_groups() is not an option, because it is also called with nl_table_lock already held from the mc_list section of the dump. Make the lockless readers safe instead: - Allocate a new bitmap and free the old one after an RCU grace period, instead of relying on the implicit kfree() done by krealloc(). - Publish @groups before @ngroups, both with release semantics, and have the lockless readers load @ngroups first. A reader can then never pair the new (bigger) size with the old (smaller) buffer, and a reader picking up the new pointer while still seeing the old size is guaranteed to see the initialized bitmap. netlink_realloc_groups() is called from process context (bind() and setsockopt()), so kfree_rcu_mightsleep() can be used, once the table has been released. Fixes: 21e4902aea80 ("netlink: Lockless lookup with RCU grace period in socket release") Fixes: ad202074320c ("netlink: Use rhashtable walk interface in diag dump") Reported-by: James Burton Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260911160804.917099-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ed3ea86db736a30bebf49b947c42730e8451bcd2 Author: Nikolay Aleksandrov Date: Mon Sep 14 13:52:58 2026 +0300 net: bridge: vlan: fix bugs caused by switchdev deletion errors [ Upstream commit 2842ce397dd09882530b42f7fdb0c855767eb24e ] Allowing switchdev to prevent vlan deletion and error out in __vlan_del could cause multiple different issues - inconsistent state, memory leaks when flushing, NULL pointer dereference on bridge error when flushing. It doesn't make sense to allow it to stop __vlan_del, so log the error and continue with software vlan deletion. This is also consistent with 8021q behaviour. Suggested-by: Ido Schimmel Fixes: bf361ad38165 ("net: bridge: check __vlan_vid_del for error") Fixes: 5454f5c28eca ("net: bridge: vlan: check for errors from __vlan_del in __vlan_flush") Fixes: 2594e9064a57 ("bridge: vlan: add per-vlan struct and move to rhashtables") Fixes: 9c86ce2c1ae3 ("net: bridge: Notify about bridge VLANs") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260914105258.3436918-1-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d09c51ce28e4283907d598a6d44840b0d04cd822 Author: Lorenzo Bianconi Date: Mon Sep 14 09:41:07 2026 +0200 net: stmmac: do not overwrite phc_index when no PTP clock is registered [ Upstream commit f0ef4b1eaed000a304726a43091588e8426ba08a ] stmmac_get_ts_info() reports phc_index as 0 when hardware timestamping is supported but no PTP clock has been registered yet (e.g. while the interface is down). Zero is a valid PHC index and would make userspace resolve the wrong clock; the absence of a clock should be reported as -1. The ethtool core already initializes phc_index to -1 before invoking the get_ts_info callback (ethtool_init_tsinfo()), so just drop the erroneous assignment. Fixes: 9364fa7fcf12 ("net: stmmac: Remove setting of RX software timestamp") Reviewed-by: Maxime Chevallier Reviewed-by: Rahul Rameshbabu Signed-off-by: Lorenzo Bianconi Reviewed-by: Gal Pressman Link: https://patch.msgid.link/20260914-stmmac-fix-phc_index-v2-1-bf3d90373fe4@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 03b672eba4937ff18337049824a114012d57f202 Author: Eric Dumazet Date: Thu Sep 10 20:46:12 2026 +0000 drop_monitor: fix out-of-bounds write in reset_per_cpu_data() [ Upstream commit 439f392084f8f7f59ab9d47a9579185accefe1d8 ] In reset_per_cpu_data(), al is computed as: al = sizeof(struct net_dm_alert_msg); al += dm_hit_limit * sizeof(struct net_dm_drop_point); al += sizeof(struct nlattr); skb = genlmsg_new(al, GFP_KERNEL); ... nla = nla_reserve(skb, NLA_UNSPEC, sizeof(struct net_dm_alert_msg)); ... msg = nla_data(nla); memset(msg, 0, al); Because al includes sizeof(struct nlattr) (the 4-byte attribute header), genlmsg_new() allocates al bytes of tailroom starting at nla. However, msg points to nla_data(nla), which is located sizeof(struct nlattr) bytes past nla. Calling memset(msg, 0, al) therefore writes al bytes starting from msg, exceeding the allocated buffer by sizeof(struct nlattr) (4 bytes) and corrupting skb_shared_info. Fix this by letting al represent only the payload length, allocating the skb with genlmsg_new(nla_total_size(al), GFP_KERNEL), and zeroing al bytes from msg. Fixes: 683703a26e46 ("drop_monitor: Update netlink protocol to include netlink attribute header in alert message") Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260910204612.3762015-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4a621946395ff7d32d23059c9ba2026708d50e4 Author: Eric Dumazet Date: Thu Sep 10 20:46:11 2026 +0000 drop_monitor: use raw_cpu_ptr() in tracepoint probes [ Upstream commit c19b7d35086b7d240f1ca3088b0079d2bd39ffb9 ] syzbot reported a preemption warning in sk_skb_reason_drop(): BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5917 caller is net_dm_packet_trace_kfree_skb_hit+0x119/0x350 net/core/drop_monitor.c:519 In net_dm_packet_trace_kfree_skb_hit(), data = this_cpu_ptr(&dm_cpu_data) is evaluated before spin_lock_irqsave(&data->drop_queue.lock, flags). When kfree_skb() is called from preemptible context (e.g. process context during close() on /dev/net/tun), preemption is enabled, triggering the CONFIG_DEBUG_PREEMPT warning in smp_processor_id(). The same pattern exists in net_dm_hw_trap_summary_probe() and net_dm_hw_trap_packet_probe() for dm_hw_cpu_data. This is a false positive because each per-cpu structure is protected by its own spinlock. If the task migrates to another CPU right after reading the per-cpu pointer, the lock still safely synchronizes access to that queue. Use raw_cpu_ptr() instead of this_cpu_ptr() to silence CONFIG_DEBUG_PREEMPT without disturbing interrupt state or breaking PREEMPT_RT locking semantics. Fixes: ca30707dee2b ("drop_monitor: Add packet alert mode") Fixes: 5855357cd40e ("drop_monitor: Prepare probe functions for devlink tracepoint") Reported-by: syzbot+dc57fd6722deb17e92af@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6aa316b2.f81106d8.2ab401.0014.GAE@google.com/ Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260910204612.3762015-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bda4d9525fb91a2388ee09669421b8d505290864 Author: Eric Dumazet Date: Thu Sep 10 20:46:10 2026 +0000 drop_monitor: use timer_shutdown_sync() to prevent timer rearming during teardown [ Upstream commit c391a40f71886b28c082b47270f0e856fa3e1150 ] In drop_monitor teardown paths (net_dm_trace_off_set(), net_dm_hw_monitor_stop(), and error unwind paths in net_dm_trace_on_set() and net_dm_hw_monitor_start()), per-CPU timers are stopped using timer_delete_sync() followed by cancel_work_sync(). However, there is a circular dependency between send_timer and dm_alert_work: 1) sched_send_work() (timer callback) schedules dm_alert_work. 2) send_dm_alert() / net_dm_hw_summary_work() calls reset_per_cpu_data() or net_dm_hw_reset_per_cpu_data(). 3) If memory allocation fails under memory pressure in the reset function, it re-arms the timer via mod_timer(&data->send_timer, ...). If dm_alert_work is running concurrently while timer_delete_sync() executes on another CPU, an allocation failure in the worker will re-arm the timer after timer_delete_sync() has already returned. Once cancel_work_sync() completes and module_put() is called, the timer remains active in the timer wheel. If the module is then unloaded, the timer will fire and execute sched_send_work() in freed memory, triggering a kernel panic / use-after-free. Switch from timer_delete_sync() to timer_shutdown_sync(). This guarantees that any in-flight timer handler has finished and prevents subsequent re-arming attempts from running workers from succeeding. When monitoring is restarted later, timer_setup() is invoked, which cleanly re-initializes the timer. Fixes: 9398e9c0b1d4 ("drop_monitor: Perform cleanup upon probe registration failure") Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260910204612.3762015-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d0d6d65637e125ac40c1d773fbec107b7f358793 Author: Eric Dumazet Date: Thu Sep 10 20:46:09 2026 +0000 drop_monitor: synchronize tracepoint unregistration on error path [ Upstream commit 6a038ef2b57922b6d9ca98ddac0df0681849b704 ] If register_trace_napi_poll() fails in net_dm_trace_on_set(), unregister_trace_kfree_skb() is called to roll back the kfree_skb tracepoint registration. However, tracepoint_synchronize_unregister() is omitted before calling cancel_work_sync() and module_put(). An in-flight probe executing concurrently on another CPU could call schedule_work() after cancel_work_sync() has already returned, leaving a pending work item scheduled after the module reference is dropped. If the module is then unloaded, executing the work item triggers a kernel panic. Add tracepoint_synchronize_unregister() after unregister_trace_kfree_skb() in the error path, matching net_dm_trace_off_set() and net_dm_hw_probe_unregister(). Fixes: 7c747838a558 ("drop_monitor: Split tracing enable / disable to different functions") Signed-off-by: Eric Dumazet Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260910204612.3762015-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 30992fe39e65589ed8e000425e088fa74994b811 Author: Eric Dumazet Date: Sat Sep 12 23:30:48 2026 +0000 pppoatm: ensure a writable skb header and linear data [ Upstream commit ecc7253683a3c55caa868ce0ee530fcb0044bd3c ] In pppoatm_send(), LLC encapsulation checks whether there is sufficient headroom for the 4-byte LLC header, but does not ensure that the skb header is writable. Normal transmit packets passing through ppp_start_xmit() have their header unshared via skb_cow_head(). However, packets can also reach pppoatm_send() via PPP channel bridging (PPPIOCBRIDGECHAN) without going through ppp_start_xmit(). Use skb_cow_head() to ensure both sufficient headroom and a writable header before pushing the LLC header. While at it: - Call pskb_may_pull(skb, 1) before inspecting skb->data[0] to prevent out-of-bounds reads on zero-length or non-linear frames (e.g. from bridging). - Defer SC_COMP_PROT protocol compression until after pppoatm_may_send() succeeds. This eliminates the temporary skb allocation on admission failure and completely removes the fragile "undo" heuristic at the nospace label, avoiding any risk of reading uninitialized headroom or performing an unbalanced skb_push(). Fixes: 4cf476ced45d ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls") Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260912233048.3977192-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bcf6013c2b4d732c6e4bf4d0f6ae4a18d63d414b Author: Lorenzo Bianconi Date: Fri Sep 11 11:20:15 2026 +0200 net: stmmac: fix TSO header length truncation [ Upstream commit 15989abd74f16f44bf953d056b95f1d2fda9b0cd ] stmmac_tso_xmit() stores the protocol header length returned by stmmac_tso_header_size() in a u8. stmmac_tso_valid_packet() admits headers up to 1023 bytes, so a header longer than 255 bytes wraps modulo 256 (486 becomes 230, 256 becomes 0). A TCP over IPv6 socket carrying a few hundred bytes of sticky destination/hop-by-hop options makes skb_tcp_all_headers() exceed 255 while staying below the 1023-byte limit, so such an skb reaches stmmac_tso_xmit(). Widen proto_hdr_len to unsigned int, which is sufficient since the value is bounded by the hardware limit, and adjust the debug print specifier accordingly. Fixes: 9edfa7dab811 ("net: stmmac: enable TSO for IPv6") Signed-off-by: Lorenzo Bianconi Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260911-stmmac-fix-header-length-v1-1-8fc103334327@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit be550ee108ad80828aa61280400bedfc7e7c39d3 Author: Kuniyuki Iwashima Date: Sat Sep 12 03:07:51 2026 +0000 af_unix: Unify scc_index when finalising SCC in __unix_walk_scc(). [ Upstream commit 4a4263dfeabad72f95e8ab6e15146861fa4144dd ] Commit bfdb01283ee8 ("af_unix: Assign a unique index to SCC.") changed Tarjan's algorithm to update lowlink with lowlink, which is called lowpoint (unix_vertex.scc_index). unix_vertex_dead() assumes all vertices in an SCC share the same lowpoint, but this is not always true if an SCC has two or more back edges, depending on the order of DFS. For example, the graph below has two back edges from B to A and from C to B. A --> B --> C ^ | ^ | `----' `----' If DFS walks through A -> B -> C -> B (-> C -> B) -> A (-> B -> A), each index and scc_index will be updated as follows. A --> B --> C C = (3, 3) (index, scc_index) B = (2, 2) A = (1, 1) A ... B ... C C = (3, 2)<-. ^ | B = (2, 2) -' `----' A = (1, 1) A ... B ... C C = (3, 2) ^ | . . B = (2, 1)<-. `----' .... A = (1, 1) -' Then, unix_vertex_dead() thinks that B is passed to another SCC with scc_index 2, and the SCC is not garbage-collected. This does not happen if DFS walks in a different order below or starts from B. 1 3 A --> B --> C ^ | ^ | `----' `----' 2 4 Let's unify scc_index across the SCC when finalising it. Note that updating v->index was previously done in unix_scc_dead(), when called from __unix_walk_scc(), just to save one loop. Since __unix_walk_scc() now iterates over the SCC anyway, the update is moved back to __unix_walk_scc() and 'fast' argument is dropped. Fixes: 4090fa373f0e ("af_unix: Replace garbage collection algorithm.") Reported-by: James Burton Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260912030852.1467872-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18174b166547ef41973cc19feb5ef9cab39a8def Author: Juan Perdomo Date: Sat Sep 12 23:09:45 2026 -0400 Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup [ Upstream commit 801fb950cae7048eb7d83b18857d1ca37b8cd5a4 ] rfcomm_sock_cleanup_listen() closes unaccepted child sockets through rfcomm_sock_close(), which takes the child socket lock before rfcomm_dlc_close() acquires rfcomm_mutex. The RFCOMM worker takes these locks in reverse order while handling connections and DLC state changes, so lockdep reports a possible deadlock. Close dequeued children without taking their socket lock. The accept queue owns a reference to each child, and bt_accept_dequeue() locks the child while unlinking it and clearing its parent pointer. Dropping the child lock makes it important to prevent a concurrent rfcomm_connect_ind() from enqueueing a new child after cleanup observes an empty queue. Set a listening socket to BT_CLOSED while its lock is still held, before dropping the lock and draining the queue. The state check in rfcomm_connect_ind() then rejects new children once cleanup starts. Reported-by: syzbot+0cece8fa7d83523f47a3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0cece8fa7d83523f47a3 Fixes: b7ce436a5d79 ("Bluetooth: switch to lock_sock in RFCOMM") Signed-off-by: Juan Perdomo Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit de4c3c72bcc6e8474f70c22427f94ca44bccd890 Author: Sai Teja Aluvala Date: Fri Sep 11 17:22:22 2026 +0530 Bluetooth: btintel_pcie: fix off-by-one bounds check in RX submit [ Upstream commit 2ea5a87a5a7ae58cb2662b8a7d06f209383e1765 ] btintel_pcie_submit_rx() used frbd_index > rxq->count to guard the FRBD array access, allowing frbd_index == rxq->count to pass through and index one element past the end of the array. Change the check to >= rxq->count so every out-of-range index is rejected. This issue was reported by Claude Mythos. Fixes: c2b636b3f788 (Bluetooth: btintel_pcie: Add support for PCIe transport) Signed-off-by: Sai Teja Aluvala Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 9f74bc9e17a2e6b0f7013f27f3f732ef452ed6b7 Author: Tzung-Bi Shih Date: Mon Sep 14 09:47:29 2026 +0000 Bluetooth: btmtksdio: Fix PM runtime reference leak in shutdown [ Upstream commit 7b60ee5f46f2ee329de661f7c68b6818d8136220 ] In btmtksdio_shutdown(), pm_runtime_get_sync() is called at the beginning of the function. However, if sending the WMT function control command fails later, the driver returns early. It bypasses the corresponding pm_runtime_put_noidle() and pm_runtime_disable() calls, leaking the PM usage counter and leaving PM runtime enabled indefinitely. Fall through to execute the PM runtime cleanup block even if WMT errors. Fixes: 7f3c563c575e ("Bluetooth: btmtksdio: Add runtime PM support to SDIO based Bluetooth") Signed-off-by: Tzung-Bi Shih Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5a5cfd8488c97e1b8939515429fe4c81e9f2df4f Author: Chris Lu Date: Mon Sep 14 14:56:54 2026 +0800 Bluetooth: btmtksdio, btmtkuart: validate WMT event length before struct access [ Upstream commit 8879e3e0a84a86954c855caceead4867e74a9a27 ] btmtksdio.c and btmtkuart.c cast a received WMT event straight to struct btmtk_hci_wmt_evt and read its op/flag fields without checking the event is long enough to contain them, unlike btmtk.c. The FUNC_CTRL case then further casts to struct btmtk_hci_wmt_evt_funcc and reads its 2-byte status field, again without a length check. Firmware that sends a short or malformed WMT event makes both drivers read past the end of the received SKB. Mirror btmtk.c: validate the base WMT header with skb_pull_data() before touching any of its fields, and when a FUNC_CTRL event turns out to be the short, header-only form (a plain enable/disable ack with no status word), decode the result from the header's own flag byte instead (0 = success, otherwise failure). Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression. Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Fixes: e0b67035a90b ("Bluetooth: mediatek: update the common setup between MT7622 and other devices") Assisted-by: Claude:claude-opus-5 Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 805f2ca09d62cd1b9a1d887984df0ea1ff5a3aa2 Author: Chris Lu Date: Mon Sep 14 14:56:53 2026 +0800 Bluetooth: btmtk: fix wrong status for short WMT FUNC_CTRL events [ Upstream commit 78b6abd6c7a7591aacdae657f813214dae4fcd3b ] A too-short BTMTK_WMT_FUNC_CTRL event (WMT header only, no trailing 2-byte status word) is always treated as BTMTK_WMT_ON_UNDONE. This short form is how firmware acks a plain enable/disable request, and the actual result is carried in the header's own flag byte (0 = success), not a separate status word. Decode it from there instead of assuming failure. Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression. Fixes: e3ac0d9f1a20 ("Bluetooth: btmtk: accept too short WMT FUNC_CTRL events") Assisted-by: Claude:claude-opus-5 Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 502c1024f1bccfa5fae63027f64649551a73c70f Author: Luiz Augusto von Dentz Date: Thu Sep 10 14:07:24 2026 -0400 Bluetooth: ISO: set BT_LISTEN before requesting a BIG sync [ Upstream commit 296e7f3c5071cc02dc22e1566e759179fa1792ae ] A BIS connection is matched to its parent socket by looking for a socket in BT_LISTEN state with the same BIG handle: iso_conn_ready() if (test_bit(HCI_CONN_BIG_SYNC, &hcon->flags)) parent = iso_get_sock(hdev, &hcon->src, &hcon->dst, BT_LISTEN, iso_match_big_hcon, hcon); The socket was only moved to BT_LISTEN after iso_conn_big_sync() returned, while the LE BIG Create Sync command has already been queued by then. If the BIG sync is established before the state is updated, which is easy to hit with an emulated controller as the command may complete in a few hundred microseconds, no parent is found and the BIS connections are never notified to the listening socket. The user space is then left waiting for connections that never arrive, e.g. bluetoothd never completes a MediaTransport1.Acquire of a Broadcast Sink transport. Move the socket to BT_LISTEN before requesting the BIG sync, so the state is visible by the time the command is queued, and restore the previous state if the request could not be started. Since the socket is briefly visible as a listening socket, child sockets may have been queued in the meantime, so drain the accept queue before restoring the state: the cleanup paths of BT_CONNECT2/BT_CONNECTED don't do it and the children would be left with a dangling parent pointer. Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f016daabd4fec4e9b8563f8b6f42eabce0ca66b0 Author: Luiz Augusto von Dentz Date: Thu Sep 10 14:06:27 2026 -0400 Bluetooth: ISO: Fix parent socket leak in iso_conn_ready() [ Upstream commit ca18ee413a7cb6f09885778039225e58bae0d607 ] iso_get_sock() returns the parent socket with a reference held, which is dropped by sock_put() once the child socket has been set up. The error path taken when iso_sock_alloc() fails only calls release_sock() and returns, leaking the reference and thus the parent socket itself. Drop the reference on that path as well. Fixes: fa224d0c094a ("Bluetooth: ISO: Reassociate a socket with an active BIS") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 15754e4ec47ac5d117c9609c34a49ed6980ac4a1 Author: Ibrahim Abdelkader Date: Wed Aug 19 14:54:25 2026 +0200 Bluetooth: hci_qca: Do not write to the serial port after it is closed [ Upstream commit 4e93c65f87825e1e012bce56615320aeb123815d ] hci_uart_close() closes the serdev port if HCI_QUIRK_NON_PERSISTENT_SETUP is set (for example, for the WCN399x family). A failed hci_dev_open_sync() following a successful qca_setup() calls hdev->close() but not hdev->shutdown(), so the port is closed while power->vregs_on is left true. qca_serdev_remove() then passes its power->vregs_on test and calls qca_power_off(), which writes to the closed port unconditionally. Seen on a WCN3988 by unbinding the driver after a controller failure. The trace below is from a 7.0.0 based kernel, where qca_power_off() was still named qca_power_shutdown(): Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Call trace: tty_set_termios+0x50/0x238 (P) ttyport_set_baudrate+0x84/0xc0 serdev_device_set_baudrate+0x24/0x40 qca_power_shutdown+0x158/0x1fc [hci_uart] qca_serdev_remove+0x54/0x68 [hci_uart] serdev_drv_remove+0x1c/0x2c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xc0 Check HCI_UART_PROTO_READY, which hci_uart_close() clears in the same place it closes the port, before writing to it. The regulator disable is left unconditional so the controller is still powered down. The dangling serport->tty that turns this into a use-after-free is addressed in a separate patch. Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Signed-off-by: Ibrahim Abdelkader Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a552b4bc058b35ac8520e258b45ede7c6050b871 Author: Radek Podgorny Date: Wed Sep 9 00:29:37 2026 +0200 Bluetooth: put the peer's on-air address on air when we cannot resolve [ Upstream commit 4914c499896121ae8b9d5b90f0abc5c8287ff396 ] An identity address only reaches a peer that is advertising an RPA if the controller resolves it on our behalf. Where it cannot, the host has to put the peer's on-air address on air itself. hci_connect_le() still swaps the caller's identity address for the peer's cached RPA before creating the connection, but __hci_conn_add() resolves the RPA back to the identity address when it stores it, so the identity is what goes out. Storing the identity is right when the controller translates it on the way to the radio; without LL Privacy, or with this peer absent from the resolving list, nothing does. A peer advertising an RPA cannot answer its identity address, so the attempt burns a full create-connection timeout. That is not merely a slow connect: a controller without extended scanning cannot scan while it is initiating, so every dead attempt also takes the scanner off the air for the whole timeout. Measured on a CYW43438, which reports neither LL Privacy nor extended advertising (LE features 3f 00 00 08 00 00 00 00), against a peer advertising a resolvable private address the host holds the IRK for, with the connection requested on the peer's identity address: before: LE Create Connection to the identity address, public type 1.61s -> 22.07s, then LE Create Connection Cancel LE Connection Complete: Unknown Connection Identifier (0x02) after: LE Create Connection to the peer's RPA, random type LE Connection Complete: Success Advertising reports reaching the host per second, same window, same five unrelated devices on the adapter: before 1s:2 [nothing from 2s through 21s] 22s:5 23s:3 after 0s:11 1s:5 2s:2 3s:5 4s:3 5s:4 ... 21s:2 22s:1 23s:2 One dead connect costs twenty seconds of scanning for every device on the adapter, not just the one being dialled. Keep the RPA in conn->dst unless the controller will translate the identity address: address resolution enabled and the peer's identity actually programmed into the resolving list. Testing ll_privacy_capable() alone would not be enough: it reports the feature bit, not whether resolution is switched on and not whether this peer is in the list. Resolution is cleared with the other volatile flags on power-off and switched off again while suspend pauses scanning, and a peer's IRK is only programmed along the accept list path, so a direct-connect target, a peer without HCI_CONN_FLAG_ADDRESS_RESOLUTION, and one that did not fit in a full list are all absent from it. With the peer programmed, the identity address stays in conn->dst and the controller translates it: measured on an Intel controller, the host dials the identity and LE Enhanced Connection Complete reports Resolved Public with the peer's RPA in the separate peer resolvable private address field. With the peer absent from the list the same setup dials the RPA itself. Everything downstream already copes with an RPA in conn->dst: it is what every outgoing LE connection stored before 14b06c3a88f7, the connection complete event names the address that was dialled, and le_conn_complete_evt() resolves it back to the identity once the link is up. ISO links keep the unconditional conversion: they are created from an existing ACL or a periodic sync and never dial this address themselves. Keeping the RPA is only right while the peer is still using it, which is why the preceding patch drops the cached RPA as soon as the peer is seen advertising its identity address. Without that, a peer that turns privacy off would be dialled on the address it abandoned rather than the one it is answering on. Fixes: 14b06c3a88f7 ("Bluetooth: HCI: Always use the identity address when initializing a connection") Assisted-by: Claude:claude-opus-5 Assisted-by: Claude:claude-fable-5 Signed-off-by: Radek Podgorny Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 82699d1b727ba5980b94f1eb8dc3d346f41b7c67 Author: Weiming Shi Date: Sun Sep 6 23:43:32 2026 +0800 Bluetooth: coredump: Quiesce dump work on unregister [ Upstream commit d236517c264e41dc09833c708ef23bccb7a91219 ] hci_devcd_handle_pkt_init() arms dump_timeout and coredump producers queue dump_rx without holding an hdev reference. Unregister leaves both works live, so disconnecting during an active dump lets them access hdev after hci_release_dev() frees it. Shut down coredump processing during unregister. Close the producer gate under dump_q.lock before disabling both works, then free the active buffer and queued packets under hci_dev_lock. Serializing the gate with enqueue prevents controller-specific workers from adding packets after the final purge. Fixes: 9695ef876fd1 ("Bluetooth: Add support for hci devcoredump") Reported-by: syzbot+b170dbf55520ebf5969a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b170dbf55520ebf5969a Reported-by: Aby Sam Ross Link: https://lore.kernel.org/r/20260322210849.68743-1-abysamross@gmail.com Suggested-by: Aby Sam Ross Reported-by: Tristan Madani Link: https://lore.kernel.org/r/20260814231248.3096377-1-tristmd@gmail.com Reported-by: Xiang Mei Assisted-by: OpenAI Codex:gpt-5 Signed-off-by: Weiming Shi Reported-by: Xiang Mei Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c298a61e18029401486c40298a50fbeea7e7b663 Author: Chandrashekar Devegowda Date: Tue Sep 8 15:26:58 2026 +0530 Bluetooth: btintel_pcie: validate TX skb length in send_sync [ Upstream commit 4b837ebd0ea21ae5cc26f02dc042edc6fe7b46b9 ] btintel_pcie_prepare_tx() copies skb->len bytes into a fixed BTINTEL_PCIE_BUFFER_SIZE (4096) DMA slot via an unchecked memcpy. Oversized packets are currently rejected only in btintel_pcie_send_frame(); any future caller of btintel_pcie_send_sync() would silently overflow the DMA buffer. Add the bounds check in btintel_pcie_send_sync() itself, right before skb_push() and the DMA copy. Assisted-by: Copilot:claude-sonnet-5 code-review code-generation Fixes: 6e65a09f9275 ("Bluetooth: btintel_pcie: Add *setup* function to download firmware") Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit cbb325bc150e8c0dbce004ac0e5516bcffc0de31 Author: ThangNN99 Date: Sun Sep 6 22:21:27 2026 +0700 Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained [ Upstream commit 6610c6fe4b8936c232048e6049bf77c70a6f759c ] hci_send_acl(), hci_send_sco() and hci_send_iso() queue hdev->tx_work unconditionally. They can run from the L2CAP/SCO/ISO socket send path while hci_dev_close_sync() is draining hdev->workqueue (HCIDEVDOWN racing with a socket write). Since that queue_work() is not chained work from the tx_work worker itself, __queue_work() sees the queue marked __WQ_DRAINING, warns "cannot queue %ps on wq %s", and drops the work: WARNING: CPU: 1 PID: 5985 at kernel/workqueue.c:2352 __queue_work Call Trace: queue_work_on l2cap_chan_send l2cap_sock_sendmsg ... hci_dev_close_sync() already sets HCI_CMD_DRAIN_WORKQUEUE before draining, but only hci_cmd_work() and handle_cmd_cnt_and_timer() check it before queuing. Route the tx_work producers through the same guard via a shared hci_sched_tx() helper. Fixes: 525daaea459f ("Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close") Reported-by: syzbot+b6919040d9958e2fc1ae@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b6919040d9958e2fc1ae Signed-off-by: ThangNN99 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 54ccc01012a240476edf641bf1a2b8bff54fe6ae Author: Baineng Shou Date: Thu Sep 10 10:16:52 2026 +0800 dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg() [ Upstream commit 075bc7b1d3dde5ed43fbaabbc1a69f09b7fc3a47 ] In mmp_pdma_prep_slave_sg(), for_each_sg() iterates the scatterlist putting each entry into 'sg', but the entry length is read from 'sgl' (the list head) instead of 'sg' (the current entry): for_each_sg(sgl, sg, sg_len, i) { addr = sg_dma_address(sg); avail = sg_dma_len(sgl); /* should be 'sg' */ Consequently 'avail' is always the length of the first entry. For multi-sg lists this causes out-of-bounds reads when a later entry is shorter than the first, and silent data loss when it is longer. Single-sg or uniformly-sized lists happen to mask the issue. Fixes: c8acd6aa6bed3 ("dmaengine: mmp-pdma support") Signed-off-by: Baineng Shou Reviewed-by: Frank Li Link: https://patch.msgid.link/20260910021652.1296640-1-shoubaineng@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ea06930907de40f2e5447abc03bb023b62ed16a3 Author: Namjae Jeon Date: Wed Sep 9 09:58:48 2026 +0900 ksmbd: keep compound responses on query info errors [ Upstream commit 9fa26285ae70ac2d3d1b47459a6b4463ab053e1c ] Do not reset the RFC1002 length of the complete response when a query info buffer is too small. The current command will add its error response through ksmbd_iov_pin_rsp(), while resetting the base length can truncate earlier responses in a compound request. This lets ksmbd return the earlier responses and the query-info error response together. Remove the now-unused rsp_org parameter from the pipe query-info helpers. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Reported-by: Mobin Aydinfar Reviewed-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 054a35a90c0706b1d29d503f5322ed0ac3b0f51c Author: Namjae Jeon Date: Tue Jul 7 00:07:09 2026 +0900 ksmbd: fix partial file information responses [ Upstream commit 6b8b79226bc3e0ac3fdd4e91836241af712e8cd1 ] Variable-length file information handlers use the client output length while constructing the response. FILE_ALL_INFORMATION can consequently return -EINVAL before the common buffer check, while stream information can stop building the complete result too early. Build the complete response within the available server response buffer and apply the client output length only when selecting the final status and transmitted length. Use the protocol-defined fixed sizes for all, alternate-name, and stream information to distinguish STATUS_INFO_LENGTH_MISMATCH from STATUS_BUFFER_OVERFLOW. This fixes smb2.getinfo.qfile_buffercheck. Signed-off-by: Namjae Jeon Stable-dep-of: 9fa26285ae70 ("ksmbd: keep compound responses on query info errors") Signed-off-by: Sasha Levin commit fd8bc313b9ebb4e45d865ace06f6743a37f54c5e Author: Namjae Jeon Date: Sun Jul 5 22:43:46 2026 +0900 ksmbd: return buffer overflow for partial filesystem info [ Upstream commit 0ecd35fac4b4f2828490689b46039744d201dcb0 ] The query-info buffer check returns STATUS_INFO_LENGTH_MISMATCH for every output buffer smaller than the complete response. Variable-length filesystem information instead requires STATUS_BUFFER_OVERFLOW when the fixed portion fits but the complete data does not. Pass the fixed size for each filesystem information class to the buffer checker. Keep INFO_LENGTH_MISMATCH for buffers below that size, and return BUFFER_OVERFLOW with a response truncated to the requested length for larger partial buffers. This fixes smb2.getinfo.qfs_buffercheck. Signed-off-by: Namjae Jeon Stable-dep-of: 9fa26285ae70 ("ksmbd: keep compound responses on query info errors") Signed-off-by: Sasha Levin commit 1c4bb940c3bb4325bb88ac1b7eaf5faaa39e7d63 Author: Eric Dumazet Date: Sat Sep 12 14:48:48 2026 +0000 tcp: do not let tcp_rmem be set below 4096 [ Upstream commit 83a945a529d6e002dd7339c532288a931f463dba ] We can hit a division by zero crash in tcp_rcvbuf_grow() and tcp_rcv_space_adjust(): divide error: 0000 [#1] PREEMPT SMP RIP: 0010:tcp_rcvbuf_grow+0x187/0x450 net/ipv4/tcp_input.c:939 ... grow = div_u64(((u64)rcvwin << 1) * (newval - oldval), oldval); The division uses oldval = tp->rcvq_space.space as divisor. When tp->rcvq_space.space is zero, this leads to a divide-by-zero exception. tp->rcvq_space.space is initialized in tcp_init_buffer_space(): tp->rcvq_space.space = min3(tp->rcv_ssthresh, tp->rcv_wnd, (u32)TCP_INIT_CWND * tp->advmss); If tcp_rmem[1] is configured to very small values (such as 1), sk->sk_rcvbuf is initialized to 1. Then tcp_full_space(sk), which computes (sk->sk_rcvbuf * scaling_ratio) >> 8, truncates to 0. This sets tp->window_clamp = 0, tp->rcv_ssthresh = 0, and tp->rcvq_space.space = 0. Later, when data arrives and DRS is invoked, tcp_rcvbuf_grow() divides by oldval == 0. Back in 2015, commit b1cb59cf2efe ("net: sysctl_net_core: check SNDBUF and RCVBUF for min length") ensured that net.core.rmem_default and net.core.rmem_max cannot be set below SOCK_MIN_RCVBUF. Similarly, SO_RCVBUF setsockopt enforces max_t(int, val * 2, SOCK_MIN_RCVBUF). However, net.ipv4.tcp_rmem still had .extra1 = SYSCTL_ONE, allowing arbitrarily small values. Because SOCK_MIN_RCVBUF depends on sizeof(struct sk_buff) and cacheline alignment, its value varies across architectures and configuration options. Using a fixed constant of 4096 ensures a predictable, architecture- independent lower bound that is safely above SOCK_MIN_RCVBUF everywhere and matches the documented 4K default. Fix this by setting tcp_rmem.extra1 to 4096 and updating the documentation. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260912144848.3448026-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 56d38839ef0bff6526d9bd73b6811bd00316b21c Author: Kuniyuki Iwashima Date: Mon Sep 14 01:14:01 2026 +0000 tcp: Don't call skb_clone_and_charge_r() for close()d listener in tcp_v6_do_rcv(). [ Upstream commit 8e759cd1f6444a946bd1fd2b2b29eea582eea1d5 ] tcp_v6_do_rcv() no longer calls skb_clone_and_charge_r() for TCP_LISTEN since commit 073d89808c06 ("net: fix data-races around sk->sk_forward_alloc"). However, there is still a small race window between tcp_v6_rcv() and tcp_v6_do_rcv(), where concurrent close() changes TCP_LISTEN to TCP_CLOSE, causing skb_clone_and_charge_r() to be called locklessly and resulting in the splat below. [0] Let's avoid calling skb_clone_and_charge_r() for TCP_CLOSE as well. This is fine for non-listeners because tcp_rcv_state_process() drops skb for TCP_CLOSE and opt_skb was freed immediately anyway. [0]: sk->sk_forward_alloc WARNING: net/ipv4/af_inet.c:162 at inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:162, CPU#1: ksoftirqd/1/28 Modules linked in: CPU: 1 UID: 0 PID: 28 Comm: ksoftirqd/1 Not tainted 7.2.0 #17 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:162 Code: 3d 49 ff e9 06 fd ff ff e8 d0 5b 83 f8 90 0f 0b 90 e9 35 fe ff ff e8 c2 5b 83 f8 90 0f 0b 90 e9 c5 fe ff ff e8 b4 5b 83 f8 90 <0f> 0b 90 e9 04 ff ff ff e8 a6 5b 83 f8 90 0f 0b 90 e9 65 fe ff ff RSP: 0018:ffffc90000677bb8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880117bde80 RCX: ffffffff8957eb41 RDX: ffff88801dad5d00 RSI: ffffffff8957ec3c RDI: 0000000000000005 RBP: 00000000fffff000 R08: ffffffff8957eb41 R09: 00000000fffff000 R10: 0000000000000005 R11: 0000000000000000 R12: dffffc0000000000 R13: ffff8880117bdf10 R14: ffffffff81c08eb7 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8880d7ae5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f93a1021138 CR3: 00000000207a9000 CR4: 0000000000350ef0 Call Trace: __sk_destruct+0x82/0xae0 net/core/sock.c:2356 rcu_do_batch kernel/rcu/tree.c:2645 [inline] rcu_core+0x59c/0x1100 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9b0 kernel/softirq.c:622 run_ksoftirqd kernel/softirq.c:1076 [inline] run_ksoftirqd+0x38/0x60 kernel/softirq.c:1068 smpboot_thread_fn+0x458/0xc80 kernel/smpboot.c:160 kthread+0x396/0x4a0 kernel/kthread.c:436 ret_from_fork+0x8e0/0xe40 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fixes: e994b2f0fb92 ("tcp: do not lock listener to process SYN packets") Reported-by: Taras Madan Signed-off-by: Kuniyuki Iwashima Reviewed-by: Xuanqiang Luo Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260914011420.115556-1-kuniyu@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c40ed3e884c8dc0350f26484030438ef24208ff1 Author: Nikolay Aleksandrov Date: Fri Sep 11 13:50:21 2026 +0300 net: bridge: mst: move switchdev call outside rcu [ Upstream commit 18a6fe05fb6e18de29fa90d388bb34044114b3d8 ] This is a follow-up of one of sashiko's pre-existing bug reports. br_mst_set_state() calls switchdev_port_attr_set() for nonzero MSTIs while holding rcu_read_lock() which invokes the blocking switchdev notifier chain and may sleep. Nonzero MSTI changes come from netlink with rtnl held. Move the switchdev call before entering the rcu section and assert that rtnl is held. The call cannot be deferred because netlink needs its error and extack. Also DSA reads the old bridge MST state during the callback and checks it. A deferred callback will be late and will see the updated state. Fixes: 3a7c1661ae13 ("net: bridge: mst: fix vlan use-after-free") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260911105021.1385934-1-razor@blackwall.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c5f73cde72f48308dc11934e1a411445d82c7f7d Author: Karl Mehltretter Date: Tue Aug 11 10:27:02 2026 +0200 wifi: brcmfmac: fix lost 802.1x TX completion wakeup [ Upstream commit 621d90169cef6c8da5b6134db5c0c4e23cdd09ce ] brcmf_txfinalize() decrements pend_8021x_cnt before a lockless waitqueue_active() check. atomic_dec() does not order the decrement against the check. The waiter can therefore observe a nonzero count while the waker observes an empty queue, losing the final wakeup and delaying key installation until the 950 ms timeout. Add smp_mb__after_atomic() to order the decrement before the queue check. wait_event_timeout() provides the matching barrier. LKMM confirms that this forbids the lost-wakeup outcome. Fixes: 21fff75d2fb6 ("brcmfmac: use wait_event_timeout for 8021x pending count") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260811082702.44521-1-kmehltretter@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 438131e7ae847e907d345bf504d7e25585561b5c Author: Hohyun Sim Date: Thu Sep 10 15:37:43 2026 +0900 net: fddi: skfp: fix NULL deref when setting the MAC address while down [ Upstream commit 7c8810c2e69c3d9ca6df870b40ae9218e50b4fb1 ] skfp_ctl_set_mac_address() calls ResetAdapter() unconditionally, without checking netif_running(). ResetAdapter() first calls card_stop(), which sets smc->hw.hw_state to STOPPED, and then mac_drv_clear_tx_queue(), which walks the two transmit queues: for (i = QUEUE_S; i <= QUEUE_A0; i++) { queue = smc->hw.fp.tx[i] ; ... t = queue->tx_curr_get ; smc->hw.fp.tx[] is only populated by init_tx(), which is reached from skfp_open() through init_smt() -> init_fddi_driver() -> init_fplus() -> init_mac() -> init_tx(). The private area is allocated and zeroed by alloc_fddidev(), so on an interface that has never been brought up both queue pointers are still NULL. The hw_state test at the top of mac_drv_clear_tx_queue() does not catch this, because card_stop() has just set STOPPED; the function proceeds into the loop and dereferences NULL. ResetAdapter() does call init_smt() itself, but only after the queues have been cleared. Setting the MAC address on a down interface therefore oopses: ip link set dev fddi0 address 02:00:00:00:00:01 BUG: KASAN: null-ptr-deref in mac_drv_clear_tx_queue+0x68/0x2c0 [skfp] Read of size 8 at addr 0000000000000010 by task ip/302 Call Trace: mac_drv_clear_tx_queue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] skfp_ctl_set_mac_address+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] netif_set_mac_address+0x1e4/0x2c0 do_setlink+0x684/0x2680 Address 0x10 is the offset of tx_curr_get, the third pointer in struct s_smt_tx_queue, on 64-bit. mac_drv_clear_rx_queue(), which ResetAdapter() calls immediately afterwards, dereferences smc->hw.fp.rx[QUEUE_R1] in the same way behind the same ineffective hw_state test; the transmit queue merely crashes first. Both are covered by the guard below. Skip the adapter reset when the interface is down. dev_addr_set() is left unconditional, so the new address is still recorded in dev->dev_addr. Nothing is lost by not resetting the adapter here: skfp_open() deliberately re-reads the factory address on every open, read_address(smc, NULL); eth_hw_addr_set(dev, smc->hw.fddi_canon_addr.a); and the comment above it states this is done to discard exactly such an address override across a close/open cycle. An address set while the interface is down could not have survived the following open even before this change, so the guard removes no working behaviour. Guarding the hardware side of ndo_set_mac_address() with netif_running() is established practice; skge_set_mac_address() has done so since commit 2eb3e621c4e0 ("skge: set mac address bonding fix"). Guarding the reset as a whole, rather than NULL-checking the queues, is also what the rest of the driver expects. After a previous open/close the queue pointers are stale but non-NULL, so there is no crash, yet ResetAdapter() goes on to call smt_online() and STI_FBI() ("Enable Board Interrupts") while skfp_close() has already called free_irq() - the adapter would be brought back online with no handler installed. The only other ResetAdapter() caller is skfp_interrupt(), which by construction runs only while the device is open. Found by automated driver testing against an emulated SysKonnect FDDI adapter under a KASAN-enabled 7.0.0 kernel. Triggering it requires CAP_NET_ADMIN. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: LLM KASAN Signed-off-by: Hohyun Sim Link: https://patch.msgid.link/20260910063743.110747-1-tlaghgus0425@korea.ac.kr Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fda3000147dc96c75ba162f680bec0a9fecf3037 Author: Dong Chenchen Date: Thu Sep 10 22:00:42 2026 +0800 ipv4: icmp: reject RTN_UNREACHABLE input routes in icmp_route_lookup [ Upstream commit 2998147b59c9df0a51477c7a6b3d1f0ba3127dd4 ] When the forward output route cannot be used in icmp_route_lookup(), it enters the "reverse path" and calls ip_route_input() on fl4_dec.daddr, the original packet's source address. ip_route_input() only returns an error for truly invalid packets. For unreachable addresses it will succeed and return an input route whose dst.output is set to ip_rt_bug(). The existing check only rejects RTN_LOCAL routes, so the RTN_UNREACHABLE route types can still be returned and later used for output, syzkaller triggering a WARN_ON_ONCE() in ip_rt_bug() as bellow: ------------[ cut here ]------------ WARNING: net/ipv4/route.c:1273 at ip_rt_bug+0x14/0x20 RIP: 0010:ip_rt_bug+0x14/0x20 Call Trace: ip_push_pending_frames+0xfa/0x100 __icmp_send+0x905/0xf10 ip_options_compile+0xc0/0xd0 ip_rcv_finish_core+0x321/0xae0 ip_rcv+0x1de/0x260 __netif_receive_skb_one_core+0x11a/0x130 netif_receive_skb+0x7b/0x260 tun_get_user+0x11bf/0x1c10 ------------[ cut here ]------------ Reject input route that is RTN_UNREACHABLE to fix it. The net warning is only printed for RTN_LOCAL, as RTN_UNREACHABLE is not the result of a race condition. Fixes: 8b7817f3a959 ("[IPSEC]: Add ICMP host relookup support") Suggested-by: Ido Schimmel Reviewed-by: Jiayuan Chen Reviewed-by: Ido Schimmel Signed-off-by: Dong Chenchen Link: https://patch.msgid.link/20260910140042.1880242-1-dongchenchen2@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1c23dba51dbf7e86c7c2e617c964be1411329cb4 Author: Kuniyuki Iwashima Date: Sat Sep 5 23:36:30 2026 +0000 sysctl: Check range in proc_dointvec_ms_jiffies_minmax [ Upstream commit 82431877d837a6c2593efd8e66ba28b35a220ca4 ] Add the range check to do_proc_int_conv_ms_jiffies_minmax that commit d174174c6776 ("sysctl: replace SYSCTL_INT_CONV_CUSTOM macro with functions") incorrectly removed. Fixes: d174174c6776 ("sysctl: replace SYSCTL_INT_CONV_CUSTOM macro with functions") Signed-off-by: Kuniyuki Iwashima Signed-off-by: Joel Granados Signed-off-by: Sasha Levin commit 906140955c8debde65afe12e594e04c49a61b0d9 Author: Nicolai Buchwitz Date: Sun Sep 13 21:00:52 2026 +0200 net: bcmgenet: restore the hardware filters on open [ Upstream commit 23ca4ddc4fce2c233a49e9fd34d4b5b02bd7324e ] bcmgenet_hfb_init() runs INIT_LIST_HEAD() on priv->rxnfc_list, which drops every rule off the list, and bcmgenet_open() calls it on each ifup. Every rule the user configured is silently lost: # ethtool -N eth0 flow-type ether dst $MAC action 0 Added rule with ID 0 # ethtool -n eth0 | grep -c Filter: 1 # ip link set eth0 down && ip link set eth0 up # ethtool -n eth0 | grep -c Filter: 0 Initialise the lists once at probe and restore the rules on open, as bcmgenet_resume() already does. Fixes: 3e370952287c ("net: bcmgenet: add support for ethtool rxnfc flows") Signed-off-by: Nicolai Buchwitz Reviewed-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260913190052.939955-1-nb@tipi-net.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 97df811a11d4f76bc2ffe67b6bf730263f56c668 Author: Daniel Golle Date: Thu Sep 10 14:13:15 2026 +0100 net: dsa: mxl862xx: disable the stats poll on teardown [ Upstream commit 9e92ad4630f5dd1838ce6bbe6b1bd2c73d34de36 ] mxl862xx_setup() arms the stats poll before mxl862xx_setup_mdio(), and nothing stops it until dsa_register_switch() has returned an error to mxl862xx_probe(). DSA frees the dsa_port list before it returns, so a poll that fires once .setup or a later step of dsa_tree_setup() has failed walks freed ports. On shutdown the user ports stay registered, and the WORK_STOPPED flag test in mxl862xx_get_stats64() is not atomic with the cancel in mxl862xx_shutdown(), so a re-arm that read the flag before it was set queues the poll after cancel_delayed_work_sync() has returned. Arm the poll once .setup has succeeded and stop it from a .teardown op, which DSA calls on unregister and after a failed registration, in both cases before it frees the ports. Use disable_delayed_work_sync() there and in shutdown(): it drains a running poll as the cancel did and turns every later attempt to queue the work into a no-op, so the re-arm cannot bring the poll back. remove() and the probe error path only set WORK_STOPPED, which crc_err_work tests before it walks the ports. Fixes: a21d33a5265f ("net: dsa: mxl862xx: implement .get_stats64") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/1eb6f7fc1789b67e4b11e3f4d5ff080d0b6f7cbb.1789045590.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c16e1ccc082a3763dfc6bc2d3f658c1a6336f9d Author: Andrea Mayer Date: Sun Sep 13 21:44:21 2026 +0200 seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation [ Upstream commit 7616242a2b37883f7322aaa1d2bd6cd0fed28315 ] When an SRv6 packet arrives on an interface enslaved to a VRF, vrf_ip6_rcv() sets IP6SKB_L3SLAVE in IP6CB, but decap_and_validate() has never set IPSKB_L3SLAVE in IPCB. The bit stayed clear in the common case, and with CONFIG_IPV6_MIP6 the leftover frag_max_size of a reassembled outer packet could even set it, with no VRF involved. Commit 44930446dde4 ("ipv6: seg6: clear IPv4 control block on IPIP decapsulation") then made the unreliable bit reliably clear. The effect of the missing flag is visible with End.DX4 when a delivery to a local address of the node reaches the socket lookup. For example, a UDP socket bound to the enslaved ingress interface does not receive any of the decapsulated packets, while an unbound socket outside the VRF does. This contradicts Documentation/networking/vrf.rst: by default the scope of an unbound UDP or TCP socket is limited to the default VRF. Set IPSKB_L3SLAVE for IPv4 in decap_and_validate(), which already does the same for IPv6. The socket lookup then matches the decapsulated packet like any other packet received on that enslaved interface. Such a packet matches an unbound UDP or TCP socket only when udp_l3mdev_accept or tcp_l3mdev_accept is set. Fixes: 891ef8dd2a8d ("ipv6: sr: implement additional seg6local actions") Signed-off-by: Andrea Mayer Reviewed-by: David Ahern Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260913194421.31-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c59e4a90780f3b1825e4bc7300820dfb6df51a18 Author: Dmitry Baryshkov Date: Thu Sep 3 15:19:10 2026 +0300 drm/msm/dsi: round the byte clock rate after reparenting to the PHY PLL [ Upstream commit 2028280686f4fa78e2f1f6dede4b6c1fd782b9e3 ] DSI 6G v2.9 hosts (SM8650, SM8750, Kaanapali, etc.) reparent the byte and pixel RCGs to the DSI PHY PLL at runtime from dsi_link_clk_set_rate_6g_v2_9(), after the PHY has been enabled. However dsi_calc_clk_rate_6g() runs earlier, in order to compute the bit clock request for the PHY. At that point the byte RCG still has its reset parent (XO), so clk_round_rate() returns a bogus rate, which then ends up in the PHY bit clock request and the PLL gets programmed to a wrong frequency, breaking the panel. Move the rounding to dsi_link_clk_set_rate_6g(), which is called after the RCGs have been reparented to the PLL. Storing the rounded rate at this point still makes later link_clk_set_rate() calls no-ops in the CCF. Derive the byte interface clock rate from the rounded byte clock rate, otherwise it would keep requesting the idealized rate and retrigger the PLL on every transfer. Reported-by: Abel Vesa Reported-by: Krzysztof Kozlowski Fixes: 6cd33b6f4155 ("drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value") Assisted-by: LLM Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Tested-by: Konrad Dybcio # SM6115P J606F Tested-by: Abel Vesa Reviewed-by: Abel Vesa Patchwork: https://patchwork.freedesktop.org/patch/750496/ Link: https://lore.kernel.org/r/20260903-fix-eliza-dsi-v1-1-3474a6c9f2e0@oss.qualcomm.com Signed-off-by: Sasha Levin commit 0382d1384640d0bf4ce21cb65eae0676f2a9929b Author: Filipe Manana Date: Thu Sep 10 17:37:48 2026 +0100 btrfs: tree-checker: print dev extent offset in error message [ Upstream commit a1167d9420474ab9ed9efca99d86aeb6217c0265 ] If a dev extent's offset is not sector size aligned, the error message is printing the dev extent's objectid instead of the offset. This is a copy paste error, as before this check we check the objectid field. Fixes: 008e2512dc56 ("btrfs: tree-checker: add dev extent item checks") Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit be1d5e95ec499ed5ee9704aa27dd1407ccf0d0ac Author: Nicolas Escande Date: Fri Jul 31 16:58:30 2026 +0200 wifi: ath11k: cleanup arsta in ath11k_mac_peer_cleanup_all() [ Upstream commit 820b8cff81c796ba20573e04722ab62500713f97 ] When mac80211 removes a sta, it calls .sta_state() which in turn calls ath11k_mac_station_remove(). In that function we clean up both peers & arsta related resources. But when the firmware crashes, ath11k calls ieee80211_restart_hw(), which assumes that all driver related resources are cleaned up beforehand. This cleanup is supposedly done by ath11k_mac_peer_cleanup_all() but does not in fact free arsta->rx_stats / tx_stats. Extract the arsta cleanup from ath11k_mac_station_remove() into a new ath11k_mac_station_cleanup() and call it from both there and ath11k_mac_peer_cleanup_all(). This should handle kmemleaks reports like: unreferenced object 0xffffff801ae66400 (size 1024): comm "hostapd", pid 1306, jiffies 4295011565 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc d61c08ec): kmemleak_alloc+0x3c/0x50 __kmalloc_cache_noprof+0x2b0/0x3e0 ath11k_mac_op_sta_state+0x1dc/0xb10 drv_sta_state+0xac/0x6f8 sta_info_insert_rcu+0x314/0x5e0 sta_info_insert+0x14/0x38 ieee80211_add_station+0x10c/0x1a0 nl80211_new_station+0x3e8/0x680 genl_family_rcv_msg_doit+0xc0/0x120 genl_rcv_msg+0x1b4/0x258 netlink_rcv_skb+0x4c/0x108 genl_rcv+0x38/0x60 netlink_unicast+0x190/0x278 netlink_sendmsg+0x15c/0x370 ____sys_sendmsg+0x120/0x290 ___sys_sendmsg+0x70/0xa0 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Nicolas Escande Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260731145830.769811-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 3db8afba2d210b7d80cd5cc6b76d7f46daa9b47a Author: Slavin Liu Date: Sun Sep 13 20:51:54 2026 +0800 ALSA: hda: trace PCM open only after assigning a stream [ Upstream commit c9e6e5f38bf75276605f1952b22285f5f3abcaff ] Stream assignment can fail when hardware streams are exhausted. Move the tracepoint after the NULL check because its payload accesses the assigned stream tag. Detected by static analysis and reviewed with AI-assisted source auditing. Fixes: 184865085b88 ("ALSA: hda - rename hda_intel_trace.h to hda_controller_trace.h") Assisted-by: LLM Signed-off-by: Slavin Liu Link: https://patch.msgid.link/20260913125154.109944-1-bolin.liu@seu.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7f9780df677370a19b4ec9764f13b1b82073e0d9 Author: Karl Mehltretter Date: Sat Aug 22 16:31:10 2026 +0200 drm/vc4: Use managed KMS polling to fix UAF on unbind [ Upstream commit 073a30d75f309812ed61af134f24ffef4107b13a ] vc4_kms_load() calls drm_kms_helper_poll_init() but the driver provides no matching drm_kms_helper_poll_fini(). The output poll work stays scheduled after unbind and runs on the freed drm_device: # modprobe vc4; rmmod vc4; sleep 10 BUG: KASAN: slab-use-after-free in delayed_work_timer_fn BUG: KASAN: slab-use-after-free in drm_client_dev_hotplug [drm] Workqueue: events output_poll_execute [drm_kms_helper] Allocated by task 171: __devm_drm_dev_alloc Freed by task 262 (rmmod): drm_dev_put / component_del Use drmm_kms_helper_poll_init() so polling is finalized with the device, as other drivers do. Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260822143110.68594-1-kmehltretter@gmail.com Reviewed-by: Maíra Canal Signed-off-by: Maíra Canal Signed-off-by: Sasha Levin commit b7f4d2588b1342bb190c04b3d7a32560f206c74c Author: Shuicheng Lin Date: Wed Sep 9 16:21:02 2026 +0000 drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memory [ Upstream commit 985862be16c7e4da808c51f393d631fb60c0be5c ] __xe_shrinker_walk() walks the SYSTEM and TT LRUs without a runtime PM reference. Shrinking a bo outside system memory invalidates its GPU mappings, which needs the device resumed, so while it is runtime suspended the page table zap trips an assert and the TLB invalidation returns -ENODEV: WARNING: drivers/gpu/drm/xe/xe_bo.c:770 at xe_bo_move_notify+0x1fc/0x450 [xe] xe_bo_shrink+0x20f/0x2b0 [xe] __xe_shrinker_walk+0x174/0x410 [xe] xe_shrinker_scan+0x10c/0x1e0 [xe] do_shrink_slab+0x176/0x7e0 drop_caches_sysctl_handler+0x9c/0xf0 Take a reference before walking a memory type other than XE_PL_SYSTEM and stop there if it cannot be acquired. Reuse the shrinker's existing acquire path, which resumes the device directly where reclaim allows that and otherwise queues the PM worker for a later scan. Stop the walk once the scan target is met, so a satisfied scan does not wake the device. System memory is still reclaimed while the device is suspended. Gate this on xe_device_is_l2_flush_optimized(), the same condition under which xe_bo_trigger_rebind() issues the invalidation for a non-fault-mode vm, so reclaim is unaffected elsewhere. The System CCS copy already has its own reference in xe_bo_shrink(). Only a non-fault-mode vm can reach this, since a fault-mode vm requires LR mode and that holds a runtime PM reference for the vm's lifetime. Reproduced with igt@xe_madvise@dontneed-before-exec while the GPU is runtime suspended. v2: simplify needs_rpm check. (Matt) retarget Fixes tag since the issue occurs with the non-fault-mode path added by 4e7ebff69aed. v3: handle this in xe_shrinker.c instead of xe_bo.c (Thomas) v4: stop the walk once the scan target is met. (Sashiko) v5: rebase on the freed page accounting fix. (Sashiko) v6: reuse the shrinker acquire path so runtime pm can be resumed directly instead of always queueing a worker. (Thomas) v7: replace xe_pm_runtime_put() with xe_shrinker_runtime_pm_put(). (Thomas) Fixes: 4e7ebff69aed ("drm/xe/xe3p_lpg: flush shrinker bo cachelines manually") Assisted-by: Claude:claude-opus-5 Cc: Tejas Upadhyay Cc: Matthew Brost Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260909162102.1097006-3-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit 628f92b28bf4c371c10207daf6fc4caee0c0db2e) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit bff42b0d1d903f08e51152112d74ff8ba1ea9fdd Author: Shuicheng Lin Date: Wed Sep 9 16:21:01 2026 +0000 drm/xe/shrinker: Return the freed page count through a parameter [ Upstream commit 3c90e42a01426262f0cd166bc01b45c05562640d ] __xe_shrinker_walk() and xe_shrinker_walk() return either the number of pages freed or a negative error, so the two cannot be reported at once. On error the pages already freed are dropped, and since xe_shrinker_scan() only accumulates non-negative returns while *scanned is updated by pointer, the shrinker tells mm that it scanned without freeing. Accumulate the count into a caller-provided counter and return only the status, so an error no longer discards what the walk had freed. Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos") Assisted-by: Claude:claude-opus-5 Reviewed-by: Thomas Hellström Cc: Matthew Brost Link: https://patch.msgid.link/20260909162102.1097006-2-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit d7aac1a0235a6ce41e30cec385e2db8c33dad12d) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit a6b8b3ce9b4871f7fd4e3593df71e84a279fa9bf Author: Shuicheng Lin Date: Tue Sep 8 17:50:51 2026 +0100 drm/xe/mmio_gem: Revoke drm_vma_node on xe_mmio_gem destroy [ Upstream commit 37fcbd7b2f8996d783932dab11bc668e169b0de6 ] xe_mmio_gem_create() calls drm_vma_node_allow() but nothing ever calls drm_vma_node_revoke(). The drm_vma_offset_file rb-tree entry allocated by drm_vma_node_allow() is not freed by drm_gem_object_release(), so it is leaked on every create/destroy cycle. Add a struct drm_file * parameter to xe_mmio_gem_destroy() and call drm_vma_node_revoke() from there, mirroring the drm_vma_node_allow() call in xe_mmio_gem_create(). Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Suggested-by: Ilia Levi Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Shuicheng Lin Reviewed-by: Ilia Levi Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-14-matthew.auld@intel.com (cherry picked from commit 32f0cb250598456d812fb7ca57a040282858323d) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit ec99748122b2b441f062c0f20253d6b31c833172 Author: Ilia Levi Date: Tue Sep 8 17:50:49 2026 +0100 drm/xe/mmio_gem: use write-back mapping for dummy page [ Upstream commit 819f189265a5955da743e78e20a713a038982e89 ] Currently vmf_insert_pfn() maps the dummy page as UC, inheriting the VMA's page protection which was set for the real MMIO region. This conflicts with the direct map's WB mapping of the same page, creating a cache type alias which is architecturally undefined on some platforms. Use vmf_insert_pfn_prot() with a WB pgprot instead. Also simplify to fault in the requested page instead of the whole VMA. Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260525125801.975038-6-ilia.levi%40intel.com Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-12-matthew.auld@intel.com (cherry picked from commit 1e8e28e35df0e77ae1b22fc091c1f422f62fa5e9) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit b5849031cfae75c31726216ab0d5649b753bf6bf Author: Ilia Levi Date: Tue Sep 8 17:50:48 2026 +0100 drm/xe/mmio_gem: forbid VMA split [ Upstream commit 247a82da6f563dcfd9074a68f99a0c0997d0679c ] The fault handler assumes it always operates on a VMA spanning the entire GEM object. This does not hold when the VMA has been split, e.g. by a partial munmap or mprotect. In that case the handler may map wrong physical pages or cause SIGBUS. Handle this by forbidding VMA split, as partial unmaps are not deemed useful for MMIO GEMs. Suggested-by: Matthew Auld Signed-off-by: Ilia Levi Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-11-matthew.auld@intel.com (cherry picked from commit f3391a0b12d7bf826a0b21600d2f294f3dce4c14) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit b808a9af5fd21f9c68b0d024eda7535b5dce6a4e Author: Zihan Xi Date: Wed Sep 9 12:37:18 2026 +0000 wifi: virt_wifi: don't transfer operstate before register [ Upstream commit e5c8d7acd31b27057ea42cd405d0b3ece097bc89 ] virt_wifi_newlink() calls netif_stacked_transfer_operstate() before register_netdevice(). If the lower device is dormant, that queues the new netdev on lweventlist while it is still uninitialized. If registration fails after that, for example because of an invalid name such as "bad/name", free_netdev() immediately frees the object. A later linkwatch_fire_event() then use-after-frees the list entry. Move the transfer to after netdev_upper_dev_link(), as macvlan and ipvlan already do. Fixes: c7cdba31ed8b ("mac80211-next: rtnetlink wifi simulation device") Reported-by: Vega Assisted-by: LLM Co-developed-by: Luxing Yin Signed-off-by: Luxing Yin Signed-off-by: Zihan Xi Link: https://patch.msgid.link/f5a832fb0ab228ce6e2b5a91fba4ca8b79198a2f.1788948455.git.zihanx@nebusec.ai Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c99ea7855124ca1428a1e59c2b4590aaef34eacf Author: Namjae Jeon Date: Thu Sep 3 14:06:02 2026 +0900 ksmbd: follow SMB2 session expiration semantics [ Upstream commit d7fd1f98607f2cd358e583f9548bdf0173090a86 ] ksmbd_session_register() destroys valid sessions after ten seconds of inactivity whenever a client starts another SessionSetup exchange. This confuses Session.IdleTime with Session.ExpirationTime. Windows can create additional authenticated sessions on an existing connection, so deleting the older session invalidates its tree connects and makes mapped drives fail with STATUS_NETWORK_NAME_DELETED. The session expiration rules require the server to change a valid session to expired only after its credential expiration time passes. A valid or expired session otherwise keeps its connection from being scavenged. Connections that have not negotiated a dialect, have no sessions, or have only InProgress sessions are disconnected after an implementation-specific timeout. Use the Windows-compatible 45 second value and run the expiration check periodically for both TCP and SMB Direct. Keep zero as an infinite credential expiration time, and count each Valid-to-Expired transition. Set expired sessions to InProgress when they reauthenticate. If authentication fails, remove the session from the global and per-connection tables immediately, including SMB3 multichannel connections. Retain protection against abandoned SessionId-zero exchanges by allowing only one InProgress authentication per connection. Additional exchanges fail with STATUS_INSUFFICIENT_RESOURCES, and stale InProgress sessions are reaped after the same 45 second setup timeout. This bounds the original unauthenticated memory-exhaustion path without evicting established sessions. Fixes: ea174a918939 ("ksmbd: destroy expired sessions") Reported-by: Mobin Aydinfar Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit e8d3bc459112f39b40aa40dade9b0084d337e685 Author: Namjae Jeon Date: Sun Jun 28 15:43:58 2026 +0900 ksmbd: extend procfs server statistics [ Upstream commit 4c670ccd5790816fc0f5714d5ee3c67dd5a9c67a ] The server proc entry does not expose configured limits or enough outcome data to distinguish protocol errors from transport stalls. Report the server state, listener and signing configuration, connection limits, timeout values, current client and open-file totals, IPC activity, and durable scavenger state. Classify processed SMB2 response statuses by NTSTATUS severity and provide counters for common error groups while retaining the per-command counters. Signed-off-by: Namjae Jeon Stable-dep-of: d7fd1f98607f ("ksmbd: follow SMB2 session expiration semantics") Signed-off-by: Sasha Levin commit f0d3dba61b365cc278d650a5546a7d0bfe050ac8 Author: Namjae Jeon Date: Sun Jun 28 15:35:29 2026 +0900 ksmbd: fix malformed procfs status output [ Upstream commit 1f7dd03a88a8405143aab195f6fa9ed2243494b1 ] The ksmbd procfs monitoring files produce misleading or malformed output. The constant-name helper uses a bitwise test for enum values. This omits zero-valued constants and can print multiple names for one lease state. It also unconditionally emits a newline, splitting entries in the open-file table across two lines. Session capabilities are printed as numeric flag values even though a table of descriptive names is available. Use exact matching for enum values. Print flag names as a comma-separated list, preserving unknown bits as hexadecimal values. Let callers control line termination so each open-file entry remains on one line. Print common session properties once, and report signing and encryption independently. Adjust client and open-file column widths for IPv6 addresses and 64-bit file IDs, and fix the misspelled OPLOCK_EXCLUSIVE name. Also expose and maintain the total request count alongside the per-command counters. Signed-off-by: Namjae Jeon Stable-dep-of: d7fd1f98607f ("ksmbd: follow SMB2 session expiration semantics") Signed-off-by: Sasha Levin commit cdc31537012bc7a58c95c6750db321b69dd802bb Author: Xiang Mei Date: Mon Sep 14 00:43:24 2026 -0700 ALSA: 6fire: fix OOB write from device-reported iso length [ Upstream commit 1589afe2d099d3e817873bc474676968d7080410 ] usb6fire_pcm_in_urb_handler() sizes each outgoing isochronous packet as (actual_length - 4) / (in_n_analog << 2) * (out_n_analog << 2) + 4, where actual_length is the unsigned length the device reported for the matching IN packet. A packet completed with status 0 and actual_length < 4 wraps the subtraction to 0x7fffffec; a zero-length isochronous packet is legal on the bus, and the preceding loop rejects only non-zero status. The sum reaches memset() on out_urb->buffer, a 4832-byte object from kcalloc(PCM_MAX_PACKET_SIZE, PCM_N_PACKETS_PER_URB). Even without the wrap the result is out of bounds: at 88.2/96 kHz the 4-in/6-out scaling turns a full 420-byte IN packet into 628, so eight packets span 5024 bytes of that buffer. usb_submit_urb() rejects an over-long descriptor only after the memset() and the usb6fire_pcm_playback() copy of user PCM data have run. Guard the subtraction as the sibling usb6fire_pcm_capture() already does, and limit the frame count to what fits in rt->out_packet_size, the OUT endpoint's wMaxPacketSize. This bounds total_length by the buffer size while keeping each packet length aligned to a whole output frame. BUG: KASAN: out-of-bounds in usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338) Write of size 18446744073709551456 at addr ffff88802a3d0000 by task vhci_rx/5018 Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) kasan_check_range (mm/kasan/generic.c:186 mm/kasan/generic.c:200) __asan_memset (mm/kasan/shadow.c:84) usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741) vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107 drivers/usb/usbip/vhci_rx.c:242) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 10: __kmalloc_cache_noprof (mm/slub.c:5563) usb6fire_pcm_init (sound/usb/6fire/pcm.c:560 sound/usb/6fire/pcm.c:595) usb6fire_chip_probe (sound/usb/6fire/chip.c:133) usb_probe_interface (drivers/usb/core/driver.c:399) The buggy address belongs to the object at ffff88802a3d0000 which belongs to the cache kmalloc-8k of size 8192 The buggy address is located 0 bytes inside of 4832-byte region [ffff88802a3d0000, ffff88802a3d12e0) Kernel panic - not syncing: Fatal exception in interrupt Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB") Reported-by: co+855929c2df672879@bugs.sh Closes: https://lore.kernel.org/all/gisnub8aWGLbyZLcDCSc7zWsHonMWGcyRgt5%40bugs.sh/ Assisted-by: LLM Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260914074324.3590843-1-xmei5@asu.edu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d181434549b3da668110a25d743848cce9897f4e Author: Takashi Iwai Date: Thu Sep 3 18:04:39 2026 +0200 ALSA: usb: 6fire: Avoid embedded URBs [ Upstream commit 9fe49dbc023e82dfaee7b245997d820d01742a9a ] The USB 6fire driver uses URBs embedded in different structs for PCM, MIDI and communication, and this is basically a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. For addressing the problem, this patch converts those embedded URBs to ones that are properly allocated via usb_alloc_urb(). The pcm_urb.packets[] is gone, as it's allocated by usb_alloc_urb(), hence it's found in urb.iso_frame_desc[] instead. The conversions are rather straightforward; each embedded struct urb is changed to a pointer, and its callers are updated accordingly. The resource for those structs are released in the common destructor functions (usb6fire_comm_free(), etc), which are called at both the init error path and the disconnect. No functional changes, only compile-tested. Link: https://lore.kernel.org/20260903130757.0668310a.michal.pecio@gmail.com Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260903160458.1938392-4-tiwai@suse.de Stable-dep-of: 1589afe2d099 ("ALSA: 6fire: fix OOB write from device-reported iso length") Signed-off-by: Sasha Levin commit 00a316a7a36f222a27d389c1faaccbc8b565fb24 Author: Runyu Xiao Date: Mon Sep 14 13:15:37 2026 +0800 gpio: virtuser: skip free_irq when no IRQ is installed [ Upstream commit 50fd0ada8d37587223001600933270b59cb30e19 ] Disabling interrupt monitoring uses atomic_xchg() to clear the stored IRQ. When monitoring is already disabled, atomic_xchg() returns 0. It must not be passed to free_irq(). The bug is reproducible on an x86_64 QEMU guest with CONFIG_GPIO_VIRTUSER=y and CONFIG_GPIO_SIM=y. Configure a live gpio-virtuser device through configfs. Its input lookup must refer to a live gpio-sim bank, such as key gpio-sim-test with offset 0. The consumer's dev_name attribute is shown as below; then run: echo 0 > /sys/kernel/debug/gpio-virtuser//gpiod:input:0/interrupts On an unpatched kernel, this reaches gpio_virtuser_interrupts_set() with ld->irq still at its initial value 0, and free_irq() reports: Trying to free already-free IRQ 0 The same reproducer completes without the warning on the patched kernel. Fixes: 91581c4b3f29 ("gpio: virtuser: new virtual testing driver for the GPIO API") Assisted-by: LLM Signed-off-by: Runyu Xiao Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260914051537.15320-1-runyu.xiao@seu.edu.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit c692919e8f57ad7e3981d78e3acde6a3b28f012d Author: Ulises Mendez Martinez Date: Fri Sep 4 15:07:09 2026 +0000 objtool: Validate disassembler headers in libopcodes probe [ Upstream commit 7e61560628d17ea6b1d8ee370f6d42694cff8758 ] commit 3f2de814c059 ("objtool: Fix libopcodes linking with static libraries") tested for libopcodes availability by linking a test snippet with a forward declaration of disassemble_init_for_target(). However, testing symbol linkage with an extern declaration only verifies the presence of the library (.so/.a) and bypasses checking for development headers (binutils-dev). On systems where libopcodes is present without development headers installed, the probe succeeds, enabling BUILD_DISAS. Subsequent compilation of objtool then fails: fatal error: 'bfd.h' file not found 113 | #include Additionally, the probe invokes $(HOSTCC) without $(HOSTCFLAGS), ignoring any sysroot or include flags specified for the host compiler. Fix this by including and directly in the test snippet, passing $(HOSTCFLAGS) so host compiler options are respected, and defining PACKAGE="objtool" to satisfy the configuration check in . Fixes: 3f2de814c059 ("objtool: Fix libopcodes linking with static libraries") Fixes: 436326bc525d ("objtool: fix build failure due to missing libopcodes check") Reported-by: Alice Ryhl Assisted-by: Antigravity:Gemini-Next Signed-off-by: Ulises Mendez Martinez Link: https://patch.msgid.link/20260904150710.2997558-1-umendez@google.com Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit d75f640789ad61bd95d30a6f6942c21e702228e3 Author: Karl Mehltretter Date: Sat Sep 5 12:20:38 2026 +0200 Input: trackpoint - fix the inertia attribute name in the ABI document [ Upstream commit 45b0037899704caf9078be2be4de69361ca7d933 ] The attribute is created as "inertia" (TRACKPOINT_INT_ATTR(inertia, ...) in drivers/input/mouse/trackpoint.c); the ABI file spells the path "intertia". The description below it already says inertia. Fix the spelling. Fixes: aebb47d4e7a9 ("Input: trackpoint: document sysfs interface") Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260905102038.42882-1-kmehltretter@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 022f1cb8f4ee6243f34f4535445411de45a8570f Author: Gabor Juhos Date: Wed Sep 9 16:08:25 2026 +0200 spi: spi-qpic-snand: avoid writing QPIC_EBI2_ECC_BUF_CFG register [ Upstream commit 930a7312c946bf4731721cadd82bb9a2ada496ca ] The description of commit bfb34eced559 ("mtd: rawnand: qcom: avoid writing to obsolete register") says this: "QPIC_EBI2_ECC_BUF_CFG register got obsolete from QPIC V2.0 onwards. Avoid writing this register if QPIC version is V2.0 or newer." Although the referenced commit is related to the 'qcom-nandc' driver, however the hardware supported by the current driver is also based on QPIC v2.0 so we should avoid writing that register here as well. Remove the register writing code to avoid undefined behaviour. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos Reviewed-by: Md Sadre Alam Link: https://patch.msgid.link/20260909-qpic-snand-avoid-ebi2-reg-write-v1-1-9b1b1466cc75@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 65e76684877377e1641911677184164637c65228 Author: Richard Fitzgerald Date: Thu Sep 10 12:44:58 2026 +0100 ASoC: soc-pcm: Apply snd_soc_dai_link_ch_map.codec_ch_mask to codec params [ Upstream commit 6b382bdfe26a2232091bf743e454e6794295783e ] In __soc_pcm_hw_params() if there is a snd_soc_dai_link_ch_map with non-zero codec_ch_mask, use that channel mask to restrict which channels are enabled on the codec. But only if there isn't a TDM mask. It is possible that a snd_soc_dai_link_ch_map could include the same codec multiple times on different CPUs so the for_each_rtd_ch_maps() loop accumulates the channel masks for all entries of that codec. If a TDM mask was also set, it takes priority and is used instead of any possible snd_soc_dai_link_ch_map entries. (They cannot be ANDed together because the bit positions are indicating different things: TDM is a bit for each TDM slot, codec_ch_mask is a bit for each codec channel.) This fixes a problem of incorrect TX channels enabled on the codec when multiple codecs are aggregated on a single capture link. For example: - Two CPUs with six 4-channel codecs. - The machine driver chooses to assign one channel from each codec to one channel on the CPU - But the codec hw_params() would be passed a channel count of 6, which (a) is more channels than the codec has and (b) allows enabling channels that should not be driving the audio bus. Fixes: ac950278b087 ("ASoC: add N cpus to M codecs dai link support") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910114500.1586637-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2df594738686f04eecab7511eaa101850f50ecd2 Author: Richard Fitzgerald Date: Thu Sep 10 12:44:57 2026 +0100 ASoC: Add codec_ch_mask to snd_soc_dai_link_ch_map [ Upstream commit 88b14c0d0bab5c0f3e7c641f274e3c70210c0e36 ] Add a codec_ch_mask member to snd_soc_dai_link_ch_map. The CPU and codec channel masks are not necessarily the same, and are quite likely different. SoundWire and I2S/TDM both support assigning different sample slots to each codec, so for example channel 0 on each codec could map to different channels at the CPU. It is also possible for one TX channel to map to multiple RX channels. So it isn't _always_ safe to assume that the total number of set bits in the CPU ch_mask is the same as the total number of enabled channels on the codec. For example consider this mapping on a capture stream: CPU0 CODEC0 cpu_ch_mask = 0x03 CPU1 CODEC0 cpu_ch_mask = 0x03 This could be either four TX channels on the codec split across two receiving CPUs, or two TX channels on the codec duplicated to two CPUs. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910114500.1586637-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown Stable-dep-of: 6b382bdfe26a ("ASoC: soc-pcm: Apply snd_soc_dai_link_ch_map.codec_ch_mask to codec params") Signed-off-by: Sasha Levin commit 2997440f36a1c7ee30145337f6aae9fb91d450ba Author: Richard Fitzgerald Date: Thu Sep 10 12:44:56 2026 +0100 ASoC: Rename snd_soc_dai_link_ch_map.ch_mask to cpu_ch_mask [ Upstream commit 4d855d747521505b54457c96bc73577bf74b2374 ] Rename the ch_mask member of snd_soc_dai_link_ch_map to cpu_ch_mask, as that is what it is used for. The CPU and codec channel masks are not necessarily the same, and are quite likely different. SoundWire and I2S/TDM both support assigning different sample slots to each codec, so for example channel 0 on each codec could map to different channels at the CPU. So it's quite normal that the channel mask at the CPU end is different for each codec, but the codec channel masks are the same for each codec. Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260910114500.1586637-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown Stable-dep-of: 6b382bdfe26a ("ASoC: soc-pcm: Apply snd_soc_dai_link_ch_map.codec_ch_mask to codec params") Signed-off-by: Sasha Levin commit 4483604a4fd6635282f8d134d035136db9bd4d8f Author: William Bright Date: Wed Aug 12 11:05:52 2026 +0100 drm/msm/dp: fix link bandwidth check when wide bus is enabled [ Upstream commit 58995b11dfb7dda095d23f22fa4dc79b923b5adf ] msm_dp_display_mode_valid() halves the pixel clock when either YUV420 or wide bus is in use, then uses that halved value both for the controller pixel clock limit and for the DP link bandwidth check. Only YUV420 halves the data crossing the link. Wide bus widens the internal DPU to DP interface to two pixels per clock, halving the controller clock. Every pixel is still transmitted, so the link bandwidth requirement remains. As a result, modes needing up to twice the available link bandwidth pass validation. On the IMDT QCS8550 SBC (rev5 with CYPD6125), where DP runs over USB-C alt mode where only two lanes are available, 3840x2160@60 was accepted despite needing 9.6 Gbps against the 8.64 Gbps the link can carry. Use a separate link pixel clock that is only halved for YUV420 for the bandwidth calculation, leaving the wide bus halving to apply solely to the controller pixel clock limit. With this, 4k@60 is correctly rejected and 4k@30 selected instead. Fixes: df9cf852ca30 ("drm/msm/dp: account for widebus and yuv420 during mode validation") Assisted-by: Claude:claude-opus-5 Signed-off-by: William Bright Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/746145/ Link: https://lore.kernel.org/r/20260812-msm-dp-link-bw-v1-1-b0e3ce1190be@imd-tec.com [DB: dropped useless comment] Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 5e97d117b79c3ce89542369ef697be64850de8ad Author: Jesse Casco Date: Sat Aug 8 13:13:25 2026 -0400 drm/msm/dp: skip PUSH_IDLE when the link was never enabled [ Upstream commit e249a6e2a130c08bb4d8b0a55cbe29754307e5c9 ] msm_dp_display_atomic_enable() returns early when link training fails, leaving ->power_on false and the main link down. msm_dp_display_atomic_disable() nevertheless writes DP_STATE_CTRL_PUSH_IDLE and waits for an idle-pattern completion that cannot arrive, so every failed enable is followed by "PUSH_IDLE pattern timedout". Every other step of the teardown is already gated on that flag: msm_dp_display_disable(), called from .atomic_post_disable(), returns early on !power_on. The PUSH_IDLE write is the only one that is not, so the controller's runtime-PM reference is then dropped without the link having been taken down. On glymur (Snapdragon X2 Elite) the consequence is not a warning. The SoC does not survive it: TrustZone force-stops the SOCCP and ADSP remote processors and the machine resets silently about 50 ms later, with no oops and no panic. On an ASUS Zenbook A16 (UX3607OA), whose eDP panel does not currently train, this reproduces without any compositor or GPU involvement: # eDP enable has already failed with "Failed link training (rc=-104)" echo 1 > /sys/class/graphics/fb0/blank [535.645455] === marker === [535.694833] qcom_q6v5_pas d00000.remoteproc: fatal error received: \ sys_m_smsm.c:512:TZ force stop [535.694875] remoteproc remoteproc0: crash detected in soccp: type fatal error [535.728857] qcom_q6v5_pas 6800000.remoteproc: fatal error received: \ sys_m_smsm.c:783:err fatal notification received from TZ Gate the PUSH_IDLE write on ->power_on so the disable path is consistent with the rest of the teardown. With this applied the same sequence is harmless and the machine stays up; without it, it resets every time. The unconditional write dates back to the original DP driver (c943b4948b58 ("drm/msm/dp: add displayPort driver support")), but the surrounding code has been restructured several times since, so no Fixes: tag is offered. Note that the eDP link-training failure that exposes this on the A16 is a separate problem in the glymur eDP PHY and is reported separately; this change is about not damaging the machine when training fails, for whatever reason. Tested on ASUS Zenbook A16 (UX3607OA), Snapdragon X2 Elite Extreme, on linux-next next-20260803 and next-20260807. The machine has since been running next-20260807 with this patch as its daily driver. Assisted-by: Anthropic:Claude-Opus-5 Signed-off-by: Jesse Casco Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/745167/ Link: https://lore.kernel.org/r/20260808171325.133041-1-jesse.casco@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0b349249d572633d7c8cdeb917623d1676a2b7c3 Author: Nguyen Ngoc Thang Date: Sun Sep 13 20:44:46 2026 +0700 ALSA: pcm: set timer->private_data before registering the PCM timer [ Upstream commit 1e713f9bb2ac583521f06b0eb4e22440b1e3d078 ] snd_pcm_timer_init() calls snd_device_register() to link the new struct snd_timer into the global timer list while it still carries hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop), and only afterwards sets timer->private_data = substream. Once the timer is on the list under register_mutex, a concurrent reader can already reach it through the same mutex and invoke these callbacks. /proc/asound/timers does this via c_resolution(), and snd_timer_open()+snd_timer_start() reach start()/stop() the same way. All three dereference timer->private_data, which for this brief window is NULL, giving a NULL-pointer dereference: substream = timer->private_data; return substream->runtime ? ... // substream is NULL Move the private_data/private_free assignment before snd_device_register() so the timer is never visible on the list without its private_data set. On the snd_device_register() failure path, private_free() (snd_pcm_timer_free()) can now run, but it only does substream->timer = NULL, which is already NULL at that point since substream->timer is set to the new timer just once, after a successful registration -- so the failure path stays safe. Reported-by: syzbot+19da64013c46df87f971@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=19da64013c46df87f971 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Nguyen Ngoc Thang Link: https://patch.msgid.link/20260913134446.114724-1-ngocthang2710.1999@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 117d19438af57174952522a98a6f1fbacae3f940 Author: AngeloGioacchino Del Regno Date: Fri Sep 11 09:40:15 2026 +0200 phy: mediatek: phy-mtk-hdmi-mt8195: Fix TMDS clk bit ratio setting [ Upstream commit 486a70ef848264dcf9a57f0bb0452848db9537de ] The comment in the mtk_phy_tmds_clk_ratio() function clearly and correctly explains that the TMDS ratio has to be 1/10 for data rates under 3.4Gbps, and 1/40 over that. Unfortunately though, the TXC_DIV register setting was wrong, as in value 3 means to divide by 8 and, in order to achieve the in spec 1/40 (tmds) data rate, this has to divide by 4 instead! Add definitions for the TXC_DIV register values clearly explaining the meanings (DIV2, DIV4, DIV8), and program the correct, DIV 4, value to the register in mtk_phy_tmds_clk_ratio(). This fixes out of spec clocking and, with this change, SoCs using the MT8195 class HDMI PHYs can now successfully be configured to output 3840x2160@60Hz over HDMI. Fixes: 45810d486bb4 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195") Reviewed-by: Manivannan Sadhasivam Signed-off-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20260911074015.9994-3-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f2d482c6ae1734ca0da9fe71d7b5c04a1693503b Author: AngeloGioacchino Del Regno Date: Fri Sep 11 09:40:14 2026 +0200 phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflow [ Upstream commit de7f29a1fe1dc2864d8a47f8c39d508442cae167 ] When trying to calculate a PLL rate for target display resolutions above 2560x1440, 24bpp, 30Hz, the pixel clock value will be more than 32-bits long but the division to finally calculate the digital clock divider is being done with div_u64(), which expects a 32bit unsigned divisor. Fix the overflow by using div64_u64() instead. Fixes: 9d9ff3d2a4a5 ("phy: mediatek: hdmi: mt8195: fix wrong pll calculus") Reviewed-by: Manivannan Sadhasivam Signed-off-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20260911074015.9994-2-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c4b0f48ddf7bbd2896c655e20ce58ac4e72289d3 Author: Namjae Jeon Date: Mon Sep 7 13:34:25 2026 +0900 ntfs: ignore interrupted inode reads as corruption [ Upstream commit 8c5dc7587fdd45f957af81a9adc1e16863f300fc ] Do not mark the volume in error or report an inode as corrupt when reading it was interrupted by a signal. -EINTR and -ERESTARTSYS indicate a transient read failure rather than on-disk NTFS corruption. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6137d60a03dfb8dd482a2cab98539c2021b9bfcc Author: Namjae Jeon Date: Mon Sep 7 13:34:01 2026 +0900 ntfs: propagate folio errors [ Upstream commit 1923eeffa63edeff427d76fc302bc5eb835771ce ] Return the error from __filemap_get_folio() instead of replacing it with -ENOMEM. Fixes: af0db57d4293 ("ntfs: update inode operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 742797432e8c9b0dd54ecc523c185e26b09d79a0 Author: Namjae Jeon Date: Sun Sep 6 21:37:28 2026 +0900 ntfs: protect runlist updates with the runlist lock [ Upstream commit 91709ba5d6d709b2b663287b7e871e2c6b480502 ] ntfs_non_resident_attr_shrink() calls runlist helpers that require the runlist write lock, but did not hold it while freeing clusters and truncating the runlist. Serialize those operations and the resident conversion with the runlist lock. ntfs_attr_map_cluster() can merge a newly allocated run before updating mapping pairs. If the update fails, free the clusters and restore both the in-memory runlist and on-disk mapping pairs from a saved runlist. Mark the volume in error if either rollback step fails. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 47aa2ab6391d6dbb664f9ea8b410afc0324368bd Author: Namjae Jeon Date: Fri Sep 4 14:46:38 2026 +0900 ntfs: account for MFT records added during allocation [ Upstream commit 631946431ddc66a472c5cc629cd654e62dfa1f88 ] When no free MFT record is available in the initialized $MFT/$BITMAP, ntfs_mft_record_alloc() extends $MFT/$DATA and formats the requested record together with a dynamically sized tail reserve. Those records become visible through the $MFT file size before charging the requested record to the free-record counter. Account for all newly visible records before releasing the MFT allocation lock, then subtract the one record being allocated. Keep MFT counter updates independent of the asynchronous free-cluster scan and update the counter when a record is successfully cleared in the MFT bitmap. Store the clamped result of the MFT bitmap scan and keep statfs from exposing an invalid cached count if an accounting error occurs. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit eaa27b0885402f43acd4a18fc516210a4a70afaa Author: Namjae Jeon Date: Sun Sep 6 11:12:47 2026 +0900 ntfs: repack $MFT/$ATTRIBUTE LIST [ Upstream commit b1d732e62a5b3942546e4edaab8976258e779287 ] Repack the non-resident $MFT/$ATTRIBUTE_LIST into a contiguous run when its mapping pairs no longer fit in the base MFT record. Propagate allocation and writeback errors, and check synchronous replacement writes. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit fa4cca0a9804693dfd0a31f99218e2f94f01ee40 Author: Namjae Jeon Date: Tue Sep 8 15:52:46 2026 +0900 ntfs: use dynamic MFT tail reservation [ Upstream commit 6d8c197c9992659a65525a07de4368c8401fdda7 ] The ntfs MFT allocator historically treated records below 64 as a permanent extension area and stopped searching for $MFT extent records after record 400. Windows and ntfs3 do not maintain that on-disk layout, so an NTFS volume can have free MFT records while ntfs returns -ENOSPC when $MFT:$DATA needs another mapping-pairs extent. Use record 24 as the first normal record and maintain an in-memory tail reserve of up to four initialized records. Normal allocations skip the reserve, while $MFT metadata extent allocations consume it. When a new tail is initialized, allocate at least two records and reserve the following records to avoid recursive allocation during MFT extension. Existing free runs can seed the reserve on volumes mounted without one. For $MFT/$DATA, constrain an extent record to a record whose byte offset is below the new extent lowest VCN byte offset. This preserves bootstrap reachability without an arbitrary record 400 limit. If no safe record is available, validate and use reserved records 15, 12, 13, and 14 as bootstrap candidates while keeping their MFT bitmap entries in use. This allows existing Windows volumes to extend $MFT using their actual free records and prevents normal file allocation from consuming the metadata reserve. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Reviewed-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 9c8b6eff6e7505c128b615d9a1364ef66fa5c18e Author: Takashi Iwai Date: Thu Sep 10 17:52:23 2026 +0200 ALSA: bcd2000: Fix race between rawmidi and disconnect [ Upstream commit 221253723dc58bb901c3f27a7659823e63fc598c ] Although we tried to fix the potential UAF issues at USB disconnect on bcd2000 driver, there is still an overlooked case -- namely, when a rawmidi trigger callback has been already running at USB disconnect handling, the in-flight function (e.g. bcd2000_midi_send()) could still access the URB, because the previous URB NULL-check & clearance was considered only for the URB complete callbacks, but not about the parallel rawmidi operations. For addressing the race, this patch introduced a new spinlock that covers each rawmidi operation as well as the rawmidi handling in the complete callback. The URB is cleared with the lock, so it guarantees that the pending rawmidi task already finished or a NULL check is effective. Fixes: 459d3a64766f ("ALSA: bcd2000: clear the URB pointers on disconnect") Link: https://patch.msgid.link/20260910155227.996210-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a265524cdd6b29ba6eb9842ea0c9ba4186eb995a Author: Kuniyuki Iwashima Date: Wed Sep 9 23:31:26 2026 +0000 neighbour: Skip default parms when resumed in neightbl_dump_info(). [ Upstream commit 979aabdad8dd03394467ee484a1a70f3d40b19ba ] neightbl_dump_info() calls neightbl_fill_info() in each loop to render the default parms. If there are many devices and neightbl_fill_param_info() failed, neightbl_fill_info() is called again when the dump resumes: # ynl --family rt-neigh --dump getneightbl --output-json | jq '.[] | {name: .name, ifindex: .parms.ifindex}' ... { "name": "ndisc_cache", "ifindex": null } ... { "name": "ndisc_cache", "ifindex": 6 } { "name": "ndisc_cache", "ifindex": null } { "name": "ndisc_cache", "ifindex": 5 } Let's skip neightbl_fill_info() if it is already called in neightbl_dump_info(). Note that we cannot use !neigh_skip instead of !default_skip because default_skip == 1 && neigh_skip == 0 could be true if the first neightbl_fill_param_info() fails. Also, nidx must be cleared at the end of each table loop; otherwise, if neightbl_fill_info() for a subsequent table fails, the leftover nidx from the previous table would be saved in cb->args[1], resulting in erroneously skipping parms of the subsequent table in the next dump. Fixes: c7fb64db001f ("[NETLINK]: Neighbour table configuration and statistics via rtnetlink") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260909233143.2401847-5-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 001f9b3df58c2d6e124e7fa43c316f6be0abe622 Author: Kuniyuki Iwashima Date: Wed Sep 9 23:31:25 2026 +0000 neighbour: Don't render blackhole_netdev via RTM_GETNEIGHTBL. [ Upstream commit 7b430fcfc972f61b09cc19ca95997586af4a147d ] The cited commits started to initialise blackhole_netdev with neigh_parms_alloc(). This is visible in init_net as the ifindex==0 entries via RTM_GETNEIGHTBL: # ynl --family rt-neigh --dump getneightbl --output-json \ | jq '.[] | select(.parms.ifindex == 0) | {name: .name, ifindex: .parms.ifindex}' { "name": "arp_cache", "ifindex": 0 } { "name": "ndisc_cache", "ifindex": 0 } For RTM_SETNEIGHTBL, ifindex being 0 means wildcard. Let's skip blackhole_netdev's parms in neightbl_dump_info(). Note that lookup_neigh_parms() does not need the same change because the default parms is always the first entry and matches with ifindex == 0. Fixes: e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev") Fixes: 22600596b675 ("ipv4: give an IPv4 dev to blackhole_netdev") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260909233143.2401847-4-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8550b50e49b01b572e653e572f24ddd73949aa74 Author: Kuniyuki Iwashima Date: Wed Sep 9 23:31:24 2026 +0000 neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS. [ Upstream commit 6d79b223ec44ada58ad37db42f539b60985a7722 ] NDTPA_INTERVAL_PROBE_TIME_MS sets .type and .min but misses .validation_type, so no validation is applied: # ynl --family rt-neigh --do setneightbl \ --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 0}}' # ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arp_cache" and has("config")) | .parms["interval-probe-time-ms"]' 0 Moreover, nla_get_msecs() uses msecs_to_jiffies(), and u64 is silently cast to u32, so a larger value can bypass the min check: e.g. 4294967296 == 0x100000000 # ynl --family rt-neigh --do setneightbl \ --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 4294967296}}' # ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arp_cache" and has("config")) | .parms["interval-probe-time-ms"]' 0 msecs_to_jiffies() returns MAX_JIFFY_OFFSET if the value is larger than INT_MAX. Also, INT_MAX ms overflows int NEIGH_VAR() when HZ > 1000 (Alpha, MIPS), and passing a negative integer to queue_delayed_work(unsigned long delay) causes sign extension, which wraps around the expiry time to the past, resulting in it being handled as 0 delay in the timer wheel. Let's use NLA_POLICY_FULL_RANGE() and limit the max to 1 day. The same max check is applied to sysctl as well. Note that this controls the probe interval for NTF_MANAGED entries, so the max of 1 day is unlikely to break any deployments. Fixes: 211da42eaa45 ("net, neigh: introduce interval_probe_time_ms for periodic probe") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260909233143.2401847-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 043cb1f7e0ce2238717b7ae107dd34c0b5498146 Author: Kuniyuki Iwashima Date: Wed Sep 9 23:31:23 2026 +0000 neighbour: Add missing RCU annotation for neightbl_dump_info(). [ Upstream commit 764dcebb033764633700a036c7351a7c6350eec6 ] neightbl_dump_info() fetches the first non-default neigh_parms with list_next_entry(&tbl->parms, ...) and iterates through the list with list_for_each_entry_from_rcu(). However, list_next_entry() does not use RCU helper. Let's use list_for_each_entry_rcu() and skip the default parms. Fixes: 4ae34be50064 ("neighbour: Convert RTM_GETNEIGHTBL to RCU.") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260909233143.2401847-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 44cf11a2971971a9902c46c7f7ba23b876e9ce34 Author: Karl Mehltretter Date: Fri Aug 21 04:53:27 2026 +0200 keys: fix lost wakeup when reaping a dead key type [ Upstream commit 2725ab3f5ad1c5f375c7c9fee4af02a9b138f701 ] clear_bit() is atomic with respect to the word it modifies, but it is an unordered operation: it implies no memory barrier on either side (Documentation/atomic_bitops.txt). key_garbage_collector() clears KEY_GC_REAPING_KEYTYPE with clear_bit() and calls wake_up_bit() after reaping a dead key type. wake_up_bit() uses a lockless waitqueue check and requires a full barrier after the clear. The existing smp_mb() is before clear_bit(), so nothing orders the clear against that check. The GC can see an empty waitqueue while unregister_key_type() still sees the bit set. The final wakeup is then lost, leaving module unload stuck in wait_on_bit(). Use clear_and_wake_up_bit(). Its clear_bit_unlock() has RELEASE semantics, so the completed GC work stays ordered before the clear, and its smp_mb__after_atomic() orders the clear before the waitqueue check. Fixes: 0c061b5707ab ("KEYS: Correctly destroy key payloads when their keytype is removed") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://lore.kernel.org/r/20260821025327.61488-1-kmehltretter@gmail.com Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 6913ff607c2bc8694193e1fcc40bf16d75f35f16 Author: Jérémy Jean Date: Thu Sep 10 18:37:43 2026 +0000 smb: client: validate absolute native symlink targets before NT fixups [ Upstream commit 23c240d9509e15f72e4112fc95f0160ab32ec430 ] With symlinkroot unset, an absolute target is copied without conversion to an NT drive path. Later code still assumes an NT prefix is present when modifying the target and calculating the print name length. For "/ab", this causes two failures: sym[5] and path[5] are written past their allocations, and plen -= 2 * poff subtracts an assumed 8-byte prefix from a 6-byte UTF-16 target, wrapping u16 plen to 65534. That underflow causes another overflow: memcpy() copies 65534 bytes into a 24-byte buffer. A user with write access to a mounted share can trigger these bugs with default settings. Validate the NT drive prefix, including an ASCII drive letter, before accessing fixed offsets or subtracting the prefix length. Fixes: 3363da82e02f ("smb: client: fix native SMB symlink traversal") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit b9a68a9ccaada15d8dd0102c188cc6b868ff800b Author: Thadeu Lima de Souza Cascardo Date: Wed Aug 26 08:46:58 2026 -0300 drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr [ Upstream commit 9eb1a393c89a79c4210230d23e7d88d239c61d7b ] When an out_fence_ptr is provided but DRM_MODE_PAGE_FLIP_EVENT is not set, a drm_pending_vblank_event will be allocated. If later, there is an allocation failure or another failure at setup_out_fence(), that event will not have base.fence set and it will not be released at complete_signaling(). Release the event and set crtc_state->event to NULL just like in the DRM_MODE_PAGE_FLIP_EVENT case when there is a failure at drm_event_reserve_init(). That is, prepare_signaling() releases the event and there is nothing to be done at complete_signaling(). Use drm_event_cancel_free() as that will also undo drm_event_reserve_init() in case it has been called. Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260727-drm_crtc_atomic_commit_leak-v1-1-23d9948a9d7c@igalia.com?part=1 Fixes: 92c715fca907 ("drm/atomic: Fix double free in drm_atomic_state_default_clear") Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patch.msgid.link/20260826-drm_pending_vblank_event_leak-v4-1-f8de8b996b9d@igalia.com Signed-off-by: Sasha Levin commit 62a9d7fc1c7fb3a2dea25b291710d2afebcad9c4 Author: Catalin Marinas Date: Mon Sep 7 12:30:25 2026 +0100 arm64: mte: Fix PTRACE_{PEEK,POKE}MTETAGS error documentation [ Upstream commit fdb9ebc7fb7788b8371fbef6c17dc5c8291e1429 ] PTRACE_{PEEK,POKE}MTETAGS return -EIO rather than -EOPNOTSUPP (as documented) when no tags are copied from/to a mapping without PROT_MTE. This has been the behaviour since the interface was introduced, though the original intent was to distinguish between address not being accessible and mapped as untagged. Update the documentation to match the implementation (de-facto ABI). Since -EOPNOTSUPP was never returned, change the error assignment to -EIO as well to avoid confusion. Fixes: df9d7a22dd21 ("arm64: mte: Add Memory Tagging Extension documentation") Fixes: 18ddbaa02b7a ("arm64: mte: ptrace: Add PTRACE_{PEEK,POKE}MTETAGS support") Reported-by: Yury Khrustalev Cc: Will Deacon Cc: Mark Rutland Signed-off-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 100887892b1d8f49f296bc7d22a121006ac39c32 Author: Breno Leitao Date: Thu Sep 10 06:53:27 2026 -0700 arm64: hibernate: clone only the linear map that exists at runtime [ Upstream commit e4a6f57d22e079e23fafac51057fad534160b269 ] This is similar to commit 1537e55728ec2 ("arm64: trans_pgd: clone only the linear map that exists at runtime"), but in a different place. swsusp_arch_resume() clones the kernel linear map with trans_pgd_create_copy(..., PAGE_OFFSET, PAGE_END). PAGE_OFFSET comes from the compile-time VA_BITS, so a CONFIG_ARM64_VA_BITS_52 kernel booting on hardware without LPA2 -- vabits_actual is 48 and the fifth level is folded -- hands the walk a 3.9PB window while its linear map only spans the top 128TB. On a VA_BITS_52 4k kernel with CONFIG_KASAN_GENERIC in a 4GB VM, I see: swapper/0: page allocation failure: order:0, mode:0x920(GFP_ATOMIC|__GFP_ZERO) hibernate_page_alloc+0x10/0x1c swsusp_arch_resume+0x70/0x320 hibernation_restore+0xa4/0x138 software_resume+0x15c/0x270 PM: hibernation: Failed to load image, recovering. PM: hibernation: resume failed (-12) Fix it by copying the linear map that is the actual one, not the compiled one. Fixes: a6bbf5d4d9d1 ("arm64: mm: Add definitions to support 5 levels of paging") Signed-off-by: Breno Leitao Reviewed-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4e31aa6cf1d6f4e64dd183a83c0d676a9e5e9f22 Author: Shouping Wang Date: Thu Sep 10 19:46:01 2026 +0800 perf/arm-cmn: Fix wp_dev_sel2 setting for multi-DTM configurations [ Upstream commit 49daa3d668b69a5454b5aba0078848a479f79f1c ] When MXP_MULTIPLE_DTM_EN is TRUE, each DTM will monitor at most two device ports. In this case, {wp_dev_sel2, wp_dev_sel} will only use values 2'b00 and 2'b01 per DTM. Previously the setting allowed values beyond the supported range per DTM, which could cause each DTM to select invalid ports when MXP_MULTIPLE_DTM_EN is TRUE. Fix this by only setting CMN_DTM_WPn_CONFIG_WP_DEV_SEL2 when !multi_dtm. Fixes: 60d1504070c2 ("perf/arm-cmn: Support new IP features") Signed-off-by: Shouping Wang Reviewed-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d9e6175a3ee48209ee65f294fc567b4e16b29b74 Author: Pablo Neira Ayuso Date: Mon Sep 7 21:04:05 2026 +0200 netfilter: flowtable: hold reference on ct until flow is released [ Upstream commit e75a9fa1d44bcbd66ea02e8781bcca6ea4076e0d ] nf_ct_put() releases the ct->ext area inmediately, the rcu typesafe semantics also allow to refer to the wrong conntrack from the flowtable datapath. Hold reference on ct until flow is released after rcu grace period. Add rcu_barrier() on module exit path, to ensure pending flow entries are release before module goes away. Fixes: 0ff90b6c2034 ("netfilter: nf_flow_offload: fix use-after-free and a resource leak") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit df80342f4bfc023ad7d6703df5e27f583ff0cb8d Author: Pablo Neira Ayuso Date: Thu Sep 3 01:28:56 2026 +0200 netfilter: nf_nat: unregister and release hooks on error [ Upstream commit cbdd39ce42530a193c56beb206a3356cb6d01016 ] If nf_hook_entries_insert_raw() fails, the NAT hooks get never released, resulting in a memleak. Postpone setting nat_proto_net->nat_hook_ops when the hooks are registered to simplify the error path to decide whether the nat hooks need unwinding. Fixes: 1cd472bf036c ("netfilter: nf_nat: add nat hook register functions to nf_nat") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c8cd6d3463e5ddbb61a5f3363c2e4580512d104d Author: Fernando Fernandez Mancera Date: Thu Aug 27 12:32:56 2026 +0200 netfilter: nf_tables: fix device name and prefix match in hook lookup [ Upstream commit 444e4c88c9c62a3d823069006563513fe7d5aa66 ] Currently, a netdev chain or flowtable hooked to a device prefix can be unintentionally deleted by a control-plane request targeting an exact device name or even a shorter one due to the usage of min() to calculate the length to match. Fix this by making sure an exact device match never matches a prefix and that both the target and the candidate have the same length during delete operation. The add and update paths retain the existing overlap matching to prevent a single device from matching multiple hooks. Reported-by: Wei Fang Closes: https://lore.kernel.org/netfilter-devel/CANE+tVrDeNCHQVmsqkV2ozeBqyE3GtRDMhZgsg1bhw10yGNTRQ@mail.gmail.com/ Fixes: 6d07a289504a ("netfilter: nf_tables: Support wildcard netdev hook specs") Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1c43f5db482f74b41987c39c9c375a5e767556eb Author: Theodor Arsenij Larionov Trichkine Date: Tue Aug 25 12:10:56 2026 +0300 netfilter: nft_nat: fully initialise new_addr in netmap setup [ Upstream commit d313499df66159b4b7971d760d16729598ab7e5a ] nft_nat_setup_netmap() builds the mapped address in an on-stack union nf_inet_addr. For an IPv4 mapping it writes only the 4-byte .ip member and the loop runs a single 32-bit iteration, but it then copies the whole 16-byte union into range->min_addr and range->max_addr, so the upper 12 bytes reach nf_nat_setup_info() uninitialised. KMSAN reports an uninit-value in nf_nat_setup_info() reached from nft_nat_eval(). The IPv6 path fills all 16 bytes and is not affected. Zero-initialise new_addr. Fixes: 3ff7ddb1353d ("netfilter: nft_nat: add netmap support") Signed-off-by: Theodor Arsenij Larionov Trichkine Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit bd6f234e7016ffba09a394b90c8b85407b6498b5 Author: Karl Mehltretter Date: Sun Sep 6 19:03:01 2026 +0200 drm/msm/adreno: Fix the skip_gpu parameter description [ Upstream commit 8061ee61b9426fe38350fa9eead2d9c50b03deb6 ] The module parameter is skip_gpu, but its MODULE_PARM_DESC() names no_gpu, so modinfo describes a parameter that does not exist and shows no description for the real one. Use the parameter name in the description. Fixes: 3f17991488af ("drm/msm/adreno: Add a modparam to skip GPU") Assisted-by: LLM Signed-off-by: Karl Mehltretter Patchwork: https://patchwork.freedesktop.org/patch/751406/ Message-ID: <20260906170301.2393-1-kmehltretter@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit cebb1748c3dfb214b154433110df25f15c7c71a8 Author: Karl Mehltretter Date: Sun Sep 6 19:03:47 2026 +0200 drm/msm: Fix the separate_gpu_kms parameter description [ Upstream commit adf5967331318bcb436fc80069915231ec039352 ] The module parameter is separate_gpu_kms, but its MODULE_PARM_DESC() names separate_gpu_drm, so modinfo describes a parameter that does not exist and shows no description for the real one. Use the parameter name in the description. Fixes: 217ed15bd399 ("drm/msm: enable separate binding of GPU and display devices") Assisted-by: LLM Signed-off-by: Karl Mehltretter Patchwork: https://patchwork.freedesktop.org/patch/751407/ Message-ID: <20260906170347.2427-1-kmehltretter@gmail.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit fd7be7e8b34f79c2e38c6d7caa1abe7da6ec8261 Author: David Laight Date: Mon Aug 3 10:47:01 2026 +0100 x86/div64: Fix addition of large constants in mul_u64_add_u64_div_u64() [ Upstream commit f65d38155aef069c897a64643a03db237dd1e0c8 ] Adding constants over 2^31 fails to compile because the ADD instruction only supports 32bit signed immediates. Replace the "irm" constraint with "erm" so that the compiler loads large constants into a register. Found by a patch to drivers/iio/frequency/ad9910.c [ bp: Massage commit message. ] Fixes: 6480241f31f5 ("lib: add mul_u64_add_u64_div_u64() and mul_u64_u64_div_u64_roundup()") Signed-off-by: David Laight Signed-off-by: Borislav Petkov (AMD) Reviewed-by: H. Peter Anvin Link: https://patch.msgid.link/20260803094702.3852-2-david.laight.linux@gmail.com Signed-off-by: Sasha Levin commit e6bdfdf3bcb02d0d626a45e8c98b7e63d2fddf9d Author: Jérémy Jean Date: Tue Sep 8 08:55:20 2026 +0000 RDMA/siw: Bound fragmented header copies by the remaining length [ Upstream commit 9ff797e516dbc1ecb73701ec4c24055712d44411 ] siw_get_hdr() can receive an extended DDP/RDMAP header across more than one TCP callback. The first callback may receive most of the header, while the next one still limits the copy to hdrlen - MIN_DDP_HDR instead of the number of missing bytes. This makes the destination move past the end of the header and overwrite the receive state, including fpdu_part_rcvd. A later callback can then use a negative fpdu_part_rcvd value as a copy offset, which creates an OOB write. Use the number of header bytes already received when calculating the next copy length. Fixes: 754209850df8 ("RDMA/siw: Always consume all skbuf data in sk_data_ready() upcall.") Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20260908085520.1746329-1-Jeremy.Jean@oss.cyber.gouv.fr Assisted-by: Codex:gpt-6 Acked-by: Bernard Metzler Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9ecd3dcbdf1f315aadc049b291f59c79dc478062 Author: Leon Romanovsky Date: Thu Sep 10 09:35:13 2026 -0400 RDMA/efa: Keep EQ resources alive while IRQ is registered [ Upstream commit e22a3627b7151754f07f90ea3d1ab6e85f5d93f4 ] The completion IRQ handler accesses the EQ state and DMA buffer. Its IRQ was registered before that state was initialized, while teardown released the buffer before free_irq() synchronized the handler. Initialize the EQ without arming it, register the IRQ, and then arm it. Reverse the resource order during teardown by freeing the IRQ before destroying the EQ. Fixes: 2a152512a155 ("RDMA/efa: CQ notifications") Link: https://patch.msgid.link/20260907-use-after-free-of-admin-queue-struct-v1-2-dd9d9267fbf4@nvidia.com Reviewed-by: Michael Margolin Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit cf5520d1c931a70ccce0a1a247113bcec47a42be Author: Leon Romanovsky Date: Thu Sep 10 09:35:13 2026 -0400 RDMA/efa: Keep admin queues alive while IRQ is registered [ Upstream commit e08aca85c02ff290f785f07acae758f0daf5f49e ] The management IRQ handler accesses both the admin completion queue and the async event queue. The driver registered the IRQ before constructing these queues and destroyed them before freeing the IRQ, so the handler's lifetime was not contained by the resources it accesses. Initialize the queues with interrupts masked, request the IRQ, and then switch to interrupt mode. On removal, reset the device and free the IRQ before destroying the queues. Also reset the device before destroying the queues if IRQ registration fails, because the device already has their DMA addresses. Fixes: b7f5e880f377 ("RDMA/efa: Add the efa module") Link: https://patch.msgid.link/20260907-use-after-free-of-admin-queue-struct-v1-1-dd9d9267fbf4@nvidia.com Reviewed-by: Michael Margolin Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit bd4f8c894634d7d551833a7d15abd0ad21fcaee2 Author: Alex Bereza Date: Tue Aug 18 09:36:29 2026 +0200 dmaengine: xilinx_dma: Fix hardware buffer descriptor chain after cyclic DMA [ Upstream commit 7ed1e3070c9b4bbd67d5519e14711038dd53ab13 ] Using the DMA in cyclic mode modifies the hardware buffer descriptor chain in xilinx_dma_prep_dma_cyclic so that the last descriptor used by the cyclic transfer points back to the first descriptor, but it never restores the original descriptor ring. This breaks using non-cyclic mode after cyclic mode with an error like: xilinx-vdma 86000000.dma: Channel 00000000354d5c8d has errors 100, cdr 6de40000 tdr 6de40400 The only way to get out of this error state is to rebuild the hardware buffer descriptor ring by releasing and re-acquiring the channel. Fix using non-cyclic mode after cyclic mode by always restoring the original buffer descriptor ring in the same manner as it is set up by xilinx_dma_alloc_chan_resources(). Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario") Signed-off-by: Alex Bereza Reviewed-by: Frank Li Reviewed-by: Suraj Gupta Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-after-cyclic-mode-v1-1-1fe47e701d6c@bereza.email Link: https://patch.msgid.link/20260818-fix-hw-buf-desc-after-cyclic-mode-v2-1-530ff44c6a81@bereza.email Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1de93785f32b450e9eae1e4fcfb7d03eb49eb27e Author: Sascha Hauer Date: Mon Aug 17 22:44:33 2026 +0200 dmaengine: pxa: fix double counting of the hw descriptors [ Upstream commit f6504be006aa4bb4bd26285f410a885c17920d65 ] pxad_alloc_desc() was converted from kzalloc(struct_size(sw_desc, hw_desc, nb_hw_desc), GFP_NOWAIT) to kzalloc_flex(), which sets the __counted_by() counter sw_desc->nb_desc itself - but only where the compiler has __builtin_counted_by_ref(), so from gcc 15.1 or clang 22.1 on. The loop below it still increments nb_desc, which makes it come out doubled there and correct elsewhere. nb_desc is what pxad_free_desc() iterates over and what set_updater_desc() indexes from, so set it explicitly and drop the increment. The error path has to lower it to the number of descriptors allocated so far, otherwise pxad_free_desc() would free entries that were never allocated. Fixes: 69050f8d6d075 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types") Assisted-by: Claude:claude-opus-5 Signed-off-by: Sascha Hauer Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20260817-dmaengine-pxa-v1-1-850c215c1196@pengutronix.de Link: https://patch.msgid.link/20260817-dmaengine-pxa-v2-1-f42ab0569a48@pengutronix.de Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e71fc80d7d38ced4511611473e86cfdad6efad8b Author: Alex Bereza Date: Mon Aug 17 11:23:55 2026 +0200 dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse order [ Upstream commit cee9c863ee68cb27d66745eb03f60e357f4f8ad2 ] xilinx_dma_alloc_chan_resources() builds a static ring of hardware buffer descriptors once and the driver uses this ring throughout the lifetime of a channel. This requires the allocation order of hardware buffer descriptors from chan->free_seg_list to stay in sync with the hardware buffer descriptor ring built at channel allocation time by returning oldest descriptors to chan->free_seg_list first. When chan->pending_list is not empty e.g. during xilinx_dma_terminate_all() the chan->free_seg_list and the order of the static hardware buffer descriptor ring get out of sync. Descriptors age in this order: pending -> active -> done. So freeing pending_list first returns the newest buffer descriptors to the chan->free_seg_list first and thus breaks the order required by the static hardware buffer descriptor ring. Then when the channel is reused, after a wrap around of the free_seg_list the DMA will find a hardware buffer descriptor with a length field that is still zeroed and stop with something like this: xilinx-vdma 86000000.dma: Channel 000000003a21d7b8 has errors 10, cdr 6de4c000 tdr 6de4c000 After this no more descriptors are completed and a consumer potentially blocks and waits forever. The only way to get out of this error state is to rebuild the static hardware buffer descriptor ring and the free_seg_list by releasing and re-acquiring the channel. Fix the order in which hardware buffer descriptors are returned to free_seg_list to ensure the mentioned requirement holds. Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario") Signed-off-by: Alex Bereza Reviewed-by: Frank Li Reviewed-by: Suraj Gupta Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-reuse-v1-1-d79827a844c7@bereza.email Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 43b3e8fc153bfa6388a6f6fc933456af0adadec4 Author: Karl Mehltretter Date: Sun Sep 6 19:10:09 2026 +0200 scsi: qla2xxx: Fix the ql2xfc2target parameter description [ Upstream commit 779f202a92ef10a426efc07d0f4267918cb07ca3 ] The module parameter is ql2xfc2target, but its MODULE_PARM_DESC() names qla2xfc2target, so modinfo describes a parameter that does not exist and shows no description for the real one. Use the parameter name in the description. Fixes: 877b03795fcf ("scsi: qla2xxx: Add option to disable FC2 Target support") Assisted-by: LLM Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260906171009.2560-1-kmehltretter@gmail.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit ae75153f0a9fa268dfe53adda9fc7b28bbdbbb94 Author: Karl Mehltretter Date: Sun Sep 6 19:09:25 2026 +0200 scsi: pm80xx: Fix the use_msix, use_tasklet and read_wwn parameter descriptions [ Upstream commit 264bf9655c3d067d775a46f05eb8c871c488a864 ] The MODULE_PARM_DESC() lines of use_msix, use_tasklet and read_wwn all name a parameter zoned, which does not exist, and the use_tasklet one repeats the use_msix text. modinfo shows three "zoned" entries and no description for the real parameters. Name the right parameters and describe use_tasklet. Fixes: efa1fca45082 ("scsi: pm8001: Remove PM8001_USE_MSIX") Fixes: 205430290ad0 ("scsi: pm8001: Remove PM8001_USE_TASKLET") Fixes: 80975adc79dd ("scsi: pm8001: Remove PM8001_READ_VPD") Assisted-by: LLM Signed-off-by: Karl Mehltretter Reviewed-by: Damien Le Moal Link: https://patch.msgid.link/20260906170925.2524-1-kmehltretter@gmail.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit db1ca0ffc56b30455fa9df5c275942251548146f Author: Meijing Zhao Date: Wed Sep 2 15:59:44 2026 +0800 mm: memblock: show all region flags in debugfs [ Upstream commit e2d5b01f878d76bd1142e512a0b979a1d3cd0abf ] Commit 493f349e38d0 ("memblock: Add flags and nid info in memblock debugfs") made memblock_debug_show() stop after finding the first set flag. A memblock region can carry multiple flags, so the remaining flags are hidden from debugfs. Walk all bits in the region flags and print every set flag separated by "|". Keep walking beyond flagname[] so that a set flag without a known name is reported as UNKNOWN rather than silently ignored. Fixes: 493f349e38d0 ("memblock: Add flags and nid info in memblock debugfs") Signed-off-by: Meijing Zhao Link: https://patch.msgid.link/20260902075944.3742866-1-zhaomeijing100@gmail.com Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin commit 03d67414bd05b86029afc14535238a9393eac1c6 Author: Johannes Berg Date: Tue Sep 8 14:28:21 2026 +0200 wifi: mac80211: set up the TX info early to fix failure paths [ Upstream commit 50d3d79dc0743b616afb00d01a626c76758721f7 ] The previous commit 2c51457d930f ("wifi: mac80211: free ack status frame on TX header build failure") cleaned up the leak, but still left the code a bit messy and the failed SKB didn't get reported to userspace. Fix this up by initialising skb->cb[] earlier, which allows using ieee80211_free_txskb() and therefore reports it for the failure in ieee80211_build_hdr(), and unifies the ieee80211_skb_resize() failure path with it. Assisted-by: LLM Fixes: c3e7724b6bc2 ("mac80211: use ieee80211_free_txskb to fix possible skb leaks") Link: https://patch.msgid.link/20260908122838.201719-22-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4a4e3fa77ea36d3419d806fb5883ef425a605a5d Author: Johannes Berg Date: Tue Sep 8 14:28:20 2026 +0200 wifi: mac80211: mesh: release the channel if start fails [ Upstream commit ae97fff6495a8764bc0ef281cfe5444f701e527f ] ieee80211_join_mesh() acquires a channel context and then calls ieee80211_start_mesh(), which can fail. In that case, the chanctx isn't released then interface removal will attempt to unassign it after it's removed from the driver, hitting: wlan0: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.c:366 at drv_unassign_vif_chanctx ieee80211_assign_link_chanctx __ieee80211_link_release_channel ieee80211_link_release_channel ieee80211_teardown_sdata unregister_netdevice_many_notify _cfg80211_unregister_wdev ieee80211_remove_interfaces ieee80211_unregister_hw mac80211_hwsim_del_radio hwsim_exit_net Correctly release the channel on start failures. Assisted-by: LLM Reported-by: syzbot+63a84ea9c0f57d6133fa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=63a84ea9c0f57d6133fa Fixes: 2b5e19677592 ("mac80211: cache mesh beacon") Link: https://patch.msgid.link/20260908122838.201719-21-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ba5bf83a81e8832cb84bb3a2da67512f81f57a02 Author: Johannes Berg Date: Tue Sep 8 14:28:19 2026 +0200 wifi: mac80211: mesh: reset the CSA state when leaving [ Upstream commit 860134b3af77970e006feab7e5decb8c84771c7f ] ifmsh->csa is allocated in ieee80211_mesh_csa_beacon() and only freed in ieee80211_mesh_finish_csa(), i.e. when the channel switch completes. Leaving the mesh while a switch is still pending therefore leaks it. Additionally, ifmsh->csa_role and ifmsh->chsw_ttl have their state leak in this case, so things can get mixed up in addition to the memory leak. Refactor the reset and call it in ieee80211_stop_mesh() to fix it all. Assisted-by: LLM Reported-by: syzbot+f5752cd6b94fe38be666@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f5752cd6b94fe38be666 Fixes: b8456a14e9d2 ("{nl,cfg,mac}80211: implement mesh channel switch userspace API") Link: https://patch.msgid.link/20260908122838.201719-20-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9d83c08dcce808c732988a5291e3ef4f59d09edb Author: Johannes Berg Date: Tue Sep 8 14:28:18 2026 +0200 wifi: mac80211: add HE 6 GHz capability in the scan elems len [ Upstream commit cd54bf333f5631d3630bab0a832e9ae648f73515 ] The HE 6 GHz Band Capability element is in the probe request for every band if 6 GHz is supported, so add the size to scan_ies_len. Otherwise, building probe request elements can fail, triggering the WARN_ON in __ieee80211_start_scan(). Assisted-by: LLM Fixes: 2ad2274c58ee ("mac80211: Add HE 6GHz capabilities element to probe request") Reported-by: syzbot+f961b9f94edbc266f1f8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f961b9f94edbc266f1f8 Link: https://patch.msgid.link/20260908122838.201719-19-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c68c947e3489a323e4f3e8a764d3f26a6f6ab8e0 Author: Johannes Berg Date: Tue Sep 8 14:28:17 2026 +0200 wifi: mac80211: don't access the TSF of a down interface [ Upstream commit 0b1de9feeb8651f7a3bb53ed7c9006e3b5298c01 ] The tsf debugfs files call the driver even if the interface isn't up, tgriggering check-sdata-in-driver warnings. Reject the access in that case. Assisted-by: LLM Fixes: 37a41b4affa3 ("mac80211: add ieee80211_vif param to tsf functions") Reported-by: syzbot+1c8c45017f784e646b47@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1c8c45017f784e646b47 Link: https://patch.msgid.link/20260908122838.201719-18-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 15c408bae4f1155654380e32d60ab2bba4c58555 Author: Johannes Berg Date: Tue Sep 8 14:28:16 2026 +0200 wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set [ Upstream commit b481e64e4498e2c053d5954f546ee02338f6ab63 ] In the error path of ieee80211_mesh_csa_beacon() the settings that were just assigned are read back with rcu_dereference(), which lockdep then complains about. There's no need to read the pointer at all, tmp_csa_settings still is the right value anyway. Assisted-by: LLM Fixes: b8456a14e9d2 ("{nl,cfg,mac}80211: implement mesh channel switch userspace API") Reported-by: syzbot+b59873f5699e941717ca@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b59873f5699e941717ca Link: https://patch.msgid.link/20260908122838.201719-17-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1cf42768fa082e9a2f79f47edbc6458ec85fad57 Author: Johannes Berg Date: Tue Sep 8 14:28:15 2026 +0200 wifi: mac80211: don't allow link changes when iface is down [ Upstream commit 370872d30349d81dec519e15ea2949fd63511cf7 ] ieee80211_set_active_links() only checks that the interface is running in the inner __ieee80211_set_active_links(), after drv_can_activate_links() was already called, so using active_links on an interface that's down triggers the check-sdata-in-driver warning. Add the missing check in the debugfs file. Assisted-by: LLM Fixes: 3d9011029227 ("wifi: mac80211: implement link switching") Reported-by: syzbot+582469b3a9ef5f13606b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=582469b3a9ef5f13606b Link: https://patch.msgid.link/20260908122838.201719-16-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1c0a5c96473b9e7a5f4c453ef6a13dc0f5589a4b Author: Johannes Berg Date: Tue Sep 8 14:28:14 2026 +0200 wifi: mac80211: require a peer station for TDLS setup confirm [ Upstream commit 038e1d126304fd25d507fd4e671232df57bd1799 ] It's nonsense for the setup confirm to go to station that doesn't even exist, and it hits a warning when building the frame: WARN_ON_ONCE(!sta || !ap_sta) Only accept WLAN_TDLS_SETUP_CONFIRM when the station is already there as a TDLS station. Need to copy the call to ieee80211_tdls_prep_mgmt_packet() since the existing WLAN_TDLS_DISCOVERY_REQUEST already falls through to it. Assisted-by: LLM Fixes: 6f7eaa47e1de ("mac80211: add TDLS QoS param IE on setup-confirm") Reported-by: syzbot+e55106f8389651870be0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e55106f8389651870be0 Link: https://patch.msgid.link/20260908122838.201719-15-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 875835377d8d62c849b4eb03a7abfafa71d7668f Author: Johannes Berg Date: Tue Sep 8 14:28:13 2026 +0200 wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown [ Upstream commit 4504f3960dc4501c73be9f99eabda2e26e9db41e ] On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same AP_VLAN up again will increment the counter again and eventually hit the sanity check: WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt != master->crypto_tx_tailroom_needed_cnt); Reset it on ifdown to avoid that. Assisted-by: LLM Fixes: f9dca80b98ca ("mac80211: fix AP_VLAN crypto tailroom calculation") Reported-by: syzbot+de3ee5362db09487ea37@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=de3ee5362db09487ea37 Link: https://patch.msgid.link/20260908122838.201719-14-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c69718519a81e87284494d0c6e6eb7bdd834707a Author: Johannes Berg Date: Tue Sep 8 14:28:12 2026 +0200 wifi: mac80211: don't allow injecting frames wider than the chanctx [ Upstream commit e14bf37bb2b3853012ff160131d1c6233f7a9cc9 ] Frames injected on a monitor interface can carry a radiotap field requesting a bandwidth, which mac80211 passes down to the driver regardless of the the actual operational bandwidth. If the bandwidth requested is too wide, that triggers a warning in hwsim: WARN_ON(hwsim_get_chanwidth(bw) > hwsim_get_chanwidth(confbw)) Drop such frames entirely instead since they cannot be sent. Assisted-by: LLM Fixes: 646e76bb5daf ("mac80211: parse VHT info in injected frames") Reported-by: syzbot+435fdb053cf98bfa5778@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=435fdb053cf98bfa5778 Link: https://patch.msgid.link/20260908122838.201719-13-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d7fa45d8123a7f794b93fc22dbcf19f38dc4d8cb Author: Johannes Berg Date: Fri Sep 4 17:01:35 2026 +0200 wifi: mac80211_hwsim: don't hand frames to mac80211 while stopping [ Upstream commit 87840d4a3a21b1c19b867a80e16ba69dff284de2 ] The code checks ->started for frames coming from wmediumd, but the radio can be stopped after the check and before frame delivery, causing mac80211 to hit the WARN_ON(!local->started). Expand the mutex for this case and synchronise against it when the radio is stopped to avoid being able to hit the warning with hwsim. Drop the error print that would've complicated the error path, it only triggers for allocation failures (already noisy) and malformed frames anyway. Assisted-by: LLM Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx") Reported-by: syzbot+b4aa2b672b18f1d4dc5f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b4aa2b672b18f1d4dc5f Link: https://patch.msgid.link/20260904170140.5f69a10d606b.I4a7921d00643f69e439c7a3b221d104f66a3dcdc@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b949b2720688691f1e41bdbfbe3df2b6dc77c34d Author: Johannes Berg Date: Fri Sep 4 17:02:02 2026 +0200 wifi: cfg80211: get the wiphy out of a dying network namespace [ Upstream commit 4635b1a1c1d693178a537446a6e09963f0fdae52 ] When a network namespace is destroyed, cfg80211_pernet_exit() moves any wiphy back to the initial namespace, and just warns if that fails. But moving an interface can fail (due to allocation failures), and then the wiphy is left behind with a garbage netns pointer: Kernel mode fault at addr 0x30 genlmsg_multicast_netns.constprop.0+0x46/0xcf [cfg80211] nl80211_notify_wiphy+0xcd/0xe8 [cfg80211] wiphy_unregister+0x169/0x3fc [cfg80211] Note that commit debac3a20dec ("net: Remove conflicting altnames for dying netns in __dev_change_net_namespace().") fixed another path that could reach it without allocation failures. Remove interfaces that cannot be moved instead of failing the switch, so that the wiphy always ends up in the initial namespace. In this case the netdev core will unregister the interfaces anyway. Assisted-by: LLM Reported-by: syzbot+c5f8a81e794d4a4f2014@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c5f8a81e794d4a4f2014 Fixes: 463d018323851 ("cfg80211: make aware of net namespaces") Link: https://patch.msgid.link/20260904170220.7f3edc6d9992.I5e57921011244d3d8ef14d89e738aa19a5d972a0@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 821bab0456dfca12acef6df702c8f2477d313227 Author: Johannes Berg Date: Fri Sep 4 17:02:01 2026 +0200 wifi: mac80211: unlist vifs when their netdev is unregistered [ Upstream commit eee2efd82867b623982ac51925b5a1812a74c50d ] mac80211 only removes vifs from the local->interfaces list when an interface is removed via ieee80211_if_remove(), before it unregisters the netdev. However, it's possible for a netdev to be unregistered without going through that: When the netns that holds the wiphy is destroyed, the wiphy is supposed to move to the init_ns, but that can run into allocation failures. Then, mac80211 has an interface listed that doesn't exist, and will eventually hit BUG: failure at net/wireless/core.h:141/wiphy_to_rdev()! ... _cfg80211_unregister_wdev+0x24/0x36a [cfg80211] cfg80211_unregister_wdev+0x15/0x1d [cfg80211] ieee80211_remove_interfaces+0x1ff/0x257 [mac80211] ieee80211_unregister_hw+0x73/0x1d1 [mac80211] mac80211_hwsim_del_radio+0x114/0x166 [mac80211_hwsim] Remove the interface from the list in ->ndo_uninit if it's still around to avoid this. Assisted-by: LLM Fixes: 463d018323851 ("cfg80211: make aware of net namespaces") Link: https://patch.msgid.link/20260904170220.038ad73e6c04.I990abca78483e058746b6f42b4796717c3028164@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 739b7bf3942da4cde8eedb143d01a16ed865d1d7 Author: Johannes Berg Date: Fri Sep 4 17:02:00 2026 +0200 wifi: cfg80211: undo netns switch if renaming the wiphy fails [ Upstream commit a41bd1938a9bfe226d444172a7e20e4bd5097960 ] Once all the interfaces have been moved, cfg80211_switch_netns() moves the wiphy itself by setting its network namespace and then renaming it, which makes sysfs move it. The rename can fail (but only on allocation failures), leaving things mixed up and hitting the warning there. Ignoring it isn't great, undo the move and let the change fail in this case. If undo fails then WARN, then things would again be stuck in two different network namespaces. Assisted-by: LLM Reported-by: syzbot+3515319a302224e081b4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3515319a302224e081b4 Fixes: 463d018323851 ("cfg80211: make aware of net namespaces") Link: https://patch.msgid.link/20260904170220.7966cc705e33.Ib398351113bbd3cab85302467060cab378564421@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e6660383ebf57723c69119029e36a3be7932bd60 Author: Johannes Berg Date: Fri Sep 4 17:01:59 2026 +0200 wifi: cfg80211: restore netns_immutable on failures [ Upstream commit eeee52cfd1d639774c9812e8890631404a057dd2 ] Switching a wiphy's netns has to clear netns_immutable before moving interfaces, but then if any of the interfaces fails to move, it gets netns_immutable cleared forever. Then userspace can move it by itself, breaking the assumption that they all move together. Fix the order here and always reset netns_immutable after attempting the move. Assisted-by: LLM Fixes: 463d018323851 ("cfg80211: make aware of net namespaces") Link: https://patch.msgid.link/20260904170220.7ea88157dcbc.Id868585a790be8b9ece9b39b0db464a5963faaf3@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0cd452ccaa5c5971440256ce72c64611eca176c1 Author: Johannes Berg Date: Fri Sep 4 16:57:14 2026 +0200 wifi: mac80211: only operate on TDLS peers in the TDLS code [ Upstream commit 6f0a100df8539ce90f37c14e1945f396ca2410bc ] ieee80211_tdls_oper() can operate on the AP station, which then yields various warnings when the AP station is removed then or at a later point in time after being confused for a TDLS peer. Always check that the station is a TDLS peer. Assisted-by: LLM Fixes: dfe018bf9953 ("mac80211: handle TDLS high-level commands and frames") Fixes: 17e6a59a365a ("mac80211: cleanup TDLS state during failed setup") Reported-by: syzbot+a59b5291776979816910@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a59b5291776979816910 Link: https://patch.msgid.link/20260904165722.3bad8b79679b.I99618745e83cbe9b9804179387be15fcd3505ae3@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit de6f9561db572df86d65c05545eb2397313bb8a5 Author: Johannes Berg Date: Fri Sep 4 16:57:13 2026 +0200 wifi: mac80211: reset the LED state when ifup fails [ Upstream commit 78183e8331958fda11cd2b6850bb424a9747c4b2 ] When the first interface comes up, the radio LED is turned on. This can start the TPT trigger timer, which continues running. But if bringing up the interface fails then the timer keeps running and won't be stopped by anything, eventually it can be freed: ODEBUG: free active (active state 0) object: ffff888127e12130 object type: timer_list hint: tpt_trig_timer+0x0/0x300 net/mac80211/led.c:145 WARNING: CPU: 0 PID: 5923 at lib/debugobjects.c:612 debug_print_object+0x1a2/0x2b0 debug_check_no_obj_freed+0x4b7/0x600 lib/debugobjects.c:1129 kfree+0x436/0x670 mm/slub.c:6818 ieee80211_led_exit+0x162/0x1c0 net/mac80211/led.c:210 ieee80211_unregister_hw+0x27e/0x3a0 net/mac80211/main.c:1706 rt2x00lib_remove_dev+0x55b/0x670 Undo the LED state in the error path. Assisted-by: LLM Fixes: 67408c8c7b9d ("mac80211: selective throughput LED trigger active") Reported-by: syzbot+e84ecca6d1fa09a9b3d9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e84ecca6d1fa09a9b3d9 Link: https://patch.msgid.link/20260904165722.044aa432f873.I601a67a2cd558b8ef8416a07554ae7efe896e9d8@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6eac225f59c1c2277ac74f8a716d6df0ba3b8d28 Author: Johannes Berg Date: Fri Sep 4 16:57:12 2026 +0200 wifi: mac80211: reset state when starting AP fails [ Upstream commit 3f28551d0241254a75626d868041c6340285088b ] ieee80211_start_ap() can set enable_beacon (and beacon_int) and fail later, leaving it set forever. Scanning can then attempt to restore beaconing on such an interface, leading to: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:mac80211_hwsim_link_info_changed+0xca7/0xf00 Call Trace: drv_link_info_changed+0x413/0x860 net/mac80211/driver-ops.c:495 ieee80211_link_info_change_notify+0x24b/0x3c0 net/mac80211/main.c:427 ieee80211_offchannel_return+0x381/0x580 net/mac80211/offchannel.c:160 __ieee80211_scan_completed+0x993/0xe30 net/mac80211/scan.c:519 ieee80211_scan_work+0x472/0x2010 net/mac80211/scan.c:1193 cfg80211_wiphy_work+0x2b7/0x550 net/wireless/core.c:538 in hwsim. Also, cfg80211 then allows changing the interface type, and the off-channel path getgs confused about beaconing as well, leading to another warning: WARNING: net/mac80211/driver-ops.c:468 at drv_link_info_changed+0x583/0x880 ieee80211_link_info_change_notify+0x24b/0x3c0 net/mac80211/main.c:427 ieee80211_offchannel_stop_vifs+0x328/0x5c0 net/mac80211/offchannel.c:122 ieee80211_start_sw_scan net/mac80211/scan.c:583 [inline] __ieee80211_start_scan+0xfb6/0x1af0 net/mac80211/scan.c:882 Reset the state on failures to always have it correct. Assisted-by: LLM Fixes: d6a83228823f ("mac80211: track enable_beacon explicitly") Reported-by: syzbot+ca7a2759caaa6cd4e3db@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ca7a2759caaa6cd4e3db Reported-by: syzbot+c4686c3eb8b64032618f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c4686c3eb8b64032618f Link: https://patch.msgid.link/20260904165722.9629429a5221.I7f599412bfe12a09d41ea4901be9ad165d07d133@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d222fdc973bb8dbf0357772bd9042ffdc8291939 Author: Johannes Berg Date: Fri Sep 4 16:57:11 2026 +0200 wifi: mac80211: abort chanswitch when leaving a mesh [ Upstream commit ac7472a24bd433b81c06582835dd1d5547c10da9 ] The code in ieee80211_stop_mesh() leaves CSA active, but leaving the mesh released the channel context, so the CSA finalize work crashes: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003 KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:ieee80211_put_srates_elem+0x42/0x640 net/mac80211/util.c:3272 Call Trace: ieee80211_mesh_build_beacon+0xa83/0x1b50 net/mac80211/mesh.c:1093 ieee80211_mesh_rebuild_beacon+0xc7/0x170 net/mac80211/mesh.c:1147 ieee80211_mesh_finish_csa+0x131/0x210 net/mac80211/mesh.c:1542 ieee80211_set_after_csa_beacon net/mac80211/cfg.c:4085 [inline] __ieee80211_csa_finalize net/mac80211/cfg.c:4133 [inline] ieee80211_csa_finalize+0x633/0x1150 net/mac80211/cfg.c:4155 cfg80211_wiphy_work+0x2ab/0x450 net/wireless/core.c:438 Abort the channel switch properly. Assisted-by: LLM Fixes: b8456a14e9d2 ("{nl,cfg,mac}80211: implement mesh channel switch userspace API") Reported-by: syzbot+81cd9dc1596563141d19@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=81cd9dc1596563141d19 Link: https://patch.msgid.link/20260904165722.d0b87eee08aa.I80550d6127e0bb26efb49a5fbe95be1aef1cd0cb@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7aca529c0d8d4aed6529b9ba98b9699e21b54d02 Author: Johannes Berg Date: Fri Sep 4 16:57:10 2026 +0200 wifi: mac80211: suppress chanctx warning for debugfs reset [ Upstream commit bf29d085e0eba92388518719d044f4702a8c6644 ] Before suspend all the channel contexts should removed, so the warning makes sense and should be there, but during reset the same code is called without first removing. Limit the check to the real suspend case. Assisted-by: LLM Fixes: 12e7f517029d ("mac80211: cleanup generic suspend/resume procedures") Reported-by: syzbot+56a1a45a9a2c04d425ff@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=56a1a45a9a2c04d425ff Link: https://patch.msgid.link/20260904165722.fe46395e310b.Ic4aaa95bd9d0ceb6a3cd7d84c425afee7d7d3dd7@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ea3ef2165e4751df2ee3bc1c07a192243a08faa5 Author: Johannes Berg Date: Fri Sep 4 16:57:09 2026 +0200 wifi: mac80211: don't offload TC setup on AP_VLAN interfaces [ Upstream commit 362bd5bce29ed0f6fd3d39a7065567777d70606e ] AP_VLAN interfaces are purely virtual, so don't try to offload TC setup to drivers. We can't really use the AP interface either since we may not know it all the time, and it could technically even change. Just reject the TC offload so things get done in software. Assisted-by: LLM Fixes: 61587f1556fe ("wifi: mac80211: add support for letting drivers register tc offload support") Reported-by: syzbot+f1ba58d6b55abd13239e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f1ba58d6b55abd13239e Link: https://patch.msgid.link/20260904165722.726cc076cecb.Iccfd88b13635425e850ce031376eb60a4ce5f4f8@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 23d51c0bc18f21d957756ba4650520bb3bc726b2 Author: Johannes Berg Date: Fri Sep 4 16:57:08 2026 +0200 wifi: mac80211: don't warn when an IBSS has no channel to scan [ Upstream commit a7491b7efbd9136b120a12ed72af9c12121dd134 ] ieee80211_request_ibss_scan() warns when regulatory leaves no allowed channel, but that can happen as the regdomain can change while IBSS is operating, and it can continue to operate briefly during the 60s grace period until it's shut down. Just remove the warning in this case. Assisted-by: LLM Fixes: 34bcf7150241 ("mac80211: fix ibss scanning") Reported-by: syzbot+1634c5399e29d8b66789@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1634c5399e29d8b66789 Link: https://patch.msgid.link/20260904165722.fe380c27fef4.I0e8bee2e12a40d240851a4bc724d47753af46159@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 58b806f699052c572dec6cab2c376f884f27e98f Author: Johannes Berg Date: Fri Sep 4 16:57:07 2026 +0200 wifi: mac80211: don't start a ROC while scanning [ Upstream commit 733f0fde95392ed5f61a4e36aee661ea8d0e8581 ] The ROC work can be pending when a scan starts (which requires ROC list to be empty, but that's possible), and then a new ROC can be added to the list and the work will pick it up. Avoid starting that ROC if a scan made it between things, as otherwise we'll hit a warning later: WARNING: net/mac80211/offchannel.c:404 at ieee80211_start_next_roc+0x256/0x2d0 Workqueue: events_unbound cfg80211_wiphy_work Call Trace: __ieee80211_scan_completed+0x4fd/0xe40 net/mac80211/scan.c:537 ieee80211_scan_work+0x472/0x1ff0 net/mac80211/scan.c:1193 cfg80211_wiphy_work+0x410/0x570 net/wireless/core.c:513 Assisted-by: LLM Fixes: aaa016ccd5df ("mac80211: rewrite remain-on-channel logic") Reported-by: syzbot+c3a167b5615df4ccd7fb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c3a167b5615df4ccd7fb Link: https://patch.msgid.link/20260904165722.f9d5b150edd8.I61bc9de8c8d089096ad695213b9c85c7df38c3bd@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9580c87b0210d78ad969e2910c423db4a32d0e2a Author: Johannes Berg Date: Fri Sep 4 16:55:07 2026 +0200 wifi: cfg80211: fix NAN regulatory enforcement [ Upstream commit 17a5f8571d1d40c88b78cfc154a7da0d60f13f37 ] reg_wdev_chan_valid() returns early for any wdev that has no netdev, which is fine for P2P originally (and later PD still), but NAN has no netdev and yet enforcement code was added and is needed, but is dead code right now. Use wdev_running() instead so that netdev-less wdevs aren't skipped. P2P/PD don't do anything in the later switch, but NAN code can now be reached. Assisted-by: LLM Fixes: 0e8ec738a71e ("wifi: cfg80211: add support for NAN data interface") Link: https://patch.msgid.link/20260904165614.6abc075b5401.Ib90696e3fa49b1698c27d64db5360d51f6f187a9@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b0e3f019e461ac42e45aa3ec1216cefaca2f4a8b Author: Johannes Berg Date: Fri Sep 4 16:55:06 2026 +0200 wifi: cfg80211: ibss: ref BSS entry for joined event [ Upstream commit 708f9d43d6a2eb9c6b83fe62af628de9dffd9314 ] When the IBSS is joined, we only record the BSSID/channel in the event and look up the BSS entry when processing it. However, that's racy, e.g. a new scan with NL80211_SCAN_FLAG_FLUSH can remove it, causing a warning in the event work: !bss WARNING: net/wireless/ibss.c:37 at __cfg80211_ibss_joined+0x3d3/0x440 Workqueue: cfg80211 cfg80211_event_work cfg80211_process_wdev_events+0x39f/0x5b0 net/wireless/util.c:1144 cfg80211_process_rdev_events+0xa1/0x110 net/wireless/util.c:1179 cfg80211_event_work+0x2f/0x40 net/wireless/core.c:393 Do the lookup early (the driver is expected to only join an IBSS that has a BSS entry) and keep a reference to it. Assisted-by: LLM Fixes: 667503ddcb96 ("cfg80211: fix locking") Reported-by: syzbot+7f064ba1704c2466e36d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7f064ba1704c2466e36d Link: https://patch.msgid.link/20260904165614.f49a213f0e49.I192bfe738750ebb5f2c4faa3019a428da64cd3ec@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0aa44982125c86b47961be5ac1c82eddab8080f3 Author: Johannes Berg Date: Fri Sep 4 16:55:05 2026 +0200 wifi: cfg80211: don't filter by BSS type when removing stale entries [ Upstream commit b377e1000d963e7182a987082b4b06580bd7ac84 ] When an assoc AP switches to a channel that already has a BSS entry, cfg80211_update_assoc_bss_entry() removes that entry before rehashing the real one, since the two would otherwise collide in the BSS rbtree. The lookup for that entry also required it to match the connection's BSS type, so an entry advertising e.g. the IBSS capability bit was left in place, and the following cfg80211_rehash_bss() then ran into it: WARN_ON(!cmp) Changing the type shouldn't really happen, but can be triggered by a rogue AP/device, so drop the check and remove any entries matching the comparison. Assisted-by: LLM Fixes: 0afd425b1b64 ("cfg80211: fix duplicated scan entries after channel switch") Reported-by: syzbot+dc6f4dce0d707900cdea@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dc6f4dce0d707900cdea Link: https://patch.msgid.link/20260904165614.1f05dae1c546.Ib52d57b57caa912efee020f9d4a033a5160617ce@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 332ea1502c46f53375cb109fa82bfaff818f3a41 Author: Johannes Berg Date: Fri Sep 4 16:55:04 2026 +0200 wifi: cfg80211: only group hidden BSSes with beacon entries [ Upstream commit 068843ed0902c552a13860c5ec6b2ca65b57a065 ] When a probe response for an unknown BSS comes in, __cfg80211_bss_update() looks for an existing entry with the same BSSID and a hidden (zero-length or NUL-filled) SSID, and if it finds one it groups them, using the beacon IEs from the existing entry. But that could find another entry without a beacon, if it was also from a probe response (with SSID), so there's a group without beacon elements. If a beacon with a hidden SSID for that BSSID arrives later, cfg80211_combine_bsses() goes looking for the probe response entries that belong to it - i.e. entries with the same BSSID and channel that have no beacon IEs - and finds those two. They are already grouped with each other, so it hits its WARN_ON_ONCE(bss->pub.hidden_beacon_bss) WARN_ON_ONCE(!list_empty(&bss->hidden_list)) which are there because an entry without beacon elements is not supposed to be part of a group yet. Only combine entries when a beacon was already received, ones that are kept separate will be combined when a beacon arrives. Assisted-by: LLM Fixes: 4593c4cbe1c9 ("cfg80211: fix BSS list hidden SSID lookup") Reported-by: syzbot+1a797e1c81be78a2ace7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1a797e1c81be78a2ace7 Link: https://patch.msgid.link/20260904165614.bcfa64715745.Iad740347c86de56d4ff4f96a95f3c3afc47c42de@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cf6da29d17994865f73ca70976495ea856909c63 Author: Johannes Berg Date: Fri Sep 4 16:55:03 2026 +0200 wifi: cfg80211: don't free driver-owned scan requests [ Upstream commit dab68a74e90b8e07f08ed9deaa5884857a3cfe89 ] When an interface goes down while a scan is running, cfg80211 completes the scan towards userspace and frees the scan request. However, the driver can be convinced that it owns the request, since the cancellation is (intended to be) asynchronous. The WARN_ON() in the netdev notifier was meant to catch this, but it's not actually avoidable, so it triggers and we get a UAF in scan_done(). There doesn't seem to be a great way around it, so just track that the driver is still convinced it owns the request, and then just free it on completion if it was already cancelled. Also remove the warnings since they can trigger in the intended architecture. Assisted-by: LLM Fixes: 4a58e7c38443 ("cfg80211: don't "leak" uncompleted scans") Reported-by: syzbot+189dcafc06865d38178d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=189dcafc06865d38178d Link: https://patch.msgid.link/20260904165614.375e543228b1.I03cbb5a54cb02d6bba5034286af1ed73aba134d1@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4aed7e47a10b94ea3c5171e8d1382081accd2e03 Author: Shivank Garg Date: Sat Aug 22 19:22:06 2026 +0000 dmaengine: wait for RCU readers before releasing dma_device [ Upstream commit dc750422170a563c7a81f6e49d36bb02c62ae37f ] dma_issue_pending_all() walks the dma_device_list with list_for_each_entry_rcu() under rcu_read_lock(). dma_device_release() unlinks the device with list_del_rcu() and then calls device->device_release() (which in many drivers, such as plx_dma.c, directly calls kfree()). Because there is no grace period between unlinking the device and freeing it, concurrent RCU readers in dma_issue_pending_all() can access the device after it has been freed. The lockless walk originally relied on clients holding a dmaengine reference to pin the provider module, and therefore the device, for as long as they might traverse the list. Commit 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") decoupled the dma_device lifetime from the module reference, so the device can now be released while a reader is still walking the list. Add synchronize_rcu() before the device is freed, so RCU readers are guaranteed to have finished. Keep it unconditional: providers that do not implement device_release() free the device themselves once dma_async_device_unregister() returns. This call will delay for a grace period with dma_list_mutex held, which is safe and only teardown path is delayed. Fixes: 2ba05622b8b1 ("dmaengine: provide a common 'issue_pending_all' implementation") Suggested-by: Sashiko Link: https://sashiko.dev/#/patchset/20260526-dmaengine-kref-fix-v2-0-3df60afac01d@amd.com Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-4-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 02bd02c585293634b213b142cba63cbf77891f6b Author: Shivank Garg Date: Sat Aug 22 19:22:05 2026 +0000 dmaengine: fix use-after-free in dma_chan_put() and dma_release_channel() [ Upstream commit e873c74132f0c5f1452816cd9bb26208f0bba1e1 ] When dma_device_put() drops the last reference on chan->device->ref, dma_device_release() runs and may free the dma_device along with its channels. dma_chan_put() then still reads chan->device->owner via dma_chan_to_owner() for the trailing module_put(). KASAN catches it: slab-use-after-free in dma_chan_put+0x3e6/0x4c0 Read of size 8 by task insmod/6319 Freed by task 6319: kfree+0x225/0x470 dma_chan_put+0x395/0x4c0 dmaengine_put+0xf8/0x160 Cache the module owner in dma_chan_put() before the put so the trailing module_put() does not need chan->device. Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") Suggested-by: Sashiko Link: https://sashiko.dev/#/patchset/20260518-dmaengine-kref-fix-v1-1-4d6125048fb7@amd.com Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-3-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 77906ac448d2fa81fa710ae26c0e591ebdc81154 Author: Shivank Garg Date: Sat Aug 22 19:22:04 2026 +0000 dmaengine: Fix device kref underflow in dma_chan_put() [ Upstream commit 44dab659064eb5c10adb0306510eebe848ed592d ] dma_chan_get() takes chan->device->ref only on the slow path: /* no kref on fast path */ if (chan->client_count) { __module_get(owner); chan->client_count++; return 0; } if (!try_module_get(owner)) return -ENODEV; if (!dma_device_get(chan->device)) { // calls kref_get_unless_zero() dma_chan_put() drops the ref unconditionally, so every fast-path get/put pair drops one extra device reference. The bug fires when two conditions hold together: a non-private provider has a persistent client holding chan->client_count > 0 and another client cycles dmaengine_get()/dmaengine_put(). When the kref hits zero, the subsequent dma_find_channel() returns NULL even though the provider module is still loaded. Fix this by dropping device->ref only on the last put, matching the single slow-path get. Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-2-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b49a8488a46c6c60cefaa6f799ef22e662715312 Author: Donggeun Yoo Date: Mon Sep 7 21:01:24 2026 +0900 dma-mapping: don't trace the DMA address when the allocation fails [ Upstream commit 92c6a8d6470f7e7aa86c1f144818d8fa4fcbd5aa ] dma_alloc_attrs() passes *dma_handle to trace_dma_alloc() without checking whether the allocation succeeded. No backend writes it on failure: dma_direct_alloc(), iommu_dma_alloc() and the dma_map_ops instances assign it only on the path that returns a buffer. Callers usually pass an uninitialized automatic variable, so a failed allocation records whatever the stack held, next to the virt_addr=(null) that marks the record as an error: dma_alloc: dmatrace dir=BIDIRECTIONAL dma_addr=deadbeefdeadbeef size=1099511627776 virt_addr=0000000000000000 The device coherent pool path reaches the same call: a non-zero return from dma_alloc_from_dev_coherent() means the request was handled, not that it succeeded, so cpu_addr is NULL and dma_handle is untouched once the pool runs out. For an allocation event a NULL virt_addr already means the request failed, so the address field carries nothing. Report 0 for it in the event class rather than at each call site, which covers dma_alloc_pages() and dma_alloc_sgt_err() as well. Fixes: 038eb433dc14 ("dma-mapping: add tracing for dma-mapping API calls") Fixes: 68b6dbf1f441 ("dma-mapping: trace more error paths") Suggested-by: Marek Szyprowski Signed-off-by: Donggeun Yoo Link: https://lore.kernel.org/r/20260907120124.603373-1-donggeunyoo.kernel@gmail.com Reviewed-by: Sean Anderson Signed-off-by: Marek Szyprowski Signed-off-by: Sasha Levin commit d50277d6c193f73b207e1e8d8fec5e1562e23095 Author: Donggeun Yoo Date: Sat Sep 5 16:47:27 2026 +0900 dma-coherent: report a failed reserved memory assignment [ Upstream commit 504981db4f69bdd28054fb98c96a3a67f7248dde ] rmem_dma_device_init() drops the return value of dma_assign_coherent_memory() and always reports success. That call fails with -EBUSY when the device already has a coherent pool, and the file allows only "*one* such region of memory" per device. of_reserved_mem_device_init_by_idx() reads the zero as success. It logs "assigned reserved memory node" for a region that was not assigned and records the pairing, so of_reserved_mem_device_release() later runs rmem_dma_device_release() for it. That clears dev->dma_mem without looking at which region it was called for, dropping the pool the device did get and leaving it on ordinary memory. dma_declare_coherent_memory() checks the same call and releases the memory on failure, and rmem_swiotlb_device_init() propagates its own errors. Return the error here as well, so a device tree that assigns two pools to one device fails the probe instead of half working. Fixes: 7bfa5ab6fa1b ("drivers: dma-coherent: add initialization from device tree") Signed-off-by: Donggeun Yoo Link: https://lore.kernel.org/r/20260905074727.108029-1-donggeunyoo.kernel@gmail.com Signed-off-by: Marek Szyprowski Signed-off-by: Sasha Levin commit 5a6ecf5e2e524bfc66f93fca82c2a9107bd0c8ef Author: Orgad Shaneh Date: Tue Sep 1 19:33:55 2026 +0000 MIPS: Octeon: apply USB FDT fixups also when USB is modular [ Upstream commit 126f16e0a1b353c2ba5c7e2c8626cfa865934f9f ] The uctl/usbn device-tree fixups in octeon_prune_device_tree() - which set the board's USB reference-clock frequency and type from __cvmx_helper_board_usb_get_clock_type() - are guarded by "#ifdef CONFIG_USB", which is false when USB is built as a module. The fixups then silently disappear and octeon-hcd sees whatever default the DTS carries (12MHz crystal in octeon_3xxx.dts), leaving the PHY dead or the bus erroring on boards with a different reference clock. Use IS_ENABLED() so USB=m gets the same fixups as USB=y. Fixes: 7fd57ab9d9cf ("MIPS: Octeon: Fix compile error when USB is not enabled.") Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 1632b98df41763150da589cdce0a55fb752aa02c Author: Julian Braha Date: Sun Aug 16 00:51:09 2026 +0100 mips: econet: fix unmet dependencies for ECONET [ Upstream commit fb5a08026a68be0ec5f660588311fb1091bf5d58 ] ECONET selects EARLY_PRINTK_8250, SERIAL_OF_PLATFORM, and SERIAL_8250 without ensuring their dependencies, EARLY_PRINTK and TTY are met. This causes unmet dependencies: WARNING: unmet direct dependencies detected for SERIAL_8250 Depends on [n]: TTY [=n] && HAS_IOMEM [=y] && !S390 Selected by [y]: - ECONET [=y] WARNING: unmet direct dependencies detected for EARLY_PRINTK_8250 Depends on [n]: EARLY_PRINTK [=n] && USE_GENERIC_EARLY_PRINTK_8250 [=y] Selected by [y]: - ECONET [=y] WARNING: unmet direct dependencies detected for SERIAL_OF_PLATFORM Depends on [n]: TTY [=n] && HAS_IOMEM [=y] && SERIAL_8250 [=y] && OF [=y] Selected by [y]: - ECONET [=y] However, in the discussion of v1 of this patch, Arnd pointed out that these selects don't belong here in the first place. [1] Let's remove them to resolve the unmet dependencies. These unmet dependencies were found by kconfirm, a static analysis tool for Kconfig. Fixes: 79ee1d20e37c ("mips: econet: Fix incorrect Kconfig dependencies") Fixes: 35fb26f94dfa ("mips: Add EcoNet MIPS platform support") Suggested-by: Arnd Bergmann Signed-off-by: Julian Braha Tested-by: Caleb James DeLisle Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit d6dd59a158097f63e16eaa0114e5d2b85a1746a6 Author: Bard Liao Date: Tue Sep 1 11:10:19 2026 +0800 soundwire: cadence_master: wait and cancel cdns->work before clock stop [ Upstream commit aba7b41faeecb7692458095ce6fafc341fe0b80e ] A peripheral event could happen during the clock stop process. We need to wait for the event be handled before stopping the bus clock. Otherwise, we will get the IO transfer timed out issue. Fixes: af4cc917826f ("soundwire: cadence: mask Slave interrupt before stopping clock") Signed-off-by: Bard Liao Reviewed-by: David Lin Reviewed-by: Shuming Fan Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260901031019.233254-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 65893c8d28f239c7ddad5a83683be193a9133e9b Author: Johannes Berg Date: Fri Sep 4 16:55:02 2026 +0200 wifi: cfg80211: check IP header size in cfg80211_classify8021d() [ Upstream commit 48b2c5c628b09cf36cbeca53e0432fc2a7518be7 ] A frame that looks like IP can be transmitted, but be too short, so the DS field is read incorrectly: BUG: KMSAN: uninit-value in cfg80211_classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 cfg80211_classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 ieee80211_select_queue+0x37a/0x9e0 net/mac80211/wme.c:180 __ieee80211_subif_start_xmit+0x60f/0x1d90 net/mac80211/tx.c:4304 ieee80211_subif_start_xmit+0xa8/0x6d0 net/mac80211/tx.c:4538 ... packet_sendmsg+0x9173/0xa2a0 net/packet/af_packet.c:3108 Use skb_header_pointer() like the MPLS case. Assisted-by: LLM Fixes: e31a16d6f64e ("wireless: move some utility functions from mac80211 to cfg80211") Reported-by: syzbot+878ddc3962f792e9af59@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=878ddc3962f792e9af59 Link: https://patch.msgid.link/20260904165614.5e61a4c80b92.I37d68d3f406cb3b90b32e6943418d66070b65197@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7166da84a7fe3553f9065782fd80299a37b150e5 Author: Johannes Berg Date: Fri Sep 4 16:55:01 2026 +0200 wifi: cfg80211: don't get the radio mask for netdev-less wdevs [ Upstream commit a7783e585360ee05dfe21d3173dbbe985c94f29e ] cfg80211_calculate_bi_data() calls rdev_get_radio_mask() with wdev->netdev, which can be NULL and then crashes in mac80211. To avoid that, invert the order of checks since wdev->netdev is always valid for beaconing interfaces. Assisted-by: LLM Fixes: abb4cfe3661a ("wifi: cfg80211: extend interface combination check for multi-radio") Reported-by: syzbot+abff43d2d045e37c0bb2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=abff43d2d045e37c0bb2 Link: https://patch.msgid.link/20260904165614.2056a8b7dc91.I7412c5062d8166ad6c81ee7252cec49dea19a60f@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1ff3add37c329704ec46181b4ae4f00f9f16ce6f Author: Carolina Jubran Date: Wed Sep 2 17:06:32 2026 +0300 IB/IPoIB: Avoid restoring OPER_UP after multicast flush [ Upstream commit 9a141d3dc869d18b2eab35e999f4790a9b84e40f ] ipoib_ib_dev_flush_light() temporarily clears IPOIB_FLAG_OPER_UP to prevent multicast joins while ipoib_mcast_dev_flush() is running, and restores the flag afterwards if it was previously set. This restore races with ipoib_ib_dev_down(). If the interface is brought down while the flush is in progress, ipoib_ib_dev_down() clears IPOIB_FLAG_OPER_UP, but the flush path may set it again after the device has already gone down. Since commit 894021a75291 ("IB/ipoib: Make the carrier_on_task race aware"), ipoib_mcast_carrier_on_task() relies on IPOIB_FLAG_OPER_UP being cleared to terminate its rtnl_trylock() retry loop. If the flag is left set after shutdown, the workqueue retries forever, causing teardown to deadlock when ipoib_ndo_uninit() waits in destroy_workqueue() while holding RTNL. Instead of overloading IPOIB_FLAG_OPER_UP to block multicast joins during a light flush, introduce a dedicated IPOIB_FLAG_MCAST_FLUSH flag. Use it together with IPOIB_FLAG_OPER_UP to determine whether multicast joins are allowed, avoiding the race with device shutdown. Fixes: 344bacca8cd8 ("IB/ipoib: Don't allow MC joins during light MC flush") Reported-by: Ben Davies Signed-off-by: Carolina Jubran Reviewed-by: Cosmin Ratiu Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260902-avoid-rest-oper-up-v1-1-04fcd4916cae@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit af1b69be19c34e28c0ae54bee954b58cd076969a Author: Shmulik Cohen Date: Wed Aug 12 22:04:11 2026 +0300 wifi: libipw: reject too-short association responses [ Upstream commit adb7118b7d2cfd7e8213c17d7d2829f353017754 ] libipw_handle_assoc_resp() reads the capability, status and aid fields of the 30-byte association response prefix and then computes the information element length as stats->len - sizeof(*frame) stats->len is a u16 and sizeof() has type size_t, so the subtraction is evaluated as size_t and wraps instead of going negative. Truncating that to the u16 length parameter of libipw_parse_info_param() turns a frame shorter than the fixed fields into a length near 64 KiB, and the parser then reads past the receive buffer. Both the ipw2100 and ipw2200 management receive paths reach this function having established only that the frame carries the generic 24-byte three-address header. Reject the frame before any fixed field is touched. Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device. Fixes: 9e8571affd1c ("[PATCH] ieee80211: Add QoS (WME) support to the ieee80211 subsystem") Assisted-by: Claude:claude-opus-5 Signed-off-by: Shmulik Cohen Link: https://patch.msgid.link/20260812190412.18333-3-anuk909@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 19959fb60228f6dccc40d55507f8b1a751c2dc89 Author: Shmulik Cohen Date: Wed Aug 12 22:04:10 2026 +0300 wifi: libipw: reject too-short beacon and probe responses [ Upstream commit 5ce5721e8cbe3e80db8f43851cc2a2a92485ef4b ] libipw_process_probe_response() and the libipw_network_init() call it makes assume the frame contains the full 36-byte beacon and probe response prefix, but the ipw2100 and ipw2200 receive paths only establish that a management frame carries the generic 24-byte three-address header. libipw_network_init() then computes the information element length as stats->len - sizeof(*beacon) stats->len is a u16 and sizeof() has type size_t, so the subtraction is evaluated as size_t and wraps instead of going negative. Truncating that to the u16 length parameter of libipw_parse_info_param() yields 65524 for a 24-byte beacon, and the parser then walks the receive buffer as if it held almost 64 KiB of information elements, reading past the allocation. Reject the frame before any fixed field is touched. Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device. Fixes: b453872c35cf ("[NET] ieee80211 subsystem") Assisted-by: Claude:claude-opus-5 Signed-off-by: Shmulik Cohen Link: https://patch.msgid.link/20260812190412.18333-2-anuk909@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6fba6233e9ca7718661e53555a3961c58772c21a Author: Bogdan Nicolae Date: Fri Aug 7 11:34:18 2026 -0500 wifi: brcmfmac: cyw: pass PMKID to firmware if present [ Upstream commit e2de8d5eb2984416affdd9559e55f37c7f1bbf47 ] Zero out auth_status on initialization. Otherwise, garbage will leak from the stack to the firmware (when ssid is less than 32 bytes and/or when params->pmkid is set). Then, pass the params->pmkid to the firmware (without it, the firmware caches a garbage PMKID on successful authentication and denies a subsequent association request that includes the PMKID). Fixes: 66f909308a7c ("wifi: brcmfmac: cyw: support external SAE authentication in station mode") Signed-off-by: Bogdan Nicolae Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260807163418.487508-1-bogdan.nicolae@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 03d5e4776e8b71c2468c5c3c48b39202c87a8796 Author: Peng Hao Date: Fri Aug 28 19:15:31 2026 +0800 wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path [ Upstream commit a3d722190cdef18da4878b5efc27c3c386dda248 ] mwifiex_pcie_request_irq() registers each MSI-X vector with a per-index dev_id (&card->msix_ctx[i]). On a request_irq() failure the cleanup loop "for (j = 0; j < i; j++)" frees msix_entries[j].vector but passes the failed index's &card->msix_ctx[i] as the dev_id. free_irq() matches on (irq, dev_id), so it fails to find the action registered with &card->msix_ctx[j]: the already-requested IRQ j is not freed (leaked) and free_irq() warns about freeing a non-existent IRQ. Use &card->msix_ctx[j]. Fixes: 99074fc1e67b ("mwifiex: enable pcie MSIx interrupt mode support") Signed-off-by: Peng Hao Link: https://patch.msgid.link/20260828111531.56723-1-flyingpeng@tencent.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 46371442847a725cc0df3697fea2eba1dd54b82b Author: Mariano Baragiola Date: Sun Aug 9 09:49:47 2026 -0300 wifi: virt_wifi: free skb when disconnected [ Upstream commit f9edf7cf63b96d2b776fca8d258d3c5256e40c8e ] When the simulated link is disconnected, virt_wifi_start_xmit() returns NET_XMIT_DROP without freeing the skb. dev_hard_start_xmit() treats this return value as consumed, so every packet sent while disconnected leaks its skb. Free the skb before returning the drop status. Fixes: c7cdba31ed8b ("mac80211-next: rtnetlink wifi simulation device") Signed-off-by: Mariano Baragiola Link: https://patch.msgid.link/20260809124947.3590270-1-mbaragiola@linux.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9f04f9b14416e878a43e0f48877c9fc3f51a80d0 Author: Lachlan Hodges Date: Thu Aug 27 15:43:02 2026 +1000 wifi: mac80211: include TIM bitmap control for buffered S1G mcast traffic [ Upstream commit af72b5946d493cecced27d0951ea37c1d178601e ] Currently when building the S1G TIM element, we only build the bitmap control if we have buffered unicast traffic. Since AID 0 sits within the bitmap control if we have buffered multicast traffic with no buffered unicast traffic the bitmap control won't be emitted and dozing stations will be unaware of buffered multicast. To fix, only exclude the bitmap control byte when we don't have both buffered unicast and multicast traffic. Fixes: ee6360945483 ("wifi: mac80211: support block bitmap S1G TIM encoding") Signed-off-by: Lachlan Hodges Link: https://patch.msgid.link/20260827054302.254124-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit bea1739bf3e90347ef2ebfb91322a905fb919ff9 Author: Ruoyu Wang Date: Thu Aug 13 23:31:49 2026 +0800 dmaengine: sprd: Fix runtime PM reference leak in probe [ Upstream commit a7df136ec529ee49a789c5029bc37b98b0d4bedd ] pm_runtime_get_sync() increments a device's usage counter even when it fails. sprd_dma_probe() currently jumps directly to controller clock cleanup on that error, bypassing both pm_runtime_put_noidle() and pm_runtime_disable(). This can happen if the preceding unchecked pm_runtime_set_active() fails and the following runtime-resume attempt also returns an error. Enter the existing runtime-PM unwind path instead. This drops the reference without idling the partially initialized device, disables runtime PM, and then releases the controller clocks. The success path and propagated error code are unchanged. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 9b3b8171f7f4 ("dmaengine: sprd: Add Spreadtrum DMA driver") Signed-off-by: Ruoyu Wang Reviewed-by: Frank Li Reviewed-by: Baolin Wang Link: https://patch.msgid.link/20260813153149.3953497-1-ruoyuw560@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b82dfc06d32408d0d00d9c7c876f569d60d71238 Author: Troy Mitchell Date: Mon Jul 27 01:26:15 2026 -0700 dmaengine: mmp_pdma: fix wrong extended DRCMR base for SpacemiT K3 [ Upstream commit d1fc569fcbc7be6de06b034cf954a95e30ca1fb2 ] The extended DRCMR window on SpacemiT K3 starts at 0x1100. Commit 6587b8661a0b ("dmaengine: mmp_pdma: add SpacemiT K3 support") incorrectly set it to 0x1000, causing DRCMR accesses for request IDs >= 64 to target offsets 0x100 too low. The 0x1100 base has been verified on K3 silicon using real SPI and QSPI DMA transactions. The K3 DMA documentation [1] was updated on June 24, 2026, to reflect the corrected register addresses. Drop the bogus DRCMR_EXT_BASE_K3 macro and reuse DRCMR_EXT_BASE_DEFAULT for the K3 ops. Fixes: 6587b8661a0b ("dmaengine: mmp_pdma: add SpacemiT K3 support") Link: https://www.spacemit.com/community/document/info?nodepath=hardware/key_stone/k3/k3_docs/k3_usermanual/16_peripherals/dma.md&lang=en [1] Signed-off-by: Troy Mitchell Reviewed-by: Frank Li Link: https://patch.msgid.link/20260727-k3-pdma-fix-drcmr-base-v2-1-afba55cba1f3@linux.spacemit.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bf88ac4867050112a6c819c8d1a7209bf48ef427 Author: Quanye Yang Date: Sun Aug 30 15:09:55 2026 +0800 RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted [ Upstream commit 2ae16aaa78b5edc6e6d0904c84fd9cdfb762bcda ] The client borrows shared CQ credits in the ADDR_RESOLVED handler via ib_cq_pool_get(), before the peer is connected. create_cm() can return -ERESTARTSYS from wait_event_interruptible_timeout() without destroying the CM ID. The init_conns() and stop-and-destroy paths then call destroy_con_cq_qp() while cq is still NULL (no PUT) and only afterwards rdma_destroy_id(). CMA serializes the handler against rdma_destroy_id() with handler_mutex, but that does not order the GET against destroy_con_cq_qp(). If ADDR_RESOLVED has already passed the DESTROYING check, it can take con_mutex, GET credits, and then lose the con to kfree. Device unregister later hits WARN_ON(cq->cqe_used) in ib_cq_pool_cleanup(). Set a per-connection flag under con_mutex before CQ/QP teardown so a racing ADDR_RESOLVED cannot borrow credits after teardown has begun. Reported-by: syzbot+d396918a29afb8543e1c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d396918a29afb8543e1c Fixes: 3b89e92c2a95 ("RDMA/rtrs: Use new shared CQ mechanism") Signed-off-by: Quanye Yang Link: https://patch.msgid.link/20260830-rdma-rtrs-clt-cq-pool-leak-v1-1-b169434fd3df@proton.me Reviewed-by: Jack Wang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6ff94b263d176a6f938a6e35353a3c44e9c21772 Author: Jacob Moroni Date: Tue Sep 1 16:00:14 2026 +0000 RDMA/irdma: Enforce local fence for IB_WR_REG_MR [ Upstream commit 3fb905f07ea45b31c8f67ba6e4668de46f527e65 ] Enforce local fence for IB_WR_REG_MR to avoid spurious FASTREG_VALID_MKEY async events during heavy invalidation and registration activity. Commit 69e8e429bca2 ("RDMA/irdma: Enforce local fence for LOCAL_INV WRs") was very similar, but was not sufficient to prevent all occurrences of these async events. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260901160014.2026285-1-jmoroni@google.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 74d4085221a7ec5440996af199ccadfa75b9eb0e Author: Cheng Xu Date: Fri Aug 28 11:03:44 2026 +0800 RDMA/erdma: Use IRQ-safe XArray helpers for QP and CQ tables [ Upstream commit 00baeade709fb66da647e8327e8398bb532e30f7 ] Locked QP and CQ lookups from EQ interrupts can deadlock with create-path XArray updates. If an interrupt arrives while the create path holds the plain xa_lock, the lookup spins forever trying to acquire the same lock. Use IRQ-safe XArray helpers for all QP and CQ create-path updates, including the GSI QP store and error paths. Initialize both arrays with XA_FLAGS_LOCK_IRQ so sleeping allocations preserve interrupt state. Fixes: 98df2aee1459 ("RDMA/erdma: Hold CQ references when processing EQ events") Fixes: a52eeff32024 ("RDMA/erdma: Hold QP references for AE and CM processing") Signed-off-by: Cheng Xu Link: https://patch.msgid.link/20260828030344.88021-1-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c0d8df85db146d6275e226cb950023be69dd6c77 Author: Li RongQing Date: Wed Aug 26 15:32:16 2026 +0800 RDMA/mad: Fix receive buffer leak when PKey enforcement fails [ Upstream commit 3476c28c9addfa253f505e6bd87f1f5598b961d0 ] ib_mad_complete_recv() initializes mad_recv_wc->rmpp_list and then runs ib_mad_enforce_security() before linking recv_buf onto that list. On failure it calls ib_free_recv_mad(), which only walks rmpp_list and frees the ib_mad_private of every buffer found there. As the list is still empty at that point, nothing is freed at all. The caller cannot clean up either: ib_mad_recv_done() sets recv to NULL right after ib_mad_complete_recv() returns, assuming the MAD layer took ownership of the buffer. Every MAD that fails the PKey check therefore leaks one ib_mad_private (about 300 bytes per IB port MAD, ~2K for OPA), and a remote node can trigger this repeatedly by sending MADs with a wrong PKey. Link recv_buf onto rmpp_list right after the list is initialized, so the error path has something to free. Fixes: 47a2b338fe63 ("IB/core: Enforce security on management datagrams") Signed-off-by: Li RongQing Link: https://patch.msgid.link/20260826073216.2367-1-lirongqing@baidu.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9149e05699f7c7dfe6b83fe2140814ea21d52633 Author: Li RongQing Date: Wed Aug 26 15:31:46 2026 +0800 RDMA/uverbs: Fix potential leak of resources->collection in flow_resources_alloc() [ Upstream commit 08d4d9802d58bf032099091e6acf719f3298f28e ] The two array allocations are done unconditionally and only checked afterwards, so if the counters allocation fails while the collection allocation succeeds, the error path frees counters and the containing struct but never frees resources->collection, losing the only pointer to it. Fixes: de7498147d00 ("RDMA/uverbs: Refactor flow_resources_alloc() function") Signed-off-by: Li RongQing Link: https://patch.msgid.link/20260826073146.2203-1-lirongqing@baidu.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit dab479a77b6552525d34f4441a191001a3af1ac9 Author: Sriharsha Basavapatna Date: Mon Aug 24 22:54:43 2026 +0530 RDMA/bnxt_re: Avoid exposing umdbr to userspace [ Upstream commit 23d7e03a52ece66b992620aa9b8fa5f164077c0f ] The umdbr field in struct bnxt_re_db_region returns the raw unmapped PCI BAR address of the doorbell region. Avoid sharing this field to the userspace. Change this to a reserved field and stop populating it, keeping the ABI layout and size unchanged for existing binaries. Fixes: 1234a9d8aebb ("RDMA/bnxt_re: Support doorbell extensions") Signed-off-by: Sriharsha Basavapatna Link: https://patch.msgid.link/20260824172443.33943-1-sriharsha.basavapatna@broadcom.com Reviewed-by: Selvin Xavier Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f79cf42ff23f9120246cd6740eaa26f59c632a4a Author: Ryan Mehri Date: Sat Aug 22 23:33:43 2026 -0400 RDMA/rtrs: guard against null kobj name [ Upstream commit 99c24a8968ebef0573825b5cb89d5985d51635b9 ] In the client, if `init_path()` errors, the callee tries to clean up with `rtrs_clt_close_conns()`. However, this can lead to calling the event tracing code with `clt_path->kobj->name` being `NULL` and thus causing a null pointer dereference when trying to copy from it. This just adds a guard to check that the name is not `NULL` before copying from it. The server appears to have a similar pattern. Fixes: 5a93929d9f9a1 ("RDMA/rtrs-clt: Add event tracing support") Fixes: c16762b7bf54d ("RDMA/rtrs-srv: Add event tracing support") Reported-by: syzbot+1695193198994f4e7fed@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1695193198994f4e7fed Signed-off-by: Ryan Mehri Link: https://patch.msgid.link/20260823034303.163403-1-ryan.mehri1@gmail.com Reviewed-by: Jack Wang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 727bbda37d9758960c346546004eea4ad49242e1 Author: Linkai Gong Date: Fri Aug 21 17:09:08 2026 +0800 RDMA/bnxt_re: check create_singlethread_workqueue() in DCB setup [ Upstream commit 6c368f7baaea63c1c7c28c6df271511f2a1562c9 ] bnxt_re_init_dcb_wq() ignores a failed allocation. The async DCB handler later calls queue_work() on the NULL pointer. Fixes: 51dc5312dcd9 ("RDMA/bnxt_re: Add support to handle DCB_CONFIG_CHANGE event") Signed-off-by: Linkai Gong Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 7908fbc597a694bbd99bfb59ece73bc3daded68e Author: Yehyeong Lee Date: Fri Aug 21 17:06:20 2026 +0900 IB/isert: wait for deferred control PDU completions before releasing the connection [ Upstream commit a8fe3dfce8c0d8a76dc3d8486a5bff5feebe156f ] isert_send_done() hands ISTATE_SEND_TASKMGTRSP, ISTATE_SEND_REJECT and ISTATE_SEND_TEXTRSP completions off to isert_comp_wq and returns. The work item then runs isert_completion_put() -> isert_put_cmd(), which reads isert_conn->conn and takes conn->cmd_lock. Nothing orders that work item against teardown. isert_wait_conn() queues isert_release_work, which frees isert_conn, and iscsit_close_connection() frees the iscsit_conn right after it returns, so the queued work can run against freed memory. Count the deferred control PDU completions per connection and let isert_wait_conn() wait for them before the release work is queued. ISTATE_SEND_LOGOUTRSP is deliberately not counted: that branch runs iscsit_logout_post_handler(), which ends up waiting for conn->conn_wait_comp, and that completion is only sent by iscsit_close_connection() after it has called iscsit_wait_conn(). Waiting for it here would deadlock. Its wait stays the existing isert_wait4logout(). The splat below is from a kernel with tracing printk()s and an msleep(200) injected into isert_do_control_comp() to widen the window: BUG: KASAN: slab-use-after-free in isert_put_cmd+0x53d/0x620 Read of size 8 at addr ffff8881054f1038 by task kworker/u17:1/182 CPU: 0 UID: 0 PID: 182 Comm: kworker/u17:1 Tainted: G B 7.2.0-rc5-TWIDE-gb8babf08acc7 #1 PREEMPT(lazy) Tainted: [B]=BAD_PAGE Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: isert_comp_wq isert_do_control_comp Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x3e/0x70 ? isert_put_cmd+0x53d/0x620 kasan_report+0xce/0x100 ? isert_put_cmd+0x53d/0x620 isert_put_cmd+0x53d/0x620 ? isert_completion_put+0x305/0x330 ? isert_do_control_comp+0x2ef/0x310 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 48: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x158/0x370 isert_cma_handler+0x1e3/0x2ae0 cma_cm_event_handler+0x3e/0x240 cma_ib_req_handler+0x17d9/0x4490 cm_process_work+0x41/0x330 cm_work_handler+0x5727/0xc160 process_one_work+0x633/0x1030 worker_thread+0x45b/0xd10 kthread+0x2c6/0x3b0 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 Freed by task 184: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x121/0x380 iscsit_close_connection+0x7cf/0x1e60 iscsit_take_action_for_connection_exit+0x1b6/0x360 iscsi_target_tx_thread+0x472/0x690 kthread+0x2c6/0x3b0 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260821080620.1694119-1-yhlee@isslab.korea.ac.kr Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ceecf3f9c322fc6937a66682942a26ad13a34a07 Author: Yehyeong Lee Date: Wed Aug 19 10:08:04 2026 +0900 IB/iser: reject a remote invalidation of an unregistered direction [ Upstream commit d85f0f0a7c85756fc992c70d869706f19dac9259 ] A write command whose data is sent entirely as immediate data is not registered. iser_reg_mem_fastreg() takes the DMA key path and leaves rdma_reg[ISER_DIR_OUT].desc at NULL, while iser_dma_map_task_data() has already set dir[ISER_DIR_OUT]. iser_check_remote_inv() looks at dir[] alone and hands the descriptor to iser_inv_desc(), which reads desc->sig_protected. A target that answers such a command with IB_WR_SEND_WITH_INV faults the initiator. Leaving those commands unregistered is deliberate. The same function already terminates the connection when a target sends a remote invalidation the initiator did not ask for. A target that invalidates a direction that was never registered is in the same class, so give it the same answer. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 0 UID: 0 PID: 40 Comm: kworker/u8:2 Not tainted 7.2.0-rc5-ISERHOST-gf5098b6bae76-dirty #3 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: rxe_wq do_work RIP: 0010:iser_task_rsp+0x6d6/0xec0 Code: 48 c1 ea 03 80 3c 02 00 0f 85 ba 06 00 00 48 8b 9b 78 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 20 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 76 06 00 00 80 7b 20 00 0f 84 3d 04 RSP: 0018:ffff88811b008db8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000001848 RDX: 0000000000000004 RSI: 1ffff11021587b12 RDI: 0000000000000020 RBP: ffff88810adc1ae4 R08: ffff888109b7f860 R09: ffffffff90a922c0 R10: ffff88810adc1a1c R11: 000000000000003c R12: ffff888109b7f800 R13: ffff88810adc1acc R14: ffff888109b7f820 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88818a676000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005afe2b CR3: 000000010af23005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: __ib_process_cq+0xe1/0x390 ib_poll_handler+0x6e/0x200 irq_poll_softirq+0x1df/0x480 ? clockevents_program_event+0x2ba/0x860 ? __pfx_irq_poll_softirq+0x10/0x10 handle_softirqs+0x18e/0x590 ? __pfx_handle_softirqs+0x10/0x10 ? __hrtimer_rearm_deferred+0x156/0x450 do_softirq+0x3b/0x60 __local_bh_enable_ip+0x61/0x70 __alloc_skb+0x732/0x890 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx___alloc_skb+0x10/0x10 ? _raw_read_unlock_irqrestore+0x16/0x50 rxe_init_packet+0x16b/0x4f0 prepare_ack_packet+0xb8/0x830 rxe_receiver+0x499/0x9980 ? __pfx_rxe_receiver+0x10/0x10 ? rxe_completer+0x29e5/0x38c0 ? hrtimer_start_range_ns_common+0x75f/0x1730 ? hrtimer_start_range_ns+0xa6/0x2c0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_rxe_receiver+0x10/0x10 do_work+0x144/0x470 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Fixes: 59caaed7a72a ("IB/iser: Support the remote invalidation exception") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260819010804.641772-1-yhlee@isslab.korea.ac.kr Reviewed-by: Max Gurtovoy Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 92711389ceed5628b0af5015c8c2bfc6ef15befa Author: Ovidiu Panait Date: Wed Jul 22 08:53:53 2026 +0000 arm64: dts: renesas: r9a09g087: Switch GBETH TX queue scheduling to WRR [ Upstream commit 2ac7bad110be6ebe478d6bd57821f7f5259a1f54 ] The GBETH ethernet nodes don't specify a TX scheduling policy, so stmmac falls back to Strict Priority. In this configuration the queue with the highest priority gets all the traffic, starving the others under load. Under sustained UDP TX load with multiple data streams, this starvation triggers spurious adapter resets due to TX queue timeouts: iperf3 -c -i0 -t60 --bind-dev end0 -u -b0 -P4 end0: NETDEV WATCHDOG: CPU: 1: transmit queue 1 timed out 5228 ms end0: Reset adapter. Investigation shows that only the highest priority queue is advancing while the others stall for more than 5 seconds, causing a netdev watchdog reset. Switch the TX scheduling policy to Weighted-Round-Robin (WRR) so that traffic is processed across all queues, eliminating the stalls. Fixes: c4698a34993b ("arm64: dts: renesas: r9a09g087: Add GMAC nodes") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260722085353.136986-6-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 853306d948125e72fccf540416d986bff91e5713 Author: Ovidiu Panait Date: Wed Jul 22 08:53:52 2026 +0000 arm64: dts: renesas: r9a09g077: Switch GBETH TX queue scheduling to WRR [ Upstream commit f9d9a1913c09366bf7b967d39575e06cb80128dc ] The GBETH ethernet nodes don't specify a TX scheduling policy, so stmmac falls back to Strict Priority. In this configuration the queue with the highest priority gets all the traffic, starving the others under load. Under sustained UDP TX load with multiple data streams, this starvation triggers spurious adapter resets due to TX queue timeouts: iperf3 -c -i0 -t60 --bind-dev end0 -u -b0 -P4 end0: NETDEV WATCHDOG: CPU: 1: transmit queue 1 timed out 5228 ms end0: Reset adapter. Investigation shows that only the highest priority queue is advancing while the others stall for more than 5 seconds, causing a netdev watchdog reset. Switch the TX scheduling policy to Weighted-Round-Robin (WRR) so that traffic is processed across all queues, eliminating the stalls. Fixes: 394c1e24a4cf ("arm64: dts: renesas: r9a09g077: Add GMAC nodes") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260722085353.136986-5-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 287437678a70889f75e872180b91578d1898f8b5 Author: Ovidiu Panait Date: Wed Jul 22 08:53:51 2026 +0000 arm64: dts: renesas: r9a09g047: Switch GBETH TX queue scheduling to WRR [ Upstream commit 63016c3a91f2c458ca75869c8c782e899591f22d ] The GBETH ethernet nodes don't specify a TX scheduling policy, so stmmac falls back to Strict Priority. In this configuration the queue with the highest priority gets all the traffic, starving the others under load. Under sustained UDP TX load with multiple data streams, this starvation triggers spurious adapter resets due to TX queue timeouts: iperf3 -c -i0 -t60 --bind-dev end0 -u -b0 -P4 end0: NETDEV WATCHDOG: CPU: 1: transmit queue 1 timed out 5228 ms end0: Reset adapter. Investigation shows that only the highest priority queue is advancing while the others stall for more than 5 seconds, causing a netdev watchdog reset. Switch the TX scheduling policy to Weighted-Round-Robin (WRR) so that traffic is processed across all queues, eliminating the stalls. Fixes: 41ffbb1c42d3 ("arm64: dts: renesas: r9a09g047: Add GBETH nodes") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260722085353.136986-4-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit f2042a2bb43b0c62253f9677e880c52d504a131a Author: Ovidiu Panait Date: Wed Jul 22 08:53:50 2026 +0000 arm64: dts: renesas: r9a09g056: Switch GBETH TX queue scheduling to WRR [ Upstream commit 66fcbdbeca0118b8aeac218b33fa18c394513543 ] The GBETH ethernet nodes don't specify a TX scheduling policy, so stmmac falls back to Strict Priority. In this configuration the queue with the highest priority gets all the traffic, starving the others under load. Under sustained UDP TX load with multiple data streams, this starvation triggers spurious adapter resets due to TX queue timeouts: iperf3 -c -i0 -t60 --bind-dev end0 -u -b0 -P4 end0: NETDEV WATCHDOG: CPU: 1: transmit queue 1 timed out 5228 ms end0: Reset adapter. Investigation shows that only the highest priority queue is advancing while the others stall for more than 5 seconds, causing a netdev watchdog reset. Switch the TX scheduling policy to Weighted-Round-Robin (WRR) so that traffic is processed across all queues, eliminating the stalls. Fixes: c8c8a57c5b40 ("arm64: dts: renesas: r9a09g056: Add GBETH nodes") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260722085353.136986-3-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit c674261743eea29b264b8802cbda156c36fd392d Author: Ovidiu Panait Date: Wed Jul 22 08:53:49 2026 +0000 arm64: dts: renesas: r9a09g057: Switch GBETH TX queue scheduling to WRR [ Upstream commit 33da68f61d25ef8411489d06514ff627c1f88152 ] The GBETH ethernet nodes don't specify a TX scheduling policy, so stmmac falls back to Strict Priority. In this configuration the queue with the highest priority gets all the traffic, starving the others under load. Under sustained UDP TX load with multiple data streams, this starvation triggers spurious adapter resets due to TX queue timeouts: iperf3 -c -i0 -t60 --bind-dev end0 -u -b0 -P4 end0: NETDEV WATCHDOG: CPU: 1: transmit queue 1 timed out 5228 ms end0: Reset adapter. Investigation shows that only the highest priority queue is advancing while the others stall for more than 5 seconds, causing a netdev watchdog reset. Switch the TX scheduling policy to Weighted-Round-Robin (WRR) so that traffic is processed across all queues, eliminating the stalls. Fixes: 050ee38d0002 ("arm64: dts: renesas: r9a09g057: Add GBETH nodes") Signed-off-by: Ovidiu Panait Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260722085353.136986-2-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 173a9164d901f188a10386345c99e63e4c7f6428 Author: Biju Das Date: Wed Aug 26 13:27:24 2026 +0100 power: sequencing: Fix build issue with COMPILE_TEST [ Upstream commit 3b54dbd119805361695cb50ca6a875f4c7518b74 ] The POWER_SEQUENCING_TH1520_GPU driver depends on (ARCH_THEAD && AUXILIARY_BUS) || COMPILE_TEST. This means when COMPILE_TEST=y and ARCH_THEAD is not set, the driver can still be built even though it requires AUXILIARY_BUS, which may not be selected in that configuration, leading to a build failure. Fix this by dropping AUXILIARY_BUS from the dependency and instead selecting it directly, so the dependency is satisfied regardless of whether COMPILE_TEST or ARCH_THEAD is enabled. Fixes: 1a7312b93ab0 ("power: sequencing: extend build coverage with COMPILE_TEST=y") Signed-off-by: Biju Das Link: https://patch.msgid.link/20260826122742.153643-3-biju.das.jz@bp.renesas.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 426f54f20b79c5b164a0472ad3f6ba36afcd08c6 Author: Or Har-Toov Date: Tue Aug 11 19:19:16 2026 +0300 RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency [ Upstream commit a44a3f175eaee7e5aeb6a8fed381c4a0d5f49236 ] Commit 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages") introduced disassociation_lock to protect new mmap registrations against uverbs_user_mmap_disassociate(), but created an ABBA deadlock: Thread A (mmap / fork): mmap_lock -> disassociation_lock Thread B (disassociate): disassociation_lock -> mmap_lock Fix by removing disassociation_lock entirely and using the pre-existing hw_destroy_rwsem instead. hw_destroy_rwsem already provides the same protection: rdma_umap_open() and ib_uverbs_mmap() both use down_read_trylock() before registering a new VMA, so holding hw_destroy_rwsem in uverbs_user_mmap_disassociate() is sufficient to block new registrations. trylock is used in both mmap paths (not blocking down_read) because mmap_lock is already held on entry, and uverbs_user_mmap_disassociate() acquires mmap_lock internally — a blocking read would recreate the same deadlock. The only caller that was not taking hw_destroy_rwsem for write was rdma_user_mmap_disassociate(). Fix it to take the rwsem per-ufile while iterating under lists_mutex. This is safe because ib_uverbs_close() releases hw_destroy_rwsem entirely before acquiring lists_mutex, so the two locks are never held simultaneously. lockdep warning: [ 776.654252] ====================================================== [ 776.655214] WARNING: possible circular locking dependency detected [ 776.656167] 6.18.0for-upstream_debug_94e244d9ccab #1 Not tainted [ 776.657114] ------------------------------------------------------ [ 776.658087] devlink/14824 is trying to acquire lock: [ 776.658879] ffff88811170c800 (&mm->mmap_lock){++++}-{4:4}, at: uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs] [ 776.660479] [ 776.660479] but task is already holding lock: [ 776.661460] ffff888142d92b08 (&file->disassociation_lock){+.+.}-{4:4}, at: uverbs_user_mmap_disassociate+0x39/0x780 [ib_uverbs] [ 776.663177] [ 776.663177] which lock already depends on the new lock. [ 776.663177] [ 776.664525] [ 776.664525] the existing dependency chain (in reverse order) is: [ 776.665724] [ 776.665724] -> #2 (&file->disassociation_lock){+.+.}-{4:4}: [ 776.666887] __mutex_lock+0x16d/0x2330 [ 776.667633] rdma_umap_open+0x129/0x280 [ib_uverbs] [ 776.668489] dup_mmap+0xa40/0x1790 [ 776.669170] copy_process+0x5dd2/0x6170 [ 776.669933] kernel_clone+0xb6/0x610 [ 776.670636] __do_sys_clone+0xb5/0xf0 [ 776.671354] do_syscall_64+0x70/0x12e0 [ 776.672083] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.672940] [ 776.672940] -> #1 (&mm->mmap_lock/1){+.+.}-{4:4}: [ 776.673985] down_write_nested+0x90/0x1e0 [ 776.674751] dup_mmap+0x201/0x1790 [ 776.675448] copy_process+0x5dd2/0x6170 [ 776.676180] kernel_clone+0xb6/0x610 [ 776.676904] __do_sys_clone+0xb5/0xf0 [ 776.677615] do_syscall_64+0x70/0x12e0 [ 776.678351] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.679239] [ 776.679239] -> #0 (&mm->mmap_lock){++++}-{4:4}: [ 776.680253] __lock_acquire+0x18c6/0x2ec0 [ 776.681018] lock_acquire+0x10e/0x2e0 [ 776.681742] down_read+0x95/0x430 [ 776.682395] uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs] [ 776.683436] uverbs_destroy_ufile_hw+0x1ae/0x270 [ib_uverbs] [ 776.684416] ib_uverbs_remove_one+0x22b/0x420 [ib_uverbs] [ 776.685371] remove_client_context+0xa6/0xf0 [ib_core] [ 776.686342] disable_device+0x12b/0x240 [ib_core] [ 776.687249] __ib_unregister_device+0x269/0x460 [ib_core] [ 776.688233] ib_unregister_device+0x21/0x30 [ib_core] [ 776.689140] mlx5r_remove+0xd0/0x170 [mlx5_ib] [ 776.689999] device_release_driver_internal+0x3b2/0x560 [ 776.694876] bus_remove_device+0x1f5/0x3e0 [ 776.695638] device_del+0x3b9/0x990 [ 776.696329] mlx5_detach_device+0x17e/0x350 [mlx5_core] [ 776.697429] mlx5_unload_one_devl_locked+0x3f/0xb0 [mlx5_core] [ 776.698578] mlx5_devlink_reload_down+0x1f9/0x550 [mlx5_core] [ 776.699712] devlink_reload+0x13e/0x680 [ 776.700456] devlink_nl_reload_doit+0xc29/0x1160 [ 776.701293] genl_family_rcv_msg_doit+0x1c9/0x2a0 [ 776.702135] genl_rcv_msg+0x3f0/0x6b0 [ 776.702854] netlink_rcv_skb+0x11d/0x370 [ 776.703605] genl_rcv+0x24/0x40 [ 776.704236] netlink_unicast+0x5b4/0x970 [ 776.704984] netlink_sendmsg+0x730/0xbf0 [ 776.705748] __sock_sendmsg+0xc5/0x190 [ 776.706461] __sys_sendto+0x201/0x2f0 [ 776.707188] __x64_sys_sendto+0xdc/0x1b0 [ 776.707931] do_syscall_64+0x70/0x12e0 [ 776.708643] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.709546] [ 776.709546] other info that might help us debug this: [ 776.709546] [ 776.710910] Chain exists of: [ 776.710910] &mm->mmap_lock --> &mm->mmap_lock/1 --> &file->disassociation_lock [ 776.710910] [ 776.712805] Possible unsafe locking scenario: [ 776.712805] [ 776.713828] CPU0 CPU1 [ 776.714589] ---- ---- [ 776.715347] lock(&file->disassociation_lock); [ 776.716097] lock(&mm->mmap_lock/1); [ 776.717067] lock(&file->disassociation_lock); [ 776.718199] rlock(&mm->mmap_lock); [ 776.718857] [ 776.718857] *** DEADLOCK *** Fixes: 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages") Signed-off-by: Or Har-Toov Signed-off-by: Leon Romanovsky Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260811-fix-mmap-lockdep-v1-1-1151b41063b4@nvidia.com Acked-by: Junxian Huang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5bd42f74ec3b4f4687fb600f367af0828d513b3c Author: Krystian Kaniewski Date: Wed Aug 12 10:16:41 2026 +0200 RDMA/core: Reject unregistering netdevs in ib_get_eth_speed [ Upstream commit ef9fbe1b93f3b617b96e86d5cd76b3fa44514cb5 ] ib_device_get_netdev() intentionally returns a referenced net_device even when it is unregistering, so matching and cleanup callers can still find the association. The reference keeps struct net_device allocated, but does not guarantee that the device remains operational. ib_get_eth_speed() uses the returned device operationally by invoking its ethtool callback. Although that call is made under RTNL, the function does not verify the registration state first. An asynchronous RDMA port query can therefore call into a netdev after NETDEV_UNREGISTER and ndo_uninit have completed. Check for NETREG_REGISTERED while holding RTNL and return -ENODEV for a device which is being unregistered. Keeping RTNL across the check and the ethtool operation prevents unregister from starting between them. Keep the speed fallback and warning under RTNL as well, so the warning can safely read netdev->name. Drop the netdev reference before releasing RTNL once all accesses to the device are complete. Fixes: d41861942fc5 ("IB/core: Add generic function to extract IB speed from netdev") Reported-by: syzbot+5fe14f2ff4ccbace9a26@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5fe14f2ff4ccbace9a26 Signed-off-by: Krystian Kaniewski Link: https://patch.msgid.link/20260812081708.32468-1-krystianmkaniewski@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f121721dc631a13f7f2961bc5f061e8f3a7d14f1 Author: Or Har-Toov Date: Tue Aug 11 19:25:57 2026 +0300 RDMA/mlx5: Remove warn on missing representor in query_port_speed [ Upstream commit 2be77295316c2dff0a33c0dc3a65abdab4ccf796 ] The representor ib_device's phys_port_cnt is set to the total vport count when the uplink vport rep loads. Individual port[i].rep entries are populated only as each VF/SF vport rep registers. A NULL .rep for a given port index is therefore expected while VF reps are still loading or haven't been enabled yet. Tools like ibstat and ibv_devinfo iterate over all ports of all RDMA devices. Some ports may not have an eswitch representor, causing repeated dmesg warnings when these tools run without a device argument. This causes dmesg to be flooded with this message on every ibstat invocation. Remove the warning and return -ENODEV when no representor exists for the queried port. Fixes: aaecff5e13cd ("RDMA/mlx5: Implement query_port_speed callback") Signed-off-by: Or Har-Toov Reviewed-by: Shay Drory Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20260811-remove-warn-on-miss-rep-v1-1-eccf399bc6af@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d4fc4e37f8a143b0fe83b42c8fb48cf542154fee Author: Michael Bommarito Date: Tue Jun 16 22:27:28 2026 -0400 RDMA/rxe: insert mcg into mcg_tree only after rxe_mcast_add() succeeds [ Upstream commit 1caceeb2d74bbe88223aea55eb8626b4c5f076fd ] rxe_get_mcg() publishes a newly allocated multicast group in rxe->mcg_tree before programming the backing Ethernet multicast address with rxe_mcast_add(), which runs outside mcg_lock. A local userspace RDMA client reaches this path with ATTACH_MCAST on a UD QP; if rxe_mcast_add() then returns an error (for example -ENODEV when the backing netdev has been removed, or a propagated dev_mc_add() error), the unwind frees the published group without removing it from the tree. A later lookup of the same MGID dereferences the freed struct rxe_mcg from __rxe_lookup_mcg(). Fix this by keeping the new mcg private until rxe_mcast_add() succeeds. Split the tree publication into __rxe_publish_mcg(), call rxe_mcast_add() before taking the tree reference, and free the still-private mcg on failure. Because the group is never visible in mcg_tree until the multicast address is programmed, no concurrent caller can look it up or attach a QP to a group that is about to be torn down, so the error path needs no conditional unwind. If another caller publishes the same MGID while the address is being programmed, the post-add re-check under mcg_lock finds the winner; this caller then drops its private object and balances its own rxe_mcast_add() with rxe_mcast_del() before returning the winner. Reproduced by forcing the rxe_mcast_add() error return under KASAN: without the change the next attach to the same MGID reports a slab-use-after-free in __rxe_lookup_mcg(); with it the forced failure returns cleanly. A no-injection attach/detach regression, including a two-QP shared join/leave and re-attach, stays KASAN- and leak-clean. Fixes: a926a903b7dc ("RDMA/rxe: Do not call dev_mc_add/del() under a spinlock") Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260617022728.2770116-1-michael.bommarito@gmail.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 2d6c6f94d3e1cde049fe5db71dbd5549f10b2de1 Author: Weiming Shi Date: Sun Jul 26 19:15:30 2026 +0800 RDMA/rxe: Restore HMM_PFN_WRITE check in ODP write paths [ Upstream commit 769001ce838d907ecaa95f1d0a4e8fc86f761f9f ] Commit 0b261d7c1cd3 ("RDMA/rxe: Break endless pagefault loop for RO pages") dropped the access permission test from rxe_check_pagefault() and left only HMM_PFN_VALID. A page faulted in read-only, for example a page-cache folio behind a PROT_READ file mapping, then satisfies the check and ODP write operations (RDMA WRITE, RDMA READ response, SEND payload, atomics) modify it through kmap without ever breaking CoW. An unprivileged user can register an ODP MR over such a mapping and have incoming RDMA traffic overwrite the page cache of a file it only holds O_RDONLY, including /etc/passwd or setuid binaries. This is the same primitive class as Dirty COW and CVE-2022-2590. mlx5 has the missing invariant: its ODP path sets the device write bit only for pfns that carry HMM_PFN_WRITE. Restore it in rxe by requiring HMM_PFN_WRITE in rxe_check_pagefault() for every operation except RXE_PAGEFAULT_RDONLY. A write to a non-writable VMA now fails the one fault attempt with -EPERM from hmm_vma_fault() instead of re-faulting forever. For a writable VMA the fault breaks CoW and the write lands in the private page. Keep pmem flushes on the read-only check. arch_wb_cache_pmem() never modifies memory, and the FLUSH access bits do not make the umem writable, so classifying flushes as writes would make every flush against a flush-only MR fail. Fixes: 0b261d7c1cd3 ("RDMA/rxe: Break endless pagefault loop for RO pages") Signed-off-by: Weiming Shi Link: https://patch.msgid.link/20260726111533.1037819-1-bestswngs@gmail.com Reviewed-by: Zhu Yanjun Tested-by: Hongqiang Luo Tested-by: Xinyu Ma Tested-by: Zhanbo Ye Reported-by: Weiming Shi Reported-by: Shaomin Chen Reported-by: Rui Ding Reported-by: Miao Zhao Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 3988cd49adc312343654d536b2353b200ae35dfc Author: Xixin Liu Date: Tue Jul 28 08:50:00 2026 +0800 clk: scpi: register scpi-cpufreq once and clear on failure [ Upstream commit ab06cf8152dace327cd873188e4a036c4e0b5944 ] scpi_clocks_probe() walks clock children and, for each DVFS provider, calls platform_device_register_simple("scpi-cpufreq", -1, ...). Two related bugs: Since all DVFS providers register the fixed scpi-cpufreq device using PLATFORM_DEVID_NONE, a second registration fails with -EEXIST and overwrites the pointer to the successfully registered device. The first device can then no longer be unregistered. Register the virtual device only once. If registration fails, reset the pointer to NULL so a subsequent DVFS provider can retry and the global pointer only represents a successfully registered device. Fixes: 9490f01e2471 ("clk: scpi: add support for cpufreq virtual device") Fixes: 67bcc2c5f1da ("clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled") Signed-off-by: Xixin Liu Link: https://patch.msgid.link/fd1b9199a9c3.v2.1785200642.git.liuxixin@kylinos.cn (sudeep.holla: reworded the commit message to improve readability) Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 108c46e8dacc4a0e472a74f98171115d49cbc079 Author: Xixin Liu Date: Tue Jul 28 08:50:00 2026 +0800 clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate [ Upstream commit 70f4b78d560e592cbf3325b162424737d032fc1d ] dvfs_get_idx() may return an out-of-range index if the SCP firmware is buggy or returns a stale value. Only negative indexes were rejected, so a large index walked past info->opps and could treat garbage as a clock rate (KASAN OOB / wrong frequency to consumers). The missing upper bound dates back to the original SCPI clock driver. Treat indexes >= opp count as invalid and return 0, same as idx < 0. Fixes: cd52c2a4b5c4 ("clk: add support for clocks provided by SCP(System Control Processor)") Signed-off-by: Xixin Liu Link: https://patch.msgid.link/04f9ab766e07.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit cc563a59aded6f3b02d75dcc3c0bc5e90755d99e Author: Xixin Liu Date: Tue Jul 28 08:50:00 2026 +0800 firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS [ Upstream commit 32471d84a487c7fd74532bc96be56f8028cf4a3f ] scpi_dvfs_get_info() already rejected a zero opp_count, but still trusted any larger value from the SCP firmware. The shared-memory reply only holds MAX_DVFS_OPPS entries in buf.opps[]; a bigger count over-reads that array and then sizes the allocated OPP table incorrectly (garbage OPPs / OOB). The missing upper bound dates back to the original SCPI DVFS support. Reject zero and out-of-range counts in one check and return -EINVAL. Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") Signed-off-by: Xixin Liu Link: https://patch.msgid.link/022802f0b38f.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 8d85d6bc9c46dc41cb2be0eac53f8ab068c3a807 Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Wed Aug 26 16:17:45 2026 -0400 xfrm: hold net_device reference under RCU in bundle creation [ Upstream commit 9fa903b24b1f46b4ff5443bcd4aca23e5c57f9c1 ] xfrm_bundle_create() and xfrm_create_dummy_bundle() read dst->dev into a local pointer without taking a device reference, then pass it to xfrm_fill_dst(). A concurrent RTM_DELLINK replaces dst->dev via dst_dev_put() and frees the old net_device, causing a use-after-free when xfrm6_fill_dst() later dereferences the stale dev pointer. BUG: KASAN: slab-use-after-free in xfrm6_fill_dst+0x82c/0x860 (net/ipv6/xfrm6_policy.c:86 netdev_hold()) Read of size 8 at addr ffff8880142fe588 by task exploit/153 Call Trace: xfrm6_fill_dst+0x82c/0x860 xfrm_resolve_and_create_bundle+0x21d4/0x2bd0 xfrm_lookup_with_ifid+0x485/0x1640 ip6_dst_lookup_flow+0x19b/0x1e0 udpv6_sendmsg+0x1443/0x2dd0 Fix this by reading dst->dev via dst_dev_rcu() and keeping the RCU read-side critical section active until xfrm_fill_dst() has taken the required device references. Fixes: 25ee3286dcbc ("[IPSEC]: Merge common code into xfrm_bundle_create") Fixes: a0073fe18e71 ("xfrm: Add a state resolution packet queue") Suggested-by: Steffen Klassert Reported-by: Xiang Mei (Microsoft) Link: https://lore.kernel.org/all/20260820200245.44312-1-blbllhy@gmail.com/ Cc: AutonomousCodeSecurity@microsoft.com Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 3431f525718f6b07da308cda6d44f8cb548bbd37 Author: Gang Yan Date: Fri Aug 14 17:37:40 2026 +0800 RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access [ Upstream commit d10e2a08799e858d3e71ea4169bcd018f216d444 ] mr_check_range() validates that [iova, iova+length) falls within the registered MR range using wraparound-prone arithmetic: if (iova < mr->ibmr.iova || iova + length > mr->ibmr.iova + mr->ibmr.length) A remote peer can craft an RDMA-Write/Read RETH so that iova + length wraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the check. rxe_mr_iova_to_index() then computes a huge index (int idx, only guarded by WARN_ON) and rxe_mr_copy_xarray() dereferences mr->page_info[huge], causing an out-of-bounds read/write and a kernel oops that is triggerable by an unauthenticated remote peer. Rewrite the check in overflow-safe form; the first two clauses guarantee that the subsequent subtractions do not underflow: if (iova < mr->ibmr.iova || length > mr->ibmr.length || iova - mr->ibmr.iova > mr->ibmr.length - length) With the fix, mr_check_range() returns -EINVAL for the crafted iova and the responder reports REMOTE_ACCESS_ERROR instead of triggering the OOB. Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Gang Yan Link: https://patch.msgid.link/20260814093740.292954-1-gang.yan@linux.dev Reviewed-by: Zhu Yanjun Reviewed-by: Shukai Ni Tested-by: Shukai Ni Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4dd7a53f1c5b44693c26dac4b9b5bd5bb9d604c8 Author: Norbert Szetei Date: Thu Aug 27 19:18:07 2026 +0200 RDMA/rxe: validate access flags before swapping the MR's PD [ Upstream commit ae36a5b609ae79f4de966328b78d2584be9719a4 ] rxe_rereg_user_mr() reassigns mr->ibmr.pd first and only then validates the IB_MR_REREG_ACCESS argument: if (flags & IB_MR_REREG_PD) { rxe_put(old_pd); rxe_get(pd); mr->ibmr.pd = ibpd; } if (flags & IB_MR_REREG_ACCESS) { if (access & ~RXE_ACCESS_SUPPORTED_MR) return ERR_PTR(-EOPNOTSUPP); mr->access = access; } Both flags pass the entry check because RXE_MR_REREG_SUPPORTED is IB_MR_REREG_PD | IB_MR_REREG_ACCESS, so a caller can reach the access check with mr->ibmr.pd already reassigned. mr->ibmr.pd is owned by the core, which adjusts pd->usecnt only on the success path: ib_uverbs_rereg_mr() jumps to put_new_uobj on a driver error without undoing the reassignment, so mr->pd == new_pd while the usecnts still charge the MR to orig_pd. ib_dereg_mr_user() then decrements new_pd, whose count can reach zero while a memory window still references it; uverbs_free_pd() frees the PD on that count alone and rxe_mw_cleanup() writes to freed memory: BUG: KASAN: slab-use-after-free in __rxe_put+0x31/0xa0 Write of size 4 at addr ffff8881301dd690 by task rxe_poc/591 __rxe_put+0x31/0xa0 rxe_mw_cleanup+0x42/0x200 __rxe_cleanup+0x115/0x370 rxe_dealloc_mw+0x4c/0x80 Allocated by task 591: ib_uverbs_alloc_pd+0x258/0x540 Freed by task 591: ib_dealloc_pd_user+0x174/0x210 uverbs_free_pd+0x8d/0xc0 ib_uverbs_dealloc_pd+0x18e/0x1d0 Validate the access flags before mutating any state so the callback either applies every requested change or none. Fixes: 544c7f62cf32 ("RDMA/rxe: Implement rereg_user_mr") Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/46E1D5C0-24BE-4D01-BDB3-634FE09B22C5@doyensec.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit bfdc744bf20ae4c3ef2e470298de5237c5c9a13c Author: Guoqing Jiang Date: Thu Aug 27 20:55:53 2026 +0800 RDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept [ Upstream commit 32cd87f54dd1070020e664ccb0312a9f0fea79b4 ] We need to clear cep before release state_lock as siw_qp_llp_close and siw_qp_modify->siw_qp_llp_close did. Otherwise if siw_qp_modify() fails in siw_accept(), the QP's state_lock is released before the error path cleanup. A concurrent ibv_modify_qp() transitioning the QP to ERROR can race in this window: siw_accept() ibv_modify_qp(ERROR) ---------------------- ---------------------- siw_qp_modify() fails up_write(&qp->state_lock) down_write(&qp->state_lock) nextstate_from_idle(): if (qp->cep) siw_cep_put(qp->cep) <- frees cep qp->cep = NULL goto error cep->qp = NULL <- UAF Clear qp->cep and drop the association reference taken by siw_cep_get(), all under the write lock held from the initial down_write(&qp->state_lock). Thread B therefore sees qp->cep == NULL, skips its own put, and cannot free the cep before siw_accept() is done with it. Fixes: 6c52fdc244b5 ("rdma/siw: connection management") Reported-by: Shuangpeng Bai Link: https://lore.kernel.org/linux-rdma/d6fbe475-a5c2-f975-99b0-a0bd6b6d10e8@linux.dev/T/#m5876c1ff2de8686a9a1173b8f1aa0ff5363a785c Signed-off-by: Guoqing Jiang Link: https://patch.msgid.link/20260827125553.12831-1-guoqing.jiang@linux.dev Acked-by: Bernard Metzler Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e4f0d2f6bdc7bcbdf6a50f667df628992d0e8077 Author: Pengpeng Hou Date: Sun Aug 30 22:22:44 2026 +0800 ARM: socfpga: select the PL310 erratum 753970 workaround [ Upstream commit cfc1e9a543e3589ba200795b6e7fd8ef4314efdf ] ARCH_INTEL_SOCFPGA selects CACHE_L2X0 and several PL310 erratum workarounds. The 753970 workaround is still conditioned on PL310, but that Kconfig symbol no longer exists, so this one selection is always disabled. Select PL310_ERRATA_753970 directly, consistently with the other PL310 workarounds required by the platform. Fixes: fbc125afdc50 ("ARM: socfpga: Turn on ARM errata for L2 cache") Signed-off-by: Pengpeng Hou Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit 3b298e27c3dac0e273fe905d91c6a5ecad8317f7 Author: Lucas Tanure Date: Sat Aug 29 10:47:58 2026 +0100 arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM [ Upstream commit 406292fd75f95aa3010fec95b5beb5a8b7e3ba3a ] The vsync PWM output can appear on either of two pins, but the description named a single group that does not exist, so anything using it would refuse to start. Name the real groups instead, one entry per pin. No board describes this output yet, so nothing changes today. Fixes: 2a2a7b9701a7 ("arm64: dts: amlogic: t7: Add PWM pinctrl nodes") Assisted-by: Claude:claude-opus-5 Signed-off-by: Lucas Tanure Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260829094758.23248-5-tanure@linux.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 08194b1c7dfdfa15712e596df817c40f4523f7a6 Author: Lucas Tanure Date: Sat Aug 29 10:47:57 2026 +0100 arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies [ Upstream commit 1e5a53bd16ac501e68463e84023d1bff543cc696 ] The board powers its two CPU clusters, the GPU, the NPU, the memory and the always-on domain from regulators steered by PWM outputs. None of them were described, so Linux treated those outputs as unused and switched them off part way through boot. The supplies then drifted away from the levels the bootloader had set, which showed up as random hangs and memory corruption. Describe each supply so it has an owner and is left alone. The voltage ranges are read off the feedback networks on the board schematic. VDDNPU is deliberately not the range in Amlogic's own device tree: this board fits a different feedback resistor, which puts it about 40mV higher at both ends. Fixes: 8c45bf9ae4ef ("arm64: dts: amlogic: t7: khadas-vim4: Add power regulators") Assisted-by: Claude:claude-opus-5 Signed-off-by: Lucas Tanure Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260829094758.23248-4-tanure@linux.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 6a458c1d6e2ef0ad8e57968fb9e197f81bee5749 Author: Lucas Tanure Date: Sat Aug 29 10:47:56 2026 +0100 arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs [ Upstream commit ae7be5c58a819259e5eb98a3abfa60842478f2ae ] Two of the PWM outputs can each appear on more than one pin, but the description named a single group that does not exist, so anything using it refused to start. Name the real groups instead, one entry per pin, the same way the other multi-pin PWM output is already described. Fixes: 2a2a7b9701a7 ("arm64: dts: amlogic: t7: Add PWM pinctrl nodes") Assisted-by: Claude:claude-opus-5 Signed-off-by: Lucas Tanure Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260829094758.23248-3-tanure@linux.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 40332d03f6c67fe9d6677e1cd1f1eff7a5f5c0e8 Author: Lucas Tanure Date: Sun Aug 23 12:53:35 2026 +0100 arm64: dts: amlogic: t7: khadas-vim4: allow the SD card to be power cycled [ Upstream commit c793a084ab3088744516aef437b4239d0d98623f ] SD cards start at 3.3V and switch to 1.8V to reach UHS-I speeds. Some cards refuse that switch, and the SD specification says the only way to recover is to power the card off and start again. SD_3V3 is marked regulator-always-on, so the supply never goes off, the card stays stuck half way through the switch, and the MMC core retries forever: mmc1: error -95 whilst initialising SD card Drop regulator-always-on. regulator-boot-on still turns the supply on at boot, and a card that refuses the switch now falls back to high speed instead of failing to initialise. Fixes: 8c45bf9ae4ef ("arm64: dts: amlogic: t7: khadas-vim4: Add power regulators") Signed-off-by: Lucas Tanure Assisted-by: Claude:claude-fable-5 Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260823115335.102219-3-tanure@linux.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit d8724cb6a2d1d910dc1c47f827f153c10e5eddb5 Author: Lucas Tanure Date: Sun Aug 23 12:53:34 2026 +0100 arm64: dts: amlogic: t7: use the real UART pclk [ Upstream commit 882de800bf583dd15969836088789edbf035a944 ] uart_a listed the 24MHz crystal for all three of its clocks because the T7 clock controller driver did not exist when these boards were added. That leaves the real UART bus clock without a user, so the kernel turns it off when it disables unused clocks at the end of boot, and the board hangs. Update the board DTS files to point uart_a's pclk to CLKID_SYS_UART_A instead of the dummy crystal clock. Fixes: 4fef056588f5 ("arm64: dts: amlogic-t7-a311d2-khadas-vim4: add initial device-tree") Fixes: 6f048cc7a635 ("arm64: dts: add board AN400") Signed-off-by: Lucas Tanure Assisted-by: Claude:claude-fable-5 Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260823115335.102219-2-tanure@linux.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 0d0845ee61c5df47cc68bc446501f48f71e8dcc6 Author: Maher Azzouzi Date: Mon Aug 17 14:37:52 2026 +0100 esp: downgrade zerocopy managed frags before mutating skb frags [ Upstream commit f89416eb3db151170a6f3c6dfc5239d26cdce4d2 ] On the out-of-place output path (esp->inplace == false) ESP rewrites the skb frag array: esp_output_head() appends a trailer frag and esp_output_tail() replaces the frags with a destination page, both referenced with get_page(). When the skb carries zerocopy managed frags (SKBFL_MANAGED_FRAG_REFS) the payload frags are owned by the ubuf and must not be referenced or unreferenced individually, but ESP mutates the frag array without ever downgrading the skb. This breaks the managed-frag invariant two ways: - esp_ssg_unref() walks the source scatterlist and drops a page reference for every frag, including the ubuf-owned payload frags, pushing their refcount below the GUP pin bias while the pages are still pinned, i.e. a use-after-free of the zerocopy pages; - esp_output_tail() installs its destination page as frag 0 with get_page() but leaves SKBFL_MANAGED_FRAG_REFS set, so skb_release_data() takes the skip_unref branch and never drops that reference, leaking the x->xfrag page at packet rate. Fix this the way every other frag-mutating site does (__ip_append_data(), __ip6_append_data(), tcp_sendmsg_locked()) and call skb_zcopy_downgrade_managed() before ESP touches the frag array: it takes a real reference on each existing frag and clears SKBFL_MANAGED_FRAG_REFS, so the per-frag unref in esp_ssg_unref() and the frag release in skb_release_data() are both balanced and no mixed-ownership frag array is left behind. Fixes: 753f1ca4e1e5 ("net: introduce managed frags infrastructure") Signed-off-by: Maher Azzouzi Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 664fc0941df7c1918b2cd4de6ee00469ba77d8e4 Author: Eric Dumazet Date: Fri Aug 7 17:15:33 2026 +0000 xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject() [ Upstream commit d2f5082f9e84653fa1a9e8aebaaff23e688f5e19 ] syzbot reported a suspicious RCU usage warning in ip6_pkt_drop(): WARNING: suspicious RCU usage in ip6_pkt_drop include/net/addrconf.h:389 suspicious rcu_dereference_check() usage! Call Trace: __in6_dev_get_safely include/net/addrconf.h:389 [inline] ip6_pkt_drop+0x596/0x610 net/ipv6/route.c:4620 ip6_pkt_discard+0x1c/0x30 net/ipv6/route.c:4651 xfrm_trans_reinject+0x324/0x630 net/xfrm/xfrm_input.c:806 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 When commit 4f4920669d21 ("xfrm: Reinject transport-mode packets through workqueue") converted xfrm_trans_reinject from a tasklet to a workqueue, the reinjection loop ceased running in softirq context. Workqueue workers run in process context where local_bh_disable() does not enter an RCU read-side critical section under CONFIG_PREEMPT_RCU. Because finish callbacks (such as ip6_rcv_finish) expect to run under an RCU read lock (performing route lookups, l3mdev lookups, and accessing RCU-protected data structures), invoking them in workqueue context without rcu_read_lock() triggers RCU lockdep warnings. Furthermore, packets queued to the workqueue via xfrm_trans_queue_net() may carry non-refcounted (noref) dst entries (e.g. from ip_route_input_noref). Additionally, on netdevice unregistration, dst_dev_put() replaces dst->dev with blackhole_netdev, so dst entries do not keep skb->dev alive while queued in the workqueue. Fix these issues by: 1. Calling skb_dst_force(skb) in xfrm_trans_queue_net() while still in the caller's RCU section to ensure dst is reference-counted before queuing. 2. Holding a reference on skb->dev via dev_hold()/dev_put() across workqueue deferral so skb->dev remains valid during finish() callback processing. 3. Acquiring rcu_read_lock() around the finish callback invocation loop in xfrm_trans_reinject(). Fixes: 4f4920669d21 ("xfrm: Reinject transport-mode packets through workqueue") Reported-by: syzbot Signed-off-by: Eric Dumazet Cc: Steffen Klassert Cc: Liu Jian Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit e70f639aee2ff0def155c256cace9e0f81d998e2 Author: Kyle Zeng Date: Tue Aug 4 06:10:37 2026 +0000 xfrm: fix compat ALLOCSPI request use-after-free [ Upstream commit d1ebd9081879fd9ae9c8fb7e8928f19cc88ae320 ] xfrm_state_netlink() builds the ALLOCSPI response with dump_one_state(), which already calls alloc_compat() with the response skb and header. xfrm_alloc_userspi() then calls alloc_compat() again, but passes the original request skb and its header. For a compat request, the translator therefore interprets the 228-byte compat xfrm_userspi_info as the 232-byte native layout and reads four bytes past the declared payload. It also publishes the translated child through the request's frag_list. A multicast clone of the request shares skb_shared_info and can observe that child. xfrm_user_rcv_msg() frees it after the request handler returns, racing a compat receiver which may still be copying from it and resulting in a use-after-free. Remove the redundant conversion. The response keeps its correct compat translation from dump_one_state(), and no child is attached to the inbound request. Fixes: 5f3eea6b7e8f ("xfrm/compat: Attach xfrm dumps to 64=>32 bit translator") Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber Signed-off-by: Kyle Zeng Co-developed-by: David Lee Signed-off-by: David Lee Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 5b8afb56ccb7c014b0f1ac40341708b200443c2d Author: Henry Martin Date: Mon Aug 3 12:01:54 2026 +0800 xfrm: iptfs: fix runt reassembly panic from short inner tot_len [ Upstream commit dc33262be1fe43d0eb0b84fb58c6ed42e2f64a8c ] When the start of an inner packet is split across two outer packets such that fewer than 4 bytes land at the end of the first one, __input_process_payload() saves those bytes as a runt and skips the iplen/iphlen validation performed for in-place packets. When the continuation packet arrives, iptfs_reassem_cont() only requires the declared inner length to be >= sizeof(ra_runt) (6) before allocating the reassembly skb with that attacker-controlled length. However, __iptfs_iphlen() always returns the fixed minimum IP header size (20 for IPv4, 40 for IPv6), so for an inner IPv4 tot_len in [6, 19] the header-completion copy writes past the declared packet length, and the subsequent "ipremain -= copylen" underflows to ~4GB, leaving the payload copy length bounded only by blkoff (up to 64KB). At runtime the skb_put() tailroom check turns this into skb_over_panic(), i.e. an unprivileged kernel panic (DoS), reachable locally via userns+netns IPTFS SAs and remotely against IPTFS VPN gateways when the decrypted outer skb is linear (e.g. AF_PACKET taps, tun/tap delivery). Align the runt path with the normal path by requiring the declared inner length to cover at least the IP header size. This also subsumes the previous >= sizeof(ra_runt) check, since the minimum IP header is always larger than the runt buffer. This issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab. Fixes: 075694765446 ("xfrm: iptfs: handle received fragmented inner packets") Reported-by: Henry Martin Signed-off-by: Henry Martin Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 5b31ed6c0941195a1680648361858d18bb8b9500 Author: Aleksandr Nogikh Date: Fri Jul 31 10:06:20 2026 +0000 xfrm: add missing RCU read lock in xfrm_send_migrate_state() [ Upstream commit 42d100f5232f39b8ea7b00a7c2482325c7f032a4 ] xfrm_nlmsg_multicast() requires the RCU read lock to be held because it safely dereferences the net->xfrm.nlsk pointer using rcu_dereference(). When it is called from xfrm_send_migrate_state(), the RCU read lock is not held, which triggers a suspicious RCU usage warning: WARNING: suspicious RCU usage net/xfrm/xfrm_user.c:1630 suspicious rcu_dereference_check() usage! Call Trace: lockdep_rcu_suspicious+0x13f/0x1d0 kernel/locking/lockdep.c:6876 xfrm_nlmsg_multicast+0x1d8/0x1f0 net/xfrm/xfrm_user.c:1630 xfrm_send_migrate_state+0x870/0xae0 net/xfrm/xfrm_user.c:3340 xfrm_do_migrate_state+0x1749/0x1e90 net/xfrm/xfrm_user.c:3507 xfrm_user_rcv_msg+0x7a8/0xf30 net/xfrm/xfrm_user.c:3907 Fix this by wrapping the xfrm_nlmsg_multicast() call in xfrm_send_migrate_state() with rcu_read_lock() and rcu_read_unlock(). Fixes: a9d155ea9b44 ("xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+c0e99a1aa85a286d7a3b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c0e99a1aa85a286d7a3b Link: https://syzkaller.appspot.com/ai_job?id=8977f559-3a7e-4bb5-b4d6-1196956260b6 Signed-off-by: Aleksandr Nogikh Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit da56d0ee93d1bad779b0486f2fab92d1bc1f0cf3 Author: Roshan Kumar Date: Tue Jul 28 10:56:08 2026 +0530 xfrm: iptfs: fix stack OOB read in iptfs_skb_reset_frag_walk() [ Upstream commit d042487dc118e494db2e2c1382310255c90ff544 ] iptfs_skb_reset_frag_walk() advances to the fragment containing @offset with an unbounded loop: while (offset >= walk->past + walk->frags[walk->fragi].len) walk->past += walk->frags[walk->fragi++].len; walk->fragi is advanced and walk->frags[walk->fragi] is dereferenced without ever checking fragi against walk->nr_frags. When the requested offset is at or beyond the total length spanned by the walk's fragments, fragi runs past nr_frags and off the end of the fixed-size on-stack frags[MAX_SKB_FRAGS + 1] array, reading out-of-bounds stack memory. The two callers behave differently: iptfs_skb_add_frags() already guards against this with if (!walk->nr_frags || offset >= walk->total + walk->initial_offset) return len; but iptfs_skb_can_add_frags() has no such guard and calls iptfs_skb_reset_frag_walk() unconditionally, so it performs the out-of-range walk. Its own "fragi < walk->nr_frags" bound check runs only afterwards, too late to prevent the read. This is reachable from the receive path: a crafted IP-TFS (AGGFRAG) payload delivered to an IPTFS SA drives iptfs_reassem_cont() -> iptfs_skb_can_add_frags() with an offset past the fragment total, e.g.: BUG: KASAN: stack-out-of-bounds in iptfs_skb_reset_frag_walk+0x235/0x250 Read of size 4 at addr ffff888008ad7210 by task repro/345 iptfs_skb_reset_frag_walk+0x235/0x250 net/xfrm/xfrm_iptfs.c:392 iptfs_skb_can_add_frags+0x155/0x310 net/xfrm/xfrm_iptfs.c:420 iptfs_reassem_cont+0xcf8/0x1140 net/xfrm/xfrm_iptfs.c:902 iptfs_input_ordered+0x552/0x670 net/xfrm/xfrm_iptfs.c:1280 iptfs_input+0x3d6/0xde0 net/xfrm/xfrm_iptfs.c:1741 xfrm_input+0x282f/0x6140 net/xfrm/xfrm_input.c:700 xfrm4_esp_rcv+0x93/0x120 net/ipv4/xfrm4_protocol.c:104 ip_rcv+0x278/0x2d0 net/ipv4/ip_input.c:612 Give iptfs_skb_can_add_frags() the same up-front guard that iptfs_skb_add_frags() already has, so the walk is never entered with an out-of-range offset. When it triggers, the caller falls back to the existing linearize-and-copy path, which is safe. Fixes: 5f2b6a909574 ("xfrm: iptfs: add skb-fragment sharing code") Reported-by: Roshan Kumar Signed-off-by: Roshan Kumar Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit c43da1dd08cd9ae0fb65ad7dca434f2ccbb49218 Author: Jens Axboe Date: Tue Sep 1 19:39:46 2026 +0200 sunvdc: fix -EIO issue due to lack of retries [ Upstream commit 5067d4ba713961d8ccea1e06cd4c453793f3121e ] John reports that since commit: a11f6ca9aef9 ("sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") users of Linux inside Solaris ldom see occasional -EIO errors because the request send loop now times out. The current loop does 10 retries, and inside vio_ldc_send() a further 1000 1usec retries are done as well. Even with 10.5 msec of busy loop retries that's apparently not enough to always succeed. Rather than introduce continued busy looping, requeue the request and have the delayed queue kicking retry the request after another 10ms. This obviously isn't ideal, but there's seemingly no way to wait for this type of event. And if 10ms of busy looping was not enough to make progress, then presumably this is an edge condition and we just need to guarantee to make forward progress at some later point in time. That's more suitably done through letting the CPU tend to other work, rather than sitting in a tight loop retrying. [stian: rebased on top of the cookie-unmap fix, without which every requeued attempt leaks LDC map table entries; tested on an UltraSPARC T4 LDOM where the vdc_tx_trigger failure condition was reproduced and absorbed by the requeue with no I/O error] Reported-by: John Paul Adrian Glaubitz Link: https://lore.kernel.org/all/20251006100226.4246-2-glaubitz@physik.fu-berlin.de/ Link: https://lore.kernel.org/all/418310b3-2b77-4534-b2fd-27dcc11e333c@kernel.dk/ Signed-off-by: Stian Halseth Link: https://patch.msgid.link/20260901173947.3292110-3-stian@itx.no Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1620594720383249a95eb1ebb2154428e3967bcc Author: Günther Noack Date: Thu Sep 17 17:42:29 2026 +0200 selftests/landlock: Add audit test for whiteout object creation [ Upstream commit 8c46c6acbebe0d8544fd1b55e5ddf36828d7b9ea ] Add audit_layout1.make_whiteout: This test looks similar to audit_layout1.make_char, but creates a whiteout object through mknod(). Since whiteout object creation is now guarded with LANDLOCK_ACCESS_FS_MAKE_REG rather than LANDLOCK_ACCESS_FS_MAKE_CHAR, it also needs to log the matching denial to audit. Signed-off-by: Günther Noack Link: https://patch.msgid.link/20260813093157.1436894-5-gnoack@google.com Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit 7c233eabb89ffb6b7550f7d6412e8b73f71a2948 Author: Günther Noack Date: Thu Sep 17 17:42:28 2026 +0200 selftests/landlock: Add tests for whiteout object creation [ Upstream commit ee890889b30b22f9a21636061def7a04e4f89380 ] Add tests to check that whiteout object creation is guarded by LANDLOCK_ACCESS_FS_MAKE_REG, in the cases where these are created from userspace: * Conventional creation with mknod() * Linking or renaming an existing whiteout object * renameat2() with RENAME_WHITEOUT, which creates a new whiteout object in the source location * renameat2() with RENAME_EXCHANGE, with one of the renamed objects being a whiteout object Signed-off-by: Günther Noack Link: https://patch.msgid.link/20260813093157.1436894-4-gnoack@google.com [mic: Update commit message as requested] Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit bb45f6d4b890629bfd3a0722662f7af6b05783bf Author: Günther Noack Date: Thu Sep 17 17:42:27 2026 +0200 selftests/landlock: Use an actual chardev for MAKE_CHAR audit test [ Upstream commit 173b1bd8730825e1f6862dbd07856e7d68447a41 ] By passing a (0, 0) device number, the audit test for LANDLOCK_ACCESS_FS_MAKE_CHAR was accidentally creating a whiteout object rather than a char device. In preparation to treating whiteout objects differently, use an actual character device instead. Signed-off-by: Günther Noack Link: https://patch.msgid.link/20260813093157.1436894-2-gnoack@google.com Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin