commit dd88d16895909aeaa7ac9fb867cd5c798826040b Author: Alexandre Frade Date: Sat Nov 7 07:42:52 2026 +0000 Linux 6.18.62-xanmod1 Signed-off-by: Alexandre Frade commit 9be512814487d72401f60133aa2b15837c3b0658 Merge: 7d1d06705486 c3f63d70f236 Author: Alexandre Frade Date: Sat Nov 7 07:38:39 2026 +0000 Merge tag 'v6.18.62' into 6.18 This is the 6.18.62 stable release commit c3f63d70f236bb7685e6d11d1d9b5b351552e600 Author: Greg Kroah-Hartman Date: Fri Nov 6 13:17:37 2026 -0500 Linux 6.18.62 Signed-off-by: Greg Kroah-Hartman commit c49934da934cf495faf782aa5d84f413221c9be6 Author: Juergen Gross Date: Thu Nov 5 08:27:38 2026 +0100 xen-blkback: Avoid UAF when reading I/O statistics commit a02926f7c89bfc798ee9514e09694ff4279928a1 upstream. Reading I/O statistics via sysfs concurrently with tearing down a frontend device might result in UAF or a NULL dereference, as the reading of the statistics data is not synchronized with freeing the data. Use a rwlock for synchronizing. This is XSA-528 / CVE-2026-100082 Reported-by: Yehyeong Lee Signed-off-by: Juergen Gross Acked-by: Roger Pau Monné Signed-off-by: Greg Kroah-Hartman commit 34f0f63dc6dc11895a17bb5672451b6b11622c99 Author: Jan Beulich Date: Fri Nov 6 17:07:01 2026 +0100 xen-netback: defer xenvif_mcast_addr_list_free() commit bfddc420afe827d9f06458cdf8087cd602f8c9cb upstream. In order for the function to legitimately avoid locking/RCU, it needs to run after all TX/RX processing has finished/stopped: Lookups happen from xenvif_start_xmit(), while adds/removes happen from xenvif_tx_action() (called out of xenvif_poll()). Move the call out of xenvif_disconnect_data() (the call to the function from connect()'s error path doesn't require any cleaning up there), and put it past the synchronization point in backend_disconnect(). This is XSA-527 / CVE-2026-100081. Fixes: b17075d5c198 ("xen-netback: fix race condition on XenBus disconnect") Reported-by: kerhunt Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 37d5a73170579b30e67cc8b19ec69715eea3a6b6 Author: Juergen Gross Date: Fri Nov 6 13:07:52 2026 +0100 xen-netback: Fix UAF when reading statistics data commit 5fb756f1bbec7a3862dda5d79028bf656271804c upstream. The network statistic data in the driver is protected by RCU. Unfortunately when tearing down the queues after an error during connecting to the frontend (e.g. due to illegal Xenstore data filled in by the guest), the statistic data is being freed without synchronizing the RCU state. In case the data is being read via sysfs in this phase, access to already freed memory or memory being in new use is possible. Fix that by calling synchronize_net() before freeing the queue data. This is XSA-526 / CVE-2026-100080 Reported-by: Yehyeong Lee Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 7ab573237315f5cba0603cb039698adebeb29094 Author: Greg Kroah-Hartman Date: Fri Nov 6 12:06:15 2026 -0500 Linux 6.18.61 Link: https://lore.kernel.org/r/20261104211043.516122098@linuxfoundation.org Tested-by: SJ Park Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Ron Economos Tested-by: Pavel Machek (CIP) Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Miguel Ojeda Tested-by: Barry K. Nathan Signed-off-by: Greg Kroah-Hartman commit 4d14072b93fa78cad4f05a13f3c63090d9ba5e8f Author: Alice Ryhl Date: Tue Nov 25 13:59:37 2025 +0000 rust: bitmap: add MAX_LEN and MAX_INLINE_LEN constants commit f5535d78e12600deb30a9fb3c628c425f0caec21 upstream. To avoid hard-coding these values in drivers, define constants for them that drivers can reference. Also, update all instances in bitmap.rs and id_pool.rs that use these values to use the new constants. Signed-off-by: Alice Ryhl Reviewed-by: Burak Emir Signed-off-by: Yury Norov (NVIDIA) Signed-off-by: Greg Kroah-Hartman commit 2f92c0286cfd58bff9d6d54c01a771073d5eb775 Author: David Woodhouse Date: Tue Oct 20 10:48:10 2026 +0100 tun: Require CAP_NET_ADMIN to attach to an ownerless device commit ffdf678dd16610e3f006dac904bd37c09684673c upstream. Twenty years ago I made creating a tuntap device require CAP_NET_ADMIN in commit ca6bb5d7ab22 ("[NET]: Require CAP_NET_ADMIN to create tuntap devices.") The idea was to allow the permissions on /dev/net/tun to be relaxed to 0666 and thus allow owners of tun devices assigned with TUNSETOWNER to actually open it and get at their devices. What we missed at the time was that persistent devices with *no* owner were already essentially world-consumable, and anyone who could open the device node could also attach to those. Even then, using persistent devices with no explicitly set owner — on the (false) presumption that CAP_NET_ADMIN would be required to open them — wasn't an egregious userspace bug. There are cases where it does make sense to separate the creation/configuration of the netdevice, from the process which shovels packets into it. Since then, TUNSETGROUP was added a year later in commit 8c644623fe7e ("[NET]: Allow group ownership of TUN/TAP devices."). Its commit message noted that if both uid and gid are set, both have to match (in itself a bizarre choice) — but still not that with *neither* set, no permission at all was required. Then in 2012 commit c8d68e6be1c3 ("tuntap: multiqueue support") allowed new queues to be attached to a device from the moment of its creation, with no way for userspace to close the race between creation and a subsequent TUNSET{OWNER,GROUP}. In 2024, commit 3ca459eaba1bf ("tun: fix group permission check") tried to fix things to be saner: only require the user *or* the group to match, in line with standard POSIX permissions, and require CAP_NET_ADMIN if neither the user nor group authorised the access (although it put the CAP_NET_ADMIN check first, and would wrongly have reported the capability as having been used even when it was not). That fix was reverted in commit a70c7b3cbc06 ("tun: revert fix group permission check") due to allegedly causing a regression in an selinux test suite which *expected* the attachment to succeed when authorised by none of user, group, nor CAP_NET_ADMIN: https://lore.kernel.org/netdev/CAFqZXNtkCBT4f+PwyVRmQGoT3p1eVa01fCG_aNtpt6dakXncUg@mail.gmail.com/ We should not break UAPI. But we don't have to consider an selinux test case which deliberately exercises a security flaw to be UAPI worth preserving either. To which end, I have fixed it in selinux-testsuite commit b2f894f0016b ("tests/tun_tap: set an owner on the device for the relabel tests"). So: fix the lack of CAP_NET_ADMIN check on devices which *haven't* been assigned an owner or group, while leaving the weird tun ownership model as it was (user *and* group have to match, if both are set). If someone still wants to fix the latter (which wasn't actually the reason the previous attempt was reverted), they can do it under separate cover. Permit attaching to an existing device only if an owner and/or group was set and the caller matches all that were set, or if the caller has CAP_NET_ADMIN. The only behavioural change is that a device with no owner or group now requires CAP_NET_ADMIN to attach — precisely the loophole we want to close. And put the CAP_NET_ADMIN check in the right place this time. Fixes: ca6bb5d7ab22 ("[NET]: Require CAP_NET_ADMIN to create tuntap devices.") Reported-by: Andrew Lutomirski Signed-off-by: David Woodhouse Cc: stable@vger.kernel.org Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/3c77f88acff5b3c2617b22d64faad15f6212619c.camel@infradead.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3c5bfeef8f711ceb355f26390ab53871025e93db Author: Scott Gauche Date: Mon Oct 5 11:40:17 2026 -0400 ALSA: hda/realtek: Fix audio after Windows reboot on ASUS Q423SA commit 8acd6469f42784f38872ad83b14c41152d986b63 upstream. The ASUS Vivobook S 14 Q423SA-U5512 (DMI family S5406SA) with the ALC294 codec has working analog audio when booted directly after a full shutdown. After a warm reboot from Windows 11, audio works briefly during Linux startup, then both the internal speakers and headphones become silent. PCM playback continues without errors. Coefficient 0x1b is 0x4e4b on a direct cold boot, but 0x4a4b after the Windows warm reboot. Restoring bit 10 changes it back to 0x4e4b and immediately enables both analog outputs. Speaker playback, headphone playback, jack switching, cold boot, and suspend/resume were tested successfully. The same 0x4a4b state and immediate recovery with 0x4e4b were independently confirmed on another S5406SA with subsystem 1043:10c4. The same coefficient write is already used by ALC294_FIXUP_ASUS_COEF_1B for the ASUS UX431DA. That fixup cannot be reused here because it chains to ALC289_FIXUP_ASUS_GA401 and applies unrelated DAC routing and microphone pin configuration. Add a model-specific fixup for subsystem 1043:10c4 and chain it to the existing ALC2XX_FIXUP_HEADSET_MIC fixup instead. Link: https://github.com/thesofproject/sof/issues/11051 Fixes: f2d08f3651fb ("ALSA: hda/realtek: Fix headset mic on ASUS Vivobook S14 S5406SA") Signed-off-by: Scott Gauche Link: https://patch.msgid.link/20261005154017.1164657-1-scott-dev@scottgauche.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9ec1c52ba989baeb3a6daa118dc22f9802406524 Author: Peter Griffin Date: Tue Sep 8 12:37:27 2026 +0000 opp: fix use after free in _update_opp_table_clk() commit 1f6de65e3314519ce462bfd3a1d29e918f97e4e5 upstream. dev_pm_opp_put_opp_table() frees the opp_table which is subsquently used by dev_err_probe(). This causes an Oops during boot on gs101-oriole. cpu cpu0: error 000000006b6b6b6b: Couldn't find clock Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cd3 ... Hardware name: Oriole (DT) pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _of_add_table_indexed+0x80/0xbb0 lr : _of_add_table_indexed+0x6c/0xbb0 ... Call trace: _of_add_table_indexed+0x80/0xbb0 (P) dev_pm_opp_of_cpumask_add_table+0x70/0x120 dt_cpufreq_probe+0x23c/0x480 platform_probe+0x64/0xb8 Fixes: 84f05af0975c9 ("opp: Use clk_get_optional() to avoid leaving opp_table->clk as an error pointer") Signed-off-by: Peter Griffin Reviewed-by: Tudor Ambarus [ Viresh: use return value of dev_err_probe() ] Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 4225b4944f9d11e2d59562867ff0b027ba0025b9 Author: Pablo Neira Ayuso Date: Mon Aug 10 10:18:22 2026 +0200 netfilter: conntrack: always lower timeout for non-closing RST packets commit 73df81b38cb7f70a347a97370386378a86e53019 upstream. The existing check might extend the timeout if the ESTABLISHED timeout has been tuned to be lower than UNACK via sysctl. Reported by sashiko. Fixes: bf80e6802273 ("netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 34bdda87c1890b18f0dc40211ec755e392168c6c Author: Srinivasan Shanmugam Date: Thu Jun 25 10:25:24 2026 +0530 drm/amdgpu/powerplay: Align get_tonga_state_array() header with prototype commit 4986757d3207383c052689532e505edccc6df7c8 upstream. The function header above get_tonga_state_array() still refers to check_powerplay_tables() and does not describe all of the function parameters. Update it to match the current function prototype and include the missing parameter description. Fixes: 1ac24df78c56 ("drm/amd/pm: Validate Tonga PowerPlay state array bounds") Cc: Yang Wang Cc: Hawking Zhang Signed-off-by: Srinivasan Shanmugam Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 27f2fdcb6be2e8762ad660a579827e834644beea Author: Alexander Atanasov Date: Sun Jan 25 08:57:46 2026 +0000 selftests: ublk: add missing gitignore for metadata_size binary commit 8e5bcc3a955a2cc4460b391f55d3b49905eb248e upstream. A new utility metadata_size was added in commit 261b67f4e347 ("selftests: ublk: add utility to get block device metadata size") but it was not added to .gitignore. Fix that by adding it there. While at it sort all entries alphabetically and add a SPDX license header. Reviewed-by: Caleb Sander Mateos Fixes: 261b67f4e347 ("selftests: ublk: add utility to get block device metadata size") Signed-off-by: Alexander Atanasov Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 7dc33618ae473d3354277a7f76df256c435d7713 Author: Sean Young Date: Wed Sep 23 09:32:02 2026 +0100 media: rc: Fix build failure with CONFIG_LIRC disabled commit 0c795849fd70d6bdb99aea5dd08d9b43128612f6 upstream. commit 37efd09ba2c6 ("media: rc: Ensure registered is cleared in error path") broke the build if CONFIG_LIRC was not enabled. Fixes: 37efd09ba2c6 ("media: rc: Ensure registered is cleared in error path") Reported-by: kernel test robot Link: https://lore.kernel.org/oe-kbuild-all/202609230511.Em5Osw74-lkp@intel.com Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit 3594027c292b09d9301b4be80fa8e0c815ffaf2a Author: Zi Yan Date: Mon Oct 12 22:20:16 2026 -0400 mm/rmap: don't discard lazyfree THPs at PMD level commit 984c0700854e35779a2bcce6b02783e709b6efa2 upstream. __discard_anon_folio_pmd_locked() clears a lazyfree THP's PMD before it determines whether the folio can be discarded, and restores it if the folio is dirty or has extra references. It is done under only the PMD lock and the anon_vma read lock inside try_to_unmap_one() and no mmap lock is held. The temporarily none PMD causes UAF. A parallel munmap() or mremap() is supposed to serialize with it on the PMD lock, but zap_pmd_range() (called by munmap()) and move_page_tables() (called by mremap()) do not take the lock when they see the temporarily none PMD and skip the PMD. There is no more page table walk after the none PMD is restored: - munmap(): free_pgtables() waits in unlink_anon_vmas() for the anon_vma lock, then free_pmd_range() drops the restored PMD as bad without removing the rmap, so the folio keeps a stale mapcount. - whole-VMA MREMAP_DONTUNMAP: dontunmap_complete() unlinks the source VMA from its anon_vma while the restored PMD still maps the folio. - plain mremap(): the THP is not moved but unmapped, so the THP's data is lost. In the first two cases, the folio stays mapped, but no VMA that maps it is linked to its anon_vma. When the anon_vma is freed, it is still reachable when one rmap walks the folio. Racing lazyfree reclaim against MREMAP_DONTUNMAP as an unprivileged user reproduces a KASAN use-after-free in folio_lock_anon_vma_read() as reported in the Closes link. One solution is to use an invalidated PMD instead of a cleared one until the discard is committed, but it needs arch fixes first. 1. GUP-fast still follows an invalidated PMD on riscv, LoongArch and s390. 2. sparc64 miscounts thp_pte_count when an invalidated PMD is set again or cleared. To keep the fix simple for backport, stop discarding lazyfree THPs at PMD level instead. try_to_unmap_one() splits the PMD and discards the folio at PTE level. unmap_huge_pmd_locked() and __discard_anon_folio_pmd_locked() are left in place, unused, to minimize this fix for backport and the invalidated PMD approach is planned as a follow-up series to use them again. Link: https://lore.kernel.org/20261012-lazyfree-stable-fix-v2-1-6387d6e30063@nvidia.com Fixes: 735ecdfaf4e8 ("mm/vmscan: avoid split lazyfree THP during shrink_folio_list()") Signed-off-by: Zi Yan Signed-off-by: Andrew Morton Reported-by: Kyle Zeng Closes: https://lore.kernel.org/r/20261009165214.40212-2-kylebot@openai.com Reviewed-by: Kyle Zeng Reviewed-by: Lance Yang Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Tested-by: JongHyuk Kim(MalHyuk) Link: https://lore.kernel.org/CADQRuqvXQ=YE=7T3oR66vTxE33pi=ygEeZKPTOU=cALZL0Figw@mail.gmail.com Assisted-by: LLM Cc: Rik van Riel Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Harry Yoo Cc: Jann Horn Cc: Signed-off-by: Zi Yan Signed-off-by: Greg Kroah-Hartman commit 63dc56500a91591ad9b42e09ca4646b0a4d03406 Author: Danish Khateeb Date: Wed Nov 4 10:58:23 2026 -0500 pps: generators: fix use-after-free when closing a removed device [ Upstream commit d19552611cb2eb6329826871565e5309bec2f288 ] The cdev of a PPS generator is embedded in struct pps_gen_device, but nothing ties the lifetime of that structure to the cdev: pps_gen is freed by the release function of its device, and an open file holds a device reference only until pps_gen_cdev_release() drops it. When the generator is unregistered while /dev/pps-genN is open, that put_device() drops the last reference and frees pps_gen, and __fput() then calls cdev_put() on the freed cdev: BUG: KASAN: slab-use-after-free in cdev_put+0x53/0x60 Read of size 8 at addr ffff88801383e138 by task ppsgen64/149 Call Trace: cdev_put+0x53/0x60 __fput+0x745/0xad0 fput_close_sync+0xd9/0x1b0 __x64_sys_close+0x86/0xf0 ... Freed by task 149: kfree+0x25a/0x6d0 device_release+0xca/0x3c0 kobject_put+0x169/0x320 pps_gen_cdev_release+0x51/0x80 __fput+0x36a/0xad0 pps.c had the same bug, fixed in commit c79a39dc8d06 ("pps: Fix a use-after-free"). Fix it the usual way: embed the struct device in pps_gen_device and register both with cdev_device_add(). This makes the device the parent of the cdev, so the cdev holds a device reference until the last file is closed. Fixes: 86b525bed275 ("drivers pps: add PPS generators support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Danish Khateeb Acked-by: Rodolfo Giometti Link: https://patch.msgid.link/20260929124937.51114-2-danishkhateeb03@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2b2a1d370f16fa545902f60b2eb95738285f4b8b Author: Jori Koolstra Date: Wed Nov 4 10:58:22 2026 -0500 pps: change pps_gen_class to a const struct [ Upstream commit 4dc0c899b14c3ea2c9b5f42b523301040d1c8100 ] The class_create() call has been deprecated in favor of class_register() as the driver core now allows for a struct class to be in read-only memory. Change pps_gen_class to be a const struct class and drop the class_create() call. Signed-off-by: Jori Koolstra Reviewed-by: Greg Kroah-Hartman Acked-by: Rodolfo Giometti Link: https://patch.msgid.link/20260302142436.3292766-1-jkoolstra@xs4all.nl Signed-off-by: Greg Kroah-Hartman Stable-dep-of: d19552611cb2 ("pps: generators: fix use-after-free when closing a removed device") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d1df2ec20a6ddac6ae553b34b39472a20c5de9c6 Author: Yibo Tan Date: Wed Nov 4 10:58:03 2026 -0500 media: ipu-bridge: Fix use-after-free in IVSC error path [ Upstream commit 3d42d1c82717f0853379b516a7fab54b636e09cc ] ipu_bridge_get_ivsc_acpi_dev() returns an ACPI device with a reference held. If no matching CSI device is found, ipu_bridge_check_ivsc_dev() drops that reference before passing the device to dev_err(). Concurrent CSI device and ACPI namespace removal can drop the other references, making this the final put. dev_err() then reads the freed struct acpi_device and its kobject name. This was reproduced without kprobes by racing normal CSI platform-device unregistration and ACPI configfs table removal against the production ipu_bridge_init() entry. KASAN reported the final free through device_release(), followed by invalid reads through _dev_err(). Emit the error message while the lookup reference is still held, then drop the reference as before. Source reproducers and vulnerable/fixed serial logs, with only the build hostname redacted, are available at: https://github.com/kimaiden1984-boop/linux-ipu-bridge-acpi-uaf-reproducer The fixed target builds with W=1 on x86-64. This was not tested on physical IPU hardware. The tests establish runtime reachability but do not measure occurrence frequency on shipping systems or establish exploitability. Fixes: c66821f381ae ("media: pci: intel: Add IVSC support for IPU bridge driver") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Yibo Tan Signed-off-by: Sakari Ailus [ sashal: Retained the existing "MEI CSI dev" diagnostic because CVS support is absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bd47ee501b6ac4a26ae41f780a43b7967302a269 Author: Ian Bridges Date: Tue Nov 3 17:40:00 2026 -0500 ksmbd: fix use-after-free after a failed durable reconnect [ Upstream commit 248b5819591c577727930e4e255a455235fab50a ] ksmbd_reopen_durable_fd() republishes a detached durable handle in the reconnecting session's file table and takes no reference for that entry. If smb2_open() then fails, cleanup relies on the final ksmbd_fd_put() to remove the volatile id. Two reconnects of the same handle can both take a lookup reference before either attaches it. If the one that reopens first then fails and drops its references first, the other request makes the final put through ksmbd_put_durable_fd(). That frees the handle without removing the first session's table entry, so tearing that session down writes to freed memory. BUG: KASAN: slab-use-after-free in __close_file_table_ids+0x14d/0x740 [ksmbd] Call Trace: __close_file_table_ids+0x14d/0x740 [ksmbd] ksmbd_destroy_file_table+0x76/0x100 [ksmbd] ksmbd_session_destroy+0xf8/0x480 [ksmbd] ksmbd_dispose_sessions+0x13e/0x200 [ksmbd] ksmbd_conn_sessions_cleanup+0x4c3/0x6d0 [ksmbd] Freed by task 1030: __ksmbd_close_fd+0x97d/0x1000 [ksmbd] smb2_open+0x14eb/0xd9f0 [ksmbd] Commit 3515503322f4 ("ksmbd: fix durable reconnect error path file lifetime") handles a final put made by the reconnecting request, but not one made by another holder. Remove the volatile id under the file-table lock on this error path, before the references are dropped, as ksmbd_close_fd() does on the request_open path just above. Removal then no longer depends on which holder makes the final put. The stale comment in the reconnect cleanup is updated to match. A successful reconnect is unchanged. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Cc: stable@vger.kernel.org Signed-off-by: Ian Bridges Signed-off-by: Namjae Jeon [ sashal: Adapted the cleanup call to a braced if (fp) block because the replay and request-open cleanup branches are absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7f30b886c5a1a2b3d9342ea82d0699eff812a472 Author: Dairui Zhang Date: Tue Nov 3 16:38:12 2026 -0500 ksmbd: verify transform SessionId matches the decrypted header [ Upstream commit 798214e6fafcdcc29f5ba2661a473232b5e70cfb ] When an encrypted request comes in, the decryption key is picked by the SessionId in the transform header, but the request is then authorized under whatever session the decrypted inner header names. Nothing ever compares the two, so on a connection with more than one session a client can get a request decrypted with one session's key and run it as another session. Encrypted requests are exempt from signing too, so a valid AEAD tag is the only proof of session identity, and it is checked against the wrong session. MS-SMB2 says the server must check that the transform SessionId matches the one in the decrypted SMB2 header and treat a mismatch as a protocol error. Add that check in __handle_ksmbd_work() after decryption, before dispatching: the message has to be at least one fixed SMB2 header, the first operation must not set SMB2_FLAGS_RELATED_OPERATIONS and its SessionId must match the transform SessionId, and every following non-related operation in a compound chain must carry the same SessionId. NextCommand offsets must be 8-byte aligned and stay inside the message; the bounds check is done by subtraction so it cannot wrap. When the decrypted payload is a compression transform, the existing decompression step runs first and the decompressed SMB2 message is checked instead, since a compression transform header carries no SessionId. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: Dairui Zhang Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Dairui Zhang Signed-off-by: Namjae Jeon [ sashal: Placed session validation directly after decryption because the intervening decompression code is absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c81681bcb7f088f1c2509bbc1a046b0403f5fbb6 Author: DaeMyung Kang Date: Tue Nov 3 16:37:54 2026 -0500 ksmbd: fix named stream write and EOF handling [ Upstream commit 02165c8d402392278a5cd2cf97645ed73a7ad4a1 ] An SMB WRITE to an existing named stream can silently discard data after its written range. ksmbd stores streams as xattr values, but the write path passes offset + count as the length of the replacement xattr even when the old stream is longer. Writing 26 bytes at offset 0 to a 60-byte stream reports 26 bytes written while discarding the remaining 34 bytes. Keep the existing xattr length when an in-place write ends before EOF. Reject writes that cross XATTR_SIZE_MAX rather than storing only the portion that fits while reporting the full requested count. Commit 4ea0bb8aaedf ("ksmbd: handle set/get info file for streamed file") intentionally skipped ordinary inode truncation for stream handles: an EOF SetInfo on an ADS had truncated the base file. That fixed the base file corruption but left stream EOF changes reporting success without resizing the stream. Handle these requests by resizing only the stream xattr; the base file size remains untouched. Zero-fill stream extensions. This is needed alongside the write fix: a short write's accidental truncation previously masked an ignored explicit EOF change. The stream resize helper returns xattr errors directly rather than using the base-file truncate path's EBADF conversion. Fixes: f44158485826 ("cifsd: add file operations") Fixes: 4ea0bb8aaedf ("ksmbd: handle set/get info file for streamed file") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon [ sashal: changed const struct mnt_idmap pointers to non-const pointers ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3092d8a596efaeccdebe0804bf263e5e6eef39d7 Author: Ian Bridges Date: Tue Nov 3 14:48:59 2026 -0500 ksmbd: fix out-of-bounds read when padding the final compound response [ Upstream commit 714f27729121d59f103ca4dad7b0c2d1c125cd71 ] Compound response handling pads the last response of a compound to an 8-byte boundary by growing the final iov and the RFC1002 length. smb2_allocate_rsp_buf() allocates exactly response_sz. A command can fill the response buffer to within 7 bytes of its end, for example a QUERY_INFO whose output is bounded only by the space left. The padding can then run past the allocation, and ksmbd_tcp_writev() reads those bytes when it sends the response. BUG: KASAN: slab-out-of-bounds in _copy_from_iter+0x744/0x10e0 Call Trace: _copy_from_iter+0x744/0x10e0 tcp_sendmsg_locked+0x2290/0x3f80 ksmbd_tcp_writev+0x10c7/0x1ab0 [ksmbd] Allocate room for the padding when the request is a compound, as smb2_read() and smb2_read_pipe() do for their payloads. response_sz is unchanged, so commands still fill only up to it, and kvzalloc() zeroes the padding. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Ian Bridges Signed-off-by: Namjae Jeon [ sashal: Adjusted context to retain work->conn->vals->max_trans_size instead of vals->max_trans_size. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 52a8eb87416e775c6af5018dc5fc04733abedafc Author: DaeMyung Kang Date: Tue Nov 3 14:48:46 2026 -0500 ksmbd: use the existing xattr name for a named stream [ Upstream commit a7d1d52748e0fe4d06fdb871fc9899904fbba93f ] SMB stream names are case-insensitive, but ksmbd stores each named stream in an xattr whose name is case-sensitive. Opening an existing stream finds its xattr with a case-insensitive match, yet the handle keeps the name as the client spelled it, and every later operation that needs an exact name uses that spelling: - a WRITE or an end-of-file change creates a second xattr, so a stream created as "Foo" and written through "foo" ends up stored twice, and which value a later lookup returns depends on xattr list order; - delete-on-close and delete-pending removal can fail with -ENODATA, or remove only a case-variant copy and leave the original; - the share mode check compares stream names with strcmp(), so two opens of the same stream that differ only in case do not conflict. Have ksmbd_vfs_casexattr_len() copy the matching xattr's name into the handle when the stream is opened, so later operations use the name already on disk. The match must have the same length as the name it replaces; the stream lookup passes a length that includes the terminating NUL, which already guarantees that, and the check makes the copy safe for any caller. A stream that does not exist yet keeps the client's spelling, as before. smb2_rename() compares and looks up fp->stream.name case-insensitively, so it behaves the same with either spelling. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon [ sashal: adapted stream lookup signature changes to the existing callers and non-const mnt_idmap interface ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4a7f332fd43eee2541197d6e1e297b9ef2e1b07f Author: Henry Hu Date: Tue Nov 3 14:48:15 2026 -0500 ksmbd: fix invalid pointer dereference when get_inode_acl() fails [ Upstream commit 19d180c7baab7126af5848ed87d5f7b5add0cef2 ] When get_inode_acl() fails, it returns an ERR_PTR(), but ksmbd_acls_fattr() stored that pointer in smb_fattr without checking for errors. Later callers then passed the error pointer to security descriptor helpers or posix_acl_release(), resulting in an invalid pointer dereference. This was reproduced on an XFS-backed share when xfs_get_acl() returned ERR_PTR(-ENOMEM). Querying the SMB ACL from a CIFS client triggered the crash: BUG: unable to handle page fault for address: fffffffffffffff8 RIP: smb_acl_sec_desc_scratch_len+0x58/0x90 [ksmbd] Call Trace: smb2_query_info+0x40d/0x17c0 [ksmbd] handle_ksmbd_work+0x1ca/0x770 [ksmbd] Fix this by checking the return values from get_inode_acl() in ksmbd_acls_fattr(). Treat -EOPNOTSUPP as indicating that no ACL is available, and propagate all other errors to the callers. Update smb2_open() and smb2_get_info_sec() to handle these errors. Cc: stable@vger.kernel.org Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Assisted-by: Codex:gpt-5.6-sol Reviewed-by: ChenXiaoSong Signed-off-by: Henry Hu Signed-off-by: Namjae Jeon [ sashal: retained the non-const mnt_idmap parameter in ksmbd_acls_fattr() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fbe9fcda7ae8835b454c376de1d49232ab6bbcfb Author: Namjae Jeon Date: Tue Nov 3 10:47:24 2026 -0500 ksmbd: prevent stale data from being written by SMB2 WRITE requests [ Upstream commit bc0e0f5ac1d7b044d403f859406b4b66d4b1ce9b ] Initialize the compatibility byte in request buffers without zeroing the entire allocation. Keep the one-byte compatibility exception for SMB2 messages so valid zero-length WRITE requests remain compatible, and validate the data range in the WRITE handlers against the current compound request before accessing it. This prevents stale request-buffer data from being written to files or sent to IPC pipes. Fixes: 443d61d1fa9f ("ksmbd: allocate one more byte for implied bcc[0]") Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-32436 Signed-off-by: Namjae Jeon [ sashal: Inlined the unavailable smb2_current_req_len() helper and omitted the decompression change because compression support is absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2756a41a82d618bf1d8b41d74108311815cb695c Author: Namjae Jeon Date: Tue Nov 3 10:34:00 2026 -0500 ksmbd: prevent share root removal through empty paths [ Upstream commit 9fd1fcbbf84986a7bcf601a2b90540899069d263 ] A FileLinkInformation request can supply "/" as the new link name. smb2_get_name() strips the trailing slash and passes an empty string to ksmbd_vfs_kern_path_start_removing(). ksmbd_vfs_path_lookup() resolves an empty pathname as the configured share path, without LOOKUP_BENEATH. With ReplaceIfExists set, smb2_create_link() can therefore remove the share root from its parent before link creation fails. An authenticated client with a writable share and DELETE access to a file can trigger this if the share root is empty and the mapped user has write and search permission on its parent directory. Return -EINVAL for empty pathnames when for_remove is set, before resolving the share path or acquiring removal resources. Ordinary lookups continue to accept empty pathnames for opening the share root. Fixes: 74d7970febf7 ("ksmbd: fix racy issue from using ->d_parent and ->d_name") Cc: stable@vger.kernel.org Reported-by: Zachariah Mithani (AploSec) Signed-off-by: Namjae Jeon [ sashal: Replaced for_remove with the existing do_lock parameter. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 38cddb9f7c9102f23652d198748c658072cf0df5 Author: Ian Bridges Date: Tue Nov 3 10:29:53 2026 -0500 ksmbd: fix session reference leak on compounded SESSION_SETUP [ Upstream commit 03bd8f5279e490e15e0c0f0fa388ffbd2fbacd65 ] A compound request can place SESSION_SETUP after another command. That earlier command leaves a reference to its session in work->sess. smb2_sess_setup() then overwrites work->sess with the session it looks up or creates, and the dispatcher later puts work->sess only once. The inherited reference is never dropped. That leaks the session, together with its setup connection and socket, and every repeat of the compound leaks another. unreferenced object (size 512): __kmalloc_cache_noprof+0x32c/0x3a0 ksmbd_smb2_session_create+0xf6/0x9c0 [ksmbd] smb2_sess_setup+0xda4/0x6280 [ksmbd] handle_ksmbd_work+0x88c/0x1cb0 [ksmbd] Save the inherited session on entry. After the request has been processed, release it once, but only when smb2_sess_setup() has replaced work->sess with its own session or cleared it. Do this after ksmbd_conn_unlock() so the put does not run under srv_mutex. An error path may instead leave the inherited session in work->sess. Keep it there, so the dispatcher still puts it and the error response is still signed or encrypted with it as before. Fixes: 7aa8804c0b67 ("ksmbd: fix user-after-free from session log off") Cc: stable@vger.kernel.org Signed-off-by: Ian Bridges Signed-off-by: Namjae Jeon [ sashal: Omitted the installed = true assignment for the absent rejected-binding signature-check block. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 28db998d396a9b2e6e9ecf69c2a201b8f06df2b2 Author: Aamir Ahmed Date: Tue Nov 3 09:59:19 2026 -0500 ksmbd: deny access for an empty DACL instead of granting the request [ Upstream commit de0cffef897c1c232ed973f89928cd6c93d0b1e3 ] smb_check_perm_dacl() returns the access mask it computes to the SMB2 CREATE handler, which uses it as the granted access for the open. For a security descriptor whose DACL is present but contains no ACEs, the function is supposed to deny access: an empty (non-NULL) DACL grants no access to anyone except the object owner's implicit READ_CONTROL and WRITE_DAC (MS-DTYP 2.4.5). The empty-DACL branch only denies when both - the DACL has no trailing bytes (pdacl_size == sizeof(struct smb_acl)), and - the request contains bits beyond READ_CONTROL / WRITE_DAC. In every other case it takes the shared "goto err_out" with rc still 0, which returns success without modifying *pdaccess, so the caller grants the full requested access. Three problems follow: - The READ_CONTROL / WRITE_DAC carve-out models the owner's implicit rights, but the check runs before is_owner is computed, so those rights are handed to *every* caller, not just the owner. For READ_CONTROL the SMB2 CREATE path does not fall back to inode_permission(), so any user can read the security descriptor of an object whose empty DACL is meant to deny them. - A request of exactly READ_CONTROL and/or WRITE_DAC is granted to any caller. WRITE_DAC lets the handle rewrite the DACL. - A DACL that declares zero ACEs but carries trailing bytes (pdacl_size > sizeof(struct smb_acl)) skips the deny entirely and is granted whatever was requested. On shares where the NT ACL is the authoritative access control -- e.g. "force user" shares, where every client maps to one POSIX identity so POSIX cannot distinguish users -- this is an access-control bypass. Compute is_owner before the empty-DACL branch and deny access from an empty DACL unless the caller is the owner requesting no more than READ_CONTROL / WRITE_DAC. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Aamir Ahmed Signed-off-by: Namjae Jeon [ sashal: added missing ownership declarations and initialization of is_owner using the mount’s ID mapping ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1f1a7cdcc7a9a73b5496a45390fb13b7bf7b088f Author: Mario Peter Date: Tue Nov 3 08:43:18 2026 -0500 driver core: take parent lock in async device attach [ Upstream commit 187a62f99da29b1a55602b0d401a783d8dc86161 ] For device types with need_parent_lock set (only USB interfaces), probe() must run with the parent device locked. A synchronous attach after device_add() gets this from the caller, e.g. usb_set_configuration() holds the udev lock while adding interfaces. __device_attach_async_helper() runs the probe from an async worker instead, where that lock isn't held, and only takes device_lock(dev). With async probing enabled for the hub driver (e.g. driver_async_probe=* or driver_async_probe=hub), this races when a multi-TT hub is configured. For multi-TT hubs, hub_probe() calls usb_set_interface(hdev, 0, 1) to select the TT-per-port altsetting, and usb_set_interface() creates the endpoint devices of the interface a second time: usb_set_configuration() async worker [udev locked] device_add(intf) queues the probe ----------> __device_attach_async_helper() [intf locked, udev not locked] hub_probe() usb_set_interface(hdev, 0, 1) create_intf_ep_devs(intf) create_intf_ep_devs(intf) create_intf_ep_devs() checks and sets intf->ep_devs_created without a lock of its own. If usb_set_configuration() has created ep_81 but not yet set the flag, usb_set_interface() skips removing the endpoint devices of the old altsetting and creates ep_81 again. With a synchronous probe, hub_probe() runs inside device_add() with the udev lock held, and usb_set_configuration() then finds ep_devs_created already set. Single-TT hubs don't call usb_set_interface() from hub_probe() and don't show this warning, but their probe runs without the udev lock as well. On an i.MX8MM board with an onboard USB2514 hub this hit 11 of 100 boots: sysfs: cannot create duplicate filename '.../1-1/1-1:1.0/ep_81' Call trace: sysfs_warn_dup usb_create_ep_devs create_intf_ep_devs usb_set_interface hub_probe usb_probe_interface really_probe __device_attach_async_helper async_run_entry_fn It also shows on v7.3-rc6 in QEMU, with dummy_hcd and a raw-gadget program emulating a multi-TT hub: re-authorizing the hub in a loop, while a SCHED_FIFO task preempts the writing task at random points for 3 ms, hit the warning in 29 of 6000 iterations. Take the parent lock in __device_attach_async_helper() as well, like __driver_attach_async_helper() does, and move __device_driver_lock/unlock() up for that. With this the warning was gone in 300 boots on the board and in 6000 iterations in QEMU. Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers") Signed-off-by: Mario Peter Cc: stable@vger.kernel.org # 4.2 Cc: Dmitry Torokhov [ johan: switch to async_schedule_dev_nocall() to avoid deadlock if async_schedule_dev() runs synchronously when parent lock is held ] Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20261014133109.1392265-4-johan@kernel.org [ Fold the nested conditions into a single if statement; correct commit message to mention "device types" rather than "buses" for "need_parent_lock". - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2af51c1d68e6ff96d26e4e5e9cf62bf253149442 Author: Vincent Liu Date: Tue Nov 3 08:43:17 2026 -0500 driver core: Check drivers_autoprobe for all added devices [ Upstream commit ea34511aaf755349999a1067b2984a541bee1492 ] When a device is hot-plugged, the drivers_autoprobe sysfs attribute is not checked (at least for PCI devices). This means that drivers_autoprobe is not working as intended, e.g. hot-plugged PCI devices will still be autoprobed and bound to drivers even with drivers_autoprobe disabled. The problem likely started when device_add() was removed from pci_bus_add_device() in commit 4f535093cf8f ("PCI: Put pci_dev in device tree as early as possible") which means that the check for drivers_autoprobe which used to happen in bus_probe_device() is no longer present (previously bus_add_device() calls bus_probe_device()). Conveniently, in commit 91703041697c ("PCI: Allow built-in drivers to use async initial probing") device_attach() was replaced with device_initial_probe() which faciliates this change to push the check for drivers_autoprobe into device_initial_probe(). Make sure all devices check drivers_autoprobe by pushing the drivers_autoprobe check into device_initial_probe(). This will only affect devices on the PCI bus for now as device_initial_probe() is only called by pci_bus_add_device() and bus_probe_device(), but bus_probe_device() already checks for autoprobe, so callers of bus_probe_device() should not observe changes on autoprobing. Note also that pushing this check into device_initial_probe() rather than device_attach() makes it only affect automatic probing of drivers (e.g. when a device is hot-plugged), userspace can still choose to manually bind a driver by writing to drivers_probe sysfs attribute, even with autoprobe disabled. Any future callers of device_initial_probe() will respect the drivers_autoprobe sysfs attribute, which is the intended purpose of drivers_autoprobe. Signed-off-by: Vincent Liu Link: https://patch.msgid.link/20251022120740.2476482-1-vincent.liu@nutanix.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 187a62f99da2 ("driver core: take parent lock in async device attach") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4d6e1b44d1fbfa70b045a670b18200dc4824226b Author: Fredric Cover Date: Mon Nov 2 17:15:04 2026 -0500 smb: client: fix early procfs exposure race [ Upstream commit 7b1afb631395c958993cda4631002258ef4151ea ] Currently, init_cifs() calls cifs_proc_init() near the beginning of the function, before INIT_LIST_HEAD, leading to a momentarily uninitialized, but exposed, procfs. If a userspace process reads this empty procfs, iterating over a zeroed list_head leads to a NULL pointer dereference and a kernel oops/panic. For example, if a delay is added between cifs_proc_init() and INIT_LIST_HEAD, and a userspace process is polling /proc/fs/cifs/DebugData, the following oops occurs: BUG: kernel NULL pointer dereference, address: 0000000000000608 Oops: Oops: 0000 [#1] SMP PTI CPU: 0 UID: 0 PID: 3477 Comm: cat Not tainted 7.3.0-02212-g4df4d2a577db-dirty #6 PREEMPT(lazy) RIP: 0010:cifs_debug_data_proc_show+0x103/0xd80 [cifs] Call Trace: ? seq_read_iter+0x86/0x400 ? seq_read_iter+0x86/0x400 seq_read_iter+0x183/0x400 proc_reg_read_iter+0x62/0x90 copy_splice_read+0x215/0x310 splice_file_to_pipe+0xec/0x1c0 do_splice+0x4b8/0x780 __se_sys_splice+0x18f/0x250 do_syscall_64+0x109/0x330 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by moving cifs_proc_init() down in init_cifs(), ensuring it runs only after all internal lists, locks, counters, and workqueues are fully ready, but before registering the filesystem. Update the error cleanup ladder and exit_cifs() to maintain proper LIFO order. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Fredric Cover Cc: stable@vger.kernel.org Signed-off-by: Paulo Alcantara [ sashal: Adjusted init_cifs() context because smb1_init_maperror() and smb2_init_maperror() are absent. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ee793cc8dcd58ed9afa0a69a84d66df4f8eacd88 Author: Zikang Gao <2715417602@qq.com> Date: Mon Nov 2 17:14:57 2026 -0500 smb: client: do not pass a NULL buf to is_oplock_break() [ Upstream commit 2225ab306575e424b3dad2ee1be2521c89249d15 ] receive_encrypted_read() sets *num_mids = 1 and never writes the caller's bufs[]. Offload returns -1 with *num_mids = 0, so the demultiplex thread skips the frame. The inline decrypt path returns 0 even when smb2_find_mid() fails. cifs_demultiplex_thread() then treats mids[i] == NULL as an oplock break and calls is_oplock_break(bufs[i], server) with bufs[i] still NULL. smb2_is_valid_oplock_break() reads hdr.Command at offset 12 and oopses. A large encrypted READ whose MessageId does not match is enough to panic cifsd. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 100 Comm: cifsd RIP: smb2_is_valid_oplock_break+0xc8/0x2270 [cifs] cifs_demultiplex_thread Kernel panic - not syncing: Fatal exception Return -1 when inline decrypt finds no mid, and skip is_oplock_break() plus the unknown-frame dump when bufs[i] is NULL. receive_encrypted_standard() already assigns bufs[*num_mids]. Fixes: c42a6abe3012 ("CIFS: Add capability to decrypt big read responses") Assisted-by: LLM Signed-off-by: Zikang Gao <2715417602@qq.com> Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Cc: stable@vger.kernel.org [ sashal: Adjusted context to retain the existing one-argument mid_execute_callback() and release_mid() calls. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0eec7b84e83ff90b81bc302a49f463728f2e9572 Author: Cheng Yongkang Date: Wed Nov 4 11:44:12 2026 -0700 io_uring/net: fix multishot recv length limit accounting Commit 3e3aebb7570ccdde5cc49c9bfc8fd3a436b71b0c upstream. io_recv_finish() debits sr->mshot_total_len with min_t(int, sel->val, sr->mshot_total_len). sel->val is the cumulative byte count of the request: on a bundle retry the receive path adds sr->done_io back to the return value, and the bundle branch in io_recv_finish() recovers the new bytes with this_ret = sel->val - sr->done_io. The debit therefore uses the wrong value after a bundle retry, and the int cast truncates a limit above INT_MAX. For an IORING_OP_RECV multishot request with optlen above INT_MAX, the limit becomes negative when cast to int, so the first completion debits the entire limit and ends the multishot with IORING_RECV_MSHOT_DONE while the socket still holds data that covers the limit. With 120 bytes queued, a 64-byte buffer and optlen 0x80000000, the first 64-byte CQE lacks IORING_CQE_F_MORE and 56 bytes remain unread; the same setup with optlen 0x7fffffff posts 64 and 56 bytes with F_MORE. After a bundle retry, the bytes already debited for the previous attempts are debited again, so the limit is exhausted early. With 1400 bytes queued, optlen 1000 and buffers of 600, 100, 100, 50, 50 and 200 bytes, the first attempt delivers 700 bytes and retries; the second delivers 200 more, but the debit accounts for 900 and finishes the request with a terminal 900-byte CQE while 500 bytes remain unread. The limit could have been reached. Debit only the bytes received by this invocation, sel->val - sr->done_io, and compare as unsigned so a limit above INT_MAX is accounted correctly. Non-bundle multishot requests keep sr->done_io at zero, so their accounting is unchanged. Fixes: 0ebc9a7ecf6a ("io_uring/net: Support multishot receive len cap") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Cheng Yongkang Link: https://patch.msgid.link/179328314078.648427.10086632105828535293@gmail.com [axboe: fix-up near-by incorrect comment while in there] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b5e22247346f6bd20b3bf7250c000865e323bead Author: Cheng Yongkang Date: Wed Nov 4 11:44:11 2026 -0700 io_uring/timeout: count cancelled timeouts in cq_timeouts Commit 1c8b49851543f41fc8bb18bcd1f15cc93d14b530 upstream. io_timeout_cancel() posts the cancelled timeout's -ECANCELED CQE without advancing ctx->cq_timeouts. io_timeout_fn() and io_kill_timeout() advance it for every timeout CQE they post, and io_flush_timeouts() computes the number of non-timeout completions as seq = cached_cq_tail - cq_timeouts to compare against each off timeout's target_seq. The cancelled timeout's CQE is therefore counted as a regular completion, so every cancellation makes an already armed off timeout fire one completion early. A ring with a keep-alive timeout of off=4 completes it after two NOPs when one off=100 victim is cancelled through IORING_OP_ASYNC_CANCEL, and before any NOP when two victims are cancelled. The cancel CQE should count, but the cancelled timeouts' -ECANCELED CQEs must not: the expected counts are three and two NOPs respectively. Advance cq_timeouts when io_timeout_extract() succeeds, under timeout_lock and before the -ECANCELED completion is queued, matching io_timeout_fn() and io_kill_timeout(). The -ENOENT and -EALREADY paths post no new timeout CQE and keep their accounting. Both the ASYNC_CANCEL and the TIMEOUT_REMOVE path go through io_timeout_cancel(). Fixes: bfe68a221905 ("io_uring: off timeouts based only on completions") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Cheng Yongkang Link: https://patch.msgid.link/179328314078.648427.13761781546953594668@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0ac8f069a8bd7a507df59c505182065ae720e946 Author: Kyle Zeng Date: Wed Nov 4 11:44:10 2026 -0700 io_uring: defer foreign io-wq enqueues to task_work Commit 3de16279b43dc285ed2222aba06cebdc82fdb28b upstream. An IOPOLL ring without DEFER_TASKRUN can be reaped by a task other than the one that submitted the I/O. If a polled request is marked REQ_F_REISSUE, io_free_batch_list() calls io_queue_iowq() with the original tctx. Ordinary task exit can tear down tctx->io_wq after draining only the tracked requests. The live request pins the task, but not its io-wq, so the foreign task can race io_wq_put_and_exit() and enqueue through a freed or NULL queue. Forward foreign userspace enqueues to the owning task before accessing tctx->io_wq. Use a dedicated task_work callback so reissues still go straight to io-wq, and fail them if task_work is running in cancellation mode. Preserve the existing PF_KTHREAD cancellation path. This also covers the other callers of io_queue_iowq() without changing the worker-owned enqueue path. Signed-off-by: Kyle Zeng Signed-off-by: Jens Axboe [axboe: 6.18 lacks 13b0742fd058, which removed io_req_queue_iowq(). Name the new task_work callback io_queue_iowq_foreign_tw() so it doesn't clash with the existing io_req_queue_iowq_tw()] Signed-off-by: Greg Kroah-Hartman commit 8bfd0b6319261f08b29945228b3377f89211f303 Author: Chris Mason Date: Wed Nov 4 11:44:09 2026 -0700 io_uring/sqpoll: don't wait for the thread to exit Commit 360395e8dbf9d23579f74b84a1af11190813b0f8 upstream. io_sq_thread_stop() wakes the SQPOLL thread and waits for it to exit. The thread belongs to the thread group that created the ring, so a SIGSTOP or the cgroup freezer holds it in get_signal(), and the wake up doesn't change that. io_ring_exit_work() then sleeps in that wait until someone continues or kills the process. iou_exit has 64 slots, so 64 closed SQPOLL rings of a stopped process keep every other ring from being freed, for everyone. Don't wait. Set the stop bit, wake the thread, and let it exit when it gets to run again. The sqd can now outlive its last ring, so give it a second refcount with one reference for the rings and one for the thread, and free it with the last one. The thread can't reach a freed ring, rings leave ctx_list before dropping their reference, and the io-wq hash is refcounted. Fixes: 16efa4fce3b7 ("io_uring: allow IO worker threads to be frozen") Signed-off-by: Chris Mason Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9063d0bcba9598ad87d24a892d9b5ef074b95f70 Author: Chris Mason Date: Wed Nov 4 11:44:08 2026 -0700 io_uring: free XArray nodes left by a failed store Commit 51bab09b7ca1a9a6dd9303a3b7ee346f8128c963 upstream. A failed xa_store() can leave nodes without entries in the tree, and erasing every entry doesn't free those. An XArray needs xa_destroy() before it goes away, even an empty one. That was dropped for tctx->xa in commit ca6484cd308a ("io_uring: no need to call xa_destroy() on empty xarray") over a lockdep report from freeing the tctx in softirq context, and ctx->personalities never had it. Now that the nodes are charged, a store can fail at memory.max and the leaked nodes stay charged. Call xa_destroy() in io_uring_clean_tctx(), which the task runs itself in process context before the tctx is freed, in the error path of __io_uring_add_tctx_node(), and for ctx->personalities in io_ring_ctx_free(). Fixes: ca6484cd308a ("io_uring: no need to call xa_destroy() on empty xarray") Signed-off-by: Chris Mason Signed-off-by: Jens Axboe [axboe: 6.18 installs the tctx before adding the node and has no error path that frees it, drop that hunk. There's no ctx->hpage_acct either] Signed-off-by: Greg Kroah-Hartman commit 9089fd4d2ad6e5692b6971035f7460b97d3a5aaf Author: Chris Mason Date: Wed Nov 4 11:44:07 2026 -0700 io_uring: charge tctx nodes and personalities Commit 0b34e7b20a48710b6f53716bf7030920b69fdbdd upstream. The io_tctx_node allocated the first time a task touches a ring, and the XArray nodes behind tctx->xa and ctx->personalities, are plain GFP_KERNEL. tctx->xa is indexed by the ring pointer, so nearly every entry needs nodes of its own, and a task gets one entry per ring it has used. 642 threads on 4000 rings held 2.3GB with 59MB charged against a 64MB memory.max. Allocate the node with GFP_KERNEL_ACCOUNT and set XA_FLAGS_ACCOUNT on both XArrays. Fixes: 0f2122045b94 ("io_uring: don't rely on weak ->files references") Signed-off-by: Chris Mason Signed-off-by: Jens Axboe [axboe: 6.18 has kmalloc() for the node, inline in __io_uring_add_tctx_node()] Signed-off-by: Greg Kroah-Hartman commit 963c6e849b70259e17855214a999808391a32dd3 Author: Chris Mason Date: Wed Nov 4 11:44:06 2026 -0700 io_uring/rsrc: charge buffer arrays and nodes to memcg Commit 075d5837bafc317e796548f721b8fbf7add6821d upstream. The io_mapped_ubuf of a registered buffer has one bio_vec per page, unless the pages coalesce into huge pages. Huge pages only count against RLIMIT_MEMLOCK once per ring, so a buffer that maps the same 2MB folio over and over in a way that defeats coalescing gets a full bvec array per registration while only the one folio counts as locked. 1GB of that registered in 100 slots took several times a 64MB memory.max, with 2.6MB charged. Allocate the io_mapped_ubuf and the io_rsrc_node with GFP_KERNEL_ACCOUNT. An object reused from the ring caches stays charged to whoever allocated it first, same as the io_kiocb cache. Fixes: de2939388be5 ("io_uring: improve registered buffer accounting for huge pages") Signed-off-by: Chris Mason Signed-off-by: Jens Axboe [axboe: 6.18 uses kvmalloc() + struct_size_t() rather than kvmalloc_flex()] Signed-off-by: Greg Kroah-Hartman commit 2b8f16724d51019325d2412c6324cde0850f8085 Author: Josef Bacik Date: Wed Nov 4 11:44:05 2026 -0700 io_uring/io-wq: no new workers once the exit has begun Commit 47c68f925062a6013235d06add85a59f7d91e0fb upstream. io_wq_exit_start() sets IO_WQ_BIT_EXIT, but worker creation task_work queued before that stays queued until io_wq_exit_workers() cancels it. In between the task runs its task_work while canceling requests, and a worker can still get created. That's a problem for exec. begin_new_exec() calls io_uring_task_cancel() after de_thread(), when it's supposedly the only thread left, and io_wq_exit_workers() only waits for ->worker_done, which a worker completes before do_exit(). So the exiting worker is still in the thread group, using the mm, files and sighand, while exec replaces them. Easy to hit with a signal pending when create_io_thread() fails and the retry gets queued right before execve(). Cancel the queued creation task_work as soon as the exit bit is set. Pending work that isn't otherwise canceled now ends with -ECANCELED when the io-wq is destroyed, rather than depending on whether the task happened to run its task_work first. Fixes: 685fe7feedb9 ("io-wq: eliminate the need for a manager thread") Signed-off-by: Josef Bacik [axboe: the barrier is already upstream, see 0e5663856b69, only the cancel is new] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6621b094bc684625d54f80c68ba81bc1f39989de Author: Daan De Meyer Date: Wed Nov 4 11:44:04 2026 -0700 io_uring/net: don't retry a non-blocking connect() that fails with -EAGAIN Commit 71537ed811107c514c0342e98902d489d6d2b7cd upstream. IORING_OP_CONNECT on an O_NONBLOCK AF_UNIX stream socket retries a connect that fails with -EAGAIN because the listener's backlog is full. Polling the client socket doesn't help: an unconnected stream socket reports EPOLLOUT and EPOLLHUP right away, before the backlog drains. So io_uring retries the connect until the apoll retry limit is hit, then punts the request to io-wq. With a full backlog, io_connect() runs 128 times in the submitting task and once more in a new io-wq worker. That worker stays in the task's thread group, so a later unshare(CLONE_NEWUSER) fails with -EINVAL. None of this changes the result. __sys_connect_file() adds the socket's own O_NONBLOCK to every attempt, so the attempt from io-wq fails with -EAGAIN as well. That -EAGAIN becomes the CQE result, and connect(2) returns the same -EAGAIN. Let's complete the request with -EAGAIN right away when the socket has O_NONBLOCK set, like connect(2) does. io_accept() already completes -EAGAIN this way for IORING_ACCEPT_DONTWAIT. -EINPROGRESS still waits for the connection to complete. A blocking socket still ends up in io-wq, where the connect sleeps until the listener accepts. Fixes: f8e85cf255ad ("io_uring: add support for IORING_OP_CONNECT") Signed-off-by: Daan De Meyer Link: https://patch.msgid.link/20261027-b4-io-uring-connect-eagain-v1-1-f4e3aaaa49ee@amutable.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 87160b45abf0ec5beafe312e4a9761ccb596196b Author: Yichong Chen Date: Wed Nov 4 11:44:03 2026 -0700 io_uring/net: keep recvmsg buffer select length within MAX_RW_COUNT Commit 18d3f56eb6e6500a65d81cf265f0fe74fd9ecab6 upstream. io_recvmsg() takes the transfer length from the ring provided buffer when sqe->len is 0, and such a buffer can be up to 4G. min_ret is an int, so 2G or more makes it negative and the (ret < min_ret) block is skipped, and the oversized length reaches the socket layer unchanged: an empty socket then completes with 0 instead of arming poll, and a short read is reported as complete. Clamp the length to MAX_RW_COUNT, as io_recv() does. Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20261023112209.87979-1-chenyichong@uniontech.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4b3c285f9c5ac80bfe985b3b8778c756063e9105 Author: Yichong Chen Date: Wed Nov 4 11:44:02 2026 -0700 io_uring/kbuf: advance head when a pickup empties the buffer ring Commit 8742f4b5a472c347fe568a73468a2d9e4d630b33 upstream. io_ring_buffers_peek() flags the request with REQ_F_BL_EMPTY if the buffers it picked were the last ones available, comparing head to tail. When the loop breaks because max_len was exhausted the buffer was picked, but head is left pointing at it, so the flag isn't set if it was the last buffer. A bundle receive then retries, finds no buffer, and the request, which has received data, is marked as failed on account of the -ENOBUFS. That severs a link, and ends a multishot. Fixes: 35c8711c8fc4 ("io_uring/kbuf: add helpers for getting/peeking multiple buffers") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20261023091711.83481-1-chenyichong@uniontech.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1f5c774488fa2dabe6667cb26888aaea39c4ead6 Author: Stefan Metzmacher Date: Fri Oct 23 19:26:09 2026 +0900 smb: smbdirect: fix buffer length underflow in RDMA transfers commit 7193241a49c958782ba4b8df06da3734d1e317d2 upstream. When a remote buffer descriptor is larger than the remaining local buffer, smbdirect_connection_rdma_xmit() clamps its length and sets buf_len to zero. The common accounting code then subtracts the clamped length from buf_len, causing it to underflow. If another descriptor follows, the loop processes it with a wrapped remaining length and includes memory beyond the local buffer in the RDMA transfer. A client can trigger an out-of-bounds kernel write with an SMB WRITE request, or an out-of-bounds kernel read with an SMB READ request, by supplying multiple RDMA buffer descriptors with an oversized descriptor before the last one. Remove the premature assignment to buf_len. Subtracting the clamped length already consumes the remaining buffer, so the next iteration stops and only descriptors within the local buffer are used to build work requests. Fixes: e628bf939aaf ("ksmbd: reduce descriptor size if remaining bytes is less than request size") Cc: stable@vger.kernel.org Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-33549 Signed-off-by: Stefan Metzmacher Signed-off-by: Namjae Jeon [ metze: in 6.18 the code is smb_direct_rdma_xmit() in fs/smb/server/transport_rdma.c ] Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Greg Kroah-Hartman commit 224e9856b8aab0ae7e6d63335554a9394ed4d2de Author: Amir Goldstein Date: Sat Oct 17 18:43:30 2026 +0200 ovl: fix mount setup failing when override_creds drops CAP_SYS_ADMIN commit 333ad304d4794d6384087ea7fc16e58ab642809b upstream. When a process drops CAP_SYS_ADMIN and calls fsconfig(FSCONFIG_SET_FLAG, "override_creds"), overlayfs saves those restricted credentials in ofs->creator_cred. ovl_fill_super() then wraps the entire mount setup in with_ovl_creds(), switching to those restricted credentials for the duration. Mount setup calls clone_private_mount(), which checks CAP_SYS_ADMIN against current credentials. With restricted credentials active, this check fails with -EPERM even though the task issuing FSCONFIG_CMD_CREATE is fully privileged. Use the mounter's real credentials only for cloning the private layer mounts. Keep all other backing filesystem operations during mount setup under the stashed credentials. Reported-by: Disha Goel Closes: https://lore.kernel.org/linux-unionfs/20260924112858.51392-1-disgoel@linux.ibm.com Fixes: c28f922c9dcee ("clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns") Cc: stable@vger.kernel.org Reviewed-by: Christian Brauner (Amutable) Signed-off-by: Amir Goldstein [backport: 6.18 has no scoped_with_creds(), use scoped_class(override_creds)] Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 1d9706fb79a9499f5a0f7d7f755b6bb9b14cc426 Author: Chris Mason Date: Wed Nov 4 19:45:16 2026 +0100 ovl: do not copy up a dentry that was removed commit f635192ad223d2009ee640b63adf5ce3198aa338 upstream. A change to a removed file through an open descriptor replaces whatever has its old name in the upper layer. Copy up must only create a name in the upper directory, never replace one. After an unlink, an rmdir or a rename over a lower dentry, a dentry that an open file keeps alive still has its old parent and name, but in the upper directory that name is now a whiteout or a new object. ovl_copy_up_workdir() renames the copy over it, which brings back the removed object and destroys whatever took its name. An unprivileged user opened a lower FIFO and unlinked it, root created a file at that name, and fchmod on the old descriptor replaced the file of root with the FIFO. Fix this by looking up the target name of the rename in ovl_copy_up_workdir() with LOOKUP_EXCL, so that copy up fails with -EEXIST if the name is taken, as copy up with O_TMPFILE already does when it links the copy to the name. Fixes: e9be9d5e76e3 ("overlay filesystem") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik [amir: use LOOKUP_EXCL instead of relying on d_unhashed()] Signed-off-by: Amir Goldstein [backport: no start_renaming_dentry() and LOOKUP_EXCL, fail with -EEXIST if the target of ovl_lookup_upper() is positive] Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 0759376aa01168edeec9319f9cc8e5e9b9388c5c Author: Chris Mason Date: Wed Nov 4 19:45:15 2026 +0100 ovl: hold a reference on the parent in readdir commit 16d319e12328acafeafd3eecdf09c46d7fb43452 upstream. Listing a directory on an overlay uses a freed dentry and crashes the kernel when a lookup moves the directory at the same time. Code that can sleep may only use d_parent without a reference while something stops a move of the dentry. ovl_iterate_real(), ovl_need_adjust_d_ino() and ovl_cache_update() use the d_parent of the listed directory and hold only the lock of that directory. When a lookup finds the directory under another parent after a change to a layer, d_splice_alias() moves it without that lock and drops its reference on the old parent. With a delay in ovl_iterate_real(), getdents64 on an overlay directory raced a rename in the lower layer and a lookup that moved its dentry, and after an rmdir of the old parent KASAN reported a use-after-free in security_inode_getattr(). Fix this by using dget_parent() in the three functions. Fixes: b5efccbe0a12 ("ovl: constant d_ino across copy up") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik [amir: fix comments in ovl_need_adjust_d_ino()] Signed-off-by: Amir Goldstein [backport: no ovl_need_adjust_d_ino(), take the parent with dget_parent() in ovl_iterate() and test a local flag] Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 68439a05ed529a8b0350f8c6ff3618ff4a8d972d Author: Chris Mason Date: Wed Nov 4 19:45:14 2026 +0100 ovl: check that the parents of volatile/dirty are dirs commit e34d2ef818e4c7676d8d8e1bf43e6a1ed39efb2a upstream. An unprivileged user crashes the kernel by mounting overlayfs with the volatile option. A dentry that serves as the parent of a lookup must be a directory. ovl_create_volatile_dirty() walks work/incompat/volatile/dirty by name, and ovl_lookup_or_create() returns an existing entry whatever its type. A file or a symlink that another task creates during the mount becomes the parent of the next lookup, which calls a NULL ->lookup. An unprivileged user mounted overlayfs with "volatile" in a user namespace while a second process created a symlink named work/incompat, and the mount task oopsed on a NULL ->lookup call. Fix this by returning -ENOTDIR from ovl_lookup_or_create() when the caller asked for a directory and the existing entry is a non-dir. Fixes: c86243b090bc ("ovl: provide a mount option "volatile"") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik Signed-off-by: Amir Goldstein [backport: no ovl_start_creating_upper(), check the child of ovl_lookup_upper() in ovl_lookup_or_create() instead] Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit ae8c2228af6b7778c10b693bd6c5e103ef9c9451 Author: Jiale Yao Date: Thu Sep 24 22:29:17 2026 +0800 HID: roccat: savu: reject short special reports commit 76c51fdc825a0486f8d88ff896d39acec8f377b4 upstream. The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to a helper which inspects data[0] and, for a special report, reads the complete struct savu_mouse_report_special. A truncated report can therefore cause an out-of-bounds read. Require enough data for the special report before calling the helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 6a2a6390cf09 ("HID: roccat: add support for Roccat Savu") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit c2e90164acb61217f2b9fdda05d83c80657c963c Author: Jiale Yao Date: Thu Sep 24 22:29:16 2026 +0800 HID: roccat: ryos: reject short special reports commit 02f3607d0beb82e76481568bf631235e6a319b47 upstream. The raw event callback runs before HID core validates and zero-pads the report. It reads the report number without checking the received length and passes matching data to roccat_report_event(), which copies a complete struct ryos_report_special. A truncated report can therefore cause an out-of-bounds read and expose adjacent data through the Roccat character device. Require a complete special report before inspecting or forwarding it. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 6f3a19360545 ("HID: roccat: add support for Ryos MK keyboards") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 08a4c26838f185f42cb80e5c50826e57c1e18e88 Author: Jiale Yao Date: Thu Sep 24 22:29:15 2026 +0800 HID: roccat: pyra: reject short button reports commit 493268f459bb6aeeecbc77f2204c11ad74d05213 upstream. The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and read a complete struct pyra_mouse_event_button for button reports. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: cb7cf3da0daa ("HID: roccat: add driver for Roccat Pyra mouse") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 196fff636bf4fd8ca7dcdeb46b17c275d9064766 Author: Jiale Yao Date: Thu Sep 24 22:29:14 2026 +0800 HID: roccat: kovaplus: reject short button reports commit e95917a606f486e46f5136fc1b72190742a091d6 upstream. The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and read a complete struct kovaplus_mouse_report_button for button reports. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 0e70f97f257e ("HID: roccat: Add support for Kova[+] mouse") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 49360ac9b47ff9852eed6ed047c8428b54b2de3a Author: Jiale Yao Date: Thu Sep 24 22:29:13 2026 +0800 HID: roccat: konepure: reject short button reports commit 1590b7c9bea0abe7a5d25dbfe06287c48c238a6f upstream. The raw event callback runs before HID core validates and zero-pads the report. It reads the report number without checking the received length and passes matching data to roccat_report_event(), which copies a complete struct konepure_mouse_report_button. A truncated report can therefore cause an out-of-bounds read and expose adjacent data through the Roccat character device. Require a complete button report before inspecting or forwarding it. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 8936aa31cd5f ("HID: roccat: add support for Roccat Kone Pure gaming mouse") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 6d1f22a55259462618c73284aa1de40c970b419b Author: Jiale Yao Date: Thu Sep 24 22:29:12 2026 +0800 HID: roccat: koneplus: reject short button reports commit d879e17a8b4c572c0b53b4e42a36849484e8f00c upstream. The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and, for a button report, read the complete struct koneplus_mouse_report_button. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 47dbdbffe15b ("HID: roccat: Add support for Roccat Kone[+] v2") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 664627e3be18faa067c9c8f6def684a76791c1f2 Author: Jiale Yao Date: Thu Sep 24 22:29:11 2026 +0800 HID: roccat: isku: reject short button reports commit 93e5f7f6189af76a2b2e2dfe647838a7b9f99d21 upstream. The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and, for a button report, read the complete struct isku_report_button. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: d41c2a7011df ("HID: roccat: Add support for Isku keyboard") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 6ebe75dbb9cf448b867782470ceb42cb2f73e704 Author: Gabor Tanz Date: Mon Oct 12 17:03:57 2026 +0200 HID: quirks: Always poll the Anne Pro 2 with product ID a292 commit cbc13a78a89d087252947d0a51048e576cfcb3ef upstream. The wired Anne Pro 2 identifying as 04d9:a292 stops delivering keyboard input after a period of inactivity. Unplugging and reconnecting the keyboard restores input. Keeping ObinsKit running prevents the problem. A read-only userspace reader that keeps USB HID interface 1 open also prevents it, as does usbhid.quirks=0x04d9:0xa292:0x00000400 without either application running. Commit ca28aff0e1dc ("HID: quirks: Always poll Obins Anne Pro 2 keyboard") added HID_QUIRK_ALWAYS_POLL for product ID a293. The variant identifying as 04d9:a292 exhibits the same symptom. Apply the quirk to this product ID as well. Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Gabor Tanz Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit d4cb80ade5f4c1494957d09d7227a8eb948eb590 Author: Jiale Yao Date: Thu Sep 24 22:44:12 2026 +0800 HID: pxrc: reject short input reports commit 0deb22da5a8c6663c3e071f55fd7d7e3189f5517 upstream. The HID core invokes raw_event callbacks before validating the report length. pxrc_raw_event() reads byte seven and writes bytes one and seven without checking that the report contains those bytes. A one-byte input report reproduced the first invalid access under KASAN: BUG: KASAN: slab-out-of-bounds in pxrc_raw_event+0x161/0x260 Read of size 1 by task hidtrigger/90 Call Trace: pxrc_raw_event+0x161/0x260 kasan_report+0x139/0x170 Require all eight bytes before reading or rewriting the report. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: acc3e34613da ("HID: Add driver for PhoenixRC Flight Controller") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ac0e2a0fbe429e4529e54852264c59c0e3c838b5 Author: Jiale Yao Date: Thu Sep 24 22:44:11 2026 +0800 HID: prodikeys: validate fixed-format MIDI reports commit 0ff37294c41bd925258893310398bc2b45fcd4a7 upstream. The HID core invokes raw_event callbacks before validating the report length. Prodikeys reports 0x01 and 0x04 are passed to handlers that always read bytes one through three, regardless of the supplied size. A truncated report can therefore cause an out-of-bounds read. Require four bytes for the two fixed-format reports. Keep report 0x03 on its existing variable-length path, which derives the number of note pairs from size and only accesses complete pairs. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: 3a370ca1dcf8 ("HID: Prodikeys PC-MIDI HID Driver") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 14acfdfca5151537b623243a6c0e66a2e6fca7de Author: Lorenzo Stoakes (ARM) Date: Sat Sep 26 14:17:01 2026 +0100 HID: picoLCD: check for fb_deferred_io_init() error commit feade898fc958ff355101adf12d5632272e64220 upstream. fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently picolcd_init_framebuffer() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. When the file is subsequently opened, fb_open() will dereference a NULL pointer (calling fb_deferred_io_open()). Fix this by checking for the error. Also correct cleanup ordering - defio is initialised after the sysfs file, so cleanup defio first. Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit ee55408b95bdc28f1bd1eb4591185838037a1f98 Author: Jiale Yao Date: Thu Sep 24 22:44:10 2026 +0800 HID: mcp2221: validate response report length commit 1ae40774d386b7a51e4799200106429a7e14e8ec upstream. MCP2221 responses are 64-byte reports, but mcp2221_raw_event() currently accepts any report of at least four bytes. Several response handlers read far beyond that minimum. In particular, the I2C status response reads offset 20 and copies ADC samples starting at offset 50. Other GPIO, SRAM, and flash response handlers also access fixed offsets beyond byte three. The HID core invokes raw_event callbacks before validating the report length, so a truncated response can cause an out-of-bounds read. Require a complete protocol report before dispatching any response handler. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 47f50fbfd664ceede78f502950eb5638b537ed74 Author: Jiale Yao Date: Thu Sep 24 22:44:09 2026 +0800 HID: mcp2200: validate READ_ALL response length commit 26ce0e6bf0b27fc6a2f490f38555dfd0a27c9605 upstream. The HID core invokes raw_event callbacks before validating the report length. mcp2200_raw_event() casts a READ_ALL response to struct mcp_read_all_resp and reads fields through offset ten without checking that the response contains the structure. A one-byte READ_ALL response reproduced the issue under KASAN: BUG: KASAN: slab-out-of-bounds in mcp2200_raw_event+0x24b/0x3a0 Read of size 1 by task hidtrigger/89 Call Trace: mcp2200_raw_event+0x24b/0x3a0 kasan_report+0x139/0x170 Reject an incomplete READ_ALL response with a protocol error before reading its fields. The common completion path then wakes the command waiter with the error instead of leaving it to time out. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: 740329d7120f ("HID: mcp2200: added driver for GPIOs of MCP2200") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit bf3e9e06e850c78673b373f3a6bb4baaf2949d66 Author: Jiale Yao Date: Thu Sep 24 22:44:08 2026 +0800 HID: logitech-dj: validate unnumbered keyboard reports commit c2deafcb4c8227771f768d77ed3c0a489250e9b2 upstream. The HID core invokes raw_event callbacks before validating the report length. For an unnumbered keyboard report, logi_dj_raw_event() uses the second byte as temporary storage while prepending a report ID. A one-byte report therefore makes both the initial write and the later restoration access data beyond the received report. Reject unnumbered keyboard reports that do not provide the temporary byte. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 6a0a7d6418261e99e74ba7089b08889f1a93eafd Author: Jiale Yao Date: Thu Sep 24 22:44:07 2026 +0800 HID: elo: reject short touchscreen reports commit 1cb92fcb2ac344d78737e3c5cb7b061dfb2850b1 upstream. The HID core invokes raw_event callbacks before validating the report length. elo_raw_event() only checks the first-byte packet marker before elo_process_data() reads coordinates, flags, and pressure through offset seven. A truncated packet beginning with the expected marker can therefore cause an out-of-bounds read. Require the complete eight-byte SmartSet packet before parsing it. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: d23efc19478a ("HID: add driver for ELO 4000/4500") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 94d0e789d8b0d2ea8e25ed5ff2fe2648e11f2297 Author: Jiale Yao Date: Thu Sep 24 22:44:06 2026 +0800 HID: cp2112: validate response report lengths commit fc54e71a063c0dcc4bceba6d0f71805a9b84082d upstream. The HID core invokes raw_event callbacks before validating the report length. cp2112_raw_event() reads every field of a transfer status response without checking size. For a data response, it reads the length at offset two and copies that many bytes from offset three, again without ensuring that the input report contains them. Require a complete transfer status structure. For data responses, first require the header and then ensure the clamped payload length fits in the received report before copying it. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: e932d8178667 ("HID: add hid-cp2112 driver") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit d618e93e9cf5611867b3a7546e09bedff4b65139 Author: Jiale Yao Date: Thu Sep 24 22:44:05 2026 +0800 HID: cougar: reject short special-key reports commit c6c0df8a4b73a0d563c5e64de640ef5ff525fc82 upstream. The HID core invokes raw_event callbacks before validating the report length. cougar_raw_event() reads the key code and action from offsets one and two without checking that those bytes are present. A short report on the special interface can therefore cause an out-of-bounds read. Consume reports that do not contain the action field before accessing the fixed offsets, consistent with the callback's handling of other reports on the special interface. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: b8e759b8f6da ("HID: cougar: Add support for the Cougar 500k Gaming Keyboard") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 076bea989f998f4d5a62d74de2f04f6f5b94b3f3 Author: Alan Stern Date: Sat Oct 10 13:44:15 2026 -0400 HID: core: Fix out-of-bounds left shift by 32 in s32ton() commit 5fe63b415c636c7f4f6848a8e53bdd4bbf0c300d upstream. Syzbot reported an out-of-bounds shift (32-bit integer shifted left by 32) in the s32ton() routine in the HID core. This routine converts a signed 32-bit integer to a signed n-bit integer, and it caps the value of n at 32. But when n == 32 there's no need to do anything; it can simply return the input value. This will avoid calculating (1 << n) when n is 32, which was the cause of the invalid shift. Signed-off-by: Alan Stern Fixes: 69c02ffde6ed ("HID: core: clamp report_size in s32ton() to avoid undefined shift") Reported-by: syzbot+25a1d2907885b2182275@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/6ac9cbd8.a150a118.27e199.0025.GAE@google.com/ Tested-by: syzbot+25a1d2907885b2182275@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Link: https://patch.msgid.link/dfa0aa1c-e55e-4316-8307-f72a07383634@rowland.harvard.edu Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 5652b50db002f6cd72c86886aaa1372a429375b9 Author: Basavaraj Natikar Date: Tue Oct 6 16:07:54 2026 +0530 HID: amd_sfh: Use report type from request node commit 85f1bea97f1909f81577cfcf3e4db9017e7f5337 upstream. Use report type from request node while sending feature and input reports to HID core. The cli_data report type array is never assigned and feature reports are sent as input reports. Fixes: 1434f9fc0e47 ("SFH: Create HID report to Enable support of AMD sensor fusion Hub (SFH)") Closes: https://github.com/ublue-os/bazzite/issues/5796 Cc: stable@vger.kernel.org Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 292e9c446a7c32b295392811ae97d0aeb0755c11 Author: Basavaraj Natikar Date: Tue Oct 6 16:07:53 2026 +0530 HID: amd_sfh: Remove unsupported motion-state field from accelerometer report commit 6ff86122906357687735dd379c6279e3b2fa26af upstream. The accelerometer HID report descriptor declares a trailing motion-state field (usage 0x0451), but the Sensor Fusion Hub never reports this data, so each accelerometer input report is one byte shorter than the descriptor advertises. This was previously harmless because hid-core zero-padded short reports. Since commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") such reports are rejected instead: hid-sensor-hub 0020:1022:0001.0003: Event data for report 1 was too short (15 vs 14) As a result the accelerometer input events are dropped and screen auto-rotation stops working on AMD SFH systems. Remove the motion-state field from the accelerometer report descriptor and drop the unused in_accel_shake_detection member, so the descriptor matches the report actually provided by the hardware. Fixes: 1434f9fc0e47 ("SFH: Create HID report to Enable support of AMD sensor fusion Hub (SFH)") Reported-by: Andrej Scek Closes: https://lore.kernel.org/linux-input/CADrS85612m-Hh-G4BJmOhy-y6r3Ni3kD8_GM-2QRBeWWEEZWuA@mail.gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 30e55a93cdc6b24e9cef7b975376b925098aad2b Author: Jiale Yao Date: Thu Sep 24 22:44:13 2026 +0800 HID: zydacron: validate key report length commit 9932c9af185f8586e883d44ca562c12f4487c762 upstream. The HID core invokes raw_event callbacks before validating the report length. zc_raw_event() verifies the report ID in byte zero and then reads the key code from byte one for report IDs 0x02 and 0x03 without checking that the second byte is present. A one-byte report reproduced the issue under KASAN: BUG: KASAN: slab-out-of-bounds in zc_raw_event+0x54c/0x580 Read of size 1 by task hidtrigger/93 Call Trace: zc_raw_event+0x54c/0x580 __hid_input_report+0x2ef/0x3a0 inject_store+0x479/0x490 [faketrans] Require both the report ID and key code before processing the report. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw_event length validation to hid-asus. Fixes: d0742abaa1c3 ("HID: add omitted hid-zydacron.c file") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit d4de3f8bd52854572bfc03b89ab236b94bf8a14c Author: Amit Machhiwal Date: Mon Sep 28 17:58:37 2026 +0530 KVM: PPC: Fix get_d_signext() 12-bit displacement for paired-single D-form commit 31895b0ff96778b524c74b43a108090581271603 upstream. get_d_signext() has two compounding bugs since its introduction in 2010: 1. The extraction mask 0x8FF silently drops bits 8-10 of the 12-bit D field (PPC ISA bits 21-23), corrupting any displacement that has any of those bits set. 2. The sign-magnitude idiom "-(d & 0x7ff)" is wrong for two's-complement: for D=0xFFC (encoding of -4) it returns -252 instead of -4. Together these errors produce a wrong effective address for psq_l, psq_lu, psq_st, and psq_stu whenever the displacement is negative or is a positive value >= 0x100 with bits 8-10 set — essentially any real-world paired- single stack-relative access. The D field occupies the bottom 12 bits of the instruction word (confirmed by the adjacent W and I extractions via inst_get_field(inst,16,16) and inst_get_field(inst,17,19)). Replace the open-coded logic with the standard sign_extend32(inst & 0xfff, 11), which correctly performs two's-complement sign extension from 12 bits to 32 bits. Fixes: 831317b605e7 ("KVM: PPC: Implement Paired Single emulation") Cc: stable@vger.kernel.org Signed-off-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260928122837.8782-4-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 7a02dfbd2f4a7dec468221d639f740a51d4483e1 Author: Amit Machhiwal Date: Mon Sep 28 17:58:36 2026 +0530 KVM: PPC: Book3S HV: Add preempt_disable() around virtual-mode HPTE bit-lock users commit abbbe5ff83e7c9ed3a4d61b73011f1df7bf87907 upstream. kvmppc_hv_find_lock_hpte() requires virtual-mode callers to run with preemption disabled, because it can return with HPTE_V_HVLOCK still held until the caller later unlocks the HPTE. Existing virtual-mode callers in book3s_64_mmu_hv.c already follow that rule. Two virtual-mode call paths do not: 1. kvmppc_handle_exit_hv() calls kvmppc_hpte_hv_fault() for hash-mode data-side and instruction-side faults after guest exit, with preemption already enabled. kvmppc_hpte_hv_fault() calls kvmppc_hv_find_lock_hpte() directly. 2. kvmppc_pseries_do_hcall() executes virtual-mode handlers for HPT hcalls via kvmppc_pseries_do_hpt_hcall() with preemption enabled. The handlers for H_ENTER, H_REMOVE, H_READ, H_CLEAR_MOD, H_CLEAR_REF, H_PROTECT, and H_BULK_REMOVE spin on try_lock_hpte() or lock_rmap(), and H_ENTER also reaches kvmppc_do_h_enter(), which uses arch_spin_lock() on kvm->mmu_lock. That raw lock choice is intentional because kvmppc_do_h_enter() is also used by real-mode callers, so the correct fix is to establish the proper preemption context at the virtual-mode caller boundary. If a vCPU thread is preempted while holding HPTE_V_HVLOCK, any other thread on the same CPU trying to acquire the same bit-lock can spin indefinitely. The same applies to lock_rmap() users and to the H_ENTER path while holding the raw mmu_lock. Fix this by adding preempt_disable()/preempt_enable() pairs around the two kvmppc_hpte_hv_fault() call sites in kvmppc_handle_exit_hv(), and around the kvmppc_pseries_do_hpt_hcall() invocation in kvmppc_pseries_do_hcall(). Targeting only the HPT hcall helper avoids wrapping non-HPT hcalls (such as H_RTAS, H_CONFER, H_REGISTER_VPA) that perform page faults, blocking memory allocations, or context switches. Fixes: 6165d5dd99db ("KVM: PPC: Book3S HV: add virtual mode handlers for HPT hcalls and page faults") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Amit Machhiwal Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260928122837.8782-3-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 216729d9780df7d4cf91435af38c8f65d51ce93d Author: Xiaoyao Li Date: Wed Aug 19 17:48:55 2026 +0800 KVM: TDX: Enable Notify VM exit commit d93395058c1951bb657c8895dd1fc0f22263f1cc upstream. Enable Notify VM exit functionality for TDX guests. Notify VM exit is an existing feature supported by KVM. Userspace can enable Notify VM exit through KVM_CAP_X86_NOTIFY_VMEXIT when it's reported as supported. However, KVM reports the support of this CAP just based on the hardware capability but doesn't differentiate between VMX and TDX. This leads to the issue that userspace can enable this cap for TDX guests without getting an error, but the feature is not actually enabled because KVM doesn't call the TDX module API to program the relevant TD VMCS fields. Enable Notify VM exit for TDX guests by: - Invoking TDX module API calls to set NOTIFY_VM_EXITING and Notify Window in TD VMCS. It's done in tdx_vcpu_init() where other TD VMCS bits are set. Since TDX vCPU cannot be reset, it only needs to be configured once when initializing the TDX vCPU. - Adding corresponding exit handler for TDX Notify VM Exit. Notify VM exit can happen when executing the IRET instruction. If the IRET unblocks the NMI blocking state, bit 12 of the exit qualification is set. In this case, the VMM needs to restore the "blocked by NMI" state when it decides to re-enter the guest. For TDX, KVM cannot manage the GUEST_INTERRUPTIBILITY_INFO and it's TDX module's responsibility to handle it. Extract the common part without NMI blocking handling into a helper in common.h so that it can be shared between VMX and TDX. Note, KVM uses "pre-production" terminology for the feature formally called Notify VM-Exit. All public versions of the SDM refer to the feature as Instruction Timeout. This will be remedied in the near future, for now, use KVM's terminology for consistency. Note, #2, there is no enumeration bit for Notify VM exit by TDX module because all TDX modules support it, and allow to set the corresponding TD VMCS fields as long as the hardware supports the feature. Fixes: 161d34609f9b ("KVM: TDX: Make TDX VM type supported") Cc: stable@vger.kernel.org Signed-off-by: Xiaoyao Li Reviewed-by: Rick Edgecombe Reviewed-by: Binbin Wu Link: https://patch.msgid.link/20260819094903.3060020-2-xiaoyao.li@intel.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit c16bdb1a49985f3fe55e35518910d37f1f33b8b3 Author: Xiaoyao Li Date: Wed Aug 19 17:48:56 2026 +0800 KVM: TDX: Check if there is valid exit infos based on vp_enter_ret commit 0966c881ea13be5ec89820c185de4d55568e80ed upstream. Check if there is valid exit info based on vp_enter_ret instead of relying on the clobbered Exit Reason, in tdx_get_exit_info(). Current KVM uses "Exit Reason is not equal to the synthesized invalid Exit Reason, -1u," as the condition to identify there is a real TD Exit and valid exit infos. However, there is one issue with this approach: KVM updates the Exit Reason to the synthesized invalid Exit Reason for real EPT MISCONFIG as well. This is a false positive for real EPT MISCONFIG, which has valid exit infos. Though the issue can be addressed by changing the handling for real EPT MISCONFIG to not update the Exit Reason to the synthesized one, relying on the clobbered Exit Reason itself is brittle. Instead, check vp_enter_ret directly to identify if it is a valid Exit Reason. Fixes: da407fe45908 ("KVM: TDX: Handle EPT violation/misconfig exit") Cc: stable@vger.kernel.org Suggested-by: Sean Christopherson Signed-off-by: Xiaoyao Li Reviewed-by: Binbin Wu Link: https://patch.msgid.link/20260819094903.3060020-3-xiaoyao.li@intel.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit ab15e4093e2aff170ea2087ab994f64530a13cba Author: Sean Christopherson Date: Wed Aug 26 11:44:49 2026 -0700 KVM: x86: Zero reserved synic flags when delivering message to avoid stack leak commit 2616f497506a772db53e7bb1024cde50b4c165e0 upstream. Ensure all reserved flags are zeroed when setting the msg_pending flag as part of SynIC message delivery, as setting only msg_pending can leak seven bits of kernel stack data to the guest. E.g. gcc typically uses a bitwise-OR to set the msg_pending flag, without initializing the on-stack variable. Precisely zero the flags, e.g. as opposed to zeroing the entire structure, to make it somewhat more obvious that the flags *need* to be zeroed. E.g. it would be quite easy to misread the initial read of guest memory and think that zeroing the entire structure is completely superfluous. Fixes: 3a0e7731724f ("x86: kvm: hyperv: simplify SynIC message delivery") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Reviewed-by: Vitaly Kuznetsov Link: https://patch.msgid.link/20260826184449.814130-1-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit ec9df57c8e00f189d58d927cc9a1f49592f687af Author: Chengfeng Ye Date: Wed Aug 26 02:39:24 2026 +0800 KVM: x86: Take SRCU in kvm_zap_gfn_range() commit b59a87c1ba3c347e8aec5f932eb7abf13064fd62 upstream. kvm_zap_gfn_range() walks memslots and rmaps and may drop mmu_lock to reschedule. Callers that do not already hold kvm->srcu (or slots_lock) can race with memslot deletion: synchronize_srcu_expedited() does not wait, kvm_free_memslot() frees the old slot and its rmap, and the zap resumes on freed memory. The VFIO noncoherent-DMA path hits this by zapping the entire GPA space without SRCU. KASAN reported: BUG: KASAN: vmalloc-out-of-bounds in slot_rmap_walk_next+0x82/0x1c0 Read of size 8 at addr ffffc900005c1008 Call Trace: slot_rmap_walk_next+0x82/0x1c0 __kvm_rmap_zap_gfn_range+0x17a/0x280 kvm_zap_gfn_range+0x2a6/0x6a0 kvm_vfio_set_attr+0x576/0x770 kvm_device_ioctl+0x1ff/0x3b0 Take SRCU inside kvm_zap_gfn_range() so every caller is covered. Nesting with an existing kvm->srcu critical section is fine; the helper uses a local index. Drop the now-redundant SRCU pair from __kvm_set_or_clear_apicv_inhibit(). Fixes: 362ff6dca541 ("KVM: x86/mmu: Zap KVM TDP when noncoherent DMA assignment starts/stops") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Reviewed-by: Kai Huang Link: https://patch.msgid.link/20260825183924.237727-1-nicoyip.dev@gmail.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit a92a07205e010029796b35924655aebb903b2e7c Author: Loc Nguyen Date: Fri Oct 2 05:42:54 2026 +0000 KVM: x86: Request event processing for exception VM-Exits commit 88b23a2e8286b7016c3b58dc10093cf28c22aa3d upstream. Request event processing whenever kvm_queue_exception_vmexit() queues an exception VM-Exit. Most callers reach the helper through kvm_multiple_exception(), which already sets KVM_REQ_EVENT, but nested asynchronous page faults call it directly. Without another event request, vcpu_enter_guest() skips kvm_check_and_inject_events() and re-enters L2. A subsequent VM-Exit can clear the pending exception while reconstructing vectoring state, losing the synthetic #PF VM-Exit. The APF reason remains PAGE_NOT_PRESENT and a later regular #PF can consume the stale value. Setting KVM_REQ_EVENT in the common helper ensures that L1 receives the queued VM-Exit before KVM re-enters L2. Fixes: 7709aba8f716 ("KVM: x86: Morph pending exceptions to pending VM-Exits at queue time") Cc: stable@vger.kernel.org Signed-off-by: Loc Nguyen Link: https://patch.msgid.link/20261002053723.3275202-2-loc@ryzome.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit a58917a271cb48ece05208111f9e0ea8891316b0 Author: Sean Christopherson Date: Wed Sep 30 12:36:23 2026 -0700 KVM: x86: Preserve DR6.BLD (Bus Lock Detect) when delivering #DB payload commit 719a1d58bf43edd03b271df90b67c58c1e9a7da4 upstream. Preserve Bus Lock Detect if it isn't present in the payload. Unlike RTM, which is explicitly modified on every #DB, DR6.BLD is modified if and only if the #DB is due to a (coincident) Bus Lock Detect. Per Intel's SDM: Other debug exceptions do not modify this bit. And AMD's APM All other #DB exceptions leave DR6[BLD] unmodified, Restore the explicit RTM handling that was clobbered by commit 9a3ecd5e2aa1 ("KVM: X86: Rename DR6_INIT to DR6_ACTIVE_LOW"), as the semantics of any given bit are feature specific, i.e. are obviously not consistent for active-high versus active-low. In other words, while the bug was technically introduced when support for Bus Lock Detect was added, it's really that attempt to genericize handling of active-low bits that set KVM up to fail. Fixes: e8ea85fb280e ("KVM: X86: Add support for the emulation of DR6_BUS_LOCK bit") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930193634.3415089-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 8239d357a9373f985d5921e3dc12c137d130a283 Author: Keqiang Duan Date: Thu Aug 20 20:35:12 2026 +0800 KVM: x86: Clear hardware HLT state when userspace makes a vCPU not-halted commit 883719f57f5d3898637b130d6db4742471cad618 upstream. Force a vCPU out of its hardware-tracked halted state when userspace puts the vCPU into any state other than HALTED via KVM_SET_MP_STATE, i.e. clear VMCS.GUEST_ACTIVITY_STATE if it says the vCPU is halted. Add an optional kvm_x86_ops hook to do the clearing, as SVM has no equivalent VMCB field. When HLT-exiting is disabled for a VM (KVM_CAP_X86_DISABLE_EXITS with KVM_X86_DISABLE_EXITS_HLT, e.g. QEMU's "-overcommit cpu-pm=on"), a guest HLT halts the physical CPU instead of exiting to KVM, and hardware saves GUEST_ACTIVITY_STATE=HLT into the VMCS on the next VM-Exit. That field is sticky: it survives VM-Exit/VM-Enter and is only cleared by vmx_clear_hlt() on event injection, or by vmx_vcpu_reset() on INIT / vCPU creation. Nothing clears it on a userspace-driven state change. KVM_SET_REGS only writes the software register cache and KVM_SET_MP_STATE only writes vcpu->arch.mp_state; kvm_vcpu_running() likewise consults software state only. A VMM that emulates a machine reset therefore ends up with a vCPU that KVM happily VM-Enters while hardware refuses to fetch instructions. Reproduce with a Linux guest by triggering a panic/kdump on a non-boot vCPU: nmi_shootdown_cpus() parks the other vCPUs -- including vCPU0 -- in crash_nmi_callback(), which does local_irq_disable() followed by a bare HLT. The capture kernel then resets the machine via port 0xCF9. QEMU rewrites RIP to 0xfff0 and sets mp_state to RUNNABLE, but vCPU0's GUEST_ACTIVITY_STATE is still HLT, so the BSP never executes the reset vector, never sends SIPIs, and the entire VM hangs at "reboot: machine restart" forever. Only destroying and recreating the VM recovers it. Key off "not HALTED" rather than "is RUNNABLE" as HALTED is the only target state for which retaining the hardware halted state is meaningful; every other transition either can't be reached on VMX, e.g. AP_RESET_HOLD, or goes through vmx_vcpu_reset(), which stuffs GUEST_ACTIVITY_ACTIVE anyways. This also captures the intent more directly: KVM only ever drops the hardware halted state, it never installs it. Hook KVM_SET_MP_STATE rather than the VM-Enter path so that the clearing is driven by an explicit userspace declaration, and so that no work is added to vmx_vcpu_run(). Gate the call on kvm_hlt_in_guest() even though vmx_clear_hlt() checks it as well, as the check is cheap and makes it obvious in common code when the hardware state can exist at all. Do nothing for TDX vCPUs as TDX doesn't support disabling HLT-exiting and KVM cannot access a TD's VMCS, i.e. the VMCS used to run the vCPU can't in HALTED state, and even if it were, KVM can't change it. Fixes: caa057a2cad6 ("KVM: X86: Provide a capability to disable HLT intercepts") Cc: stable@vger.kernel.org Tested-by: Qinguang Chen Signed-off-by: Zhiping Du Signed-off-by: Keqiang Duan Reviewed-by: Chao Gao Link: https://patch.msgid.link/20260820123512.87236-1-duankeqiangcym@gmail.com [sean: drop claim that spurious wakeups are ok, massage changelog] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 46f5df89f55cc454fa2098fe25b5ee4cd53bfa2f Author: David Woodhouse Date: Mon Aug 31 22:26:41 2026 +0100 KVM: x86/xen: Take kvm->srcu in __kvm_xen_has_interrupt() commit aa8ad943f242ef14d136c5440b1178de77466c9e upstream. kvm_gpc_check() checks the cached memslot generation against the current one, which dereferences kvm->memslots and therefore requires kvm->srcu to be held. __kvm_xen_has_interrupt() does not take it. Most callers do happen to hold kvm->srcu, but not all of them: - kvm_emulate_halt() on the VM-Exit path, via kvm_vcpu_has_events() and kvm_cpu_has_extint(). vcpu_enter_guest() drops the vCPU's SRCU lock before entering the guest, so it is not held on the way back out. - kvm_vcpu_block() -> kvm_vcpu_check_block() -> kvm_arch_vcpu_runnable(), which is the case the existing comment in this function describes. On a PROVE_RCU kernel the former produces: WARNING: suspicious RCU usage include/linux/kvm_host.h:1092 suspicious rcu_dereference_check() usage! ... kvm_gpc_check+0x344/0x3e0 [kvm] __kvm_xen_has_interrupt+0x83/0x310 [kvm] kvm_cpu_has_extint+0x1ff/0x370 [kvm] kvm_cpu_has_interrupt+0x16/0x100 [kvm] kvm_vcpu_has_events+0x4ce/0x690 [kvm] kvm_emulate_halt+0x52/0x1f0 [kvm] vmx_vcpu_run+0x988/0x2630 [kvm_intel] Use guard(srcu) so that the three existing early returns don't each need an explicit unlock. SRCU read sections nest, so this is harmless on the paths which already hold it, and srcu_read_lock() does not sleep, so it is also safe in the atomic case which this function already handles. Fixes: 7caf9571563e ("KVM: x86/xen: Use gfn_to_pfn_cache for vcpu_info") Cc: stable@vger.kernel.org Signed-off-by: David Woodhouse Assisted-by: Claude:claude-mythos-5 Reviewed-by: Paul Durrant Link: https://patch.msgid.link/20260831213632.81023-11-dwmw2@infradead.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b7af8dc92af17e107d15360e62470ec862fa3d7f Author: David Woodhouse Date: Mon Aug 31 22:26:37 2026 +0100 KVM: x86/xen: Enforce 4-byte alignment of vcpu_info registration commit eacdb76c5f04956035c5d7f7e1973028f30684a2 upstream. Xen's map_guest_area() enforces that vcpu_info is aligned to sizeof(xen_ulong_t). KVM has no such check, allowing a guest to register vcpu_info at an arbitrary byte alignment. Enforce unconditional 4-byte alignment regardless of the current shinfo mode. This is sufficient because subsequent commits ensure that all locked atomic operations on vcpu_info fields use at most 32-bit accesses. Return -ENXIO on failure, matching Xen's map_guest_area() behaviour for unaligned requests. Originally observed in review of an unrelated patch: https://lore.kernel.org/all/20260604193554.1BA311F00893@smtp.kernel.org/ Cc: stable@vger.kernel.org Fixes: 73e69a86347a ("KVM: x86/xen: register vcpu info") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260604193554.1BA311F00893@smtp.kernel.org Assisted-by: Kiro:claude-opus-4.6-1m Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant Link: https://patch.msgid.link/20260831213632.81023-7-dwmw2@infradead.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit fea3d340226302c89a4a790f6904479818b0ba3a Author: Sean Christopherson Date: Wed Sep 2 16:20:27 2026 -0700 KVM: x86/mmu: Bug the VM if KVM calcs a CPU role with EFER.LMA=1 && CR4.PAE=0 commit 34dacbe7ae93f2d3c26cd0bf3e08200b1fa2c180 upstream. Bug the VM if KVM attempts to construct a CPU role with the should-be- impossible combination of long mode being active without PAE paging being enabled. KVM's MMU construction assumes that EFER.LMA can be set if and only CR4.PAE is set, and will create a completely invalid MMU if that assumption fails. FNAME(walk_addr_generic) already has sanity checks to try and mitigate the fallout, but attempt to catch such bugs earlier, as this is (at least) the second time KVM has had bugs that escaped into FNAME(walk_addr_generic), and it's entirely possible the bad state could cause problems elsewhere. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902232028.2767071-5-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 54afd548602bb96b3fbb0b4b11ccbbfeb5fb46fc Author: Sean Christopherson Date: Wed Sep 2 16:20:26 2026 -0700 KVM: x86/mmu: Bug the VM if KVM attempts to walk more levels than the MMU has commit 115f9405a2ed6d78ee7ad8436bdd638743f6d1d4 upstream. Extend the "EFER.LMA && !CR4.PAE" check, which exists largely to guard against KVM configuring a paging32 MMU with more than 2 levels of paging, with a very explicit check for exactly that: that KVM isn't trying to walk more levels of paging than the MMU template provides. I.e. harden KVM against all bugs that would cause KVM to generates accesses beyond the bounds of guest_walker's arrays, regardless of how KVM ended up with the misconfigured MMU. Note, don't use w->cpu_role.base.level directly as the paging64 template only provides two levels of page tables for PAE paging on 32-bit hosts, and handles the third level by manually emulating the PDPTR access. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260902232028.2767071-4-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 87152138116af6c9fc4e4e682c1ca087e2062323 Author: Xiaoyao Li Date: Wed Aug 19 17:49:00 2026 +0800 KVM: VMX: Preserve negative return value in vmx_handle_exit() with bus lock detected commit cef48693da1e964e9f192bfc16cd0ed287c48337 upstream. Preserve the negative return value from __vmx_handle_exit() when a bus lock is detected, instead of always overwriting it with 0. The purpose of bus_lock_detected handling is to force a userspace exit to inform userspace that a bus lock happened. The negative return value can achieve this purpose, and changing the negative value to 0 fails to return an error to userspace. So, preserve the negative return value. Fixes: fe6b6bc802b4 ("KVM: VMX: Enable bus lock VM exit") Cc: stable@vger.kernel.org Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260805034602.5B2BB1F000E9@smtp.kernel.org/ Signed-off-by: Xiaoyao Li Link: https://patch.msgid.link/20260819094903.3060020-7-xiaoyao.li@intel.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 4ef5e623d2fe29a48a497f96b06ade68034718de Author: Xiaoyao Li Date: Wed Aug 19 17:49:01 2026 +0800 KVM: VMX: Make handle_bus_lock_vmexit() a shared helper commit 326fa2c9b4d3e6cab58c139eb55aaabd7179192e upstream. Move handle_bus_lock_vmexit() from vmx.c to main.c to make it a shared helper so that TDX can use it for Bus Lock VM exit handling as well. Rename it to add vt_ prefix to reflect that it is a helper for both VMX and TDX. Cc: stable@vger.kernel.org Signed-off-by: Xiaoyao Li Reviewed-by: Nikolay Borisov Link: https://patch.msgid.link/20260819094903.3060020-8-xiaoyao.li@intel.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 196450c52f3517e4b7d6199e3841485e11c6f7c8 Author: Sean Christopherson Date: Thu Sep 3 18:03:46 2026 -0700 KVM: VMX: Disallow using to_vmx() in common VT code commit f305fd31f52a8d3ce4d2bf0c88c45bb7a373809c upstream. Poison to_vmx() in main.c and posted_intr.c so that attempting to interpret the vCPU as a VMX vCPU will fail at compile time, as opposed to failing at runtime, or worse corrupting state without outright failing. Note, to_tdx() is buried in tdx.c, i.e. isn't broadly reachable, and so doesn't need the same treatment as to_vmx(). Reviewed-by: Xiaoyao Li Reviewed-by: Kai Huang Tested-by: Kai Huang Reviewed-by: Binbin Wu Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260904010353.3175819-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit a12e105e9753b641624f170b9c0f26d626103880 Author: Sean Christopherson Date: Mon Sep 21 17:13:28 2026 -0700 KVM: Use goto to handle errors during memslot preparation commit 23a205797cec86f391d0be886b9bc741e1262063 upstream. Use a goto to unwind early memslot changes if preparing for a memslot operation fails. This will allow moving the creation of guest_memfd bindings into kvm_set_memslot() without needing to copy+paste the unwind logic. No functional change intended. Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand (Arm) Reviewed-by: Ackerley Tng Link: https://patch.msgid.link/20260922001332.1121266-3-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit a4c2d0a9a9019e71c94ff2b8f56b8f7fc97bd71d Author: Sean Christopherson Date: Wed Sep 2 16:20:25 2026 -0700 KVM: nSVM: Ignore EFER.LMA if EFER.LME=0 when preparing L2 state commit 1c4c84a643b704e473cb171f7b61359ff29b12a4 upstream. Force EFER.LMA=0 if EFER.LME=0 when preparing L2 state for VMRUN, i.e. mimic real hardware's behavior of ignoring EFER.LMA if EFER.LME=0. VMRUN unfortunately allows the nonsensical combination, i.e. doesn't fail, but KVM itself has an invariant EFER.LMA can be set et if and only if EFER.LME is set. Breaking that invariant can lead to a variety of issue, particularly in MMU code that keys off EFER.LMA when determining whether to emulate/virtualization 4/5-level paging versus PAE paging. Cc: stable@vger.kernel.org Cc: Yosry Ahmed Link: https://patch.msgid.link/20260902232028.2767071-3-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 058173bce103b6ac405b2bbf61e29a7f3767348f Author: Yosry Ahmed Date: Thu Sep 3 22:32:58 2026 +0000 KVM: SVM: Trigger new ASID allocation in both VMCBs on pCPU switch commit bf260dc9e7b8bfcd06c1a8e739797b1cf0917c72 upstream. When the pCPU where the VMCB was most recently used is switched, reset the ASID generation in both VMCBs, triggering new ASID allocation for the immediate VMRUN as well as the next VMRUN on the other VMCB. The ASID is shared between vmcb01 and vmcb02, and gets flushed on every nested transition. However, since pCPU tracking is done per VMCB, it is possible for one VMCB to allocate a new ASID when migrated to a new pCPU, and then the other VMCB reuses that ASID on the old pCPU. This can result in the same ASID being used by multiple vCPUs on the old pCPU. Example scenario: - vCPU runs on pCPU A, vmcb01 is active, asid=1. - vCPU migrates to pCPU B, vmcb01 pCPU changes, new asid=2. - Another vCPU runs on pCPU A and allocates asid=2 as well. - vCPU migrates back to pCPU A, and then switches to vmcb02 before it runs again with vmcb01. - No pCPU switch is detected for vmcb02, so VMRUN is done with asid=2. - Two vCPUs end up using asid=2 on the same pCPU. Keep the VMCB dirtying to the active VMCB only. Clean bits are tracked by a pCPU for each VMCB, so do not unnecessarily dirty a VMCB if its pCPU does not change. Additionally, initialize the tracked pCPU for vmcb02 to -1 on nested enablement as hardening, so that a new ASID allocation is always triggered when nested is disabled and re-enabled. No performance regression was noticed when overcommitting L1 vCPUs in L0 (to force rescheduling), pinning L1 <-> L2 vCPUs, and running CPUID in a tight loop bouncing between 2 vCPUs in L2. An alternative (and perhaps more proper) fix would be tracking the ASID per-VMCB instead (e.g. [1]). However, that's a more involved change, and it would result in having different ASIDs for L1 and L2 without actually properly maintaining them. It would probably work because all TLB flushes target the current VMCB, and the other VMCB is always flushed on nested transitions, but the code ends up in an arguably more fragile state. Punt a proper clean fix to an incoming (and overdue) overhaul of SVM's ASID usage [2]. [1] https://lore.kernel.org/lkml/20250205182402.2147495-2-yosry.ahmed@linux.dev [2] https://lore.kernel.org/kvm/20260728003557.1136583-1-yosry@kernel.org Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Signed-off-by: Yosry Ahmed Reviewed-by: Nikunj A Dadhania Link: https://patch.msgid.link/20260903223258.486034-1-yosry@kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit da31978b9ccbe7628885d79a19da5531cea63b5d Author: Mike Rapoport (Microsoft) Date: Thu Aug 13 12:01:28 2026 +0300 x86/mm/pat: Fix effective RW computation in lookup_address_in_pgd_attr() commit ebaf7c9bbb1e16523d7036e7e1225ad2dfcc6482 upstream. lookup_address_in_pgd_attr() accumulates the effective NX and RW bits of the walked page table levels so that verify_rwx() can detect mappings that are both writable and executable. The RW bits are folded into a bool with rw &= pXd_flags(*pXd) & _PAGE_RW; but _PAGE_RW is 0x2. So consider the accumulation line: rw &= pXd_flags(*pXd) & _PAGE_RW; where rw=0x1 and the right side evaluates down to 0x2. It'll end up doing: rw = 0x1 & 0x2 and rw always ends up 0. This way rw becomes false at the first level walked, regardless of the actual permissions, and verify_rwx() treats every mapping as non-writable and never reports a W^X violation. Add double negation to the right side to normalize the _PAGE_RW flag to 0 or 1. Assisted-by: Copilot:claude-opus-4.8 Fixes: ceb647b4b529 ("x86/pat: Introduce lookup_address_in_pgd_attr()") Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Dave Hansen Reviewed-by: Juergen Gross Reviewed-by: Lorenzo Stoakes (ARM) Tested-by: syzbot@syzkaller.appspotmail.com Tested-by: Atish Patra Tested-by: Nikunj A Dadhania Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20260813-cpa-fixes-v2-5-39b4ff90f91d@kernel.org Signed-off-by: Greg Kroah-Hartman commit ff30731bbce188f00a516e900ce585daa81c40a1 Author: Sean Christopherson Date: Thu Oct 22 14:01:32 2026 -0700 x86/cpuid: Mark CPUID function 0x23 as being indexed commit 108775fa28fe04a16f19a828a779689f3d0ea9f0 upstream. Add function 0x23 to the set of CPUID functions that are indexed, as per the SDM and the many sub-leafs defined in leaf_types.h. Closes: https://lore.kernel.org/all/213d614fe73e183a230c8f4e0c8fa1cc3d45df39.camel@intel.com Reported-by: Rick Edgecombe Signed-off-by: Sean Christopherson Signed-off-by: Borislav Petkov (AMD) Tested-by: Rick Edgecombe Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261022210134.612848-2-seanjc@google.com Signed-off-by: Greg Kroah-Hartman commit 7ace4531de8a7d9d2a8f5abb69524d775d20b114 Author: David Howells Date: Tue Oct 6 14:30:01 2026 +0100 rxrpc: Fix return in rxrpc_recvmsg_data() for service calls commit 18a71e111c7505e16c2de91480561fc491f41341 upstream. When rxrpc_recvmsg_data() gets called on a service call that has received all of the request, RXRPC_CALL_RECVMSG_READ_ALL has been set, and this causes rxrpc_recvmsg_data() to jump straight out, indicating the end of the call (ie. rxrpc_kernel_recv_data() returns 1) without waiting for the call to be processed or the reply to be transmitted. rxperf_deliver_to_call() also has to be altered to call rxrpc_kernel_recv_data() to collect the final ACK on a service call as does afs_deliver_to_call(). Fixes: d001648ec7cf ("rxrpc: Don't expose skbs to in-kernel users [ver #2]") Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260914151340.3227501-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Jeffrey Altman cc: Eric Dumazet cc: "David S. Miller" cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261006133011.531806-10-dhowells@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 7ea62525912d575c12928ed60efa6a6f94af7389 Author: David Howells Date: Tue Oct 6 14:30:00 2026 +0100 rxrpc: Fix double IRQ enablement commit 41eb0af096ba8754e584d47e6de42f1e4980ceae upstream. rxrpc_notify_socket() explicitly disables and then re-enables IRQs, but one of its call chains (rxrpc_input_queue_data() -> rxrpc_end_rx_phase() -> rxrpc_call_completed() -> rxrpc_set_call_completion()) has IRQs disabled around it. Fix this by making rxrpc_notify_socket() use irqsave spinlocks. Fixes: a2ea9a907260 ("rxrpc: Use irq-disabling spinlocks between app and I/O thread") Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260812110129.979970-6-dhowells@redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Eric Dumazet cc: "David S. Miller" cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20261006133011.531806-9-dhowells@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit ff518f5f7adc035d10c70216c0475305f58c004c Author: David Howells Date: Tue Oct 6 14:29:57 2026 +0100 afs: Fix afs to abort the rxrpc call on send error commit 3e6af08a571fe2943a006acf3e890f36322602bc upstream. Fix afs_send_empty_reply() and afs_send_simple_reply() to always try to abort the rxrpc call rather than just aborting on -ENOMEM and otherwise abandoning it. If the call is already complete due to network failure or a received abort, this will do nothing. Also make afs_make_call() always abort on send error; again, it does nothing if the rxrpc call is already dead. Fixes: 08e0e7c82eea ("[AF_RXRPC]: Make the in-kernel AFS filesystem use AF_RXRPC.") Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824091645.415423-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Eric Dumazet cc: "David S. Miller" cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261006133011.531806-6-dhowells@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 8b9efc7b27bf7d3f12f5ba3d5d9ab39a76883637 Author: David Howells Date: Tue Oct 6 14:29:56 2026 +0100 rxrpc: Fix lack of short-send handling in rxrpc_kernel_send_data() commit af208f36ae22440cf6011a43cb3064fd525d85b4 upstream. Fix rxrpc_kernel_send_data() to loop around if it detects a short send. David Laight suggested doing it here rather than wrapping all the calls in loops. Further, remove the len argument and use the iterator count instead and return 0 on success, not the amount copied. Note this is also a prerequisite for changing the way rxrpc_send_data() works to return a short send rather than an error if some data was buffered. Fixes: 651350d10f93 ("[AF_RXRPC]: Add an interface to the AF_RXRPC module for the AFS filesystem to use") Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824091645.415423-1-dhowells%40redhat.com Suggested-by: David Laight Signed-off-by: David Howells cc: Marc Dionne cc: Eric Dumazet cc: "David S. Miller" cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261006133011.531806-5-dhowells@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 965456110cf6952cc4eec80761171503e6e424df Author: David Howells Date: Tue Oct 6 14:29:55 2026 +0100 rxrpc: Fix update of call->tx_pending without holding lock commit 7801c42c3bb737cfb06194a383873fcad8daacf5 upstream. Currently, rxrpc_send_data() updates call->tx_pending just before it returns - but it won't be holding the call->user_mutex when it does this if a wait was interrupted by a signal. This would allow a parallel sendmsg() to race. Further, both the callers of rxrpc_send_data() call it with the lock held, and then it returns an indication through the parameter list to say whether it has dropped the lock or not - after which the callers both just drop the lock if it's still held. Fix this by: (1) Moving the release of call->user_mutex down into rxrpc_send_data() and get rid of the indicator parameter. This makes it easier to see where the lock is held. (2) After waiting, if the attempt to reacquire the mutex is interrupted, just return directly there rather than going to out_unlock (3) Restricting the txb variable to inside the buffering loop and leaving ->tx_pending set until we've queued the buffer. Note that there's a slight change in behaviour in that wait_for_space failure now doesn't check for completion because it doesn't hold the call user_mutex. The caller, however, should re-issue the send and pick up any error at a second attempt. Fixes: b0f571ecd794 ("rxrpc: Fix locking in rxrpc's sendmsg") Closes: https://sashiko.dev/#/patchset/20260702144919.172295-1-dhowells%40redhat.com Signed-off-by: David Howells cc: Marc Dionne cc: Eric Dumazet cc: "David S. Miller" cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.org cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261006133011.531806-4-dhowells@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit e77fe4052e155f6ab7872fe0aa71c2d91843847c Author: Chuck Lever Date: Sat Aug 8 11:40:11 2026 -0400 SUNRPC: Treat every TLS error alert as fatal commit 2c0dfe9d6d81e4bc9201b11dab3876cbfd01884e upstream. svc_tcp_sock_process_cmsg() decides whether an alert ends the session by reading the alert's level octet. RFC 8446 Section 6 retired that field. The severity is implicit in the description, and a receiver treats every alert listed in Section 6.2 as an error alert "regardless of the AlertLevel in the message". A peer that aborts with unexpected_message but leaves the legacy octet set to warning makes the server return -EAGAIN. svc_tcp_recvfrom() then leaves a dead TLS session attached to an open transport. NFSD keeps polling it. Decide from the alert description instead. close_notify and user_canceled are the closure alerts (RFC 8446 Section 6.1). Every other description ends the session, including one this kernel does not recognize. Fixes: 39067dda1d86 ("SUNRPC: Use new helpers to handle TLS Alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-3-62d9a631c880@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 8067c654ae8c6d88aa0d499e9974b59ab2fe5042 Author: Ameer Hamza Date: Sat Aug 15 03:19:52 2026 +0500 sunrpc: treat empty auth.unix.gid replies as negative entries commit a12cc0930235b86b934ade7c077a1935c2ac333d upstream. When rpc.mountd cannot resolve a uid (getpwuid() or getgrouplist() failure, e.g. while winbind or sssd is briefly unreachable), it answers the auth.unix.gid upcall with zero groups. unix_gid_parse() installs that as a valid positive entry, and svcauth_unix_set_client() then replaces the credential's group list with the empty one on every request, RPCSEC_GSS included via svcauth_gss_set_client(). One failed lookup strips that uid of all supplementary groups on every export for up to mountd's configured TTL (30 minutes by default), long after the NSS backend has recovered. mountd cannot send an empty list for a successful lookup, since getgrouplist(3) always includes at least the user's primary group, so a zero-group reply can only mean the lookup failed. Record it as a negative entry: unix_gid_find() then returns -ENOENT and svcauth_unix_set_client() keeps the groups the RPC credential already carries. This is the fallback that commit 3fc605a2aa38 ("[PATCH] knfsd: allow the server to provide a gid list when using AUTH_UNIX authentication") promised when no answer is available, and the same state try_to_negate_entry() already creates when no listener holds the channel open. Fixes: 3fc605a2aa38 ("[PATCH] knfsd: allow the server to provide a gid list when using AUTH_UNIX authentication") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Ameer Hamza Link: https://patch.msgid.link/20260814221953.108837-2-ameer.hamza@truenas.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit fd7b12865b2078f16406834631c4a68262d28346 Author: Zhiling Zou Date: Sat Sep 12 21:56:09 2026 +0800 SUNRPC: trace an accepted transport before publishing it commit 06f90cf104fc21ee01e7ef1eb80e092173089b9f upstream. svc_handle_xprt() publishes a newly accepted transport before tracing it. svc_add_new_temp_xprt() places the transport on sv_tempsocks and clears XPT_BUSY, so another nfsd thread can dequeue it at once. If the peer has already closed the connection, that thread runs svc_delete_xprt(), which drops the list reference, the only reference the new transport holds. trace_svc_xprt_accept() then reads the transport's addresses and network namespace from freed memory. Before publication the accepting thread owns the transport exclusively: XPT_BUSY is still set from svc_xprt_init() and the transport is on no list. Emit the tracepoint there. Fixes: 11bbb0f76e99 ("SUNRPC: Trace a few more generic svc_xprt events") Cc: stable@vger.kernel.org Reported-by: VEGA Assisted-by: LLM Signed-off-by: Zhiling Zou Link: https://patch.msgid.link/d15495bff2247e3f9d4f9ef36df8e246a3898380.1789220778.git.zhilinz@nebusec.ai [ cel: trace before publication instead of taking an extra reference ] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 03bfe7879fa8ac500f79c62b7afd848d2e5f3e16 Author: Chuck Lever Date: Sat Aug 8 11:40:12 2026 -0400 SUNRPC: Resume receiving after a TLS control record commit 8079c660b247f282340fbe7f55cf8a354009db9e upstream. A TLS control record delivers no payload to the RPC layer. svc_tcp_recvfrom() clears XPT_DATA before the receive, and svc_tcp_sock_recv_cmsg() returns -EAGAIN for the record it consumed. Nothing marks the transport ready again. kTLS raises data_ready for arriving TCP segments, not for records it has already decrypted. An RPC Call queued behind an alert or a KeyUpdate waits until the client sends more. The client blocks until its RPC timeout expires. The receive takes only the first two octets of the record. kTLS holds the remainder on its receive list, where each later receive takes two octets more. Drain a record that is not an alert, then mark the transport ready once a control record has been consumed. Fixes: 5e052dda121e ("SUNRPC: Recognize control messages in server-side TCP socket code") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-4-62d9a631c880@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 560956c8d2479bbf3a215b94391d9ada2063206e Author: Chuck Lever Date: Sat Aug 8 11:40:10 2026 -0400 SUNRPC: Reject a TLS alert record that is not two octets commit d16bebe45272ced4f962d27b9efd8b32a3876bd9 upstream. tls_alert_recv() reads two octets from the kvec it is handed and does not check the length (net/handshake/alert.c). svc_tcp_sock_recv_cmsg() calls it for any positive receive, and the alert[] buffer it supplies carries no initializer. A one-octet alert body leaves the description read from uninitialized stack and reported through trace_tls_alert_recv(). The peer controls that length. Neither tls_rx_msg_size() nor tls_rx_one_record() enforces the two-octet Alert payload. A TLS 1.3 record carrying only the inner content-type octet decrypts to a zero-length payload. RFC 8446 Section 5.1 requires a record with an Alert type to carry exactly one message, so any other length is malformed. Require exactly two octets before parsing and return -EBADMSG otherwise. That closes the transport rather than acting on a partly uninitialized alert. Gate the path on a control message rather than a positive count so that a zero-length record reaches the check. Fixes: bee47cb026e7 ("sunrpc: fix handling of server side tls alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-2-62d9a631c880@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f44daa50489fede01012c575d9f5e7b11a212fe4 Author: Chuck Lever Date: Sat Aug 15 12:28:44 2026 -0400 SUNRPC: Reject a socket that already has an svc_sock attached commit 0995447b8059c4d23853cdcddbe789c4a2b6bb88 upstream. Writing the same socket descriptor to /proc/fs/nfsd/portlist twice attaches a second svc_sock to one socket. svc_setup_socket() saves the socket's callbacks before installing its own, so the second attach records svc_write_space() as the old write_space callback. svc_udp_init() invokes that callback by way of svc_sock_setbufsize(), and svc_write_space() then calls itself until the kernel stack is exhausted: BUG: TASK stack guard page was hit at ffffc900037d7ff8 svc_write_space+0x90/0x2b0 net/sunrpc/svcsock.c:429 svc_write_space+0xe6/0x2b0 net/sunrpc/svcsock.c:430 ... 700 more ... svc_sock_setbufsize+0x18d/0x220 net/sunrpc/svcsock.c:386 svc_udp_init net/sunrpc/svcsock.c:854 [inline] svc_setup_socket+0xb2f/0x1090 net/sunrpc/svcsock.c:1498 svc_addsock+0x2fd/0x760 net/sunrpc/svcsock.c:1547 __write_ports_addfd fs/nfsd/nfsctl.c:742 [inline] write_ports+0xa5b/0xcc0 fs/nfsd/nfsctl.c:861 nfsctl_transaction_write+0x106/0x1a0 fs/nfsd/nfsctl.c:112 svc_data_ready() and svc_tcp_state_change() chain through their saved callbacks the same way, so a TCP descriptor added twice recurses on the next incoming segment instead. Reaching any of this takes a writer on portlist, and the nfsd filesystem sets no FS_USERNS_MOUNT, so the reproducer needs CAP_SYS_ADMIN in the initial user namespace. Reject a socket that already carries sk_user_data. svc_setup_socket() overwrites that field unconditionally, so a socket some other consumer has claimed is one NFSD would corrupt whether or not the callbacks recurse. Fixes: b41b66d63c73 ("[PATCH] knfsd: allow sockets to be passed to nfsd via 'portlist'") Cc: stable@vger.kernel.org Reported-by: syzbot+54cdc566f64abf51b7f1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=54cdc566f64abf51b7f1 Link: https://patch.msgid.link/20260815162844.8219-1-cel@kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f735700c06303335067a49ad4ad8f0b60eb43897 Author: Chris Mason Date: Sun Sep 13 12:07:06 2026 -0400 sunrpc: pin gss module across auth_domain RCU free commit b64d21116374688c33302a6704387c27d1156d72 upstream. A gss auth_domain stores a raw pointer to svcauthops_gss in dom->flavour, and its release queues svcauth_gss_domain_release_rcu() via call_rcu(). Both live in auth_rpcgss.ko text, and nothing pins the module while a domain referencing it is reachable. rmmod auth_rpcgss can therefore unmap that text while an NFSD export still holds a reference to the domain. The export cache is one such holder. When the export is finally released, the domain reference drops from module text: svc_export_put() auth_domain_put(exp->ex_client) auth_domain_release() dom->flavour->domain_release(dom) /* into module text */ svcauth_gss_domain_release() call_rcu(&dom->rcu_head, svcauth_gss_domain_release_rcu) Once auth_rpcgss is unloaded, the domain_release call lands in unmapped memory. The rcu_barrier() in exit_rpcsec_gss() does not help: it waits only for callbacks already queued, and this one is not queued until the export goes away. NFSD's NFSv4 objects import symbols from auth_rpcgss.ko, so only a server built without CONFIG_NFSD_V4 can unload auth_rpcgss while exports still name a gss domain. Take a module reference in svcauth_gss_register_pseudoflavor() before publishing the domain and drop it at the end of svcauth_gss_domain_release_rcu(). The rcu_barrier() then holds the module image until this callback has returned. Fixes: 608a0ab2f54a ("SUNRPC: Add lockless lookup of the server's auth domain") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Chris Mason [ cel: rewrote description ] Link: https://patch.msgid.link/20260913160706.384180-1-cel@kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit c5862ac50d8d057f9922bac001dd0e81d78721b1 Author: Jeff Layton Date: Tue Sep 1 09:39:41 2026 -0400 SUNRPC: keep the first error in svc_register() commit 9ed91d7c4698e611ea5bfca45076008def831fb3 upstream. svc_register() assigns every pg_rpcbind_set() result to the same "error" variable and returns the last one, so a later result erases an earlier failure. Keep the first error instead of the last. Fixes: 642ee6b209c2 ("SUNRPC: Allow further customisation of RPC program registration") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260901-nfsd-nl-hang-v5-3-a540d86668b0@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1cc4b3089eabec479b9cce2d6999ab2263d7def2 Author: Jérémy Jean Date: Thu Sep 10 12:51:20 2026 +0000 SUNRPC: fix oversized GSS proxy token copy commit 62319c2534b603b416fa2aa2f3ef18c311f75010 upstream. gss_read_proxy_verf() allocates one page per token chunk, but it copies the entire linear head of an RPC request into in_token->pages[0]. A UDP datagram can leave more than PAGE_SIZE bytes in the linear head, so a large RPCSEC_GSS INIT token overwrites following pages. Copy the linear head in page-sized chunks before switching to the request page array. The linear head itself can span multiple pages. Fixes: 5866efa8cbfb ("SUNRPC: Fix svcauth_gss_proxy_init()") Cc: stable@vger.kernel.org Signed-off-by: Jérémy Jean Assisted-by: Codex:gpt-5 Link: https://patch.msgid.link/20260910125120.3798995-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 67d36b376f76a71e52a5f8ed4a4d9d90b8b68133 Author: Chuck Lever Date: Sat Aug 8 11:40:09 2026 -0400 SUNRPC: Do not credit control-record octets to the RPC stream commit 129e7107b971009bc81643d23f3ab949f540d321 upstream. svc_tcp_sock_recv_cmsg() receives up to two octets into a local buffer, and returns that count for any record type other than TLS_RECORD_TYPE_ALERT. Nothing reached the caller's buffer, but svc_tcp_read_marker() adds the count to sk_tcplen and svc_tcp_read_msg()'s caller adds it to sk_datalen. The RPC stream advances over octets it never received. The fragment marker is assembled from stale sk_marker octets. The message body comes from pages nothing wrote. A conforming client reaches this. RFC 8446 Section 4.6.3 lets either peer send KeyUpdate once it has sent its Finished, and svcsock has no rekey path. kTLS leaves the partially consumed record on ctx->rx_list, so the body drains two octets per svc_tcp_recvfrom() call. Each pair is credited the same way. Return -EAGAIN for a record that is not an alert. That is what svc_tcp_sock_process_cmsg()'s default arm returned before the receive moved into a local buffer. Fixes: bee47cb026e7 ("sunrpc: fix handling of server side tls alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-1-62d9a631c880@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit d514dd81771aff1192e84a57ae60428c13f07ccb Author: Chuck Lever Date: Wed Sep 2 09:31:01 2026 -0400 SUNRPC: Copy the deferred RPC Call from the head buffer commit 2192a56b0686599358909c3e12e9a366f5b5d452 upstream. svc_defer() snapshots the RPC Call for replay once a pending cache upcall resolves. It copies the Call starting (rq_arg.len - head[0].iov_len) bytes before head[0].iov_base, a back-up that once covered a transport header. No transport has had one since commit 983084b2672c ("SUNRPC: Remove svc_rqst::rq_xprt_hlen"), so the two lengths are meant to be equal. An RPCSEC_GSS Call breaks that assumption. Unwrapping the integrity service truncates rq_arg.len by the length of the trailing checksum, and unwrapping the privacy service leaves rq_arg.len short by an amount the client sets with trailing bytes after the wrap token. Neither adjusts head[0].iov_len. Both lengths are size_t, so the subtraction underflows and the copy starts past head[0].iov_base. Every deferred integrity Call replays a shifted snapshot. A deferred replay skips GSS verification, so a shifted snapshot runs as an authenticated Call. With the privacy service the offset is client-chosen. A forged Call placed in that window, naming another user's GSS context handle, runs under that identity. Copy the Call from head[0].iov_base. Refuse to defer a Call whose length runs past the head buffer, so the copy cannot read out of bounds. Fixes: 260c1d1298f6 ("svc: Add transport hdr size for defer/revisit") Cc: stable@vger.kernel.org Reported-by: Kimi Security Team Reported-by: Yilin Zhang Link: https://patch.msgid.link/20260902133101.48914-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit c1e38828c93e5fc958a3d6155c5703d6e7b3de8e Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:00:49 2026 -0300 nfsd: zero NFSv4 COMPOUND tag padding commit 3f1181cb09c85499286c7f462d93530b0ebcafcc upstream. nfs4svc_encode_compoundres() copies the tag bytes into reserved XDR space and skips directly to the aligned end of the field. xdr_reserve_space() rounds the reservation up but does not initialize the padding bytes. A remote client can choose a tag length that is not a multiple of four, causing one to three stale bytes from the response page to be returned in the COMPOUND reply. Use xdr_encode_opaque_fixed() to copy the tag and clear its XDR padding. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260915160049.3105481-1-qwe.aldo@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f5a336ad931afdd609c809cea4b3d910e781bd6f Author: Jeff Layton Date: Tue Sep 1 09:39:40 2026 -0400 NFSD: validate transport name in listener_set before serv creation commit 421becdc5cf4d7d2fbda393e78ca76d25d277c0f upstream. nfsd_nl_listener_set_doit() holds nfsd_mutex for the whole listener teardown and rebuild. The code checks NFSD_A_SOCK_TRANSPORT_NAME for presence only, and not for content. An arbitrary name therefore reaches svc_xprt_create_from_sa(). There, a name that matches no registered class calls request_module("svc%s", name). That call is a TASK_KILLABLE usermode helper upcall, and it runs under nfsd_mutex. Check the name against the classes that NFSD can create: tcp, udp and rdma. The check goes in nfsd_nl_validate_listeners(), which runs before the code takes nfsd_mutex. The rejection names the offending attribute through extack, since -EPROTONOSUPPORT on its own does not say which entry carried the bad name. This narrows the upcall. It does not remove it. NFSD accepts "rdma" without a condition, so on a kernel that does not build svcrdma the name still reaches request_module("svcrdma") under nfsd_mutex. That is necessary for the modular case, where the autoload is legitimate. Fixes: 16a471177496 ("NFSD: add listener-{set,get} netlink command") Cc: stable@vger.kernel.org Assisted-by: LLM Link: https://syzkaller.appspot.com/bug?extid=c7eae0eb80858a2dba0f Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260901-nfsd-nl-hang-v5-2-a540d86668b0@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit c12f04f29dac29fba1f4eafe54455d48b4ca8df0 Author: Chuck Lever Date: Tue Sep 1 16:19:46 2026 -0400 NFSD: Set nn->cld_net before registering the cld pipe commit 14996e662f3b734427e2d645cacffc27b779f7d1 upstream. rpc_mkpipe_dentry() instantiates the pipe's dentry before it returns, so the cld pipe can be opened as soon as nfsd4_cld_register_net() has run. __nfsd4_init_cld_pipe() does not store the new cld_net in nn->cld_net until after that call. cld_pipe_downcall() reaches the cld_net only through that pointer and takes cn_lock without checking it, so a write() that lands in the window oopses. Store nn->cld_net once @cn is fully initialized and before the pipe is registered, and clear it again when registration fails. Fixes: f3f8014862d8 ("nfsd: add the infrastructure to handle the cld upcall") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901-alemi-v2-6-e163f94a3a6e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f4d884c878991bceb8a8e7a6f9d18667fe381e3d Author: Chuck Lever Date: Fri Aug 28 19:18:41 2026 -0400 NFSD: Return NFSERR_ISDIR for NFSv2 READ and WRITE on a non-regular file commit 07649099cc8c449ea8d37d0e8d6b532fecb24bf8 upstream. Commit 0ac903d1bfdc ("NFS: NFSERR_INVAL is not defined by NFSv2") changed the status NFSD returns for an NFSv2 READ or WRITE of a symlink or other non-regular file from NFSERR_INVAL to NFSERR_IO. RFC 1094 defines neither an INVAL nor a SYMLINK status. U-Boot's NFS client follows a symlink only when READ fails with NFSERR_ISDIR or NFSERR_INVAL. Since that commit it cannot load a boot image through a symlink exported by a Linux NFS server: the load completes with zero bytes transferred. Solaris returns NFSERR_ISDIR when the target of an NFSv2 READ or WRITE is not a regular file. Return the same status from NFSD. Other NFSv2 procedures continue to return NFSERR_IO. Fixes: 0ac903d1bfdc ("NFS: NFSERR_INVAL is not defined by NFSv2") Cc: stable@vger.kernel.org Reported-by: Jörg Sommer Closes: https://lore.kernel.org/linux-nfs/apE90ZRZB8IW_AiS@jo-so.de/ Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260828231841.282003-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit ea993a4e9ad93dc8208c356e5f4994428de4cdb8 Author: Chuck Lever Date: Tue Aug 18 14:41:51 2026 -0400 NFSD: Resolve the recall-any mask names in the trace format commit c563a1f0679566d7d586802e5346591d0af8da78 upstream. RCA4_TYPE_MASK_* are enum constants, so the preprocessor cannot fold them into the print format that show_rca_mask() builds for the nfsd_cb_recall_any event. Nothing declares an eval map for them either, so trace_event_eval_update() has no substitution to apply at module load, and the event's format file ships the enumerator names verbatim. trace-cmd and perf cannot decode the bmval0 field. Declare the eval maps for the nine mask bits show_rca_mask() decodes. The format then carries the shift counts as integers, the same shape the SUNRPC trace points already emit from their BIT() flag decoders. Fixes: 638593be55c0 ("NFSD: add CB_RECALL_ANY tracepoints") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260818184151.31180-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit af501c516757bc9a6b9aefe4ad28428a764f6878 Author: Chuck Lever Date: Tue Sep 1 16:19:44 2026 -0400 NFSD: Reject an oversized principal hash from nfsdcld commit dbed9418c48906dae1a7bc328fb3bc0d0d0020c8 upstream. __cld_pipe_inprogress_downcall() takes the principal hash length from the daemon's GraceStart downcall without checking it against the cc_princhash payload it describes, which holds at most SHA256_DIGEST_SIZE bytes. The length is stored verbatim in the reclaim record, and nfsd4_cld_check_v2() later hands it to memcmp() against a digest array of SHA256_DIGEST_SIZE bytes on the stack. A length up to U8_MAX reads past the end of that array, and the stray bytes can only make the comparison fail, denying the client its reclaim. The pipe is mode 0600 in rpc_pipefs, so the trigger is a broken or hostile nfsdcld rather than an unprivileged task. Reject a length larger than the wire field, as the existing check on the client name length does. Fixes: 6ee95d1c8991 ("nfsd: add support for upcall version 2") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901-alemi-v2-4-e163f94a3a6e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 7d464c3e93214a8d1fcbd226f5d622993232bbb3 Author: Aldo Ariel Panzardo Date: Tue Sep 15 09:56:36 2026 -0300 nfsd: propagate SETXATTR value decode errors commit cfcfe0b38a66bbc4122c78a2b75e1b97b3534761 upstream. nfsd4_decode_setxattr() stores the status returned while assembling a non-empty attribute value, but then unconditionally returns nfs_ok. An allocation failure can therefore leave a NULL value buffer paired with a non-zero length and allow compound processing to continue. Return the decoder status so that the operation stops on the original error. Fixes: 23e50fe3a5e6 ("nfsd: implement the xattr functions and en/decode logic") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260915125636.2849626-1-qwe.aldo@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 37fc2ec211630360e9aefcaaec8730db964645f2 Author: Jérémy Jean Date: Mon Aug 17 20:57:14 2026 -0400 nfsd: preflight SEQUENCE replies before accepting a slot commit 35ff1a7a7e3835c3e974bc5c45d335897564ceae upstream. nfsd4_sequence() narrows the reply buffer to the session's cached reply limit before it accepts the slot seqid. A client may negotiate ca_maxresponsesize_cached down to NFSD_MIN_HDR_SEQ_SZ, and nfsd4_alloc_slot() then gives every slot a zero-length sl_data[]. A COMPOUND tag can fill that narrowed buffer until it holds the SEQUENCE opcode but not the status word that follows. nfsd4_encode_operation() returns without running nfsd4_encode_sequence(), so cstate.data_offset stays zero. It leaves op->status at nfs_ok as well, so the COMPOUND is treated as having succeeded. nfsd4_store_cache_entry() declines to cache a lone SEQUENCE that returned an error. That test reads the status the operation reported, so it passes here. The copy starts at offset zero and takes the whole reply, RPC and COMPOUND headers included, into the zero-length sl_data[]. The COMPOUND tag is copied along with it, so the client picks most of the bytes written past the end of the slot: BUG: KASAN: slab-out-of-bounds in read_bytes_from_xdr_buf+0x1bc/0x390 Write of size 80 at addr ffff888003a549cd by task kunit_try_catch/24 __asan_memcpy+0x38/0x60 read_bytes_from_xdr_buf+0x1bc/0x390 nfsd4_sequence_done+0x5b0/0x810 nfs4svc_encode_compoundres+0x1bf/0x240 Check that the fixed-size SEQUENCE result, plus room for a following operation's error status, fits the negotiated limit before narrowing the buffer and consuming the slot seqid. The slot and its reply cache are left unchanged, as RFC 8881 Section 2.10.6.1.2 requires of an error returned from SEQUENCE. Fixes: 47ee52986472 ("nfsd4: adjust buflen to session channel limit") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Tested-by: Mayank Jangid (OpenSec Intelligence) Link: https://patch.msgid.link/20260817-jean-v1-1-9e356596ab85@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 76bb89e8155fe29da36ecf0121e9e98afc0f4184 Author: Chuck Lever Date: Mon Jul 20 12:37:24 2026 -0400 NFSD: Map flex file layout IDs through the request's user namespace commit f913d5d2130a584d1a027ffe3dfd88b6be2e0540 upstream. nfsd4_ff_proc_layoutget() and nfsd4_ff_encode_layoutget() translate the file's owner and group with init_user_ns, but every other identity nfsd places on the wire goes through nfsd_user_namespace(). When the transport carries a credential from a non-initial user namespace, the flex file layout reports host-global IDs. The client copies those IDs into the AUTH_SYS credential it presents to the data server, and svcauth_unix_accept() resolves that credential in the transport's namespace, so data server I/O runs under an identity unrelated to the file's owner. Switching to the request's namespace introduces a second hazard. from_kuid() returns (uid_t)-1 when the target namespace has no mapping for the owner, and the IOMODE_READ arm adds one to that result to derive an identity for which the data server denies writes. The addition would wrap to zero, handing the client uid 0 instead of an identity distinct from the owner. Translate both IDs in nfsd4_ff_proc_layoutget(), which has the svc_rqst, and carry the wire values in struct pnfs_ff_layout. from_kuid_munged() substitutes overflowuid for an unmapped owner and thus never returns (uid_t)-1, so the increment cannot wrap to zero. Fixes: 9b9960a0ca47 ("nfsd: Add a super simple flex file server") Cc: stable@vger.kernel.org Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260720141442.783935-1-cel@kernel.org?part=3 Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260720163724.810227-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 16ee8e3e0615c23435691a992fd16a1c8a701351 Author: Chuck Lever Date: Tue Sep 15 20:42:40 2026 -0400 NFSD: map fh_verify() status codes for NFS_ACLv3 replies commit b1eb9f1aea88a0d7ec8116a70c33b7b31ad0a3eb upstream. The NFS_ACLv3 protocol shares its status code space with NFSv3, which has NFS3ERR_BADHANDLE but no NFSERR_NOFILEHANDLE. An NFS_ACLv3 GETACL or SETACL request that carries an empty file handle gets a reply with status 10020, a value the client cannot interpret. Commit 1459ad57673b ("nfsd: Move error code mapping to per-version proc code.") made fh_verify() return nfserr_nofilehandle for an empty handle regardless of protocol version. The NFSv3 procedures gained nfsd3_map_status() in exchange, but the NFS_ACLv3 procedures did not, so the unmapped status reaches the encoder. Add the same mapping to the NFS_ACLv3 procedures. Fixes: 1459ad57673b ("nfsd: Move error code mapping to per-version proc code.") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260916004240.141975-2-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 5733621eee9f20c30865406cbfd2385560bd68a4 Author: NeilBrown Date: Fri Jul 17 19:27:49 2026 +1000 nfsd: honour client-provided attributes for NFS4_CREATE_EXCLUSIVE4_1 commit ddfabbc7840891e09cd500ab97c9cd36b650ec24 upstream. When a file is created with a v4.1 OPEN which requests NFS4_CREATE_EXCLUSIVE4_1, the request can include attributes to be set. However when the mtime/atime are set to hold the verifier, the other ia_valid flags are cleared, so no attributes requested by the client are used. This code was originally written for NFSv3 where NFS3_CREATE_EXCLUSIVE never includes attributes. When it was updated for v4.1, the fact that an exclusive create CAN include attributes was not handled properly. Fixes: ac6721a13e5b ("nfsd41: make sure nfs server process OPEN with EXCLUSIVE4_1 correctly") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: NeilBrown Link: https://patch.msgid.link/20260717093001.1972119-2-neilb@ownmail.net Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 540649cb8543472f6edfe9ae8b42c04aa3bd67e9 Author: Cen Zhang (Microsoft Security FORGE Labs) Date: Fri Aug 28 00:19:25 2026 -0400 nfsd: hold cl_lock in client_has_openowners() commit 5336899b5491eaa2ac22c2925d87daab2b140eb3 upstream. client_has_openowners() walks clp->cl_openowners and reads so_stateids without clp->cl_lock. nfs4_put_stateowner() unhashes that openowner under cl_lock and then frees it, so a concurrent EXCHANGE_ID with mismatched creds can use-after-free the nfs4_openowner. BUG: KASAN: slab-use-after-free in client_has_state+0x10a/0x140 fs/nfsd/nfs4state.c:3718 client_has_openowners() nfsd4_exchange_id nfsd4_proc_compound nfsd_dispatch svc_process Take clp->cl_lock while client_has_openowners() walks the openowner list. Fixes: 4eaea1342507 ("nfsd: improve client_has_state to check for unused openowners") Cc: stable@vger.kernel.org Reported-by: Xiang Mei (Microsoft) Cc: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) Link: https://patch.msgid.link/20260828041925.36758-1-blbllhy@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 676b048197cd4b83d63690fc7452a3af9bfd0c43 Author: Chuck Lever Date: Mon Aug 24 10:04:40 2026 -0400 NFSD: Fix out-of-bounds read in the rpc_status dump commit cbea14890783fead76f878caf0775a62a42049bf upstream. nfsd_nl_rpc_status_get_dumpit() loads args->opcnt and args->ops separately, then walks ops[] before rechecking rq_status_counter. A COMPOUND that completes between the two loads runs nfsd4_release_compoundargs(), which zeroes opcnt and points ops back at the eight-entry inline array. A dump that already sampled an opcnt of 200 clamps it to the sixteen slots in rq_opnum, then indexes iops[0..15]. iops is the last member of struct nfsd4_compoundargs and rq_argp is allocated at exactly that size, so the walk runs off the end of the allocation. The trailing recheck discards the sampled data, but the read has already happened. NFSD_CMD_RPC_STATUS_GET carries no GENL_ADMIN_PERM, so an unprivileged local user can repeat the dump against a busy server until it lands in the window. Sample opcnt and ops into locals, then finish the counter recheck before dereferencing ops. An unchanged counter means both came from the same COMPOUND, where opcnt cannot exceed what ops holds. Fixes: bd9d6a3efa97 ("NFSD: add rpc_status netlink support") Cc: stable@vger.kernel.org Reported-by: Prabhakar Pujeri Closes: https://lore.kernel.org/linux-nfs/20260823113255.3417-1-prabhakar.pujeri@dell.com/ Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260824-nfsd-posix-acl-ownership-v1-1-090fffc608ec@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit e48996466d78606890613a950fcddbdaa8fd41e8 Author: Wentao Liang Date: Thu Sep 17 16:31:54 2026 +0000 nfsd: Fix id-to-name cache entry leak in idtoname_parse() commit 8ca3b74c0c447af17d0e27e76658a3d4cae3c5ba upstream. idtoname_lookup() returns the id-to-name cache entry with a new reference. The name is parsed between the lookup and the update call, and when the parsed name is malformed (negative length or longer than IDMAP_NAMESZ), idtoname_parse() jumps to the error label without dropping the reference returned by idtoname_lookup(), leaking the cache entry. Release the reference with cache_put() before taking the error exit. Fixes: f9ecc921b5b5 ("[PATCH] knfsd: Use new cache code for name/id lookup caches") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260917163154.2162438-1-vulab@iscas.ac.cn Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit fa5fbc8f5fbd5de34e0dec395d45fa7b66dbf086 Author: David Flynn Date: Tue Sep 8 12:34:46 2026 -0400 nfsd: fetch direct I/O alignment for files handed to the filecache commit ace72c3d263294df7111477caaeff37438aa10af upstream. nfsd_file_do_acquire() fetches a file's direct I/O alignment attributes (nf_dio_mem_align, nf_dio_offset_align and nf_dio_read_offset_align) only on the branch where NFSD opens the file itself. The other branch, taken when the caller supplies an already-open struct file, stores that file in the nfsd_file and leaves the three alignment fields zero. NFSv4 OPEN with CREATE takes the supplied-file branch: nfsd4_create_file() creates the file with dentry_create() and passes the resulting struct file as open->op_filp, which nfs4_get_vfs_file() hands to nfsd_file_acquire_opened(). The cached nfsd_file therefore keeps zero alignment for its whole life, and nfsd_write_dio_iters_init() refuses direct I/O for every WRITE to a file the client has just created. Observed on an export whose backing device reports a dio_mem_align of 4: all 16 of 16 1 MiB NFSv4.2 writes that followed an OPEN(CREATE) took the buffered path, while 16 of 16 writes to the same file reopened without CREATE went direct. Hoist the nfsd_file_get_dio_attrs() call out of the open branch so that it runs once, for both branches, whenever the acquire has otherwise succeeded. A getattr failure now fails the acquire on the supplied-file branch exactly as it already does on the open branch. Fixes: d11f6cd1bb4a ("NFSD: filecache: add STATX_DIOALIGN and STATX_DIO_READ_ALIGN support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5.1 Signed-off-by: David Flynn Signed-off-by: Mike Snitzer Link: https://patch.msgid.link/20260908163448.30841-4-snitzer@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 36fcebcb656aca84499ff6cb7877ffd5ac6d0dec Author: Chuck Lever Date: Sun Aug 16 13:19:14 2026 -0400 NFSD: Fail a pool_threads read whose reply does not fit commit e27c63245903402ccfdb46c576462981a7e032e3 upstream. The reply to a pool_threads read is the list of per-pool thread counts, formatted into a buffer of SIMPLE_TRANSACTION_LIMIT bytes. snprintf() truncates its last write and strlen() measures only what fit, so a reply too long for that buffer ends mid-number with no terminating newline. A pool running 4096 threads is reported as 40. Nothing marks the reply as incomplete, so an administrator reads a plausible but wrong count. Take snprintf()'s return value, which reports the truncation strlen() cannot see, and fail the read with -ENAMETOOLONG when the list does not fit. That is the errno svc_one_xprt_name() already returns for the same condition. Suggested-by: David Laight Fixes: eed2965af1ba ("[PATCH] knfsd: allow admin to set nthreads per node") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260812193349.13347-1-david.laight.linux@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 0b5149b7ad8ccd64c61e887e2cf1af068b6210c9 Author: Ameer Hamza Date: Mon Aug 24 22:36:41 2026 +0500 nfsd: don't modify a session slot when replaying its cached reply commit 2987838317501ff67b672ac2a441fe34b7729f3d upstream. nfsd4_sequence() claims a session slot by setting NFSD4_SLOT_INUSE under nn->client_lock. A reply served from the slot's reply cache does not claim it, and that distinction lived only in cstate->status, which nfsd4_sequence() set to nfserr_replay_cache. Commit cc028a10a48c ("NFSD: Hoist status code encoding into XDR encoder functions") moved nfsd4_proc_compound()'s cstate->status assignment below the out: label, and the replay path's goto out was the one path that relied on skipping it. The test in nfsd4_sequence_done() therefore no longer identifies a replay, and every replay now stores its reply and clears NFSD4_SLOT_INUSE as though it owned the slot. NFSD4_SLOT_INUSE is the interlock: check_slot_seqid() rejects every sequence id for a slot that is in use, before replay_matches_cache() runs. A replay never sets it, so two replays can be in flight on the same slot at once. One can read slot->sl_cred under nn->client_lock while the other's completion frees and rebuilds it from the XDR encoder without that lock. Two completions can also collide with each other and release the same group_info twice. free_svc_cred() leaves cr_uid, cr_gid and cr_flavor intact, so the reader passes every earlier test in same_creds() and dereferences a NULL cr_group_info. From a 6.12.91 production server: BUG: kernel NULL pointer dereference, address: 0000000000000004 CPU: 63 UID: 0 PID: 39015 Comm: nfsd RIP: 0010:same_creds+0x38/0xa0 [nfsd] RDX: 0000000000000000 Call Trace: nfsd4_sequence+0x6a8/0x910 [nfsd] nfsd4_proc_compound+0x345/0x670 [nfsd] nfsd_dispatch+0x100/0x220 [nfsd] svc_process_common+0x311/0x700 [sunrpc] svc_process+0x131/0x1c0 [sunrpc] svc_recv+0x7ef/0x9c0 [sunrpc] nfsd+0xa3/0x100 [nfsd] Kernel panic - not syncing: Fatal exception Since v6.14 a live session's slot table can shrink, and the unowned store becomes a use-after-free write. nfsd4_sequence() defers the shrink while a slot is in use, but it tests NFSD4_SLOT_INUSE, which a replay does not set, so free_session_slots() can kfree() the slot the replay still holds in cstate->slot. Record the claim in cstate->slot_owned when nfsd4_sequence() accepts a request and test that in nfsd4_sequence_done(), so only the request that claimed the slot updates its cached reply and clears NFSD4_SLOT_INUSE. svc_generic_init_request() zeroes the compound response before each request, so the flag starts clear. Fixes: cc028a10a48c ("NFSD: Hoist status code encoding into XDR encoder functions") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Ameer Hamza Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260824173641.3274260-1-ameer.hamza@truenas.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f6d1f1072243a1adb1ae15425f6e36f86be94078 Author: Chuck Lever Date: Tue Sep 1 16:19:41 2026 -0400 NFSD: Don't complete a cld upcall the daemon has not read commit 7f4bf851aca4e18940ebf2bddf4ba6783802ee81 upstream. cld_pipe_downcall() matches a reply to its upcall on the xid alone. A write that arrives before the daemon has read that upcall completes __cld_pipe_upcall() while its struct rpc_pipe_msg is still queued on the pipe. The waiter returns, its stack frame goes away, and the pipe keeps a list_head that points into it. The next rpc_queue_upcall() walks that pointer: BUG: KASAN: vmalloc-out-of-bounds in __list_add_valid_or_report Read of size 8 at addr ffffc90007027950 by task syz.0.96/13066 __list_add_valid_or_report+0x6a/0x130 rpc_queue_upcall cld_pipe_upcall nfsd4_cld_grace_start nfsd4_cld_tracking_init The pipe is mode 0600 in rpc_pipefs, so the trigger is a broken or hostile nfsdcld rather than an unprivileged task. Record whether the daemon has consumed the whole message and complete only when it has. cld_pipe_destroy_msg() runs on every path by which the pipe releases a message, so it can maintain that flag under cn_lock. nfsdcld sends its -EINPROGRESS downcalls only after reading the upcall, so the new check does not break the GraceStart record stream. Fixes: f3f8014862d8 ("nfsd: add the infrastructure to handle the cld upcall") Cc: stable@vger.kernel.org Reported-by: Farhad Alemi Closes: https://lore.kernel.org/linux-nfs/CA+0ovCjVF58WLeen2ctdzHyWUASAAW3Y=Yjihyq0pFApYawtDg@mail.gmail.com/ Link: https://patch.msgid.link/20260901-alemi-v2-1-e163f94a3a6e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit b202a337fddfb81c5d159e66441fb84c7783f537 Author: Chuck Lever Date: Mon Aug 17 21:08:36 2026 -0400 NFSD: Do not send CB_RECALL_ANY to NFSv4.0 clients commit 95ff0c079b9cab91f2327beb4197a3bc48c71f55 upstream. deleg_reaper() sends CB_RECALL_ANY to every ACTIVE client holding delegations, but CB_RECALL_ANY is an NFSv4.1 operation. An NFSv4.0 client's callback service accepts only CB_GETATTR and CB_RECALL, so it replies OP_ILLEGAL. The decoder maps the unexpected opnum to -EIO, and nfsd4_cb_done() marks the client's callback channel down. Nothing brings the channel back. nfsd4_run_cb_work() sets NFSD4_CB_UP only for a minor version above zero, and the only nfsd4_probe_callback() call site an NFSv4.0 client reaches is nfsd4_setclientid_confirm(). One visit from the reaper therefore leaves the channel marked down until the client re-establishes its clientid. RENEW then returns NFS4ERR_CB_PATH_DOWN for as long as the client holds delegations. nfsd4_cb_channel_good() stops returning true, so the client is granted no further delegations. Skip clients at minor version zero. Fixes: 44df6f439a17 ("NFSD: add delegation reaper to react to low memory condition") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260817-recall-any-keep-count-v5-1-3b2cffce701e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 20b76bdbd029343ea98944cb88bf016da2371739 Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:00:22 2026 -0300 NFSD: copy SETXATTR data from all XDR buffer segments commit b01319947c69b0e3ea0fcd4b675eb892f9cad8a0 upstream. nfsd4_vbuf_from_vector() manually copies the head followed by whole pages starting at offset zero. This assumes that all remaining data starts at the beginning of the page array and that no data is stored in the tail. However, nfsd4_decode_setxattr() passes an xdr_buf returned by xdr_stream_subsegment(). Such a sub-buffer can have a nonzero page_base and can span its page and tail segments. Ignoring that layout can copy the wrong bytes into the value passed to vfs_setxattr(). Use read_bytes_from_xdr_buf(), which observes the complete xdr_buf layout. Fixes: c1346a1216ab ("NFSD: Replace the internals of the READ_BUF() macro") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260915160022.3105295-1-qwe.aldo@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 624531ecd48b96be2a94c964685762960bd11208 Author: Aldo Ariel Panzardo Date: Tue Sep 15 13:01:19 2026 -0300 nfsd: clear XDR padding in GETXATTR replies commit daba58690339ae86f1ebeb5197aa1369fae37e57 upstream. nfsd4_vbuf_to_stream() uses a raw memcpy() for the first fragment of an attribute value. xdr_reserve_space() aligns the reservation but does not initialize the extra bytes. If the complete value fits in that fragment, the loop that clears padding for the final fragment is never entered. A remote client reading an attribute whose length is not a multiple of four can therefore receive one to three stale bytes from the response page. Encode the first fragment with xdr_encode_opaque_fixed(), matching the final-fragment path and ensuring that any XDR padding is zeroed. Fixes: 23e50fe3a5e6 ("nfsd: implement the xattr functions and en/decode logic") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260915160119.3105745-1-qwe.aldo@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit f256b39c64e956d9db46c5a42be99f9fe9685919 Author: Jeff Layton Date: Tue Sep 1 09:39:39 2026 -0400 NFSD: cap the number of listeners accepted in listener_set commit 9a05e5ee0a98b9550521df86936b5f825bc07ec2 upstream. nfsd_nl_listener_set_doit() matches each requested listener against the existing set. The nested loop that does this is O(N * M), where N is the requested count and M is the existing count. The loop runs under sv_lock with bottom halves disabled. A userland request with a very large listener list can therefore spin in atomic context for a long time. Reject a request that carries more than NFSD_NL_LISTENER_MAX (1024) entries. The check goes in nfsd_nl_validate_listeners(), before the code takes any lock. The limit is far above any realistic configuration. This patch does not cap M. Only the message size bounded N; real sockets bound M. A listener_set result set is the requested set, so that path also holds M at the cap, but __write_ports_addxprt() adds two listeners per call and removes none, so repeated calls can push M past it. The worst case under sv_lock is therefore 1024 * M, plus 1024 nla_parse_nested() calls. Both interfaces require CAP_NET_ADMIN. Fixes: 16a471177496 ("NFSD: add listener-{set,get} netlink command") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260901-nfsd-nl-hang-v5-1-a540d86668b0@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 7c4846faba43c30736f77e5680de698cb55cf0de Author: Mike Snitzer Date: Mon Sep 28 11:54:27 2026 -0400 NFS/localio: report the stability a DIO WRITE actually has commit 077d39c1ac8c9b2e2fad8e66a2ba6250ced1a860 upstream. Since commit d32ddfeb5593 ("nfs/localio: Ensure DIO WRITE's IO on stable storage upon completion") a DIO WRITE issued through LOCALIO is persisted before it completes: nfs_local_iters_init() sets IOCB_DSYNC|IOCB_SYNC on it despite whatever the caller asked for, so that the buffered head and tail and the O_DIRECT middle of a misaligned write cannot complete out of order. The reply still reported the stability that was asked for, so an UNSTABLE write came back UNSTABLE, the client kept its pages on the commit list, and the COMMIT that followed ran an fsync for data that is already on stable storage. Report the stability the kiocb actually carries instead: FILE_SYNC when IOCB_SYNC is set, DATA_SYNC when only IOCB_DSYNC is. A write told FILE_SYNC has no reason to COMMIT and sends none. Buffered writes, and any write that asked for at least what it got, are unchanged. Fixes: d32ddfeb5593 ("nfs/localio: Ensure DIO WRITE's IO on stable storage upon completion") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5-1 Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit c4faa631e9e12ccc40b8fca99eed1596bdc10075 Author: Mike Snitzer Date: Mon Sep 28 11:54:25 2026 -0400 NFS/localio: fix nfs_local_dio_misaligned tracepoint commit 1ea352a0db8bcb6ff6820e9a8715aac0aa3c761f upstream. The intended focus of nfs_local_iters_setup_dio()'s call to trace_nfs_local_dio_misaligned() is on the middle segment being misaligned, yet the @offset passed in was local_dio->start_len. It would appear this was a cut-n-paste bug from the preceding nfs_local_iter_setup() call that passes local_dio->start_len. Fix this by passing the @offset as local_dio->middle_offset and calculate the start segment's offset rather than assume. Example traces, before this fix: python3-32744 [006] .l... 132946.352360: nfs_local_dio_write: fileid=00:33:1286 fhandle=0xf1f7c10b offset=1048759 count=1048576 mem_align=4 offset_align=512 start=1048759+329 middle=1049088+1048064 end=2097152+183 python3-32744 [006] .l... 132946.352360: nfs_local_dio_misaligned: fileid=00:33:1286 fhandle=0xf1f7c10b offset=329 count=1048064 mem_align=4 offset_align=512 start=329+329 middle=1049088+1048064 end=2097152+183 After this fix: python3-32744 [006] .l... 132946.352360: nfs_local_dio_write: fileid=00:33:1286 fhandle=0xf1f7c10b offset=1048759 count=1048576 mem_align=4 offset_align=512 start=1048759+329 middle=1049088+1048064 end=2097152+183 python3-32744 [006] .l... 132946.352360: nfs_local_dio_misaligned: fileid=00:33:1286 fhandle=0xf1f7c10b offset=1049088 count=1048064 mem_align=4 offset_align=512 start=1048759+329 middle=1049088+1048064 end=2097152+183 Fixes: 6a218b9c3183e ("nfs/localio: do not issue misaligned DIO out-of-order") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 209ad0993faea7bbf5c8f981a56c120813473e07 Author: Jimmy Zuber Date: Tue Sep 22 17:56:56 2026 +0000 NFS: Fix stale negative cache on failed nfs_mkdir() commit 211cda4fdf33011cee39f8970c4625b207142d6b upstream. Since commit 8376583b84a1 ("nfs: change mkdir inode_operation to return alternate dentry if needed"), nfs_mkdir() no longer drops the dentry on RPC failure. A negative cache value can then result in spurious ENOENT results for further operations within that directory, such as open or stat. We observed this breaking some applications where an EEXIST on mkdir caused the application to assume the directory to exist, only to fail operations within that directory due to the retained negative cache entry. The other create paths, nfs_create() and nfs_mknod(), still drop the dentry on failure. This patch restores the previous behavior. Fixes: 8376583b84a1 ("nfs: change mkdir inode_operation to return alternate dentry if needed") Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Jimmy Zuber Reviewed-by: NeilBrown Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit d2609b2db66a161d95b588e28aa2b473a5c6b054 Author: Benjamin Coddington Date: Tue Sep 15 08:22:08 2026 -0400 NFSv4/flexfiles: Bound page coalescing on the absolute stripe offset commit a84c62c4f03706b2c2f01dcc5fe614a4233ee75d upstream. ff_layout_pg_test() was copied from the files layout, which partitions data servers relative to pattern_offset and bounds coalescing with a segment-relative offset. Flexfiles has no pattern_offset: nfs4_ff_layout_calc_dss_id() partitions on the absolute file offset (RFC 8435 Section 6). So when a layout segment's offset is not stripe-unit-aligned, the segment-relative coalescing window is shifted off the absolute stripe grid and a coalesced I/O can straddle a stripe boundary, sending the bytes past it to the wrong data server. Bound coalescing on the absolute offset to match calc_dss_id(). Aligned segments, including all whole-file layouts, are unchanged. Fixes: 4934ccbeaed3 ("NFSv4/flexfiles: Read path updates for striped layouts") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 43b9e0c39eed665be2267329b5c041ba2b2a997c Author: Benjamin Coddington Date: Tue Sep 15 08:22:04 2026 -0400 NFSv4/flexfiles: Use the full 64-bit stripe_unit commit 0cc1191538b1523dfe944eedc799fdd146c05fbf upstream. ff_layout_alloc_lseg() decodes stripe_unit as the 64-bit value the protocol defines and struct nfs4_ff_layout_segment stores it as one, but both consumers narrow it back to 32 bits: nfs4_ff_layout_calc_dss_id() divides with do_div(), which casts the divisor, and ff_layout_pg_test() copies it into a u32 first. A stripe_unit that does not fit is silently truncated, so the client stripes on a unit the server did not specify -- or divides by zero, if the low 32 bits happen to be clear. Divide by the full value, with div64_u64() and div64_u64_rem(). Fixes: 20b1d75fb840 ("NFSv4/flexfiles: Add support for striped layouts") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 12326bd73a61676cf1a42e2629251430ac8f96af Author: Benjamin Coddington Date: Tue Sep 15 08:22:07 2026 -0400 NFSv4/flexfiles: Use the full 64-bit offset for read DS selection commit 448591e1f82902e5714bd436d6367adc7fbaea90 upstream. The read data-server selection helpers declare their offset parameter as u32, truncating the file offset before nfs4_ff_layout_calc_dss_id() computes the stripe index. The write path already passes the full offset; make the read path match. Fixes: 4934ccbeaed3 ("NFSv4/flexfiles: Read path updates for striped layouts") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 938f374ec83912d1383810a1d31aa7ac1940b11e Author: Benjamin Coddington Date: Thu Oct 15 07:33:07 2026 -0400 NFSv4/flexfiles: fail I/O to the data server once a lock is lost commit 7fa2ad367abe6d3155daefb57331e7fce1a17afd upstream. When a client loses a byte-range lock, because its lease expired and it may not recover the lock (nfs.recover_lost_locks=0) or because reclaim failed, it marks the lock state NFS_LOCK_LOST and fails further I/O by that lock owner. Otherwise an application that believes it holds a lock over a range is never told that the lock is gone, and can overwrite data that another client has since written under its own lock on that range. The NFSv4 READ/WRITE and file layout I/O paths apply this in rpc_call_prepare, where nfs4_set_rw_stateid() returns -EIO for a lost lock. The flexfiles data server I/O path does not: the NFSv3 data server path never checked, and the check on the NFSv4 path was removed when the data server stateid began to be taken from the layout. Fail read and write RPCs to the data server in rpc_call_prepare when the lock is lost. The data server path has no use for the stateid that nfs4_set_rw_stateid() selects, and selecting it looks up a delegation or open stateid on every I/O. Instead add nfs4_lock_context_lost(), which only tests NFS_LOCK_LOST, and check it alongside the open state. Its lookup, __nfs4_lookup_lock_state(), is split out of __nfs4_find_lock_state() and takes no reference: a lock state is only unlinked from state->lock_states under state->state_lock, so one found while holding that lock cannot be freed before it is released. Use it in nfs4_copy_lock_stateid() as well, which only reads the lock state under that lock. That drops a reference get and put from stateid selection for all NFSv4 I/O without changing the stateid selected. Terminating the RPC in rpc_call_prepare is not enough on its own. The done callback reads the -EIO as a data server connection error, forgets the device ID, and resets the I/O to pNFS (or, for an NFSv4 data server, possibly to the MDS). After a reset to pNFS a new LAYOUTGET is granted and rpc_call_prepare fails the I/O again, without end. The existing NFS_CONTEXT_BAD check does not loop, since the open state is then invalid and pnfs_update_layout() fails the reset I/O, but it still forgets the device ID. So when an RPC that was never sent fails and the open context is bad, the open state is invalid, or the lock is lost, complete it with -EIO without error handling. An RPC that was sent and failed is handled as before, so a real data server error is still reported to the MDS. Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver") Fixes: bb21ce0ad227 ("flexfiles: use per-mirror specified stateid for IO") Cc: stable@vger.kernel.org Tested-by: Arun Potharaju Assisted-by: LLM Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 8581c8ea5fd2bc2cd0ac41704084e03cab06950b Author: Benjamin Coddington Date: Tue Sep 15 08:22:09 2026 -0400 NFSv4/filelayout: Anchor page coalescing on pattern_offset commit 7f2d221b01f356b6bb3bb6efef998f8b28339824 upstream. filelayout_pg_test() bounds page coalescing to a single stripe unit using an offset relative to pls_range.offset, but the data server is selected by nfs4_fl_calc_j_index() using an offset relative to pattern_offset. When a segment's pattern_offset and range offset are not congruent modulo the stripe unit, the coalescing window is shifted off the DS-selection grid, so a coalesced I/O can straddle a stripe boundary and send the bytes past it to the wrong data server. Anchor coalescing on pattern_offset to match nfs4_fl_calc_j_index(). Stripe-congruent segments, including the common whole-file pattern_offset 0 case, are unchanged. Fixes: c6194271f94b ("pnfs: filelayout: support non page aligned layouts") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit bfa512d906cdbd5de45529746ef3f20d5e9c2b0a Author: Benjamin Coddington Date: Fri Sep 4 08:56:02 2026 -0400 NFSv4.1/pnfs: suspend pNFS on NFS4ERR_TOOSMALL from LAYOUTGET commit 28c950413605fb5b6cb3863c5e3274ea69701097 upstream. If the layout for the requested range is larger than the size the client advertised in loga_maxcount, RFC 8881 Section 18.43.3 has the metadata server return NFS4ERR_TOOSMALL. The client caps loga_maxcount at a single page, so a flexfiles server that stripes a layout segment across several dozen data servers produces this error today. The client has no handling for it: nfs4_stat_to_errno() maps the error to -ETOOSMALL during decode, which nothing in the layoutget path recognizes and nfs_error_is_fatal() does not consider fatal, so pnfs_update_layout() clears the layout fail bit and returns no segment. The I/O falls back to the MDS, but because no fail bit was set, every subsequent pageio attempt sends another LAYOUTGET that is doomed to the same NFS4ERR_TOOSMALL. Files whose layouts do not fit the reply buffer never use pNFS and pay an extra round trip on every pageio. Map -ETOOSMALL to -EMSGSIZE in the layoutget exception handler and have pnfs_update_layout() treat it like NFS4ERR_LAYOUTUNAVAILABLE: mark the layout mode as failed and fall back to I/O through the MDS. Fixes: d600ad1f2bdb ("NFS41: pop some layoutget errors to application") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Benjamin Coddington Reviewed-by: Jeff Layton Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit cf4c0b3acb1d0600acc39ecb2f3b22647ac6ddb1 Author: Benjamin Coddington Date: Tue Sep 15 08:22:03 2026 -0400 NFSv4/pnfs: Free the netid when draining a data-server address list commit a7c8e96d1b9fa327cbdea514d047c8295b28d49a upstream. nfs4_pnfs_ds_addr_free() releases all three of an address entry's allocations, but the four sites that drain a decoded list before it reaches a data server open-code the loop and free only da_remotestr and the entry, leaking da_netid. Both layout drivers drain that list when nfs4_pnfs_ds_add() returned a data server already in the cache, and again on their error exits. Lift the drain into nfs4_pnfs_ds_addr_list_free() so an address list has one owner. A striping mount reaches the cached case on nearly every GETDEVICEINFO, since many deviceIDs name the same data servers. Fixes: 4be78d26810b ("NFSv4/pNFS: Store the transport type in struct nfs4_pnfs_ds_addr") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 9b89bd161183277fe08077f7877b495ec53a2440 Author: Chuck Lever Date: Tue Sep 1 16:19:48 2026 -0400 pnfs/blocklayout: Complete a device upcall when the pipe is closed commit 2a25cc8e984610828a526086313b8a7aeefe507d upstream. Once blkmapd has read a whole upcall, rpc_pipe_read() unlinks the message from every pipe list, so the purges in rpc_pipe_release() and rpc_close_pipes() no longer reach it. bl_upcall_ops supplies no .release_pipe callback, and bl_pipe_destroy_msg() returns without completing the upcall because a downcall is expected to follow. A daemon that exits between the read and the write therefore strands its waiter: bl_resolve_deviceid() sleeps in wait_for_completion() and never returns, and it holds nn->bl_mutex across that wait, so every later device resolution in the net namespace blocks behind it. Add a .release_pipe that completes an upcall blkmapd has consumed and left unanswered. Completing an upcall retires it, so a message the framework has already purged is no longer in flight and is not completed a second time here. Fixes: fe0a9b740881 ("pnfsblock: add device operations") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901-alemi-v2-8-e163f94a3a6e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 7b757e120aaffef893fa9a8ecfdf9144566cbc96 Author: Chuck Lever Date: Tue Sep 1 16:19:45 2026 -0400 pnfs/blocklayout: Complete a device upcall only on its own reply commit acfbea6c5e27c68d6b6d12849eb2b7f8466ccf06 upstream. bl_pipe_downcall() wakes bl_resolve_deviceid() on any write of the right size, without checking that blkmapd has read the upcall being replied to. A write that arrives first returns the waiter while its struct rpc_pipe_msg is still queued on the pipe, which then holds a list_head into a dead stack frame. Reaching the pipe takes root, so the trigger is a broken or hostile blkmapd. The wait has two further defects. bl_resolve_deviceid() sets TASK_UNINTERRUPTIBLE only after rpc_queue_upcall() has made the message visible, so a reply that lands in between wakes a running task and the schedule() that follows sleeps forever holding bl_mutex. And nn->bl_mount_reply is never reset, so when the pipe purges an unread upcall the waiter takes the previous reply as its own. Move the message into struct nfs_net, where bl_mutex already limits the pipe to one upcall per net namespace. Accept a reply only while blkmapd has read the whole message and no earlier reply has been taken, and reject any other write with -EINVAL. Wait for that reply on a completion so it cannot slip past the sleep, and check msg->errno before trusting it. Fixes: fe0a9b740881 ("pnfsblock: add device operations") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260901-alemi-v2-5-e163f94a3a6e@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit bed2aa2307e427525ce71bd8d60331418d5b2629 Author: Benjamin Coddington Date: Tue Sep 15 08:22:06 2026 -0400 pNFS: Fix CB_NOTIFY_DEVICEID CHANGE to consume ndc_immediate commit a0cb76dc3b2919af8257fc08b4f9a79a35442483 upstream. decode_devicenotify_args() gated the trailing ndc_immediate on cbd_layout_type rather than cbd_notify_type, so the flag was never consumed and a multi-item cnda_changes<> misaligned after the first entry. Fixes: 1be5683b03a7 ("pnfs: CB_NOTIFY_DEVICEID") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 520b48753e3c54172a078e7e4b82aec83ae2e08d Author: Ratnaker Gautam Date: Sat Oct 17 23:15:05 2026 +0200 smb: client: validate NT transaction response layout and offsets commit 83d0d5e0ca22233c75daf139ec0063b9d2ff1ac7 upstream. validate_ntransact() assumes that the response uses the fixed 18-word NT transaction layout. A different WordCount makes get_bcc() locate the byte count at a different offset from pSMBr->ByteCount, allowing the subsequent bounds checks to use inconsistent response boundaries. The function also turns the 32-bit ParameterOffset and DataOffset fields into pointers before checking their bounds. On a 32-bit client, a large offset can wrap the pointer below end_of_smb and pass the one-sided pointer comparison. The caller then dereferences the parameter pointer or copies from the data pointer. Require the expected WordCount before reading the byte count. Check each offset and count against the received SMB length as integers before forming either pointer. Use subtraction after validating the offset so that the range checks cannot overflow. Reported-by: Ratnaker Gautam Fixes: 0a4b92c05ed0 ("[CIFS] Add worker function for Get ACL cifs style") Cc: stable@vger.kernel.org Signed-off-by: Ratnaker Gautam Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit ba57bfe1a9fa1566757cd3f3310ccdf88f4b7673 Author: Dominik Maier Date: Fri Oct 23 01:21:16 2026 +0200 smb: client: fix slab-out-of-bounds write in id_mode_to_cifs_acl() commit a377a3645c7d0246af0bc4ef24db94bb2670bdde upstream. In id_mode_to_cifs_acl(), while the chown branch reserves sizeof(struct smb_ntsd) + 2 * sizeof(struct smb_sid) (plus sizeof(struct smb_acl) and the worst-case ACE space after commit 0ee150794c75 ("smb: client: fix heap overflow in DACL owner/group rewrite")), the chmod branch only adds 2 * sizeof(struct smb_ace) or 5 * sizeof(struct smb_ace) to secdesclen (or 1 * sizeof(struct smb_ace) on posix). However, the chmod branch also invokes build_sec_desc() -> copy_sec_desc(), which unconditionally writes the Owner SID at pnntsd + sidsoffset and the Group SID at pnntsd + sidsoffset + sizeof(struct smb_sid) (2 * 68 = 136 bytes total), and set_chmod_dacl() always writes a struct smb_acl header (8 bytes) even when the source descriptor has dacloffset == 0. When a security descriptor has compact or overlapping Owner/Group SIDs (or dacloffset == 0), calling chmod() under-allocates pnntsd and writes past the end of the slab buffer. Reserve sizeof(struct smb_acl) + 2 * sizeof(struct smb_sid) (plus sizeof(struct smb_ntsd) on the posix path) in the chmod branch of id_mode_to_cifs_acl(). Fixes: 7ee0b4c635c0 ("cifs: fix hardcoded default security descriptor length") Fixes: f5065508897a ("cifs: Retain old ACEs when converting between mode bits and ACL.") Assisted-by: ARTIST LLM Signed-off-by: Dominik Maier Cc: stable@vger.kernel.org Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 4a426ca5be7e3dedbe76575b967db04fbf01136f Author: Abdifatah Suruur Date: Fri Oct 23 14:52:46 2026 +0300 smb: client: fix fiemap wild read on empty truncated response commit f5baa17a0f316c235d61623ac8e8fb32c2b3c0cc upstream. smb3_fiemap() treats -E2BIG from SMB2_ioctl() as a truncated range blob and loops for the next chunk. If the server reports STATUS_BUFFER_OVERFLOW with OutputCount == 0, SMB2_ioctl() returns -E2BIG with out_data == NULL and out_data_len == 0, and the existing length checks accept the empty result. The loop then evaluates next = out_data[num - 1].file_offset + ... with num == 0, reading 16 bytes before NULL. Reject a truncated range blob that contains no range, so the resume offset is never computed from an empty response. Also require the last range in a truncated blob to advance the resume offset without overflowing, and to stay within the requested range; a malicious or broken server could otherwise make no progress or underflow len and loop forever. Free the previous response buffer before retrying. Reproduced on 6.6.87.2 with a malicious SMB2 server that answers FSCTL_QUERY_ALLOCATED_RANGES with STATUS_BUFFER_OVERFLOW and OutputCount == 0; an FS_IOC_FIEMAP ioctl on the mount oopses in cifs_fiemap() with CR2 = fffffffffffffff8. The code path is unchanged on mainline. Fixes: 2f3ebaba13ce ("cifs: add fiemap support") Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit acf25a7be39dccdbf60fdf3d437dd7832fa4b6d3 Author: Luxiao Xu Date: Fri Oct 16 15:11:01 2026 +0800 smb: client: fix buffer overflow in SMB2_tcon() commit 73cc469b0ff7551f8537ea919709973e6dc4f514 upstream. In SMB2_tcon(), unc_path is allocated with a fixed buffer size of MAX_SHARENAME_LENGTH * 2 bytes (672 bytes). However, the user-controlled UNC path (tree) length is passed to cifs_strtoUTF16(), which assumes the destination buffer is large enough and writes strlen(tree) + 1 UTF-16 code units. Commit 62a1a439e0fd ("cifs: clean up handling of unc= option") removed the length check on UNC mount options, allowing mount paths to exceed MAX_SHARENAME_LENGTH while retaining the fixed-size buffer allocation in SMB2_tcon(). Consequently, an oversized UNC string causes cifs_strtoUTF16() to write past the end of the heap object, resulting in a slab-out-of-bounds write. Furthermore, if a tree exceeds MAX_TREE_SIZE characters, strscpy() truncates it in cifs_tcon::tree_name, causing subsequent reconnects or failovers to fail. Fix this by first verifying that the length of tree does not exceed MAX_TREE_SIZE, returning -EINVAL if it does. Then, dynamically allocate unc_path based on the length of tree so that it safely accommodates all UTF-16 code units for paths within MAX_TREE_SIZE. Fixes: 62a1a439e0fd ("cifs: clean up handling of unc= option") Cc: stable@vger.kernel.org Reported-by: Xin Liu Closes: https://bugtracker.nebusec.ai/f/3292 Assisted-by: LLM Suggested-by: Paulo Alcantara Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei [pc: remove unused MAX_SHARENAME_LENGTH] Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit b304a9268f7d54eb75ce62f75013c9a90eabf084 Author: Paulo Alcantara Date: Sun Oct 25 20:48:08 2026 -0300 smb: client: don't resurrect an exiting tcon from cached dir workers commit d58e7b40908a8a57755811d5b37af1df3380278f upstream. cfids_laundromat_worker() bumps tcon->tc_count for every expired open cfid and queues cached_dir_offload_close() without checking whether the tcon is already being torn down. Racing with the final cifs_put_tcon(), the tcon comes back from zero and gets torn down twice: T1 T2 cifs_put_tcon() --tc_count == 0, TID_EXITING tconInfoFree() free_cached_dirs() cancel_delayed_work_sync() cfids_laundromat_worker() ++tc_count == 1 queue_work(serverclose_wq) kfree(tcon->origin_fullpath) kfree(tcon) cached_dir_offload_close() close_cached_dir() [UAF] cifs_put_tcon() tconInfoFree() [double free] cached_dir_lease_break() also bumps tc_count without tc_lock, racing with the laundromat's locked update. Take the tcon reference through a helper that refuses once the tcon is TID_EXITING or its refcount has dropped to zero. Queued put_work and close_work then always hold a tcon reference, so tconInfoFree() can't run before they finish and free_cached_dirs() doesn't need to flush any workqueue. If the laundromat can't get a reference, put the cfid back on the dying list for free_cached_dirs() to free; its handle goes away with the tree connection. The lease break path finds the tcon on ses->tcon_list under cifs_tcp_ses_lock, so it can't see TID_EXITING, but it now takes tc_lock. Fixes: 3fa640d035e5 ("smb: During unmount, ensure all cached dir instances drop their dentry") Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: David Howells Cc: Namjae Jeon Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 93d1fbe38f0c1f230fdd24410353b1fd9e5883d3 Author: VeroFess Date: Mon Oct 26 15:01:03 2026 +0900 smb: server: size directory name conversion buffer correctly commit f1f37834eaba5904103af1f18afe3510c7e9dc71 upstream. A 2048-byte ASCII directory name needs 4098 bytes when converted to UTF-16, including the terminator. ksmbd_convert_dir_info_name() caps its allocation at PATH_MAX and writes past the end of that buffer. Allocate space for one UTF-16 code unit per input byte plus the terminator. Use kmalloc_array() to check the size calculation. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Assisted-by: gpt 6 sol with daybreak blue Signed-off-by: VeroFess Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 70daf37bef86eeafc9242ba32a5911e89e887ecb Author: Borislav Petkov (AMD) Date: Fri Aug 21 18:32:31 2026 -0700 x86/bugs: Adapt SRSO mitigation to Zen6 commit ae1d2082d93bc04604dc08e9b7f9cdba5e0c28e6 upstream. Zen6 has BTB protection which isolates the different contexts (user/kernel, guest/host) from one another. This makes the SafeRET mitigation there unnecessary leaving the user/user and guest/guest attack vectors open, whose protection is handled by the Spectre v2 mitigation setting to do IBPB on a context switch. Detect that setting and report it with a new mitigation string. Signed-off-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/20260822013231.1109255-1-bp@kernel.org Signed-off-by: Greg Kroah-Hartman commit 30fb9f2ad94a84ed36bcf514f220e535dcdc5f7c Author: Darrick J. Wong Date: Mon Oct 12 08:21:22 2026 -0700 xfs: reattach dquots after changing inode ids commit 2f528e4a8f89daa6d0cc64b044f6f94c018fe9ae upstream. LOLLM noticed that xrep_inode_ids can change the user, group, or project id of any given file. When this happens, we need to detach any existing incore dquot and attach the correct ones. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit e6338cdc1003b8f3c5518bad6ed73b220c29c291 Author: Darrick J. Wong Date: Mon Oct 12 08:22:25 2026 -0700 xfs: range-check bc_levels array access in scrub tracepoints commit 73b7276b8a4b5eb272f3c3b36ea3042e786f4741 upstream. LOLLM noticed xchk_btree()'s odd habit of passing cur->bc_nlevels to xchk_btree_ptr_ok when we're checking the pointer to the root block at the start of the btree scan. This enables us to skip checking the pointer for an inode btree's root (since it doesn't have one) but doesn't handle per-AG btrees quite correctly. There isn't a problem for __xfs_btree_check_ptr itself, but the corruption tracepoint naively walks off the end of bc_level[]. Fix that by adding a helper to do an implicit range check. Cc: stable@vger.kernel.org # v5.16 Fixes: 6ca444cfd66354 ("xfs: prepare xfs_btree_cur for dynamic cursor heights") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit a312988016bd083fc964b1fb57febec9e2de76d5 Author: Darrick J. Wong Date: Sun Oct 4 22:56:51 2026 -0700 xfs: propagate errors while checking null siblings commit e5bde75a816b3549942f4b09a8bf09006b7ea9de upstream. LOLLM observes that if xfs_da3_path_shift returns an error here, scrub doesn't handle it the way that it handles most runtime errors. Instead, it drops the error and keeps going, even though that's not how that's supposed to work. Fix that by calling xchk_da_process_error to set corruption flags and then jump out of the flow of execution. Cc: stable@vger.kernel.org # v4.15 Fixes: 7c4a07a424c18d ("xfs: scrub directory/attribute btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 27b6057c988473d8ffd78f9d60996a995645e662 Author: Darrick J. Wong Date: Mon Oct 12 23:07:48 2026 -0700 xfs: opportunistically skip btree block checks commit 4ce244b234c251963fca6dff9de6edf26a209d08 upstream. LOLLM notices that both callers of xchk_btree_get_block will return early if *pblock is NULL after a successful return. However, xchk_btree_get_block itself can return 0 after flagging a corruption. There's no point in continuing after we've found a corruption, so null the pointer out. Cc: stable@vger.kernel.org # v4.15 Fixes: cc3e0948d2686f ("xfs: scrub the shape of a metadata btree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 05fd50e646ea0ced39af7b9cc7de96dff27613b6 Author: Darrick J. Wong Date: Mon Oct 12 23:06:46 2026 -0700 xfs: only written file data blocks can be shared commit 634b63baf05062988456a0bd5df2696c14ea2949 upstream. LOLLM noticed that xchk_refcountbt_rmap_check (and its rt equivalent) will count any rmap owner towards the shared count. However, the only blocks that can be shared between xfs files are written file data blocks; and the only blocks that can have single-refcount entries are COW staging extents. Fix the checking code. Cc: stable@vger.kernel.org # v4.16 Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit a20e7217f69462b4c373747fa08a975e6e102229 Author: Darrick J. Wong Date: Mon Oct 12 08:21:38 2026 -0700 xfs: never reset the default quota timer commit ddf4fe30c3fd7d37cf9bad3887ddb69984954cf4 upstream. LOLLM notices that xrep_quota_fix_timer doesn't check the dquot id, which means that it can inadvertently reset the default quota timer when we really meant to ensure that a (non-root) quota overage timeout has a sane timestamp. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9ee0b919b7df67ce8f73b650cf2ad1194cd51b94 Author: Darrick J. Wong Date: Sun Oct 4 22:57:38 2026 -0700 xfs: init inode number for tracepoint commit e98643f794d0d7a7fde8b29276d74e09fa0d5d19 upstream. LOLLM complains that if the xchk_dir_lookup call fails, it won't set ino to anything. ino is then passed into the tracepoint function, which means that it reports random stack garbage. Set it to NULLFSINO instead so that the circumstance is more obvious. Cc: stable@vger.kernel.org # v6.13 Fixes: 0d2c636e489c11 ("xfs: repair metadata directory file path connectivity") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 55a29b330617978e571c1ddb4f96ad5f916522ef Author: Darrick J. Wong Date: Mon Oct 12 23:05:43 2026 -0700 xfs: fix data fork block count check in xrep_inode_blockcounts commit 147f9f8300cb284923e08bb8a7b32ba9681c45ed upstream. LOLLM notices that for non-reflink realtime files, the @count output of xchk_inode_count_blocks includes both the file blocks on the realtime volume and the bmap btree blocks on the data volume. Therefore, we must compare this value to rblocks + dblocks to avoid unnecessary failure. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9702d68ad6264299994b188d2c835dd062a45217 Author: Darrick J. Wong Date: Mon Oct 12 08:21:54 2026 -0700 xfs: fix correction of unwritten extents in quota file data fork commit 6f2792720673f569fa3e1f68181b9d6fd26802b5 upstream. LOLLM noticed a couple of problems with the code that fixes unwritten mappings in the quota file's data fork: first, we should zero the ondisk contents as part of converting them to "unwritten" just in case we crash shortly after the conversion. Second, and more importantly, it noticed that we fail to resynchronize the iext tree cursor after modifying the iext tree. If the tree shape changes, we could be in a world of hurt. Third, we should force a quotacheck if we reset an ondisk dquot. Fix all issues. Cc: stable@vger.kernel.org # v6.8 Fixes: a5b91555403e3a ("xfs: repair quotas") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 1bde9463d75244ade3f870e34e9e60f2cb686c44 Author: Darrick J. Wong Date: Sun Oct 4 22:57:07 2026 -0700 xfs: don't try to scrub self-referential dirent in metapath checker commit 1e7337a3ecebab1bb2ba02187d88b94e5146e4f0 upstream. LOLLM observes that the _ilock_both helper will loop forever trying to double-lock the same inode if mpath->dp == sc->ip. Callers are not supposed to call us with parent == child because that makes no sense. Trigger an assertion, mark the scan incomplete, and return IO error so that this fails noisily. Cc: stable@vger.kernel.org # v6.13 Fixes: b3c03efa5972f0 ("xfs: check metadata directory file path connectivity") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit f12cbd5e2029427d5ca44703de1b0bf5f8e1a293 Author: Darrick J. Wong Date: Mon Oct 12 23:09:22 2026 -0700 xfs: don't try to repair rtsummary if the summary file isn't computed commit 6e82b7641889ad0198f3bf17a5e4c6fe7aab0850 upstream. LOLLM observed that we can erroneously try to repair the rtsummary file if we've not yet computed its contents. That results in a corrupt summary file, so let's add a flag to track whether or not the incore data is complete. Cc: stable@vger.kernel.org # v6.10 Fixes: abf039e2e4afde ("xfs: online repair of realtime summaries") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 3e8c3ed178c1e8a1cc93f773ed15c6e487c7885e Author: Darrick J. Wong Date: Mon Oct 12 08:20:51 2026 -0700 xfs: don't subtract excess usage twice when computing agf_btreeblks commit 4439b626fb5104204952aa2f169451688fb6be26 upstream. LOLLM noticed that the free space btree repair code calculates agf_btreeblks from the number of blocks we wrote to rebuild the free space btrees (minus the roots). That's correct. However, it observes that we subtract the "excess" reservation, which is not correct. Fix this accounting problem. Cc: stable@vger.kernel.org # v6.8 Fixes: 4bdfd7d15747b1 ("xfs: repair free space btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 32b3e288e22c597e1a73f59fe28c3277ab33f62e Author: Darrick J. Wong Date: Mon Oct 12 23:08:35 2026 -0700 xfs: don't set a metadata directory's parent to sb_rootino commit c9f98b0f4f70c8cfd617dc2886bf2fc0a36ab9da upstream. LOLLM complains that it's weird to set a metadata directory's parent inumber to the regular directory tree root. Fix this even if nobody's ever going to notice this because metadata path lookups don't access dotdot. Cc: stable@vger.kernel.org # v6.13 Fixes: 4f3d4dd1b04b2b ("xfs: define the on-disk format for the metadir feature") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit fb6d5c9a2edff47753dd97934821741dab97e5b4 Author: Darrick J. Wong Date: Mon Oct 12 23:08:20 2026 -0700 xfs: don't scan across metadata/regular directory trees for dirents commit 03ce4ca43c00394364493865f417d646e252bac2 upstream. LOLLM points out that the directory repair code should never scan files in the regular directory tree when fixing a metadata directory and vice-versa. Amend the scan predicate to check this condition. Cc: stable@vger.kernel.org # v6.13 Fixes: 4f3d4dd1b04b2b ("xfs: define the on-disk format for the metadir feature") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 1a5bcf87b6110f7dc52af2ab0b616dd3050f3613 Author: Darrick J. Wong Date: Mon Oct 12 23:08:51 2026 -0700 xfs: don't rescan ifree and icount when frozen commit 18028768415e3c05ab7edb22d740e2f4dc52836a upstream. LOLLM points out that it's pointless to rescan the AGs if we've already frozen the filesystem because there won't be any more perturbations. Fix this to mark the scan incomplete and exit. Cc: stable@vger.kernel.org # v5.2 Fixes: 75efa57d0bf5fc ("xfs: add online scrub for superblock counters") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 83b5bfa2400c5af79f869fb3ac79c2563871855f Author: Darrick J. Wong Date: Mon Oct 12 23:06:30 2026 -0700 xfs: don't queue rmap update twice when reaping a fork commit 219ff8a734d8438e24eb346a847c9b1ad9b7ab5d upstream. LOLLM noticed that xrep_reap_bmapi_iter calls xfs_bmap_unmap_extent and xfs_rmap_unmap_extent to remove a mapping from a file fork and its reverse mapping. However, xfs_bmap_del_extent_real also queues a deferred rmap removal log item, which means that we incorrectly queue two rmap removal operations. Fix that by removing the extra call and updating the comment to mention this subtlety that I forgot, having written the code. :P Cc: stable@vger.kernel.org # v6.10 Fixes: 5befb047b9f4de ("xfs: add the ability to reap entire inode forks") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 6b93f0aeb8815a3ad296492e97173f9fc137340e Author: Darrick J. Wong Date: Mon Oct 12 23:05:28 2026 -0700 xfs: don't overrun incore inode when cleaning attr forks commit c28b4b48deac17749ed1ebe4289a4ba73541ddc6 upstream. LOLLM noticed that xrep_dinode_check_afork doesn't check for a di_forkoff value that is so large that the attr fork would begin after the end of the inode space. This causes afork_{ptr,size} to be nonsense. What we really ought to do here is zap the attr fork. Cc: stable@vger.kernel.org # v6.8 Fixes: e744cef2060559 ("xfs: zap broken inode forks") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8310008293296958de8cbe6ed1856f71dff3e254 Author: Darrick J. Wong Date: Mon Oct 12 23:07:17 2026 -0700 xfs: don't clear COWEXTSIZE on directories on reflink filesystems commit 3978b1f3109dfd5c648442bb040f9abd58608226 upstream. LOLLM noticed that xrep_dinode_flags clears the COWEXTSIZE flag unnecessarily on directories on reflink filesystems. Directories just pass the hint along to new children, so it's valid to leave the flag set. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 7ba6cf053eaf1350e23c438a9d1576f620512998 Author: Darrick J. Wong Date: Sun Oct 4 22:57:22 2026 -0700 xfs: don't allow sm_agno for non-group metadir path checking commit 20c5a56bc4f2329872d21561e4a2d4b8576004c9 upstream. LOLLM noticed that the metadata directory tree path checker accepts non-zero values in the sm_agno field for non-group metadata. Make that case return -EINVAL. Cc: stable@vger.kernel.org # v6.13 Fixes: a74923333d9c3b ("xfs: scrub metadir paths for rtgroup metadata") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b5eb4ffd63fd2207568fcf2b76abffa86bbcf1ed Author: Darrick J. Wong Date: Mon Oct 12 08:23:43 2026 -0700 xfs: complain loudly when dirtree checker finds broken links commit e09438cab72c2c6a32665829d4186155346bfee8 upstream. LOLLM observed that the directory tree walk code bails out if it finds broken parent pointers along the way. However, it flattens the return code to zero, which means that we can end up in the repair code having not completed the scan. We should never proceed with a repair in this state, so let's mark the scrub incomplete and exit. Cc: stable@vger.kernel.org # v6.10 Fixes: 928b721a11789a ("xfs: teach online scrub to find directory tree structure problems") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 85975166223d129d8dcc74127ea9dcc01e951406 Author: Darrick J. Wong Date: Mon Oct 12 23:07:33 2026 -0700 xfs: clear set[ug]id mode bits when zapping attr fork commit eb20a959760c21e3547cd811d0d9b0b29df98959 upstream. LOLLM observes that zapping a file's attr fork could result in ACLs being removed from the file. Because we have no idea what we're deleting, we should clear the setuid and setgid bits in addition to the access mode bits so that nobody can access the file. Cc: stable@vger.kernel.org # v6.8 Fixes: e744cef2060559 ("xfs: zap broken inode forks") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit c73ee3683ab45eb70f65acb0c55c3a7cfe38c703 Author: Darrick J. Wong Date: Mon Oct 12 08:23:27 2026 -0700 xfs: clarify various parts of the bitmap API commit 00f32fdf54983371d39162efef7df693e2842ffb upstream. LOLLM pointed out some underspecified parts of the xbitmap{32,64} API. Specifically, the behavior of set/clear/test functions when the length parameter is zero is not well defined, nor is what happens when someone tries to disunion a bitmap with itself. None of these situations are expected, but we'll define zero-length set and clear to be nops, and the rest to be checked by assertions. Cc: stable@vger.kernel.org # v6.8 Fixes: 6ece924b952262 ("xfs: create separate structures and code for u32 bitmaps") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 27d1f450dec6ef87fcbcc7b3a72f41c1f34481e8 Author: Darrick J. Wong Date: Mon Oct 12 08:20:35 2026 -0700 xfs: check for termination during rmap btree walk commit 1fc241cdeab276dc6c3ec14840faa706ed7712ff upstream. LOLLM complains that we should check for a fatal signal *every* time we walk a record in the rmap btree as part of rebuilding the free space btrees. Fix that, and improve responsiveness to ^C of xfs_scrub. Cc: stable@vger.kernel.org # v6.8 Fixes: 4bdfd7d15747b1 ("xfs: repair free space btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 821a9d99caf16de8bd5298762b4463445adae39f Author: Darrick J. Wong Date: Mon Oct 12 23:07:01 2026 -0700 xfs: check for fragments when full-extent sharing matches commit 95e213c1ddb40dfb0a8178ed35c9f29992a320e1 upstream. LOLLM noticed that xchk_refcountbt_process_rmap_fragments returns early if there are enough rmap records that overlap the space referenced by a refcountbt record to match the refcount in that refcountbt record. Unfortunately, it never checks the fragment list in this case, so it won't find the discrepancy between the rmap and refcount btrees. Cc: stable@vger.kernel.org # v4.16 Fixes: dbde19da963706 ("xfs: cross-reference the rmapbt data with the refcountbt") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit f2cc5001ffcc1d8e5e16607ce4b6920ea30c2cfe Author: Aldo Ariel Panzardo Date: Wed Sep 23 08:57:44 2026 -0300 xfs: bound inode fork length against the fork size during log recovery commit 9232301894a06e664d8de2da97175cf98419bd16 upstream. xlog_recover_inode_commit_pass2() copies an inode log item's data/attr fork region into the inode buffer using the on-log region length without bounding it against the fork capacity, e.g.: len = item->ri_buf[2].iov_len; memcpy(XFS_DFORK_DPTR(dip), src, len); The only guard is an ASSERT, which is a no-op on production kernels (CONFIG_XFS_DEBUG off), and xfs_dinode_verify() runs only after the copy. A crafted image with a dirty log can therefore drive a heap out-of-bounds write at mount time. The XFS_ILOG_DBROOT sibling already passes XFS_DFORK_DSIZE as a bound; the DDATA/DEXT and ADATA/AEXT memcpy paths did not. Bound each logged fork region against the destination fork size before copying it, and reject the log item with -EFSCORRUPTED when it does not fit. Because the recovered inode is only verified after the fork data has been copied in, the checks are done up front, before any memcpy into the on-disk inode. Fixes: 658fa68b6f34 ("xfs: refactor log recovery inode item dispatch for pass2 commit functions") Cc: stable@vger.kernel.org # v5.8 Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 5909f2935ca2897b51800d00f58a48605253ef4b Author: Aldo Ariel Panzardo Date: Wed Sep 23 08:57:54 2026 -0300 xfs: bound da-node entry count against the correct geometry commit 3df5e5aaa3bc0913236c48ab29b7df3a785aa29f upstream. xfs_da3_node_verify() bounds the node entry count against the larger of the directory and attribute geometries because, as a buffer verifier, it cannot tell whether the block belongs to the directory or the attribute tree. When the directory block size exceeds the fs block size (e.g. mkfs.xfs -n size=64k -b size=4k), an attribute node buffer is a single fs block that holds only m_attr_geo->node_ents entries, yet a crafted attr node may claim a count up to m_dir_geo->node_ents and still pass the verifier. xfs_da3_node_lookup_int() then indexes btree[] up to that count during its binary search -- an out-of-bounds read via getxattr/listxattr on a mounted crafted image. The buffer verifier is the wrong place to tighten this: it has no fork context, and the transaction-less read path used by getxattr does not run xfs_da3_node_set_type() either. xfs_da3_node_lookup_int(), on the other hand, always runs on that path and holds args->geo, the geometry of the fork actually being searched. Bound the entry count against args->geo->node_ents there, before walking the entries. Fixes: 7ab610f9e0f1 ("xfs: move node entry counts to xfs_da_geometry") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit bd805c0a79143baca5104d9f6607b2c35efcdb1e Author: Darrick J. Wong Date: Sun Oct 4 22:58:09 2026 -0700 xfs: always zero the whole shortform header when zeroing attr fork commit 52aa50cea408e27454d206cccecbe4f694a6c1e1 upstream. LOLLM noticed that xrep_xattr_fork_remove can decide to reset the attr fork contents to an empty shortform header, but then fails to zero the padding byte in the header. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: e47dcf113ae348 ("xfs: repair extended attributes") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit e1903c3144d8ce946c64e7ce2fd3393d05191643 Author: Darrick J. Wong Date: Mon Oct 12 23:08:04 2026 -0700 xfs: always report scrub errors in tracepoints commit 1ccc8f553d885d49c1bfe141ea1f331511940b3a upstream. LOLLM complains that the error processing functions in scrub will sometimes zero out *error before recording a tracepoint. This makes diagnosing problems harder, so let's fix that. Cc: stable@vger.kernel.org # v4.15 Fixes: 4700d22980d459 ("xfs: create helpers to record and deal with scrub problems") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 782bcf8c6d3683f91cd40cd6cc169eb62106da4e Author: Darrick J. Wong Date: Mon Oct 12 08:22:09 2026 -0700 xfs: always report inode repair setup failures commit ce9098338a7e1a77246684242d10779fc4d4a539 upstream. LOLLM noticed that xchk_setup_inode silently discards errors being returned by xrep_setup_inode. Fix that, and fix the stub macro so that it actually "returns" a value. Cc: stable@vger.kernel.org # v6.8 Fixes: 2d295fe65776d1 ("xfs: repair inode records") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8cce27911eb3f8bb16f04b0a913277de6b7506b4 Author: Darrick J. Wong Date: Sun Oct 4 22:58:25 2026 -0700 xfs: always forget cached ACLs if the attr fork swap succeeds commit 41ee987f53785b9443388a756912b1a0fe3c9592 upstream. LOLLM complains that xrep_xattr_rebuild_tree omits the xfs_forget_acl call if the attr fork swap succeeds (and hence the acls might have changed) but reaping the old attr fork fails. Fix it so that we always purge the cached acls if the swap succeeds, even if subsequent steps do not. This avoids some cache coherency problems with access controls. Cc: stable@vger.kernel.org # v6.10 Fixes: e47dcf113ae348 ("xfs: repair extended attributes") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 4b4979ebf938728ef577803f73c0d10e6d2cb4d2 Author: Darrick J. Wong Date: Mon Oct 12 08:21:07 2026 -0700 xfs: abort directory tree repair whenever dl->aborted is set commit 4582327e7068194d55941b49dd66be211b9e3f90 upstream. LOLLM observed that if the live update hooks for the directory tree repair code ever fail, they'll set dl->aborted, but then the main repair code path won't check it to exit early. This can cause incorrect repairs, so let's check for hook errors and abort the repair. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit c548d0de41b0ffc142af218ee0c7e3231d8aee35 Author: Darrick J. Wong Date: Mon Oct 12 23:09:38 2026 -0700 xfs: update quota flags on secondary supers when metadir enabled commit 9d9ea6e6cbc4cb1a36fb79f873d97e1ac2fe1a64 upstream. xfs/085 exposes an interesting bug when metadir is enabled, quotas are enabled via mount option, and the primary superblock crc fails validation: Phase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... quota accounting and enforcement flags lost Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 unexpected regular file inode 16908418 with metadata flag will zap cleared inode 16908418 unexpected regular file inode 16908419 with metadata flag will zap cleared inode 16908419 unexpected regular file inode 16908420 with metadata flag will zap cleared inode 16908420 - agno = 3 - process newly discovered inodes... Quota files have been created, but xfs_repair thinks that quotas aren't enabled and trashes the quota files. Looking at the filesystem reveals that the quota accounting flags were indeed persisted to the primary superblock but not the secondary: # xfs_db -c 'sb 0' -c 'print qflags' -c 'sb 1' -c 'print qflags' /dev/sdf Metadata corruption detected at 0x561c68436080, inode 0x81 dinode xfs_db: Failed to load metadir root directory, error 117 Metadata corruption detected at 0x561c683f7c80, xfs_agf block 0x1/0x200 xfs_db: cannot init perag data (117). Continuing anyway. Metadata CRC error detected at 0x561c6844d1b5, xfs_sb block 0x0/0x200 qflags = 0x7cf qflags = 0 On a metadir filesystem, quota state is supposed to persist across mount cycles if the sysadmin doesn't provide any quota mount options. Therefore, any time we update the quota flags on a metadir filesystem, we should write the same change to the secondary supers so that xfs_repair will find the quota data if it ever has to restore from a secondary. Cc: stable@vger.kernel.org # v6.13 Fixes: d5d9dd5b3026a8 ("xfs: persist quota flags with metadir") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 96a80a3312b433a79eaffa55250071640140f902 Author: Darrick J. Wong Date: Mon Oct 12 23:09:07 2026 -0700 xfs: rescan the AGs if incore delalloc counter is negative commit 47b1e941bb55f735d82ba2649412260da78b98f8 upstream. LOLLM complains that percpu_counter_sum can return a negative number but we instead misinterpret that into a huge unsigned value and do bad things to fdblocks. It shouldn't do that, so let's add a retry loop and an attempt to freeze the filesystem to (hopefully) zero out the incore delalloc counter. It probably won't work, but at least failing the repair beats doing the wrong thing. Cc: stable@vger.kernel.org # v5.2 Fixes: 75efa57d0bf5fc ("xfs: add online scrub for superblock counters") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 741d01a5f49023bf10071ab4a0fc144ddd4766d5 Author: Darrick J. Wong Date: Sun Oct 4 22:57:53 2026 -0700 xfs: release ip after unlinked list store failure commit 9a263723d7c9ab0615bab3f5cc145d3d24454a5c upstream. If, while processing an unlinked list we see an inode that has nonzero link count, we fail to store the incore prev/next pointers, we should release the incore inode instead of leaking it. This was in the llm fixes branch but fell out for -rc7. Weird. Cc: stable@vger.kernel.org # v7.2-rc7 Fixes: 0052633527158b ("xfs: don't ignore runtime errors in xrep_iunlink_reload_next") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 97b85a593188f63e133883525c9159f77e660197 Author: Aldo Ariel Panzardo Date: Wed Sep 23 08:58:23 2026 -0300 xfs: reject remote xattr entries with an out-of-range value length commit 15ccd92a782a0253f4a17895f3d3f71e5c1d1973 upstream. xfs_attr3_leaf_verify_entry() validates a remote attribute entry's name but never bounds its on-disk value length (xfs_attr_leaf_name_remote. valuelen, a __be32). A crafted leaf with valuelen = 0x80000000 passes the verifier and the CRC. That length is later assigned into the signed int args->rmtvaluelen (xfs_attr3_leaf_getvalue), becoming negative, which slips past the signed -ERANGE check in xfs_attr_copy_value(); a getxattr() with a small buffer then memcpy()s a full remote block into the small kvalue buffer (xfs_attr_rmtval_copyout) -- a heap out-of-bounds write with attacker-controlled content, from an unprivileged getxattr(2) on a mounted crafted image. Reject remote entries whose value length exceeds XFS_XATTR_SIZE_MAX in the leaf verifier, so the malicious block is rejected at read time. Fixes: c84760659dcf ("xfs: check attribute leaf block structure") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit c2cd6b3b480ef2ae9752ed924a2199c8c90569a1 Author: Aldo Ariel Panzardo Date: Wed Sep 23 08:58:22 2026 -0300 xfs: reject out-of-range attribute value lengths in xfs_attr_copy_value commit 0643549ffecaeb716c0b75590a9b76dfa5eb35b3 upstream. xfs_attr_copy_value() takes the value length as a signed int and, for a remote xattr, is handed args->rmtvaluelen. That field is filled from the on-disk __be32 xfs_attr_leaf_name_remote.valuelen in xfs_attr3_leaf_getvalue(), so a crafted length such as 0x80000000 is stored into the signed rmtvaluelen as a negative number. The "buffer too small" guard in xfs_attr_copy_value() is a signed comparison: if (args->valuelen < valuelen) return -ERANGE; A negative valuelen therefore compares as smaller than the caller's buffer size, skips the -ERANGE path, and is then used as a copy length, leading to an out-of-bounds copy of a full remote block into a small getxattr(2) buffer on a mounted crafted image. Reject a value length that is negative or larger than the maximum xattr size before it is used, so a bogus on-disk length can no longer slip through the value copier. Fixes: 9df243a1a9e6 ("xfs: consolidate attribute value copying") Cc: stable@vger.kernel.org Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 5e730e4a26c4242d9deac359e4bd1dd41c06acaf Author: Darrick J. Wong Date: Mon Oct 12 08:22:41 2026 -0700 xfs: reject absurdly large xattr value lengths in xchk_xattr_actor commit fd012955641881169a9f01a00f656f6ca73842ec upstream. LOLLM suggests that we shouldn't try to allocate absurdly large buffers for xattr value checks because that will push reclaim very hard, never succeed, and is pointless because nobody can create xattrs that large. Since the xattr repair code ignores values larger than XATTR_SIZE_MAX, we can flag the corruption and return early. Cc: stable@vger.kernel.org # v5.3 Fixes: 6d6ccedd76823c ("xfs: only allocate memory for scrubbing attributes when we need it") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit de55e799f549e9aa0f7899dcb03a2a816df2d87b Author: Darrick J. Wong Date: Mon Oct 12 23:06:14 2026 -0700 xfs: reduce new btree slack factor if free space is negative commit 80f13dc7225eec318da7499c7a562d7a34d25e6a upstream. LOLLM points out that if the incore fdblocks counter is negative, the assignment to uint64_t will mask this possibly low space situation and we don't pack the btree blocks as tightly as we probably ought to. If it's the case that there's some free space and fdblocks is too low due to an error in the superblock field, then we can end up failing btree rebuilds due to ENOSPC unnecessarily. This is a corner case, but let's fix it anyway. Cc: stable@vger.kernel.org # v6.8 Fixes: be408417630427 ("xfs: implement block reservation accounting for btrees we're staging") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 42451fefb076230cdeac1da4e85b08e18af67d18 Author: Aleksandr Nogikh Date: Mon Nov 2 17:14:49 2026 -0500 media: usbtv: fix null-pointer dereference on disconnect [ Upstream commit cb705f75d03e946a4514488beb9e3bac9bcdb2e6 ] A null-pointer dereference can occur in usb_make_path() when called from usbtv_querycap() (and other ioctl handlers) during device disconnection. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057] RIP: 0010:usb_make_path include/linux/usb.h:985 [inline] RIP: 0010:usbtv_querycap+0x9c/0x100 drivers/media/usb/usbtv/usbtv-video.c:612 ... Call Trace: v4l_querycap+0x236/0x470 drivers/media/v4l2-core/v4l2-ioctl.c:1106 __video_do_ioctl+0x8af/0xc70 drivers/media/v4l2-core/v4l2-ioctl.c:3133 video_usercopy+0x860/0x1430 drivers/media/v4l2-core/v4l2-ioctl.c:3475 v4l2_ioctl+0x18d/0x1e0 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 This happens due to a race condition between the USB device disconnect routine (usbtv_disconnect()) and V4L2 ioctls. When the device is disconnected, usbtv_disconnect() sets usbtv->udev = NULL without holding the usbtv->v4l2_lock mutex. Concurrently, an ioctl handler like usbtv_querycap() can be executing under the v4l2_lock and attempt to use usbtv->udev, leading to a crash. To fix this, move the usbtv->udev = NULL assignment into usbtv_video_free() and protect it with mutex_lock(&usbtv->v4l2_lock). This ensures that no non-queue ioctl handler can run concurrently with the pointer being nullified. If an ioctl is already running, the mutex will block the disconnect path until the ioctl finishes. If an ioctl is blocked waiting for the lock, it will acquire it after the disconnect routine releases it, but will then check video_is_registered() (which was cleared by vb2_video_unregister_device()) and safely return -ENODEV. Acquiring v4l2_lock after vb2_video_unregister_device() avoids reintroducing a historical deadlock issue, and usbtv_audio_free() remains safe as it is called before usbtv_video_free(). Fixes: 65e6a2773d65 ("media: usbtv: Remove useless locks in usbtv_video_free()") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.6-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+37a57a84893052ab6071@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=37a57a84893052ab6071 Link: https://syzkaller.appspot.com/ai_job?id=5abbe65a-5853-4bc2-9135-5c75f88d51ed Signed-off-by: Aleksandr Nogikh Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f9362852c8b91f76fdf182d7961bf345cc30021a Author: Johan Hovold Date: Mon Nov 2 17:14:48 2026 -0500 media: usbtv: drop redundant device reference [ Upstream commit dbc6798b80481a20f9aff671bc4d529eae63c9e8 ] Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. Drop the redundant device reference to reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of memory leaks when drivers fail to release it. Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Stable-dep-of: cb705f75d03e ("media: usbtv: fix null-pointer dereference on disconnect") Signed-off-by: Sasha Levin commit 9d275d40b6ece705ba1f10410883b6c374b9e24b Author: Hazem Mohamed Abuelfotoh Date: Tue Nov 3 17:45:41 2026 +0000 Revert "net: Convert proto_ops bind() callbacks to use sockaddr_unsized" Revert commit 946dc5835c8fbe5eb5ceb13f5717778911ff4586 which is commit 0e50474fa514822e9d990874e554bf8043a201d7 upstream. Commit 946dc5835c8f ("net: Convert proto_ops bind() callbacks to use sockaddr_unsized") is a backport of upstream commit 0e50474fa514. It was queued for v6.18.57 only as a Stable-dep-of commit 56e78b670356 ("Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback"), but it is not a dependency of that fix: - Commit 56e78b670356 ("Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback") touches only net/bluetooth/hci_sync.c. Commit 0e50474fa514 ("net: Convert proto_ops bind() callbacks to use sockaddr_unsized") changes 74 files and none of them is net/bluetooth/hci_sync.c. - The same fix went into 6.12.y as commit 117d8bcaf1ab ("Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback") without commit 0e50474fa514 ("net: Convert proto_ops bind() callbacks to use sockaddr_unsized"). Its +/- lines are identical to the 6.18.y version, commit ff5625d27415 ("Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback"). - Commit ff5625d27415 ("Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback") cherry-picks cleanly onto the parent of commit 946dc5835c8f ("net: Convert proto_ops bind() callbacks to use sockaddr_unsized"), and the resulting net/bluetooth/hci_sync.c matches the one in v6.18.57. Upstream commit 0e50474fa514 ("net: Convert proto_ops bind() callbacks to use sockaddr_unsized") carries no Fixes: or Cc: stable tag. It is an API conversion ("No binary changes expected"), not a fix. It also needed non-trivial adaptation for 6.18.y. Commit bf33247a90d3 ("net: Add struct sockaddr_unsized for sockaddr of unknown length") is not in 6.18.y, so the backport adds its own definition of struct sockaddr_unsized to include/linux/socket.h. The result is a half-converted in-kernel socket API, which no mainline release ever had: kernel_bind() kernel_connect() v6.18.56 struct sockaddr * struct sockaddr * v6.18.57+ struct sockaddr_unsized * struct sockaddr * v6.19 struct sockaddr_unsized * struct sockaddr_unsized * Code that probes for struct sockaddr_unsized via kernel_bind() and then assumes the mainline (v6.19+) kernel_connect() signature breaks on 6.18.57+ with -Werror=incompatible-pointer-types. Nothing in 6.18.y after v6.18.57 depends on this commit. With it reverted on top of v6.18.59, the tree contains no references to struct sockaddr_unsized. Signed-off-by: Hazem Mohamed Abuelfotoh Signed-off-by: Sasha Levin commit 47c65443173086a38726770178e55d3d59b71bc6 Author: Jean Delvare Date: Tue Nov 3 17:04:39 2026 +0100 EDAC/mc: Really fix error path ordering in edac_mc_alloc() The backport of 51520e03e70d ("EDAC/mc: Fix error path ordering in edac_mc_alloc()") to stable kernel branches is incomplete due to a different memory allocation scheme. In v6.19 and earlier, the device initialization must be moved further up so that all jumps to the error label are covered. Signed-off-by: Jean Delvare Cc: stable@kernel.org # v6.19- Signed-off-by: Sasha Levin commit 9e3a6b707681a6291a410d1b7ce15840a9912a86 Author: Andrea Parri Date: Thu Oct 1 16:30:39 2026 +0200 rtnetlink: wait for RCU readers in rtnl_link_unregister() [ Upstream commit 3b70edea393de445255da6c706eebb823117a955 ] rtnl_link_ops_get() finds ops on link_ops under rcu_read_lock() and only then takes ops->srcu. rtnl_link_unregister() unlinks ops, then calls synchronize_srcu() and cleanup_srcu_struct() without first waiting for RCU readers. A reader that found ops before list_del_rcu() and has not yet taken ops->srcu is not waited for. Such a reader then locks a cleaned-up srcu_struct and keeps using ops after the module that owns it is gone. rtnl_newlink() and rtnl_dump_ifinfo() both look up ops without RTNL, the latter for any user that dumps links filtered by kind. With delays added between the lookup and srcu_read_lock() in rtnl_link_ops_get(), and before rtnl_link_ops_put() in rtnl_dump_ifinfo(), running "ip link show type dummy" alongside "rmmod dummy" on a KASAN kernel gives: BUG: KASAN: vmalloc-out-of-bounds in __srcu_read_unlock+0x57/0x70 Read of size 8 at addr ffffffffc02ff318 by task ip/147 Call Trace: __srcu_read_unlock+0x57/0x70 rtnl_dump_ifinfo.cold+0x30/0x3b rtnl_dumpit+0x7a/0x1b0 netlink_dump+0x486/0x11b0 __netlink_dump_start+0x661/0x910 rtnetlink_rcv_msg+0x611/0x9e0 netlink_rcv_skb+0x126/0x380 netlink_unicast+0x605/0x830 netlink_sendmsg+0x6d0/0xbb0 __sys_sendto+0x335/0x3a0 Call synchronize_rcu() before synchronize_srcu(), as rtnl_af_unregister() already does. This should be enough because rtnl_link_ops_get() is the only RCU walker of link_ops, and it takes ops->srcu before rcu_read_unlock(), so every reader that found ops is covered by synchronize_srcu() once the RCU grace period ends. The extra grace period only costs time at module unload. Readers and the writer were serialized by RTNL until link_ops got its own mutex, which is why the missing RCU wait did not matter before. Cc: stable+noautosel@kernel.org # needs real net-admin (non-ns) Fixes: 6b57ff21a310 ("rtnetlink: Protect link_ops by mutex.") Reviewed-by: Eric Dumazet Signed-off-by: Andrea Parri Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20261001143040.28467-1-parri.andrea@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0bc2d40b9c01be44ecc73435038c32ccf4b3a692 Author: Joseph Qi Date: Tue Nov 3 19:08:03 2026 +0800 ksmbd: fix breaking_cnt leak on early return in oplock_break() For leases, oplock_break() increments breaking_cnt before calling oplock_break_pending(), and returns early when the pending check reports nothing to break: the level is already at or below the requested level and, for a lease, the state is not HANDLE|READ caching. Neither early return decrements the counter, and wait_lease_breaking(), the only place that force-clears it, sits below those returns, so breaking_cnt stays elevated for the life of the open. A stuck breaking_cnt makes same_client_has_lease() skip lease upgrades forever, and every subsequent same-client CREATE on that lease is answered with SMB2_LEASE_FLAG_BREAK_IN_PROGRESS, so the client never resumes caching. The ordering dates back to the original SMB3 server code, but the early return became routinely reachable for leases already broken to NONE when smb_break_all_levII_oplock() stopped filtering out non-level-II leases in 17699905a381, "ksmbd: fix lease break and ack state handling". Move the increment below the pending check so the early returns cannot strand the counter. This is the minimal equivalent of the reorder that mainline made in b0148dc5625d, "ksmbd: serialize oplock close with pending break ownership". Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Joseph Qi Signed-off-by: Sasha Levin commit 818a9fd779443b931b05c025d85f29680efb26c2 Author: Yongjun Gwon Date: Mon Nov 2 17:15:26 2026 -0500 ksmbd: serialize directory emptiness checks with readdir [ Upstream commit 7220980b2423d06a0604516129bfa4cec8a697ae ] SMB2 QUERY_DIRECTORY holds fp->readdir_lock while it calls iterate_dir() on fp->filp. An SMB2 SET_INFO request with FILE_DISPOSITION_INFORMATION can resolve the same FileId and call ksmbd_vfs_empty_dir() on the same filp without that lock. iterate_dir()'s inode read lock permits concurrent readers and does not serialize per-file iterator state. ext4 stores its dx readdir cursor and fname RB tree in file->private_data. Concurrent reset or refill can therefore free a fname node while the other worker still traverses it or retains its RB-tree link, resulting in use-after-free accesses. An authenticated SMB client with list and delete rights on a directory in a writable KSMBD share backed by ext4 can trigger this when the directory takes the dx readdir path. The client overlaps an SMB2 QUERY_DIRECTORY request with an SMB2 SET_INFO request carrying FILE_DISPOSITION_INFORMATION on one live FileId. In one x86_64 SMP KASAN multi-shot guest using ksmbd-for-next at 171df27077fb, the unmodified kernel reported a cross-worker use-after-free before a panic. The first report's access and free stacks show the two request paths directly (trimmed): BUG: KASAN: slab-use-after-free in ext4_htree_store_dirent+0x488/0x550 Read of size 8 by task kworker/2:0/29 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ext4_htree_store_dirent+0x488/0x550 htree_dirblock_to_tree+0x535/0x990 ext4_htree_fill_tree+0x319/0xba0 ext4_readdir+0x175a/0x2f40 iterate_dir+0x1b6/0x630 smb2_query_dir+0x1003/0x1cc0 Freed by task 279: free_rb_tree_fname+0x67/0xc0 ext4_readdir+0x13a9/0x2f40 iterate_dir+0x1b6/0x630 ksmbd_vfs_empty_dir+0xa2/0x100 smb2_set_info+0x2ffa/0x45d0 Take fp->readdir_lock across the entire emptiness check. This places both iterators over that handle's filp in the same lock domain while preserving the disposition status handling. The exact code change completed a warning-free x86_64 KASAN bzImage build. Tracing three request pairs showed that the two iterate_dir() calls no longer overlapped and the expected statuses were preserved. A further 1,600 reproducer iterations completed with expected statuses and no KASAN report, Oops, or panic. The reproducer and complete guest configuration are available privately to maintainers on request. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Yongjun Gwon Signed-off-by: Namjae Jeon [ sashal: adjusted set_file_disposition_info() context for the existing directory condition and older oplock/delete-pending helpers ] Signed-off-by: Sasha Levin commit 8fd7a71a70955fce73f75911799a43c8fcb7a7f9 Author: Florian Westphal Date: Wed Apr 29 08:21:35 2026 +0200 netfilter: nf_tables: fix netdev hook allocation memleak with dormant tables [ Upstream commit 63bac027860308d1344f761cb47aabb3b30973fd ] sashiko says: could the related code in __nf_tables_abort() leak the struct nft_hook objects when the table is dormant? In __nf_tables_abort(), when rolling back a NEWCHAIN transaction that updates hooks, the code conditionally unregisters and frees the hooks only if the table is not dormant [..] if (!(table->flags & NFT_TABLE_F_DORMANT)) { nft_netdev_unregister_hooks(net, &nft_trans_chain_hooks(trans), true); } ... nft_trans_destroy(trans); Unfortunately netdev family mixes hook registration and allocation. Push table struct down and only check for the flag to unregister. Fixes: 216e7bf7402c ("netfilter: nf_tables: skip netdev hook unregistration if table is dormant") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d1f2c892c6cb5801a51817b12bd0326b22b27880 Author: Florian Westphal Date: Sat Sep 5 07:01:50 2026 +0200 netfilter: nft_payload: restrict checksum offsets to known values [ Upstream commit c2226f0c7fe90b67732e5ae36dc5c3cc01ddf888 ] We need to prevent userspace from corrupting e.g. tcp->doff, because many locations in conntrack and conntrack helpers rely on nf_conntrack_in() having validated the packet headers. nft_payload allows to alter headers later which invalidates this assumption. The 'Fixes' commit restricts writes to safe fields, but there is another side channel: the checksum location. Restrict this too. Reported via sashiko/gemini. Fixes: 112e447d17f7 ("netfilter: validate L4 headers after userspace packet writes") Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 3199bbed3a0bdf72bf294c61eb540472ac4fb6a2 Author: Zhiling Zou Date: Mon Aug 3 09:11:23 2026 +0800 netfilter: validate L4 headers after userspace packet writes [ Upstream commit 112e447d17f78d08485b3076a8baa1dfb9794bd8 ] NFQUEUE and nft_payload can hand packet data modified by userspace back to the stack. Recent restrictions keep link and network headers stable, but transport header fields can still be changed. A packet can therefore keep the same network header and conntrack entry while changing the transport header layout. For TCP, increasing doff can make later helper or NAT code use a different transport-header base than the parser used, and can make offsets point past skb->tail. Extend NFQUEUE payload validation to check the final L4 protocol and known base headers after IPv4 options or IPv6 extension headers. Reject packets whose L4 protocol no longer matches an attached non-template conntrack entry, and reject IP fragments that already have such a conntrack entry before trying to validate transport headers. Unknown L4 protocols are left to their normal protocol handlers. For nft payload writes, reject transport-header stores that overlap TCP doff. nft_nh_write_ok() already rejects network-header protocol changes, so keeping doff stable prevents nft payload writes from changing the TCP header length underneath conntrack and helper users. This patch is a follow up to commit df07998dfd40 ("netfilter: nftables: restrict linklayer and network header writes") and commit 54f34607d184 ("netfilter: nfnetlink_queue: restrict writes to network header"). Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 593971fdc06d6e17685e5aeb1be4a2ab6657a64b Author: Florian Westphal Date: Tue Jun 9 13:51:55 2026 +0200 netfilter: nftables: restrict checkum update offset [ Upstream commit c3716a3c43465641ded6e01c0b187de42e87a80d ] After previous patch, writes to network header are restricted. However, there is another way to manipulate the l3 header: The checksum update function. Restrict this for network header writes, only the ipv4 header is allowed. This needs run-time checks because BRIDGE, INET, NETDEV families can carry l3 headers other than IP. checksum updates to the udp/tcp (l4) headers are not restricted. Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit fe189691a7938dfc901d64195bdbb29ca2ab8a40 Author: Florian Westphal Date: Tue Jun 9 13:51:54 2026 +0200 netfilter: nftables: restrict linklayer and network header writes [ Upstream commit df07998dfd40796a05fff7ffea2661ad65ed42a7 ] Don't permit arbitrary writes to linklayer and network header data. Several spots in network stack trust header validation performed in ipv4/ipv6 before PRE_ROUTING hook. For linklayer, allow writes for netdev ingress. For other hooks, only allow link layer writes that do not spill into network header. For network header, check the offset/length combinations: - changing dscp requires store at offset 0 for checsum fixups, so make sure ip version + length field isn't altered. - ip6 dscp starts directly after the version field, so make sure it remains 6. Several of these checks could already be done at rule insertion time. Risk is that this might cause ruleset load failures for existing rulesets. With this change such writes are silently skipped and packet passes unchanged. Transport and inner header bases are not checked / restricted. Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 9b02841c69dc59652c86e8d3a7858de8469daeae Author: Pablo Neira Ayuso Date: Sun Mar 22 23:51:47 2026 +0100 netfilter: nft_meta: add double-tagged vlan and pppoe support [ Upstream commit 3785091c6c16a1ce4a5e0460881fc81ed8d2c8a1 ] Currently: add rule netdev x y ip saddr 1.1.1.1 does not work with neither double-tagged vlan nor pppoe packets. This is because the network and transport header offset are not pointing to the IP and transport protocol headers in the stack. This patch expands NFT_META_PROTOCOL and NFT_META_L4PROTO to parse double-tagged vlan and pppoe packets so matching network and transport header fields becomes possible with the existing userspace generated bytecode. Note that this parser only supports double-tagged vlan which is composed of vlan offload + vlan header in the skb payload area for simplicity. NFT_META_PROTOCOL is used by bridge and netdev family as an implicit dependency in the bytecode to match on network header fields. Similarly, there is also NFT_META_L4PROTO, which is also used as an implicit dependency when matching on the transport protocol header fields. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 40089f2f78aa95fc9fb9c35ee550a70d3f21ef06 Author: Florian Westphal Date: Tue Jun 9 13:51:53 2026 +0200 netfilter: nfnetlink_queue: restrict writes to network header [ Upstream commit 54f34607d184c1cc056c59a5b3d86d96dd6a515c ] nfnetlink_queue doesn't allow selective replacements of some part of the payload, only complete replacement. If the new data is shorter, skb is trimmed, otherwise expanded. Add minimal validation of the new ip/ipv6 header. Check total len matches skb length. Disallow ip option modifications. IPv6 extension headers are also disabled. IP options and exthdrs could be allowed later after validation pass or ip option recompile. Transport header is not checked. Bridge modifications are rejected. Given userspace doesn't even receive L2 headers, use is limited and I don't think there are any users of bridge nfnetlink_queue, let alone users that modifiy payload. Arp isn't supported at all. Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 819b2241c43e6bbd9dbca9301d5ca557b2ff1a57 Author: Daniel Borkmann Date: Wed Apr 29 17:46:48 2026 +0200 ipv6: Implement limits on extension header parsing [ Upstream commit 3744b0964d5267c0b651bcd8f8c25db6bf4ccbac ] ipv6_{skip_exthdr,find_hdr}() and ip6_{tnl_parse_tlv_enc_lim, protocol_deliver_rcu}() iterate over IPv6 extension headers until they find a non-extension-header protocol or run out of packet data. The loops have no iteration counter, relying solely on the packet length to bound them. For a crafted packet with 8-byte extension headers filling a 64KB jumbogram, this means a worst case of up to ~8k iterations with a skb_header_pointer call each. ipv6_skip_exthdr(), for example, is used where it parses the inner quoted packet inside an incoming ICMPv6 error: - icmpv6_rcv - checksum validation - case ICMPV6_DEST_UNREACH - icmpv6_notify - pskb_may_pull() <- pull inner IPv6 header - ipv6_skip_exthdr() <- iterates here - pskb_may_pull() - ipprot->err_handler() <- sk lookup The per-iteration cost of ipv6_skip_exthdr itself is generally light, but skb_header_pointer becomes more costly on reassembled packets: the first ~1232 bytes of the inner packet are in the skb's linear area, but the remaining ~63KB are in the frag_list where skb_copy_bits is needed to read data. Initially, the idea was to add a configurable limit via a new sysctl knob with default 8, in line with knobs from commit 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination options"), but two reasons eventually argued against it: - It adds to UAPI that needs to be maintained forever, and upcoming work is restricting extension header ordering anyway, leaving little reason for another sysctl knob - exthdrs_core.c is always built-in even when CONFIG_IPV6=n, where struct net has no .ipv6 member, so the read site would need an ifdef'd fallback to a constant anyway Therefore, just use a constant (IP6_MAX_EXT_HDRS_CNT). All four extension header walking functions are now bound by this limit. Note that the check in ip6_protocol_deliver_rcu() happens right before the goto resubmit, such that we don't have to have a test for ipv6_ext_hdr() in the fast-path. There's an ongoing IETF draft-iurman-6man-eh-occurrences to enforce IPv6 extension headers ordering and occurrence. The latter also discusses security implications. As per RFC8200 section 4.1, the occurrence rules for extension headers provide a practical upper bound which is 8. In order to be conservative, let's define IP6_MAX_EXT_HDRS_CNT as 12 to leave enough room for quirky setups. In the unlikely event that this is still not enough, then we might need to reconsider a sysctl. Signed-off-by: Daniel Borkmann Reviewed-by: Ido Schimmel Reviewed-by: Eric Dumazet Reviewed-by: Justin Iurman Link: https://patch.msgid.link/20260429154648.809751-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 65367b0545955c945739a3fb193186f04fa01e24 Author: Florian Westphal Date: Sat May 16 23:23:21 2026 +0800 netfilter: disable payload mangling in userns [ Upstream commit 968cc2c96390f06e56ed6a43f935bfebdefed28f ] Several parts of network stack rely on iph->ihl validation done by network stack before PRE_ROUTING. Disable this feature for user namespaces for now. tcp option handling is likely safe even for LOCAL_IN, so this this leaves tcp option mangling via nft_exthdr.c as-is. I don't think these are the only means to alter packets, but these appear to be relatively prominent. This could be relaxed later. Example: - allow userns for ingress hook. - allow userns if base is transport header. Also, we should revalidate or restrict generally: - Don't allow linklayer writes to spill into network header - restrict ipv4 and ipv6 to 'known safe' writes, e.g. saddr/daddr/check/tos Reported-by: Qi Tang Reported-by: Tong Liu Tested-by: Qi Tang Link: https://lore.kernel.org/netfilter-devel/20260515100411.3141-1-fw@strlen.de/ Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 03c67f33c3d9ee28842aef2ed39e582751be3f1f Author: Cheng-Yang Chou Date: Tue Nov 3 19:07:49 2026 +0000 sched_ext: Fix scx_flush_disable_work() UAF race [ Upstream commit d99f7a32f09dccbe396187370ec1a74a31b73d7e ] scx_flush_disable_work() calls irq_work_sync() followed by kthread_flush_work() to ensure that the disable kthread work has fully completed before bpf_scx_unreg() frees the SCX scheduler. However, a concurrent scx_vexit() (e.g., triggered by a watchdog stall) creates a race window between scx_claim_exit() and irq_work_queue(): CPU A (scx_vexit (watchdog)) CPU B (bpf_scx_unreg) ---- ---- scx_claim_exit() atomic_try_cmpxchg(NONE->kind) stack_trace_save() vscnprintf() scx_disable() scx_claim_exit() -> FAIL scx_flush_disable_work() irq_work_sync() // no-op: not queued yet kthread_flush_work() // no-op: not queued yet kobject_put(&sch->kobj) -> free %sch irq_work_queue() -> UAF on %sch scx_disable_irq_workfn() kthread_queue_work() -> UAF The root cause is that CPU B's scx_flush_disable_work() returns after syncing an irq_work that has not yet been queued, while CPU A is still executing the code between scx_claim_exit() and irq_work_queue(). Loop until exit_kind reaches SCX_EXIT_DONE or SCX_EXIT_NONE, draining disable_irq_work and disable_work in each pass. This ensures that any work queued after the previous check is caught, while also correctly handling cases where no disable was triggered (e.g., the scx_sub_enable_workfn() abort path). Fixes: 510a27055446 ("sched_ext: sync disable_irq_work in bpf_scx_unreg()") Reported-by: https://sashiko.dev/#/patchset/20260424100221.32407-1-icheng%40nvidia.com Suggested-by: Tejun Heo Signed-off-by: Cheng-Yang Chou Signed-off-by: Tejun Heo [ Sync error_irq_work instead of disable_irq_work. ] Signed-off-by: Kuba Piecuch Signed-off-by: Sasha Levin commit 92c9bc8561a7cb0274752b1409b2bb6a89d6ecc5 Author: Richard Cheng Date: Tue Nov 3 19:07:48 2026 +0000 sched_ext: sync disable_irq_work in bpf_scx_unreg() [ Upstream commit 510a27055446b8f0d29487ca8b8d2033dc2b6ca6 ] When unregistered my self-written scx scheduler, the following panic occurs. [ 229.923133] Kernel text patching generated an invalid instruction at 0xffff80009bc2c1f8! [ 229.923146] Internal error: Oops - BRK: 00000000f2000100 [#1] SMP [ 230.077871] CPU: 48 UID: 0 PID: 1760 Comm: kworker/u583:7 Not tainted 7.0.0+ #3 PREEMPT(full) [ 230.086677] Hardware name: NVIDIA GB200 NVL/P3809-BMC, BIOS 02.05.12 20251107 [ 230.093972] Workqueue: events_unbound bpf_map_free_deferred [ 230.099675] Sched_ext: invariant_0.1.0_aarch64_unknown_linux_gnu_debug (disabling), task: runnable_at=-174ms [ 230.116843] pc : 0xffff80009bc2c1f8 [ 230.120406] lr : dequeue_task_scx+0x270/0x2d0 [ 230.217749] Call trace: [ 230.228515] 0xffff80009bc2c1f8 (P) [ 230.232077] dequeue_task+0x84/0x188 [ 230.235728] sched_change_begin+0x1dc/0x250 [ 230.240000] __set_cpus_allowed_ptr_locked+0x17c/0x240 [ 230.245250] __set_cpus_allowed_ptr+0x74/0xf0 [ 230.249701] ___migrate_enable+0x4c/0xa0 [ 230.253707] bpf_map_free_deferred+0x1a4/0x1b0 [ 230.258246] process_one_work+0x184/0x540 [ 230.262342] worker_thread+0x19c/0x348 [ 230.266170] kthread+0x13c/0x150 [ 230.269465] ret_from_fork+0x10/0x20 [ 230.281393] Code: d4202000 d4202000 d4202000 d4202000 (d4202000) [ 230.287621] ---[ end trace 0000000000000000 ]--- [ 231.160046] Kernel panic - not syncing: Oops - BRK: Fatal exception in interrupt The root cause is that the JIT page backing ops->quiescent() is freed before all callers of that function have stopped. The expected ordering during teardown is: bitmap_zero(sch->has_op) + synchronize_rcu() -> guarantees no CPU will ever call sch->ops.* again -> only THEN free the BPF struct_ops JIT page bpf_scx_unreg() is supposed to enforce the order, but after commit f4a6c506d118 ("sched_ext: Always bounce scx_disable() through irq_work"), disable_work is no longer queued directly, causing kthread_flush_work() to be a noop. Thus, the caller drops the struct_ops map too early and poisoned with AARCH64_BREAK_FAULT before disable_workfn ever execute. So the subsequent dequeue_task() still sees SCX_HAS_OP(sch, quiescent) as true and calls ops.quiescent, which hit on the poisoned page and BRK panic. Add a helper scx_flush_disable_work() so the future use cases that want to flush disable_work can use it. Also amend the call for scx_root_enable_workfn() and scx_sub_enable_workfn() which have similar pattern in the error path. Fixes: f4a6c506d118 ("sched_ext: Always bounce scx_disable() through irq_work") Signed-off-by: Richard Cheng Reviewed-by: Andrea Righi Reviewed-by: Cheng-Yang Chou Signed-off-by: Tejun Heo [ 6.18.y has neither f4a6c506d118 nor sub-schedulers. Here, the flush is a no-op when scx_disable() loses the exit claim to scx_vexit(), whose error_irq_work queues disable_work later. Sync error_irq_work instead of disable_irq_work and drop the scx_sub_enable_workfn() hunk. ] Signed-off-by: Kuba Piecuch Signed-off-by: Sasha Levin commit f799665b9c8dc07e865263f43ca23a5105b29488 Author: Darrick J. Wong Date: Thu Sep 24 21:11:17 2026 -0700 xfs: fix xchk_stats_estimate_bufsize to allow for the trailing null commit 6b8d60784b61a17bd591cb4c6e8aa9ed29c24f5c upstream. LOLLM complains that xchk_stats_estimate_bufsize underestimates the buffer size by 1 byte because scnprintf wants to store a null byte after the newline in each line. Each call to scnprintf overwrites the null left by the previous call, but we still need the null byte for the last line in the file. Cc: stable@vger.kernel.org # v6.6 Fixes: d7a74cad8f4513 ("xfs: track usage statistics of online fsck") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 7f25f443a4a6156ad706aafc3b76ef0d842eea68 Author: Darrick J. Wong Date: Thu Sep 24 21:11:01 2026 -0700 xfs: actually check XFS_DIFLAG2_METADATA for metadata btree data forks commit 436ae68743a6974021fefa21fd3093d9bf8e66e4 upstream. LOLLM noticed that xrep_dinode_check_dfork doesn't require that the inode has the METADATA flag set in flags2. Add that check. Cc: stable@vger.kernel.org # v6.14 Fixes: 702c90f4516223 ("xfs: support file data forks containing metadata btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 38a595275d276c25466ed774f6b4d9108bc8355d Author: Darrick J. Wong Date: Thu Sep 24 21:10:45 2026 -0700 xfs: adjust checks for cross-AG reaping issues commit 4c6668ecebc61bb0a53d4c6e95509bc960cf6bbc upstream. While analyzing the reaping code for the previous patch, I studied the xfs_fsblock_t code to reconstruct how this code works. AGs have a superblock at the start of each AG which means that regions in the xfsb_bitmap (aka xfs_fsblock_t bitmap) cannot cross an AG boundary, so we don't need a loop here like we do for xfs_rtblock_t bitmaps. However, the checks here are not quite right -- there can be quite a lot of reserved space in COW forks, which means that the bitmap extent actually can exceed XFS_MAX_BMBT_EXTLEN. We also don't have an explicit debugging check that we never cross AGs, so add that here. Cc: stable@vger.kernel.org # v6.8 Fixes: 66da11280f7ecd ("xfs: reintroduce reaping of file metadata blocks to xrep_reap_extents") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 2b33121ec2a85d660a1d6cf78cb365961019d645 Author: Darrick J. Wong Date: Thu Sep 24 21:13:06 2026 -0700 xfs: jump out of xchk_bmap_check_rmap if fatal signals commit 49d300a51442bd64b627645b7b0b1cd66e492905 upstream. LOLLM observes that we never check for fatal signals inside the loop that checks file fork mappings against the rmapbt. This can lead to lengthy delays in responding to a ^C, so add some bailout checks. Cc: stable@vger.kernel.org # v4.17 Fixes: 5e777b62b0bcb6 ("xfs: bmap scrubber should do rmap xref with bmap for sparse files") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 44cc66d047efa739b2bd816177dd3ebad3c0e76c Author: Darrick J. Wong Date: Thu Sep 24 21:13:22 2026 -0700 xfs: mark overfull dabtree node blocks as corrupt commit f61c91a2e5994fa81141d6c06dadae1fed206018 upstream. LOLLM observes that we need to range-check the dabtree node record count before using it to index an array. Fix that. Cc: stable@vger.kernel.org # v4.15 Fixes: 7c4a07a424c18d ("xfs: scrub directory/attribute btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit c67017f673bc4a118fac377bc99d39b34465f426 Author: Darrick J. Wong Date: Thu Sep 24 21:13:38 2026 -0700 xfs: check fork type against dabtree block magic number commit 43030b72a11a532e7e3c21ac84a8625425b4201b upstream. LOLLM complains that we fail to flag dabtree blocks that should never be associated with the file fork -- data forks can't point to xattr leaves, and attr forks can't point to dirent blocks. Add the missing checks. Cc: stable@vger.kernel.org # v4.15 Fixes: 7c4a07a424c18d ("xfs: scrub directory/attribute btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 31f79a0919e3f0d96f7df2c3aa4f7896394f2356 Author: Darrick J. Wong Date: Sun Sep 27 23:16:36 2026 -0700 xfs: abort dirtree repair if the live update hook dies commit 07732dea4f5d0410e1566b81a58a1154bf9dcb29 upstream. LOLLM notices that if the live update hook for the directory tree repair code hits an error, it will set dl->aborted and stops working. If the repair code ever sees that condition, it ought to bail out immediately instead of continuing with obsolete data. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 50dd205bf3c00f512d817fe9254983ff7a81a2e5 Author: Darrick J. Wong Date: Sun Sep 27 23:17:07 2026 -0700 xfs: fix revalidation of xchk_dquot_iter cached mappings commit 6c64d650460b455980a6023d43bc6c8859c1cfd2 upstream. LOLLM noticed that the purpose of xchk_dquot_iter_revalidate_bmap is to revalidate the quota file mapping after we've (presumably) done something to the quota file contents. However, the "yes this is valid" code isn't quite strong enough -- the mapping must cover at least the block at fileoff, not just end after fileoff. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: 21d7500929c8a0 ("xfs: improve dquot iteration for scrub") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 1f5def7e91a6ebb668620c44c59e8f82c9dab839 Author: Darrick J. Wong Date: Sun Sep 27 23:16:51 2026 -0700 xfs: bail out of directory tree repairs on error commit d83ca4e7cc65dce6a02fd3427cefd174517657a3 upstream. LOLLM complains that we ignore errors returned by xrep_dirpath_retain_parent and can set the dotdot entry to random stack garbage. Fix that by passing errors all the way out. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 006556968a49b4afe63cbe3c311f5c40086c793f Author: Darrick J. Wong Date: Sun Sep 27 23:17:54 2026 -0700 xfs: assign an owner to scrub_stats_fops commit fe67a493c7a76cf75556152af24285a114f69d34 upstream. LOLLM complains that file_operations structs for debugfs files are supposed to have an owner set so that the module can't get unloaded if someone's sitting on a debugfs file long after unmount/rmmod. Fix that. Cc: stable@vger.kernel.org # v6.6 Fixes: d7a74cad8f4513 ("xfs: track usage statistics of online fsck") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 09b787d595590f3abba4c71f7b28d27a8d52aeb7 Author: Darrick J. Wong Date: Sun Sep 27 23:17:38 2026 -0700 xfs: allow softlimit with no hardlimit in quota scrub commit 342c2e00b3a99099a7088f7b8c8f075670c603a9 upstream. LOLLM observes that the sysadmin can set a user's soft limit to a nonzero value and the hard limit to zero, so those aren't corruptions. Cc: stable@vger.kernel.org # v4.15 Fixes: c2fc338c87a31f ("xfs: scrub quota information") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 5cdd8d436feba462a2f7a41bf04bc3bfe84c17fc Author: Darrick J. Wong Date: Sun Sep 27 23:18:10 2026 -0700 xfs: fix lost errno returned from xfarray_foliosort commit 8c4f172c246717b1420f138a159ed15c315a58bd upstream. LOLLM noticed that we stop the sort early but don't actually pass along the error code, which could enable repair code to continue running with an unsorted array. Fix that. Cc: stable@vger.kernel.org # v6.9 Fixes: ee13fc67205b98 ("xfs: convert xfarray_pagesort to deal with large folios") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 1fc1a5a2419a5315872c239e8c56c6dbf26539ae Author: Darrick J. Wong Date: Sun Sep 27 23:17:23 2026 -0700 xfs: don't repair fs summary counters with garbage commit 22a8a7501c0146dba4ce99b8256975ffe945125d upstream. LOLLM noticed that if we scan the filesystem and come up with totally garbage numbers for the summary counters, we don't actually mark the scan incomplete. Because we don't do this, repair can install the garbage values into the filesystem, making things worse. Don't do that. Cc: stable@vger.kernel.org # v6.9 Fixes: 4ed080cd7cb077 ("xfs: repair summary counters") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b5891acd62d82d8ef24b81cf1ca72206aa566d98 Author: Darrick J. Wong Date: Sun Sep 27 23:18:25 2026 -0700 xfs: fix skipped inode mask handling in iscan commit 63341d4af16fe850716b454fcd18990590d07d97 upstream. xfs_highbit64() returns -1 if none of the bits in its argument are set. In this particular callsite, a totally zeroed mask means that no inodes were skipped, so executing the if-body is incorrect. Fix that. Cc: stable@vger.kernel.org # v6.9 Fixes: 82334a79c6eb1c ("xfs: iscan batching should handle unallocated inodes too") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 0c5802d7be2bd122ddd8922f262cab8be2e977d5 Author: Darrick J. Wong Date: Sun Sep 27 23:18:41 2026 -0700 xfs: don't proceed with xattr repair if the live update fails commit 833f98b3be45bc7c6ce4c87bdc4892f546ab72ee upstream. LOLLM observes that we ought to make one last check for failed live updates before replacing the xattr structure. Let's be cautious here. Cc: stable@vger.kernel.org # v6.10 Fixes: e5d7ce0364d8ee ("xfs: replay unlocked parent pointer updates that accrue during xattr repair") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 8edb7edb9d33714d128758c5127324059b703b4f Author: Eric Sandeen Date: Tue Sep 29 18:13:05 2026 -0500 xfs: validate rc_domain in xchk_rtrefcount_mergeable commit f04361fb8694bff98ec61e2e2030a1993426fdca upstream. xchk_refcount_mergeable validates that the domains match, but this was omitted from the realtime version of the check; fix it. Fixes: c27929670de144 ("xfs: scrub the realtime refcount btree") Cc: stable@vger.kernel.org # v6.14 Signed-off-by: Eric Sandeen Reviewed-by: Darrick J. Wong Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 18773e41e92b21f4f8082f12750404bea4caab0a Author: Darrick J. Wong Date: Sun Sep 27 23:18:57 2026 -0700 xfs: don't fix the directory tree if live update fails commit c8226f3d1a7eafe472addc232689e9c9a0c36a1c upstream. LOLLM complains that we don't double-check dl->aborted one last time to before committing repairs to the filesystem. This is important because the live update handler could have set ->aborted if it encountered a runtime error. Cc: stable@vger.kernel.org # v6.10 Fixes: 3f31406aef493b ("xfs: fix corruptions in the directory tree") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 6b7f9ab7610b42d5d8c3f425f53a1dc3dffb8667 Author: Darrick J. Wong Date: Sun Oct 4 22:55:33 2026 -0700 xfs: flag excessive delalloc rt extents as corruption commit 2b47be015a5e54f4a3d62afa636ba593de9b67f6 upstream. LOLLM observed that we should not allow repairs to proceed if the count of delayed-allocation realtime extents exceeds the number of free rt extents because we can't install negative numbers into the superblock. It's unclear how we could end up in that state in real life, but let's at least complain loudly about it if we ever encounter it. Cc: stable@vger.kernel.org # v6.2 Fixes: e74331d6fa2c21 ("xfs: online checking of the free rt extent count") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit e065e5f8dfa4a40fb5b2f89281c50af0bed2ed59 Author: Darrick J. Wong Date: Sun Oct 4 22:55:48 2026 -0700 xfs: zero out di_metatype when removing the metadir file iflag commit f5b4d8c8ce16675f77c25a4ff06caaa9a2739f31 upstream. LOLLM pointed out that we should zero di_metatype (fka di_onlink) when we're clearing the METADIR inode flag because the file is no longer a metadata file. Cc: stable@vger.kernel.org # v6.13 Fixes: 7297fd0bebbd70 ("xfs: enforce metadata inode flag") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 56192355a67e9a42b1b941c3c6a615c909df4350 Author: Darrick J. Wong Date: Sun Oct 4 22:56:20 2026 -0700 xfs: don't pass iget failures up when marking ondisk inodes commit 7f5e8bf335e5e257fb82cf5b3521980ded60e863 upstream. LOLLM observes a couple of problems with this callsite -- an ENOMEM return is completely ignored and a subsequent run through the loop body obliterates the return value completely. Also, an error value indicating that the list is corrupt can get passed up (thus terminating the repair) even though we can handle corrupt lists. Fix the callsite not to have these problems. Cc: stable@vger.kernel.org # v6.10 Fixes: ab97f4b1c03075 ("xfs: repair AGI unlinked inode bucket lists") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit a9e94a4cd5a0ed3e875f03c9495f014d3ba71744 Author: Darrick J. Wong Date: Sun Oct 4 22:56:35 2026 -0700 xfs: always reset incore attr fork buffer when resetting fork commit 71cb13685e72a3c5d118732559c727a0c9090b7f upstream. LOLLM noticed that the local format attr fork verifier depends on if_bytes being set correctly. However, the fork reset function doesn't reset that correctly, which can cause post-repair verifier failures. Fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: e5d7ce0364d8ee ("xfs: replay unlocked parent pointer updates that accrue during xattr repair") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 3b7198678a3a91660db33c41625dfdc4056ffe29 Author: Darrick J. Wong Date: Tue Sep 22 23:02:02 2026 -0700 xfs: fix inode btree repair when a cluster is larger than a chunk commit 65b89ac3e8c2f041384f715a71b9d113edfa32e5 upstream. LOLLM noticed that on filesystems where an inode cluster buffer is larger than an inode chunk, we can run through the loop body in xrep_ibt_process_cluster more than once, and the number of inodes that we pass to xrep_ibt_cluster_record is incorrectly large. In this case we can run right off the end of the buffer. Fix this by moving the nr_inodes computation inside the loop. Note that this is only likely to happen on filesystems with (say) 512b inodes and 64k fsblocks. Cc: stable@vger.kernel.org # v6.8 Fixes: dbfbf3bdf639a2 ("xfs: repair inode btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit b50c563a99cb35e9edf1b00934ab3d5f0da4d3a5 Author: Darrick J. Wong Date: Tue Sep 22 23:02:49 2026 -0700 xfs: actually report corrupt xattrs as XFAIL during cross-referencing commit b339cc253019518c61b8b150fb7ea727fdae59f4 upstream. Some LLM reports that xchk_dir_parent_pointer really ought to report xattr corruption errors as XFAIL (cross-referencing failed) when a directory scrub tries to find the parent pointer for a dirent name. Let's do that. Cc: stable@vger.kernel.org # v6.10 Fixes: 61b3f0df5c2358 ("xfs: check dirents have parent pointers") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 779f9d180b4b1fdf2d4b045a1acd763043ee83c3 Author: Darrick J. Wong Date: Tue Sep 22 23:02:34 2026 -0700 xfs: fix buffer overflow in corrupt inline attr structure commit 017dd7a84ff4cd2275eb62f4ee6d63c705bac107 upstream. LOLLM noticed a buffer overrun if the xattr scrubber encounters a file with a shortform attr fork with sf->count > 0 but if_bytes == sizeof(struct xfs_attr_sf_hdr). Basically, we have enough data to have a header with a nonzero count, but no space for any of those shortform entries. In this case, the xfs_attr_sf_nextentry() call will run off the end of if_data and blow up. Cc: stable@vger.kernel.org # v6.4 Fixes: ae0506eba78fd1 ("xfs: check used space of shortform xattr structures") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 1519f7a63f663afef62a2c2e1ec1b75881220936 Author: Darrick J. Wong Date: Tue Sep 22 23:03:20 2026 -0700 xfs: fix unnecessary dapos truncation in xchk_dir_walk commit f60a2ef8d8a7ac6dedf4d0c3325cc3fc2fe0d948 upstream. LOLLM points out that the all the implementations of xchk_dirent_fn can handle a signed @dapos parameter, so the truncation here breaks the information captured in scrub tracepoints if the directory is very large. I don't think it ever made sense to do the truncation for the VFS readdir code for programs that can handle 64-bit offsets, but commit 15440319767942 has been around for 17 years without complaints so I'll leave that alone. Stumbled-over: 15440319767942 ("[XFS] truncate readdir offsets to signed 32 bit values") Cc: stable@vger.kernel.org # v6.4 Fixes: 4c233b5c4f29df ("xfs: streamline the directory iteration code for scrub") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 83f274a69ba6379a50780a7cb117b9052d3a8e6f Author: Darrick J. Wong Date: Tue Sep 22 23:03:36 2026 -0700 xfs: actually lock the metafile reservation when adjusting after repair commit e53c620b3670fc0c162b5f768a10a3a17d0c04f6 upstream. LOLLM reported that xrep_reset_metafile_resv performs unlocked loads and stores to the metadata file space reservation counters and thus can race with other threads. Fix this by taking the lock. Cc: hch@lst.de Cc: stable@vger.kernel.org # v6.15 Fixes: 1df8d75030b787 ("xfs: make metabtree reservations global") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 84c0abd7e70fde9f2f61f06287dbee82734e664a Author: Darrick J. Wong Date: Tue Sep 22 23:03:52 2026 -0700 xfs: avoid cross-rtgroup reaping after a repair commit d7c204d4ea7ef0cf0dac908388984c2936f1f94e upstream. LOLLM notices that the extents stored in a xrtb_bitmap (aka xfs_rtblock bitmap) can span multiple rtgroups due to two circumstances. The first is that the size of an rtgroup is an exact power of two, which means that rtgroups are adjacent in the segmented xfs_rtblock_t address space. This is fairly common to reduce the amount of multiplication and division needed to handle space on the rt volume. The second is that (unlike in the original rtgroups design), rtgroups do not have fixed-location metadata like AGs do, which means that there's nothing to force a break between rtgroups. Therefore, we must loop through the rtgroups in xreap_rtmeta_extent to avoid running off the end of an rtgroup while reaping. Cc: stable@vger.kernel.org # v6.14 Fixes: fd97fe1112088c ("xfs: fix CoW forks for realtime files") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit c937966701c230d273cf0b953049fc9f9e48bba6 Author: Darrick J. Wong Date: Tue Sep 22 22:57:53 2026 -0700 xfs: online quotacheck must dirty dquot if enforcement adjustments needed commit 244425cf63d7e3a0ff5736b41f0e0afe807f7031 upstream. LOLLM noticed that we have no way to force xchk_commit_dquot to call xfs_qm_adjust_dqenforcement if nothing else is wrong with the dquot. Therefore, add a new predicate to force the dirty flag if the dquot has zero limits and there are default limits; or if the grace period timer needs adjusting. Cc: stable@vger.kernel.org # v6.9 Fixes: 96ed2ae4a9b06b ("xfs: repair dquots based on live quotacheck results") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 173eb03891f4cf7f390521e66cdc5f203dbed591 Author: Darrick J. Wong Date: Tue Sep 22 22:58:08 2026 -0700 xfs: fix buffer overruns in xfs_ioc_attr_list commit 0b9081a774ee7b9dff1e9ac3765b73c1d6bba5b2 upstream. When we converted the al_offset array in struct xfs_attrlist into a VLA, the size of the object shrank by 4 bytes. Unfortunately, the buffer size validation in the attrlist ioctl wasn't updated to notice this, so the al_offset[0] assignment blindly writes off the end of the buffer. LOLLM noticed the omitted check and complained. Cc: stable@vger.kernel.org # v6.5 Fixes: 371baf5c9750a2 ("xfs: convert flex-array declarations in struct xfs_attrlist*") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 83c2efaba8665aca902e440ff78d9b22c0449728 Author: Darrick J. Wong Date: Tue Sep 22 22:57:37 2026 -0700 xfs: fix missing xfs_qm_adjust_dqlimits call in quotacheck repair commit da483b8a9c2c3e7b23655699680feb57a194000c upstream. LOLLM noticed that everywhere else in the kernel, a call to xfs_qm_adjust_dqlimits precedes every call to xfs_qm_adjust_dqtimers. In particular, mount-time quotacheck does this, but online quotacheck does not. Looking at xfs_qm_adjust_dqlimits, that function is in charge of conveying default limits to a dquot if that dquot's limits have been zeroed. That's quite possible in a repair, so we actually need to do that. However, there's a pre-existing pattern in the kernel -- for non-root dquots, first we call xfs_qm_adjust_dqlimits to set the dquot's limits to the defaults if they are zero, and then xfs_qm_adjust_dqtimers to start grace periods if the dquot's usage is above the softlimit. The grace period decision cannot be made correctly if we forget to import the default limits. Therefore, let's combine both into a single xfs_qm_adjust_dqenforcement helper that takes care of both pieces, which fixes quotacheck and makes it hard to repeat this mistake. Cc: stable@vger.kernel.org # v6.9 Fixes: 96ed2ae4a9b06b ("xfs: repair dquots based on live quotacheck results") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 6afaf9a32817c7871d8a8b54ed13eba7c82c83cf Author: Darrick J. Wong Date: Tue Sep 22 22:58:55 2026 -0700 xfs: fix xfs_rename_space_res for non-pptr filesystems commit a800b926346c3aa2482421f5c0272280ee7d32e8 upstream. We don't need to reserve space for a parent pointer update for an existing target if parent pointers are disabled. Fix this regression (which LOLLM noticed) so that rename reservations go back to what they were before parent pointers. Cc: stable@vger.kernel.org # v6.10 Fixes: 5a8338c88284df ("xfs: Add parent pointers to rename") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 95941108be83dd9bdeb9f53b7b72dbfafdef1827 Author: Darrick J. Wong Date: Tue Sep 22 22:59:11 2026 -0700 xfs: fix ondisk symlink target validation in xrep_dinode_check_dfork commit aafe21c23ad8263251085291019d8860ddc51da9 upstream. LOLLM noticed that online repair of a broken symlink file could fail unnecessarily if a local-format symlink target isn't null terminated. The ondisk target isn't required to be null terminated, but repair enforces that anyway because it uses the validator for the incore symlink target. (The incore buffer is always null-terminated). Fix this by reverting the changes to xfs_symlink_shortform_verify and adding an ondisk-specific helper in inode_repair.c. Cc: stable@vger.kernel.org # v6.8 Fixes: e744cef2060559 ("xfs: zap broken inode forks") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Reviewed-by: Dave Chinner Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit af6d2f0a32325299264c8bbd64964c96ef5143ad Author: Darrick J. Wong Date: Tue Sep 22 23:01:00 2026 -0700 xfs: compute the correct fdblocks/frextents for repair when they're negative commit f98d007017acf0eaec2e116ff9c0ece735f61bb3 upstream. LOLLM observed that if either fdblocks or frextents are negative, we'll set the CORRUPT flag and exit immediately. This doesn't work for a repair because we still have to walk the filesystem metadata to compute the correct summary counters so that we can install the new values. Currently we just write zeroes into the summary counters, which isn't right. Cc: stable@vger.kernel.org # v6.9 Fixes: 4ed080cd7cb077 ("xfs: repair summary counters") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 9c16395459335b1266864bc441fb31051c2b4507 Author: Darrick J. Wong Date: Tue Sep 22 23:01:16 2026 -0700 xfs: mark cow extents bad if there's no rmap mapping for them commit 2ffc0619c9c2881443c5fffb10db8f2bc0aa2ce8 upstream. LOLLM noticed that we fail to mark cow staging extents as bad if there's a cow staging extent but no rmap record for the cow staging event. Close this gap. Cc: stable@vger.kernel.org # v6.8 Fixes: dbbdbd0086320a ("xfs: repair problems in CoW forks") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit fa21d1f4f6176e95d110302e66d2a70a4c54b4ab Author: Darrick J. Wong Date: Tue Sep 22 23:01:31 2026 -0700 xfs: clear the symlink zapped flag if inline symlink is ok commit f8d0d90f2e24b1f4a14796ae63cebfd820cadfcd upstream. LOLLM noticed that we fail to clear the SYMLINK_ZAPPED flag if an inline symlink checks out ok, even after a repair. Fix that. Cc: stable@vger.kernel.org # v6.8 Fixes: d9041681dd2f53 ("xfs: set inode sick state flags when we zap either ondisk fork") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 5c6a8b2f2f4dc3a0da89c7379ae64962850ba1e3 Author: Amir Goldstein Date: Sun Oct 18 11:52:52 2026 +0200 ovl: skip copy up of empty security.capability commit 50912a1715b8a7c614b654011a0db750e372b43e upstream. ovl_copy_xattr() gives up if it can't read an attribute that listxattr() has named. An empty security.capability, which anybody has been able to store on any file for a long time, is such a case: it is listed, and getxattr() has nothing to return for it. A file in a lower layer that carries one can't be copied up: it can't be written to, renamed or have its mode changed. There is nothing to copy if there are no data. Go on with the next one. Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik [amir: treat -EINVAL as no capability too, and do the same in ovl_copy_up_meta_inode_data()] Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 7ecbeb1a84f2d099012ccd95a8a7588e1306cc46 Author: Chris Mason Date: Fri Oct 16 21:17:23 2026 +0000 ovl: set the revalidate flags after d_instantiate() commit 75e89c0055c1d7f7eeb462995f11253ca5864f79 upstream. stat() of a file on an overlayfs mount triggers a kernel warning and fails with ECHILD if another task is creating that file at the same time. This happens on an overlay with a FUSE upper layer, which is the layer where overlayfs creates new files. Write access to a directory on such an overlay is all a user needs to run the two tasks. The revalidate flags are DCACHE_OP_REVALIDATE and DCACHE_OP_WEAK_REVALIDATE. They tell path walk to call ->d_revalidate() or ->d_weak_revalidate() on a dentry, so that the filesystem can check that the cached dentry is still valid. An overlay dentry only has one of these flags if a dentry in one of its layers has it. FUSE dentries have the first one. When a flag is set on an overlay dentry, path walk calls ovl_dentry_revalidate_common(). That function only expects a dentry without an inode in RCU walk, while the dentry is being destroyed. For such a dentry outside of RCU walk, it hits a WARN_ON() and returns -ECHILD. So a negative overlay dentry must never have the flags set. ovl_instantiate() breaks this rule. When a task creates a file, the overlay dentry for the new name is hashed but still negative. ovl_instantiate() then works in this order: - It copies the flags from the new upper dentry to the overlay dentry. - It calls ovl_get_inode(), which can sleep in a getxattr request to the FUSE server. - Only then does it call d_instantiate(). A second task that looks up the name between the first step and the last finds a negative dentry with the flags set and revalidates it. Reproduced with a FUSE server that delays its getxattr reply: stat() of a name that was being created hit the WARN_ON() and failed with ECHILD. Fix this by setting the flags after d_instantiate(). Fixes: bccece1ead36 ("ovl: allow remote upper") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 8cd9ec121a63c544d89744e9b07ca8f5f8535cdf Author: Hungyu Lin Date: Wed Oct 28 19:51:33 2026 +0000 ovl: reserve space for the casefolded name terminator commit a65eb1808177a4381718abe563dddebf840598f9 upstream. ovl_casefold() allocates NAME_MAX bytes and passes that capacity to utf8_casefold(), which also needs room for a terminating NUL. A valid name whose folded form is exactly NAME_MAX bytes therefore fails to fold, and ovl_fill_merge() falls back to comparing the original bytes. For example, when two casefolded layers contain directories named with 255 uppercase and lowercase ASCII letters respectively, readdir lists both names even though lookup treats them as the same directory. The same names merge correctly at 254 bytes. Reserve one additional byte in both the allocation and the folding capacity so that NAME_MAX-byte folded names use the canonical merge key. Fixes: ee95c5fc86dd ("ovl: Create ovl_casefold() to support casefolded strncmp()") Cc: stable@vger.kernel.org Signed-off-by: Hungyu Lin Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 9b50f28c22c948b0c134d5c5dbd62ea0ada97fc3 Author: Chris Mason Date: Fri Oct 16 21:17:04 2026 +0000 ovl: read the nlink xattr of every indexed non-dir commit eb644ed5c6d9afdb1554c41cef1f39d150fbc554 upstream. With nfs_export=on, data written through a file handle to a lower file, i.e. a file that exists only in a lower layer of the overlay, can be lost on the next mount. A lookup of the file by name then returns -EIO. Also, a file with one name reports st_nlink 2 once it has been copied to the upper layer. After such a file is removed, its file handle can still open it until the next mount. Before a lower file is changed for the first time, overlayfs copies it to the writable upper layer. This is called copy up. The index directory is $workdir/index, where $workdir is the directory given by the workdir= option. Each entry is named after the file handle of a lower inode, so that overlayfs can get from the handle to the copied up inode. With nfs_export=on, copy up indexes every non-directory: it copies the file to an entry in the index directory and then hard links that entry into the upper directory. The index entry is an extra link to the upper inode, so overlayfs stores the link count that users should see in the overlay.nlink xattr. A file can also be opened by handle, either by an NFS client or by a process with CAP_DAC_READ_SEARCH calling open_by_handle_at(). If the file is not in the dcache, its overlay dentry is disconnected, i.e. it has no parent yet. Copy up then creates the index entry but no hard link in the upper directory. The index entry has i_nlink 1 and holds the only copy of the data written to the file. ovl_get_nlink() reads the stored count. Its caller passes a default, which the function returns if there is no stored count. If the lower inode has i_nlink 1, the function returns the default without reading the xattr. That was correct as long as only lower files with multiple links were indexed. On the next mount, ovl_verify_index() looks for orphans, i.e. index entries of files whose last name was removed. For an index entry with i_nlink 1, it passes a default of 0 to ovl_get_nlink() and treats a result of 0 as an orphan. Here the lower inode also has i_nlink 1, so the result is the default. ovl_indexdir_cleanup() then replaces the entry with a whiteout, which in the index marks a file as deleted. The written data is lost. A lookup by name then returns -EIO, because a whiteout as the index entry of a lower file that still exists is a bad index. ovl_get_inode() gets the wrong count the same way. Its default is the i_nlink of the upper inode, which includes the index entry, so a copied up file with one name reports st_nlink 2. When that name is removed, the count drops to 1 rather than 0. ovl_nlink_end() replaces the index entry with a whiteout only at a count of 0, so the entry stays, and the handle of the removed file still opens it. Reproduced by writing through open_by_handle_at() to an uncached lower file with one link. After a remount the data was lost, and the name returned EIO. Fix this by adding an argument to ovl_get_nlink() that says whether the caller found an index entry, and by skipping the xattr only if the caller found none. Known gaps: - An index entry that a kernel without this patch left behind for a removed file now stays, and the handle of that file keeps working. The entry has i_nlink 1 and a stored count of 1, just like the entry of a file that was only written by handle. Without this patch, the next mount treated it as an orphan. Fixes: fbd2d2074bde ("ovl: index all non-dir on copy up for NFS export") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 37537892ca404fa94050114ccebe02f64b9ffad7 Author: Amir Goldstein Date: Fri Oct 16 09:33:58 2026 +0200 ovl: fortify ovl_copy_xattr() against underlying layer modifications commit e6b9117076fb4c0ff4a670efa9c876d9a50d79ab upstream. Adapt ovl_getxattr_value() to be used from ovl_copy_xattr(), by allowing to pass it a pre-allocated buffer, which can be resized and by handling the ENODATA/EOPNOTSUPP return codes in the caller. This replaces the retry loop in ovl_copy_xattr() with a single retry after resizing the buffer. If the value changed again by then, the underlying layer was modified, so return -EIO instead of retrying. As a side effect, ovl_copy_up_meta_inode_data() now returns -EIO instead of -ERANGE in this case of underlying xattr size changes. Reported-by: Fahad Alharbi Tested-by: Fahad Alharbi Suggested-by: Miklos Szeredi Link: https://lore.kernel.org/linux-fsdevel/CAJfpegsVoUyqy0dYkTvBGRZvgdv_nmzmCw_uF+LP-Vq3EhEkSg@mail.gmail.com/ Fixes: e4ad29fa0d22 ("ovl: use a minimal buffer in ovl_copy_xattr") Cc: stable@vger.kernel.org Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit b9f57bb52124aec87bbe344d70a30806fe22b992 Author: Chris Mason Date: Wed Oct 7 12:10:59 2026 +0000 ovl: fix a torn path in ovl_get_redirect() commit 2001cd7ca5560198131e46c6ca3c3472b06145c2 upstream. A hard link of a metacopy file that races with a rename of an ancestor stores a redirect to the wrong lower file. Each component of an absolute redirect must be the name that a dentry has in the parent that the walk continues with. ovl_get_redirect() copies the name under d_lock and calls dget_parent() after the unlock, and the callers for a hard link hold no lock that stops a rename across directories. A rename between the two steps combines the old name with the new parent. With delays in ovl_get_redirect(), an unprivileged user hard-linked a metacopy file while renaming its ancestor to another directory, the stored redirect named another lower path, and after a remount the file showed the data of a root-only file. Fix this by taking the parent first and checking it again under d_lock. Fixes: e04527fefba6 ("ovl: fix dentry leak in ovl_get_redirect") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 628260a7204314ab5f1cd93bddb1721cc0226b38 Author: Chris Mason Date: Wed Oct 7 09:45:28 2026 +0000 ovl: do not copy up an xattr value that was never read commit 755b5c5c9277be251a51623d6065abab948c61bc upstream. Copy-up stores uninitialized kernel memory in an xattr of the upper file, where the user can read it. ovl_copy_xattr() may only pass bytes to ovl_do_setxattr() that ovl_do_getxattr() has read. When the read fails with -ERANGE the function asks for the size again, and if the new size fits the buffer it stores the buffer although nothing was read into it. The buffer comes from kvmalloc(), or it still holds the value of the previous xattr. A FUSE lower layer that answers every sized GETXATTR with -ERANGE made copy-up store 4096 bytes that the server never sent, with a kernel pointer in them, as an xattr of the upper file. Fix this by failing the copy-up with -EIO when the size that follows -ERANGE fits the buffer. Reported-by: Fahad Alharbi Closes: https://lore.kernel.org/linux-fsdevel/CAOQ4uxjhfpNVvoVrTayj46H2CViTOc3oxzM6xdb8+E7ikE2CSA@mail.gmail.com/ Fixes: e4ad29fa0d22 ("ovl: use a minimal buffer in ovl_copy_xattr") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 6a49ab7c9a68ad9ace8c7fb6fdd7126f4f3411c8 Author: Chris Mason Date: Fri Oct 16 21:17:17 2026 +0000 ovl: check the casefold flag of directories only commit 1d27da7de3f74405b1de85ad26c5ea90f826114b upstream. On an overlay over casefolded (case-insensitive) directories, every lookup of a file that is not a directory fails with EREMOTE, and the first file create triggers a kernel warning. No privilege is needed: an unprivileged user can cause both in a user namespace, with the layers on a tmpfs that they have mounted with the casefold option. Some filesystems support casefolding, which is case-insensitive name lookup. It is enabled per directory, and the inode of a casefolded directory has the S_CASEFOLD flag. overlayfs accepts layers on a filesystem that supports casefolding as long as casefolding is enabled on every directory of the layers, or on none. The mount records which of the two applies in ofs->casefold. ovl_lookup_single() compares the S_CASEFOLD flag of each file that it finds against ofs->casefold and returns -EREMOTE on a mismatch. Filesystems only set S_CASEFOLD on directories, so with casefolded layers a regular file, a symlink or a special file never matches and its lookup fails. ovl_get_inode() does the same comparison in a WARN_ON_ONCE() for each new overlay inode. A failed lookup never gets that far, so it is the first file create that trips the warning. Reproduced on an overlay over casefolded tmpfs or ext4 directories, with stat() of a regular file, a symlink and a FIFO, and with a file create: each stat() failed with EREMOTE. For an unprivileged user in a user namespace, on tmpfs, stat() of a regular file failed in the same way, and the file create triggered the warning. Fix this by limiting both checks to directories. Fixes: 16754d61dc69 ("ovl: Support mounting case-insensitive enabled layers") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit b050952bc4e3409c655a4abcd987131bd77ef570 Author: Chris Mason Date: Fri Oct 16 21:17:07 2026 +0000 ovl: always encode the origin fh when index is enabled commit 949f9d8a5580c77a45fa759123367682aba4d173 upstream. On an overlay with index=on,nfs_export=on, copy up of a directory crashes the kernel once an LSM has started to deny CAP_DAC_READ_SEARCH to the mounter, the task that mounted the overlay. The mount and the LSM policy change require root. After that, any user who can write to a directory that exists only in a lower layer triggers the oops by doing so. Before a file or directory that exists only in a lower layer is changed for the first time, overlayfs copies it to the writable upper layer. This is called copy up. On copy up, ovl_get_origin_fh() encodes the file handle of the lower inode, called the origin. It returns NULL if ovl_can_decode_fh() says that the lower filesystem cannot decode handles. Whether the callers can handle NULL depends on the index option: - Without an index, NULL is fine: the callers store an empty origin xattr. - With index enabled, overlayfs keeps entries for copied up inodes in an internal index directory. The name of an index entry is derived from the handle, so ovl_get_origin_fh() must return a handle or an error. The mount only enables the index if ovl_can_decode_fh() succeeds for all layers, but the result can change later. The function checks the export operations of the filesystem and capable(CAP_DAC_READ_SEARCH). Copy up runs with the mounter's credentials, and an LSM can start to deny the capability to those credentials after the mount. ovl_get_origin_fh() then returns NULL with index enabled. This goes wrong in two callers: - With nfs_export=on, copy up of a directory creates an index entry for the directory. ovl_create_index() passes the NULL handle to ovl_get_index_name_fh(), which dereferences it. - If the result changes while mount(2) is still running, ovl_get_indexdir() passes a NULL from ovl_get_origin_fh() to ovl_verify_set_fh() in the same way. Before the commit in the Fixes tag, these two callers encoded the handle themselves, without consulting ovl_can_decode_fh(). Reproduced with a BPF LSM program that started to deny the capability after the mount. An unprivileged touch in a directory that had not been copied up yet oopsed in ovl_get_index_name_fh(). With this patch the touch succeeds and the directory gets its index entry. Fix this by calling ovl_can_decode_fh() in ovl_get_origin_fh() only when index is disabled. Fixes: 5b02bfc1e7e3 ("ovl: do not encode lower fh with upper sb_writers held") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit b219cdaea16b2f3e8e13a63662d462addd8a2cd0 Author: Chris Mason Date: Wed Oct 7 10:47:10 2026 +0000 ovl: use the pinned upper dir in ovl_fix_origin() commit 4f61ff2ebfb3d2967b83b6a4d456242244d5a61f upstream. Renames made directly on the upper filesystem during a lookup crash the kernel. A dentry that is passed to vfs_setxattr() must be pinned. ovl_fix_origin() passes upper->d_parent to ovl_set_impure() without a reference, and the lookup holds no lock of the upper directory. A rename on the upper filesystem changes d_parent, and only the child pins the new parent, so a second rename and an rmdir free it. With delays in ovl_fix_origin() and ovl_set_impure(), renaming the upper directory twice and removing the intermediate parent during the lookup of a merge directory without an origin xattr gave a KASAN use-after-free in vfs_setxattr(). Fix this by passing the upper dentry that the overlay parent holds. Fixes: 9678e6303057 ("ovl: fix inconsistent d_ino for legacy merge dir") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik [amir: add helper ovl_set_impure_dir()] Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit c7e2808209899b2b94dbbcc3b28d44f6c065df62 Author: Chris Mason Date: Wed Oct 7 10:34:08 2026 +0000 ovl: take a snapshot of the name for copy up commit 65bf000962a33ec9d2488e4e1797b6cf630abcbb upstream. The copy up of a directory reads a freed dentry name when a lookup moves the directory at the same time. A pointer to the name of a dentry is only valid while something stops a move of the dentry. ovl_do_copy_up() keeps a plain copy of c->dentry->d_name in c->destname, and ovl_copy_up_start() only keeps ovl_rename() away. When a lookup finds the same directory under another name after a change to the lower layer, d_splice_alias() moves the dentry and frees its external name. With a delay in ovl_do_copy_up(), a chmod of a lower-only directory with a 60 byte name raced with a rename of that directory in the lower layer and a stat of the new name, and KASAN reported a use-after-free in lookup_noperm_common(). Fix this by using take_dentry_name_snapshot() for c->destname. Fixes: 829c28be9bb9 ("ovl: use d_splice_alias() in place of d_add() in lookup") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 7805739ce4577f2c53f5a30be2d48e83e91c63bc Author: Chris Mason Date: Wed Oct 7 10:01:19 2026 +0000 ovl: set OVL_WHITEOUTS before publishing the upper dir commit cbec8610ec5aaf35df50094ff639febc23f20773 upstream. Listing a directory while it is copied up causes a use-after-free of the readdir cache. A merge directory must never be iterated as a real upper directory: that mode frees the cache in OVL_I(inode)->cache without looking at its refcount, while files opened in merged mode still use it. ovl_copy_up_workdir() publishes the upper dentry before it sets OVL_WHITEOUTS, and ovl_dir_open() samples both without a lock, so an open between the two stores finds the upper directory and takes it for a real one. With a delay between the two stores, an unprivileged process that listed a directory during its copy-up saw only "." and "..", and its next getdents freed the readdir cache of another descriptor. Fix this by setting OVL_WHITEOUTS before ovl_inode_update(), so that ovl_dir_reset() agrees with ovl_dir_open(), and by testing OVL_TYPE_MERGE() of the path type in ovl_dir_open(), so that an open that observes the upper dentry never iterates a merge dir as a real dir, regardless of the order in which it observes the flag. Fixes: b79e05aaa166 ("ovl: no direct iteration for dir with origin xattr") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik [amir: test OVL_TYPE_MERGE() instead of smp_rmb() in ovl_dir_open()] Link: https://lore.kernel.org/linux-unionfs/CAOQ4uxh-1J2OBjnDVbrrrjy1puSOW0kABvghN85ih6dtKUBTyA@mail.gmail.com/ Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit ecc327edd96a65ac177379664cc0972d8a23dfa4 Author: Weiming Shi Date: Sun Oct 25 02:07:30 2026 -0700 smb: client: stop processing a read response after a receive error commit 51efca72345acdbedc4af76782d464bd15ba50ff upstream. cifs_read_iter_from_socket() may call cifs_reconnect() before returning an error. The reconnect path aborts pending mids and invokes their callbacks. The callback can then release the cifs_io_subrequest containing rdata. cifs_readv_receive() nevertheless continues after a negative return and may dereference rdata in cifs_readv_discard(). KASAN reports the resulting UAF: BUG: KASAN: slab-use-after-free in cifs_readv_receive Read of size 4 by task cifsd cifs_readv_receive (fs/smb/client/transport.c:1284) cifs_demultiplex_thread (fs/smb/client/connect.c:1355) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) Freed by task 148: netfs_put_subrequest (fs/netfs/objects.c:267) netfs_read_collection (fs/netfs/read_collect.c:460) netfs_wait_for_in_progress (fs/netfs/misc.c:462) Return the socket error immediately, as this path did before the iterator conversion. This also avoids adding a negative length to total_read. Cc: stable@vger.kernel.org Fixes: d08089f649a0 ("cifs: Change the I/O paths to use an iterator rather than a page list") Reported-by: co+24c7c12d69e63c6d@bugs.sh Assisted-by: LLM Signed-off-by: Weiming Shi Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit daee49d7a51f1edb062581d49684c9cbfb3d7dc9 Author: Diego Oliva Date: Tue Sep 29 10:16:31 2026 +0100 smb: client: fix OOB last_entry pointer from unbounded LastNameOffset commit 570c783a96f054dd3ac409a92772e9afb705d21c upstream. CIFSFindFirst() and CIFSFindNext() locate the last entry of a TRANS2_FIND_FIRST2 or TRANS2_FIND_NEXT2 response by adding the LastNameOffset of the response parameters to the start of the data area, and store the result in psrch_inf->last_entry. MS-CIFS 2.2.6.2.2 defines that offset as the offset of the entry's file name; the client follows the reading of NT and Samba servers, which point it at the entry. LastNameOffset is only checked against CIFSMaxBufSize, which says nothing about the response actually received: validate_t2() lets the data area start up to 1024 bytes into the buffer, and SendReceive() copies at most CIFSMaxBufSize + MAX_CIFS_HDR_SIZE bytes of a response, 16468 by default, into a cifs_request allocation of CIFSMaxBufSize + MAX_SMB2_HDR_SIZE bytes, 16588 by default. The pointer itself can therefore be placed anywhere from the end of the received data to 820 bytes past the end of the allocation. The read through that pointer is far larger than its displacement. find_cifs_entry() hands last_entry to cifs_save_resume_key() after every FindNext and after the FindFirst of a search rewind, and cifs_fill_dirent() takes the length of the name from the entry itself: a __le32 FileNameLength for most levels, a __u8 for SMB_FIND_FILE_INFO_STANDARD, and for SMB_FIND_FILE_UNIX the result of a scan for the terminating NUL over up to PATH_MAX + 1 UTF-16 units. The name is recorded as the resume name of the search, and the next CIFSFindNext() rejects only a recorded length of PATH_MAX or more before copying the name into the ResumeFileName of its request and sending it with the resume key taken from the same entry: up to 4 KiB of memory from past the end of the allocation leaks to the server, and for SMB_FIND_FILE_UNIX the NUL scan runs about twice as far before the length is even known. The entry does not have to lie outside the response for that either: a maximal response ends about 120 bytes before the end of the allocation, so an entry in its last bytes with a name just under PATH_MAX has nearly all of that name copied from past the allocation. It needs nothing unusual from the client: a FindNext response that reports no entries and does not end the search makes find_cifs_entry() send the next FindNext at once, carrying whatever was parsed at LastNameOffset, and a search rewind can do the same after its FindFirst. SMB1 is not negotiated by default: this takes a malicious or compromised server, a mount of it with an explicit vers=1.0, which CONFIG_CIFS_ALLOW_INSECURE_LEGACY (default y) permits, and a directory listing on that mount. With KASAN enabled, a response that places the last entry past the buffer, with a large DataOffset and a LastNameOffset near the end of its range, gives: ================================================================== BUG: KASAN: slab-out-of-bounds in cifs_save_resume_key.isra.0+0x7aa/0x7f0 Read of size 4 at addr ffff88807b55c33b by task ls/83 CPU: 1 UID: 0 PID: 83 Comm: ls Not tainted 7.3.0-rc4-00457-gf14572c203d5 #69 PREEMPT(lazy) Call Trace: kasan_report+0xdf/0x1a0 cifs_save_resume_key.isra.0+0x7aa/0x7f0 cifs_readdir+0x1ed6/0x29c0 iterate_dir+0x1c0/0x570 __x64_sys_getdents64+0x133/0x270 do_syscall_64+0x109/0x5d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 83 on cpu 0 at 19.317556s: cifs_buf_get+0x36/0x90 smb_init+0x4f/0x110 CIFSFindNext+0xf7/0x14c0 cifs_readdir+0xf51/0x29c0 The buggy address belongs to the object at ffff88807b558000 which belongs to the cache cifs_request of size 16588 The buggy address is located 623 bytes to the right of allocated 16588-byte region [ffff88807b558000, ffff88807b55c0cc) ================================================================== The four bytes read there are the FileNameLength of the entry, which cifs_fill_dirent() takes before anything checks where the entry lies. Ignore the last entry when it does not start inside the received response or the response holds no entries; for a response without entries, last_entry pointed into or past its empty data area and cifs_save_resume_key() parsed whatever the buffer held there. The entry is bounded by the response that was received, which is what the buffer holds, rather than by the data area the response declares, which a later patch checks against the received length. Record the search handle before the last entry is examined, since a response without a usable last entry still carries the handle that the search is continued and closed with; leaving the assignment in the else branch would drop the handle of every response without entries. This bounds where the last entry starts, not how far it is parsed: an entry that starts within the final bytes of the response still has its fixed part read past the end of the received data and its name, up to 4095 bytes, copied from past the end of the allocation, until the following patch bounds the parse itself. A response without a usable last entry continues the search with an empty resume name, since the preceding patch, "smb: client: fix use-after-free infoleak via the readdir resume name", drops the recorded name whenever a new response is installed. This patch applies on top of that one and relies on it: without it, every response rejected here would leave the previous name in place, pointing into a buffer that has been released. A conforming server is not affected: the last entry lies inside the data area of the response. Fixes: 0752f1522a91 ("[CIFS] make sure we have the right resume info before calling CIFSFindNext") Fixes: b77d753c413e ("[CIFS] Check that last search entry resume key is valid") Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Diego Oliva Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit f976692490bbdf670d4cc241b8951c8cfddb1583 Author: Cen Zhang Date: Thu Oct 22 17:08:41 2026 +0800 ocfs2: snapshot dentry names in file and setattr traces commit 8cd3ff30659775a6831c66687a69d2b83d163591 upstream. Patch series "ocfs2: stabilize dentry names in file and setattr traces", v4. Snapshot names at all six users of ocfs2__file_ops and at the separate setattr event. Patch 1 handles the five ordinary file-operation callers and setattr. Patch 2 handles release separately to preserve its locked open-count sample and take the snapshot outside that critical section. The release explanation distinguishes its existing RCU lifetime coverage from name/length consistency. It does not claim that the ordinary callers' external-name UAF interleaving crosses the held inode spinlock. The release source change is unchanged from v3. Patch 1 also removes the read callback's redundant NULL-inode check. The two patches apply independently and leave trace formats unchanged. This patch (of 2): The open, fsync, read, write and splice-read trace calls pass the live dentry name and length to the shared ocfs2__file_ops event class. ocfs2_setattr() passes the same unprotected arguments to its own event. Both events size and copy a __string field separately. A reference to the dentry does not pin the external storage backing an individual name. With an event enabled, a caller can be preempted after loading the name pointer. A long-to-short rename can then replace the name and reclaim its old external allocation before the trace callback sizes or copies it, provided no other snapshot retains that allocation. The setattr inode lock does not exclude every rename: a same-directory rename of a source directory need not take that directory's inode lock. It can therefore change the dentry name while setattr records its event. Inline names and separately loaded lengths can also change during trace record sizing and copying. Take a dentry name snapshot around each of these six trace calls and pass both the string and length from the snapshot. Check event enablement before taking a snapshot. Keep the event classes and formats unchanged. Also remove the redundant NULL-inode check in the read callback. file_inode() returns the open file's inode, which is already used by the trace call above the check. The historical report below is from the read path. KASAN report as below: BUG: KASAN: slab-use-after-free in strlen+0x85/0xa0 Read of size 1 at addr ffff88810a5b2b18 by task python3/496 [CPU and host details omitted.] Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? strlen+0x85/0xa0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? strlen+0x85/0xa0 kasan_report+0xe0/0x110 ? strlen+0x85/0xa0 strlen+0x85/0xa0 trace_event_raw_event_ocfs2__file_ops+0xf0/0x480 ? __pfx_trace_event_raw_event_ocfs2__file_ops+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? pmbd_probe_hit_cookie+0xe7/0x1c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_pmbd_probe_hit_cookie+0x10/0x10 ocfs2_file_read_iter+0x6cd/0xb30 ? __pfx_ocfs2_file_read_iter+0x10/0x10 ? selinux_file_permission+0x11d/0x540 ? srso_alias_return_thunk+0x5/0xfbef5 ? security_file_permission+0x26/0x80 vfs_read+0x7d2/0xc20 ? __pfx_vfs_read+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_do_sys_openat2+0x10/0x10 ksys_read+0x111/0x200 ? __pfx_ksys_read+0x10/0x10 ? irqentry_exit+0xbe/0x820 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on_prepare+0x11d/0x150 ? srso_alias_return_thunk+0x5/0xfbef5 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [User register dump omitted.] Allocated by task 489: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x2de/0x780 __d_alloc+0x5fc/0x8c0 d_alloc_parallel+0x106/0x11d0 lookup_open+0x3ff/0x13e0 path_openat+0x95e/0x2020 do_file_open+0x21e/0x470 do_sys_openat2+0xf4/0x1b0 __x64_sys_openat+0x136/0x1e0 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 0: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 __rcu_free_sheaf_prepare+0x65/0x2a0 rcu_free_sheaf_nobarn+0x1d/0x50 rcu_core+0x6be/0x1ed0 handle_softirqs+0x1fa/0x8d0 __irq_exit_rcu+0x113/0x1e0 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 The buggy address belongs to the object at ffff88810a5b2b00 which belongs to the cache kmalloc-rcl-192 of size 192 The buggy address is located 24 bytes inside of freed 192-byte region [ffff88810a5b2b00, ffff88810a5b2bc0) [Page and shadow-memory dumps omitted.] Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0088-v7-6324344256f0c3b1c3d8-0@gmail.com Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0088-v7-6324344256f0c3b1c3d8-1@gmail.com Fixes: 468eedde23d6 ("ocfs2: Remove mlog(0) from fs/ocfs2/file.c") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 7ff4f020f7b03fddd529735f0b61ac0a8dd92c9e Author: Cen Zhang Date: Wed Oct 14 11:47:15 2026 +0800 ocfs2: pin refcount trees before dropping the lookup lock commit 8c714a074074af7ae59233c1fa6ef9d7aa710462 upstream. A refcount tree returned to ocfs2_lock_refcount_tree() must stay alive until that caller releases its operation reference. However, ocfs2_get_refcount_tree() returns the cached pointer after dropping osb_lock, and the caller only takes its kref afterwards. The registry reference does not protect this gap from concurrent removal. This can happen when another node frees a refcount root and reuses its block with a different generation while this mount retains the old cached tree. Two local operations on different inodes sharing the new root, such as data CoW and an external xattr update, can then look up the same stale tree. Their inode locks are independent, and both the REFCOUNT DLM lock and rf_sem are acquired after the first operation reference. The following ordering is possible, with no other operation references: Data CoW Xattr update -------- ------------ Look up the old tree under osb_lock, then drop osb_lock Look up the same tree and take a kref Acquire the tree locks and read the new on-disk generation Erase the old tree under osb_lock Unlock and drop the operation kref Drop the registry kref, freeing tree Take a kref through the freed tree pointer The final kref_get() accesses freed rf_getcnt storage, and subsequent accesses in ocfs2_lock_refcount_tree() also use the freed allocation. Take the operation reference in ocfs2_get_refcount_tree() before releasing osb_lock, including when an insertion loses to another lookup. Removal must acquire the same lock, so it cannot drop the registry reference before the lookup has pinned the tree. Keep the existing unlock and error path puts. The two callers that already hold the refcount tree lock keep their borrowed lookup behavior and do not acquire an extra reference. KASAN report as below: BUG: KASAN: slab-use-after-free in ocfs2_lock_refcount_tree+0x94a/0x9b0 Read of size 4 at addr ffff888117212820 by task python3/497 [Kernel and hardware identification omitted.] Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? ocfs2_lock_refcount_tree+0x94a/0x9b0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? ocfs2_lock_refcount_tree+0x94a/0x9b0 kasan_report+0xe0/0x110 ? ocfs2_lock_refcount_tree+0x94a/0x9b0 ocfs2_lock_refcount_tree+0x94a/0x9b0 ? __pfx_ocfs2_lock_refcount_tree+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? ocfs2_refcount_cow+0x3b6/0xd90 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kmalloc_cache_noprof+0x28d/0x610 ? ocfs2_refcount_cow+0x3b6/0xd90 ocfs2_refcount_cow+0x410/0xd90 ? __pfx_ocfs2_refcount_cow+0x10/0x10 ? __pfx___might_resched+0x10/0x10 ? down_write+0x11a/0x1f0 ? __pfx_down_write+0x10/0x10 ? ocfs2_inode_unlock+0x1a9/0x260 ? __pfx_ocfs2_inode_unlock+0x10/0x10 ? ocfs2_file_write_iter+0x1413/0x1d30 ocfs2_file_write_iter+0x157b/0x1d30 ? __pfx_ocfs2_file_write_iter+0x10/0x10 ? lock_acquire+0x190/0x300 ? __x64_sys_pwrite64+0x1b7/0x220 ? __pfx___might_resched+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? security_file_permission+0x26/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_is_held_type+0x8f/0x100 vfs_write+0x639/0x1010 ? __pfx_ocfs2_file_write_iter+0x10/0x10 ? lock_vma_under_rcu+0x154/0x4a0 ? __pfx_vfs_write+0x10/0x10 ? lock_release+0x121/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 __x64_sys_pwrite64+0x1b7/0x220 ? __pfx___x64_sys_pwrite64+0x10/0x10 ? irqentry_exit+0xbe/0x820 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on_prepare+0x11d/0x150 ? srso_alias_return_thunk+0x5/0xfbef5 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Register dump omitted.] Allocated by task 491: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 ocfs2_allocate_refcount_tree+0x49/0x1a0 ocfs2_create_refcount_tree+0x5d7/0x1630 ocfs2_attach_refcount_tree+0x57d/0x1100 __ocfs2_reflink.isra.0+0x1c4/0x1940 ocfs2_reflink+0x501/0x9b0 ocfs2_reflink_ioctl+0x6b2/0x920 ocfs2_ioctl+0x538/0x640 __x64_sys_ioctl+0x163/0x1d0 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 498: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 ocfs2_lock_refcount_tree+0x672/0x9b0 ocfs2_xattr_set+0x72c/0x2530 ocfs2_xattr_user_set+0xaf/0xf0 __vfs_setxattr+0x143/0x1b0 __vfs_setxattr_noperm+0x112/0x5b0 __vfs_setxattr_locked+0xfe/0x2b0 vfs_setxattr+0x13c/0x370 do_setxattr+0x128/0x170 filename_setxattr+0x147/0x190 path_setxattrat+0x1ac/0x260 __x64_sys_setxattr+0xcb/0x140 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888117212800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 32 bytes inside of freed 1024-byte region [ffff888117212800, ffff888117212c00) [Page and memory dumps omitted.] Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0037-v4-9f1a261dfbc341721689@gmail.com Fixes: 374a263e790c ("ocfs2: Add refcount tree lock mechanism.") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Tao Ma Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 59d336153d40649afe86ff57d3bde1ac1588e850 Author: Jiaming Zhang Date: Mon Sep 14 11:49:40 2026 +0800 ocfs2: fix chunk number of the first chunk in a local quota file commit 4effccfd50baee4f325694964aeee997dca7bd96 upstream. Mounting a crafted OCFS2 image can corrupt kernel memory. When the local quota file header of such an image claims zero chunks, the first quota entry allocated during the mount gets a chunk number taken from a kernel pointer, and releasing that entry clears a bit far outside the chunk bitmap. The write will corrupt the data stored at that address, and the corruption may lead to a system crash or damage unrelated data. Mounting requires CAP_SYS_ADMIN, so it takes an untrusted image, such as removable media or a loop mount of a file from elsewhere. Since the chunk number comes from a kernel pointer, the address of the bit that gets cleared differs from boot to boot, and the issue has been reported under several titles: - BUG: unable to handle kernel paging request in ocfs2_local_release_dquot - KASAN: use-after-free Write in ocfs2_local_release_dquot - KASAN: slab-out-of-bounds Write in ocfs2_local_release_dquot - KASAN: slab-use-after-free Write in ocfs2_local_release_dquot - KFENCE: use-after-free write in ocfs2_local_release_dquot Note that none of these is a use-after-free in the quota code: the chunk and its buffer head are alive. The bit that gets cleared lies far outside the bitmap. KASAN and KFENCE name each report based on the object occupying that address, which explains why the same issue is reported under so many different titles. In the report I sent, the address fell in a free page, which KASAN labels use-after-free. There are known reproducers. Both a syzkaller and a C reproducer are available from the Google Drive link [1] in my report thread. The issue was found by our modified syzkaller, not a theoretical thing found by an LLM. I have not seen it outside fuzzing, so it is not affecting me in the real world. The local quota file in OCFS2 is divided into chunks, and each chunk begins with a header block holding a bitmap of the quota entries that chunk has handed out. Chunks are numbered from zero, and that number is used to convert the file offset of an entry back into a bit position in the bitmap. ocfs2_local_quota_add_chunk() appends a new chunk to the in-memory list and numbers it one past the chunk that was last: list_add_tail(&chunk->qc_chunk, &oinfo->dqi_chunk); chunk->qc_num = list_entry(chunk->qc_chunk.prev, struct ocfs2_quota_chunk, qc_chunk)->qc_num + 1; The predecessor is looked up after the new chunk is added to the list, so if the list was empty, the prev pointer is the list head itself. The head is the dqi_chunk member of struct ocfs2_mem_dqinfo and is not a chunk, so reading qc_num through it lands 16 bytes past the start of the head, on the dqi_gqinode pointer that follows it. The first chunk of the file is then numbered with the lower half of a kernel pointer instead of 0. The list is empty when the local quota file header claims the file has no chunks. ocfs2_local_read_info() takes dqi_chunks from that header without validating it, so an image with dqi_chunks == 0 takes this path when the first quota entry is allocated. ocfs2_create_local_dquot() turns the bad number into a file offset with ol_dqblk_off(), which shifts a 32-bit block number left by the block size bits, so the top bits of such a large block number are lost. ocfs2_local_release_dquot() turns the offset back into a bit index with ol_dqblk_chunk_off(), using the full chunk number, so the lost bits push that index far outside the bitmap, and clearing it corrupts unrelated memory. Compute the chunk number before putting the chunk on the list, and use 0 when the list is empty. Link: https://lore.kernel.org/20260914034940.4070970-1-r772577952@gmail.com Link: https://drive.google.com/drive/folders/1-LzPTgOALEc3eOjmgM6oOfRKkYXJ-bnO?usp=drive_link [1] Fixes: 9e33d69f553a ("ocfs2: Implementation of local and global quota file handling") Signed-off-by: Jiaming Zhang Signed-off-by: Andrew Morton Closes: https://lore.kernel.org/lkml/CANypQFZ05tpth0Xc33gmP6jgPnkY4VuezyHcsajV-SqCsmN_gg@mail.gmail.com/ Reviewed-by: Joseph Qi Assisted-by: Claude Code:claude-opus-5 Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Heming Zhao Cc: Signed-off-by: Greg Kroah-Hartman commit 5ff0f92064ab9bb344e7389c198cc9fd7ed30e29 Author: Cen Zhang Date: Wed Oct 14 11:43:40 2026 +0800 ocfs2: cancel quota sync work before freeing quota info commit 1dd1f005026d52642b994d63baa16b0b31f3b14f upstream. OCFS2 quota info owns dqi_sync_work and must outlive both its timer and qsync_work_fn(). ocfs2_local_free_info() frees that owner without cancelling the work, relying on the quota suspend/disable wrappers. Loading quotas on a read-only to read-write remount can successfully queue the work in ocfs2_global_read_info() and then fail while attaching a dquot to an existing inode in add_dquot_ref(). The quota core unwinds that failure directly through dquot_disable(), bypassing the OCFS2 wrapper: Remount task (s_umount write) Timer/workqueue ocfs2_global_read_info() schedules dqi_sync_work add_dquot_ref() returns an error dquot_disable() ocfs2_local_free_info() frees oinfo delayed-work timer expires qsync_work_fn() reads oinfo The timer core can then write to the freed embedded timer, or qsync_work_fn() can read oinfo->dqi_gqinode before its s_umount trylock. The outer ocfs2_disable_quotas() cleanup skips the failed type because dquot_disable() has already cleared its loaded state. Cancel dqi_sync_work synchronously at the start of ocfs2_local_free_info(), before dropping the global inode or freeing any owner state. The work is initialized whenever read_file_info() succeeds. dquot_disable() holds s_umount for write, so the callback skips its quota scan via down_read_trylock() and can finish without waiting for teardown. The synchronous cancel also handles its self-rearm. KASAN report as below: BUG: KASAN: slab-use-after-free in __run_timers+0x9e9/0xa10 Write of size 8 at addr ffff888111b0aad0 by task swapper/3/0 Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? __run_timers+0x9e9/0xa10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? __run_timers+0x9e9/0xa10 kasan_report+0xe0/0x110 ? __run_timers+0x9e9/0xa10 __run_timers+0x9e9/0xa10 ? __pfx___run_timers+0x10/0x10 ? __lock_acquire+0x5a3/0x2140 ? __pfx_do_raw_spin_lock+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 timer_expire_remote+0xfa/0x160 ? __pfx_timer_expire_remote+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x160 tmigr_handle_remote_up+0x4ba/0x9d0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? tmigr_handle_remote+0x21a/0x340 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups_from+0x5a/0x160 tmigr_handle_remote+0x24f/0x340 ? __pfx_tmigr_handle_remote+0x10/0x10 ? lock_acquire+0x190/0x300 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 run_timer_softirq+0x222/0x270 ? __pfx_run_timer_softirq+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xb8/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 handle_softirqs+0x1fa/0x8d0 ? __pfx_handle_softirqs+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock+0x23/0x40 ? srso_alias_return_thunk+0x5/0xfbef5 ? __hrtimer_rearm_deferred+0x1fb/0x5d0 __irq_exit_rcu+0x113/0x1e0 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 ? ct_kernel_exit.constprop.0+0xc5/0xf0 ? do_idle+0x3ae/0x650 default_idle+0x9/0x10 default_idle_call+0x6c/0xb0 do_idle+0x3ae/0x650 ? cpuhp_online_idle+0x9c/0xb0 ? __pfx_do_idle+0x10/0x10 ? __entry_text_end+0x1020f6/0x1020f9 ? lockdep_hardirqs_on_prepare+0xeb/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 cpu_startup_entry+0x54/0x60 start_secondary+0x223/0x2d0 ? __pfx_start_secondary+0x10/0x10 common_startup_64+0x13e/0x158 Allocated by task 523: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x28d/0x610 ocfs2_local_read_info+0x181/0x1580 dquot_load_quota_sb+0x69e/0x11c0 dquot_load_quota_inode+0x227/0x3e0 ocfs2_enable_quotas+0x27c/0x520 ocfs2_reconfigure+0x964/0xd00 reconfigure_super+0x3ca/0xa70 path_mount+0x141e/0x1e80 __x64_sys_mount+0x24b/0x2d0 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 523: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 ocfs2_local_free_info+0x47b/0x800 dquot_disable+0x5d9/0x17a0 dquot_load_quota_sb+0xd3c/0x11c0 dquot_load_quota_inode+0x227/0x3e0 ocfs2_enable_quotas+0x27c/0x520 ocfs2_reconfigure+0x964/0xd00 reconfigure_super+0x3ca/0xa70 path_mount+0x141e/0x1e80 __x64_sys_mount+0x24b/0x2d0 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888111b0a800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 720 bytes inside of freed 1024-byte region [ffff888111b0a800, ffff888111b0ac00) Host details, register and page dumps omitted. Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0052-v3-b4904bd6c85daf033adf@gmail.com Fixes: 1a6152d36dee ("quota: propagate error from __dquot_initialize") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Reviewed-by: Jan Kara Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Chao Yu Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit a3dd8d3af023837516d8715393acbaa7b252f6d7 Author: Joseph Qi Date: Wed Oct 14 19:23:21 2026 +0800 ocfs2/dlm: hold the lookup reference across convert AST enqueue commit 125fe08ff6cfa064e1212f586f01993ee45c0330 upstream. dlm_convert_lock_handler() drops the reference it took when it found the lock on res->granted at its leave label, one statement before it calls dlm_queue_ast(). dlm_free_dead_locks() takes res->spinlock and drops the list and base references, so a peer death landing in that gap leaves the handler's own put as the one that frees the lock, and __dlm_queue_ast() then reads lock->lockres from freed memory. The handler is registered next to dlm_create_lock_handler(), so a convert message buffered on a dying peer's socket arrives on the same o2net receive work that o2net_disconnect_node() does not wait for. The two can interleave as follows, with the reference counts as they are before this fix: Socket data-ready Node-down thread Receive worker ----------------- ---------------- -------------- o2net_data_ready() select sc under callback read lock o2net_disconnect_node() queue shutdown begin flush; new color queue sc_rx_work in the new color release callback lock shutdown socket flush returns read buffered convert_lock dlm_convert_lock_handler() find lock on res->granted dlm_lock_get() refs = 3 lock res->spinlock __dlmconvert_master() call_ast = 1 unlock res->spinlock DLM node-down cleanup lock res->spinlock dlm_free_dead_locks() unlink lock put list ref refs = 2 put base ref refs = 1 unlock res->spinlock dlm_lock_put() refs = 0 free lock dlm_queue_ast() __dlm_queue_ast() read lock->lockres (use-after-free) __dlmconvert_master() only moves the lock between lists, so the count entering the gap is base, list and lookup. Drop the lookup reference after the AST is queued instead of before it and the race ends with the one __dlm_queue_ast() took, which dlm_flush_asts() releases later with ast_pending cleared and ast_list unlinked. No extra get is needed, and the normal case ends with the same count as before. dlmconvert_master() has the same shape but is only reached from dlmlock() for a lock this node owns, which dlm_free_dead_locks() never matches. Link: https://lore.kernel.org/20261014112321.2955584-1-joseph.qi@linux.alibaba.com Fixes: 2c5c54aca9d0 ("ocfs2/dlm: Add missing dlm_lock_put()s") Signed-off-by: Joseph Qi Signed-off-by: Andrew Morton Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Signed-off-by: Greg Kroah-Hartman commit f4ae0b96a4abc7d59088eb2e0a2ee524c15f3bf0 Author: Cen Zhang Date: Tue Oct 13 23:39:29 2026 +0800 ocfs2/dlm: hold a lock reference across grant AST enqueue commit 71743471204e21113295c786e5cfa570294234a4 upstream. A newly granted remote lock must remain alive until its grant AST is queued. dlmlock_master() publishes the lock on res->granted with its base and queue references, then drops res->spinlock before calling dlm_queue_ast(). The resource's reserved AST count does not retain the lock itself. This can fail when a peer dies with an immediately grantable CREATE buffered on its socket. O2NET's node-down callback flushes receive work before DLM cleanup, but the flush only waits for work queued on entry. A data-ready callback that already selected the socket container can queue new receive work after the flush advances its work color. Socket shutdown does not discard bytes already queued for TCP receive. The late receive work and DLM node-down cleanup can interleave as follows (the lock reference operations shown are before this fix): Socket data-ready Node-down thread Receive worker ----------------- ---------------- -------------- o2net_data_ready() select sc under callback read lock o2net_disconnect_node() queue shutdown begin flush; new color queue sc_rx_work in the new color release callback lock shutdown socket flush returns read buffered CREATE dlmlock_master() lock res->spinlock add lock to granted unlock res->spinlock DLM node-down cleanup lock res->spinlock dlm_free_dead_locks() unlink lock put queue/base refs free lock unlock res->spinlock dlm_queue_ast() __dlm_queue_ast() read lock->lockres (use-after-free) DLM cleanup holds res->spinlock while dlm_free_dead_locks() drops the queue and base references. The CREATE handler no longer holds that spinlock when __dlm_queue_ast() reads the lock, before taking its AST list reference. Take a temporary lock reference under res->spinlock when a grant AST will be queued, and drop it after dlm_queue_ast(). This keeps the lock alive across cleanup until the AST path has taken its own reference, without reversing the existing AST/resource lock order. KASAN report as below: BUG: KASAN: slab-use-after-free in __dlm_queue_ast+0x8a4/0xc00 Read of size 8 at addr ffff88810ead5940 by task kworker/u16:3/52 CPU: 3 UID: 0 PID: 52 Comm: kworker/u16:3 Not tainted 7.3.0-rc4-next-20260921-pmb-bt-functional-v1+ #1 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: o2net o2net_rx_until_empty Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? __dlm_queue_ast+0x8a4/0xc00 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20e/0x420 ? __dlm_queue_ast+0x8a4/0xc00 kasan_report+0xe0/0x110 ? __dlm_queue_ast+0x8a4/0xc00 __dlm_queue_ast+0x8a4/0xc00 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_lock+0x130/0x270 ? __pfx___dlm_queue_ast+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x45/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xeb/0x1a0 dlm_queue_ast+0x46/0x70 dlmlock_master+0x51f/0xf50 ? __pfx_dlmlock_master+0x10/0x10 ? dlm_create_lock_handler+0x2b2/0x870 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 dlm_create_lock_handler+0x35b/0x870 ? __pfx_dlm_create_lock_handler+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? kvm_clock_get_cycles+0x31/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_dlm_create_lock_handler+0x10/0x10 o2net_rx_until_empty+0x1dae/0x32c0 ? reacquire_held_locks+0xdd/0x200 ? __pfx_o2net_rx_until_empty+0x10/0x10 ? lock_acquire+0x190/0x300 ? process_one_work+0x935/0x1b40 ? process_one_work+0x834/0x1b40 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 process_one_work+0x9a8/0x1b40 ? __pfx_process_one_work+0x10/0x10 ? lock_acquire+0x190/0x300 ? lock_is_held_type+0x8f/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x65c/0xe40 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kthread_parkme+0x177/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_worker_thread+0x10/0x10 kthread+0x351/0x460 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x659/0x940 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x74f/0xf70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 52: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x89/0x90 kmem_cache_alloc_noprof+0x20b/0x5c0 dlm_new_lock+0x39/0x5f0 dlm_create_lock_handler+0x16e/0x870 o2net_rx_until_empty+0x1dae/0x32c0 process_one_work+0x9a8/0x1b40 worker_thread+0x65c/0xe40 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 Freed by task 603: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kmem_cache_free+0x242/0x580 dlm_lock_release+0x1df/0x2f0 dlm_lock_put+0x51/0x80 __dlm_hb_node_down+0x15be/0x2710 dlm_hb_node_down_cb+0x6c/0xa0 o2hb_run_event_list+0x34a/0x500 o2hb_do_disk_heartbeat+0x1a07/0x2950 o2hb_thread+0x1ed/0xdc0 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff88810ead5900 which belongs to the cache o2dlm_lock of size 184 The buggy address is located 64 bytes inside of freed 184-byte region [ffff88810ead5900, ffff88810ead59b8) [Page and shadow memory dumps omitted.] Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0043-v5-1ad07df761ff49638789@gmail.com Fixes: 2c5c54aca9d0 ("ocfs2/dlm: Add missing dlm_lock_put()s") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Kees Cook Cc: Sunil Mushran Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 3e05df6bd33a920687c90061a6c0cc67cf71464a Author: Cen Zhang Date: Fri Oct 9 13:21:42 2026 +0800 ocfs2/heartbeat: unlink live slots when their node is missing commit 3ccd24c3f7a577b84a532cb027f1378385b82ef6 upstream. o2hb_shutdown_slot() returns immediately when its node is no longer in the configfs registry. A slot can still be linked in o2hb_live_slots when that lookup fails. Region teardown or startup-error cleanup then frees the slot array without removing its embedded list member. With the same peer live in another region, the next list update can follow a predecessor into the freed array. Reusing the node number can also make a later insertion encounter that stale member. Always remove the slot under o2hb_live_lock, even when node lookup fails. Preserve aggregate membership accounting and the last-region DOWN callback: the existing callback interface explicitly permits a NULL node for DOWN events. Only drop the node reference when lookup returned one. This closes both normal release and startup-abort paths without changing the publication or callback locking protocol. Also require a configured node before admitting a new live slot in o2hb_check_slot(). The early live-bitmap check is not held through admission: the last live slot in another region can be removed in between. Without a node, admission can then queue an UP event with a NULL argument and hit the event helper's BUG_ON. Existing live slots can still leave and generate NULL-node DOWN events. A controlled probe-instrumented test reproduced this while stopping one of two regions after removing the peer from configfs. Its KASAN report includes: BUG: KASAN: slab-use-after-free in __list_del_entry_valid_or_report+0x1e0/0x210 Read of size 8 at addr ffff888106a4ac60 by task o2hb-pmbd0058_b/497 Call Trace: dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 kasan_report+0xe0/0x110 __list_del_entry_valid_or_report+0x1e0/0x210 o2hb_do_disk_heartbeat+0x1591/0x2c50 o2hb_thread+0x1ed/0xe70 kthread+0x351/0x460 ret_from_fork+0x659/0x940 ret_from_fork_asm+0x1a/0x30 Allocated by task 491: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x2de/0x780 o2hb_region_dev_store+0x7c2/0x1b60 configfs_write_iter+0x2f9/0x4f0 vfs_write+0x639/0x1010 ksys_write+0x111/0x200 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 491: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x308/0x580 o2hb_unmap_slot_data+0x1db/0x330 o2hb_region_release+0x14b/0x4f0 config_item_cleanup+0x14b/0x230 config_item_put+0x79/0x90 configfs_rmdir+0x58a/0x910 vfs_rmdir+0x2e8/0x820 filename_rmdir+0x3b1/0x520 __x64_sys_rmdir+0x4b/0x70 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0058-v2-9446113c2b16c817c538@gmail.com Fixes: a7f6a5fb4bde ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Yufan Chen Cc: Kees Cook Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit f185fc81aee9ecf6011addacb077380958df5299 Author: Sean Young Date: Wed Aug 12 15:46:42 2026 +0100 media: rc: Fix ABBA deadlock by making locks more fine grained commit c6d68866ad8aa1e957a3e5a6ede971148f1e3d59 upstream. The ir_raw_event_unregister() function takes the ir_raw_handler_lock first and then the rc_dev->lock. Other functions like change_protocol do this in the reverse order. This means that an ir decoder module unload and writing to the protocol sysfs file can cause a deadlock. ir_raw_handler_lock protects the client list, amongst other things. Split this out into a separate lock so we can ensure the locking order is always the same. Fixes: 93cffffc18f6 ("[media] media: rc: fix decoder module unloading") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4528f92222e7b90b2ea634338657888f63887d7a Author: Sean Young Date: Mon Jul 6 18:47:51 2026 +0100 media: rc: Fix use after free in bpf progs commit f95a9f8472f97c30106513fc7494b7abad243949 upstream. Since commit dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks"), rcdev->raw is no longer set to NULL after device unregister. raw->progs could point to stale data. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e6ed118d14267f6bb03b9ad9ac60fdb8bd52f902 Author: Sean Young Date: Fri Sep 4 14:07:44 2026 +0100 media: rc: After rc_unregister_device() timers can be re-armed commit ef41a67979aed4d7d4f393c56c1e25b6754e2b78 upstream. If rc_keydown() is called after rc_register_device(), then the timers can be re-armed. Delete them again for a final time. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6d1be288650bb590aa3894bb060f8a5497c27bab Author: Sean Young Date: Mon Jul 13 11:18:39 2026 +0100 media: rc: Use after free in ir_raw_event_handle() commit 3ae19773168104fa57d2a2ec57731e89df54175f upstream. If rc_unregister_device() is called while IR is being processed, then ir_raw_event_handle() could call wake_up_process(dev->raw->thread) after kthread_stop(dev->raw->thread). Avoid use after free by using get_task_struct(). Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Reviewed-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0e18282783cc426207127c1214b40967a18ef939 Author: Sean Young Date: Tue Sep 1 11:02:22 2026 +0100 media: rc: mce_kbd: Fix inconsistent locking of keylock commit 29ee25fa9beb3232808e6d0b3e8ebfb0427cb820 upstream. data->keylock is taken with spin_lock() in ir_mce_kbd_decode(), which runs in the raw IR decode kthread with local interrupts enabled, but with spin_lock_irqsave() in mce_kbd_rx_timeout(), the rx_timeout timer callback, which runs in softirq context. If the decode kthread is holding keylock via spin_lock() when a timer interrupt fires on the same CPU and the softirq runs mce_kbd_rx_timeout(), the softirq spins forever waiting for a lock that only the now-preempted kthread can release, while the kthread cannot run again until the softirq gives up the CPU. This deadlocks the CPU. Fixes: 53a62800efb2 ("media: rc: mce_kbd decoder: fix race condition") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 87a2d2c15f1f7bc7ee210bf331d6668d511c0533 Author: Sean Young Date: Tue Sep 1 10:34:51 2026 +0100 media: rc: Fix race between bpf(BPG_PROG_ATTACH) and device unregister commit b3f5daf3222999d3f92f606a4eb5e35ab90fd0e4 upstream. Mark the device as unregistered before tearing down raw IR/bpf state, so that racing bpf(BPF_PROG_{ATTACH,DETACH,QUERY}) calls cannot slip in between ir_raw_event_unregister() completing and dev->registered being cleared. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d5e446e0a0541bf76e6e157a310f370699731cfd Author: Weigang He Date: Sat Sep 26 15:49:29 2026 +1000 media: rc: fintek-cir: process a full RX buffer instead of overflowing it commit d1febef1bcfa7bbc401729f994c375b91a833911 upstream. fintek_get_rx_ir_data() drains the CIR RX FIFO into fintek->buf[], which holds RX_BUF_LEN (32) bytes, for as long as CIR_STATUS reports pending RX data: do { sample = fintek_cir_reg_read(fintek, CIR_RX_DATA); ... fintek->buf[fintek->pkts] = sample; fintek->pkts++; ... } while (status & rx_irqs); Nothing bounds fintek->pkts. If the hardware reports data for more than RX_BUF_LEN reads in one interrupt, the loop writes past the end of buf[], starting with the pkts counter that follows it in struct fintek_dev. Hand a full buffer to fintek_process_rx_ir_data(), which parses the samples and resets fintek->pkts, before storing the next sample. This keeps the parser state consistent and drops no samples. The loop still relies on the status register to terminate. The driver does not document the hardware FIFO depth, so it is not known whether a working device can trigger this. Found by static analysis tool CodeQL. Fixes: 9bdc79ea07d9 ("[media] fintek-cir: new driver for Fintek LPC SuperIO CIR function") Cc: stable@vger.kernel.org Assisted-by: LLM codeql Signed-off-by: Weigang He Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit 63644a8b70dab7e67a8a6f563b7df9647324a41f Author: Sean Young Date: Fri Aug 7 11:50:22 2026 +0100 media: rc: Ensure registered is cleared in error path commit 37efd09ba2c62e46e3a3a793025c186f8cd1a417 upstream. If rc_register_device() fails, ensure that registered is not set to true. If lirc_register() succeeded, then userspace could have an open file descriptor open. This leads to a use-after-free. lirc_unregister() must be called with registered = false, else there is a possibility that an fd is open and polling, which would never return POLLERR unless registered is false. Note that registered must be changed under dev->lock, many functions read registered under lock (e.g. lirc_ioctl). Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 144ce635f8cc02955a9bfc7caf14b1818d957a63 Author: Sean Young Date: Wed Aug 12 13:00:23 2026 +0100 media: rc: Ensure that rc_unregister_device() does not free input device commit 61c7ca95d2483c77dfdde1b007cbe846f145dec4 upstream. During or after rc_unregister_device(), IR may still be reported which results in a input event being reported. This could result in a null pointer deref in rc_keydown() or a use-after-free of the input device if the pointer was read before it is set to NULL. Fixes: dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") Signed-off-by: Sean Young Cc: stable@vger.kernel.org Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 006ad1a97ab79f0173e44d82f75340243b54024b Author: Janne Grunau Date: Fri Oct 2 11:13:29 2026 +0100 nvmem: core: Fix OOB read for bit offsets of more than one byte commit 24530401e8001aaa637dd5007fcdc6fbc00300be upstream. When the bit offset is BITS_PER_BYTE or larger the read position is advanced by `bytes_offset`. This is not taken into account in the per-byte read loop which still reads `cell->bytes` resulting in an out of bounds read of `bytes_offset` bytes. The information read OOB does not leak directly as the erroneously read bits are cleared. Detected by KASAN while looking for a use-after-free in simplefb.c. Cc: stable@vger.kernel.org Fixes: 7a06ef751077 ("nvmem: core: fix bit offsets of more than one byte") Tested-by: Dmitry Sinyavin Signed-off-by: Janne Grunau Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20261002101329.1084348-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit fce1dd31b185ceadb9669162a5a35444b1059960 Author: Myeonghun Pak Date: Sun Oct 4 00:10:19 2026 -0400 power: supply: sbs-battery: disable polling before supply teardown commit 5c1c602463d597c5189ddc5a73dece588ba2c57a upstream. The managed poll-work cancellation is registered before the power supply, so cleanup unregisters the supply before draining polling. A pending or running poller can then call power_supply_changed() on the released supply. Commit 8d59cf3887fb ("power: supply: sbs-battery: Fix use-after-free in power_supply_changed()") moved the IRQ request after supply registration, but did not change the poll-work cancellation order. Add a later managed action that disables and drains polling before supply teardown. Its retained disabled state prevents external-power callbacks from rearming the poll work after it has been drained. Keep the original autocancel to initialize work before supply callbacks can run and to cover failed supply registration. The teardown ordering issue was found by static analysis. Fixes: 6d0c5de2fd84 ("power: supply: Clean-up few drivers by using managed work init") Cc: stable@vger.kernel.org # 6.10+ Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Link: https://patch.msgid.link/20261004041019.1123723-1-mhun512@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 2ea5385758a7cc863d9e2f6b642c8e7820437980 Author: Bryan O'Donoghue Date: Fri Sep 18 14:56:36 2026 +0100 phy: core: Fix race-condition between _of_phy_get() and try_module_get() commit 090055ee629523092688da42428558ba56d4272f upstream. Sashiko asked during a patch review if the existing usage pattern had a race condition; specifically in of_phy_get() if it was possible between returning from _of_phy_get() and running try_module_get() that a module might be unbound leading to use-after-free. Looking at the code this appears to be so, there is no linkage between the phy and module under a synchronisation primitive. Using the phy_provider_mutex in phy_get() will ensure there is a link between the returned phy pointer and the module_get() bumping the module reference count. Amend phy_get(), of_phy_get() and devm_of_phy_get_by_index() to fix the same usage pattern. phy_provider_unregister() must take the phy_provider_mutex so amending phy_get()/of_phy_get() to take that same mutex guarantees there is no use-after-free. Fixes: ff764963479a1 ("drivers: phy: add generic PHY framework") Cc: stable@vger.kernel.org Reviewed-by: Manivannan Sadhasivam Reviewed-by: Loic Poulain Tested-by: Oleg Keri # Lenovo Yoga Slim 7x Gen 11 (Glymur) Signed-off-by: Bryan O'Donoghue Link: https://patch.msgid.link/20260918-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v20-1-dc244e124e71@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit b3d771544f7d77bf191c7cc47c1f3f6feec1e05b Author: Nickolai Zeldovich Date: Fri Oct 16 10:00:43 2026 -0400 resource: report a devm_request_resource() conflict under the lock commit d2f7bdfdeac8137e942b32e0badc40e181127d7b upstream. devm_request_resource() calls request_resource_conflict(), which takes resource_lock, tries to insert the new resource and returns a pointer to the conflicting resource after dropping the lock. The error message is then formatted from that pointer: conflict->name and the %pR argument read the name, start, end, flags and desc of a resource that nothing pins any more. The owner of the conflicting resource may call release_resource() and free it the moment the lock is dropped. The conflicting resource normally belongs to another device. With two devices whose drivers claim overlapping regions (two PCI host bridges whose "ranges" windows overlap, two instances of a controller on the same aperture, or a stale claim an administrator is replacing), the following interleaving reads freed memory: CPU 0: driver B probe CPU 1: driver A unbind devm_request_resource(devB, root, resB) request_resource_conflict() write_lock(&resource_lock) __request_resource() -> resA write_unlock(&resource_lock) devres_release_all(devA) devm_resource_release() release_resource(resA) put_device() -> kfree(resA) dev_err(..., resA->name, resA) use after free Both halves are reachable from userspace on any kernel: a write to the "unbind" file of the driver that holds the region and a write to the "bind" file of the driver that wants it. One in-tree path is drivers/pci/bus.c devm_request_pci_bus_resources(), called from host bridge probe for every bridge window; the windows are the embedded struct resource of kzalloc'ed resource_entry objects that pci_free_resource_list() frees when the other bridge is released. In the common case the "resource collision" message is garbled; with the slab object poisoned (CONFIG_SLUB_DEBUG) or reused, formatting conflict->name oopses, and KASAN reports a slab-use-after-free read in devm_request_resource(). All of this happens in a probe that is already failing with -EBUSY. The window is a few hundred instructions wide and exists only when two devices actually collide, so the race has not been observed outside of analysis. Do the same here: take resource_lock, insert with __request_resource() and print the diagnostic while the lock still keeps the conflicting resource in the tree, then drop the lock. The return values and the devres handling are unchanged. The change was built for x86_64 and RISC-V; the resource KUnit tests pass on both. Found by formal verification of kernel/resource.c against the kernel binary. Link: https://lore.kernel.org/20261016140043.790048-1-nickolai@csail.mit.edu Fixes: 8d38821cbcf5 ("resources: Add device-managed request/release_resource()") Signed-off-by: Nickolai Zeldovich Signed-off-by: Andrew Morton Acked-by: Tejun Heo Reviewed-by: Bradley Morgan Assisted-by: LLM Cc: Bjorn Helgaas Cc: Ilpo Järvinen Cc: Thierry Reding Cc: Signed-off-by: Greg Kroah-Hartman commit 733552f8c5f5fdce6b2a135dfa2a05ead9f66e91 Author: Weibin Liu Date: Fri Oct 16 10:00:36 2026 +0800 spi: spi-pci1xxxx: quiesce DMA engines on transfer timeout commit 0b591332a2bdc13d3f9163793131fe3651d1556a upstream. If a DMA-mapped transfer times out waiting for DMA_TERM and neither DMA abort interrupt arrived, pci1xxxx_spi_transfer_with_dma() returns through the error label while both DMA engines are still enabled, the done/abort interrupt status is still armed and the transfer state (p->xfer, p->tx_sgl, p->rx_sgl) is still registered. The ISRs keep firing afterwards: they reprogram the DMA engines from p->tx_sgl / p->rx_sgl and signal completion through p->xfer and p->spi_xfer_done, all of which the SPI core is free to unmap or reuse once transfer_one() has returned, which is a use-after-free. A late done interrupt can also start the next transfer queued behind the failed one. Stop both DMA engines, drain the pending done/abort interrupt status and synchronize the DMA IRQs before dropping the in-progress state and the transfer pointers, and re-enable the engines afterwards so that subsequent transfers keep working. The engines are only turned back on once both were confirmed to have stopped: re-enabling an engine that failed to stop would cancel the pending stop request and let it keep running into buffers the SPI core is about to unmap or free, which is exactly the window this patch closes. An engine that failed to stop is left disabled, as the abort paths already do. The DMA interrupt status and mask registers are shared between the two SPI instances, so the cleanup drains only this instance's done/abort status bits instead of masking the interrupt lines, which would also suppress the peer instance's completion interrupts. Also make the DMA ISRs ignore interrupts while no transfer is in progress so that a stray MSI after the cleanup can no longer act on the cleared state. No PCI1XXXX hardware was available for testing and QEMU has no model of this PCIe part, so the timeout path was exercised with a userspace replica of the timeout branch and the DMA ISRs, with the register and interrupt accesses mocked: on the unfixed code both a wedged engine that clears after the timeout and a late done interrupt touch the freed transfer state, while with this fix applied neither does and an engine that failed to stop is left disabled. The module was also loaded and unloaded in a QEMU x86_64 guest running a kernel with this fix applied. Fixes: 9538edeb72c9 ("spi: mchp-pci1xxxx: DMA support for copying data to and from SPI Buf") Cc: stable@vger.kernel.org # 6.8+ Signed-off-by: Weibin Liu Link: https://patch.msgid.link/20261016020036.1333548-1-liuwb@xiaopeng.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c792858491ee39e8f6e1547c45422595cf25b415 Author: YANXIN LI Date: Sat Jul 18 19:03:07 2026 +0000 ufs: use u64 for directory size in ufs_last_byte commit 1eff23433e73d7da4f9e3529d2701e34962b161f upstream. ufs1_read_inode() and ufs2_read_inode() copy the untrusted 64-bit on-disk size into inode->i_size. ufs_last_byte() then truncates that value to an unsigned int before calculating the valid extent of a directory folio. A directory size of exactly 4 GiB is truncated to zero. In ufs_find_entry(), subtracting the requested record length from that zero forms an endpoint almost 4 GiB beyond the mapped folio. A crafted UFS2 image produces: BUG: KASAN: use-after-free in ufs_find_entry+0x583/0x6e0 [ufs] Read of size 1 ... ufs_find_entry ufs_inode_by_name ufs_lookup __lookup_slow path_lookupat The KASAN classification reflects that the adjacent physical page was free; the source-level operation is an out-of-folio read. A controlled UFS1 test with CONFIG_UFS_FS_WRITE enabled also made ufs_find_entry() return a directory entry from an adjacent anonymous page. unlink() then passed that pointer to ufs_delete_entry(), which cleared the adjacent page's 3 2-bit d_ino. This write result reproduced three out of three times. UFS normally requires a privileged mount path. A relevant boundary is a privileged automounter or image-processing service handling an attacker-supplied filesystem. The write primitive additionally requires UFS1 to be mounted read-write with CONFIG_UFS_FS_WRITE enabled; the read is reachable with read-only UFS2. Keep the intermediate size arithmetic at 64 bits so non-final pages are bounded at PAGE_SIZE. With this change, the same controlled tests reach the real on-disk directory entry and produce no adjacent-page write or KASAN report. A reproducer and full validation logs are available on request. The vulnerable helper is present in v7.2-rc3, v7.1, v6.18.38, v6.12.95, v6.6.111, and upstream master at 1229e2e57a5c. Runtime reproduction and fix validation were performed in an x86-64 QEMU guest running v7.2-rc3 with generic KASAN. Fixes: b71034e5e67d ("[PATCH] ufs: directory and page cache: from blocks to pages") Cc: stable@vger.kernel.org Signed-off-by: YANXIN LI Link: https://patch.msgid.link/20260718190300.867109-1-fadouse@pm.me Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit e7e89759445e97ccb445758c6c8d5caed4eb42f9 Author: Nguyen Quang Le Kien Date: Tue Aug 11 14:08:10 2026 +0800 usb: gadget: fix refcount underflow in gadgetfs_bind() error path commit cb3b441f2698455a48e9a023d5f7f4e3fcb94c73 upstream. gadgetfs_bind() calls get_dev() only on the success path, but gadgetfs_unbind() called from the enomem error label unconditionally calls put_dev(). When bind fails (e.g. ENOMEM), put_dev() fires without a matching get_dev(), leaving the refcount unbalanced. A subsequent close of the ep0 file descriptor calls dev_release() -> put_dev() which hits zero and frees the object; then gadgetfs_kill_sb() calls put_dev(the_device) again on the already-freed pointer, triggering a refcount underflow and use-after-free. Fix by calling get_dev() at the start of gadgetfs_bind(), before any error path that invokes gadgetfs_unbind(), so the reference is always balanced regardless of whether bind succeeds or fails. Reported-by: syzbot+8496ab5e117502750445@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=8496ab5e117502750445 Signed-off-by: Nguyen Quang Le Kien Reviewed-by: Alan Stern Link: https://patch.msgid.link/20260811060810.295666-1-khiemtranzo532001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 26dc15da08f15e8320514d700d6a4c449d1bb047 Author: Zhao Li Date: Tue Aug 25 19:26:20 2026 +0800 wifi: mt76: mt7996: unlink TWT flow if the MCU rejects the agreement commit 022f5f8b7a0580da50fcbc34da853d03d4321fe2 upstream. mt7996_mac_add_twt_setup() links a new flow into dev->twt_list before asking the MCU to add the agreement, but exits without unlinking the flow if the request fails. The flow-ID and table masks are only committed after MCU success, so the still-linked flow is invisible to the mask-gated teardown paths. If the station retries the setup, the same slot is cleared and its embedded list node reinitialized while it is still linked, corrupting dev->twt_list. If the station disassociates instead, teardown skips the flow and station storage can be freed while the node remains linked. A later scheduling or debugfs twt_stats walk can then dereference the freed flow, resulting in a use-after-free. Unlink the flow when the MCU rejects the agreement. This restores the list to its pre-request state while leaving the unchanged mask and agreement accounting untouched. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260729173632.14387-3-enderaoelyther@gmail.com/ Assisted-by: Codex:gpt-5.6-sol Assisted-by: Kimi:K3 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260825112620.97568-1-enderaoelyther@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 49e05c8d3d8f546a9723e0fca20df02703f9015d Author: Rosen Penev Date: Fri Sep 11 14:31:44 2026 -0700 wifi: ath9k: delete channel-context timers on deinit commit 81394dfb9a7905472957628b560ae894eae3a30f upstream. ath9k_deinit_channel_context() cancels chanctx_work but does not delete the offchannel and sched timers set up by ath9k_init_channel_context(). If either timer fires after deinit (e.g. during driver unload or suspend), it accesses sc->sc_ah which may already be freed by ath9k_hw_deinit(), causing a use-after-free. Delete both timers with timer_shutdown_sync() before cancelling the work item. Assisted-by: LLM Signed-off-by: Rosen Penev Acked-by: Toke Høiland-Jørgensen Cc: stable@vger.kernel.org # v6.2+ Fixes: 705d0bf83dbe ("ath9k: Add a routine for initializing channel contexts") Link: https://patch.msgid.link/20260911213144.130192-1-rosenp@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit e64707d07fcda07c71d4f1405c1bedb0787a6889 Author: Yuchao Zhang Date: Tue Sep 22 15:21:55 2026 +0800 xen-blkfront: unbind irq before tearing down ring and shadow requests commit f3e27b7955727a4d7c0e9264a2a209fbba788bdc upstream. In blkif_free_ring(), the driver tears down the ring's persistent grants, shadow request arrays, and shared ring structure (xenbus_teardown_ring), and only calls unbind_from_irqhandler() at the very end. While blkif_free_ring() is freeing persistent grants and clearing the shadow array, the event channel interrupt (blkif_interrupt) is still registered and active. If an interrupt arrives from the backend during this teardown window, blkif_interrupt() reads rinfo->ring.sring and, via blkif_completion(), accesses rinfo->shadow[id].grants_used and rinfo->shadow[id].sg. blkif_free_ring() tears these structures down without holding rinfo->ring_lock, and the handler only checks info->connected at entry, so this is a real race resulting in a use-after-free or NULL pointer dereference. Fix this by moving unbind_from_irqhandler() to the beginning of blkif_free_ring(). Calling unbind_from_irqhandler() first frees the IRQ and synchronizes with any in-flight interrupt handlers on other CPUs before ring memory and shadow request structures are deallocated, matching the teardown order in drivers/net/xen-netfront.c. Fixes: 11659569f720 ("xen/blkfront: split per device io_lock") Cc: stable@vger.kernel.org Signed-off-by: Yuchao Zhang Acked-by: Roger Pau Monné Signed-off-by: Juergen Gross Message-ID: <20260922072155.34625-1-ndaugoing@gmail.com> Signed-off-by: Greg Kroah-Hartman commit 0f332cce4d592d751aad89b404f68463099167c8 Author: Igor Putko Date: Sat Oct 3 19:33:37 2026 +0300 serial: core: shut down initialized port on removal commit 810d467c11f0c85107874d08dfdd11acba6aa0c0 upstream. When a serial port configured as a console is opened and subsequently closed, tty_port_shutdown() skips invoking port->ops->shutdown() because port->console is true. As a result, tty_port_initialized() remains true and the port's interrupt handler stays registered in the irq subsystem. If the underlying device is later unbound or removed (e.g. via sysfs driver unbind or device hot-unplug), serial_core_remove_one_port() unregisters the console, frees uport->name via kfree(), and tears down the port without shutting it down or freeing its IRQ. Consequently, the irqaction descriptor remains registered in genirq with action->name pointing to freed memory. This triggers a use-after-free read whenever genirq accesses action->name, such as when reading /proc/interrupts: BUG: KASAN: slab-use-after-free in string+0x476/0x570 Call Trace: string+0x476/0x570 vsnprintf+0x422/0x1300 seq_printf+0x... show_interrupts+... Fix this by acquiring port->mutex in serial_core_remove_one_port() after console unregistration, clearing port->console under the mutex to prevent data races with concurrent tty_port_shutdown(), and invoking uart_shutdown(NULL, state) if the port remains initialized. This ensures that port->ops->shutdown() is called and the IRQ is freed before kfree(uport->name). Reported-by: syzbot+843bf2f48f4d12e6682e@syzkaller.appspotmail.com Cc: stable Closes: https://syzkaller.appspot.com/bug?extid=843bf2f48f4d12e6682e Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") Fixes: f7048b15900f ("tty: serial_core: Add name field to uart_port struct") Signed-off-by: Igor Putko Link: https://patch.msgid.link/20261003163337.45577-1-igorpetindev@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a79de0e5e66bd0b69b38c855413a9e3a82926b24 Author: Fan Wu Date: Fri Sep 11 02:05:44 2026 +0000 scsi: dc395x: sync the waiting_timer before freeing the host commit 0b1a79f2791a06f139dce5450e487307cf0e241f upstream. The waiting_timer callback re-arms itself and takes the host lock. adapter_uninit() currently stops it with timer_delete(), which does not wait for a callback already running on another CPU. The final scsi_host_put() that frees the host (and the host lock the callback dereferences) runs right after adapter_uninit(), so a concurrent or just re-armed callback can fire after the free, leaving a potential use-after-free window. Replace timer_delete() with timer_shutdown_sync() at the top of adapter_uninit(), before the host-lock section: the timer is dequeued, a running callback is waited for and rearming is blocked before the chip is halted, so it cannot fire at all once the adapter has ceased to function. Waiting outside the lock avoids the self-deadlock that would result from syncing a callback blocked on the lock we still hold. No shutdown is needed for selto_timer because it has no reachable armer or callback. This issue was found by an in-house static analysis tool. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Cc: Jamie Lenehan Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260911020544.42966-1-fanwu01@zju.edu.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Greg Kroah-Hartman commit 325da0365ffa4f19ca50a9be2931a18bb252c07a Author: Vernon Yang Date: Wed Sep 9 10:58:03 2026 +0800 mm: khugepaged: fix folio is used after folio_put/unlock() commit 9010383e71e6ce75fcd3c8f87133c8ce6c0e6ab4 upstream. On the rollback path, folio_put() has already dropped the last reference of new_folio. On the success path, new_folio is already unlocked and can be freed concurrently. The trace_mm_khugepaged_collapse_file() is left with a dangling folio pointer. So using the folio_pfn() before dropping the reference, closing use-after-free window. Link: https://lore.kernel.org/20260909025804.3233645-4-vernon2gm@gmail.com Fixes: 4c9473e87e75 ("mm/khugepaged: add tracepoint to collapse_file()") Signed-off-by: Vernon Yang Signed-off-by: Andrew Morton Acked-by: David Hildenbrand (Arm) Acked-by: Lorenzo Stoakes (ARM) Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Ryan Roberts Cc: Zach O'Keefe Cc: Signed-off-by: Greg Kroah-Hartman commit 590f48b5644319437ad2bb8d64d5cfd4f5a5ed7b Author: Imre Kaloz Date: Wed Oct 14 17:08:43 2026 +0200 mm/slab: sample slab_state once in kmem_cache_destroy() commit 088bfdc0d7947d623f4899b9011c866e4445074d upstream. kmem_cache_release() tests slab_state >= FULL after kmem_cache_destroy() has dropped slab_mutex and unlinked the cache, and for a SLAB_TYPESAFE_BY_RCU cache after rcu_barrier(). If slab_late_init() runs before that test it sets slab_state to FULL but skips the unlinked cache, which never got a sysfs entry, so sysfs_slab_release() calls kobject_put() on a kobject that was never initialized: WARNING: lib/kobject.c:734 at kobject_put+0x64/0x2c0, CPU#1: kworker/u8:3/55 kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_put() is being called. refcount_t: underflow; use-after-free. kobject_put+0x64/0x2c0 sysfs_slab_release+0xc/0x20 kmem_cache_destroy+0x104/0x1e0 bioset_exit+0x13c/0x1e0 disk_release+0x54/0x140 put_disk+0x18/0x40 floppy_async_init+0xbec/0xd10 slab_state >= FULL asks whether the cache has a kobject, which cache creation skips while slab_state <= UP. UP is the state just below FULL, so a false sample cannot skip a kobject_put() that was owed. Seen on sparc64 at boot, where the asynchronous floppy init tears down its bio slab while the late initcalls are running. Sample slab_state once, under slab_mutex which slab_late_init() holds when it sets FULL, and use the result for both the unlink and the release. The history of this problem dates back to v3.2: Commit 69cb8e6b7c29 ("slub: free slabs without holding locks") in v3.2 moved sysfs_slab_remove() outside slub_lock and introduced a race condition between kmem_cache_destroy() and slab_sysfs_init(). Commit 945cf2b6199be ("mm/sl[aou]b: Extract a common function for kmem_cache_destroy") in v3.7 accidentally closed the race while extracting a common implementation for kmem_cache_destroy(). Commit 5413dfba88d6 ("slub: drop mutex before deleting sysfs entry") in v3.8 re-opened the race by dropping slab_mutex around sysfs_slab_remove() in __kmem_cache_shutdown(), to avoid a lockdep splat between slab_mutex and the sysfs lock. Commit 657dc2f97220 ("slab: remove synchronous rcu_barrier() call in memcg cache release path") in v4.11 shifted from synchronous rcu_barrier() to asynchronous RCU work for SLAB_TYPESAFE_BY_RCU caches. That commit, again, accidentally closed the race by moving sysfs_slab_release() to shutdown_cache(), but only for !SLAB_TYPESAFE_BY_RCU caches because destruction of SLAB_TYPESAFE_BY_RCU caches is done in an RCU work. Commit 0495e337b703 ("mm/slab_common: Deleting kobject in kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock") in v6.0 re-introduced the race for !SLAB_TYPESAFE_BY_RCU caches. Fixes: 69cb8e6b7c29 ("slub: free slabs without holding locks") Fixes: 5413dfba88d6 ("slub: drop mutex before deleting sysfs entry") Fixes: 0495e337b703 ("mm/slab_common: Deleting kobject in kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock") Cc: stable@vger.kernel.org Signed-off-by: Imre Kaloz Reviewed-by: Jose A. Perez de Azpillaga Reviewed-by: Harry Yoo (Meta) Link: https://patch.msgid.link/20261014150844.8536-1-kaloz@kernel.org Reviewed-by: Vlastimil Babka (SUSE) Signed-off-by: Harry Yoo (Meta) Signed-off-by: Greg Kroah-Hartman commit e848c0bd189bd41189f20249a4d71895ff884f40 Author: Fan Wu Date: Thu Jul 30 07:15:52 2026 +0000 media: s5p-mfc: use timer_shutdown_sync() for the self-rearming watchdog commit 63069b5917cba2e15b1a78b3f4ff99e45102c56f upstream. The MFC watchdog timer (s5p_mfc_watchdog) is self-rearming: every callback re-arms itself with add_timer() and, on a timeout, schedules watchdog_work. s5p_mfc_remove() tears this down with timer_delete_sync() followed by flush_work(). timer_delete_sync() dequeues the timer and waits for a callback that is already running, but it does not prevent a subsequent re-arm. Because the watchdog callback re-arms via add_timer(), this is the wrong shutdown primitive: once the wait returns nothing guarantees a just-queued re-arm will not fire later, dereferencing dev (clock on/off, deinit_hw, load_firmware, init_hw) after video_unregister_device(), DMA teardown and s5p_mfc_final_pm() have run, a potential use-after-free. Use timer_shutdown_sync(), which puts the timer into a shutdown state so that any add_timer()/mod_timer() from the callback becomes a no-op and no later firing is possible. Switch flush_work() to cancel_work_sync() so any watchdog_work that was already queued before the timer was stopped is cancelled rather than allowed to run to completion against the torn-down device. This issue was found by an in-house static analysis tool. No runtime reproducer is available. Fixes: af9357467810 ("[media] MFC: Add MFC 5.1 V4L2 driver") Cc: stable@vger.kernel.org Cc: Andrzej Hajda Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Reviewed-by: Marek Szyprowski Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 98e3df13c9fd57cc4051e9ee1717cfc65ee04c7d Author: Rik van Riel Date: Sat Aug 8 23:20:31 2026 -0400 media: redrat3: fix UAF in probe error path leaving rc device registered commit af452b9e01331b5338a1e5141624f17607239207 upstream. redrat3 stores its device name and phys path inside the main rr3 structure, and the rc device's device_name and input_phys point into rr3. When the RC device is registered, it keeps those pointers. KASAN: slab-use-after-free in string_nocheck lib/vsprintf.c:648 Read of size 1 at addr ffff888051fda758 by task udevd/7464 Call Trace: string_nocheck lib/vsprintf.c:648 [inline] string+0x216/0x2d0 lib/vsprintf.c:730 vsnprintf+0x74a/0xef0 lib/vsprintf.c:2945 vscnprintf+0x41/0x90 lib/vsprintf.c:3014 sysfs_emit+0x10e/0x180 fs/sysfs/file.c:761 input_dev_show_name+0x58/0x70 drivers/input/input.c:1282 Allocated by task 10: redrat3_dev_probe+0x477/0x2570 drivers/media/rc/redrat3.c:1023 Freed by task 10: redrat3_delete drivers/media/rc/redrat3.c:466 [inline] redrat3_dev_probe+0x1bf4/0x2570 drivers/media/rc/redrat3.c:1124 Syzkaller triggers this via usb probing. It probes the RedRat3 USB interface, which calls redrat3_dev_probe() in redrat3.c. That function allocates rr3, then builds an rc device whose name points into rr3 via redrat3_init_rc_dev() in redrat3.c, and registers it with rc_register_device(). When the detector enable fails after the RC device is registered, the probe jumps to the led_free path. That path unregisters the LED but does not unregister the RC device before freeing rr3 via redrat3_delete() in redrat3.c. The RC device still holds device_name = rr3->name which is now freed. Later udevd reads /sys/.../input device name via sysfs_emit() in file.c, which calls input_dev_show_name() in input.c, which emits dev->name which is the freed rr3->name. When the detector enable fails after the RC device is registered, the error path must not leave the RC device registered. Make the probe error path clean up the same way redrat3_dev_disconnect() does. This change should be safe because the RC device is fully registered at this point and its teardown via rc_unregister_device() is protected by the input device mutex, and rr3 is still alive during unregister so device_name remains valid until after unregister. The URBs are killed before rc_free, so no completion can run after rc is freed. No new lock ordering is introduced. Reported-by: syzbot+302b9b575a06733ff60c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=302b9b575a06733ff60c Link: https://lore.kernel.org/all/6a74a76d.ec7c9571.3ac9bb.0056.GAE@google.com/ Fixes: 2154be651b90 ("[media] redrat3: new rc-core IR transceiver device driver") Cc: stable@vger.kernel.org Assisted-by: Hermes:muse-spark-1.2 syzkaller Signed-off-by: Rik van Riel Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit 1711d758ede7ad6dc9f9b96366a6eea5c8c867df Author: Balakrishnan Sambath Date: Mon Aug 17 12:21:59 2026 +0530 media: microchip-isc: take a reference on the parsed endpoints commit f2eb2fd388bf3f1959556a326e797cacca341c86 upstream. for_each_endpoint_of_node() drops the reference on the current node as it advances. xisc_parse_dt() and isc_parse_dt() store the node in subdev_entity->epn and release it later with of_node_put(), but never took their own reference, so the stored pointer refers to an already-released node. This underflows the refcount and can use-after-free, reachable through the camera device tree overlay. Take a reference with of_node_get() when storing the node, and drop it in microchip_isc_subdev_cleanup() so the entities the bind loop never reaches on an early exit do not leak it. Fixes: c9aa973884a1 ("media: atmel: atmel-isc: add microchip-xisc driver") Fixes: d6701f13bd07 ("media: atmel: Use v4l2_async_notifier_add_fwnode_remote_subdev") Cc: stable@vger.kernel.org Signed-off-by: Balakrishnan Sambath Reviewed-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9fa70d75ab03f5babb072ad872a54879af4be55c Author: Cong Nguyen Date: Sat Aug 8 16:07:29 2026 +0700 media: microchip-csi2dc: fix async notifier leak on probe error path commit c7528789244ce7329ca883170fb9315d739ae985 upstream. csi2dc_of_parse() ends up calling csi2dc_prepare_notifier(), which registers the V4L2 async notifier with v4l2_async_nf_register(). The probe error label csi2dc_probe_cleanup_notifier is reached after csi2dc_of_parse() has already succeeded (e.g. when media entity init, csi2dc_power() or v4l2_async_register_subdev() fail), but it calls only v4l2_async_nf_cleanup() and never v4l2_async_nf_unregister(). The notifier therefore stays chained in the global notifier_list while the enclosing struct csi2dc_device is freed, leading to list corruption and a use-after-free when the list is next walked. Unregister the notifier before cleaning it up on the error path, matching the teardown already done in csi2dc_remove(). Fixes: 2de0b3c0f678 ("media: atmel: introduce microchip csi2dc driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4 Signed-off-by: Cong Nguyen Reviewed-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 12d0222809f943d9bcaffd5fe1d8b9d2c3c74f07 Author: Fan Wu Date: Fri Aug 7 05:35:53 2026 +0000 media: marvell: mcam: stop DMA and cancel s_bh_work before freeing DMA buffers commit 0f29f84317c1e35f6a9265277be33e60d3fc8c1c upstream. In vmalloc mode the frame-completion IRQ queues mcam_frame_work() on cam->s_bh_work, which memcpy()s from the dma_bufs[] that mcam_free_dma_bufs() frees with dma_free_coherent(). mccic_shutdown() frees those buffers without stopping the controller, so while streaming a late frame IRQ can re-arm the work after the buffers are gone, causing a use-after-free. Stop the controller in mccic_shutdown() when streaming is still active (gated on an open fd, which holds a runtime-PM reference, so the device is powered), cancel s_bh_work in mcam_free_dma_bufs(), and move INIT_WORK() into mccic_register() before the device can be published. Fixes: 67a8dbbc4e04 ("[media] marvell-cam: Basic working MMP camera driver") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 49a0623994a10d3d333d48c304f89d816495f332 Author: Fan Wu Date: Tue Jun 23 10:30:31 2026 +0000 media: imx-jpeg: cancel timeout worker when streaming stops commit 78fdfbf117c409273eecbfa7a528ef42358a0e38 upstream. Each per-fd context ctx owns a delayed_work (ctx->task_timer, callback mxc_jpeg_device_run_timeout) armed via schedule_delayed_work() at the end of mxc_jpeg_device_run() to recover a stalled encode/decode job. The only existing cancellation is cancel_delayed_work() in the frame-done IRQ handler, which de-queues a pending work item but does not wait for a callback that has already started, and it only runs when a frame completes. When the fd is closed while a job is in flight (the frame-done IRQ has not fired yet), nothing syncs the worker before mxc_jpeg_release() frees ctx with kfree() after v4l2_m2m_ctx_release(). A queued or executing mxc_jpeg_device_run_timeout() can then recover ctx through container_of(&ctx->task_timer) and dereference it (ctx->mxc_jpeg, slot_data, dev_warn) after ctx has been freed. Cancel the worker from mxc_jpeg_stop_streaming(). The cancel cannot live in mxc_jpeg_release(): mxc_jpeg_device_run() arms the timer while holding only hw_lock, not the mxc_jpeg->lock mutex that release holds, so a cancel in release could still race a concurrent mxc_jpeg_device_run() that re-arms the timer afterwards. mxc_jpeg_stop_streaming() instead runs inside v4l2_m2m_ctx_release() -> vb2_queue_release(), i.e. after v4l2_m2m_cancel_job() has set TRANS_ABORT and waited for any in-flight job to finish (so __v4l2_m2m_try_queue() will not queue and v4l2_m2m_try_run() will not run any further job for this context, which prevents mxc_jpeg_device_run() from re-arming the timer) and before the m2m context is freed. cancel_delayed_work_sync() removes a pending work item and waits for a running callback, so the worker can no longer race with the subsequent kfree(). The cancel is placed before the buffer-release loop so a concurrently running timeout callback cannot race with it over the same buffers. If the frame-done IRQ canceled a still-pending timer, this cancel is a no-op; if the timeout callback has already started, it waits for the callback to finish. The same mxc_jpeg_stop_streaming() call is also reached from VIDIOC_STREAMOFF, which drains the worker early, although STREAMOFF itself does not free ctx -- the use-after-free arises only when the fd is later closed. This bug was found by static analysis. Fixes: cfed9632ca8e ("media: imx-jpeg: Add a timeout mechanism for each frame") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Reviewed-by: Ming Qian Signed-off-by: Frank Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d02a2ed057372d3739ab23d778fc4e04d3330513 Author: Shuangpeng Bai Date: Wed Aug 12 23:12:35 2026 -0400 media: gspca: use vb2_video_unregister_device() on disconnect commit 3dbbbc3cafa2de377d9b97af4e35b8b6b5282047 upstream. gspca uses vb2_fop_release(), but gspca_disconnect() only unregisters the video device. If the queue owner closes the device after USB disconnect, vb2_fop_release() releases the queue and invokes gspca_stop_streaming() at that point. gspca_stream_off() calls subdriver stop callbacks and usb_set_interface() through gspca_dev->dev. By the time the late close runs, the USB core can have freed the usb_device, resulting in a use-after-free. This was observed as a KASAN use-after-free in sd_stopN(). Use vb2_video_unregister_device() so the queue is released and streaming is stopped synchronously during disconnect, while the usb_device is still valid. Since the helper takes the queue lock, which is usb_lock, call it after dropping that lock. Fixes: f729ef5796d8 ("media: videobuf2-v4l2.c: add vb2_video_unregister_device helper function") Cc: stable@vger.kernel.org # 5.10.x Suggested-by: Hans Verkuil Signed-off-by: Shuangpeng Bai Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cbe537c64b8fb1d0cf4bee20f89204fa51e384e5 Author: Myeonghun Pak Date: Sat Sep 12 22:05:54 2026 -0400 media: cx23885: unregister DVB bus when SP2 CI setup fails commit 22f552ff726a82a086be4ef02ce5099a0e8624b6 upstream. The DVBSKY S950C, DVBSKY T980C and TechnoTrend CT2-4500 CI paths register the DVB bus before attaching their SP2 CI client. If that client cannot be created, bound, or pinned, the current error path removes the I2C frontend components and only deallocates the frontend list, leaving the registered DVB adapter behind. Removing an I2C demod before unregistering the DVB bus can also expose the use-after-free ordering fixed for the normal remove path. Unregister the DVB bus immediately when SP2 CI setup fails, before the existing I2C client cleanup. The bus helper empties the frontend list, so the later frontend deallocation has nothing left to release. Keep failures from vb2_dvb_register_bus() on the existing cleanup path. Also release an unbound SP2 client and propagate the actual I2C creation or CI registration error. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 2b0aac3011bc ("[media] cx23885: move CI/MAC registration to a separate function") Cc: stable@vger.kernel.org Assisted-by: OpenAI:GPT-5.6 Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4ab2c987fd15a4bd28ef46a9ac871359886e6439 Author: Amit Machhiwal Date: Mon Sep 28 17:58:35 2026 +0530 KVM: PPC: Book3S HV: Add SRCU protection for virtual-mode HPT hcalls commit 61a39797bb136243c48b46e2586d8a9e2cea6a89 upstream. The virtual-mode HPT hcall handlers (H_ENTER, H_REMOVE, H_BULK_REMOVE, H_CLEAR_REF, H_CLEAR_MOD) call into book3s_hv_rm_mmu.c, which accesses memslots via kvm_memslots_raw(). kvm_memslots_raw() uses rcu_dereference_raw_check() to bypass SRCU lockdep annotation checking. This is safe in real mode because the entire guest entry/exit is wrapped in srcu_read_lock/unlock inside kvmppc_run_core() and kvmhv_run_single_vcpu(). However, since commit 6165d5dd99db ("KVM: PPC: Book3S HV: add virtual mode handlers for HPT hcalls and page faults"), these same handlers are also executed in virtual mode via kvmppc_pseries_do_hcall(), which runs after SRCU has already been released on guest exit. A concurrent KVM_SET_USER_MEMORY_REGION deletion or move can therefore call synchronize_srcu_expedited() — which does not wait for this thread — and then kfree(slot) and vfree(slot->arch.rmap) while the hcall handler still holds a raw pointer to the memslot. lock_rmap() then writes to freed vmalloc memory, leading to use-after-free and memory corruption. Because kvm_memslots_raw() suppresses lockdep checks, this race is entirely silent. Fix this by factoring out the 7 HPT hcall handlers (H_REMOVE, H_ENTER, H_READ, H_CLEAR_MOD, H_CLEAR_REF, H_PROTECT, H_BULK_REMOVE) into a helper function, kvmppc_pseries_do_hpt_hcall(), and wrapping its call site in srcu_read_lock(&kvm->srcu) / srcu_read_unlock(&kvm->srcu, idx). Targeting only the HPT hcalls avoids wrapping non-HPT hcalls that sleep (such as H_CONFER, H_REGISTER_VPA, H_PAGE_INIT) or handlers that already acquire SRCU internally (such as H_RTAS). Fixes: 6165d5dd99db ("KVM: PPC: Book3S HV: add virtual mode handlers for HPT hcalls and page faults") Cc: stable@vger.kernel.org # v5.14+ Suggested-by: Ritesh Harjani (IBM) Signed-off-by: Amit Machhiwal Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260928122837.8782-2-amachhiw@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 881ec3e0d29aa3eabe19f0ff6aec60ae9efa71e0 Author: Nicolin Chen Date: Tue Sep 15 09:38:13 2026 -0700 iommu/arm-smmu-v3: Disable the impl before disabling the SMMU on shutdown commit ab0dbf411aced59c04ce86fd8443faf13bdc9936 upstream. arm_smmu_device_shutdown() only calls arm_smmu_device_disable(), and never the impl_ops->device_disable() hook. On tegra241-cmdqv, that hook quiesces every VINTF through tegra241_vintf_hw_deinit(), which issues a CMD_SYNC on the shared CMDQ while it is still enabled. arm_smmu_disable_action() already runs this hook before disabling the SMMU, to cover an unbind or a probe failure, and no devres release ever follows a reboot or a kexec to run it again. Have arm_smmu_device_shutdown() call it directly, instead of reimplementing part of what it already does. Fixes: 9ff145a25c5c ("iommu/tegra241-cmdqv: Fix CMD_SYNC use-after-free on teardown") Cc: stable@vger.kernel.org Reviewed-by: Jonathan Cameron Assisted-by: LLM Signed-off-by: Nicolin Chen Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 35096f62ca37ef7d929c89c35938372f365aad25 Author: Andrea Parri Date: Mon Sep 28 10:48:06 2026 +0200 iomap: don't resubmit an ioend after ->writeback_submit() failed commit 3f517370076f1fedaa38cd8c78ceb73616b79336 upstream. iomap_add_to_ioend() submits the pending ioend through ->writeback_submit() before allocating a new one for the current range. When the submission fails the helper completes the ioend with an error, but iomap_add_to_ioend() returns the error without clearing wpc->wb_ctx. iomap_writepages() then submits whatever wpc->wb_ctx points to, so the already completed ioend is submitted a second time. For XFS the second bio_endio() lands in xfs_end_bio(), which list_add_tail()s the already linked ioend into ip->i_ioend_list. This corrupts the list and leaves a use-after-free/double-free window against the ioend completion worker. Reproduced with a fault-injected ->writeback_submit() failure on a reflinked XFS file with several CoW writeback ranges in flight: the unfixed kernel hits repeated "list_add double add" warnings from __list_add_valid_or_report(), the fixed kernel fails writeback cleanly. Clear wpc->wb_ctx when ->writeback_submit() fails. The old iomap_submit_ioend() cleared the context unconditionally; that clear was lost when submission moved to iomap_ioend_writeback_submit(). The final ->writeback_submit() call in iomap_writepages() needs no equivalent fix: it is the last thing the function does before returning, and every caller allocates its iomap_writepage_ctx on the stack for a single call, so wpc->wb_ctx is never read again afterwards. Fixes: f4fa7981fa26 ("iomap: hide ioends from the generic writeback code") Cc: stable@vger.kernel.org # v6.17 Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Andrea Parri Link: https://patch.msgid.link/90fbd42df4f51306e57a95830d2d53873f630eb9.1790342457.git.parri.andrea@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 2efcf743664ab4a83b4fae1f152bbea1d298e73f Author: Kyle Zeng Date: Sun Oct 25 02:27:52 2026 +0000 io_uring/io-wq: save worker type before dropping its reference commit 37e425460b7c41687e51e3254b1eb1d799da9614 upstream. io_wq_cancel_tw_create() inspects cb->func after calling io_worker_cancel_cb(). For an existing worker, that call can drop the last worker reference and wake io_worker_exit(). If the canceling task is preempted, the worker can be unlinked and freed by kfree_rcu() before the callback function is inspected. KASAN reports a slab-use-after-free read in this path. Save whether the callback belongs to an unpublished continuation worker while its reference is still held, then use the saved result for the conditional free. This preserves the existing accounting and frees only the worker allocated for the canceled continuation. Fixes: e6db6f9398da ("io_uring/io-wq: only free worker if it was allocated for creation") Cc: stable@vger.kernel.org Signed-off-by: Kyle Zeng Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1b7b31f0d4bbfb9a87dd8acce1e001a3cf1c1623 Author: Yousef Alhouseen Date: Mon Jun 29 17:29:47 2026 +0200 HID: hiddev: keep state alive through disconnect unlock commit 03f449b5de36a25fc5eba7dabf2b4494389bdb91 upstream. mutex_unlock() clears the mutex owner before taking its wait lock. A thread spinning in the final hiddev file release can acquire existancelock after hiddev_disconnect() clears the owner, then free hiddev before the disconnecting thread reaches the mutex wait lock. This causes a use-after-free in the mutex slow unlock path. Give the connection and each open file an explicit reference. Drop each reference only after its existancelock critical section has completed, so neither unlock path can free the mutex while the other is still using it. Fixes: 079034073faf ("HID: hiddev cleanup -- handle all error conditions properly") Reported-by: syzbot+563191a4939ddbfe73d4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4 Cc: stable@vger.kernel.org Signed-off-by: Yousef Alhouseen Link: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4 Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit e1b124226d55bc62b24b8f825b220d9b48b324bc Author: Richard Patel Date: Fri Oct 9 14:58:42 2026 +0000 genirq: Move interrupt thread exit_work object to irqaction commit 89a9e003a2ef73f67dff03dfd59e0a5474b56b0b upstream. irq_thread() registers irq_thread_dtor() as exit task_work using a stack-allocated callback_head. On normal interrupt thread exit, this work gets cancelled and never runs. On x86, an abnormal interrupt thread exit (e.g. handler oops) discards the stack, including the callback_head, while that callback_head is still pending. By the time exit_task_work() runs, the stack memory formerly backing callback_head is already clobbered. irq_thread() <-- on_exit_work allocated ** IRQ handler faults ** oops_end() rewind_stack_and_make_dead() <-- on_exit_work freed make_task_dead() do_exit(SIGSEGV) ... exit_shm() <-- on_exit_work clobbered ... exit_task_work() <-- stack use-after-free exit_shm()+0x30 <-- wild jump to return addr Thus, a benign threaded IRQ oops (e.g. a NULL pointer deref) is turned into a wild jump. This is caught by kernel IBT: ** first fault ** Oops: general protection fault, kernel NULL pointer dereference 0x3c0: 0000 [#1] SMP NOPTI ... ** second fault ** Missing ENDBR: exit_shm+0x30/0x1c0 kernel BUG at arch/x86/kernel/cet.c:133! ... ? task_work_run+0x5c/0x90 ? do_exit+0x209/0x460 ? rewind_stack_and_make_dead+0x16/0x20 ... note: irq/165-AudioDS[1427] exited with irqs disabled Fixing recursive fault but reboot is needed! Fix this by storing the callback_head in struct irqaction. The irqaction is only freed once irq_thread_dtor() finishes. Fixes: 2deb4be28077 ("x86/dumpstack: When OOPSing, rewind the stack before do_exit()") Signed-off-by: Richard Patel Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009145842.1616117-3-ripatel@wii.dev Signed-off-by: Greg Kroah-Hartman commit a6deaadd460a3a3cfd59c857247097e8da892af8 Author: Richard Patel Date: Fri Oct 9 14:58:41 2026 +0000 genirq: Defer kfree(irqaction) until irq_thread_dtor() finishes commit d04adff6860587e843948b0c31174f8ae11b8dfe upstream. When an interrupt thread exits abnormally via do_exit() (e.g. the interrupt handler oopses) without returning from irq_thread(), a concurrent call to free_irq() could free the irqaction before the irq_thread_dtor() exit task work runs. irq thread (oopsed) free_irq() ------------------- ---------- do_exit() exit_mm() complete_vfork_done() -------> kthread_stop() returns exit_files() ... kfree(action) exit_task_work() irq_thread_dtor() action->... <- use-after-free Track the pending exit work with the IRQTF_EXIT_WORK thread flag, and have __free_irq() wait for the bit to clear before kfree(). irq_thread_dtor() only runs on irq_thread abnormal exit. If that dtor also faults, free_irq() will hang indefinitely, but double IRQ thread faults require a reboot anyways. [ tglx: Add missing include ] Fixes: ed3e694d78cc ("move exit_task_work() past exit_files() et.al.") Signed-off-by: Richard Patel Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009145842.1616117-2-ripatel@wii.dev Signed-off-by: Greg Kroah-Hartman commit abc9c0f4f850d23e55f4230cd0f54938a64267bf Author: Ngoc Quy Date: Wed Oct 14 16:55:40 2026 +0700 fs/proc/task_mmu: pin mm_users in do_pagemap_scan() commit 4fb975471717c953f912776bb60301add1ffae11 upstream. The PAGEMAP_SCAN ioctl takes mmap_read_lock() on an mm obtained from /proc//pagemap without holding a reference to mm_users. proc_mem_open() deliberately grabs only mm_count, so a consumer that touches the address space has to call mmget_not_zero() first. Every other consumer in this file does -- m_start(), do_procmap_query(), show_smaps_rollup() and pagemap_read() -- but do_pagemap_scan() does not. Without that reference the target can reach exit_mmap() concurrently, and exit_mmap() calls unmap_vmas() while holding mmap_lock only for reading, which does not exclude the scanner. For ordinary VMAs this is harmless, as free_pgtables() and remove_vma() run afterwards under mmap_write_lock. A shared hugetlb VMA is different: __hugetlb_zap_end() frees the VMA's hugetlb_vma_lock inside the read-locked phase. walk_hugetlb_range() can therefore load vma->vm_private_data, have the lock freed underneath it, and then down_read() a freed rw_semaphore. The load happens before the freeing side clears the pointer, so this is a use-after-free and not a NULL dereference. Any unprivileged user can reach it with no huge pages configured, as hugetlb_reserve_pages() allocates the lock before the VM_NORESERVE early return. Pin mm_users across the scan, the way the other consumers do. mmput() from the exiting task can then no longer reach exit_mmap() while a walk is in progress. [akpm@linux-foundation.org: remove unneeded & undesirable test for !mm] Link: https://lore.kernel.org/20261014095540.3261469-1-ngocquy0700@gmail.com Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs") Signed-off-by: Ngoc Quy Signed-off-by: Andrew Morton Assisted-by: Claude:claude-opus-5 Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Muhammad Usama Anjum Cc: Signed-off-by: Greg Kroah-Hartman commit 1e13b8957510cfbc7367b3be1f08adc1757bb6d4 Author: Xiang Mei Date: Sat Sep 12 14:15:12 2026 -0700 fbdev: udlfb: don't rebuild the mode list while the framebuffer is in use commit ac9cfa552102b8e80e88c2872e80dc9cb5f07dda upstream. dlfb_setup_modes() frees info->modelist with fb_destroy_modelist() and rebuilds it, but fbcon holds raw pointers into that list in fb_display[i].mode and nothing un-publishes them the way do_unregister_framebuffer() and store_modes() do with fbcon_delete_modelist(). The function does refuse to install a new mode while the framebuffer has users (dlfb->fb_count != 0), but only after the list is already destroyed. Reached from the 0666 "edid" sysfs attribute, an unprivileged write to /sys/class/graphics/fb0/edid therefore fails with -EINVAL and still leaves every fb_display[i].mode dangling; the next console switch reads the freed fb_videomode in fb_videomode_to_var(). Test fb_count before touching the list. fbcon takes a reference through fbcon_open(), so that condition covers exactly the states in which fb_display[] points into the list, and the errno returned to userspace is unchanged. BUG: KASAN: slab-use-after-free in fb_videomode_to_var (drivers/video/fbdev/core/modedb.c:905) Read of size 4 at addr ffff8880107b449c by task kworker/1:1/47 Workqueue: events console_callback Call Trace: fb_videomode_to_var (drivers/video/fbdev/core/modedb.c:905) display_to_var (drivers/video/fbdev/core/fbcon.c:998) fbcon_switch (drivers/video/fbdev/core/fbcon.c:2182) redraw_screen (drivers/tty/vt/vt.c:994) complete_change_console (drivers/tty/vt/vt_ioctl.c:1141) console_callback (drivers/tty/vt/vt.c:3358) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) 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) ... The buggy address is located 28 bytes inside of freed 96-byte region [ffff8880107b4480, ffff8880107b44e0) Cc: stable@vger.kernel.org Fixes: 7d9485e2c53c ("Staging: udlfb: Add functions to expose sysfs metrics and controls") Reported-by: co+ed9902f2e44184d9@bugs.sh Closes: https://lore.kernel.org/all/1jSCSNaDKmuUG7h40rTsSl1rMaSwdlJef4rp%40bugs.sh/ Assisted-by: Claude:claude-opus-5 Signed-off-by: Xiang Mei Link: https://lore.kernel.org/all/1jSCSNaDKmuUG7h40rTsSl1rMaSwdlJef4rp%40bugs.sh/ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 3b0be34d9d1e7add0c9b99b0b4b969ca56d81066 Author: Yibo Tan Date: Tue Sep 15 22:45:28 2026 +0800 fbdev: atmel_lcdfb: Prevent FIFO work after removal commit 20b3b97cf89cb381bf07516090d99399cc9b91fd upstream. The LCD controller IRQ schedules sinfo->task to recover from a FIFO underflow. Probe currently requests the IRQ before initializing the work, so an early interrupt can schedule an uninitialized work item. The probe error path and remove path cancel the work before freeing the IRQ. A FIFO-underflow interrupt can schedule the work again after that cancellation. framebuffer_release() may then free sinfo while the work is still pending. KASAN reported a use-after-free in atmel_lcdfb_task() when an underflow interrupt occurred during removal. With the IRQ freed before the work was cancelled, the same test completed without a kernel diagnostic. Initialize the work before requesting the IRQ. In both cleanup paths, free the IRQ before cancelling the work so that it cannot be scheduled again after cancellation. Fixes: d22579b83735 ("atmel_lcdfb: FIFO underflow management") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Yibo Tan Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit aa0be226ff227b051205d05dcfd6d38c0200e5ae Author: Osama Abdelkader Date: Thu Oct 8 12:09:35 2026 +0200 drm/panthor: Fix TOCTOU race between GROUP_REGISTERED check and erase commit 7764289d76a38c3a2f9b093bf17e193ab54acd70 upstream. panthor_group_destroy() checks the GROUP_REGISTERED mark and then calls xa_erase() without holding the xarray lock across both. If the handle is destroyed by another thread in between, and a concurrent GROUP_CREATE reuses the freed ID, the first destroy erases and releases the new, still-initializing group, leading to a use-after-free in panthor_group_create(). Do the mark check and erase atomically under xa_lock(). Fixes: eec7e23d848d ("drm/panthor: Prevent potential UAF in group creation") Assisted-by: Claude:claude-opus-5.5 Reviewed-by: Boris Brezillon Reviewed-by: Liviu Dudau Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Steven Price Signed-off-by: Liviu Dudau Link: https://patch.msgid.link/20261008100935.3059587-1-osama.abdelkader@gmail.com Signed-off-by: Greg Kroah-Hartman commit d5cc1f1333d47593fcc71b73d1fade556c8ece76 Author: Bui Viet Dung Date: Thu Oct 8 11:54:13 2026 +0700 Bluetooth: hci_vhci: Pin module for debugfs file operations commit 645ee6b176c958579cff1c783413d5cff65c8197 upstream. An open debugfs file retains its file_operations pointer in the debugfs proxy state. However, force_suspend_fops, force_wakeup_fops, aosp_capable_fops, and force_devcoredump_fops have no .owner set to THIS_MODULE. As a result, full_proxy_open_regular() calls fops_get() which succeeds without taking a reference to the hci_vhci module. When userspace opens any of these debugfs files and later closes the /dev/vhci file descriptor (triggering vhci_release() and debugfs file removal), the open debugfs file descriptor remains valid in userspace. Because the module refcount was not incremented, the hci_vhci module can be unloaded via delete_module (rmmod hci_vhci). When the userspace process subsequently closes the debugfs file descriptor, full_proxy_release() accesses the already unmapped file_operations structure, resulting in a kernel page fault / oops: BUG: unable to handle page fault for address: fffffbfff846f18b #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:full_proxy_release+0x8e/0x140 Call Trace: __fput+0x39f/0xa60 fput_close_sync+0xff/0x200 __x64_sys_close+0x8c/0xf0 do_syscall_64+0xc3/0x590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Modules linked in: ... [last unloaded: hci_vhci(E)] The issue was discovered via manual code audit of drivers/bluetooth/hci_vhci.c and verified on a Linux 7.3-rc6 test VM with CONFIG_BT_VHCI=m by keeping a debugfs file open across controller teardown and module unload. Set .owner = THIS_MODULE on all four file_operations structures so that debugfs pins the module until all file descriptors are closed. Fixes: 28010791193a ("Bluetooth: vhci: Prevent use-after-free by removing debugfs files early") Cc: stable@vger.kernel.org Signed-off-by: Bui Viet Dung Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 2ff55599528d7712c46956c038665a4d5a5160e5 Author: Fan Wu Date: Tue Sep 29 06:13:49 2026 +0000 ASoC: amd: ps: fix snd_acp63_remove() teardown ordering commit c53791d673ed4da6759d276078627ec4d0c6536b upstream. The ACP IRQ handlers dereference the SoundWire, SoundWire DMA, and PDM child platform devices, but snd_acp63_remove() unregisters them while the interrupt is still held by devres, which frees it only after remove returns. An interrupt in this window is a use-after-free. Mask the ACP interrupt sources and call devm_free_irq() before the first child device is unregistered. The masking goes through the new acp_hw_ops->disable_interrupts callback, keeping the remove path platform-agnostic. The interrupt line is shared, and acp_hw_deinit() clears the sources only after the children are gone, which would leave the line raised with no handler left to ack it. The window predates the tagged refactor, which only reshaped the dereferences. devm_free_irq() waits for in-flight handlers, but not for work the hardirq has already queued: acp63_irq_handler() schedules amd_sdw_irq_thread on the SoundWire manager. Draining that work in the manager's remove path is a soundwire-side change and follows separately. This issue was found by an in-house static analysis tool. Fixes: eaf825037d6d ("ASoC: amd: ps: refactor acp child platform device creation code") Cc: stable@vger.kernel.org Co-developed-by: Song Li Signed-off-by: Song Li Signed-off-by: Fan Wu Reviewed-by: Vijendar Mukunda Link: https://patch.msgid.link/20260929061349.3879-1-fanwu01@zju.edu.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5cb07a5941b1e3dbe655110618869a81af68907e Author: Sung Byeongchan Date: Sat Oct 3 19:18:54 2026 +0900 ALSA: pcmtest: handle multiple wraps in random capture fill commit 6541871e8e63e721733cd120af4d9cd22c5ef62f upstream. The random capture helpers assume that the data generated for one timer tick wraps the DMA ring at most once. However, b_rw describes 200 ms of audio because the timer runs at 5 Hz, so it can be several times larger than a small ring. For 48 kHz, S16_LE, four-channel capture with a 512-frame buffer, the DMA ring is 4096 bytes while one tick generates 76800 bytes. After filling the 4096-byte tail, the existing code issues a second 72704-byte write from the ring base, writing 68608 bytes beyond the ring. Both interleaved and non-interleaved capture are affected. KASAN reports the first write into the adjacent free page as a use-after-free in the random-byte generator. The underlying defect is an out-of-bounds write from the live DMA ring, not a stale DMA allocation. Split each random write repeatedly at the interleaved ring or per-channel block boundary. Keep the hardware-pointer update exactly once after the complete logical write. The issue reproduced on three of three clean boots. With this change, the same vulnerable geometry completed six times without a sanitizer finding. Boundary, pattern-fill, no-timer, open/close, and module-reload controls also completed normally. snd-pcmtest is a test driver, and selecting random fill requires an administrator-controlled module parameter. The written values come from the kernel random generator; no privilege escalation or attacker-controlled write primitive was demonstrated. Fixes: 315a3d57c64c ("ALSA: Implement the new Virtual PCM Test Driver") Cc: stable@vger.kernel.org Assisted-by: OpenAI Codex Signed-off-by: Sung Byeongchan Link: https://patch.msgid.link/20261003101854.1423146-1-tjdqudcks0424@naver.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit af2b590be8feb62b5a0779dadd08e2ece5f370f2 Author: Takashi Iwai Date: Tue Oct 20 12:16:20 2026 +0200 ALSA: emux: Fix UAF of soundfont zones at note-on commit 34e3e04b8a1731a773797542f0781e99ce7cd755 upstream. snd_emux_note_on() looks up the matching zones via snd_soundfont_search_zone(), which takes sflist->lock only during the lookup and returns the raw zone pointers after releasing it. The caller then stores them in vp->zone without any protection. Meanwhile, a concurrent SNDRV_EMUX_IOCTL_REMOVE_LAST_SAMPLES ioctl may unlink and free those zones in snd_soundfont_remove_unlocked(); this leads to a use-after-free in snd_emux_note_on(), and later at accessing the cached vp->zone, e.g. in snd_emux_send_effect(). Fix it by holding sflist->lock in snd_emux_note_on() over the whole zone lookup and voice setup, and let snd_soundfont_search_zone() require the caller to hold the lock, instead. snd_soundfont_lock_preset() takes sflist->lock for setting presets_locked, so the removal path now syncs with the note-on finish. Reported-by: Sashiko Closes: https://sashiko.dev/#/bug/linux-697212bb-a434-4ff5-8778-25a84f5dad89 Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261020101624.205638-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 04d11c4db269e76ded488e650af9b70d523c6cee Author: Takashi Iwai Date: Tue Sep 29 14:53:42 2026 +0200 ALSA: control: Fix UAF in snd_ctl_elem_add() on card disconnect commit d4febca239be3c91498762dd0535a87d4af1eabc upstream. A use-after-free can be triggered via SNDRV_CTL_IOCTL_ELEM_ADD when a USB audio card is disconnected while an ELEM_ADD ioctl is in flight. The reproducer parks the ioctl thread inside copy_from_user() using userfaultfd, then tears down the USB device. Unlike every other ALSA control _user handler (ELEM_INFO, ELEM_READ, ELEM_WRITE, TLV_*), snd_ctl_elem_add_user() never calls snd_power_ref_and_wait(), so the parked thread holds no power reference. snd_card_disconnect() therefore cannot observe it via snd_power_sync_ref() and proceeds unimpeded: 1. card->shutdown is set to 1 2. device_del(&card->card_dev) drops the kobject reference on the parent USB interface device (card->dev = &intf->dev) 3. The USB core drops its own reference and calls device_release(), freeing the struct usb_interface, including the embedded struct device that card->dev points to When the userfaultfd is resolved and the thread resumes, snd_ctl_elem_add() acquires controls_rwsem without checking card->shutdown and calls __snd_ctl_add_replace(). Because the reproducer pre-registered the same control, the CTL_ADD_EXCLUSIVE path calls dev_err(card->dev, ...) on the freed USB interface: KASAN: slab-use-after-free Read in __dev_printk Add a card->shutdown guard immediately after acquiring controls_rwsem in snd_ctl_elem_add(). At that point card->shutdown is guaranteed to be stable: snd_card_disconnect() sets it before freeing the parent device, and it never transitions back to 0. A thread that acquired the lock before disconnect sees shutdown=0 and holds the write lock through the rest of the operation, preventing concurrent disconnect from proceeding past its own controls_rwsem-less shutdown=1 store (which happened earlier, outside the lock) from racing with dev_err(). Reported-by: Farhad Alemi Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260929125346.1478631-3-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit b33aedc99e3cd61d44d568c30951eb508ce9b021 Author: Frank Zhang Date: Fri Sep 4 15:56:35 2026 +0800 rust: rcpufreq_dt: add module alias commit 53732733c7af437b0ed710a1df91a67a0d3dfc07 upstream. Add the missing `platform:cpufreq-dt` module alias so that the driver can be automatically loaded when the platform device is registered. Fixes: 06149d8f2216 ("cpufreq: Add Rust-based cpufreq-dt driver") Cc: stable@vger.kernel.org Signed-off-by: Frank Zhang Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 822d6761cdea1aad6e92eefe00b9e74d54333ecf Author: Mehmet Koseoglu Date: Thu Oct 1 13:19:15 2026 +0300 rust: cpufreq: reject NULL from cpufreq_cpu_get() commit 02c5d7bfa8724789f6620f7787532666edc891a1 upstream. cpufreq_cpu_get() returns either a referenced policy or NULL. PolicyCpu::from_cpu() passed its return value to from_err_ptr(), which rejects ERR_PTR values but accepts NULL. If the lookup fails, Policy::from_raw_mut() therefore constructs a mutable reference from NULL. Dropping the resulting PolicyCpu then passes the invalid pointer to cpufreq_cpu_put(), causing an oops in kobject_put(). Reject NULL with NonNull before constructing the Policy reference. Return ENODEV instead. A KUnit negative-control run reproduced the oops with the original conversion. The same test passed with this change. The reproducer is available on request. Fixes: 6ebdd7c93177 ("rust: cpufreq: Extend abstractions for policy and driver ops") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Mehmet Koseoglu Reviewed-by: Onur Özkan Reviewed-by: spidermana Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit dc1744584b2b9cd8a04e1b824f72bfec0e3c3374 Author: Andreas Hindborg Date: Mon Jun 8 14:32:00 2026 +0200 rust: configfs: fix data offset calculation for subsystem callbacks commit e84c9b64df615e658e47561b835c1364dc48f0c0 upstream. `get_group_data()` chooses between `Group::::container_of()` and `Subsystem::::container_of()` based on whether `this` represents the root group of a configfs subsystem. It detects this by checking `(*this).cg_subsys.is_null()`, but `link_group()` in `fs/configfs/dir.c` unconditionally sets `cg_subsys` for every `config_group` attached anywhere in a registered subsystem, including the subsystem's own `su_group`. The only `config_group` with a NULL `cg_subsys` is the configfs root, on which userspace cannot trigger callbacks. The check is therefore always false at runtime, and the `Subsystem` branch is dead. Subsystem-level callbacks reach the `Group` branch and may read `data` at the wrong offset. Thus change the `is_root` check to correctly identify whether a group is a root group by comparing `this` to `subsys.su_group`. Cc: stable@vger.kernel.org Fixes: 446cafc295bf ("rust: configfs: introduce rust support for configfs") Link: https://msgid.link/20260608-configfs-fix-offset-v1-1-7f01b8fb9e5f@kernel.org [ Andreas: Fix clippy warning on 1.85.0 by moving safety comment. ] Signed-off-by: Andreas Hindborg Signed-off-by: Greg Kroah-Hartman commit c6112b0a1627f25fcb9ff40fa57c75aa73c4947a Author: Andreas Hindborg Date: Tue Sep 29 11:34:07 2026 +0200 rust: block: require `Sync` for `Operations::QueueData` commit 67b7a2728e4873e64405c5564fe50f7123012b71 upstream. The queue data installed in a `GenDisk` is stored in the request queue and handed back to the driver as a shared borrow through the `queue_rq` and `commit_rqs` callbacks. Both callbacks obtain that borrow via `ForeignOwnable::borrow` and may execute concurrently on several CPUs, since the block layer runs one hardware queue per CPU. That means a shared reference to the same queue data can be live on multiple threads at once, which is only sound when the referent is `Sync`. The initial `GenDisk` private data support omitted this bound, so a driver could install a non-`Sync` type as queue data and then access it concurrently from multiple CPUs without synchronization. Add a `Sync` bound to the `QueueData` associated type to rule that out. Fixes: 90d952fac8ac ("rust: block: add `GenDisk` private data support") Cc: stable@vger.kernel.org Reviewed-by: Alice Ryhl Reviewed-by: Gary Guo Link: https://msgid.link/20260608-queue-data-sync-v1-1-0efff051aaf3@kernel.org Signed-off-by: Andreas Hindborg Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-9-642a4c1aebd7@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 11c13964153dfe26b162e9906093573d06841c6e Author: Andreas Hindborg Date: Tue Sep 29 11:34:02 2026 +0200 rust: block: fix `Send` bound for `GenDisk` commit e502b667ee70a7fa2a578e7722672ecd4fe0eb81 upstream. The `Send` implementation for `GenDisk` was conditioned on `T: Send`. This constrains the wrong type. `T` is the `Operations` implementation, which is typically a zero-sized marker type that carries no data, so `T: Send` says nothing about whether the data a `GenDisk` actually owns can be moved to another thread. A `GenDisk` owns the queue data `T::QueueData` (stored as the `gendisk`'s `queuedata` and dropped when the `GenDisk` is dropped) and an `Arc>`. These are the values transferred when a `GenDisk` is sent across a thread boundary, so the `Send` bound must constrain exactly them. Bound `T::QueueData: Send` and `Arc>: Send` instead. Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Cc: stable@vger.kernel.org Reported-by: Priya Bala Govindasamy , Dylan Zueck , Yuan Tan Closes: https://lore.kernel.org/all/cover.1780633578.git.ytan089@ucr.edu Signed-off-by: Yuan Tan Link: https://msgid.link/20260709100100.604252-1-yuantan098@gmail.com [ Andreas: Fix tags to make checkpatch happy. Change summary line. ] Signed-off-by: Andreas Hindborg Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-4-642a4c1aebd7@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 964002cb55d9f091807ff2aa8dab9971e7bd6da0 Author: Eliot Courtney Date: Wed Sep 30 11:42:51 2026 +0900 rust: bitmap: restrict bitmap length to at most i32::MAX commit 931790a91378f6513ba82730eb5607479c3184a0 upstream. It is currently possible to construct a non-`BitmapVec` backed `Bitmap` using `Bitmap::from_raw` that is larger than `i32::MAX`, and it is not part of the unsafe requirements. Restricting all bitmaps (even non-`BitmapVec` backed ones) to a maximum size of `i32::MAX` simplifies a few things and matches `BitmapVec::MAX_LEN`. For example, `copy_and_extend` truncates `len` to u32, which is wrong for > u32::MAX size. `__bitmap_set` and `__bitmap_clear` need i32 for `size` and u32 for `start` - so they can't be run on a `Bitmap` with a > i32::MAX size. Rather than adding runtime checks to account for the case of a non `BitmapVec` backed `Bitmap`, just include that in the requirements for `Bitmap`. Add that requirement to the unsafe requirements on `Bitmap::from_raw` and `Bitmap::from_raw_mut`, and to the invariants on `Bitmap`. This also fixes u32 casts truncating in `copy_and_extend`, which could otherwise lead to OOB writes. Fixes: 11eca92a2cae ("rust: add bitmap API.") Link: https://lore.kernel.org/DKG0U8RLO7LZ.2I1AIH0S38PAP@nvidia.com Reviewed-by: Yury Norov Reviewed-by: Burak Emir Signed-off-by: Eliot Courtney Link: https://patch.msgid.link/20260930-chid-v9-2-0d6cca376cff@nvidia.com Cc: stable@vger.kernel.org [ Added a few intra-doc links. Added backticks to C types. Capitalize tagged comments. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit d2af35f84f51cb229c52680b552c538f09f7c123 Author: Miguel Ojeda Date: Sun Oct 18 15:13:13 2026 +0200 objtool/rust: add one more `noreturn` Rust function for Rust 1.101.0 commit 6b704ec9007a3f23ec5ded8f320825ac444f307d upstream. Starting with Rust 1.101.0 (expected 2026-12-24), `objtool` may report: rust/kernel.o: warning: objtool: _R..._4core6result13unwrap_failed...() falls through to next function _R..._4core6result13unwrap_failed...() (and others) due to calls to the `noreturn` symbol: core::result::unwrap_failed::unwrap_failed_inner Rust introduced this helper when making `unwrap_failed` generic [1]. The existing entry for `unwrap_failed` does not match the new helper. Thus add the mangled one to the list so that `objtool` knows it is actually `noreturn`. See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") for more details. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Josh Poimboeuf Cc: Peter Zijlstra Link: https://github.com/rust-lang/rust/pull/164059 [1] Assisted-by: LLM Link: https://patch.msgid.link/20261018131313.59391-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit d655ef174056457d1c3bc06b4405097e0a9b3bf5 Author: Karl Mehltretter Date: Thu Aug 27 06:17:08 2026 +0200 klist: avoid accesses after waking klist_remove() commit 732e3e10234cbe302d0dcbaa98c91c66628209cb upstream. klist_remove() waits until a node is unreferenced so that its caller can free the containing object. klist_release() currently publishes waiter->woken and wakes the waiter before its final accesses to the waiter and node. klist_remove() can then return, allowing its stack waiter and the containing object to be freed or reused while klist_release() is still running. In particular, bus_remove_driver() can free drv->p while __device_attach() walks the same bus klist with bus_for_each_drv(). On an arm64 Cortex-A72 system, an unpatched 7.2.0-rc3 kernel with CONFIG_PREEMPT_RT=y and CONFIG_KASAN=y reproduced the bug through the in-tree I2C/at24 path. KASAN reported a use-after-free in klist_dec_and_del() reached from klist_next()/bus_for_each_drv() while at24 was being unregistered. Clear n_klist and take a task reference before publishing woken. Use release/acquire accesses for that publication and wake the referenced task. The task reference keeps the waiter task alive if it returns and exits before wake_up_process(). Link: https://lore.kernel.org/20260827041708.31682-1-kmehltretter@gmail.com Fixes: 8b0c250be489 ("[PATCH] add klist_node_attached() to determine if a node is on a list or not.") Fixes: 210272a28465 ("driver core: Remove completion from struct klist_node") Signed-off-by: Karl Mehltretter Signed-off-by: Andrew Morton Assisted-by: LLM Cc: Danilo Krummrich Cc: Greg Kroah-Hartman Cc: Matthew Wilcox (Oracle) Cc: "Rafael J. Wysocki" Cc: Signed-off-by: Greg Kroah-Hartman commit 9250253c0ad52a985183d557d59c9cd96af223b2 Author: Ping Cheng Date: Wed Oct 7 15:00:27 2026 -0700 HID: wacom: Write shared touch initial status only once commit cae3031c691dff0be61a26bc64e31a6939010d5c upstream. For consistency with how the shared has_mute_touch_switch is handled during registration, let's apply WRITE_ONCE to is_touch_on too. Cc: stable@vger.kernel.org Fixes: ba16e5ffbaa1 ("HID: wacom: Advertise SW_MUTE_DEVICE capability prior to registration") Reviewed-by: Lee Jones Signed-off-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c93698167e8d04dc05f1f3a3e3186a58ab492496 Author: Ping Cheng Date: Wed Oct 7 15:03:35 2026 -0700 HID: wacom: Setup SW_MUTE_DEVICE according to the order of input registration commit 97ce491bcef2d231b8d51cee8e579183319a5ba4 upstream. The refactored SW_MUTE_DEVICE code assumed that stylus will be the first regiestered input. In reality, touch can be registered before stylus, such as the Wacom Cintiq Pro 13 and 16. This patch covers both touch-first and stylus-first cases. Cc: stable@vger.kernel.org Fixes: ba16e5ffbaa1 ("HID: wacom: Advertise SW_MUTE_DEVICE capability prior to registration") Reviewed-by: Lee Jones Signed-off-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 321da540c4a2091c0e23b5f4ced0131a1c77d679 Author: Lee Jones Date: Wed Sep 9 11:12:27 2026 +0000 HID: wacom: Redesign shared sibling data lifecycle commit 480c9cb14ae81f8e112ff83f8778b3d7b9324dc8 upstream. The Wacom driver coordinates state between sibling interfaces of the same physical device using a shared structure 'wacom_shared' inside 'wacom_hdev_data'. The driver kept a volatile representative pointer 'data->dev' pointing to a sibling 'hid_device' for physical path comparisons during sibling matching. This pointer management is fragile. When the representative device is disconnected, wacom_remove_shared_data() failed to clear/update 'data->dev', leading to a Use-After-Free vulnerability when subsequent sibling probes dereference the dangling 'data->dev' pointer. Resolve this issue by redesigning the sibling data lifecycle: - Eliminate the volatile 'data->dev' representative pointer completely - Redesign 'wacom_hdev_data' to store stable static copies of the required attributes upon first allocation: 'phys' path string, 'vendor', 'product' IDs and the sibling's 'device_type' - Use these static attributes for stable sibling matching in wacom_are_sibling() and wacom_get_hdev_data() This ensures sibling matching remains safe and stable even if individual siblings are dynamically added or removed. To secure the lifecycle against concurrent probe/disconnect races: - Switch kref_put() to kref_put_mutex() in wacom_remove_shared_data() to serialize refcount drops with list traversal and lookup - Modify wacom_release_shared_data() to assume the list lock is already held Also, do not accumulate the 'device_type' capability flag during subsequent sibling probes. Keeping only the first probed sibling's device_type exactly preserves the original sibling matching behavior without introducing side effects. Cc: stable@vger.kernel.org Fixes: 4492efffffeb ("Input: wacom - share pen info with touch of the same ID") Signed-off-by: Lee Jones Acked-by: Ping Cheng Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ac81120321a90b052cc50ecc9e38753c9471c75e Author: Lee Jones Date: Wed Sep 9 11:12:26 2026 +0000 HID: wacom: Fix Use-After-Free in wacom_bamboo_pad commit 3a523ecf9ac3fdd33f5eb31c43937ee44135395b upstream. wacom_bamboo_pad_pen_event() accesses wacom->shared->pen locklessly relative to wacom_remove_shared_data() which nullifies it. This can lead to a Use-After-Free if the sibling device is removed while events are being processed. Resolve this by introducing RCU protection for pen and touch pointers: - Annotate 'pen' and 'touch' in wacom_shared struct with __rcu. - Wrap lockless readers in wacom_bamboo_pad_pen_event() with rcu_read_lock() and rcu_dereference(). - Update writers in wacom_sys.c using rcu_assign_pointer(). - Use rcu_dereference_protected for comparisons under wacom_udev_list_lock. - Also use rcu_access_pointer in wacom_sibling_pending() and wacom_mode_change_work() to avoid warnings (while lockless access in the latter remains a pre-existing issue). Cc: stable@vger.kernel.org Fixes: 8c97a765467c ("HID: wacom: add full support of the Wacom Bamboo PAD") Signed-off-by: Lee Jones Acked-by: Ping Cheng Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ef74a8a685e272dbe0d21844c6e70841ccc9b1bc Author: Lee Jones Date: Wed Sep 9 11:12:25 2026 +0000 HID: wacom: Fix Use-After-Free in wacom_intuos_pad commit ef32877368a7013c060ef6bd03a30b6da2fe0c41 upstream. wacom_intuos_pad() accesses wacom->shared->touch_input locklessly inside the interrupt handler context. If the Touch sibling device is disconnected, wacom_remove_shared_data() clears 'touch_input' outside any lock, creating a Time-of-Check to Time-of-Use (TOCTOU) race condition where a preempted reader in interrupt context dereferences the freed pointer, leading to a Use-After-Free. Resolve this by introducing RCU protection for the touch_input pointer: - Annotate 'touch_input' in wacom_shared struct with __rcu - Wrap all lockless readers in wacom_wac.c with guard(rcu)() and rcu_dereference() using a unified wacom_report_touch_mute() helper - Update writers in wacom_sys.c using rcu_assign_pointer() - Call synchronize_rcu() in wacom_remove_shared_data() to ensure all active RCU readers have finished before the input device is freed Also wrap wacom_set_shared_values() and touch/pen assignments in wacom_add_shared_data() inside the wacom_udev_list_lock to serialize concurrent probe assignments, and verify that 'shared->touch == hdev' before setting touch_input to prevent concurrent sibling probe state desynchronization. Cc: stable@vger.kernel.org Fixes: 961794a00eab ("Input: wacom - add reporting of SW_MUTE_DEVICE events") Signed-off-by: Lee Jones Acked-by: Ping Cheng Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 1df501b62a2fa6bc24c74a8eefba61ffc1cf6bea Author: Lee Jones Date: Wed Sep 9 11:12:24 2026 +0000 HID: wacom: Advertise SW_MUTE_DEVICE capability prior to registration commit ba16e5ffbaa10fde960918d69af5e49f2b3fdd5e upstream. Input subsystem guidelines require that device capabilities are advertised before the input device is registered. The Wacom driver was violating this by advertising the SW_MUTE_DEVICE capability post-registration in wacom_set_shared_values() (and duplicating it in device-specific setup cases). Resolve this by moving the SW_MUTE_DEVICE capability setup to wacom_setup_touch_input_capabilities() for all touch devices that support it. For generic touch devices whose capabilities depend on mute switch usages parsed from a sibling Pen/Pad interface, defer registration with -EPROBE_DEFER until the sibling has parsed its descriptors and initialized shared capabilities. Cc: stable@vger.kernel.org Fixes: d2ec58aee8b1 ("HID: wacom: generic: support generic touch switch") Signed-off-by: Lee Jones Acked-by: Ping Cheng Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 24d9994e439fe02dca87d35b66e7fd29120f2558 Author: Lee Jones Date: Wed Sep 9 11:12:23 2026 +0000 HID: wacom: Use hdev->product in wacom_setup_touch_input_capabilities commit 86472508a7ef74b525e79a79d2d02d911a641d6b upstream. Replace the lookup-dependent 'wacom_wac->shared->touch->product' references with 'hdev->product' inside wacom_setup_touch_input_capabilities() since 'hdev' is already available (via container_of) and represents the touch device itself. Cc: stable@vger.kernel.org Signed-off-by: Lee Jones Acked-by: Ping Cheng Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit bd30e2b60e811140861d53030cf9b6226b46c032 Author: Harald Freudenberger Date: Tue Oct 6 17:46:03 2026 +0200 s390/zcrypt: Fix out-of-bounds ptr advance in cca_query_crypto_facility() commit 9fd7fca66735307fd7afa3450882a55ef80f2add upstream. The FQ reply parser code blindly advanced the walk pointer by a length value read directly from the hardware reply payload without checking that the advance stayed within the allocated reply buffer. A corrupt or malicious device response could push ptr beyond the cprbmem region, causing an out-of-bounds dereference or kernel memory exposure via the subsequent memcpy(). Fix this by tracking the remaining reply buffer space in a variable and validating each device-supplied length field against it before advancing or dereferencing the pointer. Fixes: 2004b57cde6b ("s390/zcrypt: code cleanup") Signed-off-by: Harald Freudenberger Cc: stable@vger.kernel.org Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 043da311673cd4d95dc9ad7a59ac83e8628ed049 Author: Heiko Carstens Date: Tue Oct 13 15:34:52 2026 +0200 s390/signal: Fix incorrect return address in signal frame commit adc9e872f7350e3ac29c1818d8c68b0760b4ba23 upstream. exit_to_user_mode_loop() can call arch_do_signal_or_restart() multiple times when signals are pending. If the first call set up a vDSO system call restart by saving the real user return address and adjusting psw.addr so it points to the vDSO stub, a second call builds the signal frame with the wrong return address. Restore psw.addr from arch_data, and set the return code to -EINTR before building the signal frame. This requires restart_block.arch_data to be properly initialized for all tasks. Move the initialization in copy_thread() in front of the kernel thread check, so that it also covers kernel threads and their children (PID 1, usermode helpers). Only PID 0 is left uninitialized, since it never returns to user space. Fixes: df29a7440c4b ("s390/signal: switch to using vdso for sigreturn and syscall restart") Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 0917637564e953daa79dd4f44fd86637816d2fc1 Author: Heiko Carstens Date: Mon Oct 12 10:36:27 2026 +0200 s390/probes: Fix wrong opcode for cgrb fixup commit d7ccab11a13475e656b9d2277900422c1bfc12c5 upstream. The last byte of the cgrb instruction is 0xe4, however the probes code compares against 0xe6. Fix it. Fixes: 6b169ac9b434 ("s390/kprobes: add support for compare and branch instructions") Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 3a4da934737159d2ec5341fb8c8a5c9a0c6efee2 Author: Heiko Carstens Date: Thu Oct 1 12:32:16 2026 +0200 s390/kprobes: Prevent kprobes on instructions with exception table entry commit fc9bb0ecd310b53af5116415952a1fb89d4660b9 upstream. The mvcos exception handler ex_handler_ua_mvcos() decodes the faulting instruction, assuming it is an mvcos instruction. In case the instruction is kprobed the decoded instruction is a breakpoint instruction instead, which leads to incorrect instruction decoding and potential register corruption. Fix this by simply preventing to set a kprobe on such instructions, similar like arm64 is doing it. Fixes: c488f5187a24 ("s390/uaccess: Shorten raw_copy_from_user() / raw_copy_to_user() inline assemblies") Cc: stable@vger.kernel.org Reviewed-by: Ilya Leoshkevich Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 333a1435802c54e7d0ebdb9908e59e7ab7bade1e Author: Heiko Carstens Date: Fri Oct 2 12:27:50 2026 +0200 s390/extable: Fix mvcos instruction decoding commit 4044466ff004c7ad5fd47be717cd933077e6e874 upstream. If either the b1 or b2 field of the mvcos instruction is zero, register zero is not used for address computation; zero is used instead, according to the architecture. ex_handler_ua_mvcos() incorrectly uses the real contents of register zero. Fix this. This shouldn't be a problem for any generated code, since the compiler would only generate such code if it is possible to prove at compile time that either the source or destination address is within the first 4kb of the designated address space. Such code should not exist (also confirmed by an allyesconfig build and decoding all ~7000 mvcos instructions). Fixes: c488f5187a24 ("s390/uaccess: Shorten raw_copy_from_user() / raw_copy_to_user() inline assemblies") Cc: stable@vger.kernel.org Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit ca06a46b6289ef395b5da46793a9ea7b2fd584f1 Author: Sumanth Korikkar Date: Tue Oct 6 13:13:03 2026 +0200 s390/cpum_cf: Check session mask before cpu offline commit 99a95985dfc85eecad97f0991a2401d2fcef294c upstream. cfset_offline_cpu() stops counter sets for every active session without checking whether the outgoing cpu belongs to the session mask. For example, run an hwctr session on cpu0 and a cpu bound perf event on cpu1: lshwc -l 9999 -i 5 0:b perf stat -C 1 -e cpum_cf/CPU_CYCLES/ sleep 120 chcpu -d 1 chcpu -e 1 Although the hwctr session does not include cpu1, cfset_offline_cpu() decrements its counter set reference count. The subsequent perf teardown decrements it again, causing it to underflow. The perf event keeps the percpu state alive across hotplug. When cpu1 comes online, the hwctr session is started there and the reference count moves from -1 to 0. Stopping the hwctr session then decrements it to -1 again, so the zero triggered counter set disable path is skipped. Check the session mask before stopping counter sets on the outgoing cpu. This prevents the unmatched decrement and the resulting reference count underflow. Fixes: a029a4eab39e ("s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility") Reported-by: Christian Borntraeger Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Sumanth Korikkar Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 3bcce6db59400fb643348179cd1f2a22a274b0e5 Author: Wentao Liang Date: Wed Sep 16 17:55:48 2026 +0000 drm/msm: Fix vm_bo use-after-free in with_vm_locks() commit 81878aa1a2f551f51a3d3aef2a9509503ec34d8b upstream. The unwind loop drops the vm_bo reference taken while locking before advancing to the next entry. drm_gpuvm_bo_put() may drop the last reference, removing and freeing the vm_bo, after which the plain list iterator dereferences freed memory to advance. Use the safe iterator, which saves the next entry before the body runs. Fixes: fe4952b5f27cca5d ("drm/msm: Convert vm locking") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Patchwork: https://patchwork.freedesktop.org/patch/754331/ Message-ID: <20260916175548.2089821-1-vulab@iscas.ac.cn> Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit 59eac6863eede5957bfd8872633608431ac42d3c Author: Niklas Cassel Date: Tue Sep 15 10:41:29 2026 +0200 ata: sata_fsl: Fix use-after-free of host_priv on probe() failure commit 70b1196740d61aabda13b2ad0e9c1dfa2ef9cfa3 upstream. sata_fsl_host_stop() releases hcr_base and host_priv: static void sata_fsl_host_stop(struct ata_host *host) { struct sata_fsl_host_priv *host_priv = host->private_data; iounmap(host_priv->hcr_base); kfree(host_priv); } ->host_stop() is called by the driver core through the ata_host_stop() devres action which ata_host_start() registers, so it is called both when the device is unbound and when probe() fails after the host has been started. The error_exit_with_cleanup label of sata_fsl_probe() releases hcr_base and host_priv as well, and it is reachable from the two device_create_file() calls which are done after the host has been activated. In that case sata_fsl_host_stop() runs on an already freed host_priv, resulting in a use-after-free and a double iounmap()/kfree(). Add a separate error label for the failures happening after the host has been activated, which only detaches the host and leaves hcr_base and host_priv to sata_fsl_host_stop(). Note that ata_host_detach() is dropped from error_exit_with_cleanup, as that label is now only reachable while host is still NULL. Fixes: 6c8ad7e8cf29 ("sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20260915084127.692494-11-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit fd0dd0ee82ef62b8b4bda1ffceb361946f403404 Author: Wentao Liang Date: Thu Sep 17 16:58:51 2026 +0000 ASoC: audio-graph-card2: Fix use-after-free in audio_graph2_link_c2c() commit 5ea495bccfd746b063bc6702064f167467717b41 upstream. of_graph_get_next_port() consumes the reference of its prev argument. port0 is only borrowed from the caller's iterator, so the call drops a reference the function does not own, and port0 is dereferenced again afterwards. Pass an extra reference, as graph_count_c2c() does, so the reference the callee consumes is the one taken here. Fixes: 5f281c3e82b1 ("ASoC: audio-graph-card2: use __free(device_node) for device node") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Acked-by: Kuninori Morimoto Link: https://patch.msgid.link/20260917165851.2163548-1-vulab@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 174b4b90ec6731934cf84eb267a86ad7152267fa Author: Binbin Deng <18983559317@163.com> Date: Wed Sep 23 13:46:23 2026 +0800 apparmor: fix a use-after-free in aa_lookupn_ns() commit f292873ceb4bd3a1a0f75f884361cd556e457692 upstream. aa_lookupn_ns() takes a reference on the namespace it finds with aa_get_ns(), which is kref_get() on the reference count that the namespace is released through, without checking whether the namespace is still in use. A concurrent removal of a ":"-prefixed namespace looks the same namespace up and only then takes the parent lock to remove it, so the last reference can be dropped between the lookup and the aa_get_ns() call: the reference count then reports the increment on a zero count and the kernel classifies the following use of the object as a use-after-free. A user with CAP_MAC_ADMIN can trigger this by writing a ":" removal and a ":/" removal to /sys/kernel/security/apparmor/.remove concurrently. refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0xc0/0xe0, CPU#6 Call Trace: aa_lookupn_ns+0xa9/0xc0 aa_remove_profiles+0x4fb/0x730 ? __kvmalloc_node_noprof+0x219/0x5c0 ? __pfx_aa_remove_profiles+0x10/0x10 ? aa_loaddata_alloc+0x65/0x1f0 ? _copy_from_user+0x2d/0x80 ? aa_loaddata_alloc+0x111/0x1f0 profile_remove+0x2ee/0x4a0 vfs_write+0x21e/0xcf0 ? rcu_core+0x29c/0x1740 ? timerqueue_linked_add+0x1f4/0x3d0 ? __pfx_vfs_write+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? __pfx_rcu_core+0x10/0x10 ? __pfx_hrtimer_update_next_event+0x10/0x10 ? mutex_unlock+0x7b/0xd0 ? fdget_pos+0x24d/0x4b0 ksys_write+0xf7/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? restore_fpregs_from_fpstate+0x37/0xc0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix by rejecting a namespace whose reference count is zero. Fixes: 3664268f19ea0 ("apparmor: add namespace lookup fns()") Cc: stable@vger.kernel.org Signed-off-by: Binbin Deng <18983559317@163.com> Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 1108d9a51c91bb459fa62506fd0176dc9e0927c5 Author: Josef Bacik Date: Thu Oct 15 18:07:08 2026 +0200 mm/hugetlb: fix use-after-free of a new anon folio commit 824cc56bf43c714319992bad3558803cac6e77c0 upstream. For a fault in a private mapping with nothing in the page cache, hugetlb_no_page() allocates a folio, locks it and maps it. The folio has one reference, which belongs to the page table entry from then on. After dropping the page table lock the function still sets the migratable flag of the folio and unlocks it. Whoever zaps the entry in between frees the folio. The fault holds the fault mutex and the lock of the vma. MADV_DONTNEED and the first unmap of a hole punch, hugetlb_vmdelete_list(), do not take the fault mutex, and a private vma only has a lock if it owns a reservation map: not with MAP_NORESERVE, and not in the child after fork(). Then the flag is set in, and folio_unlock() is called on, a folio that is free or has a new owner. A surplus page goes back to the page allocator while it is locked: BUG: Bad page state in process init pfn:108e00 flags: 0x200000000000059(locked|uptodate|dirty|head|node=0|zone=2) page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set A page of the pool can be given to the next user, of any file, who locks it and loses the lock to the late folio_unlock(): kernel BUG at mm/filemap.c:1532! hugetlb_no_page+0x111b/0x23e0 hugetlb_fault+0x3a9/0x14a0 An unprivileged process is enough: threads that write to a MAP_PRIVATE | MAP_NORESERVE hugetlb mapping, threads that call MADV_DONTNEED on it, and one that takes the freed pages for another file. Until commit 3a47c54f09c4 ("hugetlbfs: revert use i_mmap_rwsem for more pmd sharing synchronization") the fault held i_mmap_rwsem for reading, which everybody who zaps takes for writing. The lock that commit bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private VMAs") gave to private vmas closed the window again, but only for those with a reservation map. Be done with the folio before the page table lock is dropped, as hugetlb_wp() is with its copy. The function already unlocks page cache folios under that lock. Original fix generated by an LLM and sent in private by Josef. [david@kernel.org: simplify+move comment] Link: https://lore.kernel.org/20261015-urgent_fixes-v1-2-42796911043b@kernel.org Fixes: 3a47c54f09c4 ("hugetlbfs: revert use i_mmap_rwsem for more pmd sharing synchronization") Signed-off-by: Josef Bacik Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: Muchun Song Reviewed-by: Lance Yang Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Oscar Salvador Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Adam Litke Cc: Mel Gorman Cc: Rik van Riel Cc: Peter Xu Cc: Kiryl Shutsemau Cc: Mike Rapoport Cc: Signed-off-by: Greg Kroah-Hartman commit 8b87fd23be5a816ad572e23eb4e1e2bea027db6c Author: David Hildenbrand (Arm) Date: Thu Oct 15 18:07:09 2026 +0200 mm/hugetlb: fix use-after-free in hugetlb_mfill_atomic_pte() commit d8a9cd7fd2fb01211430c933932da58839b8ca65 upstream. Let's fix another instance where we use a folio after dropping the PTL, where someone else could e.g., MADV_DONTNEED it once we drop the PTL, making us trigger a use-after-free on the folio. Link: https://lore.kernel.org/20261015-urgent_fixes-v1-3-42796911043b@kernel.org Fixes: cb6acd01e2e4 ("hugetlbfs: fix races and page leaks during migration") Fixes: 1c9e8def43a3 ("userfaultfd: hugetlbfs: add UFFDIO_COPY support for shared mappings") Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Reported-by: Lorenzo Stoakes (ARM) Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: Muchun Song Reviewed-by: Lance Yang Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Oscar Salvador Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Adam Litke Cc: Mel Gorman Cc: Rik van Riel Cc: Peter Xu Cc: Kiryl Shutsemau Cc: Mike Rapoport Cc: Josef Bacik Cc: Signed-off-by: Greg Kroah-Hartman commit c33165bb785cb0b496a196a5ca50b9d725bb7f82 Author: Deepanshu Kartikey Date: Wed Sep 30 14:05:51 2026 +0530 media: imon: fix use-after-free in display_close via dev_dbg commit 118a3590a4080c71c565265b05b3f92e814d7647 upstream. ictx->dev is a raw pointer to the usb_interface's embedded device. On disconnect, usb_disconnect() can drop the last reference on the interface and free it while a userspace fd for /dev/lcd0 is still open. When that fd is later closed, display_close() dereferences the now-freed ictx->dev via dev_dbg(), causing a use-after-free. Remove the dev_dbg() calls that dereference ictx->dev in display_close() and free_imon_context(), rather than taking a reference on the device. Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver") Cc: stable@vger.kernel.org Reported-by: syzbot+9bfac891bdd42eb708fc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9bfac891bdd42eb708fc Link: https://lore.kernel.org/all/20260918054851.26083-1-kartikey406@gmail.com/T/ [v1] Link: https://lore.kernel.org/all/20260928121230.35359-1-kartikey406@gmail.com/T/ [v2] Signed-off-by: Deepanshu Kartikey Signed-off-by: Sean Young Signed-off-by: Greg Kroah-Hartman commit e9deece85062873763dfbb8b1121e722ef2959a0 Author: Anuj Bolewar Date: Tue Aug 4 10:18:21 2026 +0530 media: hackrf: fix use-after-free in hackrf_alloc_urbs() error path commit 6802ad4b6b267dda02209b5811edac7825c8a5f6 upstream. hackrf_alloc_urbs() frees the URBs it allocated so far when one allocation fails, but leaves the entries in dev->urb_list[] and dev->urbs_initialized untouched. The caller, hackrf_start_streaming(), then calls hackrf_free_urbs() on the error path, which walks dev->urbs_initialized entries and calls usb_free_urb() a second time on the already-freed URBs, causing a use-after-free (slab-use-after-free Write in usb_free_urb()). Drop the redundant cleanup loop inside hackrf_alloc_urbs() and let hackrf_free_urbs(), which the caller already invokes on error, own the cleanup of the successfully allocated URBs. Reported-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=832ce9fa3face1b7d44d Fixes: 969ec1f6bd92 ("[media] hackrf: HackRF SDR driver") Cc: stable@vger.kernel.org Signed-off-by: Anuj Bolewar Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2344922abe2ad811003794092931bf454b556109 Author: Pei Xiao Date: Tue Aug 4 14:47:01 2026 +0800 media: cx23885: Fix use-after-free in cx23885_finidev due to race condition commit 75016a992d9b03f5cc6df1414d1da35840d4feeb upstream. In cx23885_v4l2_dev_notify_init, &dev->cx25840_work is bound with cx23885_av_work_handler, and &dev->ir_rx_work and &dev->ir_tx_work are bound with cx23885_ir_rx_work_handler and cx23885_ir_tx_work_handler. cx23885_irq can schedule these works on system_wq when an AV_CORE interrupt is received, and the IR subdevice can also schedule the IR works from its interrupt service routine via the v4l2_device notify callback. If we remove the device, cx23885_finidev makes cleanup and the memory allocated for dev is released by kfree(dev), while the works mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cx23885_irq | schedule_work(&dev->cx25840_work) cx23885_finidev | cx23885_input_fini(dev) | cx23885_ir_fini(dev) | cx23885_shutdown(dev) | free_irq(pci_dev->irq, dev) | pci_disable_device(pci_dev) | cx23885_dev_unregister(dev) | v4l2_device_unregister(v4l2_dev) | kfree(dev) | // dev is freed | | cx23885_av_work_handler | // use dev (use-after-free) Fix it by canceling the works after the IRQ handler that can schedule them has been stopped, and before proceeding with the remaining cleanup in cx23885_finidev. Note that the flush_work() calls in cx23885_input_ir_stop() do not close this race: they only wait for works that are already queued or running at that moment, they do not prevent the IRQ handler, which is still registered at that point, from scheduling the works again afterwards, and they are skipped entirely when dev->sd_ir is NULL. The cancel_work_sync() calls are therefore placed after free_irq(), the only point at which no new work can be scheduled. Fixes: e5514f104d87 ("V4L/DVB: cx23885: Move AV Core irq handling to a work handler") Cc: stable@vger.kernel.org Assisted-by: Codex:deepseek-v4-flash Signed-off-by: Pei Xiao Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 95a1f45a82e51ff23bd82c0529bfd817c8ec437f Author: Fan Wu Date: Mon Aug 10 05:51:28 2026 +0000 media: au0828: fix use-after-free in bulk_timeout timer on disconnect commit 521030837bee352515d5ea57cc6a29581db3506e upstream. start_urb_transfer() arms dev->bulk_timeout, whose callback au0828_bulk_timeout() queues dev->restart_streaming; that work in turn calls start_urb_transfer() and re-arms the timer. au0828_dvb_unregister() cancels restart_streaming on disconnect but does not sync bulk_timeout. au0828_usb_release() then frees dev with kfree(), so a timer still armed or pending at that point can fire after the free and dereference dev through timer_container_of(). Sync the timer with timer_shutdown_sync() before cancel_work_sync(). The timer callback queues the work, so the timer must be stopped first; the shutdown variant is needed because the work re-arms the timer through start_urb_transfer(). The dvb->frontend == NULL early return guards the register-failure path where the timer was never set up. This bug was found by static analysis. Fixes: 53460c53b761 ("[media] au0828: Add timer to restart TS stream if no data arrives on bulk endpoint") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 70825b251e5f7855fd7bd93afc0b698154e00e70 Author: Chuck Lever Date: Sat Aug 22 21:40:15 2026 -0400 lockd: Fix use-after-free in nlmsvc_retry_blocked commit f5b7634f0f213299a07b461fb10385c8639a4ab8 upstream. nlmsvc_retry_blocked() examines the block at the head of nlm_blocked under nlm_blocked_lock, then releases the lock before calling nlmsvc_grant_blocked() or retry_deferred_block(). The nlm_blocked list reference is all that keeps the block alive across that window. nlmsvc_grant_blocked() does take one of its own, but not until after the lock has been dropped. Unmounting the nfsd filesystem while a lock request is still blocked reaches nlmsvc_traverse_blocks(), which drops the list reference and frees the block along with the nlm_rqst hanging off it. BUG: KASAN: slab-use-after-free in nlm_async_call+0xd6/0x230 Read of size 8 at addr ffff88811b04c808 by task lockd/8377 nlm_async_call+0xd6/0x230 nlmsvc_retry_blocked+0x61c/0x800 lockd+0x144/0x1c0 Freed by task 8392: nlmsvc_release_block+0x231/0x290 nlmsvc_traverse_blocks+0x139/0x1b0 nlm_traverse_files+0x1aa/0xa00 nlmsvc_free_host_resources+0x12/0x60 nlm_shutdown_hosts_net+0x127/0x280 lockd_down+0xd5/0x1c0 Take a reference before releasing nlm_blocked_lock and drop it once the retry has run. Fixes: 0e4ac9d93515 ("lockd: handle fl_grant callbacks") Cc: stable@vger.kernel.org Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/linux-nfs/20260818235808.3458075-1-shuangpeng.kernel@gmail.com/ Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260822-lockd-retry-blocked-uaf-v3-1-761661eae60c@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 2b61008c9f884ead174a67f1cc70342a9efee3e4 Author: Günther Noack Date: Tue Oct 6 12:58:47 2026 +0200 landlock: Fix superblock use-after-free in release_inode() commit 3e271a27c46fd591d1011c7de5a644a41e2010f1 upstream. Without this fix, release_inode() (task 1) can race with a umount operation in hook_sb_delete() (task 2). The order of operations in which the race occurs is: * task 2: hook_sb_delete() arrives at the end of the function, waiting for landlock_superblock(sb)->inode_refs to become zero. * task 1: release_inode(): does atomic_long_dec_and_test(), decrementing inode_refs to zero. * task 2: gets woken up through some other means, sees that inode_refs is zero and returns. The caller is the unmount operation and proceeds to release the superblock. * task 1: Runs wake_up_var(&landlock_superblock(sb)->inode_refs), *dereferencing the sb_security on the freed-up superblock*. Notably, wake_up_var() does not dereference the pointer passed to it, and only uses it to determine an overapproximated set of tasks to wake up. So while it's potentially possible for an attacker to provide a different value for that pointer, this only results in the wrong set of tasks getting woken up, and in this scenario, no further tasks are actually waiting. Nevertheless, KASAN detects it as a slab-use-after-free read on sb->s_security: BUG: KASAN: slab-use-after-free in release_inode+0x196/0x290 Read of size 8 at addr ffff888103b6c0a8 by task repro/217 release_inode+0x196/0x290 landlock_put_object+0x71/0x90 landlock_free_rules+0x38/0xc0 landlock_put_ruleset+0x47/0x130 fop_ruleset_release+0x33/0x40 __fput+0x305/0x780 Freed by task 54: kfree+0x11c/0x390 process_scheduled_works+0x766/0xe50 worker_thread+0x7bc/0xb20 The fix is to determine &landlock_superblock(inode->i_sb)->inode_refs only once earlier in release_inode(), and later use that precalculated address for the wake_up_var() call, without having to dereference through the superblock. Cc: stable@vger.kernel.org Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control") Assisted-by: LLM Signed-off-by: Günther Noack Link: https://patch.msgid.link/20261006105847.2541190-1-gnoack@google.com Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 439c23b897c8787f2d0c292ba9c1a2ee75595c0d Author: Nirmoy Das Date: Wed Oct 14 06:36:32 2026 -0700 iommufd: Fix event queue release use-after-free commit 440ca8a4b69f40088065b9e05ef11373292a254e upstream. iommufd_eventq_fops_release() drops the file's users reference before reading eventq->ictx. Once that reference is dropped, IOMMU_DESTROY in another thread can remove and free the event queue, so the later load accesses freed memory. Read ictx while the users reference still pins the event queue, then drop the reference and put the saved context. The context reference taken by iommufd_eventq_init() keeps ictx valid until the put. Fault and vEVENTQ file descriptors share this release path. Fixes: 07838f7fd529 ("iommufd: Add iommufd fault object") Cc: stable@vger.kernel.org Assisted-by: LLM, Specula Signed-off-by: Nirmoy Das Link: https://patch.msgid.link/20261014133632.3440297-1-nirmoyd@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 6324f087caf817f00840baa82664dec3c5634f1c Author: Yehyeong Lee Date: Sun Oct 18 00:38:05 2026 +0900 nvmet-fc: fix use-after-free in nvmet_fc_ls_create_connection() commit 2c29f8c9b9e598c09fa50aa02200136a107f6b3f upstream. nvmet_fc_ls_create_connection() looks up the association with nvmet_fc_find_target_assoc(), which returns it with a reference held, and drops that reference as soon as the target queue has been allocated. iod->assoc is then dereferenced again by nvmet_fc_makeconnid() while building the connection id. The queue only borrows the pointer and takes no reference of its own. Once the lookup reference is dropped the association is kept alive solely by the reference taken when it was created, so a disconnect LS or a remote port unregister running concurrently can free it before nvmet_fc_makeconnid() reads it: BUG: KASAN: slab-use-after-free in nvmet_fc_handle_ls_rqst_work (drivers/nvme/target/fc.c:193 drivers/nvme/target/fc.c:1841 drivers/nvme/target/fc.c:1995 drivers/nvme/target/fc.c:2021) Read of size 8 at addr ffff888179f1b000 by task kworker/u9:2/1167 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: nvmet-wq nvmet_fc_handle_ls_rqst_work 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) nvmet_fc_handle_ls_rqst_work (drivers/nvme/target/fc.c:193 drivers/nvme/target/fc.c:1841 drivers/nvme/target/fc.c:1995 drivers/nvme/target/fc.c:2021) process_scheduled_works (kernel/workqueue.c:3322 kernel/workqueue.c:3405) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (archkernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Freed by task 1167 on cpu 0 at 405.998150s: kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (include/linux/kasan.h:235 mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) nvmet_fc_handle_ls_rqst_work (drivers/nvme/target/fc.c:1808 drivers/nvme/target/fc.c:1995 drivers/nvme/target/fc.c:2021) process_scheduled_works (kernel/workqueue.c:3322 kernel/workqueue.c:3405) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (archkernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address belongs to the object at ffff888179f1b000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 0 bytes inside of freed 2048-byte region [ffff888179f1b000, ffff888179f1b800) Hold the lookup reference until the response has been built, and drop it on the error path as well. Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/linux-nvme/20260731204504.2396434-1-shuangpeng.kernel@gmail.com Fixes: c53432030d86 ("nvme-fabrics: Add target support for FC transport") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit 506c066da8fb2cef32210ca84439c7bb9855504f Author: Daejun Park Date: Fri Oct 2 16:02:00 2026 +0900 nvmet: fix use-after-free of the old registrant in nvmet_pr_preempt() commit f316aa7f018840523939183425394931b373e4d7 upstream. nvmet_pr_preempt() handles a preempt sent by the reservation holder by changing the reservation type with nvmet_pr_update_reg_attr(), unless the reservation is of an All Registrants type. For the holder that helper does not modify the registrant in place: it puts a copy on the registrant list, points pr->holder to the copy and passes the old registrant to kfree_rcu(). If the reservation type changed, nvmet_pr_preempt() then hands ®->hostid of that old registrant to nvmet_pr_resv_released(). Unless the reservation released notification is masked, that function takes subsys->lock and compares the host id against every controller of the subsystem. The caller only holds pr->pr_sem and is not in an RCU read-side critical section, so nothing keeps the old registrant alive while it is read. The result is a read of 16 freed bytes that decides which controllers get the notification. Found by code inspection. kfree_rcu() defers the free, so it usually happens after the read; when the pending free is forced to run before the read, KASAN reports the host id as freed memory. Pass the host id of the controller that sent the command instead. The registrant was looked up by that host id, and the controller outlives the request. Fixes: 5a47c2080a73 ("nvmet: support reservation feature") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Daejun Park Signed-off-by: Keith Busch Signed-off-by: Greg Kroah-Hartman commit ff2c27583cf9f4e009e30ca27b04f69bbc9b9674 Author: Mario Limonciello Date: Mon Sep 21 12:04:09 2026 -0500 platform/x86/amd: hfi: Fix a use-after-free when unloading the driver commit 55d8406dfa2fa8ad8ac2f053c2a53a97d8b0ce48 upstream. amd_hfi_probe() registers CPU hotplug callbacks with cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, ...) and schedules the static sched_amd_hfi_itmt_work work item, but amd_hfi_remove() tears down neither. The dynamically assigned hotplug state returned by cpuhp_setup_state() is discarded, so cpuhp_remove_state() can never be called, and the pending work is never cancelled. After the module is unloaded and its memory is freed, any subsequent CPU hotplug event or execution of the scheduled work dereferences the stale callback and work function pointers, resulting in a use-after-free and kernel panic. Store the hotplug state returned by cpuhp_setup_state() and, on removal, call cpuhp_remove_state() to unregister the callbacks and cancel_work_sync() to flush the scheduled work before the module memory goes away. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: bb20421c05fc ("platform/x86: hfi: Add online and offline callback support") Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260921170411.1149960-2-mario.limonciello@amd.com Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 48157350b24ac0343374ee3fa34188d7ff30be81 Author: James Kim Date: Mon Sep 14 13:23:27 2026 +0900 rapidio: mport_cdev: fix use-after-free in mport_mm_close() commit 0f2cd84858e67cf8e02438bf28243bcdc67aa49a upstream. A use-after-free vulnerability was identified in mport_mm_close() in drivers/rapidio/devices/rio_mport_cdev.c, identical to the pattern previously addressed in dma_req_free(). This is observable from userspace when an application creates an mmap mapping via the RapidIO character device and subsequently unmaps it (or terminates, triggering exit_mmap()). During munmap, mport_mm_close() is invoked and drops the mapping reference via kref_put(). If kref_put() drops the last reference, mport_release_mapping() is called, which frees the underlying rio_mport_mapping structure. The subsequent mutex_unlock() then dereferences map->md to unlock buf_mutex, leading to a use-after-free: mport_mm_close() -> mutex_lock(&map->md->buf_mutex); ... -> kref_put(&map->ref, mport_release_mapping); /* map is freed */ -> mutex_unlock(&map->md->buf_mutex); /* UAF: map used */ Fix this by caching map->md before kref_put() and using the cached pointer for mutex unlocking, ensuring that freed memory is not accessed. Link: https://lore.kernel.org/20260914042327.49798-1-james010kim@gmail.com Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: James Kim Signed-off-by: Andrew Morton Cc: Alexandre Bounine Cc: Dan Carpenter Cc: Greg Kroah-Hartman Cc: Matt Porter Cc: Signed-off-by: Greg Kroah-Hartman commit e5388f15d595dd4d7599a43e9cb58c0656a6aec6 Author: Guangshuo Li Date: Mon Sep 14 20:28:40 2026 +0800 RDMA/irdma: avoid use-after-free in icrdma_remove commit 8a8088b899e4cdfe558428cd6113d45df81625be upstream. icrdma_remove() dereferences iwdev after calling irdma_ib_unregister_device(): irdma_ib_unregister_device(iwdev) -> ib_unregister_device(&iwdev->ibdev) -> __ib_unregister_device() -> ib_dealloc_device() irdma registers irdma_ib_dealloc_device() as the dealloc_driver callback in its ib_device_ops. The RDMA core explicitly documents ib_unregister_device() that when ops.dealloc_driver is used, ib_dev will be freed upon return from the function. The ib_device is embedded in struct irdma_device and iwdev itself was allocated by ib_alloc_device(irdma_device, ibdev). Consequently, once irdma_ib_unregister_device() returns, iwdev must no longer be dereferenced. However, icrdma_remove() currently accesses iwdev->rf afterwards when deinitializing interrupts, destroying ah_tbl_lock, and freeing rf. Although the final ib_device storage is released with kfree_rcu(), the object lifetime has already ended and callers must not rely on the RCU grace period to continue dereferencing iwdev. Save iwdev->rf before unregistering the RDMA device and use the saved pointer for the remaining cleanup. This issue was found by manual code inspection. Fixes: 8498a30e1b94 ("RDMA/irdma: Register auxiliary driver and implement private channel OPs") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260914122840.1709743-1-lgs201920130244@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 8069935474b1502459ab50f75a67d7394a93cd5d Author: Henry Martin Date: Sat Oct 10 11:28:56 2026 +0800 smb: client: fix use-after-free in cifs_ses_add_channel() commit 031278577380e7875d95aed81a2b2bcac39be923 upstream. The error path of cifs_ses_add_channel() calls cifs_put_tcp_session() before cifs_chan_clear_need_reconnect(). The latter reaches cifs_ses_get_chan_index(), which dereferences server->terminate; if the put was the final reference, TCP_Server_Info is already freed and this is a use-after-free. Same put-then-use pattern as the recently fixed sibling in commit 717e0a25036b ("cifs: Fix server use-after-free in cifs_chan_skip_or_disable()"). Move the put last, but do not read chan->server after dropping chan_lock: chan points into ses->chans[], and once chan_count is decremented a concurrent add_channel can reuse the slot and overwrite the pointer, so the put would act on the new channel's server. Cache the pointer under chan_lock, clear the reconnect bit and decrement chan_count while still holding the reference, and release it after the unlock. This issue was discovered by Tencent CodeBuddy Security. Fixes: ee1d21794e55a ("cifs: handle when server stops supporting multichannel") Signed-off-by: Henry Martin Cc: stable@vger.kernel.org Reviewed-by: Namjae Jeon Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit 6c4c12b0fadcb71e4e6616e6c1ca529c772f2a15 Author: Diego Oliva Date: Tue Sep 29 10:16:30 2026 +0100 smb: client: fix use-after-free infoleak via the readdir resume name commit 59131dd72f62b198fc9ea1489ad9d3573154f684 upstream. CIFSFindNext() copies the resume name that cifs_save_resume_key() recorded from the last entry of the previous response into its request; psrch_inf->presume_name points into the response buffer that entry came from, and nothing ever clears it. find_cifs_entry() records a new name only from a response with a usable last entry, and cifs_readdir() only from an entry it walks to, so a response that carries no entries and leaves last_entry NULL, because CIFSFindFirst() or CIFSFindNext() rejected LastNameOffset, refreshes neither and presume_name keeps pointing into the previous response. That buffer has already been released: by CIFSFindNext() before it installs the new response, or by find_cifs_entry() when it rewinds the search, which does not drop the name either and can then fail in initiate_cifs_search() before a new response replaces it. The next CIFSFindNext() then copies up to PATH_MAX - 1 bytes of the resume name out of the released buffer into its request and sends them to the server: a use-after-free read that leaks kernel memory to a malicious or compromised server, which can provoke it with a single FindNext response that carries no entries and a LastNameOffset above CIFSMaxBufSize, which is all the existing check rejects. With KASAN enabled, a server that answers a listing that way gives: CIFS: VFS: ignoring corrupt resume name ================================================================== BUG: KASAN: slab-use-after-free in CIFSFindNext+0x8ca/0x14c0 Read of size 4080 at addr ffff88807c823f98 by task ls/83 CPU: 0 UID: 0 PID: 83 Comm: ls Tainted: G B 7.3.0-rc4-00457-gf14572c203d5 #69 PREEMPT(lazy) Tainted: [B]=BAD_PAGE Call Trace: kasan_report+0xdf/0x1a0 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x23/0x60 CIFSFindNext+0x8ca/0x14c0 cifs_readdir+0xf51/0x29c0 iterate_dir+0x1c0/0x570 __x64_sys_getdents64+0x133/0x270 do_syscall_64+0x109/0x5d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 83 on cpu 1 at 13.497119s: cifs_buf_get+0x36/0x90 smb_init+0x4f/0x110 CIFSFindNext+0xf7/0x14c0 cifs_readdir+0xf51/0x29c0 Freed by task 83 on cpu 0 at 13.584018s: cifs_buf_release+0x41/0x80 CIFSFindNext+0xfce/0x14c0 cifs_readdir+0xf51/0x29c0 The buggy address is located 16280 bytes inside of freed 16588-byte region [ffff88807c820000, ffff88807c8240cc) ================================================================== The same memcpy() first reads past the end of that object while it is still live, a slab-out-of-bounds read that the following patches bound; that is the taint the report above carries. SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount. Clear presume_name and resume_name_len whenever a new response is installed and when the rewind path releases the search buffer, so that the name never outlives the buffer it points into, and reset resume_key with them, since it was taken from the same entry and would otherwise be sent with an empty name. A response without a usable last entry then continues the search with an empty resume name rather than a stale one; CIFSFindNext() skips the copy of a zero-length name so that it never runs on the NULL pointer. The next patch in the series leaves last_entry NULL for a response that carries no entries, and bounds LastNameOffset against the received response rather than against CIFSMaxBufSize. Responses that are given a last entry today then take the path fixed here, so that patch must not be applied without this one. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: b77d753c413e ("[CIFS] Check that last search entry resume key is valid") Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Diego Oliva Reviewed-by: David Howells Signed-off-by: Paulo Alcantara Signed-off-by: Greg Kroah-Hartman commit b5e5d035abd1b49ecc9c85320fd6dfcc57ef9c79 Author: AngeloGioacchino Del Regno Date: Tue Jul 21 11:36:15 2026 +0200 spmi: Fix potential use-after-free by grabbing of_node reference commit f7aa9de4f2b197cdd704cdc476901b68ee128433 upstream. As noticed by Sashiko during a review run of an unrelated patch, in of_spmi_register_devices(), for_each_available_child_of_node() is used to loop through children, and to also assign a node to a newly created SPMI child device. Problem is that the refcount is dropped at every iteration so, in the specific case of DT overlays, a use-after-free may occur when an overlay is dynamically unloaded! To resolve this, increase the of_node refcount when assigning (in function of_spmi_register_devices) and release the reference in spmi_device_remove(). Fixes: bc32bbd04011 ("spmi: Set fwnode for spmi devices") Cc: stable@vger.kernel.org Reported-by: Sashiko Bot Closes: https://sashiko.dev/#/patchset/20260608100949.36309-1-angelogioacchino.delregno@collabora.com?part=2 Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 3c3b401650227e147c609c33fa458d5d963f2918 Author: Zijing Yin Date: Mon Sep 7 01:54:35 2026 -0700 SUNRPC: fix netns use-after-free in write_gssp() commit e7a8721b7edb54a157623f9e31d71345333b5fb9 upstream. While fuzzing with a customized syzkaller, I hit a refcount warning in xprt_alloc(), reached from a write to /proc/net/rpc/use-gss-proxy: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0xf8/0x120 CPU: 0 PID: 10404 Comm: syz.0.17 Not tainted 7.3.0-rc1-00096-gcfebfd3db73d Call Trace: xprt_alloc+0x83f/0x9d0 xs_setup_xprt+0xaf/0x3c0 xs_setup_local+0x47/0x7f0 xprt_create_transport+0x16c/0x730 rpc_create+0x38e/0x7f0 gssp_rpc_create+0xe2/0x180 set_gssp_clnt+0xba/0x1b0 write_gssp+0x200/0x310 proc_reg_write+0x240/0x330 vfs_write+0x2aa/0x1050 ksys_write+0x12a/0x250 do_syscall_64+0x117/0x750 entry_SYSCALL_64_after_hwframe+0x77/0x7f create_use_gss_proxy_proc_entry() stores the struct net pointer as the proc entry's private data without taking a reference on it, and an open file descriptor does not pin the namespace either, as procfs only pins the proc_dir_entry. write_gssp() reads that pointer back with pde_data() and hands it to set_gssp_clnt(), which reaches xprt_init(): xprt->xprt_net = get_net_track(net, &xprt->ns_tracker, GFP_KERNEL); get_net_track() -> get_net() -> refcount_inc() is unconditional, so rpc_create() assumes its caller holds a reference on args.net. write_gssp() does not. Dropping the last ns.count reference does not make the file go away. __put_net() only queues cleanup_net() on a workqueue, and the remove_proc_entry() that fences off further writes runs from the rpcsec_gss pernet .exit method, that is, from inside cleanup_net(). A write landing between those two points increments a refcount that is already zero. cleanup_net() does not re-read ns.count, so the namespace is freed anyway and the rpc_xprt -- along with the AF_LOCAL socket opened for it -- is left pointing at freed memory. The resurrected count is visible to the rest of that teardown too: with CONFIG_IPV6_MROUTE the same cleanup_net() worker then trips !mr_can_free_table() in ip6mr_free_table(), which tests check_net() on the namespace it is freeing. It reduces to opening /proc/net/rpc/use-gss-proxy inside a new network namespace, calling setns() back to the original one to drop the last reference, and then writing "1" to the still-open descriptor. Take the reference in write_gssp() itself and refuse the write when the namespace is already gone. This is what procfs does for every other /proc/net file: get_proc_net() is maybe_get_net(PDE_NET(PDE(inode))) and seq_open_net() returns -ENXIO when it fails. PDE_NET() cannot be reused here because the parent directory /proc/net/rpc carries no namespace pointer. Adding a .pre_exit to rpcsec_gss_net_ops so the entry is removed earlier would only narrow the window, since pre_exit also runs from cleanup_net(). Live namespaces are unaffected: a write still returns the error from set_gssp_clnt(), a write of "2" still returns -EINVAL, and reads are untouched. Fixes: 030d794bf498 ("SUNRPC: Use gssproxy upcall for server RPCGSS authentication.") Cc: stable@vger.kernel.org Signed-off-by: Zijing Yin Link: https://patch.msgid.link/20260907085435.644076-1-yzjaurora@gmail.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit ac7558126767d26198c94d21cdfe8a920ccccb79 Author: Andreas Wendleder Date: Tue Oct 13 02:01:24 2026 +0200 wifi: b43: fix use-after-free in b43_bcma_remove() commit c6c8bc355657115664131b38c53c5ddf7d93b072 upstream. b43_one_core_detach() frees the struct b43_wldev it is given the bus device of. b43_bcma_remove() then reads wldev->dev again to free the bus device, which is a read of freed memory. b43_ssb_remove() does not have the problem: it takes a copy of wldev->dev at the start. Do the same here. Fixes: 96838d61102a ("b43: Fix memory leaks in b43_bus_dev_ssb_init and b43_bus_dev_bcma_init") Cc: stable@vger.kernel.org Signed-off-by: Andreas Wendleder Link: https://patch.msgid.link/20261013000124.48605-1-gonsolo@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 41f968434a72f994d54aa86bdd18cead5b14493c Author: Li RongQing Date: Mon Jun 15 15:01:15 2026 +0800 x86/ioperm: Prevent NULL dereference on theoretical missing IO bitmap [ Upstream commit 2d36d3b451a94899db9c965adde15492ffe6027a ] Outside the IOPL emulation path, the IO bitmap is always expected to be allocated when TIF_IO_BITMAP is set. The paranoid WARN_ON_ONCE() handles the case where the flag and the pointer got out of sync. In this theoretical scenario, which presumes some other bug in the code that triggers the WARN_ON_ONCe(), return early, instead of continuing and dereferencing a NULL pointer. [ mingo: Clarified the changelog. ] Signed-off-by: Li RongQing Signed-off-by: Ingo Molnar Reviewed-by: Sohil Mehta Cc: H. Peter Anvin Link: https://patch.msgid.link/20260615070115.4720-1-lirongqing@baidu.com Signed-off-by: Sasha Levin commit 8519fc07a486e3dece785d4c4126f0b8ada9a655 Author: Kevin Cheng Date: Fri Oct 30 10:36:43 2026 +0000 KVM: VMX: Synthesize nested EPT violation GVA_IS_VALID/GVA_TRANSLATED bits [ Upstream commit 96b067b59ad9ccede585fcadab27543188353bff ] When injecting an EPT Violation into L2 in response to a fault detected while emulating an L2 GVA access, synthesize the GVA_IS_VALID and GVA_TRANSLATED bits using information provided by the walker, instead of pulling the bits from vmcs02.EXIT_QUALIFICATION. The information in vmcs02.EXIT_QUALIFICATION is valid/correct if and only if the fault being injected into L1 is the direct result of an EPT Violation VM-Exit from L2. E.g. if KVM is emulating an I/O instruction and the memory operand's translation through L1's EPT fails, using vmcs02.EXIT_QUALIFICATION is wrong as the semantics for EXIT_QUALIFICATION would be for an I/O exit, not an EPT Violation exit. Opportunistically clean up the formatting for creating the mask of bits to pull from vmcs02.EXIT_QUALIFICATION. Signed-off-by: Kevin Cheng [sean: use plumbed in @access bits, massage changelog] Link: https://patch.msgid.link/20260522232701.3671446-5-seanjc@google.com Signed-off-by: Sean Christopherson [doebel: no advanced EPT vmexit info here, so the mask keeps only the two GVA bits; set GVA_TRANSLATED via !(access & PFERR_GUEST_PAGE_MASK)] Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit 3b4df5414b99ab2dc5576e4d6f111497ad90bdee Author: Sean Christopherson Date: Fri Oct 30 10:36:42 2026 +0000 KVM: x86: Tell ->inject_page_fault() whether or a fault came from hardware [ Upstream commit fe0b872d750023eda270cbc01c53ead52b1049d8 ] When injecting a page fault (including nested TDP faults into L1), tell the injection routine whether or not the fault originated in hardware, i.e. if KVM is effectively forwarding a fault it intercept. For nested TDP fault injection, KVM needs to grab PAGE_WALK vs. GUEST_FINAL information from the VMCB/VMCS, _if_ the fault originated in hardware. Note, simply checking whether or not the original exit was due a #NPF or EPT Violation isn't sufficient/correct, as the fault being synthesized for L1 may or may not be the "same" fault that triggered a VM-Exit from L2. E.g. if access to emulated MMIO in L2 hits a !PRESENT fault (EPT Violation or #NPF), e.g. because MMIO caching is disabled or it's the first time the GPA has been accessed by L2, then KVM will enter the emulator. If emulating the MMIO instruction then hits a nested TDP fault, e.g. because L2 was accessing MMIO with a MOVSQ (memory-to-memory move), or because L1 has since unmapped the code stream, then the TDP fault synthesized to L1 will not be the same emulated fault the triggered the VM-Exit. No functional change intended (nothing uses the new param, yet...). Link: https://patch.msgid.link/20260522232701.3671446-3-seanjc@google.com Signed-off-by: Sean Christopherson Stable-dep-of: 96b067b59ad9 ("KVM: VMX: Synthesize nested EPT violation GVA_IS_VALID/GVA_TRANSLATED bits") Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit 8a803deb2c7fb7782b723edae7a587c6ea0a1c82 Author: Paolo Bonzini Date: Fri Oct 30 10:36:41 2026 +0000 KVM: x86/mmu: pass PFERR_GUEST_PAGE/FINAL_MASK to kvm_translate_gpa [ Upstream commit bd1c40114b02cf63ba33da8e7df71ed0fc2a3019 ] The XS/XU bit for EPT are only applied to final accesses, and use the U bit from the page walk itself. While strictly speaking not necessary (any value of PFERR_USER_MASK would be the same for page table accesses, because they're reads and writes only), it is clearer and less hackish to only apply MBEC to PFERR_GUEST_FINAL_MASK. Allow kvm-intel.ko to distinguish the two cases. Tested-by: David Riley Signed-off-by: Paolo Bonzini [doebel: load_pdptrs() lives in arch/x86/kvm/regs.c in this tree; keep this tree's mmu_is_nested() in the Hyper-V hunk] Stable-dep-of: 96b067b59ad9 ("KVM: VMX: Synthesize nested EPT violation GVA_IS_VALID/GVA_TRANSLATED bits") Signed-off-by: Bjoern Doebel Signed-off-by: Sasha Levin commit 42a44fe738f67ebdf85251de6c53f1bafe3677ae Author: Christoph Zwerschke Date: Mon Nov 2 16:32:41 2026 +0100 Revert "Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU" This reverts commit aa7b93fe98ba726971b7d0c68320ce513e68aac2 which is commit 980084de4d9b25193398d89a1c0430ba3501b683 upstream. With the device ID in the table, the adapter is handed over to btrtl, which in this tree, together with the backport of commit 4a23ce935f74 ("Bluetooth: btrtl: Add the support for RTL8761CUV"), now requires rtl_bt/rtl8761cu_fw.bin. That file is only shipped by linux-firmware since 20251111. On systems with older firmware packages, such as Debian trixie, the adapter no longer initializes. Without the ID entry it binds via the generic Bluetooth class and works on its ROM firmware, as it did before the backport. Mainline keeps the ID entry, so this revert is for 6.18.y only, as agreed in the regression thread. Reported-by: Erik Brangs Closes: https://bugs.debian.org/1149377 Link: https://lore.kernel.org/all/179104011040.2214689.5921682013387867802@eldamar.lan/ Signed-off-by: Christoph Zwerschke Signed-off-by: Sasha Levin commit eff110e062a51d3277c2af2f51cdefdc494dde29 Author: Christoph Zwerschke Date: Mon Nov 2 16:32:40 2026 +0100 Revert "Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU" This reverts commit bce588b4ca081833ed8fc62062291f71d4218278 which is commit 6f0624b4427e38c3bb63a951c536cf8adaee1238 upstream. With the device ID in the table, the adapter is handed over to btrtl, which in this tree, together with the backport of commit 4a23ce935f74 ("Bluetooth: btrtl: Add the support for RTL8761CUV"), now requires rtl_bt/rtl8761cu_fw.bin. That file is only shipped by linux-firmware since 20251111. On systems with older firmware packages, such as Debian trixie, the adapter no longer initializes. Without the ID entry it binds via the generic Bluetooth class and works on its ROM firmware, as it did before the backport. Mainline keeps the ID entry, so this revert is for 6.18.y only, as agreed in the regression thread. Reported-by: Erik Brangs Closes: https://bugs.debian.org/1149377 Link: https://lore.kernel.org/all/179104011040.2214689.5921682013387867802@eldamar.lan/ Signed-off-by: Christoph Zwerschke Signed-off-by: Sasha Levin commit d3d5560fb7550e74fb9851826d7dab505ffd05e0 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Tue Oct 20 12:57:59 2026 +0900 cgroup: serialize migrations of newly forked processes [ Upstream commit bf6fbf46b5ff68c4eebad5aa52309eb124f4509c ] With favordynmods enabled, a cgroup.procs migration takes the target threadgroup's cgroup_threadgroup_rwsem for writing. A process fork holds the forking threadgroup's semaphore for reading. These are different semaphores when fork creates a new process. copy_process() publishes the child's PID before cgroup_post_fork() links the child to its css_set. A writer can find the child in that interval, take its uncontended semaphore, and migrate it while child->cgroups still points to init_css_set and child->cg_list is empty. Migration links the node into init_css_set.mg_tasks. cgroup_post_fork() then adds the same node to the intended css_set as though it were unlinked, corrupting both task lists and their css_set ownership. This regresses the fork/migration race fixed by commit b12b533fa523 ("cgroups: add lock for child->cgroups in cgroup_post_fork()") and restored again in 2012 after the lock had been removed. The old task_lock protection was later superseded by global css_set and cgroup threadgroup locking. The change identified by the Fixes tag narrowed only the migration side back to a per-threadgroup lock, recreating the different-process exclusion failure. Take the new threadgroup's semaphore for reading before the child becomes visible and hold it through cgroup_post_fork(). Use a nested lock subclass because fork already holds the parent's semaphore. CLONE_THREAD children share the parent's signal_struct and remain covered by the existing lock. Migrations of unrelated, fully initialized threadgroups remain concurrent. An AI coding assistant was used to identify and reproduce the regression and to develop and test this fix. Fixes: 0568f89d4fb8 ("cgroup: replace global percpu_rwsem with per threadgroup resem when writing to cgroup.procs") Cc: stable@vger.kernel.org # 6.18+ Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 3d0d2b4ad54fc8acaee82a6994f8f24e0de23fb2 Author: Eric Dumazet Date: Tue Oct 13 13:50:22 2026 +0200 vlan: restore HW VLAN tag insertion with reorder_hdr off [ Upstream commit c2124f80be4ceb6ec566ca3b5fc87f84ea9c36e0 ] Commit 447cbe95ebb9 ("vlan: fix skb_under_panic and races when toggling HW VLAN offload") replaced vlan_passthru_header_ops with vlan_header_ops unconditionally to avoid lockless data races when modifying hard_header_len dynamically under RTNL. Prior to that commit, vlan devices on top of a real device capable of HW VLAN TX offload used vlan_passthru_header_ops, which never inserted the 802.1Q header in the frame. Now, with reorder_hdr=off (as done by Home Assistant OS / NetworkManager when flags are omitted over D-Bus), vlan_dev_hard_header() always pushes an in-band 802.1Q header, and vlan_dev_hard_start_xmit() hands the frame to the real device as is, even if the real device supports HW VLAN TX offload. This is a regression for r8169 users (Realtek RTL8168h), who report transmit queue timeouts (NETDEV WATCHDOG): this NIC stalls when asked to offload checksum and/or TSO for frames carrying an in-band tag. Users of r8152 based USB adapters were affected as well. Reverting the blamed commit, disabling TX checksum offload (which also disables TSO), or setting reorder_hdr=on were all reported to work around the issue. Keep vlan_dev_hard_header() as is: the in-band header keeps the frame layout seen at the vlan device egress (taps, tc, netfilter) unchanged, and is relied upon by stacked vlans (Q-in-Q) and by AF_PACKET SOCK_DGRAM users sending ETH_P_8021Q frames. Instead, when vlan_dev_hard_start_xmit() gets a frame carrying an in-band tag with our protocol and the real device can insert tags, move that tag to skb->vlan_tci with __skb_vlan_pop(), so that the real device inserts it. Frames sent on the wire are unchanged, except that frames shorter than 64 bytes with their tag now get up to 4 bytes of extra padding, as with reorder_hdr=on and before 447cbe95ebb9. skb_reset_mac_header() is needed first, because not all ndo_start_xmit() callers set the mac header (e.g. AF_XDP copy mode, which uses __dev_direct_xmit()). vlan_set_encap_proto() may read the two bytes after the vlan header, so frames whose linear part is shorter than VLAN_ETH_HLEN + 2 are sent unchanged, as before. This also makes sure h_vlan_proto, read earlier in the function, was in the linear part. Shared skbs (e.g. from pktgen) are also sent unchanged, since popping the tag modifies the skb, as are skbs already carrying a hwaccel tag (e.g. from generic XDP redirect), whose tag must not be overwritten, skbs carrying XDP metadata, which the pop would have to move, and CHECKSUM_PARTIAL skbs whose csum_start lies within the first VLAN_ETH_HLEN bytes (only possible with bogus offsets, e.g. from AF_XDP tx metadata), which the pop would leave before skb->data. If popping the header fails (memory allocation failure), the frame is dropped and counted in tx_dropped, rather than handing the real device a frame with an in-band tag. tx_bytes is now sampled before the pop, so the vlan device statistics do not change. This also applies to frames provided by the sender with our tag (AF_PACKET SOCK_RAW, or frames redirected from another reorder_hdr=off vlan): the real device now inserts their tag too. Fixes: 447cbe95ebb9 ("vlan: fix skb_under_panic and races when toggling HW VLAN offload") Reported-by: Jan Čermák Closes: https://lore.kernel.org/netdev/CAPa5EdCj3v17tB-SF2JNecq5Q8s1Pranr-XzAFWNpNTBPgPG7w@mail.gmail.com/ Reported-by: Stefan Agner Reported-by: hitchin999 Closes: https://github.com/home-assistant/operating-system/issues/5019 Tested-by: Jan Čermák Signed-off-by: Eric Dumazet Cc: Heiner Kallweit Link: https://patch.msgid.link/20261013115022.1043024-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3b56e95f6fad7fa7281450b443e861d82616fdb Author: Kuniyuki Iwashima Date: Wed May 6 03:59:18 2026 +0000 tcp: Fix potential UAF in reqsk_timer_handler(). commit 97c8a3c1f73d828de43a5a88e8a9a143efb2b661 upstream. When TCP socket migration fails at inet_ehash_insert() in reqsk_timer_handler(), we jump to the no_ownership: label and free the new reqsk immediately with __reqsk_free(). Thus, we must stop the new reqsk's timer before jumping to the label, but the timer might be missed since the cited commit, resulting in UAF. As we are in the original reqsk's timer context, we can safely call timer_delete_sync() for the new reqsk. Let's pass false to __inet_csk_reqsk_queue_drop() to stop the new reqsk's timer. Fixes: 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") Reported-by: Damiano Melotti Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260506035954.1563147-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e8aa0ac634f0d30a5df8106791ba67b17f71e2ae Author: Namjae Jeon Date: Sat Oct 17 09:44:48 2026 +0900 ksmbd: validate security descriptor offsets before pointer arithmetic commit 3474e1a304fbf9f7c996b24adcd519e031227a90 upstream. parse_sec_desc() constructs SID and DACL pointers by adding untrusted 32-bit offsets to the security descriptor before checking their bounds. The existing checks reject offsets into the descriptor header, but do not reject offsets beyond the descriptor's length. On a 32-bit kernel, a large offset can wrap the pointer before the descriptor. The end-only checks in parse_sid() and parse_dacl() can then accept it, allowing an authenticated SMB2 SET_INFO request to access memory outside the security descriptor and fault the kernel. Check each nonzero offset against acl_len before constructing its pointer. Initialize the optional owner and group SID pointers to NULL so an omitted SID remains absent when parsing the DACL. Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Cc: stable@vger.kernel.org Reported-by: Ratnaker Gautam Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit fb743d9cb66e84f023c780ece7cef7953c4f5479 Author: Karl Mehltretter Date: Sat Oct 3 01:29:38 2026 +0200 ksmbd: use u8 for SMB2 oplock level values commit f622fedabbb58c8006ee21373968ae07bf8a9467 upstream. The SMB2 oplock level is an unsigned 8-bit wire value, but smb20_oplock_break_ack() stores it in a plain char. On architectures where plain char is signed, the value 0xff becomes -1 and cannot compare equal to SMB2_OPLOCK_LEVEL_LEASE (0xff). The acknowledgment is consequently rejected with STATUS_INVALID_OPLOCK_PROTOCOL instead of the intended STATUS_INVALID_PARAMETER. Use u8 for the request and response oplock-level variables. This preserves all wire values in their original representation. Fixes: 80a56d4a826c ("ksmbd: align SMB2 oplock break ack handling") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 4f5ec4b0e9a89c02c25ee9932f7db09c17f784f8 Author: DaeMyung Kang Date: Fri Oct 9 00:25:35 2026 +0900 ksmbd: return end of file for reads past a named stream's data commit 626611dc22a3b63b3264a7a797d9dbc530234fcd upstream. A READ on a non-empty named stream at or beyond its end fails with STATUS_INVALID_PARAMETER. ksmbd_vfs_stream_read() returns -EINVAL when the offset is not below the stream length, and smb2_read() maps -EINVAL to that status. smb2_read() already turns a zero-byte read into STATUS_END_OF_FILE, the status a regular file returns at its end, and an empty stream already takes that path. Return 0 instead of -EINVAL so that non-empty streams do the same. Clients that read a stream until end of file otherwise get an error once they have read all of its data. The buffered copychunk path converts a zero-byte source read to -EIO, as it does for a regular file that shrinks during copying. Fixes: 2ae1a6cc4302 ("cifsd: fix potential read overflow in ksmbd_vfs_stream_read()") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 06a751809ebd33e95b05bf733697318a17a4872b Author: Abdifatah Suruur Date: Sat Oct 17 13:54:54 2026 +0300 ksmbd: reserve space for the UTF-16 terminator in stream info commit a025c4991a7d83edc4dd339e3ea86d8ff6226eca upstream. smb_strtoUTF16() always writes a terminating zero UTF-16 unit after the converted characters, but get_file_stream_info() budgets only sizeof(struct smb2_file_stream_info) + streamlen * 2 for a stream entry and sizeof(struct smb2_file_stream_info) + 7 * 2 for the trailing "::$DATA" entry. When an entry exactly fills the 448-byte small response buffer, the terminator is written two bytes past the allocation. Reserve one extra UTF-16 unit in both budget checks. The terminator is not part of the wire format, so the reported lengths are unchanged. Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 22464634d240f5132b0787048a10e8260ac7e639 Author: DaeMyung Kang Date: Fri Oct 9 00:25:37 2026 +0900 ksmbd: preserve unreadable named streams on open commit 80c816c047f7cae3c99cc75740c1f5d2c4d97b45 upstream. A write-only client can open an existing named stream with FILE_OPEN_IF without permission to read the underlying file. The case-insensitive lookup finds the xattr name, but querying its value length then fails with -EACCES. smb2_set_stream_name_xattr() treats every negative result as a missing stream and replaces the existing xattr with an empty value. A failed xattr list is not proof that the stream is absent either: for example, -ENOMEM can lead to the same empty replacement. Preserve listing errors and create a stream only for -ENOENT or -ENODATA. The latter can occur if the xattr is removed between listing its name and querying its value. Return other lookup errors without changing the stream. A write-only FILE_OPEN now reports access denied instead of name not found. FILE_OVERWRITE_IF and FILE_SUPERSEDE on an unreadable stream also fail instead of appearing to replace it. Stream writes and EOF changes already need to read the old value, so such handles cannot update the stream after opening either. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 9582dc3a31784ac930293b15edaa36c897d74e27 Author: Jan Koester Date: Mon Oct 26 10:25:37 2026 +0100 ksmbd: ignore network devices of other namespaces commit 1f5ce2b8b9164b3fcb93a18fe1e7b451c2fc6eea upstream. With no interface list configured, ksmbd binds every interface that comes up. ksmbd_netdev_event() does not look at the device's namespace, and create_socket() opens the listener in the namespace of the task raising NETDEV_UP. A container with its own address on a bridge brings up its interface and finds port 445 in its namespace already taken by ksmbd, so an SMB server running inside the container fails with "Address already in use". Interfaces are also matched by name only, so a container's eth0 going down would stop the listener on the host's eth0. Only handle netdev events for devices in init_net. Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Cc: stable@vger.kernel.org Signed-off-by: Jan Koester Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 93566781118cdff874023d5ca4e7b8054baaec31 Author: Cen Zhang (Microsoft) Date: Thu Oct 22 00:12:16 2026 -0400 ksmbd: fix parent dentry lifetime in directory enumeration commit 171df27077fb49b4af2c53ad2cedcd0e39664fe8 upstream. ksmbd_populate_dot_dotdot_entries() builds the ".." entry from the open directory's d_parent and passes that pointer to ksmbd_vfs_fill_dentry_attrs() without taking a reference. That pointer is only valid while the directory stays under this parent. If a concurrent rename moves the directory elsewhere, the old parent loses its last reference; a following rmdir then turns it into a negative dentry with d_inode cleared, and after the RCU grace period the dentry itself is freed. The worker still holds the raw pointer and dereferences d_inode through vfs_getattr() and vfs_getxattr(). A remote SMB client, authenticated or guest, triggers this by listing a directory while that directory is moved under a new parent and the old parent is deleted. It can be done by the client itself with write access or by other concurrent writers, triggering null-ptr-deref and slab-use-after-free on a KASAN build. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: ksmbd-io handle_ksmbd_work RIP: 0010:xattr_permission+0x9d/0x160 Call Trace: vfs_getxattr+0x9c/0x1b0 ksmbd_vfs_getxattr+0x82/0x100 ksmbd_vfs_get_dos_attrib_xattr+0x7f/0x130 ksmbd_vfs_fill_dentry_attrs+0x435/0x650 ksmbd_populate_dot_dotdot_entries+0x25e/0x630 smb2_query_dir+0xcf9/0x1a20 handle_ksmbd_work+0x5f1/0x1c80 process_one_work+0x90b/0x19d0 Fix by using the dentry reference counting APIs: take the parent with dget_parent(), take a matching dget() on ".", and dput() the dentry once ksmbd_vfs_fill_dentry_attrs() has returned or the pattern does not match. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Cc: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 4f238380ea3803afdc815c615521c6f6b13989a3 Author: Giorgi Kobakhia Date: Fri Sep 11 17:08:17 2026 -0700 ksmbd: fix overflow in dacloffset bounds check in build_sec_desc() commit eb96e2a0e817807c48dc8387ca6a5249fdeae3a0 upstream. When the large dacl_offset is provided, dacl_offset + sizeof(struct smb_acl) overflows on 32-bit builds and the check is passed, Which makes le16_to_cpu(ppdacl_ptr->size) read out-of-bounds. This only happens for dacl_offset in range [0xFFFFFFF8, 0xFFFFFFFF]. So the oob read is max 8 bytes preceding the allocated ppntsd. unsigned int dacl_offset = le32_to_cpu(ppntsd->dacloffset); int ppdacl_size, ntacl_size = ppntsd_size - dacl_offset; if (!dacl_offset || (dacl_offset + sizeof(struct smb_acl) > ppntsd_size)) goto out; Commit beff0bc9d69b ("ksmbd: fix overflow in dacloffset bounds check") fixes similar checks in other functions. But leaves this one out, because it is only valid for 32-bit builds. Reproduced on 32-bit ARM with KASAN, by a client sending SMB2 SET_INFO(SEC) with dacloffset=0xfffffff8, then QUERY_INFO(SEC) on the same file: BUG: KASAN: slab-out-of-bounds in build_sec_desc (fs/smb/server/smbacl.c:1105) Read of size 2 at addr c2a273fa by task kworker/1:1/35 CPU: 1 UID: 0 PID: 35 Comm: kworker/1:1 Not tainted 7.3.0-rc2+ #5 Workqueue: ksmbd-io handle_ksmbd_work Call trace: kasan_check_range from build_sec_desc (fs/smb/server/smbacl.c:1105) build_sec_desc from smb2_query_info (fs/smb/server/smb2pdu.c:7676) smb2_query_info from handle_ksmbd_work (fs/smb/server/server.c:160) handle_ksmbd_work from process_one_work (kernel/workqueue.c:3401) process_one_work from worker_thread (kernel/workqueue.c:3473) worker_thread from kthread (kernel/kthread.c:436) Add overflow check. Fixes: 8f0541186e9a ("ksmbd: fix heap-based overflow in set_ntacl_dacl()") Cc: stable@vger.kernel.org Assisted-by: LLM claude Tested-by: Xiang Mei Signed-off-by: Giorgi Kobakhia Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 93cb902b0ca04c9dc28b38776f7a03503c84b7ad Author: Dairui Zhang Date: Mon Sep 28 13:20:26 2026 +0800 ksmbd: fix OOB read and cross-share confusion in ksmbd_validate_name_reconnect() commit 783a7fc454991544bf92268d8f2413af1a7c7eb8 upstream. ksmbd_validate_name_reconnect() indexes ab_pathname[share->path_sz + 1] without checking that the path is longer than share->path_sz + 1 (d_path() fills the buffer from the end). A durable fp is not bound to its original share, so a client can preserve a file from a short-path share and reconnect it on a long-path share, making strcmp() read past the PATH_MAX buffer - with a long enough share path this oopses the kernel, and on a mapped page it also gives a byte-equality oracle on adjacent heap (the reconnect succeeds exactly when the out-of-bounds string equals the requested name). A same-share variant with the durable fp at the share root reads 1 byte past the buffer (strlen(ab_pathname) == share->path_sz). Check before comparing: the path must be longer than share->path_sz, it must start with share->path, and the next character must be '/'. The share root itself is accepted only for an empty name. Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2") Reported-by: Dairui Zhang Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Dairui Zhang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 24455d79b91b960c99e5fae24ab5c3a7689aca8d Author: Namjae Jeon Date: Sun Oct 4 09:42:27 2026 +0900 ksmbd: fix extended session security negotiation for raw NTLMSSP commit 6868f857514bbfd2ed10b9b566664dc4a8ca039d upstream. ksmbd_build_ntlmssp_challenge_blob() only advertises extended session security when conn->use_spnego is true. As a result, raw NTLMSSP negotiation drops NTLMSSP_NEGOTIATE_EXTENDED_SEC from the challenge even when the client requested it. A Windows capture shows an initial SPNEGO authentication succeeding, followed by a raw NTLMSSP negotiation on the same TCP connection. The raw challenge omits extended session security, and the client does not send an AUTHENTICATE message. The unfinished session then occupies the pending session slot, causing subsequent SESSION_SETUP requests to fail with STATUS_INSUFFICIENT_RESOURCES. Set NTLMSSP_NEGOTIATE_EXTENDED_SEC whenever the client requests it, independently of the SPNEGO wrapper, as required by [MS-NLMP]. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Reported-by: Tea La Forgia Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 99a9db401d16f37f47925ca009f77761102ff8cd Author: DaeMyung Kang Date: Sat Oct 17 12:40:50 2026 +0900 ksmbd: avoid restoring only in-memory EOF after allocation change commit 9455e920aebe41217cabff3f81e90da4c407fdb6 upstream. When SetAllocation requests a size below the allocated block count but above EOF, ksmbd truncates the file to that size and restores only the in-memory i_size. The larger EOF remains on disk and reappears after a reboot. A 3-byte file preallocated to 64 KiB can acquire a 4 KiB EOF after reducing its allocation to 4 KiB. Extending EOF this way is not a reliable way to reclaim the preallocation beyond the old EOF either. Only use this truncate path when the requested allocation is at or below the observed EOF. A truncate to the existing EOF still lets filesystems release preallocated blocks beyond EOF. Remove the in-memory-only i_size restoration. The size check still precedes vfs_truncate() taking the inode lock, so a concurrent shrink can make the truncate extend EOF; that race also existed in the original path. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit be28566c8264b9ae3d5e9b6bdce19d311bf918eb Author: Michail Andreas Michalopoulos Date: Mon Oct 19 21:11:16 2026 +0200 ksmbd: accept share config responses from ksmbd-tools before 3.5.3 commit 4f1ce9ffb996a524acf864316479a7806ae500c6 upstream. ksmbd-tools releases before 3.5.2 do not have the payload_sz field in struct ksmbd_share_config_response; the field occupies the last word of their reserved[] area, so the kernel always sees payload_sz == 0 from them. ipc_validate_msg() and share_config_request() used to treat payload_sz == 0 as "legacy userspace" and skip the payload size checks. That case was removed by commit f25e93768fcc ("ksmbd: prevent out-of-bounds reads in share config responses"). With payload_sz == 0: - the IPC$ (pipe) response fails the final message size comparison: these tools always send a one-byte payload, so msg_sz is sizeof(*resp) + 1, but the expected size is now computed as sizeof(*resp) + 0; - every other share fails "payload_sz <= veto_list_sz". In addition, ksmbd-tools before 3.5.3 copy a global "veto files" setting into the IPC$ response, so with such a configuration IPC$ also fails the now unconditional "veto_list_sz > payload_sz" check, even though pipe shares never use a veto list. ksmbd_ipc_share_config_request() then returns NULL and every tree connect fails with STATUS_BAD_NETWORK_NAME, so ksmbd cannot serve any share when used with these ksmbd-tools releases, for example the 3.5.1 package shipped by Ubuntu 24.04. Login still works, which makes the failure look like a configuration problem: CIFS: VFS: BAD_NETWORK_NAME: \\127.0.0.1\IPC$ CIFS: VFS: \\127.0.0.1 failed to connect to IPC (rc=-2) When payload_sz is zero, derive it from the size of the message actually received and store it back in the response, so that the checks in ipc_validate_msg() and the path and veto list parsing in share_config_request() all use the same bound. The response is the kernel's own copy made by handle_response(), and msg_sz has already been checked to be at least sizeof(*resp), so this cannot underflow. All checks added by that commit then apply unchanged, bounded by the bytes that really arrived, and newer ksmbd-tools that fill in payload_sz are unaffected. Also skip the veto list size check for pipe shares: share_config_request() reads neither the path nor the veto list for them. Tested in QEMU with ksmbd-tools 3.5.1 and 3.5.7 and the in-kernel SMB client over loopback, with and without a global "veto files" setting. Fixes: f25e93768fcc ("ksmbd: prevent out-of-bounds reads in share config responses") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Michail Andreas Michalopoulos Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit d85edc8f06eeffb583044098b7877b132f9517fe Author: David Heidelberg Date: Mon Sep 21 12:46:23 2026 +0200 backlight: qcom-wled: Fix WLED3 brightness register stride commit e60dc9c05e0f415ef8bc63b3179abdd49830a619 upstream. WLED3 has a 16-bit brightness register pair per string, at 0x40 + 2*n, which is what the pm8941-wled driver wrote to: rc = regmap_bulk_write(wled->regmap, wled->addr + WLED3_CTRL_REG_VAL_BASE + 2 * i, v, 2); The restructuring for WLED3 turned that into WLED3_SINK_REG_BRIGHT(n), defined as 0x40 + n, so the two byte writes for consecutive strings overlap: string 1 overwrites the MSB of string 0 with its own LSB, and with the default three strings only string 1 ends up with the requested value. Use the 2 byte stride. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: David Heidelberg Reviewed-by: Daniel Thompson (RISCstar) Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-2-bab8c7ef73cb@ixit.cz Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit e9bff555cc77ecb80c7fb7a816b1351ea4d5c738 Author: David Heidelberg Date: Mon Sep 21 12:46:24 2026 +0200 backlight: qcom-wled: Fix unbalanced OVP IRQ enable at probe commit 5eda6b51461932f9fd835ef9e4574650c69c4fe8 upstream. wled_configure_ovp_irq() derives the initial state of the OVP interrupt from the hardware: /* Keep OVP irq disabled until module is enabled */ if (!(val & WLED3_CTRL_REG_MOD_EN_MASK)) disable_irq(wled->ovp_irq); but wled->brightness, which is what the rest of the driver uses to tell whether the module is on, is left at zero. On boards where the bootloader hands the kernel a lit backlight the two disagree. MOD_EN is already set, so the interrupt is left enabled, while wled_update_status() still believes the backlight is off and takes if (!!brightness != !!wled->brightness) rc = wled_module_enable(wled, !!brightness); on the first backlight update. wled_module_enable() then schedules wled_ovp_work(), which calls enable_irq() on the already enabled interrupt: Unbalanced enable for IRQ 176 WARNING: CPU: 0 PID: 160 at kernel/irq/manage.c:774 __enable_irq+0x50/0x80 Hardware name: Xiaomi Pocophone F1 (DT) Workqueue: events wled_ovp_work Call trace: __enable_irq+0x50/0x80 enable_irq+0x48/0xa0 wled_ovp_work+0x18/0x24 process_one_work+0x1d0/0x350 worker_thread+0x13c/0x460 kthread+0x110/0x114 ret_from_fork+0x10/0x20 The bootloader is not the only way to get there. The readback runs after wledN_setup(), and wled4_setup() sets MOD_EN itself on the path where the sink configuration does not already match, as does the tail of wled_auto_string_detection(), which all three setup paths can reach through wled_auto_detection_at_init(). A cold-booted board with a dark panel can therefore reach the same disagreement. Move the MOD_EN readback into wled_probe() and use it to seed wled->brightness, so the driver starts out agreeing with the hardware, and key the OVP interrupt off wled->brightness instead. The first backlight update then only reprograms the brightness registers and leaves both the module and the interrupt alone. The OVP interrupt also stays armed from probe whenever the module is already enabled, rather than being disabled at probe and only enabled once something writes brightness. Note that a backlight update requesting brightness 0 before any non-zero one now really does turn the module off wherever MOD_EN was already set, where before it was silently ignored. wled->brightness is seeded with default-brightness rather than the level the bootloader actually programmed, so the first update can still step the brightness. Reading that level back is version specific and is done in a follow-up, to keep this fix small enough to backport. Assisted-by: LLM Fixes: 8663c188beea ("backlight: qcom-wled: Add auto string detection logic") Cc: stable@vger.kernel.org Signed-off-by: David Heidelberg Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-3-bab8c7ef73cb@ixit.cz Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 8eee3226bccd34d7edced8913968a72a9c50d3b3 Author: David Heidelberg Date: Mon Sep 21 12:46:22 2026 +0200 backlight: qcom-wled: Fix NULL pointer dereference in wled_remove() commit 1dbd46d4b2fb416a8202b1a8e4ef9d0cadbe075f upstream. wled_probe() doesn't set the driver data for the platform device. As a result, platform_get_drvdata() in wled_remove() will return NULL, and the first dereference of it crashes on unbind. Set the platform device driver data in wled_probe(). Cc: stable@vger.kernel.org Fixes: feeab87b3072 ("backlight: qcom-wled: Add support for short circuit handling") Signed-off-by: David Heidelberg Reviewed-by: Daniel Thompson (RISCstar) Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260921-qcom-wled-backlight-v4-1-bab8c7ef73cb@ixit.cz Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit cf41ae5149f1eddbc874e5d1fa68708c1b7ee546 Author: Myeonghun Pak Date: Fri Oct 2 23:04:39 2026 -0400 backlight: lm3630a: Cancel delayed work before destroying workqueue commit 2cf184caab8b406fdd9db126ee40d62418237456 upstream. The interrupt handler queues delayed work to read the interrupt status. After free_irq() stops the producer, this work can still be waiting on its timer. destroy_workqueue() cannot drain delayed work that has not yet been queued by its timer, so the timer can outlive both the workqueue and the devm-allocated chip containing the work. Cancel the delayed work synchronously after freeing the IRQ and before destroying the workqueue. This also waits for any running status read to finish before the chip's resources are released. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip") Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20261003030439.599330-1-mhun512@gmail.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit f204bb7c5d10482067e095af567c391bc88ecb44 Author: Kameron Carr Date: Mon Oct 19 16:09:46 2026 -0700 Drivers: hv: vmbus: Bounds check the shared ring buffer indices commit 1d287c17cc5bfd6386fe0770999be410b248d021 upstream. In a CoCo VM the host is untrusted. Since the VMBus ring buffer read and write indices live in shared memory, the guest has to treat both as potentially malicious. hv_ringbuffer_write() copies into the ring at write_index with no bounds checking, so the host can make the guest write packet data at any offset up to 4 GiB past the start of the ring buffer. read_index matters too: the available space derived from both indices is the only bound on how much is copied, and an out-of-range index can make it far larger than the ring. The fix is to validate both indices before use and to use the validated snapshot instead of re-accessing. For invalid indices, hv_ringbuffer_write() logs and returns -EIO. One re-read of write_index is left unchecked in this patch: hv_get_ring_bufferindices() fetches it again for the prev_indices trailer. The value is only returned to the host and is not used as an offset or length for indexing. Since this is not a security issue, it is addressed later in the series. Open-coding the bytes available arithmetic keeps the fix free of prerequisites; a later patch refactors it into a helper function. Fixes: 3e7ee4902fe6 ("Staging: hv: add the Hyper-V virtual bus") Cc: stable@vger.kernel.org # 5.15.x Reviewed-by: Michael Kelley Signed-off-by: Kameron Carr Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit d4bded35edf8d9cd5133dd934a71c3268f89f501 Author: Johan Hovold Date: Wed Oct 14 15:31:07 2026 +0200 driver core: fix parent lock use-after-free on USB disconnect commit 0f554506a3fc6a21e714adf38cc3eb0ffe1bb452 upstream. USB interfaces should be probed with their parent USB device lock held and the USB bus therefore sets the need_parent_lock bus flag so that driver core takes the parent lock when needed. Driver core is only guaranteed to hold a reference to the parent device during initial probe however and nothing prevents the device and its parent from being deregistered and the parent potentially freed, for example, while iterating over devices in driver_attach() or bus_rescan_devices_helper(). Since commit 524134d42231 ("USB: don't cancel queued resets when unbinding drivers") USB interfaces hold a reference to their parent USB device, but a parent hub may still go away while probing a USB device (e.g. via the drivers_probe sysfs interface). This can lead to a use-after-free when taking the parent device lock before checking the device->p->dead flag of the device being probed. As only USB interfaces actually need the parent lock, make the need_parent_lock feature even more fine grained by making it a device type rather than bus feature. By requiring that any users also make sure that their devices hold a reference to their parents (like USB does), driver core can lock a device and its parent without first checking if the device has been deregistered. Note that this will also increase parallelism when using asynchronous probe as USB devices connected to the same hub can now be probed in parallel. Fixes: bf74ad5bc417 ("[PATCH] Hold the device's parent's lock during probe and remove") Cc: stable@vger.kernel.org # 2.6.16: 524134d42231: USB: don't cancel queued resets when unbinding drivers Cc: stable@vger.kernel.org # 2.6.16 Cc: Alan Stern Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20261014133109.1392265-2-johan@kernel.org [ Fix mention of bus vs. device type in __device_driver_{un}lock(). - Danilo ] Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 890096a9e7c26a43634f6cba5565fffc082bb111 Author: Josef Bacik Date: Tue Oct 27 18:18:19 2026 +0100 driver core: Limit the messages on a refused uevent commit a01c8e5b1dff1ce489e6b339139e744db36b8bb3 upstream. A write to a "uevent" file which is no valid action makes kobject_synth_uevent() print a warning and uevent_store() an error every time. This is generally considered a bad thing so rate limit these messages. Fixes: b0e37c0d8a6a ("net-sysfs: make sure objects belong to container's owner") Cc: stable Signed-off-by: Josef Bacik Link: https://patch.msgid.link/2026102718-conduit-glorious-a8dc@gregkh Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 4a9a39ef6da4a3447e97033ec53077094fc2d69c Author: Johan Hovold Date: Wed Oct 14 15:31:08 2026 +0200 driver core: take parent lock on deferred probe commit 4059f8986c8f50102a04335cc1da4921dfd262d8 upstream. USB interfaces should be probed with the parent USB device lock held, but this is not honoured when probe is deferred. Add a new bus_probe_device_deferred() helper to handle deferred probe where the parent device lock is not held. Fixes: d1c3414c2a9d ("drivercore: Add driver probe deferral mechanism") Reported-by: Mario Peter Link: https://lore.kernel.org/20261007131514.1260696-1-mario.peter@leica-geosystems.com Cc: stable@vger.kernel.org # 3.4 Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20261014133109.1392265-3-johan@kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 2f1111eb40d7c27d2261c012df42bfe0e3e4e627 Author: Jamal Hadi Salim Date: Wed Oct 28 13:27:03 2026 +0100 net/sched: act_ife: do not consume the inner header on egress commit 498c631f9c6d74aad4bf43039fa3ce70ae9a8bb7 upstream. The issue: tcf_ife_decode() unconditionally calls eth_type_trans(), which pulls ETH_HLEN. On egress this consumes the inner Ethernet header, and the device receives an skb whose data points to the L3 header: - loopback_xmit() parses L3 data as Ethernet: the "ethertype" comes from the inner IPv4 source address, and the decapsulated packet is dropped or misparsed. - a real NIC transmits the frame without its Ethernet header. (The __skb_pull() BUG this used to trigger in loopback_xmit() when the remaining linear area was short is handled by "loopback: use eth_type_trans_careful()".) The Fix: Parse the inner Ethernet header with eth_type_trans() in both directions, then restore the egress data position and MAC length. On ingress the existing behavior is unchanged. On egress, push the inner Ethernet header back after parsing so the xmit path sees the original frame and later actions see a consistent network header. Conditions to recreate the bug: - egress tc filter on lo: action ife decode pipe; - AF_PACKET SOCK_RAW frame: outer Ethernet with ETH_P_IFE, IFE metadata, inner Ethernet + a valid IPv4 ICMP echo request to a local address; - before this patch, no echo is received; after it, the echo is delivered and answered. Fixes: ef6980b6becb ("introduce IFE action") Cc: stable@vger.kernel.org Signed-off-by: Jamal Hadi Salim [edumazet: reworded changelog, the crash is now handled in loopback] Signed-off-by: Eric Dumazet Acked-by: Alexei Starovoitov Link: https://patch.msgid.link/20261028122703.2093730-6-edumazet@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a3486bfb9d098473516cc0ec13061030d9f5c518 Author: Antonio Quartulli Date: Mon Oct 26 16:31:12 2026 +0100 net/sched: fix packet reordering on requeue commit 14368b9aa1017fee35d2589be7b17e0485c0f93e upstream. dev_requeue_skb() appends requeued skbs to the tail of q->gso_skb, while dequeue_skb() takes them back one at a time from the head. If the driver returns NETDEV_TX_BUSY again for the first of them, it moves behind the skbs still parked there and is sent after them. This showed up as heavy TCP reordering while benchmarking over veth, which returns NETDEV_TX_BUSY whenever its ring is full since commit dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops"). Requeue the skbs at the head of gso_skb, keeping their order. With 4 TCP streams over a veth pair with a pfifo qdisc, this removes about 1.3M out-of-order segments and 15-37k retransmits per 15 seconds, and raises throughput from about 40 to 76 Gbit/s. Fixes: a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback") Fixes: 9540d977618c ("net: sched: fix skb leak in dev_requeue_skb()") Cc: stable@vger.kernel.org Signed-off-by: Antonio Quartulli Reviewed-by: Eric Dumazet Acked-by: Jesper Dangaard Brouer Link: https://patch.msgid.link/20261026153113.3275494-1-antonio@mandelbit.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fc55d92ae6a4b2e7d062cad6d4c67f6b061d9cde Author: owen kwan Date: Sat Oct 24 10:34:15 2026 -0400 net/sched: sch_teql: fix use-after-free on lower qdisc drop commit 782d6bb8f9b8e9d8591181662222bf74cd3ecf79 upstream. The issue: teql_master_xmit() tests the slave's ndo_start_xmit() return value against NETDEV_TX_OK alone. A slave that consumes the skb but returns an error code (rc < NET_XMIT_MASK, e.g. NET_XMIT_DROP) is treated as if the skb were still owned, so the loop restores skb->dev and calls __skb_pull() on it. A VLAN slave returns the result of dev_queue_xmit() from its ndo_start_xmit() (propagated since cbbef5e18307), and when the lower qdisc drops the packet that value is NET_XMIT_DROP after the skb has been freed, giving a use-after-free in teql_master_xmit(). The Fix: test for consumption with dev_xmit_complete(), which accepts NETDEV_TX_OK and every rc < NET_XMIT_MASK, matching other callers that need to distinguish consumed results from busy. Only NETDEV_TX_OK keeps the packet counted in tx_packets/tx_bytes and advances the slave; a consumed result that is neither a success nor NET_XMIT_CN ends the attempt and is charged to tx_dropped, so lower-qdisc drops are no longer reported as good transmits. NET_XMIT_CN is counted like success because it can accompany acceptance of the current packet: pfifo_head_drop drops the old head, enqueues the current skb and returns NET_XMIT_CN. Conditions to recreate the bug: With CONFIG_NET_SCH_TEQL, CONFIG_VLAN_8021Q and CONFIG_DUMMY enabled, add lkrdummy0 (dummy) and lkrvlan0 (VLAN id 37 on lkrdummy0); set a pfifo limit 0 root on lkrdummy0 and a teql0 root on lkrvlan0; bring teql0 up with an address and send one UDP packet to it. The VLAN xmit returns NET_XMIT_DROP from the lower qdisc while holding a freed skb. Fixes: 572a9d7b6fc7 ("net: allow to propagate errors through ->ndo_hard_start_xmit()") Link: https://lore.kernel.org/netdev/179248763469.3135.1739559328868319628@kernel.org/ Link: https://lore.kernel.org/netdev/20261023162821.GN708417@horms.kernel.org/ Cc: stable@vger.kernel.org Signed-off-by: owen kwan Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-Y0BY.v2.r0.20261024060625-2@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 87d636b302886e9793bb51bf81f797b2c04197e0 Author: Jamal Hadi Salim Date: Sat Oct 24 10:34:14 2026 -0400 net/sched: sch_teql: fix slaves_lock IRQ deadlock commit 8b2043279dae25483fe1f2d926e76d41ab95c398 upstream. This is a followup of commit e5b811fe7931 ("net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF") as reported by Sashiko. The issue: master->slaves_lock serializes the master's ring of slave qdiscs. The control paths -- teql_dequeue(), teql_destroy() and teql_qdisc_init() -- take it with spin_lock_bh(), while teql_master_xmit() (the master's ndo_start_xmit) takes it with plain spin_lock(). netpoll_send_skb() wraps the transmit in local_irq_save(), and __netpoll_send_skb() asserts lockdep_assert_irqs_disabled(), so teql_master_xmit() reached from netconsole always acquires slaves_lock with hard IRQs disabled. On PREEMPT_RT spinlock_t is an rtmutex, and Documentation/locking/locktypes.rst names local_irq_disable(); spin_lock(&lock); as a sequence that breaks there because the rtmutex requires a fully preemptible context. This is reachable without any panic: the nbcon printer thread calls netconsole's write_thread() callback on every message. The usual remedy -- folding the IRQ disable into the lock with spin_lock_irqsave() -- is unavailable because the local_irq_save() is netpoll's, not ours. On non-RT the same asymmetry leaves slaves_lock acquirable with hard IRQs disabled on one path and held with hard IRQs enabled on another. That is only exploitable during the panic console flush (netconsole is CON_NBCON_ATOMIC_UNSAFE, so console_is_usable() admits its write_atomic() only from nbcon_atomic_flush_unsafe(), which panic() alone calls), and even then an IRQ-saving lock does not help if the holder oopsed inside the section or was stopped by panic_other_cpus_shutdown(). So the non-RT half is hardening; the PREEMPT_RT half is the bug. The Fix: take slaves_lock as a raw spinlock with IRQs saved at every site. Since skb_queue_purge() takes the queue's spinlock_t and may not nest inside a raw lock on PREEMPT_RT, move its call in teql_destroy() outside the raw section; dat->q is the dying qdisc's own queue and was never serialized by slaves_lock, so the move is behaviour-neutral. The new critical sections contain only RCU pointer assignments and netdev_get_tx_queue(); skb_queue_purge(), netif_wake_queue() and dev_reset_queue() are all outside them. teql_destroy()'s ring walk is O(slaves), two pointer loads and a compare per iteration, so even a large ring is microseconds with IRQs off. Keeping the purge conditional rather than dropping it outright is the conservative call for a backport. Some context: commit 6301f6a34ed8 ("net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants") hardened the parent fix; together they addressed the master->slaves resurrection use-after-free and the xmit-side BH warning but left the reverse direction -- a hard IRQ re-entering xmit while a control path holds the lock -- unaddressed. Conditions to recreate the bug: - CONFIG_PREEMPT_RT, CONFIG_NET_SCH_TEQL, CONFIG_DUMMY and CONFIG_NETCONSOLE. - Run `ip link add dev teqlslave0 type dummy`, bring teqlslave0 up, attach it with `tc qdisc add dev teqlslave0 root teql0`, and bring teql0 up. - Configure a netconsole target on teql0 with explicit local and remote IP addresses and a remote MAC address, then emit a console message. The nbcon printer thread reaches teql_master_xmit() with hard IRQs disabled by netpoll; taking slaves_lock as a spinlock_t is invalid on PREEMPT_RT. No panic or concurrent qdisc change is required. - Reachable by an admin with CAP_NET_ADMIN; teql devices exist only in the initial netns (no per-netns ops), so a user namespace does not suffice. Fixes: e5b811fe7931 ("net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF") Reported-by: Sashiko (gemini) Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260630150922.238714-1-jhs%40mojatatu.com Link: https://lore.kernel.org/netdev/20260630150922.238714-1-jhs@mojatatu.com/ Cc: stable@vger.kernel.org Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-Y0BY.v2.r0.20261024060625-1@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit cdffcb89d84455158d057a6baa87a67225a7f062 Author: Yuhang Zheng Date: Mon Oct 12 09:07:19 2026 +0800 net/sched: cls_flower: avoid stale mask references after delete commit 58f7989da6e715ce834ac861b7ba6ae9f9bdb098 upstream. Flower releases a mask reference when a filter is removed from the classifier. The filter object can remain alive while dump, walk, or hardware reoffload paths hold a reference to it. Those paths can then dereference f->mask after the mask has already been released. Keep the mask reference until the filter reference count reaches zero. Release the mask synchronously from the final __fl_put() while the caller still holds the tcf_proto reference, and leave the existing RCU work to free the mask. This keeps the mask available to every reader that still holds the filter. The filter is still removed from the classifier indexes immediately. Therefore, a deleted filter can temporarily retain an otherwise empty mask; fl_delete() uses the handle IDR, rather than the mask list, to determine whether the classifier has become empty. Failed mask assignment can leave fnew->mask as an error or borrowed pointer without an owned mask reference. Clear it before the common failure path so the final put cannot release an unowned reference. This fix does not add fields, snapshots, or per-filter memory. Fixes: 92149190067d ("net: sched: flower: set unlocked flag for flower proto ops") Cc: stable@vger.kernel.org Reported-by: Xin Liu Tested-by: Yucheng Lu Signed-off-by: Yuhang Zheng Signed-off-by: Ren Wei Link: https://patch.msgid.link/20261012010720.2248662-2-n05ec@lzu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5d3e01de312090d93b53bc179bf21cd5891f6d1e Author: Jamal Hadi Salim Date: Sat Oct 10 17:02:49 2026 -0400 net/sched: cls_bpf: accept dev-bound programs on shared blocks commit d305547d1632a242818c5ebb430c85121a2ed434 upstream. The issue: Follow-up to commit 120977e2c096 ("net/sched: cls_bpf: reject dev-bound programs bound to a different device"), which derived the target device from block->q: dev = block->q ? qdisc_dev(block->q) : NULL; tcf_block_create() leaves block->q NULL for shared blocks, so a device-bound program attached through a shared block is rejected with -EINVAL even when it is bound to a netdev that owns the block. The offload path (cls_bpf_offload_cmd()) never consults block->q and drives the per-device callbacks for shared blocks as before. The Fix: Accept the attach on a shared block when bpf_offload_dev_match() matches every netdev bound to the block, and reject an empty block. Every member must match because the offload path broadcasts the program to every callback registered on the block, so an any-member check would re-admit the wrong-device attach on a mixed block. Every dev-bound SCHED_CLS attach is skip_sw, which becomes err_stop and aborts the offload on the first failing callback, so the all-members rule is the offload path's own semantics. Iterate the public block->ports xarray (913b47d3424e, v6.8-rc1) rather than block->owner_list, which is private to cls_api.c. The shared-block rejection reports "Program is not bound to every device in the block", distinct from the non-shared message, because a member can exist without a registered callback (netdevsim registers its block callback ingress-only). Context note: This patch is not an independent fix: it re-exposes the shared-block replay path that commit 120977e2c096 ("net/sched: cls_bpf: reject dev-bound programs bound to a different device") had closed, so patch 1 must be applied first, including in stable. A stable tree taking this patch alone would re-enable shared-block attaches on a kernel whose netdevsim callback is still unchecked. Conditions to recreate the bug: - CONFIG_NETDEVSIM=y, CONFIG_NET_CLS_BPF=y - load a dev-bound SCHED_CLS program for netdevsim device B (prog_ifindex=B), pin it in bpffs - tc qdisc add dev B ingress_block 22 clsact - tc filter add block 22 ingress bpf da object-pinned skip_sw Unfixed, the filter add fails with -EINVAL ("Program is bound to a different device"); fixed, it succeeds. Adding a second, independently backed netdevsim device to the same block makes the attach fail again. Fixes: 120977e2c096 ("net/sched: cls_bpf: reject dev-bound programs bound to a different device") Reported-by: Sashiko (nipa) Link: https://lore.kernel.org/netdev/20260809094418.901607-1-jhs@mojatatu.com/ Link: https://lore.kernel.org/netdev/QDISC-PYC7.v1.20261003103747@mojatatu.com/ Cc: stable@vger.kernel.org Reviewed-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Simon Horman Link: https://patch.msgid.link/QDISC-PYC7.v2.20261010165947-3@mojatatu.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6cf00e646dc3f386dda8e608e2ca71a737c3dc14 Author: Jiakai Xu Date: Wed Mar 18 09:29:56 2026 +0000 RISC-V: KVM: Fix double-free of sdata in kvm_pmu_clear_snapshot_area() [ Upstream commit 310e2096b082ae0010e7afef666073b966ac2fa7 ] In kvm_riscv_vcpu_pmu_snapshot_set_shmem(), when kvm_vcpu_write_guest() fails, kvpmu->sdata is freed but not set to NULL. This leaves a dangling pointer that will be freed again when kvm_pmu_clear_snapshot_area() is called during vcpu teardown, triggering a KASAN double-free report. First free occurs in kvm_riscv_vcpu_pmu_snapshot_set_shmem(): kvm_riscv_vcpu_pmu_snapshot_set_shmem arch/riscv/kvm/vcpu_pmu.c:443 kvm_sbi_ext_pmu_handler arch/riscv/kvm/vcpu_sbi_pmu.c:74 kvm_riscv_vcpu_sbi_ecall arch/riscv/kvm/vcpu_sbi.c:608 kvm_riscv_vcpu_exit arch/riscv/kvm/vcpu_exit.c:240 kvm_arch_vcpu_ioctl_run arch/riscv/kvm/vcpu.c:1008 kvm_vcpu_ioctl virt/kvm/kvm_main.c:4476 Second free (double-free) occurs in kvm_pmu_clear_snapshot_area(): kvm_pmu_clear_snapshot_area arch/riscv/kvm/vcpu_pmu.c:403 [inline] kvm_riscv_vcpu_pmu_deinit.part arch/riscv/kvm/vcpu_pmu.c:905 kvm_riscv_vcpu_pmu_deinit arch/riscv/kvm/vcpu_pmu.c:893 kvm_arch_vcpu_destroy arch/riscv/kvm/vcpu.c:199 kvm_vcpu_destroy virt/kvm/kvm_main.c:469 [inline] kvm_destroy_vcpus virt/kvm/kvm_main.c:489 kvm_arch_destroy_vm arch/riscv/kvm/vm.c:54 kvm_destroy_vm virt/kvm/kvm_main.c:1301 [inline] kvm_put_kvm virt/kvm/kvm_main.c:1338 kvm_vm_release virt/kvm/kvm_main.c:1361 Fix it by setting kvpmu->sdata to NULL after kfree() in kvm_riscv_vcpu_pmu_snapshot_set_shmem(), so that the subsequent kfree(NULL) in kvm_pmu_clear_snapshot_area() becomes a safe no-op. This bug was found by fuzzing the KVM RISC-V PMU interface. Fixes: c2f41ddbcdd756 ("RISC-V: KVM: Implement SBI PMU Snapshot feature") Signed-off-by: Jiakai Xu Signed-off-by: Jiakai Xu Reviewed-by: Nutty Liu Reviewed-by: Andrew Jones Link: https://lore.kernel.org/r/20260318092956.708246-1-xujiakai2025@iscas.ac.cn Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit b97686f158517c81b3936ac28b987cbdaf0b7f8e Author: Timur Kristóf Date: Tue Oct 6 23:16:07 2026 +0200 drm/amdgpu/uvd3.1: Fix checking whether UVD firmware keyselect was already set [ Upstream commit 800ea86e83e137395eba54103e5c459c2bc9965f ] The PASS_MASK is for a different register not for UVD_FW_START. It was a mistake to check this flag. It should be enough to check that the register is non-zero. Fixes: 889a2cfd889c ("drm/amdgpu/uvd3.1: Don't validate the firmware when already validated") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20261006211607.75407-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 9dee462c83259ca769aa1bf82228adee9831685c) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b20c4193a4250353eeba887c446f151b6cdaf64f Author: Donggeun Yoo Date: Mon Sep 14 14:34:43 2026 +0900 tracing: Fix NULL dereference when copying keys for a field variable [ Upstream commit a0777b9e53157f1f6848a0fd0650f5465391ea81 ] In event_hist_trigger_parse() where it needs to create actions like "onmatch", it calls: event_hist_trigger_parse() { create_actions() { action_create() { trace_action_create() { trace_action_create_field_var() { create_field_var_hist() Where create_field_var_hist() does a loop on the hist_data representing the keys. The issue is, if the keys uses one of the pseudo field types (like common_cpu), the hist_data field element will have NULL for its field member causing a NULL pointer dereference when accessing the key_field->field->name. # echo 'hist:keys=common_cpu:ts0=common_timestamp.usecs' > \ events/sched/sched_waking/trigger # echo 'my_synth u64 lat; int prio' > synthetic_events # echo 'hist:keys=common_cpu:wakeup_lat=common_timestamp.usecs-$ts0:\ onmatch(sched.sched_waking).my_synth($wakeup_lat,prio)' > \ events/sched/sched_switch/trigger KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:create_field_var_hist+0x771/0x1380 Call Trace: trace_action_create_field_var+0x360/0x600 trace_action_create+0x393/0xe80 event_hist_trigger_parse+0x3e47/0x69e0 trigger_process_regex+0x1a6/0x250 event_trigger_write+0xce/0x160 Instead of accessing it directly, use the proper handler expr_field_str() to get the name. The three previous patches are prerequisites: without them a .buckets key and a common_stacktrace key each render into a command that cannot be parsed back. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914053443.981201-5-donggeunyoo.kernel@gmail.com Fixes: 02205a6752f2 ("tracing: Add support for 'field variables'") Signed-off-by: Donggeun Yoo Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 9876738cd08eb1ee18e9d7028ef9b7f7d3891b88 Author: Pengpeng Hou Date: Thu Jun 11 13:59:45 2026 +0800 tracing: Bound histogram expression strings with seq_buf [ Upstream commit 935601a4276f28105498609f7f98aa66e86e9c96 ] expr_str() allocates a fixed MAX_FILTER_STR_VAL buffer and then builds expression names with a series of raw strcat() appends. Nested operands, constants, field flags, and generated field names can push the rendered string past that fixed limit before the name is attached to the hist field. Build expression strings with seq_buf and return -E2BIG when the rendered name would exceed MAX_FILTER_STR_VAL. This keeps the existing tracing-side limit while replacing the raw append logic with bounded construction. Link: https://patch.msgid.link/20260611055945.22348-4-pengpeng@iscas.ac.cn Signed-off-by: Pengpeng Hou Signed-off-by: Steven Rostedt Stable-dep-of: a0777b9e5315 ("tracing: Fix NULL dereference when copying keys for a field variable") Signed-off-by: Sasha Levin commit 69c4a13c65873151477efbfcfc862993d2aaf104 Author: Pengpeng Hou Date: Thu Jun 11 13:59:44 2026 +0800 tracing: Return ERR_PTR() from expr_str() [ Upstream commit a5ca27e8ff1c10e949af7cfe474d6d1a08fb5601 ] expr_str() currently reports all failure cases as NULL, so callers cannot distinguish invalid recursion depth from allocation failure or later string construction errors. Return ERR_PTR()-encoded errors from expr_str() and make parse_unary() and parse_expr() propagate them. Clear expr->name before destroying the hist field so the error pointer is not freed as a string. Link: https://patch.msgid.link/20260611055945.22348-3-pengpeng@iscas.ac.cn Signed-off-by: Pengpeng Hou Signed-off-by: Steven Rostedt Stable-dep-of: 935601a4276f ("tracing: Bound histogram expression strings with seq_buf") Signed-off-by: Sasha Levin commit 4cb2b85da2bddc5aec846cdd5daa01d56c98c142 Author: Pengpeng Hou Date: Thu Jun 11 13:59:43 2026 +0800 tracing: Use __free() for expr_str() buffer [ Upstream commit 988995c0552b6213b6bf16cea57258d4842c1488 ] expr_str() allocates a temporary expression buffer and manually frees it on some error paths. Convert the buffer to __free(kfree) and return it with return_ptr() on success. This keeps ownership handling separate from the later ERR_PTR() conversion and string-bound change. Link: https://patch.msgid.link/20260611055945.22348-2-pengpeng@iscas.ac.cn Signed-off-by: Pengpeng Hou Signed-off-by: Steven Rostedt Stable-dep-of: a0777b9e5315 ("tracing: Fix NULL dereference when copying keys for a field variable") Signed-off-by: Sasha Levin commit 232c6e8486c7c33f0dcee8fce2c62e6db08ac150 Author: Tom Zanussi Date: Mon Apr 13 17:35:37 2026 -0500 tracing: Fix fully-qualified variable reference printing in histograms [ Upstream commit 9236eebd138aa2753f7b30fc6cee7b7202841247 ] The syntax for fully-qualified variable references in histograms is subsys.event.$var, which is parsed correctly, but not displayed correctly when printing a histogram spec. The current code puts the $ reference at the beginning of the fully-qualified variable name i.e. $subsys.event.var, which is incorrect. Before: trigger info: hist:keys=next_comm:vals=hitcount:wakeup_lat=common_timestamp.usecs-$sched.sched_wakeup.ts0: ... After: trigger info: hist:keys=next_comm:vals=hitcount:wakeup_lat=common_timestamp.usecs-sched.sched_wakeup.$ts0: ... Link: https://patch.msgid.link/5dee9a86d062a4dd68c2214f3d90ac93811e1951.1776112478.git.zanussi@kernel.org Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) Stable-dep-of: a0777b9e5315 ("tracing: Fix NULL dereference when copying keys for a field variable") Signed-off-by: Sasha Levin commit febee5fb9164793863ba216281fffd19e0f74e46 Author: Christian Brauner Date: Fri Oct 9 23:51:58 2026 +0200 ntfs3: free replaced mount options after a grace period [ Upstream commit 56c3824de56b5275c02ff6b6aa27ddbacfbb9b25 ] ntfs_fs_reconfigure() replaces the old mount options with new mount options in sbi->options. The old mount options land in fs_context and are freed as soon as remount returns. With a pathwalk held up in ntfs_nls_to_utf16() between loading sbi->options and dereferencing it while a remount replaces them: BUG: KASAN: slab-use-after-free in ntfs_nls_to_utf16+0x7ae/0x7c0 Read of size 8 at addr ff110001044fd448 by task walker/98 Call Trace: ntfs_nls_to_utf16+0x7ae/0x7c0 ntfs_d_hash+0x22b/0x500 link_path_walk+0x11ad/0x1d30 path_lookupat+0x63/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 [...] Allocated by task 95: __kmalloc_node_track_caller_noprof+0x2a2/0x730 kmemdup_noprof+0x25/0x50 ntfs_fill_super+0x1e5/0x4550 [...] Freed by task 97: kfree+0x1db/0x5b0 put_fs_context+0x13c/0x7d0 path_mount+0x54a/0x2130 __x64_sys_mount+0x20c/0x270 That info is needed in rcu lookup in the dentry hash and dentry compary methods for ntfs3 and causes a UAF today. Delay freeing with an rcu grace period. ntfs_nls_to_utf16() reads ->nls and ->ads once under rcu_read_lock() so the hooks pair with the release in ntfs_fs_reconfigure(). That also covers callers outside of rcu pathwalk such as ntfs_lookup(). They don't hold rcu_read_lock() themselves and wouldn't be protected by the grace period otherwise. Remount refuses to change the iocharset so ->nls stays valid after rcu_read_unlock(). Fixes: a3a956c78efa ("fs/ntfs3: Add option "nocase"") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-8-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) [ sashal: Dropped the ads snapshot and its later use in ntfs_nls_to_utf16() because the ADS option and delimiter code don't exist here, keeping only the RCU snapshot of nls. ] Signed-off-by: Sasha Levin commit 4aef6ceb4d6acacd53bc047ac4849677c3edbec1 Author: Christian Brauner Date: Fri Oct 9 23:51:55 2026 +0200 ipc: drop the mqueue mount with kern_unmount() on setup failure [ Upstream commit f0e48172a59e517e613b73f73cc35f24fd123aeb ] mq_init_ns() creates the mqueue mount with fc_mount_longterm(), so its ->mnt_ns is MNT_NS_INTERNAL. When setting up the mqueue or ipc sysctls or msg_init_ns() fails afterwards, create_ipc_ns() drops it with a plain mntput(). With ->mnt_ns set that takes the fast path of mntput_no_expire(). The count drops to zero and nothing ever kills the mount, so the mount and the mqueue superblock are leaked. Commit dc55e35f9e81 ("ipc: Store mqueue sysctls in the ipc namespace") added the first failure path after mq_init_ns() and never dropped the mount. Commit 7229d74e5e8c ("ipc: create_ipc_ns: drop mqueue mount on sysctl setup failure") tried to fix that with a mntput() but that doesn't help for a long-term mount. Use kern_unmount(). free_ipc() open-codes the same thing for a namespace that made it. Fixes: dc55e35f9e81 ("ipc: Store mqueue sysctls in the ipc namespace") Fixes: 7229d74e5e8c ("ipc: create_ipc_ns: drop mqueue mount on sysctl setup failure") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261009-work-fixes-rcu-v1-5-7446d2d335e6@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 73309ca08e71b8a26e94220debe4ae5831519cc5 Author: Vlad Kulikov Date: Tue Oct 21 21:13:39 2025 +0300 ipc: create_ipc_ns: drop mqueue mount on sysctl setup failure [ Upstream commit 7229d74e5e8c1f140529d405c88d4493e37ce4e3 ] If setup_mq_sysctls(ns) fails after mq_init_ns(ns) succeeds, the error path skipped releasing the internal kernel mqueue mount kept in ns->mq_mnt. That leaves the vfsmount/superblock referenced until final namespace teardown, i.e. a resource leak on this rare failure edge. Unwind it by calling mntput(ns->mq_mnt) before dropping user_ns and freeing the IPC namespace. This mirrors the normal ordering used in free_ipc_ns(). Link: https://lkml.kernel.org/r/20251021181341.670297-1-vlad_kulikov_c@pm.me Signed-off-by: Vlad Kulikov Reviewed-by: Jan Kara Cc: Aleksa Sarai Cc: Christian Brauner Cc: David Hildenbrand Cc: Ma Wupeng Signed-off-by: Andrew Morton Stable-dep-of: f0e48172a59e ("ipc: drop the mqueue mount with kern_unmount() on setup failure") Signed-off-by: Sasha Levin commit 16c95870c95f2a3d78c81b9fbc0645f4b7178c11 Author: Igor Paunovic Date: Sat Sep 5 17:04:32 2026 +0200 accel/rocket: search every core slot when looking up a scheduler [ Upstream commit 89c2c777df17eb0201c8e22afabbf3691f2a28fe ] sched_to_core() walks rdev->cores[] up to rdev->num_cores, and rocket_remove() decrements num_cores for every core it removes. Unbind a core that is not the last one and the cores behind it fall outside the search, so sched_to_core() returns NULL for a core that is still bound and still running jobs. Neither caller checks the result: rocket_job_run(): rocket_fence_create(core), core->dev rocket_job_timedout(): dev_err(core->dev, "NPU job timed out") Unbinding the middle core of the three on an RK3588 while three clients are submitting to all of them faults twice, once from the surviving core's job queue and once from its reset work: KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched] pc : rocket_job_run+0x234/0x838 [rocket] Call trace: rocket_job_run+0x234/0x838 [rocket] drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched] process_one_work+0x640/0x14f0 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched] pc : rocket_job_timedout+0xf0/0x1e0 [rocket] Call trace: rocket_job_timedout+0xf0/0x1e0 [rocket] drm_sched_job_timedout+0x188/0x6a0 [gpu_sched] Both are the third core: the workqueue names are its device and its core->index, and it was left at slot 2 while num_cores had dropped to 2. Search all the slots that were allocated, the way find_core_for_dev() now does. A core that is still bound is then found, and the two callers get the pointer they already assume they have. This does not make unbinding one core out of several safe. An open client keeps an entity pointing at the scheduler of the core that went away: drm_sched reports it as not ready for every job that lands on it, and the client waits in dma_fence_default_wait for a fence that will never signal. Stopping the NULL dereference is what belongs in a fix; the rest wants more thought. Reported-by: Sidong Yang Closes: https://lore.kernel.org/dri-devel/apwUewaRnoTNXHCt@rock-5b-plus/ Fixes: 0810d5ad88a1 ("accel/rocket: Add job submission IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Igor Paunovic Assisted-by: LLM sparse checkpatch Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260905150432.7477-1-royalnet026@gmail.com Signed-off-by: Sasha Levin commit 5684a6c24c0d7c40ef2c4ccb3e4a64cffe76a791 Author: Hari Mishal Date: Wed Sep 16 16:23:32 2026 +0200 drm/amd/display: guard dc_sink dereferences in MST mode validation [ Upstream commit 217f64f348c90cba62164e7ff38e0ccf78a5ca09 ] dm_dp_mst_is_port_support_mode() reads aconnector->dc_sink->dsc_caps... for the DSC branch-throughput check, and get_conv_frl_bw()'s HDMI-PCON FRL-bandwidth path reads aconnector->dc_sink->edid_caps.max_frl_rate, both without a NULL check. dc_sink is cleared asynchronously on MST unplug, and both functions run from paths that the driver's own comments document as racing that teardown: the connector probe worker's ->mode_valid callback and a compositor's atomic check, neither of which holds the MST manager lock that the teardown path uses. The former does have an existing dsc_aux NULL check, but dsc_aux isn't reliably cleared in every path that clears dc_sink, so it doesn't cover this. Fail the port-support check and skip the FRL conversion path when the sink is already gone. Fixes: f04d275d94e1 ("drm/amd/display: add mst port output bw check") Fixes: 5c9b8b27a883 ("drm/amd/display: Tie FRL support into amdgpu_dm") Assisted-by: gkh_clanker_t1000 Signed-off-by: Hari Mishal Reviewed-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 7c3db8da4e039698ae198c870712428644e965c7) Cc: stable@vger.kernel.org [ sashal: Dropped the FRL hunk because the HDMI 2.1 FRL code isn't present, and applied only the dc_sink NULL check in dm_dp_mst_is_port_support_mode(). ] Signed-off-by: Sasha Levin commit 81a1c7eba334786aed6806a29699bd284fc12029 Author: Alex Deucher Date: Fri Sep 25 13:46:19 2026 -0400 drm/amdgpu/gmc12: properly pass flush_type to gmc_v12_0_flush_vm_hub() [ Upstream commit 0bfb1bfc82e8fa386d4fad1caa5812b6afafa626 ] In gmc_v12_0_flush_gpu_tlb(), flush_type was not properly passed to gmc_v12_0_flush_vm_hub(). This only affected the MMIO path. In most cases the flush would go through MES. Reviewed-by: Mukul Joshi Signed-off-by: Alex Deucher (cherry picked from commit 6498e33f22a12fdc759a0c78bfe0547819277a36) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 84cc155bf4cd4ab518bb91b517c1b760b0de6c04 Author: Pierre-Eric Pelloux-Prayer Date: Mon Sep 15 14:25:44 2025 +0200 drm/amdgpu: remove gart_window_lock usage from gmc v12 [ Upstream commit c79cf5a7d903a16459846b4296fc3cd988837c54 ] This lock was part of the SDMA workaround originally implemented in gmc_v10_0_flush_gpu_tlb (a70cb2176f7ef6f moved it to amdgpu_gmc_flush_gpu_tlb). This means this lock is useless and be safely dropped. Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Signed-off-by: Alex Deucher Stable-dep-of: 0bfb1bfc82e8 ("drm/amdgpu/gmc12: properly pass flush_type to gmc_v12_0_flush_vm_hub()") Signed-off-by: Sasha Levin commit bdb5784531b2148f00a5ff5df0fc61bceebf4525 Author: Timur Kristóf Date: Wed Sep 23 14:20:31 2026 +0200 drm/amd/display: Fix fast updates on DCE 6.x [ Upstream commit 88427119e1f039c8cdffd63726c136a986ef519f ] DCE6 should use legacy fast updates, just like all DCE8 - DCN2. Set that flag for DCE 6.0, 6.1 and 6.4 (all DCE6 versions). Technically DCE6 should have been included when the fast update code was refactored, but it just happened to work until now. A recent commit "Attach only plane updates that actually changed" has exposed this issue because with that commit, DC accidentally took the new fast update code path for DCE6 as well, which caused it to boot into a black screen with a flip done timeout. This fix should be backported to all kernel versions that have "Refactor fast update to use new HWSS build sequence", but this patch won't apply cleanly to older kernels due to another refactor in "Remove dc param from check_update". Fixes: 0baae6246307 ("drm/amd/display: Refactor fast update to use new HWSS build sequence") Fixes: 9ec11bb842b6 ("drm/amd/display: Remove dc param from check_update") Signed-off-by: Timur Kristóf Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20260923122033.1046651-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 698fda6e360625850413a2d1a90b72ae5f03073d) Cc: stable@vger.kernel.org [ sashal: Replaced the missing dc_check_config flag with dc->debug = debug_defaults, setting enable_legacy_fast_update = true in the DCE6 constructors, and adjusted the dce64_construct context because is_apu was already removed. ] Signed-off-by: Sasha Levin commit 352c5f5b995ebef1cb6a8a469df57d064268dcc5 Author: Ali Ahmet Memis Date: Thu Jul 30 06:00:31 2026 +0300 tools/power turbostat: Read complete CPU lists [ Upstream commit c24362650f7a8573dc9a9991a034b8500af8eb19 ] CPU_SUBSET_MAXCPUS accepts CPU IDs through 8191, but the sysfs and cgroup CPU-list readers stop at 1024 bytes. A fragmented cpuset or hybrid PMU CPU list can exceed that size and be truncated. initialize_cpu_set_from_sysfs() can also pass a full, non-NUL-terminated buffer to parse_cpu_str(), causing an out-of-bounds read. Additionally, initialize_cpu_set_from_sysfs() returns with the file still open on success. It is now called once per CPU for thread_siblings_list, so large systems can leak thousands of descriptors during topology discovery. Use getline() so both readers receive a complete, NUL-terminated line. Close and free the sysfs CPU-list resources on every path, and report malformed input from the correct buffer. Fixes: eb187540d13a ("tools/power turbostat: Increase CPU_SUBSET_MAXCPUS to 8192") Fixes: 58839fdbd441 ("tools/power turbostat: Process HT siblings in CPU order") Cc: stable@vger.kernel.org Signed-off-by: Ali Ahmet Memis Signed-off-by: Len Brown [ sashal: Dropped the initialize_cpu_set_from_sysfs() hunk because that function doesn't exist here, and adapted the update_effective_str() context, where the err() message still had a trailing \n. ] Signed-off-by: Sasha Levin commit 850d8d4b2715185ec5cc461aa5ba93572ceb8539 Author: Paulo Alcantara Date: Mon Sep 28 10:23:00 2026 -0300 smb: client: require stable pages for signed connections [ Upstream commit 53c5c2c1095eb21e214811fec16cd75f89d72ee2 ] When signing, cifs computes the SMB signature over the pagecache folios in place and then hands those same folios to the socket. If a buffered write mutates a folio while a write subrequest is still in flight, the signature no longer matches the data that follows it, the server rejects the write with STATUS_ACCESS_DENIED (-EACCES), and the error is latched in the mapping, so the next fsync()/fallocate() returns -EIO. Mark the mapping for stable writes so netfs_perform_write() waits for writeback to complete before modifying an in-flight folio. This is only needed when the connection is signed. Fixes: 3ee1a1fc3981 ("cifs: Cut over to using netfslib") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Replaced upstream's tcon->ses->server->sign with cifs_sb_master_tcon(cifs_sb)->ses->server->sign, because cifs_set_ops() has no tcon local variable in this tree. ] Signed-off-by: Sasha Levin commit 7448dcaaf747e89dce902f453ce5f8b6a30b0113 Author: Paulo Alcantara Date: Sat Sep 26 17:15:47 2026 -0300 smb: client: only require read lease for size-extending zero range [ Upstream commit fafc68cccf8a00ed0a1f47c1413a3f16ce4dcdfa ] smb3_zero_range() refuses any FALLOC_FL_ZERO_RANGE that clears FALLOC_FL_KEEP_SIZE with -EOPNOTSUPP whenever the inode is not read caching: /* if file not oplocked can't be sure whether asking to extend size */ rc = -EOPNOTSUPP; if (keep_size == false && !CIFS_CACHE_READ(cifsi)) goto zero_range_exit; The read lease is only needed to trust the cached i_size when deciding whether the range extends the file. When it is not held, the size can instead be fetched from the server, which is authoritative, rather than refusing the request outright: query the server's end of file and take the larger of it and the cached size for the interior-vs-extend decision. The larger of the two is used because the server's end of file reflects another client's growth while the cached size reflects this client's own writes that may not have reached the server yet; using the server size alone would wrongly shrink the file when the range flush above left an extending write unwritten. The query isn't lease-protected either, so its result is only trusted to confirm the range is interior, never to justify extending: if it still shows the range going past EOF, refuse with -EOPNOTSUPP instead of calling SMB2_set_eof(), which could otherwise shrink the file if another client extended it further between the query and the call. For the same reason, take the larger of the already-computed i_size and a fresh i_size_read(inode) right before that call, instead of relying on either alone: the local variable carries the query's result, which is never written back to the inode, while a concurrent write on this client can still extend the cached i_size during the flush, the query, or the zero-data round trip that happen in between. Rejecting interior ranges is observed as generic/363 randomly failing against Windows Server with do_zero_range: fallocate: Operation not supported fsx issues an interior, non-KEEP_SIZE zero range while the inode is transiently not read caching: the server had just downgraded the file's lease from RWH to RH after breaking the write caching, and the ensuing handle reopen/revalidation left CIFS_CACHE_READ momentarily clear. The range sat well within the server's end of file, so no extend was needed, yet the range was refused and fsx aborted. This keeps the emulation correct even when a genuine lease break from another client leaves the inode without read caching -- the case the -EOPNOTSUPP guard turned into a hard failure. The extra round trip only happens on the no-lease path; the common cached case is unchanged. Fixes: 30175628bf7f ("[SMB3] Enable fallocate -z support for SMB3 mounts") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Declared only remote_i_size in smb3_zero_range() since this tree lacks the netfs_read_sizes() that upstream uses to fill i_size and remote_i_size. ] Signed-off-by: Sasha Levin commit e97dac26ed2cce04f9d159cc99e1eca828c5d49e Author: Paulo Alcantara Date: Sat Sep 26 13:04:44 2026 -0300 smb: client: drain and invalidate before server-side copy/clone [ Upstream commit c9b1194e8ec99d95db25db45edd2fbf690f043ab ] cifs_file_copychunk_range() and the clone (FICLONE) path of cifs_remap_file_range() do not serialise the destination page cache against the server-side copy the way the other server-side range operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range() and smb3_insert_range()) do. cifs_file_copychunk_range() invalidates the destination range with filemap_invalidate_inode(), which takes and drops the mapping's invalidate_lock internally, so the lock is no longer held when the copychunk ioctl is issued. It also never drains in-flight netfs I/O on the target. The clone path never takes the invalidate_lock at all (only i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not drain outstanding I/O. As a result an asynchronous destination writeback can complete after the server-side copy/clone has run and reinstate stale data over the region just written by the server, corrupting the file. This is the same class of corruption as commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole") and has been seen randomly in generic/363 against Windows Server. Fix both paths to follow the established ordering: hold the target mapping's invalidate_lock across the flush and invalidation of the destination and the server ioctl, and call netfs_wait_for_outstanding_io() on the target to drain in-flight writes before the ioctl is issued. Only the target inode's invalidate_lock is required, as the source is merely flushed and not invalidated; i_rwsem (already held via lock_two_nondirectories()) is acquired before the invalidate_lock, matching the VFS lock ordering. Since filemap_invalidate_inode() takes that same lock internally, replace it with its own unmap/flush/invalidate steps instead of calling it, and return early on a zero-length copy to avoid a range underflow. Fixes: 8101d6e112e2 ("cifs: Fix copy offload to flush destination region") Fixes: c54fc3a4f375 ("cifs: Fix flushing, invalidation and file size with FICLONE") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Adjusted context in cifs_remap_file_range() because the local i_size variable is absent, so the new netfs_wait_for_outstanding_io() call follows the truncate_inode_pages_range() call that uses i_size_read(). ] Signed-off-by: Sasha Levin commit 7beb2f2a58023b2ff28fd52bdb72bed74257ee04 Author: Paulo Alcantara Date: Sun Sep 20 16:38:03 2026 -0300 smb: client: discard post-EOF pagecache when extending a file via clone range [ Upstream commit 4721587f96cb8de8164f3fd203093a0875560999 ] cifs_remap_file_range() discarded the pagecache only for the folios overlapping the destination region, so when a clone extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended. Start the discard at the smaller of fstart and the old EOF. i_size is still old here, so nothing past the old EOF is flushed to the server. Fixes: c54fc3a4f375 ("cifs: Fix flushing, invalidation and file size with FICLONE") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Replaced the missing local i_size with (unsigned long long)i_size_read(target_inode) in the min() that bounds the pagecache discard, since the earlier refactor that adds i_size is absent. ] Signed-off-by: Sasha Levin commit 0f79506b36735822d218d5ba9e2abde1f3584884 Author: Paulo Alcantara Date: Sun Sep 20 15:05:44 2026 -0300 smb: client: clear post-EOF pagecache when extending a file via truncate [ Upstream commit 35024595f641e790e24609f3f046e1667e3b280a ] cifs_setsize() relied on pagecache_isize_extended() to zero the tail of the folio straddling the old EOF, but that helper is a no-op on CIFS (i_blkbits is 14), so data dirtied past EOF through an mmap survived and became visible once the file was extended. Use netfs_clear_stale_post_isize() instead, called after i_size is updated since cifs_setsize() callers hold i_rwsem exclusively for the whole resize. truncate_pagecache() is then called as in truncate_setsize(): a no-op on extend, and it drops the pagecache beyond the new EOF on shrink. Also thread old_size as an explicit parameter through cifs_setsize() and cifs_resize_file_locked(), captured by each caller before its own resize RPC. This closes a race where a concurrent stat() could adopt the RPC's already-updated server size via is_size_safe_to_change() before cifs_setsize() reads old_size itself. Closes: https://sashiko.dev/#/patchset/20260921230755.1133425-1-pc%40manguebit.org Fixes: c510edb9734a ("cifs: call pagecache_isize_extended() in cifs_setsize() when extending") Reviewed-by: David Howells Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Christian Brauner Cc: Matthew Wilcox Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Dropped the old_size local in cifs_setsize() (now a parameter) and kept this tree's plain i_blocks assignment, since it lacks the u64 blocks local and shrink-clamp context the patch expects. ] Signed-off-by: Sasha Levin commit 2fc1ffb15efd423ea8476abb54910a6f55945659 Author: Jakub Gawlik Date: Wed Sep 30 16:58:39 2026 +0200 ALSA: hda/realtek: Add micmute LED quirk for Acer Swift SFG16-72 [ Upstream commit 819f6aacbb1d1621c6a62721e708835fe1fb75d8 ] The Acer Swift SFG16-72 (1025:173b) uses the ALC245 codec, but its mic-mute LED is not enabled by default. Apply the existing ALC245_FIXUP_ACER_MICMUTE_LED quirk to enable the mic-mute LED. Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Jakub Gawlik Link: https://patch.msgid.link/20260930145839.374762-1-jakubgawlik13@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6faf87bc7331684d55226603bd552a3eaf7740d4 Author: Zhang Heng Date: Mon Feb 9 21:41:49 2026 +0800 ALSA: hda/realtek: add quirk for Acer Nitro ANV15-51 [ Upstream commit aa4876fe2d9fcbcaa0592b25f34ec6f6ea7876c1 ] fix mute/micmute LEDs and headset microphone for Acer Nitro ANV15-51. [ The headset microphone issue is solved by Kailang] Link: https://bugzilla.kernel.org/show_bug.cgi?id=220279 Cc: stable@vger.kernel.org Signed-off-by: Zhang Heng Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260209134149.3076957-1-zhangheng@kylinos.cn Stable-dep-of: 819f6aacbb1d ("ALSA: hda/realtek: Add micmute LED quirk for Acer Swift SFG16-72") Signed-off-by: Sasha Levin commit 5d06e2f861d61a03481348378fdf9cc3e68bff47 Author: Sean Christopherson Date: Fri Sep 4 10:06:40 2026 -0700 KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded [ Upstream commit e27fc915c8f575ab5630e27d97465c2077d4b9d1 ] Leave control.erap_ctl and control.clean as-is in the VMCS if VMRUN fails, because as per AMD: there's no explicit architectural guarantee about the behavior in the presence of VMRUN failures. So the best thing to do would be to assume that if VMRUN fails, the actions requested in the control fields may not have been performed. Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-ID: <20260904170642.3291466-3-seanjc@google.com> Signed-off-by: Paolo Bonzini [ sashal: Dropped the ERAPS hunk because the tree lacks ERAPS support, so only the vmcb_mark_all_clean() move into the VMRUN-succeeded block is applied. ] Signed-off-by: Sasha Levin commit f2bd7cf6a83e49c710e2b93d3064fa0ebb7e0006 Author: Sean Christopherson Date: Fri Sep 4 10:06:39 2026 -0700 KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN [ Upstream commit 60d93c27859fb3ec5b5a689e24de303f166477d0 ] Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN, as empirical testing shows that the CPU performs the requested TLB flush if and only if VMRUN is successful, i.e. clearing TLB control on a failed VMRUN effectively drops a TLB flush. Explicitly track the need to flush all ASIDs on a per-CPU basis, as the ASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus, this also obviates the need to avoid clobbering FLUSH_ALL_ASID with TLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid(). Deliberately don't bother saving/restoring the "old" tlb_ctl on failure, in quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from after pre_svm_run(), but before updating tlb_ctl for flush_all_asids. If VMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next successful run of the VMCB *may* unnecessarily flush all ASIDs, which strictly speaking could result in noisy neighbor issues. However, the fact that new_asid() is already guest-triggerable, because of KVM's flawed behavior of clearing the ASID on emulated INIT, means that a guest can already trigger a flush of all ASIDs at roughly the same rate. And once KVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID to each vCPU, this flaw goes away. Fixes: 38e5e92fe8c0 ("KVM: SVM: Implement Flush-By-Asid feature") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Suggested-by: Yosry Ahmed Cc: Tom Lendacky Cc: Jim Mattson Signed-off-by: Sean Christopherson Message-ID: <20260904170642.3291466-2-seanjc@google.com> Signed-off-by: Paolo Bonzini [ sashal: Replaced the svm_is_vmrun_failure() helper with an exit_code != SVM_EXIT_ERR check and dropped the ERAPS CLEAR_RAP context block, since neither exists in this tree. ] Signed-off-by: Sasha Levin commit d4f2168ee9104d7c98154104c52e681e4c1787db Author: Ilya Maximets Date: Mon Sep 21 16:55:47 2026 +0200 net/sched: act_ct: remove 'add_helper' dead code [ Upstream commit 00df72e39f306e2f7adb68528a5c92109da6a0a9 ] This variable can only become 'true' when the connection is not confirmed, but it is only checked when it is confirmed. So, it can be treated as being always false and just removed. Fixes: a21b06e73191 ("net: sched: add helper support in act_ct") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Reviewed-by: Xin Long Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20260921145655.3167436-6-i.maximets@ovn.org Signed-off-by: Jakub Kicinski [ sashal: Adapted the condition change to the branch's reordered helper block, since the context lines no longer matched, while keeping the branch's existing ordering and comment. ] Signed-off-by: Sasha Levin commit 908bc440a285d4db2b17b58267b7de21fd48d153 Author: Sean Christopherson Date: Mon Sep 21 14:16:08 2026 -0700 KVM: x86: Fill kvm_run exit fields in common get_nested_state_pages() error paths [ Upstream commit c1214f293d77c6e425a379f90d09bdb4815993a8 ] Fill kvm_run with "internal error, emulation" in the common error handling paths for getting nested state pages, as requiring each check to manually fill kvm_run is error prone and requires a non-trivial amount of copy+paste. Specifically, both SVM and VMX fail to fill kvm_run if load_pdptrs() fails, and SVM fails to fill kvm_run if kvm_hv_verify_vp_assist() fails. If those flows fail, the *best* case scenario is that KVM will exit to userspace with KVM_EXIT_UNKNOWN. The worst case scenario is that KVM exits with a stale exit_reason and confuses userspace. Note, SVM never exits to userspace if something goes sideways when dealing with vmcb12 assets while emulating VMRUN, i.e. lack of SVM-specific code is not a bug. Fixes: 0f85722341b0 ("KVM: nVMX: delay loading of PDPTRs to KVM_REQ_GET_NESTED_STATE_PAGES") Fixes: 232f75d3b4b5 ("KVM: nSVM: call nested_svm_load_cr3 on nested state load") Fixes: 3f4a812edf5c ("KVM: nSVM: hyper-v: Enable L2 TLB flush") Cc: stable@vger.kernel.org Reported-by: Jinwoo Lee Closes: https://lore.kernel.org/all/20260813043932.3214460-1-rkskek9254@gmail.com Reported-by: Stefan Teodorescu Link: https://patch.msgid.link/20260921211608.1030158-3-seanjc@google.com Signed-off-by: Sean Christopherson [ sashal: Kept this tree's vmx->nested.nested_run_pending in the vmentry_failed: context line, since the field has not yet moved to vcpu->arch. ] Signed-off-by: Sasha Levin commit 59d30bdc3dd6fd3a8990f59bc7a137b1cbb3ed4e Author: Adarsh Das Date: Sat Sep 19 16:27:32 2026 +0530 smb: client: delete compound mids on send failure before unlock [ Upstream commit 8f6f8a48399f82f4a83f7b9f25b9707e0062a4f9 ] When sending a compound request fails, smb_send_rqst() kicks off a reconnect. compound_send_recv() still has those mids on pending_mid_q, but it unlocks the server without removing them first. During reconnect, cifs_abort_connection() walks pending_mid_q and runs each mid callback. With no response yet, those callbacks return credits and drop in_flight. Then compound_send_recv()'s send-error path returns the same credits again. in_flight ends up decremented twice and smb2_add_credits() WARNs. syzbot hits this during SMB2_negotiate when the socket send fails. cifs_call_async() already calls delete_mid() before unlock on send failure. Do the same for compound chains and set cancelled_mid[] so the out: path does not delete them again. Fixes: ee258d79159a ("CIFS: Move credit processing to mid callbacks for SMB3") Reported-by: syzbot+eeb58d2197d88720a228@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/6a727d22.40259c87.584f4.04ce.GAE@google.com Tested-by: syzbot+eeb58d2197d88720a228@syzkaller.appspotmail.com Assisted-by: LLM Cc: stable@vger.kernel.org Signed-off-by: Adarsh Das Signed-off-by: Paulo Alcantara Signed-off-by: Sasha Levin commit 3c97f7cb6c48826663648b6081b614c2befc8ac7 Author: David Francis Date: Wed Aug 5 09:16:51 2026 -0400 drm/amdkfd: Avoid integer underflow in EOP ring size calculation. [ Upstream commit 8ee521b8b189799e361d4233c5180ba56656d4d4 ] 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: Sasha Levin commit 9e8f43579f849fba0dd1059160f50bd44a767366 Author: David Francis Date: Wed Aug 5 09:51:35 2026 -0400 drm/amdkfd: Avoid integer underflow with ffs in EOP ring size calc [ Upstream commit c883d0a132d430ef7ebb23fd94323be94d0fbdb8 ] 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 [ sashal: Dropped the hunk for the GFX 12.1 MQD manager file since it doesn't exist in this tree, so only the v10, v11 and v12 changes are applied. ] Signed-off-by: Sasha Levin commit 2f16636913db49afa65d36324cc8187c76e0b567 Author: Xiaogang Chen Date: Tue Jun 16 17:18:59 2026 -0500 drm/amdkfd: Guard m->cp_hqd_eop_control setting by q->eop_ring_buffer_size [ Upstream commit 8cd2ea7bab77b7aa087b1a6cc26d2df03c2a6ed9 ] To avoid wraparound if the value is 0. Signed-off-by: Xiaogang Chen Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit c0cae35661868af207077a4306bc42c7c972947c) Cc: stable@vger.kernel.org Stable-dep-of: c883d0a132d4 ("drm/amdkfd: Avoid integer underflow with ffs in EOP ring size calc") Signed-off-by: Sasha Levin commit 2548c31f3a194e9d6b69c2b050daf7bbac7ce02f Author: Darrick J. Wong Date: Mon Sep 14 22:37:36 2026 -0700 xfs: don't cross reference rmapbt with bitmaps if they're incomplete [ Upstream commit d7b92cbe566f6fe54368f62e4b515d9f80c43a18 ] LOLLM points out that runtime errors (e.g. ENOMEM) when we're trying to compute space usag bitmaps are silently dropped by the rmapbt scrubber. We ought to flag that as an incomplete scrub instead of reporting cross-referencing errors based on faulty data. Cc: stable@vger.kernel.org # v6.4 Fixes: fed050f3452da0 ("xfs: cross-reference rmap records with ag btrees") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit 9044683dfdc40ec7c6457137199704426eb21e98 Author: Zongmin Zhou Date: Wed Aug 26 14:41:17 2026 +0800 RISC-V: KVM: Fix sdata leak and stale snapshot_addr in snapshot_set_shmem [ Upstream commit b7749531a9b195f4fd7db92ca3cc49bda1a4dc8d ] A guest may call SBI_PMU_SNAPSHOT_SET_SHMEM repeatedly. Each call overwrites kvpmu->sdata without freeing the old buffer (memory leak), and if a later kvm_vcpu_write_guest() fails, the error path frees sdata but leaves snapshot_addr stale. A subsequent SBI_PMU_COUNTER_START then passes the INVALID_GPA check and crashes the host with a NULL buffer in kvm_vcpu_read_guest(). Fix this by clearing the previously installed snapshot area before installing a new one, which keeps sdata and snapshot_addr consistent. The SBI spec suggests a single invocation but defines no error code for repeated calls, so KVM must tolerate them. Fixes: c2f41ddbcdd756 ("RISC-V: KVM: Implement SBI PMU Snapshot feature") Cc: stable@vger.kernel.org Signed-off-by: Zongmin Zhou Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260826064117.58029-1-min_halo@163.com Signed-off-by: Anup Patel [ sashal: Kept the existing GFP_ATOMIC in the kzalloc context line, since __GFP_ACCOUNT isn't present here, and added the snapshot-area clear block unchanged. ] Signed-off-by: Sasha Levin commit 969825a50f58b64833edb8fda07b042a2360dc9c Author: Xie Bo Date: Mon Aug 10 13:15:43 2026 +0800 RISC-V: KVM: Release unused page after MMU invalidation [ Upstream commit ed54fdb460a6e81d5f8f38388d1f10b385dd4a58 ] If an MMU invalidation races with a G-stage fault, the fault handler skips installing the page but leaves ret set to zero. As a result, kvm_release_faultin_page() treats the page as used and can unnecessarily mark it dirty. Track the invalidation retry separately and release the page as unused, while preserving the existing return value so that the vCPU retries the fault. Fixes: 2ed90cb0938a ("KVM: RISC-V: Retry fault if vma_lookup() results become invalid") Cc: stable@vger.kernel.org Signed-off-by: Xie Bo Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260810051544.3953925-2-xb@ultrarisc.com Signed-off-by: Anup Patel [ sashal: Dropped the is_hugetlb context line and used spin_lock/spin_unlock on mmu_lock instead of write_lock/write_unlock, so the unused flag hunks apply to this tree's older kvm_riscv_mmu_map(). ] Signed-off-by: Sasha Levin commit 19b0188d02630f71ec0605f1ed0e141ee1fac2cb Author: Paulo Alcantara Date: Sun Sep 13 21:15:41 2026 -0300 smb: client: fix fattr leaking on wsl_to_fattr() failure [ Upstream commit e1253a82bb4c0fed6706a5839fc8b6e01be1abe2 ] 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 [ sashal: Reordered context in the first hunk: the three setup assignments appear in a different order, so I removed them and added the local mode initialization. ] Signed-off-by: Sasha Levin commit b057eb6ab8005c415fb9d92811f8a1fc07d4363f Author: Mahmoud Nagy Adam Date: Wed Sep 9 15:26:03 2026 +0200 selftests: ublk: install test_common.sh and trace/ scripts [ Upstream commit c4fa55f85c47cd5d54d717fb8170746edb10292e ] Every ublk test script sources test_common.sh from its own directory: . "$(cd "$(dirname "$0")" && pwd)"/test_common.sh and test_generic_02/12 additionally run bpftrace against the scripts in trace/. Neither test_common.sh nor trace/ is listed in TEST_FILES, so "make install" does not copy them into the install directory and every ublk test fails when run from there: ./test_generic_02.sh: line 4: .../kselftest_install/ublk/test_common.sh: No such file or directory ./test_generic_02.sh: line 8: _have_program: command not found The bpftrace tests are affected even when bpftrace is installed: the missing trace/*.bt makes bpftrace exit immediately, and the tests then report a skip rather than a failure, which hides the problem. Add both to TEST_FILES, matching how other selftests ship their sourced helpers (see kexec/kexec_common_lib.sh and zram/zram_lib.sh). Fixes: 6aecda00b7d1e1 ("selftests: ublk: add kernel selftests for ublk") Fixes: 723977cab4c0fd ("selftests: ublk: add generic_01 for verifying sequential IO order") Cc: stable@vger.kernel.org # v6.15+ Assisted-by: Kiro:claude-opus-5 Signed-off-by: Mahmoud Nagy Adam Reviewed-by: Ming Lei Link: https://patch.msgid.link/20260909132602.68852-2-mngyadam@amazon.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 59d9b928e7a9f2d3f142cb328a7701ce89f955a8 Author: Ming Lei Date: Fri Jan 16 22:18:55 2026 +0800 selftests: ublk: increase timeout to 150 seconds [ Upstream commit 4968fb7cc60676040258c8867f22931c8735126f ] More tests need to be covered in existing generic tests, and default 45sec isn't enough, and timeout is often triggered, increase timeout by adding setting file. Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Stable-dep-of: c4fa55f85c47 ("selftests: ublk: install test_common.sh and trace/ scripts") Signed-off-by: Sasha Levin commit 5531d09ec91c7a2db651db1dc34a83643a3e49e7 Author: Caleb Sander Mateos Date: Thu Jan 8 02:19:41 2026 -0700 selftests: ublk: add utility to get block device metadata size [ Upstream commit 261b67f4e34716e793b0b95d2722b2fe780ed5f4 ] Some block device integrity parameters are available in sysfs, but others are only accessible using the FS_IOC_GETLBMD_CAP ioctl. Add a metadata_size utility program to print out the logical block metadata size, PI offset, and PI size within the metadata. Example output: $ metadata_size /dev/ublkb0 metadata_size: 64 pi_offset: 56 pi_tuple_size: 8 Signed-off-by: Caleb Sander Mateos Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Stable-dep-of: c4fa55f85c47 ("selftests: ublk: install test_common.sh and trace/ scripts") Signed-off-by: Sasha Levin commit c70f93046f59cd98d02725e227cf967f93d86413 Author: Ming Lei Date: Tue Dec 23 11:27:42 2025 +0800 selftests/ublk: fix Makefile to rebuild on header changes [ Upstream commit a2ce133969175d36d708b7c76536b375d0522e53 ] Add header dependencies to kublk build rule so that changes to kublk.h, ublk_dep.h, or utils.h trigger a rebuild. Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Stable-dep-of: c4fa55f85c47 ("selftests: ublk: install test_common.sh and trace/ scripts") Signed-off-by: Sasha Levin commit 6ba19e15b3e17f0493ec7f8cd4a1c2bbf4e6ba1e Author: Kevin Wang Date: Wed Aug 26 09:51:55 2026 +0800 drm/amd/pm: fix gpu metrics energy accumulator for smu 13.0.0/13.0.7 [ Upstream commit 13ddcc7acb9adbed7627e952a61d1d62cd9546fc ] GPU metrics v1.3 defines energy_accumulator as a 64‑bit field. The unsupported‑firmware code path assigns UINT_MAX, which is neither the full‑width invalid value for this field nor its default value. Fixes: 8de9edb35976 ("drm/amd/pm: remove invalid gpu_metrics.energy_accumulator on smu v13.0.x") Signed-off-by: Kevin Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit c2b948c4fe16eb13d98ff5d1371956cb2f55cdc6) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d521b90533d080636422eec26d0a37f7eed0637e Author: Arie Miller Date: Thu Sep 3 22:21:29 2026 -0400 hwmon: (asus_rog_ryujin) Synchronize HID command and report handling [ Upstream commit 06d48355bf41028c1321acda6a4391cd70098be8 ] rog_ryujin_execute_cmd() holds status_report_request_lock while reinitializing a completion, intending to exclude raw-event handling. However, rog_ryujin_raw_event() does not acquire the lock when it updates the completion. A response can therefore race with reinit_completion() and be lost, leaving the command to time out. Hold the lock while parsing reports and updating their completions. Use the irqsave variants in both paths because raw-event handling may run in interrupt context. Fixes: ed3e03790c5c ("hwmon: Add driver for ASUS ROG RYUJIN II 360 AIO cooler") Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260812104617.858D01F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol sparse Signed-off-by: Arie Miller Link: https://patch.msgid.link/20260904022129.97896-3-renari@arimil.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 49cc6d5c00a7f75540d1a4324e01be4067ee652c Author: Arie Miller Date: Thu Sep 3 22:21:28 2026 -0400 hwmon: (asus_rog_ryujin) Validate HID report lengths [ Upstream commit 8042312e73c50de82634ce63eae7cf219464b481 ] rog_ryujin_raw_event() parses response headers and payload fields without first checking that they are present in the received report. A short report can therefore make the driver consume uninitialized bytes from the HID transport buffer and expose them as sensor values through sysfs. Validate the response header and the fields used by each response type before parsing them. Fixes: ed3e03790c5c ("hwmon: Add driver for ASUS ROG RYUJIN II 360 AIO cooler") Reported-by: Sashiko Closes: https://lore.kernel.org/linux-hwmon/20260812104617.858D01F000E9@smtp.kernel.org/ Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol sparse Signed-off-by: Arie Miller Link: https://patch.msgid.link/20260904022129.97896-2-renari@arimil.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit e32756e2f58abdca83f680de54a81f17d8128804 Author: Arie Miller Date: Wed Aug 12 06:35:30 2026 -0400 hwmon: (asus_rog_ryujin) Add per-device configuration [ Upstream commit b20ee9aee8779427d2f9de99cbb578b048bf7c04 ] Move model-specific report offsets and capabilities into a device information structure. This prepares the driver for coolers which use a different report layout or do not include the external fan controller, while preserving the existing Ryujin II 360 behavior. Handles an issue reported by Sashiko where an id could be missing driver_data. Link: https://lore.kernel.org/r/5a817284-a9f4-48b2-9f0f-802c5dc6963c@roeck-us.net Assisted-by: Codex:gpt-5.6-sol sparse Signed-off-by: Arie Miller Reviewed-by: Aleksa Savic Link: https://lore.kernel.org/r/20260812103532.395049-2-renari@arimil.com Signed-off-by: Guenter Roeck Stable-dep-of: 8042312e73c5 ("hwmon: (asus_rog_ryujin) Validate HID report lengths") Signed-off-by: Sasha Levin commit ac3f7cc23265318d84be7ce255ce5d15d3f676da Author: Guenter Roeck Date: Tue Sep 9 06:09:01 2025 -0700 hwmon: (asus_rog_ryujin) Rely on subsystem locking [ Upstream commit b4306c0c8e24f9e031185fb87de45391bc8c7fe9 ] Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck Stable-dep-of: 8042312e73c5 ("hwmon: (asus_rog_ryujin) Validate HID report lengths") Signed-off-by: Sasha Levin commit 2f0a57ff8467fbc58953679fb499b0b64106ead9 Author: Paulo Alcantara Date: Sun Sep 6 14:40:23 2026 -0300 smb: client: fix WSL reparse point uid/gid override [ Upstream commit cd2b2b57921d4caa7875e83198bb2aa71254328b ] wsl_to_fattr() unconditionally overwrites cf_uid/cf_gid with values from WSL extended attributes ($LXUID/$LXGID), ignoring the forceuid and forcegid mount options. Fix this by initializing cf_uid/cf_gid to the mount defaults and gating the $LXUID/$LXGID EA parsing on forceuid/forcegid. Closes: https://sashiko.dev/#/patchset/20260906190803.667489-1-pc%40manguebit.org Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Kept the existing fattr->cf_mode &= ~S_IFMT; line and added the new uid/gid default initialisation after it, and the S_DT() comparison context uses get_unaligned_le32(). ] Signed-off-by: Sasha Levin commit bd958a567974ae59f6d1ab4392127fa2c3db1696 Author: Paulo Alcantara Date: Sun Sep 6 14:39:44 2026 -0300 smb: client: fix uid/gid override in getattr with posix extensions [ Upstream commit cf4d35896621b7298eef51b7a465e5c0cb22f670 ] When mounting with 'multiuser,posix' options, cifs_getattr() overrides the server-provided uid/gid with the current process's fsuid/fsgid. This is because the condition only checks for unix extensions (tcon->unix_ext) but not posix extensions (tcon->posix_extensions). With SMB3 POSIX extensions, the server provides real uid/gid values just like with unix extensions, so they should be preserved rather than replaced with the caller's credentials. Add a tcon->posix_extensions check to the condition so that uid/gid from the server are properly reported in stat results. Reported-by: Arthur Lesuisse Closes: https://lore.kernel.org/r/DB9P190MB2012266F6B8DECBE5D26A1798DB52@DB9P190MB2012.EURP190.PROD.OUTLOOK.COM Suggested-by: Arthur Lesuisse Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara Cc: Ronnie Sahlberg Cc: Shyam Prasad N Cc: Tom Talpey Cc: Bharath SM Cc: stable@vger.kernel.org [ sashal: Kept the inline cifs_sb_flags(cifs_sb) calls instead of the upstream cached sbflags local, since that cleanup is missing here, and applied only the posix_extensions condition and comment change. ] Signed-off-by: Sasha Levin commit 5802a9fda4cede6af31a3e3b171480c0e446703c Author: Théo Lebrun Date: Fri Aug 28 16:07:33 2026 +0200 mips: select CONFIG_WEAK_REORDERING_BEYOND_LLSC from CONFIG_EYEQ [ Upstream commit bbc448c541ed90d52f9ec22f17394304e3bf170e ] 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: Sasha Levin commit 949748d8279493934bd7427809ebe23f3d0d5ea2 Author: Gregory CLEMENT Date: Mon Oct 27 17:15:35 2025 +0100 MIPS: Fix HOTPLUG_PARALLEL dependency [ Upstream commit c8610c021be3808f0913b8d79822d22e05a5fbcf ] With MIPS, it is possible to have SMP enabled without HOTPLUG_CPU selected. However, in kernel/cpu.c, some code that uses HOTPLUG_PARALLEL also requires HOTPLUG_CPU to be selected. Therefore, we should fix the HOTPLUG_PARALLEL dependency to depend on HOTPLUG_CPU, not just SMP. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202510270120.21wA1aX1-lkp@intel.com/ Signed-off-by: Gregory CLEMENT Signed-off-by: Thomas Bogendoerfer Stable-dep-of: bbc448c541ed ("mips: select CONFIG_WEAK_REORDERING_BEYOND_LLSC from CONFIG_EYEQ") Signed-off-by: Sasha Levin commit 4b24a1cbb10775fe67591806c403bd56f582b0ae Author: Harald Freudenberger Date: Mon Aug 31 10:38:34 2026 +0200 s390/crypto: Fix handling of EBUSY in PAES when req is pushed to crypto engine [ Upstream commit 3fec882c33d9b61983ee31456777f623dccd1a35 ] When a request is transferred to the engine via crypto_transfer_skcipher_request_to_engine() there are two return codes signaling a successful transfer: EINPROGRESS and EBUSY. However the correct handling of EBUSY was missing and has been added as a return code indicating a successful transfer to the crypto engine. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik [ sashal: Dropped the bool tested = crypto_skcipher_tested(tfm); context line, which this tree lacks, so only bool cleanup = true; is added in the four paes crypt functions. ] Signed-off-by: Sasha Levin commit 6c3e51e44834bfb0956a0faa7e1107eee7fe216b Author: Harald Freudenberger Date: Mon Aug 31 10:38:32 2026 +0200 s390/crypto: Fix use of mutex in atomic context in PAES [ Upstream commit 749990db95d45cc3d96aab999ac7f110259b200c ] The PAES CTR implementation used a mutex to lock one page of exclusive memory for fast CTR processing. Unfortunately a mutex is not save to use in atomic or interrupt context. So use a binary semaphore instead which is save to use in such environments. Furthermore rework the code to get rid of conditional locking. So restructure the PAES CRT code by extracting the main loop into a separate function and just give in information about the (locked) page can be used or not (is not locked). Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik [ sashal: Dropped the tested parameter from __ctr_paes_do_crypt(), its callers and the paes_convert_key() calls, since this tree's API lacks it. ] Signed-off-by: Sasha Levin commit e97fcd8b6598a9cfcc539e87c904b04091ecf4a4 Author: Harald Freudenberger Date: Mon Aug 31 10:38:30 2026 +0200 s390/crypto: Fix return code handling at skcipher_walk_done in PAES algorithms [ Upstream commit 403648373816ae8eb76fe4a393836b0d65fa8f85 ] All the 4 PAES cipher processing loops were not checking the return value of skcipher_walk_done() immediately after calling it. This could lead to error masking when both the walk operation failed and a subsequent key conversion was needed (k < n condition). Add immediate error checks after skcipher_walk_done() in all main processing loops (ECB, CBC, CTR, XTS modes) to ensure walk errors are properly propagated and not masked by subsequent operations. With that comes a slight rework around the skcipher_walk_done() invocation. It is now necessary to check if the walk has already been finalized (walk->nbytes is then 0) or not to avoid double de-allocation of resources held by the walk. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 06a76084f3e56ad08765eb53d30c83af425bd8df Author: Peter Zijlstra Date: Fri Jul 31 18:50:01 2026 +0200 s390/crypto: Replace cond_resched() with msleep(1) [ Upstream commit e11733826f9779eb954abdcd2b60b273558f1a77 ] With [1] cond_resched() is always compiled away and becomes a no-op. The comments for all cond_resched() calls in crypto code however indicate that the current process should be scheduled away to avoid instant re-invocation of a callback. This is not what cond_resched() would do or did. Instead of just removing the cond_resched() calls, replace them with msleep() calls, as suggested by Holger Dengler. This forces the current task to be scheduled away (sleeps) like originally intended. Holger provided information why this intended [2]: " Let me give a bit of background here: The protected key can only get invalid, if the Linux instance (z/VM or KVM guest) is moved to another hypervisor on a different machine (aka life guest relocation). In such a case, the crypto accelerator card and the host has to exchange the "real key", which is wrapped by the host and handed back to the guest as the re-newed protected key. Unfortunately there is no asynchronous trigger on completion, you have to re-try (and maybe get another "in progress" return). And as if that weren't bad enough, if this key exchange between card and host is the first one, card and host has to instantiate a secure communication channel (including a key exchange for the transport layer). " [1] commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") [2] https://lore.kernel.org/all/39570813-27b0-40f9-89c5-8e2dce05e2f0@linux.ibm.com/ [3] https://lore.kernel.org/all/20260731084027.GE776954@noisy.programming.kicks-ass.net/ [hca@linux.ibm.com: took Peter's patch [3] and provided commit message] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Heiko Carstens Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik Stable-dep-of: 403648373816 ("s390/crypto: Fix return code handling at skcipher_walk_done in PAES algorithms") Signed-off-by: Sasha Levin commit 46345b99ee5d4207ff1c58b46f9b488c03117d8c Author: Chaithanya Lagisetty Date: Fri Sep 4 21:44:54 2026 +0800 LoongArch: KVM: Fix resource leak in kvm_loongarch_env_init() error path [ Upstream commit 910132bc7d72f26a8b288c2a38c32445a48d5be0 ] kvm_loongarch_env_init() allocates the per-CPU kvm_context (vmcs) and kvm_loongarch_ops, registers the perf callbacks, and then registers the IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices. If any of those device registrations fails, the function returned the error directly, leaving everything acquired so far in place: vmcs and kvm_loongarch_ops are never freed, the perf callbacks stay registered, and all previously registered KVM device operations remain registered. kvm_loongarch_init() propagates the errors without calling kvm_loongarch_env_exit(), so nothing else cleans up either. Unwind the error path in reverse order of registration, so that each failure only undoes what had actually been set up. Use the same helpers in kvm_loongarch_env_exit() to remove the device registrations during normal teardown as well. Cc: stable@vger.kernel.org Fixes: c532de5a67a7 ("LoongArch: KVM: Add IPI device support") Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen [ sashal: Dropped the DMSINTC registration, its error label and its exit-time unregister call, since this tree has no DMSINTC device, so the unwind covers only IPI, EIOINTC and PCH-PIC. ] Signed-off-by: Sasha Levin commit b46e041ff51665529de1ce4731d5c7d1e1ef2208 Author: Chaithanya Lagisetty Date: Fri Sep 4 21:44:53 2026 +0800 LoongArch: KVM: Add unregister helpers for the KVM interrupt devices [ Upstream commit 4af22177032ab2357bf551fbfcdebc8fd9f2502d ] The IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices each have a helper that registers their kvm_device_ops, but there is no counterpart to remove them, so a caller that needs to undo a registration has to open-code kvm_unregister_device_ops() with the matching device type. Add kvm_loongarch_unregister_{ipi,eiointc,pch_pic,dmsintc}_device() next to the existing register helpers. kvm_unregister_device_ops() is a no-op when the corresponding device type is not currently registered. No functional change, as there are no callers yet. Cc: stable@vger.kernel.org Suggested-by: Bibo Mao Reviewed-by: Bibo Mao Signed-off-by: Chaithanya Lagisetty Signed-off-by: Huacai Chen [ sashal: Dropped the DMSINTC hunks and files because this tree has no DMSINTC support, leaving only the IPI, EIOINTC and PCH-PIC unregister helpers, with context adjusted for older surrounding code. ] Signed-off-by: Sasha Levin commit 18c77e2bd13c3dadeb3c88b475fa75d3dfc3878d Author: Austin Zheng Date: Wed Aug 19 09:33:57 2026 -0400 drm/amd/display: Remove const Qualifier From Non-Pointer Fields [ Upstream commit 93a77d353cb26772ae2fba50ae7321ae996b7f00 ] [WHY/HOW] Integer values for dml2_core_calcs_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport_params should not have the const qualifier. This prevents using different values of the inputs when the function is called again. Reviewed-by: Dillon Varone Signed-off-by: Austin Zheng Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 342280aae4f33816e8d07c15cb538a3b375a7f8f) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit ebc73f622313ff50bff23baa20db85936105b02f Author: Wenjing Liu Date: Thu Mar 26 17:13:27 2026 -0400 drm/amd/display: add const qualifiers to watermark params struct [ Upstream commit dd2308c1d007d7a3416c02e542abdc6acc23966d ] [why] There are few non const input pointer fields. Setting them to const to prevent future modification of read-only data. Reviewed-by: Dillon Varone Signed-off-by: Wenjing Liu Signed-off-by: Aurabindo Pillai Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 93a77d353cb2 ("drm/amd/display: Remove const Qualifier From Non-Pointer Fields") Signed-off-by: Sasha Levin commit 04a1c2898d4713d36225328dbf02737006c8506d Author: Austin Zheng Date: Wed Sep 24 10:23:24 2025 -0400 drm/amd/display: Update P-state naming for clarity. [ Upstream commit e44ee152a5ea8ee1b5f5440a754a9fd17639f230 ] [Why & How] P-state can refer to different things like UCLK P-state, PPT, or temp read Update naming for clarity Reviewed-by: Dillon Varone Signed-off-by: Austin Zheng Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 93a77d353cb2 ("drm/amd/display: Remove const Qualifier From Non-Pointer Fields") Signed-off-by: Sasha Levin commit dab4a7fc7be2d5c8e6f7350203a5ee1bcd90a407 Author: Austin Zheng Date: Thu Sep 11 15:37:32 2025 -0400 drm/amd/display: DML2.1 Reintegration [ Upstream commit 0975c4deb6c2a5abc1865f0ba5502b10c87b7d27 ] [Summary of changes] - Updated structs - Renaming of variables for clarity Reviewed-by: Dillon Varone Signed-off-by: Austin Zheng Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Stable-dep-of: 93a77d353cb2 ("drm/amd/display: Remove const Qualifier From Non-Pointer Fields") Signed-off-by: Sasha Levin commit 39a2c4e5e606cf49b83595971b449b3fb80743c6 Author: Sven Peter Date: Sat Aug 29 10:08:34 2026 +0200 thunderbolt: Make the DP tunnel activation callback mandatory [ Upstream commit 12f5d8b85a66a0ac08d082517d92ce136f8c0d42 ] tb_tunnel_alloc_dp() takes an optional callback which is run from dprx_work once the DPRX capabilities read has completed. Without that callback tb_dp_dprx_start() reads the capabilities synchronously and never queues the work. It however always takes a tunnel reference which is only dropped by dprx_work itself or by tb_dp_dprx_stop() when cancel_delayed_work() actually canceled that work. That reference is thus leaked for every tunnel without a callback. The only tunnels without one are those from tb_tunnel_discover_dp(), which are activated again when restoring from hibernation. Pass the callback to tb_tunnel_discover_dp() as well and drop the synchronous path such that the DPRX capabilities are always read from dprx_work. Hibernation restore then also no longer blocks for up to 12 seconds while waiting for that read to complete. Also fix up the KUnit tests. Fixes: d6d458d42e1e ("thunderbolt: Handle DisplayPort tunnel activation asynchronously") Cc: stable@vger.kernel.org Signed-off-by: Sven Peter Signed-off-by: Mika Westerberg [ sashal: Kept the existing dprx_canceled assignment in tb_dp_dprx_start() and added the new timeout and queue lines after it, and omitted the @paths kerneldoc line this tree lacks. ] Signed-off-by: Sasha Levin commit fc1fc874ceed4db566a5efbff39313d3d91d424a Author: Ido Schimmel Date: Fri Aug 28 22:23:43 2026 +0300 ipv6: udp: Create exceptions before socket matching [ Upstream commit ac76cab50e899a7346408b8d3c3a4192c2eefb9f ] Currently, when ICMPv6 Packet Too Big and Redirect Message packets are locally delivered and quote a UDP packet, an exception is only created in the IPv6 exception cache if the kernel can match the UDP packet to an existing socket. This behavior allows off-path attackers to conduct a side-channel attack on the exception cache in order to discover the ephemeral port used by a connected UDP socket. Commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()") and commit a00df2caffed ("ipv6: make exception cache less predictible") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the exception cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed. Instead, mitigate such attacks by always creating an exception, even before trying to find a matching socket. Do that by calling ip6_update_pmtu() and ip6_redirect(), the helpers used when the quoted packet did not originate from a socket. This means that guesses (right or wrong) from an off-path attacker will always result in an exception being created or updated in the cache that the attacker can observe. Pass the ifindex of the ingress device and the default uid, in a similar fashion to icmpv6_err(). Unlike IPv4, an oif of 0 would not match any nexthop in ip6_redirect_nh_match() and no exception would be created in response to a Redirect Message. Note that this does not allow attackers to create exceptions that they could not create before, as both helpers can already be reached with little to no validation. For example, by sending an ICMPv6 error that quotes an ICMPv6 Echo Reply or one that quotes a UDP source port that matches a wildcard socket. Also note that in the good case (matched socket) the above scheme comes at the cost of an extra route lookup, as the no socket helpers perform their own lookup before the one performed by ip6_sk_update_pmtu() / ip6_sk_redirect(). When the two resolve to different nexthops, it also results in two exceptions being created for the same destination IP. One in the exception cache of the nexthop resolved by the no socket helpers and another in the exception cache of the nexthop used by the socket. Fixes: 2b760fcf5cfb ("ipv6: hook up exception table to store dst cache") Cc: stable@vger.kernel.org Reported-by: Amit Klein Reported-by: Noam Caspi Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://patch.msgid.link/20260828192344.2596928-4-idosch@nvidia.com Signed-off-by: Jakub Kicinski [ sashal: Adapted the change to __udp6_lib_err() with its extra udptable argument, placing the new helper above it and adding its call before the socket lookup, since udpv6_err() is only a wrapper here. ] Signed-off-by: Sasha Levin commit d269ed9fff5215d2726d22aed160d45b9c1e23fb Author: Andy Chiu Date: Mon Aug 31 19:11:23 2026 -0600 riscv: hwprobe: initialize pair->value in hwprobe_one_pair() [ Upstream commit d0fc6fab20460add1f27402cd8b945d094a56b21 ] The vendor-extension handlers reached from hwprobe_one_pair() (hwprobe_isa_vendor_ext_thead_0() and friends) only OR the present bits into pair->value via VENDOR_EXTENSION_SUPPORTED() and clear their own missing bits; they assume the caller has already zeroed pair->value. That holds for hwprobe_get_values() (it zeroes each pair) and hwprobe_get_cpus() (it re-initializes its scratch pair per key), but not for complete_hwprobe_vdso_data(), which reuses a single pair across all keys without re-zeroing. A vendor key therefore inherits stale bits from the previously probed key, and the wrong value is cached in the vDSO all_cpu_hwprobe_values[] and handed to userspace on the fast patih. Zero pair->value once at the top of hwprobe_one_pair() so every handler starts from a clean value regardless of the caller, and drop the now redundant zeroing in the *_BLOCK_SIZE cases. hwprobe_isa_ext0() keeps its own zeroing because hwprobe_ext0_has() calls it directly, bypassing hwprobe_one_pair(). Fixes: a5ea53da65c5 ("riscv: hwprobe: Add thead vendor extension probing") Signed-off-by: Andy Chiu Reviewed-by: Jesse Taube Link: https://patch.msgid.link/20260725001614.2578617-2-tchiu@tenstorrent.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley [ sashal: Dropped the hunk that removes pair->value = 0; from the ZICBOP_BLOCK_SIZE case, since this tree has no ZICBOP key; the rest applies as upstream. ] Signed-off-by: Sasha Levin commit 79345a5d14b851e9ed28d3a9fe53301661dbcf11 Author: Yunpeng Tian Date: Sun Aug 30 18:46:56 2026 -0700 smb: client: reject SetEA requests that do not fit the request buffer [ Upstream commit 4aa2c106aef4bf3dfd97c30842db0767b26e8428 ] CIFSSMBSetEA() copies the caller's extended attribute value into the SMB request buffer without checking that it fits. The requirement is stated in the source but was never implemented: /*BB add length check to see if it would fit in negotiated SMB buffer size BB */ /* if (ea_value_len > buffer_size - 512 (enough for header)) */ if (ea_value_len) memcpy(parm_data->list.name + name_len + 1, ea_value, ea_value_len); The only bound applied on the way in is in cifs_xattr_set(): #define MAX_EA_VALUE_SIZE CIFSMaxBufSize ... if (size > MAX_EA_VALUE_SIZE) CIFSMaxBufSize is the full payload capacity of the buffer, so a value of exactly that size leaves no room for the SMB header, the TRANS2 parameter block, the fealist header and the EA name that are written ahead of it in the same object. SendReceive() already enforces the correct limit on this very length: if (in_len > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE) but it is called after the copy has taken place. An unprivileged setxattr(2) on an SMB1 mount with a 250-byte name and a 16384-byte value writes 16384 bytes starting 345 bytes into a 16588-byte cifs_request object, ending 141 bytes past it: BUG: KASAN: slab-out-of-bounds in CIFSSMBSetEA+0xabc/0xde0 Write of size 16384 at addr ffff888003aa0159 by task init/68 __asan_memcpy+0x3c/0x60 CIFSSMBSetEA+0xabc/0xde0 cifs_xattr_set+0xd3a/0xff0 __vfs_setxattr+0x13e/0x1a0 The buggy address is located 345 bytes inside of allocated 16588-byte region Apply SendReceive()'s limit to the assembled request before the copy rather than after it, and widen the byte counters so the sum cannot wrap before it is tested. byte_count is also tested against U16_MAX, because it is stored in the 16-bit pSMB->ByteCount. That becomes reachable when CIFSMaxBufSize is raised at module load, where it may be set as high as 1024*127: with a 5-byte EA name and a 65521-byte value, count is exactly U16_MAX while byte_count is 65556, and cpu_to_le16() would truncate it to 20 and transmit a frame whose ByteCount does not match its length. Testing byte_count covers count as well, since byte_count is the larger of the two and count's only 16-bit consumer is written after this point. check_add_overflow() is evaluated first so that total_len is assigned before it is reported. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yunpeng Tian Reported-by: Mingda Zhang Reported-by: Gongming Wang Reported-by: Qinrun Dai Cc: stable@vger.kernel.org Signed-off-by: Yunpeng Tian Reviewed-by: Namjae Jeon Signed-off-by: Paulo Alcantara [ sashal: Replaced the nonexistent in_len in the check_add_overflow() call with be32_to_cpu(pSMB->hdr.smb_buf_length) + 4, since header_assemble() here returns nothing. ] Signed-off-by: Sasha Levin commit c9c29481d5d4a985a57ece2090a324ba48e362a7 Author: Arvind Yadav Date: Tue Jul 28 11:58:32 2026 +0530 mm/migrate_device: clear stale mapping after freeing swapcache [ Upstream commit 34a00895d032a414830d41106a09329ae6c251b6 ] __migrate_device_pages() reads the folio mapping before calling folio_free_swap(). When folio_free_swap() succeeds, the folio is removed from the swap cache, but the saved mapping still points to swap_space. Passing the stale mapping to folio_migrate_mapping() makes it use the mapped-folio path for a folio that is no longer in swapcache. It can then operate on swap_space.i_pages with invalid reference accounting, eventually triggering a folio reference count BUG. After a successful split, nr still contains the number of pages in the original large folio, although each resulting page is now a separate order-0 folio. Reset nr to 1 so each split folio is processed separately, including its own swapcache removal and mapping lookup. Refresh the saved mapping after folio_free_swap() so the current folio state is used during migration. Link: https://lore.kernel.org/20260728062832.1107127-1-arvind.yadav@intel.com Fixes: df263d9a7dff ("mm/migrate_device: try to handle swapcache pages") Signed-off-by: Arvind Yadav Reviewed-by: Zi Yan Reviewed-by: Balbir Singh Cc: David Hildenbrand Cc: Matthew Brost Cc: Joshua Hahn Cc: Rakie Kim Cc: Byungchul Park Cc: Gregory Price Cc: Ying Huang Cc: Alistair Popple Cc: Signed-off-by: Andrew Morton [ sashal: Dropped the THP-only nr = 1 reset hunk and kept only the mapping = folio_mapping(folio) refresh after folio_free_swap(), since the split path doesn't exist here. ] Signed-off-by: Sasha Levin commit fa75d22453e523b207b37d1a04aa43309db8c2d8 Author: Breno Leitao Date: Mon Jul 20 06:23:45 2026 -0700 mm/kmemleak: report RCU-tasks quiescent states during the scan [ Upstream commit 3541a2b06ecd78ba333188df04368dcf97273d6a ] kmemleak_scan() can run for ages on large debug kernels. It was causing some soft-lockups which I got fixed with commit 3175fcfec8b16baeb ("mm/kmemleak: avoid soft lockup when scanning task stacks") with our beloved cond_resched(). I've got the fix above deployed in the Meta fleet, and now I am seeing: INFO: rcu_tasks detected stalls on tasks: task:kmemleak state:R ... nvcsw: 274/274 holdout: 1 idle_cpu: -1/3 scan_block scan_gray_list kmemleak_scan and, worse, blocks the callers waiting on that grace period. Here a BPF struct_ops map free, which waits via synchronize_rcu_mult(call_rcu, call_rcu_tasks), is stuck long enough to also trip the hung task check: INFO: task kworker/...:bpf_map_free_deferred blocked for 122 seconds __wait_rcu_gp bpf_struct_ops_map_free Then I've learned that cond_resched() is not an RCU-tasks quiescent state, so, we need to use stronger primitives. Use cond_resched_tasks_rcu_qs() at the scan reschedule points so the scan reports an RCU-tasks quiescent state as it proceeds. Inspired by commit b96285e10aad ("tracing: Have osnoise_main() add a quiescent state for task rcu"). Link: https://lore.kernel.org/20260720-kmemleak_rcu_task-v1-1-5b460ade777d@debian.org Fixes: c4b28963fd79 ("mm/kmemleak: rely on rcu for task stack scanning") Signed-off-by: Breno Leitao Reviewed-by: Paul E. McKenney Reviewed-by: SJ Park Reviewed-by: Catalin Marinas Cc: Breno Leitao Cc: Puranjay Mohan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8eaaabd4e9355e6dd567eb63b181eb389330c1d7 Author: Breno Leitao Date: Mon Jun 15 10:49:07 2026 -0700 mm/kmemleak: stop the task stack scan early when interrupted [ Upstream commit eb11f56eeca56069613d00bf623607e305b271d9 ] scan_block() already checks scan_should_stop() for every pointer and bails out of the current block, but the task stack walk cannot tell and keeps issuing a separate scan_should_stop() between every task. Return that status from scan_block() and use it as the task stack loop condition, so the walk stops as soon as a scan is interrupted. Link: https://lore.kernel.org/20260615-kmemleak-stack-resched-v3-2-acecd7d7fd92@debian.org Signed-off-by: Breno Leitao Suggested-by: Catalin Marinas Reviewed-by: Catalin Marinas Reviewed-by: Oleg Nesterov Cc: Davidlohr Bueso Cc: Lance Yang Cc: Qian Cai Cc: SeongJae Park Signed-off-by: Andrew Morton Stable-dep-of: 3541a2b06ecd ("mm/kmemleak: report RCU-tasks quiescent states during the scan") Signed-off-by: Sasha Levin commit b396167a7e2145dd65e05d389eb914b41e8f2ee2 Author: Gary Guo Date: Thu Aug 20 14:57:32 2026 +0100 rust: cfi: disable function merging if CFI is enabled [ Upstream commit 29b03d1de967a177176d12811d970cac7882afcf ] In Rust doc tests, there is a dummy `__module_firmware_test_init` function generated by the example in `module_firmware!`'s documentation, which just returns zero. Many other documentation examples generate functions that produce zero. LKP test robot reports [1] a `Flags::zeroed` instance; my local reproduction has a `Bounded::new::<0>`. LLVM's MergeFunctionsPass incorrectly merges functions with different KCFI types, causing `__module_firmware_test_init` to be merged into one of the zero-returning functions. As module init is invoked via an indirect function call, KCFI is checked and this produces a KCFI failure. I've reported this bug to upstream LLVM [2]; in the meantime, disable function merging if CFI is enabled. No separate treatment is needed for CONFIG_RUST_INLINE_HELPERS, as Clang does not enable function merging by default. [ LLVM already has a pending PR: https://github.com/llvm/llvm-project/pull/217665 which solves the issue. In addition, I asked upstream Rust if the unstable `-Zmerge-functions=disabled` flag will remain around: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/.60-Zmerge-functions.3Ddisabled.60/ and it does indeed look like that will be the case. - Miguel ] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202608201017.100a4511-lkp@intel.com [1] Link: https://github.com/llvm/llvm-project/issues/217629 [2] Signed-off-by: Gary Guo Cc: stable@vger.kernel.org Fixes: ca627e636551 ("rust: cfi: add support for CFI_CLANG with Rust") Reviewed-by: Sami Tolvanen Link: https://patch.msgid.link/20260820135733.37121-1-gary@kernel.org [ Fixed typos as discussed. Reworded slightly for other typos. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 81648c2440fd9cf828cfb981accfb56fd0d900cf Author: Tiezhu Yang Date: Mon Aug 17 22:07:14 2026 +0800 LoongArch: Expand module virtual address space to 2GB [ Upstream commit 18210a104bb97e28c26dc31fd9fc7b5c381fec62 ] The current 256MB module virtual address space is easily exhausted when loading massive graphics drivers such as amdgpu along with the large unstripped symbol tables, resulting in allocation failures of "execmem: unable to allocate memory". Thus, expand the module virtual address space to 2GB while keeping the current normal code model '-mcmodel=normal', rather than using the medium code model '-mcmodel=medium'. This approach avoids the extra performance overhead and larger binary size of forcing every function call into a 2-instruction sequence of 'pcaddu18i + jirl'. Given that individual module code segments rarely exceed 128MB, most jumps remain fast direct calls by using the bl instruction. For the long-distance jumps exceeding the +/-128MB limit, apply_r_larch_b26() emits PLT entries, while signed_imm_check() guarantees the run-time safety by rejecting any out-of-bound instruction offsets. There is still a risk that the distance between .init.text and .text of the same module exceeds 128MB. So we divide the 2GB virtual space to be two sub-regions: the first 256MB is for module text, and the rest is for module data. Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen [ sashal: Kept the existing #ifdef CONFIG_EXECMEM guard in init.c instead of upstream's #if defined(CONFIG_EXECMEM) && defined(MODULES_VADDR), and added the new module text/data region defines after it. ] Signed-off-by: Sasha Levin commit 79d5f84e63a5dbd8a8fce9385b605501f17fb3cf Author: Jeff Layton Date: Thu Jun 11 16:00:56 2026 -0400 nfsd: use test_and_clear_bit for somebody_reclaimed to prevent lost update [ Upstream commit 0a5a548861ab09e79a6b3062ac17e410323af3cd ] clients_still_reclaiming() uses separate test_bit() and clear_bit() calls on NFSD_NET_SOMEBODY_RECLAIMED. A concurrent set_bit() from the OPEN or LOCK reclaim path arriving between the test and clear is silently lost, causing the next laundromat tick to end grace prematurely. Replace with test_and_clear_bit() to make the read-and-clear atomic. Fixes: 8c67a210c90c ("nfsd: convert nfsd_net boolean flags to unsigned long flags word") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260611-nfsd-testing-v2-13-5b90e276f2d9@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 5f8e8c06c53f14e2b22e1fa62031392782b154d5 Author: Jeff Layton Date: Sat May 30 09:19:20 2026 -0400 nfsd: dedup nfs4_client_to_reclaim inserts [ Upstream commit 9b57793863f69c608691c98e57c2f9be2db9dfed ] nfs4_client_to_reclaim() unconditionally allocates a new nfs4_client_reclaim, prepends it to reclaim_str_hashtbl[], and bumps reclaim_str_hashtbl_size with no check for an existing entry for the same client name. After a reboot with a populated recovery directory that inflates the counter by one for every client that reclaims: boot: load_recdir() nfs4_client_to_reclaim(name) /* entry #1, size++ */ grace: RECLAIM_COMPLETE __nfsd4_create_reclaim_record_grace() nfs4_client_to_reclaim(name) /* entry #2, size++ */ inc_reclaim_complete() ends the grace period early only when atomic_inc_return(&nn->nr_reclaim_complete) == nn->reclaim_str_hashtbl_size With reclaim_str_hashtbl_size at 2N and nr_reclaim_complete capped at N, the equality never holds and the fast end-of-grace path is dead. The grace period always runs out the full 90-second laundromat timer, and the shadow entry left in the hash table carries a dangling cr_clp for any reader that walks it. Fix nfs4_client_to_reclaim() to look the name up with nfsd4_find_reclaim_client() first and, on a hit, fold the new princhash into the existing record (if it lacks one) and return that record without allocating or touching reclaim_str_hashtbl_size. On kmemdup() failure during the fold-in, return NULL so __cld_pipe_inprogress_downcall() surfaces -EFAULT to nfsdcld, matching the miss-path contract. Add an rw_semaphore (reclaim_str_hashtbl_lock) to struct nfsd_net that serialises all access to reclaim_str_hashtbl[] and reclaim_str_hashtbl_size. Writers (nfs4_client_to_reclaim, nfs4_remove_reclaim_record callers) hold the write side; readers (nfsd4_cld_check*, inc_reclaim_complete, clients_still_reclaiming, nfs4_has_reclaimed_state, nfsd4_check_legacy_client) hold the read side. All call sites are in sleepable context, and none is a hot path, so the rwsem cost is negligible. Reported-by: Chris Mason Fixes: 362063a595be ("nfsd: keep a tally of RECLAIM_COMPLETE operations when using nfsdcld") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-4-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit c7427dc319d3ad58f6ff49b0f2e7932a5273e61c Author: Bibo Mao Date: Mon Aug 10 12:21:50 2026 +0800 LoongArch: KVM: Set vcpu->cpu before IN_GUEST_MODE is set [ Upstream commit 32d05564a6128d59ea876cf9078fe6866a809e14 ] In function kvm_make_vcpu_request(), it will send IPI to physical CPU when vCPU is in IN_GUEST_MODE mode. And physical CPU is set in function kvm_check_vpid(), thus it should be called before IN_GUEST_MODE is set. Otherwise IPI will send to wrong old physical CPU where vCPU is running. Cc: stable@vger.kernel.org Fixes: 2fc3bd86db4b ("LoongArch: KVM: Implement basic vcpu interfaces") Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit f26957f88034c4aacee8b3c59ed5eb0a06bbb7b2 Author: Bibo Mao Date: Thu Jun 11 20:46:43 2026 +0800 LoongArch: KVM: Deliver interrupt after IN_GUEST_MODE is set [ Upstream commit 8c5cd2b9d6a724998c1ab9af06ac897b6152d568 ] Interrupt delivery should be called after IN_GUEST_MODE is set. Other threads may be posting interrupt however does not send IPI to the vCPU, since the vCPU is not in IN_GUEST_MODE yet. Here move function call with kvm_deliver_intr() after IN_GUEST_MODE is set, and set mode with OUTSIDE_GUEST_MODE with atomic method. Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Stable-dep-of: 32d05564a612 ("LoongArch: KVM: Set vcpu->cpu before IN_GUEST_MODE is set") Signed-off-by: Sasha Levin commit 01a4c00041bea67eeb554ac158992ea70fe89db5 Author: Bibo Mao Date: Thu Apr 9 18:56:36 2026 +0800 LoongArch: KVM: Check kvm_request_pending() in kvm_late_check_requests() [ Upstream commit 14d2714d6537a9df5bea2515185034dbb9d30f03 ] Add kvm_request_pending() checking firstly in kvm_late_check_requests(), at most time there is no pending request, then the following pending bit checking can be skipped. Also embed function kvm_check_pmu() in to kvm_late_check_requests(), and put it after the kvm_request_pending() checking. Signed-off-by: Bibo Mao Signed-off-by: Huacai Chen Stable-dep-of: 32d05564a612 ("LoongArch: KVM: Set vcpu->cpu before IN_GUEST_MODE is set") Signed-off-by: Sasha Levin commit bbac028f2e9cf3497da69946f53a9c38b29035ed Author: Adrian Hunter Date: Fri Aug 7 17:56:30 2026 +0300 i3c: master: Fix potential UAF in i3c_device_uevent() [ Upstream commit e5e8dd2e959f470524c16ca444d001c90d6bb3ad ] i3c_device_uevent() dereferences i3cdev->desc without holding the bus normal-use lock. Since the descriptor pointer can be replaced concurrently, including when a uevent is generated from sysfs, this can result in dereferencing a stale descriptor and lead to a use-after-free. Use i3c_device_get_info() instead, which protects access to the descriptor with the normal-use lock. Commit 6cf7b65f7029 ("i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock") replaced the accessor with a direct descriptor dereference because i3c_device_get_info() would recursively acquire bus->lock during device registration. This change depends on "i3c: master: Fix recursive locking during device registration", which moves device registration out from under bus->lock and removes the possibility of that deadlock. Without that change, restoring the i3c_device_get_info() call would reintroduce the deadlock. Fixes: 6cf7b65f7029 ("i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock") Cc: stable@vger.kernel.org # requires "i3c: master: Fix recursive locking during device registration" Signed-off-by: Adrian Hunter Acked-by: Mukesh Savaliya Reviewed-by: Frank Li Link: https://patch.msgid.link/20260807145638.168865-7-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 215bf2a69844e59109027f02de865a3df8a7a7d8 Author: Brendan Jackman Date: Wed Jul 15 09:03:59 2026 +0000 mm/page_alloc: don't spin_trylock() when disallowed in free_one_page() [ Upstream commit 52dcc33881e55189650404f833c0e6b7913d6c16 ] __free_frozen_pages() checks can_spin_trylock() before entering into the main free_frozen_page_commit()/free_one_page() path, but before this it can get to free_one_page() via the !pcp_allowed_order() and MIGRATE_ISOLATE paths. The !pcp_allowed_order() path depends on usage by callers so might not be possible in practice. The MIGRATE_ISOLATE path probably means kernel crashes and privilege escalation if anyone ever did memory hotplug and BPF tracing on a PREEMPT_RT or !SMP build. Link: https://lore.kernel.org/20260715-alloc-nolock-fixes-v1-2-fadc49952dda@google.com Signed-off-by: Brendan Jackman Fixes: 8c57b687e833 ("mm, bpf: Introduce free_pages_nolock()") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260710-spin-trylock-followup-v1-0-affb5fe5ed00%40google.com?part=2 Reviewed-by: Vlastimil Babka (SUSE) Reviewed-by: Harry Yoo (Oracle) Cc: Brendan Jackman Cc: Alexei Starovoitov Cc: Johannes Weiner Cc: Michal Hocko Cc: Sebastian Andrzej Siewior Cc: Shakeel Butt Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Signed-off-by: Andrew Morton [ sashal: Replaced the missing can_spin_trylock() helper call in free_one_page() with its equivalent inline condition, matching the existing open-coded checks in this tree. ] Signed-off-by: Sasha Levin commit d7e0602fe5a4adaee247c050981cf78784c19e04 Author: Jose Villaseñor Montfort Date: Tue Jul 28 14:13:09 2026 -0600 HID: input: read battery capacity from its actual report offset [ Upstream commit d07644524b6511b622ee7b0e2e68c9ee43d522a4 ] hidinput_query_battery_capacity() assumes the state-of-charge value is the first byte following the report ID (buf[1]) and ignores where the battery field actually sits within the report. An Apple Magic Trackpad 2 precedes the AbsoluteStateOfCharge byte with a byte of status flags in its battery reports, so this query returns the flags byte instead of the charge level. The device happens to make that easy to observe, because it exposes the same cell twice: its report descriptor declares AbsoluteStateOfCharge in two reports (0x90 and 0x9b), so hidinput_setup_battery() registers two power supplies. Only the first one is refreshed by hid-magicmouse -- it uses hid_get_battery(), which returns the first battery of the list -- and that refresh goes through the report event path, which parses the field correctly. Nothing ever reports the second one, so every read of its capacity takes the query path above. On a USB-C Magic Trackpad over USB, on an unpatched 7.1.5: hid--battery-144 = 100% (Charging) <- report event path hid--battery-155 = 3% (Discharging) <- query path Both are the same physical battery. A raw HIDIOCGINPUT of the two reports at that same moment: report 0x90 -> [90 03 64] report 0x9b -> [9b 03 64 64 00 00 10 00 00 00 00 00 00 00] ^flags ^SoC = 0x64 = 100% The device answers correctly in both cases; only the offset the kernel reads the capacity from is wrong. 0x03 is the flags byte (present, charging), reported as "3%". Bluetooth takes the same query path for its capacity, where the trackpad reported a bogus near-constant ~4% -- 0b100, the FullyCharged flag -- regardless of the real charge. Store the battery field's offset within the report at setup time and use it when querying, so the capacity is read from its real position. The report event path already parses the field correctly through the HID core; only the explicit GET_REPORT query was wrong. Devices whose capacity field is the first field in the report have a report_offset of 0 and are unaffected (buf[1 + 0] == buf[1]). Fixes: 581c4484769e ("HID: input: map digitizer battery usage") Cc: stable@vger.kernel.org Signed-off-by: Jose Villaseñor Montfort Reviewed-by: Alec Hall Signed-off-by: Jiri Kosina [ sashal: Adapted to the single-battery layout by using dev->battery_report_offset in struct hid_device instead of bat->report_offset in struct hid_battery, and kept the explicit kfree(buf) handling. ] Signed-off-by: Sasha Levin commit fb59d3c60513f586a3e25f66ab52ae6d8aa465b9 Author: Dev Jain Date: Fri Jul 3 11:41:57 2026 +0000 mm/migrate: use huge_ptep_get() in remove_migration_pte() [ Upstream commit ac1ec50d71b953524100ddc09057ee61a3dfaff3 ] remove_migration_pte() converts migration entries back to present PTEs after folio migration completes. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get(). On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Use huge_ptep_get() to dereference a huge pte pointer. Link: https://lore.kernel.org/20260703114202.365553-5-dev.jain@arm.com Fixes: 290408d4a250 ("hugetlb: hugepage migration core") Signed-off-by: Dev Jain Acked-by: Muchun Song Acked-by: David Hildenbrand (Arm) Cc: Alistair Popple Cc: Andi Kleen Cc: Anshuman Khandual Cc: Byungchul Park Cc: Catalin Marinas Cc: Dave Hansen Cc: Gregory Price Cc: Harry Yoo Cc: "Huang, Ying" Cc: Jann Horn Cc: Josh Poimboeuf Cc: Joshua Hahn Cc: Jun'ichi "Nick" Nomura Cc: Kiryl Shutsemau Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Mel Gorman Cc: Naoya Horiguchi Cc: Oscar Salvador Cc: Pedro Falcato Cc: Rakie Kim Cc: Ralph Campbell Cc: Rik van Riel Cc: Ryan Roberts Cc: Vlastimil Babka Cc: Will Deacon Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit be58823c0e2cf441be84fca9076af30e6719f127 Author: Yosry Ahmed Date: Mon Jul 13 18:10:18 2026 +0000 KVM: x86: Always initialize EFER reserved bits on vendor initialization [ Upstream commit a4b8acd428ba3f03952ef309d7f438dbc357557b ] EFER reserved bits are statically initialized, and do not reset if a vendor module is re-loaded. For example, loading kvm_amd with nested=1 removes EFER.SVME (and potentially EFER.LMSLE) from the reserved bits. Reloading kvm_amd with nested=0 does not add them back, allowing userspace to set EFER.SVME with nested=0. Re-initializing EFER reserved bits before configuring them on vendor initialization. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed Link: https://patch.msgid.link/20260713181020.2735367-4-yosry@kernel.org Signed-off-by: Sean Christopherson [ sashal: Moved the EFER reserved-bits reset into a new static kvm_init_efer_bits() in x86.c, called from kvm_x86_vendor_init() before hardware_setup(), since the MSR split files and kvm_setup_efer_caps() don't exist here. ] Signed-off-by: Sasha Levin commit 59c7c68ec4dec87942ed3179e1821cf4e9387e02 Author: Matthew Auld Date: Fri Jun 12 18:05:02 2026 +0100 drm/xe/display: skip FORCE_WC and vm_bound check for external dma-bufs [ Upstream commit 3e493f88c84088ccd7b53cdd23ac5c875c9a60dd ] Currently, xe_display_bo_framebuffer_init() unconditionally attempts to apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB creation with -EINVAL if the BO is already VM_BINDed. However, for imported dma-bufs (ttm_bo_type_sg), this check doesn't seem to make much sense since CPU caching policy is entirely controlled by the exporter. Plus there is no place to set this flag, in the first place. Also this is not rejected if not yet vm_binded, but that seems arbitrary since setting or not setting FORCE_WC should a noop either way, at this stage, and whether it is currently VM_BINDed makes no difference. Currently if we run an app and offload rendering to an external dGPU, like NV or another xe device, the dma-buf passed back to the compositor (igpu) will be an actual external import from xe pov, and it will be missing FORCE_WC, and if the compositor side did a VM_BIND before turning into it into an fb the whole thing gets rejected. So it looks like we either need to reject outright, no matter what, or this usecase is valid and we need to loosen the restriction for sg buffers. Proposing here to loosen the restriction. Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919 Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Cc: Maarten Lankhorst Cc: # v6.12+ Reviewed-by: Maarten Lankhorst Link: https://patch.msgid.link/20260612170501.550816-2-matthew.auld@intel.com [ sashal: Used SCANOUT in place of FORCE_WC and adapted the hunks to the older intel_fb_bo.c and xe_fb_pin.c code, adding the ttm_bo_type_sg exemption to both the flag check and the pin-time drm_WARN_ON. ] Signed-off-by: Sasha Levin commit 7d38a96a93270e8ceba63c2d95807b6c1c748f5f Author: Lorenzo Pieralisi Date: Thu Oct 15 10:20:26 2026 +0200 irqchip/gic-v5: Fix standalone IRSes OF probe [ Upstream commit 64212d63193cfd81849f5948365c7b0ecd011745 ] An IRS is architecturally allowed to be standalone, namely, with no direct CPUs connections. Make sure such configuration is allowed on OF firmware by skipping "cpus" and "arm,iaffids" IRS node properties parsing if they are not present so that the IRS configuration can complete successfully. Fixes: 5cb1b6dab2de ("irqchip/gic-v5: Add GICv5 IRS/SPI support") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Reviewed-by: Sascha Bischoff Link: https://patch.msgid.link/20261015-gicv5-irs-no-cpus-v1-2-d4b337b7f000@kernel.org Signed-off-by: Sasha Levin commit 59a6d8eda1c5dddecbed8665d86723ee6adda34e Author: Lorenzo Pieralisi Date: Thu Oct 15 10:20:25 2026 +0200 dt-bindings: interrupt-controller: gicv5: Relax IRS properties constraints [ Upstream commit 1d77e79d62cfe46ad3619d42ee0d1ebd3f0f79f4 ] An IRS is architecturally allowed to be stand-alone (ie with no direct CPU connection). Relax "cpus" and "arm,iaffids" properties constraints allowing a standalone IRS configuration. Fixes: 7d7299bd07c6 ("dt-bindings: interrupt-controller: Add Arm GICv5") Signed-off-by: Lorenzo Pieralisi Signed-off-by: Thomas Gleixner Reviewed-by: Sascha Bischoff Link: https://patch.msgid.link/20261015-gicv5-irs-no-cpus-v1-1-d4b337b7f000@kernel.org Signed-off-by: Sasha Levin commit db0f1d03fbd1bf8063392cd2bc557c255a9e9ac2 Author: Qing Luo Date: Mon Nov 2 01:52:02 2026 -0800 sctp: auth: discard auth_chunk when skb_clone fails [ Upstream commit 9ae7ed101cf28613071ebfbc42668c8917a670cf ] When processing AUTH + COOKIE-ECHO packets, if skb_clone() fails due to memory pressure, chunk->auth_chunk is NULL. The original code still sets chunk->auth = 1 and continues, leaving the COOKIE-ECHO to be processed without a valid auth_chunk for deferred verification. Discard the AUTH chunk early via pdiscard when skb_clone() fails, so that the receive loop can continue processing remaining chunks in the inqueue instead of stalling the entire packet. Signed-off-by: Qing Luo Acked-by: Xin Long Link: https://patch.msgid.link/20260723061107.384106-1-l1138897701@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Harshvardhan Jha Signed-off-by: Harshit Mogalapalli Signed-off-by: Sasha Levin commit 8ced68fe293a58f290f6eb3bb5441bf2cf78e88b Author: Pablo Neira Ayuso Date: Wed Aug 12 10:03:38 2026 +0200 netfilter: ctnetlink: do not expose expectation DEAD flag [ Upstream commit 322371b09058ad10d0282a0e7ec8eaa764e6aaac ] Expose expectation flags included in the NF_CT_EXPECT_MASK bitmask only. The DEAD flag is internal, do not expose it. Fixes: b8b09dc2bf35 ("netfilter: nf_conntrack_expect: use conntrack GC to reap expectations") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f540bf1291a97d754b1db77d261fd1d739717825 Author: Pablo Neira Ayuso Date: Sun Nov 1 15:27:30 2026 +0000 netfilter: nf_conntrack_expect: add and use nf_ct_expect_related_pair() commit 4aa63842fc92de1bce59d4709a0d32e718890bb2 upstream. Add a new function to insert a pair of expectations, this is required by the SIP and H323 NAT helpers. The spinlock is held to check if there is a slot for both expectations, in such case, insert them. This removes the need for nf_ct_unexpect_related() inside the loop to find a pair of consecutive ports, otherwise inserting expectations whose dead flag is already set on can happen. Bump master_help->expecting for the expectation class after checking if the expectation fits in the master expectation list, which is needed for this new _pair() function variant to run the eviction routine including the preallocated slot for the first expectation in the pair. [ Joas: nf_ct_expect_insert() and __nf_ct_expect_check() do not take a master_help argument in this tree, so keep their existing signatures; nf_ct_expect_related_report() gets master_help from nfct_help(expect->master) for the moved expecting[] increment. ] Fixes: b8b09dc2bf35 ("netfilter: nf_conntrack_expect: use conntrack GC to reap expectations") Reported-by: Jaeyeong Lee Link: https://patch.msgid.link/178377968720.33756.12204817361601593230@proton.me/ Signed-off-by: Pablo Neira Ayuso Signed-off-by: Joas Antonio dos Santos Signed-off-by: Sasha Levin commit bc6b1da681abe631ed21b7fdced48546189d64a4 Author: Pablo Neira Ayuso Date: Thu Jun 18 13:56:38 2026 +0200 netfilter: nf_conntrack_expect: use conntrack GC to reap expectations [ Upstream commit b8b09dc2bf35a00d4e0556b5d6308c7b917ebda2 ] This patch replaces the timer API by GC worker approach for expectations, as it already happened in many other subsystems. Use the existing conntrack GC worker to iterate over the local list of expectations in the master conntrack to reap expired expectations. Check IPS_HELPER_BIT to run GC for expectations, set it on for nft_ct expectation which nevers sets it. Hold the expectation spinlock while iterating over the master conntrack expectation list to synchronize with nf_ct_remove_expectations(). This also performs runtime packet path garbage collection through the expectation insertion and lookup functions while walking over one of the chains of the global expectation hashtables. Unconfirmed conntrack entries are skipped since ct->ext can be reallocated and dying are skipped since those will be gone soon. Set on IPS_HELPER_BIT if the helper ct extension is added, then the new GC worker does not need to bump the ct refcount to check if the ct->ext helper is available. This removes the extra bump on the refcount for expectation timers, this allows to remove several nf_ct_expect_put() calls after the unlink, after this update only refcount remains at 1 while on the expectation hashes. This patch implicitly addresses a race with the existing timer API allowing an expectation to access a stale exp->master pointer which has been already released when expectation removal loses races with an expiring timer, ie. timer_del() reporting false. Add a new NF_CT_EXPECT_DEAD flag to reap this expectation via GC. This is needed by nf_conntrack_unexpect_related() which is called in error paths to invalidate newly created expectations that has been added into the hashes. These expectactions cannot be inmediately released as GC or nf_ct_remove_expectations() could race to make it. On expectation insert, the runtime GC reaps stale expectations before checking the expectation limit set by policy. Set current timestamp in nf_ct_expect_alloc(), then add the expectation policy timeout (or custom timeout specified added on top of this) to specify the expectation lifetime. Fixes: bffcaad9afdf ("netfilter: ctnetlink: ensure safe access to master conntrack") Signed-off-by: Pablo Neira Ayuso [ sashal: adapted evict_oldest_expect() to the older signature that takes the master conntrack, and dropped the nft_ct helper refcount check absent in this tree. ] Signed-off-by: Sasha Levin commit af17c2ffde0b14cda5c72acbd0f0865b753fb69c Author: Darrick J. Wong Date: Tue Sep 22 23:02:18 2026 -0700 xfs: fix integer overflow problem when setting large free areas commit 7e55f84434f3a63d59feb8f89076d280ea9aa8e5 upstream. LOLLM points out that the min_t comparison in xrep_rtbitmap_mark_free operates on a 64-bit bitmap word offset quantity and a 32-bit words-per-block ratio. Unfortunately, I should have done the comparison with the (64-bit) xrep_wordoff_t type, but used the 32-bit word count type. Oops. Cc: stable@vger.kernel.org # v6.14 Fixes: 8defee8dff2b20 ("xfs: online repair of realtime bitmaps for a realtime group") Signed-off-by: Darrick J. Wong Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman commit 66b8f5bfc592e28214c1283333becd43890dfe75 Author: Bui Viet Dung Date: Thu Oct 8 20:07:53 2026 +0700 wwan: wwan_hwsim: Pin module for debugfs file operations commit a388f17e23b7e305cb306aafd73bb10d6b8ca452 upstream. An open debugfs file retains its file_operations pointer in the debugfs proxy state. However, wwan_hwsim_debugfs_portdestroy_fops, wwan_hwsim_debugfs_portcreate_fops, wwan_hwsim_debugfs_devdestroy_fops, and wwan_hwsim_debugfs_devcreate_fops in wwan_hwsim.c have no .owner set to THIS_MODULE. As a result, full_proxy_open_regular() calls fops_get() which succeeds without taking a reference to the wwan_hwsim module. When a userspace process opens any of these debugfs files, a subsequent module unload (rmmod wwan_hwsim) can succeed while the file descriptor remains open. When the userspace process subsequently closes the descriptor, full_proxy_release() accesses the already unmapped file_operations structure, triggering a kernel oops in full_proxy_release(): BUG: unable to handle page fault for address: fffffbfff84f90ef Oops: 0000 [#2] SMP KASAN NOPTI RIP: 0010:full_proxy_release+0x8e/0x140 Call Trace: __fput+0x357/0xaa0 fput_close_sync+0xe6/0x1a0 file_close_fd_locked+0x17e/0x2f0 do_close+0x33/0x70 __x64_sys_close+0x44/0x80 do_syscall_64+0xc3/0x590 entry_SYSCALL_64_after_hwframe+0x76/0x7e The issue was discovered via manual code audit of wwan_hwsim.c and reproduced on a Linux 7.3-rc6 test VM with CONFIG_WWAN_HWSIM=m. Set .owner = THIS_MODULE on all four debugfs file_operations structures in wwan_hwsim.c so that debugfs pins the module until close has completed. Fixes: 9ee23f48f670 ("wwan_hwsim: add debugfs management interface") Cc: stable@vger.kernel.org Signed-off-by: Bui Viet Dung Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20261008130753.313875-1-dungvn2345@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit df713b82b4b9671c16b52b60f3412c677719e2b8 Author: Giorgi Kobakhia Date: Mon Sep 28 13:04:45 2026 -0700 udf: fix return value for non-recorded-allocated extents in udf_map_block() commit 0f242ca0878896df30292f4922700a32e8fdd039 upstream. When someone creates a corrupted UDF filesystem where symlink contains other extent type than EXT_RECORDED_ALLOCATED, it can leads to a crash like: Oops: general protection fault KASAN: maybe wild-memory-access RIP: 0010:page_get_link (fs/namei.c:6503) Call Trace: vfs_readlink (fs/namei.c:6419) do_readlinkat (fs/stat.c:583) __x64_sys_readlink (fs/stat.c:605 fs/stat.c:602 fs/stat.c:602) This is because in this case udf_map_block() fails to convert return value of inode_bmap() from 1 to 0. Returned '1' propagates through udf_bread() all the way up to __page_get_link() where it ends up being treated as a folio pointer with obvious results. Move the reset to 0 line outside the if, so udf_map_block() returns either 0 or -errno, even if the extent type is not EXT_RECORDED_ALLOCATED. Fixes: c226964ec786 ("udf: refactor inode_bmap() to handle error") Cc: stable@vger.kernel.org Assisted-by: LLM Tested-by: Xiang Mei Signed-off-by: Giorgi Kobakhia Link: https://patch.msgid.link/20260928200445.18722-1-gkobakhi@asu.edu Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 85a8777c7ec5e17b999b4c9eb0c8cbf4ab936998 Author: Jonathan Gopel Date: Sun Oct 4 11:13:50 2026 -0600 thunderbolt: Do not RPM complete unrelated subtrees on unplug commit 96a8479804e3f7af43e639e9df39f562f1a75fd5 upstream. When a Thunderbolt device is unplugged, that switch and every switch subsequent to it on the bus device list is `complete()`d, not just its child devices. In the case of multiple domains, it may cause, eg, an attempt to `complete()` the uninitialized domain 1 root switch RPM completion on unplug of a switch from domain 0 (though ordering is not guaranteed numerically sorted). I initially noticed this issue on a Dell XPS9720 when the system would seem to sporadically not wake after unplugging a Thunderbolt dock. I tried multiple kernel versions including v7.2.7 and v7.3-rc4 to see if that resolved the issue, but the issue persisted. Eventually I found that I could consistently generate a kernel Oops reporting a page fault at 0xffff_ffff_ffff_fff8 on unplug from one side of the laptop and went bug hunting. I became suspicious of the `bus_for_each_dev()` walk that I ultimately ended up changing. To confirm this issue, I did an eBPF trace of `bus_for_each_dev()`, `complete_rpm()`, and `complete()` while unplugging in a variety of situations and found that an unplug from domain 0 tries to `complete_rpm()` domain 1's switch, whose RPM completion is not initialized and thus is holding a null wait-list pointer, triggering the page fault. Here are the key sections of that eBPF trace. Note that HEAD denotes the completion's own wait-list HEAD: ``` RESCAN_ENTER domain=0 COMPLETE rescan_domain=0 target=0-1 target_domain=0 route=0x1 parent=0-0 unplugged=1 COMPLETION done=0 head=HEAD next=HEAD prev=HEAD BUS_WALK domain=0 start=0-1 callback=complete_rpm CALLBACK_ENTER rescan_domain=0 dev=1-0 parent=domain1 is_switch=1 COMPLETE rescan_domain=0 target=1-0 target_domain=1 route=0x0 parent=domain1 unplugged=0 COMPLETION done=0 head=HEAD next=0 prev=0 complete+5 complete_rpm+43 bus_for_each_dev+133 icm_free_unplugged_children+250 icm_rescan_work+42 ``` This patch gates the `complete()` on an additional condition - that the Thunderbolt domain matches the domain of the device that was unplugged. I only have a single system with multiple Thunderbolt domains - the Dell XPS9720. I am consistently able to reproduce the Oops on that system. Since running with this patch, I have not seen the Oops reoccur. I have also tested it on a Thinkpad X1-Gen12, and that system boots and runs well with it, but it only has a single Thunderbolt domain, so it does not exercise the multi-domain failure case. Fixes: 4f7c2e0d8765 ("thunderbolt: Make sure device runtime resume completes before taking domain lock") Cc: stable@vger.kernel.org Signed-off-by: Jonathan Gopel Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit d764d3f28a38deafe2980f6671764968dcdb9bc5 Author: Cen Zhang Date: Tue Oct 13 09:58:58 2026 +0800 ocfs2: publish the filecheck owner before adding sysfs attributes commit e062baf5680845705d21df415c8f0751c96b0792 upstream. ocfs2_filecheck_create_sysfs() initializes the filecheck allocation before calling kobject_init_and_add(), but assigns entry->fs_fcheck only after that call returns. The default attribute group can already be visible while registration is in progress. A concurrent read can therefore enter ocfs2_filecheck_attr_show() with a NULL fs_fcheck and try to lock its fc_lock. Assign the initialized owner before adding the kobject, so every activated attribute has valid state. Clear the pointer when addition fails, preserving the existing teardown guard and error cleanup. A controlled probe-instrumented test kernel with the original OCFS2 registration ordering produced this Oops during a concurrent sysfs read: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:kasan_byte_accessible+0x15/0x30 Call Trace: __kasan_check_byte+0x13/0x50 lock_acquire+0x113/0x300 _raw_spin_lock+0x31/0x40 ocfs2_filecheck_attr_show+0x138/0x5f0 ocfs2_filecheck_show+0x5d/0x90 sysfs_kf_seq_show+0x1d3/0x360 seq_read_iter+0x480/0x1110 kernfs_fop_read_iter+0x419/0x5a0 vfs_read+0x7d2/0xc20 ksys_read+0x111/0x200 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Modules linked in: Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0086-v4-1b3a3c5fd05c1fb41df9@gmail.com Fixes: 5f483c4abb50 ("ocfs2: add kobject for online file check") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Heming Zhao Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Gang He Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit f5e973e238ba686a17f19dfbccccdd1c4447a2be Author: Cen Zhang Date: Fri Oct 16 09:17:13 2026 +0800 ocfs2: pin owning modules for open debugfs files commit 26d7e34b4226709084461a07bf28d9066fa96d8c upstream. The OCFS2 debugfs file operation tables do not set owner. The full debugfs proxy obtains real_fops with fops_get() at open and keeps it until final release. Without an owner, this does not acquire a reference to the module containing the table and its callbacks. Removing the debugfs entries does not drain retained open files. An open connected_nodes file can therefore outlive ocfs2_nodemanager and make full_proxy_release() read real_fops->release from freed module memory. Heming also reproduced the issue with fs_state and asked for the other OCFS2 debugfs operation tables to be checked. Set owner to THIS_MODULE in all eleven explicit debugfs operation tables: five in ocfs2_nodemanager, four in ocfs2_dlm, and two in ocfs2. The existing debugfs get/put pair then holds the appropriate module until final release. Leave the open, read and release callbacks unchanged. The blockcheck table already sets owner through DEFINE_DEBUGFS_ATTRIBUTE(), so it needs no change. The original controlled test used an unloadable OCFS2 module and case-local probe filters without changing the candidate open, unload or release logic. Closing a retained connected_nodes file after normal unload produced: BUG: unable to handle page fault for address: fffffbfff804cfef Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:full_proxy_release+0xbf/0x190 Call Trace: __fput+0x39a/0xa60 fput_close_sync+0xff/0x200 __x64_sys_close+0x8c/0xf0 do_syscall_64+0x114/0x620 entry_SYSCALL_64_after_hwframe+0x77/0x7f Modules linked in: [last unloaded: ocfs2_nodemanager] Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0089-v6-f7fda843f80887488145@gmail.com Fixes: 2309e9e040fe ("ocfs2/net: Add debug interface to o2net") Fixes: 87d3d3f3931f ("ocfs2/hb: Expose the list of heartbeating nodes via debugfs") Fixes: 3ba169ccec1c ("ocfs2/cluster: Add new function o2net_fill_node_map()") Fixes: 50397507e856 ("ocfs2: Expose the file system state via debugfs") Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Fixes: 7209300a9b98 ("ocfs2/dlm: Dumps the purgelist into a debugfs file") Fixes: d0129aceaecc ("ocfs2/dlm: Dumps the mles into a debugfs file") Fixes: 4e3d24ed1a12 ("ocfs2/dlm: Dumps the lockres' into a debugfs file") Fixes: 007dce53a29c ("ocfs2/dlm: Dump the dlm state in a debugfs file") Fixes: db02754c8a12 ("ocfs2/cluster: Show o2net timing statistics") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Suggested-by: Heming Zhao Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Kees Cook Cc: Karl Mehltretter Cc: Christophe JAILLET Cc: Yufan Chen Cc: Mike Rapoport Cc: Zhang Cen Cc: Christian Brauner Cc: Sunil Mushran Cc: Kurt Hackel Cc: Jan Kara Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 1c77b387fc305c9c314f29cd034a490bff7f81bd Author: Cen Zhang Date: Tue Oct 20 11:45:04 2026 +0800 ocfs2: drain quorum work before removing the cluster commit b584c45b6066fd9799c44ffb9badcb5db351c8a6 upstream. The configured cluster must remain available until an in-flight quorum decision has finished using its fencing method. o2quo_make_decision() drops qs_lock before calling o2quo_fence_self(), which marks heartbeat regions for unclean stop and then reads o2nm_single_cluster->cl_fence_method. Cluster removal clears the singleton without waiting for this independent system-workqueue item. When a failed-quorum decision overlaps removal of the heartbeat regions, nodes and cluster through configfs, the worker can be preempted after marking the regions and resume after the singleton has been cleared: Quorum worker Configfs removal select fence; drop qs_lock o2hb_stop_all_regions() remove regions; join heartbeat threads remove nodes; stop o2net clear singleton; release cluster read cl_fence_method The resumed read dereferences NULL instead of applying the configured fencing method. The heartbeat thread's dependency protects the local node only until the thread exits, and draining o2net does not wait for qs_work. Add o2quo_flush_work() to drain pending or running quorum decisions before clearing the singleton in o2nm_cluster_group_drop_item(). By this point the heartbeat regions and nodes have been removed, so their work publishers are stopped. The worker can finish while the cluster and its configured fencing method remain available. It does not acquire the configfs mutex held by the removal path. Keep o2quo_exit() as the counterpart of o2quo_init() for module teardown and initialization failure, and have it call the same drain helper. Cluster removal uses only the explicitly named drain operation. KASAN report as below: Oops: general protection fault, probably for non-canonical address 0xdffffc000000011b: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000008d8-0x00000000000008df] CPU: 0 UID: 0 PID: 72 Comm: kworker/0:2 Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 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: events o2quo_make_decision RIP: 0010:o2quo_fence_self+0x65/0x200 Register dump omitted. Call Trace: o2quo_make_decision+0x345/0x3a0 ? __pfx_o2quo_make_decision+0x10/0x10 ? process_one_work+0x834/0x1b40 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 process_one_work+0x9a8/0x1b40 ? __pfx_process_one_work+0x10/0x10 ? lock_acquire+0x190/0x300 ? lock_is_held_type+0x8f/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x65c/0xe40 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kthread_parkme+0x177/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_worker_thread+0x10/0x10 kthread+0x351/0x460 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x659/0x940 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x74f/0xf70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0064-v5-e3870bf6571b80b07b52@gmail.com Fixes: f6656d26d17b ("ocfs2/cluster: Make fence method configurable - v2") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 912327bb4cfdc38e83dd52300a087a7e68826ece Author: Cen Zhang Date: Thu Oct 22 17:09:10 2026 +0800 ocfs2/dlm: drain join handlers before releasing module text commit 28f366d84023651e50e32e29931401ba0df3e679 upstream. The code for a registered DLM handler must remain resident until its last invocation finishes. dlm_unregister_net_handlers() only removes dlm_join_handlers from the o2net registry. o2net_handler_get() takes a kref on the wrapper, but that reference does not pin ocfs2_dlm text. o2net_process_message() calls nh_func after dropping o2net_handler_lock. With CONFIG_OCFS2_FS_O2CB=m, ocfs2_dlm can be loaded independently of ocfs2_stack_o2cb while nodemanager continues handling messages from a configured, heartbeating peer. If no dependent module or module reference prevents normal unload, the following ordering is possible: Receive worker Module unload -------------- ------------- o2net_handler_get() take wrapper kref drop handler lock dlm_exit() unregister handlers release DLM module text call saved nh_func in released module text Use o2net_unregister_and_flush_handler_list() in the shared DLM unregister helper. It first prevents new lookups, then waits for the ordered o2net workqueue to drain, including a concurrent destruction of that queue. The acquired invocation therefore finishes before dlm_exit() returns and the loader releases the callback code. The same helper covers partial registration and dlm_init() error unwind before module memory is released. Skip the drain when the private join-handler list is empty. Early dlm_init() failures can reach this helper before any handler has been published. Partial-registration failure also reaches it a second time after the first call has already unregistered and drained the list. Neither case needs to take o2net_wq_mutex or drain unrelated work. The list is changed only by serialized module init/exit paths; a nonempty list still uses the full unregister-and-flush helper. Oops report as below: Oops: int3: 0000 [#1] SMP KASAN NOPTI CPU: 2 UID: 0 PID: 54 Comm: kworker/u16:3 Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy) Hardware identification omitted. Workqueue: o2net o2net_rx_until_empty [ocfs2_nodemanager] RIP: 0010:0xffffffffc0423871 [Instruction byte dump omitted.] Register dump omitted. Call Trace: ? o2net_rx_until_empty+0x19b1/0x3300 [ocfs2_nodemanager] ? __pfx_o2net_rx_until_empty+0x10/0x10 [ocfs2_nodemanager] ? lock_acquire+0x190/0x300 ? process_one_work+0x935/0x1b40 ? process_one_work+0x834/0x1b40 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 ? process_one_work+0x9a8/0x1b40 ? __pfx_process_one_work+0x10/0x10 ? lock_acquire+0x190/0x300 ? lock_is_held_type+0x8f/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 ? worker_thread+0x65c/0xe40 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kthread_parkme+0x177/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_worker_thread+0x10/0x10 ? kthread+0x351/0x460 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_kthread+0x10/0x10 ? ret_from_fork+0x659/0x940 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x74f/0xf70 ? __pfx_kthread+0x10/0x10 ? ret_from_fork_asm+0x1a/0x30 Modules linked in: ocfs2_nodemanager [last unloaded: ocfs2_dlm] ---[ end trace 0000000000000000 ]--- Link: https://lore.kernel.org/pm-ocfs2-objects-candidate-0076-v6-12de5f4628f57fba3be3@gmail.com Fixes: 6714d8e86bf4 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Cen Zhang Signed-off-by: Andrew Morton Reviewed-by: Joseph Qi Assisted-by: LLM Cc: Mark Fasheh Cc: Joel Becker Cc: Heming Zhao Cc: Jia-Ju Bai Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit f43a5d7b665cf04199a3e8ea0dddc9e2dbd5ada6 Author: Ameer Hamza Date: Sun Jul 26 17:46:58 2026 +0500 nfsd: fix race between client_info_show() and free_client() commit ee62dc03a69ee57855de35da1a8ab53b51d30b32 upstream. client_info_show() renders /proc/fs/nfsd/clients//info and walks clp->cl_sessions under clp->cl_lock to print each session's slot counts. free_client() tears down the same list without taking cl_lock, and is the only unlocked mutator of cl_sessions. A reader can observe a client mid-teardown because get_nfsdfs_clp() pins the nfs4_client but not its sessions: free_client() frees every session before calling nfsd_client_rmdir(), so an in-flight seq_file reader can follow a list_del()'d node whose ->next now holds LIST_POISON1 and take a general protection fault: Oops: general protection fault, probably for non-canonical address 0xdead00000000014c CPU: 1 UID: 0 PID: 132488 Comm: cat RIP: 0010:client_info_show+0x2bf/0x3d0 RAX: dead000000000100 Call Trace: seq_read_iter+0x12a/0x4b0 seq_read+0xf1/0x130 vfs_read+0xbf/0x350 ksys_read+0x6f/0xf0 do_syscall_64+0x8b/0xcb0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Kernel panic - not syncing: Fatal exception Detach cl_sessions onto a local reaplist under cl_lock, then free the sessions after dropping the lock. Removing entries from cl_sessions under cl_lock matches unhash_session(), and the detach-then-reap shape matches how __destroy_client() reaps cl_delegations. The sessions cannot be freed while cl_lock is held, since free_session() calls nfsd4_del_conns(), which re-acquires it. Reported-by: Nicholas Wolff Fixes: 601c8cb349c2 ("nfsd: add session slot count to /proc/fs/nfsd/clients/*/info") Cc: stable@vger.kernel.org Signed-off-by: Ameer Hamza Link: https://patch.msgid.link/20260726124658.1715711-1-ameer.hamza@truenas.com Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 00c0c940c1c8941497a8cf511edc95fdde8c6382 Author: Wei Jie Law Date: Wed Oct 21 10:03:09 2026 +0800 net: usb: pegasus: do not advance rx_skb->data on dropped frames commit bfa09dccf98cf78dd9282259b2140bd1472f5ae9 upstream. For the 0x8513 chip, read_bulk_callback() skips the 2-byte receive header by advancing pegasus->rx_skb->data in place. This is done before the pkt_len > PEGASUS_MTU check, and when that check drops the frame the good path resubmits the same skb with the advanced rx_skb->data as the transfer buffer, still PEGASUS_MTU bytes long. Every frame with an oversized length field therefore moves the receive buffer two more bytes towards the end of the skb data area. A device that keeps sending such frames makes the host controller write received data over skb_shared_info and past the end of the allocation, and the corrupted skb_shared_info is used when the skb is eventually freed. With an emulated device sending frames filled with 0x5a on a KASAN kernel: BUG: KASAN: slab-out-of-bounds in dummy_timer+0xade/0x3f00 [dummy_hcd] Write of size 1536 at addr ffff888105821202 by task swapper/1/0 ... Oops: general protection fault, probably for non-canonical address 0xeb4b474b4b4b4b4c: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x5a5a5a5a5a5a5a60-0x5a5a5a5a5a5a5a67] RIP: 0010:skb_release_data+0x36f/0x800 Only skip the header with skb_reserve() once the frame is going to be passed up, so the receive buffer always starts at the beginning of the skb data area. Unlike the old pointer adjustment, skb_reserve() also moves skb->tail, so the two header bytes now count against the buffer size: lower the length limit for the 0x8513 accordingly, otherwise a pkt_len of PEGASUS_MTU - 1 or PEGASUS_MTU would trip skb_over_panic(). Found by code review with LLM assistance and reproduced with an emulated USB device (raw-gadget + dummy_hcd). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Wei Jie Law Reviewed-by: Simon Horman Link: https://patch.msgid.link/20261021020310.34045-2-law.wei.jie@gt.tech.gov.sg Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f9af5772ff0ef32fa4ffb43fc10861823e6a06e3 Author: Kaho Jiang Date: Wed Oct 21 19:57:33 2026 -0400 net: ipv4: add zero check for snd_cwnd_clamp commit 363c8c79220d0db4d65dcd570529ddda15067cb5 upstream. When RTAX_CWND is locked, user is able to pass 0 into it. This could lead to writing 0 to tp->snd_cwnd, leading to a division by zero error. Oops: divide error: 0000 [#1] SMP KASAN NOPTI Call Trace: tcp_reno_cong_avoid (net/ipv4/tcp_cong.c:510 (discriminator 1)) tcp_ack (net/ipv4/tcp_input.c:3517 net/ipv4/tcp_input.c:3873 net/ipv4/tcp_input.c:4440) tcp_rcv_established (net/ipv4/tcp_input.c:6685) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1854) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2248) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207 (discriminator 1)) ip_local_deliver_finish (net/ipv4/ip_input.c:241 (discriminator 1)) ip_local_deliver (./include/linux/netfilter.h:325 ./include/linux/netfilter.h:319 net/ipv4/ip_input.c:262) ip_rcv (./include/net/dst.h:481 (discriminator 6) net/ipv4/ip_input.c:492 (discriminator 6) ./include/linux/netfilter.h:325 (discriminator 6) ./include/li) __netif_receive_skb_one_core (net/core/dev.c:6297 (discriminator 4)) __netif_receive_skb (net/core/dev.c:6410) process_backlog (net/core/dev.c:6761) __napi_poll.constprop.0 (net/core/dev.c:7830) net_rx_action (net/core/dev.c:7893 net/core/dev.c:8050) handle_softirqs (kernel/softirq.c:645) __irq_exit_rcu (kernel/softirq.c:679 kernel/softirq.c:519 kernel/softirq.c:758) irq_exit_rcu (kernel/softirq.c:775) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1062 (discriminator 35) arch/x86/kernel/apic/apic.c:1062 (discriminator 35)) RIP: 0010:tcp_cong_avoid_ai (net/ipv4/tcp_cong.c:482) Fix by checking if user pass in zero as parameter and if lock is present. Fixes: 814d488c6126 ("tcp: fix the timid additive increase on stretch ACKs") Cc: stable@vger.kernel.org Suggested-by: Eric Dumazet Reported-by: co+71b6509cb791e531@bugs.sh Signed-off-by: Kaho Jiang Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20261021235732.1313305-2-kj2864@nyu.edu Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 8e2fc3941b4005eaeef0a6b69b44a8a4941b57ab Author: Xiang Mei Date: Tue Sep 15 20:45:34 2026 -0700 media: go7007: only set audio_enabled if go7007_snd_init() succeeded commit 2eacf058d2dbb0ae3aaf576459da9e5f2b6bbfbd upstream. go7007_register_encoder() sets go->audio_enabled before calling go7007_snd_init() and discards its return value. go7007_snd_init() assigns go->snd_context only on success, so a failed ALSA setup leaves audio_enabled set with snd_context still NULL. The disconnect path tests audio_enabled and calls go7007_snd_remove(), which dereferences snd_context unconditionally. go7007_snd_init() returns -ENODEV once its never-decremented static card counter reaches SNDRV_CARDS, so SNDRV_CARDS attach/detach cycles arm the next attach; no memory pressure is needed. Set go->audio_enabled only once go7007_snd_init() has succeeded. Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: usb_hub_wq hub_event RIP: 0010:go7007_snd_remove (drivers/media/usb/go7007/snd-go7007.c:273) Call Trace: go7007_usb_disconnect (drivers/media/usb/go7007/go7007-usb.c:1336) usb_unbind_interface (drivers/usb/core/driver.c:461) device_remove (drivers/base/dd.c:618) device_release_driver_internal (drivers/base/dd.c:1349) bus_remove_device (drivers/base/bus.c:664) device_del (drivers/base/core.c:3965) usb_disable_device (drivers/usb/core/message.c:1478) usb_disconnect hub_event (drivers/usb/core/hub.c:5966) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3560) 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) Kernel panic - not syncing: Fatal exception Cc: stable@vger.kernel.org Fixes: 866b8695d67e ("Staging: add the go7007 video driver") Assisted-by: LLM Signed-off-by: Xiang Mei Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit dc0072c1b40fc376c6cbe821de947f3744ab254b Author: Xiang Mei Date: Sat Sep 12 17:29:45 2026 -0700 media: em28xx: reject audio endpoint with zero packet size commit aebfe430ba885d2f8fc882d7a6d60a7fdbe535d8 upstream. em28xx_audio_urb_init() divides by the audio endpoint's wMaxPacketSize without checking it, so a USB device that declares a zero-sized audio endpoint divides by zero at probe time. Reject a zero-sized audio endpoint like a missing one; the caller already unwinds on a negative return. Oops: divide error: 0000 [#1] SMP NOPTI Workqueue: usb_hub_wq hub_event RIP: 0010:em28xx_audio_init (drivers/media/usb/em28xx/em28xx-audio.c:718) Call Trace: em28xx_init_extension (drivers/media/usb/em28xx/em28xx-core.c:1248) em28xx_init_dev.isra.0 (drivers/media/usb/em28xx/em28xx-cards.c:3887) em28xx_usb_probe (drivers/media/usb/em28xx/em28xx-cards.c:4258) usb_probe_interface (drivers/usb/core/driver.c:396) ... usb_set_configuration (drivers/usb/core/message.c:2268) usb_generic_driver_probe (drivers/usb/core/generic.c:250) usb_probe_device (drivers/usb/core/driver.c:291) ... usb_new_device (drivers/usb/core/hub.c:2703) hub_event (drivers/usb/core/hub.c:5961) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) 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) Kernel panic - not syncing: Fatal exception Fixes: 1b3fd2d34266 ("[media] em28xx-audio: don't hardcode audio URB calculus") Cc: stable@vger.kernel.org Reported-by: co+9782320f78c23f40@bugs.sh Closes: https://lore.kernel.org/all/51lCz4R7QyTUKbh4mhXNaNzX0evpk0siOzbh%40bugs.sh/ Assisted-by: Claude:claude-opus-5 Signed-off-by: Xiang Mei Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 324d30da90f26286eccc3d8d20ceab927460d52a Author: Myeonghun Pak Date: Sun Sep 13 22:28:09 2026 -0400 media: cx88: Disable PCI device on MPEG initialization failure commit 80494a83223bc972145c23890b083d20651512bd upstream. cx8802_init_common() enables the PCI device, then returns directly if DMA mask setup or IRQ registration fails. cx8802_probe() frees the device and drops the shared core reference without disabling PCI. Disable the PCI device on both post-enable failures. Preserve -EIO for a DMA mask failure and the original request_irq() error. Do not call the full fini helper because the IRQ was not successfully requested. The successful probe and normal removal paths are unchanged. These missing error-path disables are present in the initial Git import. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Assisted-by: OpenAI:GPT-5.6 Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 04a04953b4828bfd8efd4ea3e7e9ad7dac5b083b Author: Xiang Mei Date: Mon Sep 14 18:42:43 2026 -0700 libceph: bound mon_command ack decode to front len commit 62b41a16d8603d4d809fda212f15c3e9c783a82b upstream. handle_command_ack() bounds the decode with msg->front_alloc_len, the size of the reply buffer, instead of msg->front.iov_len, the number of bytes the monitor sent. mon_alloc_msg() routes every CEPH_MSG_MON_COMMAND_ACK to get_generic_reply(), which returns the preallocated ->reply of whichever generic request carries the same tid, so the buffer keeps its fixed size however short the reply is. An ack with hdr.front_len below sizeof(struct ceph_mon_request_header) + sizeof(u32), including 0, still passes ceph_decode_need(), and ceph_decode_32() returns four bytes that were never received: uninitialized slab memory, stale bytes of an earlier message, or bytes the peer planted by sending a reply that lands in the same buffer and is then rejected. The read stays within the allocation, so KASAN does not flag it. req->result reaches userspace through ceph_monc_do_statfs(), ceph_monc_get_version() and ceph_monc_blocklist_add(); rbd hands it back from write() on /sys/bus/rbd/add_single_major, and rbd_get_client() passes it to ERR_PTR() unchecked, which faults: rbd: failed to get latest osdmap: -186318427 BUG: unable to handle page fault for address: fffffbfffe9ca034 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:do_rbd_add (drivers/block/rbd.c:7105) Call Trace: ... kernfs_fop_write_iter (fs/kernfs/file.c:345) vfs_write (fs/read_write.c:595 fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception Use msg->front.iov_len, matching handle_subscribe_ack(), handle_statfs_reply(), handle_get_version_reply() and handle_auth_reply(). A well-formed ack has front.iov_len >= 22 and is unaffected; a short one takes the existing bad: path. This applies commit d3c32939fa0e ("libceph: bound get_version reply decode to front len") to the last decode-side use of front_alloc_len in this file. Cc: stable@vger.kernel.org Fixes: 6305a3b41515 ("libceph: support for blacklisting clients") Reported-by: co+25860fb17af97289@bugs.sh Assisted-by: Cursor Signed-off-by: Xiang Mei Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit c93505aa0b2923c8116d3266b6708c94666eaa47 Author: Andrea Parri Date: Wed Sep 30 15:38:30 2026 +0200 kcsan: Avoid division by zero in kcsan_prandom_u32_max() commit 99b6fcce87037cfb6b5e177848342e97f5141205 upstream. KCSAN's skip_watch, udelay_task and udelay_interrupt parameters can be changed at runtime through /sys/module/kcsan/parameters/, where 0 means watching every access or not delaying at all. With the default CONFIG_KCSAN_SKIP_WATCH_RANDOMIZE=y and CONFIG_KCSAN_DELAY_RANDOMIZE=y, writing 0 to any of them makes the next watchpoint setup divide by zero: # echo 0 > /sys/module/kcsan/parameters/udelay_task Oops: divide error: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 93 Comm: sh Not tainted 7.3.0-rc5 #3 PREEMPT(lazy) RIP: 0010:kcsan_setup_watchpoint+0x1b5/0x410 Code: ... 65 89 05 ad 8d 98 02 d3 ee f6 29 d7 e8 22 0e 0f 01 ... RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 ... __show_trace_log_lvl+0x1bd/0x315 __die_body.cold+0x19/0x2b die+0x34/0x50 ... BUG: TASK stack guard page was hit at ffffd3ab001fbfe8 (...) reset_kcsan_skip() and delay_access() pass these values unchecked to kcsan_prandom_u32_max(), which returns "state % ep_ro". delay_access() halves the delay for compound and assert accesses, so udelay_interrupt=1 is enough there. The oops path runs instrumented code, which faults again until the stack overflows. With skip_watch=0 the guest hangs without printing anything. The division came in with commit 71a076f4a61a ("kcsan: Rewrite kcsan_prandom_u32_max() without prandom_u32_state()"). Before it, the helper scaled the random value with a multiply-shift, which yields 0 for ep_ro == 0. Go back to that via reciprocal_scale(). Tested in an x86-64 KCSAN guest with virtme-ng: after this patch, writing 0 to each parameter, or 1 to udelay_interrupt, no longer oopses. skip_watch=0 now watches every access, which is very slow with the default delays but completes when they are set to 0. Fixes: 71a076f4a61a ("kcsan: Rewrite kcsan_prandom_u32_max() without prandom_u32_state()") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Marco Elver Signed-off-by: Andrea Parri Signed-off-by: Marco Elver Signed-off-by: Greg Kroah-Hartman commit 068d3950e7180ee77faea2af617d32b8284e7d9f Author: Fang Xieyan Date: Thu Sep 17 18:43:06 2026 +0800 kcov: ignore an out-of-range comparison count in write_comp_data() commit f5263bee9eb84d2388fd7555a18d518e17226894 upstream. write_comp_data() reads the comparison record count from area[0] and uses it to index the coverage buffer: area = (u64 *)t->kcov_area; max_pos = t->kcov_size * sizeof(unsigned long); count = READ_ONCE(area[0]); /* Every record is KCOV_WORDS_PER_CMP 64-bit words. */ start_index = 1 + count * KCOV_WORDS_PER_CMP; end_pos = (start_index + KCOV_WORDS_PER_CMP) * sizeof(u64); if (likely(end_pos <= max_pos)) { The buffer is mmap'd writable into the collecting process, so count is under its control and end_pos <= max_pos is its only bound. A count that wraps the u64 multiply leaves end_pos below max_pos, so the check passes while the record store lands 24 bytes before the buffer, in the unmapped vmalloc guard page, and faults: BUG: unable to handle page fault for address: ffa0000000b60fe8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:write_comp_data+0x7e/0xa0 ... Kernel panic - not syncing: Fatal exception Bound count first: only max_pos / (sizeof(u64) * KCOV_WORDS_PER_CMP) records fit, so a larger count is not a valid index and is dropped. kcov_move_area() bounds the same untrusted count this way, and no count the end_pos <= max_pos check accepts reaches that limit, so no valid record is lost. kcov is a root-only debugfs file (debugfs_create_file_unsafe("kcov", 0600, ...)) and write_comp_data() exists only under CONFIG_KCOV_ENABLE_COMPARISONS, so this is a local, debug-kernel robustness fix: the process corrupts its own buffer and the kernel oopses. It crosses no privilege boundary. Additional details at [1] Link: https://lore.kernel.org/20260917104306.22145-1-fangxy@xiaopeng.com [1] Fixes: ded97d2c2b2c ("kcov: support comparison operands collection") Signed-off-by: Fang Xieyan Signed-off-by: Andrew Morton Reviewed-by: Alexander Potapenko Assisted-by: Hawkeye:GLM-5.3-flash Assisted-by: Qoder:Qwen3.8-Max Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Marco Elver Cc: Victor Chibotaru Cc: Signed-off-by: Greg Kroah-Hartman commit 61adcab593ff6bb806ba09df8c2c3d7e19edc908 Author: Xiang Mei Date: Thu Sep 10 16:51:09 2026 -0700 fuse: don't BUG when the copy buffer is exhausted commit c1338aae7b4054e26f322155423f6aba90aeea23 upstream. fuse_copy_fill() hits BUG_ON(!err) once the iterator backing the copy runs out of pages. Over io-uring the amount copied is not bounded by the payload buffer the server registered, so an unprivileged user can drain the iterator and panic the host - mount a FUSE filesystem with small payload buffers, then setxattr() a larger value: kernel BUG at fs/fuse/dev.c:1064! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 148 Comm: exploit Not tainted 7.3.0-rc1 #2 RIP: 0010:fuse_copy_fill (fs/fuse/dev.c:1033) Call Trace: fuse_copy_args (fs/fuse/dev.c:1354 fs/fuse/dev.c:1380) fuse_uring_args_to_ring (fs/fuse/dev_uring.c:891) fuse_uring_prepare_send (fs/fuse/dev_uring.c:940 fs/fuse/dev_uring.c:1057) fuse_uring_send_in_task (fs/fuse/dev_uring.c:1745) tctx_task_work_run (io_uring/tw.c:96) tctx_task_work (io_uring/tw.c:133) task_work_run (kernel/task_work.c:233) io_run_task_work (io_uring/tw.h:84) io_cqring_wait (io_uring/wait.c:278) __do_sys_io_uring_enter (io_uring/io_uring.c:2676) do_syscall_64 (arch/x86/entry/syscall_64.c:61) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The reply path can drain it the same way, via the server-supplied payload_sz in fuse_uring_copy_from_ring(). Return -EIO instead. All three fuse_copy_fill() callers already propagate the error. Fixes: c090c8abae4b ("fuse: Add io-uring sqe commit and fetch support") Cc: stable@vger.kernel.org Reported-by: Weiming Shi Suggested-by: Joanne Koong Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Joanne Koong Signed-off-by: Xiang Mei Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 49d7c1beac3810983869ed9260dcd444b6a51c8e Author: Yuanfu Xie Date: Wed Sep 30 15:09:45 2026 +0800 ceph: fail readdir when the MDS reply carries no dirfrag commit 728c856d7da04fb79f7aa00e974ffb6f55e55995 upstream. A ceph mount oopses in ceph_readdir() when the MDS answers a READDIR request with a reply whose extra blob is empty. parse_reply_info() skips reply blobs whose length is zero, so parse_reply_info_readdir() never runs, r_reply_info.dir_dir stays NULL, and the reply still parses as successful. ceph_mdsc_do_request() returns 0 and ceph_readdir() then reads rinfo->dir_dir->frag with no NULL check: /* extra */ ceph_decode_32_safe(&p, end, len, bad); if (len > 0) { ... err = parse_reply_info_extra(&p, p + len, req, features, s); ... } The oops on v7.3.0-rc4-00537-ga3ff15db6820, one getdents64(2) on the mount root after an ms_mode=legacy mount, trimmed: BUG: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 266 Comm: ls Tainted: G N 7.3.0-rc4-00537-ga3ff15db6820 #1 PREEMPT(lazy) RIP: 0010:ceph_readdir+0xbff/0x3ea0 Call Trace: ? __pfx_ceph_readdir+0x10/0x10 wrap_directory_iterator+0xa2/0xe0 iterate_dir+0x1da/0x5d0 __x64_sys_getdents64+0x13b/0x2a0 do_syscall_64+0xdd/0x4a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The unconditional frag read came in with 81c6aea5275ea ("ceph: handle frag mismatch between readdir request and reply"), so the bug is old. Treat a reply with no dirfrag as a protocol violation: warn once, drop the request and return -EIO, the same way ceph_readdir() already handles the two malformed-reply cases later in the function. Tested on v7.3.0-rc4-00537-ga3ff15db6820 (KASAN). Unpatched, the getdents64(2) above takes the machine down (oops=panic) on the first READDIR reply. With the patch it warns once and getdents64(2) returns -EIO, no oops, no hang. A conformant reply for an empty directory — dirfrag present, zero entries, FRAG_END|FRAG_COMPLETE — still lists "." and ".." and returns EOF on both kernels, so normal readdir behavior is unchanged. The oops is still present in v7.3-rc5 (72d3fcf802c45). Cc: stable@vger.kernel.org Fixes: 81c6aea5275ea ("ceph: handle frag mismatch between readdir request and reply") Signed-off-by: Yuanfu Xie Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 37c957fbc8ac0bfd85259b37f03e47006c8e35e8 Author: Baokun Li Date: Fri Oct 23 16:19:08 2026 +0800 blk-crypto: fix NULL deref and UAF in __blk_crypto_evict_key() commit c8c53d669d4e45b3a804013251a34387d7e11bfb upstream. Sashiko reported a possible NULL pointer dereference, triggered by the following flow: dm-inlinecrypt ctor # first use of the fallback ├─ blk_crypto_init_key() # succeeds, ctx->key.size != 0 ├─ blk_crypto_start_using_key() │ ├─ hw-wrapped key: -EOPNOTSUPP │ │ # profile never allocated (NULL) │ └─ raw key: fallback_start_using_mode() │ └─ blk_crypto_fallback_init() fails │ └─ kfree(profile) # not NULLed ├─ goto bad └─ inlinecrypt_dtr() # evicts whenever key.size is set └─ blk_crypto_evict_key() └─ blk_crypto_config_supported_natively() = false └─ blk_crypto_fallback_evict_key() └─ __blk_crypto_evict_key(blk_crypto_fallback_profile) └─ profile->num_slots # BOOM!!! This issue can be reproduced using the following commands: dd if=/dev/zero of=/tmp/backing bs=1M count=64 LOOP=$(losetup -f --show /tmp/backing) SZ=$(blockdev --getsz $LOOP) KEY=$(head -c 64 /dev/urandom | od -An -tx1 | tr -d ' \n') dmsetup create ic --table "0 $SZ inlinecrypt aes-xts-plain64 \ $KEY 0 $LOOP 0 1 keytype:hw-wrapped" And the following oops is triggered: ================================================================== blk-crypto: loop0: no support for wrapped keys Oops: general protection fault, probably for non-canonical address 0xdffffc000000000b: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000058-0x000000000000005f] CPU: 5 UID: 0 PID: 901 Comm: dmsetup 7.3.0-rc3 #1 PREEMPT(lazy) RIP: 0010:__blk_crypto_evict_key+0x2e/0x3b0 Call Trace: blk_crypto_evict_key+0x24c/0x320 inlinecrypt_dtr+0xf6/0x160 inlinecrypt_ctr+0x2d3/0xbd0 dm_table_add_target+0x661/0xf40 table_load+0x1c4/0x490 ctl_ioctl+0x32f/0x5f0 dm_ctl_ioctl+0xe/0x20 ================================================================== dm-inlinecrypt is the only caller that can evict a key that was never started, as fscrypt frees such a key without evicting it. Fix this by returning early from blk_crypto_fallback_evict_key() when tfms_inited[] is not set for the key's mode. tfms_inited[] is only set after blk_crypto_fallback_init() has successfully initialized the profile, so the crash above is no longer reachable. The bug has been latent since commit c984ff1423ae ("blk-crypto: dynamically allocate fallback profile") was merged in v6.5, and only became actually triggerable when commit e7f57d2c47e2 ("dm-inlinecrypt: add target for inline block device encryption") was merged in v7.2. Fixes: c984ff1423ae ("blk-crypto: dynamically allocate fallback profile") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://patch.msgid.link/sashiko-outbox-167341@kernel.org Suggested-by: Eric Biggers Link: https://patch.msgid.link/20261014155131.GB322435@quark Signed-off-by: Baokun Li Reviewed-by: Eric Biggers Link: https://patch.msgid.link/20261023081908.3505413-1-libaokun@linux.alibaba.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 277157864856d812c82f1ca8c156b392d368b8c7 Author: Karl Mehltretter Date: Sat Sep 26 17:06:03 2026 +0100 ARM: 9524/1: mm: align hugetlb mappings to the huge page size commit 1eb87d8f77379d4e4b279487b8c859fb64bd1afb upstream. mmap(MAP_HUGETLB) on 32-bit Arm can return an address which is not aligned to the huge page size. In a QEMU virt guest, unmapping the VMA then hits the alignment check in __unmap_hugepage_range(): kernel BUG at mm/hugetlb.c:5213! Internal error: Oops - BUG: 0 [#1] SMP ARM PC is at __unmap_hugepage_range+0x540/0x584 LR is at __zap_vma_range+0x13a0/0x1410 Commit 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags") made hugetlb mappings use the architecture's arch_get_unmapped_area(). The generic implementations handle hugetlb alignment, but the Arm implementations only account for the optional SHMLBA cache-colouring constraint. A 4 KiB-page kernel can therefore align the mapping to 4 KiB or 16 KiB instead of the required 2 MiB. Set the alignment mask from the file's hstate for hugetlb mappings in both Arm implementations. Huge-page alignment also satisfies the SHMLBA constraint. Assisted-by: LLM Fixes: 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags") Cc: stable@vger.kernel.org Acked-by: Muchun Song Link: https://lore.kernel.org/r/20260901085740.66283-1-kmehltretter@gmail.com/ Signed-off-by: Karl Mehltretter Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 5259a82b1ac101a983a6bb88a860fee80e8001ba Author: Rohinthan P Date: Wed Sep 23 12:50:50 2026 +0530 media: em28xx: use video_unregister_device for radio_dev [ Upstream commit 2579cbe68005f46fc7f8f95364f6b101b07b9d1c ] Commit 7c8bf63b7937 ("media: em28xx: use vb2_video_unregister_device") converted device unregistrations in em28xx to use vb2_video_unregister_device() instead of video_unregister_device(). However, radio devices do not have an associated videobuf2 queue (v4l2->radio_dev.queue is NULL). Calling vb2_video_unregister_device() on a radio device triggers a WARNING in vb2_video_unregister_device(): !vdev->queue WARNING: drivers/media/common/videobuf2/videobuf2-v4l2.c:1264 at vb2_video_unregister_device+0x1f8/0x200 Call Trace: em28xx_v4l2_init+0x1c39/0x3150 drivers/media/usb/em28xx/em28xx-video.c:3085 As documented in vb2_video_unregister_device(), video_unregister_device() should be used instead when vdev->queue is NULL. Revert to calling video_unregister_device() for v4l2->radio_dev in both em28xx_v4l2_fini() and the em28xx_v4l2_init() error unwind path. Fixes: 7c8bf63b7937 ("media: em28xx: use vb2_video_unregister_device") Reported-by: syzbot+f26bc23e42eeb548dee1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f26bc23e42eeb548dee1 Signed-off-by: Rohinthan P Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5712414af23936a01b48faefaafb93818fdfcc5b Author: Christian Brauner Date: Fri Oct 16 10:50:57 2026 +0200 Revert "namei: don't reveal overmounted entries in refwalk" [ Upstream commit 214897acc8c2e5d6b63189d23ccaed6fa2af45a9 ] This reverts commit 8189ab688f5a2c745dc90b63374da02f213d6994. This bug class is bigger than can be fixed with this simple patch. Back out of it and give us some time to fix this properly. Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit ebb9d776e297f388d01ca825ecb2d4308b57d6bf Author: Petr Mladek Date: Tue Oct 13 17:41:41 2026 +0200 nbcon/reboot: Switch NBCON consoles into the emergency mode in emergency_restart() [ Upstream commit d8e5fc3002294a28af53e97f6c83a35956e738f3 ] When the system is going down a normal way, the NBCON kthreads are flushed and stopped properly via a syscore shutdown callback, see printk_kthreads_shutdown(). One missing piece is emergency_restart() where the kthreads are not stopped. It might be called from several non-panic code paths, e.g. sysrq-o, kdb_reboot(), or some watchdogs. Fix it by explicitly entering the emergency (atomic) mode and trying to flush the consoles there. Note that printk_trigger_flush() must be used instead of pr_flush() because the later is not safe in an atomic context. Reported-by: kernel test robot Closes: https://lore.kernel.org/all/202608061008.48a1e76e-lkp@intel.com/ Suggested-by: John Ogness Reviewed-by: John Ogness Link: https://patch.msgid.link/20261013154141.94016-1-pmladek@suse.com Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 781ced4acf432d0f0865c54f70026c75148f41f1 Author: Michael Reeves Date: Tue Oct 6 18:03:15 2026 +1100 regmap: Remove debugfs before cache teardown [ Upstream commit 834035934cef9e60169de682f4dc9feafd49e51a ] regmap_exit() and regmap_reinit_cache() destroy the register cache before removing debugfs. A concurrent debugfs cache operation can therefore access cache state after the backend exit callback starts freeing it. Remove debugfs before cache teardown, and clear the debugfs pointer after removal. During cache reinitialization, recreate debugfs only after the new cache initializes successfully. Signed-off-by: Michael Reeves Reviewed-by: Peng Fan Link: https://patch.msgid.link/20261006-regcache-lifecycle-submit-v3-1-37bdd82fd47c@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4c6e3d81f8d49f5c8eca2bde4b07177903de62bf Author: Yong-Xuan Wang Date: Mon Oct 5 19:02:38 2026 -0600 RISC-V: errata: Add SiFive MAL-9092 workaround [ Upstream commit 148ab873d8194cb44f29474da3b4428fa2e100d1 ] SiFive cores with MAL-9092 require fence.rw instructions around HLV/HLVX/HSV hypervisor instructions to ensure proper memory ordering when accessing guest memory. Note that HSTATUS.HU is cleared during KVM initialization, restricting hypervisor instructions to HS-mode only. If future changes enable HSTATUS.HU for U-mode access, additional errata considerations will be needed. Signed-off-by: Yong-Xuan Wang Reviewed-by: Samuel Holland Link: https://patch.msgid.link/20260817-sifive-errata-v1-1-6a80f1a2743d@sifive.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit b213051fc40b1d25b705b03d29c49e169dca6fe7 Author: Jesse Zhang Date: Wed Sep 16 13:44:41 2026 +0800 drm/amdgpu/gfx11: set KMD_QUEUE for kernel gfx queues [ Upstream commit 8228688eb40cc116127e80394cb8157417854c70 ] Set KMD_QUEUE in the GFX MQD and kernel ring control registers so CP preserves kernel IB VMIDs instead of replacing them with the queue VMID. Use prop->kernel_queue to distinguish kernel and user MQDs. Signed-off-by: Jesse Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 893642e0e3b2f5aa818e0ee4a49e2d401d541e3a) Signed-off-by: Sasha Levin commit 771bdf5dd8b111f73c5de064fe80d19d5046c765 Author: Jesse Zhang Date: Wed Sep 16 13:44:27 2026 +0800 drm/amdgpu/gfx12: set KMD_QUEUE for kernel gfx queues [ Upstream commit 9fe5745f9d8eca38d31d9b672a1998edf856f651 ] Set KMD_QUEUE in the GFX MQD and kernel ring control registers so CP preserves kernel IB VMIDs instead of replacing them with the queue VMID. Use prop->kernel_queue to distinguish kernel and user MQDs. Signed-off-by: Jesse Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 14741c01680a803050e949744089b57fa53e02f7) Signed-off-by: Sasha Levin commit 4de130f28ae8cc497324d2ee7f81b30b425f956c Author: Matus Gajdos Date: Fri Oct 2 14:52:37 2026 +0200 ALSA: usb-audio: Add native DSD support for Cambridge Audio streamers [ Upstream commit 4e1462e7cd6a9b920f441842726cc2b9d232673e ] The Cambridge Audio streamer advertises the UAC2 RAW_DATA format on altsetting 2 of its playback interface, but without the DSD_RAW quirk flag the driver exposes it only as a SPECIAL format that cannot be used. Add QUIRK_FLAG_DSD_RAW for the device (USB ID 22e8:ca10), so the altsetting is exposed as DSD_U32_BE, enabling native DSD64/128/256 playback. Tested with: gst-launch-1.0 filesrc location=file.dsf ! \ avdemux_dsf ! dsdconvert ! \ alsasink device=hw:2,0 Signed-off-by: Matus Gajdos Link: https://patch.msgid.link/20261002125237.82188-1-matuszpd@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c1e50fa372a8bc1b8558a0f1fb52e1ceff404e54 Author: Jaidheer Sirigineedi Date: Fri Oct 2 13:59:51 2026 -0500 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg3xxx (103c:8bfd) [ Upstream commit 13dffca9043500ed6033d770b491a043fb952bc5 ] The mute LED on the HP Pavilion Laptop 15-eg3xxx (PCI SSID 103c:8bfd, Realtek ALC287) does not work because the machine has no entry in the quirk table. No fixup is applied, so the mute LED is never driven, even though the mute function itself works. The LED is controlled via GPIO pin 4 (mask 0x10), which is exactly what ALC287_FIXUP_HP_GPIO_LED configures. This was verified on the hardware with hda-verb: setting the GPIO data bit lights the mute LED, and clearing it turns the LED off. hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x10 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION 0x10 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x10 # LED on hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x00 # LED off Add a quirk entry for 103c:8bfd using ALC287_FIXUP_HP_GPIO_LED. Signed-off-by: Jaidheer Sirigineedi Link: https://patch.msgid.link/20261002185951.33855-1-jaidheer7@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ba06038fba12f20a824e6e0c7be5faa409c7f557 Author: Miquel Raynal Date: Thu Oct 1 17:14:44 2026 +0200 spi: cadence-qspi: Fix status polling with octal DTR chips [ Upstream commit fd99864b0ac936e870c7ae28354c5cd3dad5efd0 ] Most SPI NOR chips today use 0x05 as ReaD Status Register (RDSR) opcode. After almost every transaction, the core will wait for the said transation to be digested by the chip by polling its status register. This mechanism has been automated by certain chips, such as the Cadence QSPI controller. Unfortunately, the feature has been disabled for various (relevant) reasons. Disabling this feature has been done by setting WRITE_COMPLETION_CTRL_REG.DISABLE_POLLING_FLD, keeping the rest of the register intact. In this same register, there is also a field named WRITE_COMPLETION_CTRL_REG.OPCODE_FLD, which by default also contains 0x05, as primary RDSR opcode. As a result, both the SPI NOR and SPI NAND cores, primary users through spi-mem of the spi_mem_ops interface, do send their own RDSR. In this driver, such command goes through one of the fifth possible data path specifically crafted for short register-like commands, named STIG. In STIG mode, the opcode of the operation is written to OSPI_FLASH_CMD_CTRL_REG. This means that the opcode field of STIG configuration and the opcode field of the automatic polling configuration contain the same value. Unfortunately, the TRM explains in two different places that this configuration is forbidden, without explaining why it is problematic: $12.4.2.4.11 OSPI Software-Triggered Instruction Generator (STIG) ``` OSPI_FLASH_CMD_CTRL_REG[31-24] CMD_OPCODE_FLD bits should be set different than OSPI_DEV_INSTR_RD_CONFIG_REG[7-0] RD_OPCODE_NON_XIP_FLD and OSPI_DEV_INSTR_WR_CONFIG_REG[7-0] WR_OPCODE_FLD. ``` and $12.4.2.5.2 Configuring the OSPI Controller for Optimal Use ``` When using the OSPI Controller, the opcodes in OSPI_DEV_INSTR_RD_CONFIG_REG[7-0] RD_OPCODE_NON_XIP_FLD, OSPI_DEV_INSTR_WR_CONFIG_REG[7-0] WR_OPCODE_FLD and OSPI_WRITE_COMPLETION_CTRL_REG[7-0] OPCODE_FLD bit fields shall not match the opcode in the OSPI_FLASH_CMD_CTRL_REG[31-24] CMD_OPCODE_FLD bit field. ``` For some reasons, this is only unveiled now when testing in ODTR mode. Plain SDR modes work flawlessly with the same chips. One possible reason for this, is that the internal data path in ODTR mode is very different due to the extra opcode extension/repetition which may be interpreted differently (this is a wild guess). For sure there is an interference, as even the TRM states that there is some magic happening: $12.4.2.4.13 OSPI Command Translation ``` The WREN and the RDSR device instructions are the only ones that are sent by the controller under the hood. ``` I cannot probe the bus when the problem arises, so I don't know exactly what is sent on the bus. Practically speaking, the chip was driving the lines low (reading all 0s), which is not the usual default state when the chip is not driving the lines (all 1s). Other people on the mailing list claimed successfully using ODTR chips with this controller. My take here is that either they were using a variant of the IP without write completion at all (there is a quirk for it), or they were using chips slightly more flexible about their opcode sequency or maybe with different addr/dummy requirements. Clearing the WRITE_COMPLETION_CTRL_REG.OPCODE_FLD while disabling write completion polling entirely seems the best compromise. Signed-off-by: Miquel Raynal Link: https://patch.msgid.link/20261001-winbond-spi-next-cadence-rdsr-fix-v1-1-ec5ff594ba5d@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 60f0adc41d88682fef4ececd80045ddb73f41baa Author: Zeyu Li <13776528859@163.com> Date: Sat Sep 26 22:03:36 2026 +0800 ALSA: hda/realtek: Add ALC235 support for headset mode [ Upstream commit 9ee4266827cfb67b9fbb89136ea6a8f3d7809f5c ] The ALC235 (0x10ec0235) is registered as the ALC255 codec variant in patch_alc269(), but the headset mode functions were missing a case for it, so the CTIA/OMTP jack type detection and routing never ran on this codec. As a result, a plugged-in headset is detected (jack presence works) but the microphone signal is never routed, leaving the capture stream permanently silent. Verified on an ASUS M5451GA laptop (HDA:10ec0235,10431814): with the ALC255 coef sequence applied, the headset microphone works correctly. Signed-off-by: Zeyu Li <13776528859@163.com> Link: https://patch.msgid.link/20260926140336.27896-1-13776528859@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 13c12f98618d8dd170dce7b4daa6210637b7c2c1 Author: Eckhart Mohr Date: Thu Oct 1 20:34:00 2026 +0200 ALSA: hda/realtek: Add quirk for ASRock NUC BOX-358H [ Upstream commit 9a44b828dd7c0be1d0d6d6cf178d9727ceb6da6e ] Fix headphone jack detection for some devices Signed-off-by: Eckhart Mohr Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20261001183403.103990-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 96e38c6a49f58c023f4d5ccfd955510d2b74f4a1 Author: Reinhard Speyerer Date: Fri Sep 25 15:14:32 2026 +0200 net: usb: qmi_wwan: add Rolling Wireless RN947R [ Upstream commit 7375d38364a9aa66fb31716bcefef38aecad75d8 ] Add Rolling Wireless RN947R 0x9300 composition: DIAG + ADB + NMEA + MODEM + RMNET + QDSS + ADPL T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=33f8 ProdID=9300 Rev= 0.00 S: Manufacturer=Rolling Wireless S: Product=RN947R S: SerialNumber=xxxxxxxxxxx C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#=21 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none) E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#=22 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none) E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Reinhard Speyerer Link: https://patch.msgid.link/arZzuOOvLUZtdOlv@arcor.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ec1ea7f38d6de78d0f6d3da1187ee9f21fef132 Author: Vladimir Murzin Date: Tue Sep 22 11:37:56 2026 +0100 usb: mtu3: Fix double dereference in TP_printk [ Upstream commit cfb3293c4573289f11f913611f530ea6b1926d67 ] Paul reported kernel splat: [ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_set_halt has double dereference in TP_printk: &REC->gpd_ring->dma [ 0.000000] ------------[ cut here ]------------ [ 0.000000] Event mtu3_gadget_ep_set_halt has double dereference in TP_printk: &REC->gpd_ring->dma [ 0.000000] WARNING: kernel/trace/trace_events.c:420 at test_double_dereference+0x144/0x14c, CPU#0: swapper/0/0 [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.3.0-rc1 #15247 PREEMPT [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : test_double_dereference+0x144/0x14c [ 0.000000] lr : test_double_dereference+0x144/0x14c [ 0.000000] sp : ffffc80aa7633bf0 [ 0.000000] x29: ffffc80aa7633bf0 x28: ffffc80aa7c0f047 x27: 000508b58019388f [ 0.000000] x26: 0000000000000003 x25: 0000000000000007 x24: ffffc80aa5fceff8 [ 0.000000] x23: ffffc80aa7c0f05a x22: ffffc80aa64edfe8 x21: ffffc80aa7c0fce8 [ 0.000000] x20: ffffc80aa7c0f047 x19: 0000000000000013 x18: 0000000000000001 [ 0.000000] x17: 6572656420656c62 x16: 756f642073616820 x15: 746c61685f746573 [ 0.000000] x14: 0000000000000000 x13: ffff000139d90000 x12: 0000000000000045 [ 0.000000] x11: 00000000000000cf x10: ffff00013f546428 x9 : ffff000139d90000 [ 0.000000] x8 : 3fffffffffffc000 x7 : 0000000000000001 x6 : 0000000000000001 [ 0.000000] x5 : ffff00013f4e6440 x4 : 0000000000000000 x3 : 0000000000000000 [ 0.000000] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffc80aa764a700 [ 0.000000] Call trace: [ 0.000000] test_double_dereference+0x144/0x14c (P) [ 0.000000] trace_event_raw_init+0x37c/0x5d8 [ 0.000000] event_init+0x34/0xc0 [ 0.000000] trace_event_init+0xec/0x588 [ 0.000000] trace_init+0x24/0x6e0 [ 0.000000] start_kernel+0x4a0/0x8ec [ 0.000000] __primary_switched+0x88/0x90 [ 0.000000] irq event stamp: 0 [ 0.000000] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 0.000000] hardirqs last disabled at (0): [<0000000000000000>] 0x0 [ 0.000000] softirqs last enabled at (0): [<0000000000000000>] 0x0 [ 0.000000] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_disable has double dereference in TP_printk: &REC->gpd_ring->dma [ 0.000000] TRACE EVENT ERROR: Event mtu3_gadget_ep_enable has double dereference in TP_printk: &REC->gpd_ring->dma Which also observed by Mark and myself. The splat it result of new check introduced by b5cc230af5e5 ("tracing: Warn when an event dereferences a pointer in TP_printk()") which correctly catches issue with %pad dereferencing the address saved in the ring buffer. TP_fast_assign() logic gets executed when the tracepoint is triggered, however the TP_printk() is executed when the user reads the trace buffer which could be seconds, minutes, hours, days, even months later and nothing guarantee that __entry->gpd_ring pointer will still be pointing to what it was when it was recorded. Fix the issue by capturing immediate value of gpd_ring.dma when trace point is triggered. Reported-by: Paul E. McKenney Tested-by: Mark Rutland Reviewed-by: Steven Rostedt Signed-off-by: Vladimir Murzin Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit a6c911aa993bf979ff2ea53e80c12f3dbbe22cf9 Author: renpanpan Date: Wed Sep 30 14:55:04 2026 +0800 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 14-dv1001TU [ Upstream commit ece609abc95cc0f75e633d93f3d868b030d9a8fe ] The HP Pavilion 14-dv1001TU (subsystem ID 103c:8987) uses a Realtek ALC287 codec. The mute LED on this machine is controlled by GPIO bit 0x10, which was verified via hda-verb, but the subsystem ID is missing from the quirk table. As a result, the ALC287_FIXUP_HP_GPIO_LED fixup that drives GPIO 0x10 is never applied and the mute LED stays off even though the associated LED class device toggles correctly. Add the missing SND_PCI_QUIRK entry to map this subsystem ID to ALC287_FIXUP_HP_GPIO_LED so the mute LED works as expected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221810 Signed-off-by: renpanpan Link: https://patch.msgid.link/20260930065504.24151-1-rppxj178543@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b639fb18ad69035c9ca0c0dcd88bbb5a3dc33f49 Author: Muhtasham Nawr al-Mahmud Date: Thu Sep 24 20:45:12 2026 +0600 ALSA: hda/realtek: Fix speakers on ASUS PM3406CHA [ Upstream commit 0eee030c2c09c7a44be778de5f451d9e7a2f09c1 ] The ASUS ExpertBook PM3406CHA uses an ALC256 codec with subsystem ID 1043:1664. On Linux boot, the internal speakers are silent even though playback is routed to the codec and the speaker pin is configured for output. The codec starts with coefficient 0x10 set to 0x1d20. Writing 0x7f20 to coefficient 0x10 immediately restores internal speaker output. This was reproduced on the affected hardware from a fresh boot using hda-verb. Reducing a larger initialization sequence showed that this coefficient write alone is sufficient; no GPIO, EAPD, pin-control, or other coefficient changes are required. After applying the coefficient in userspace, speaker output also remains functional across suspend and resume. Add a machine-specific HDA fixup that writes the required coefficient. The fixup has been compile-tested, but could not be boot-tested because the affected hardware is no longer available. Closes: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2162718 Signed-off-by: Muhtasham Nawr al-Mahmud Link: https://patch.msgid.link/20260924144512.3989-1-muhtaseem2005@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 022127b8df54997648b34d2c7d5b3b207526544c Author: Zhang Heng Date: Mon Sep 21 20:44:50 2026 +0800 ALSA: hda/realtek: Add quirk for Acer Nitro AN515-45 [ Upstream commit 0d90a929836344f1d3b39f22f08ccecc62378a59 ] The Acer Nitro AN515-45 requires ALC2XX_FIXUP_HEADSET_MIC to make the headset microphone work properly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221925 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260921124450.639601-2-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3b75fa0871d32647fa3e4d18447950e5ae48041c Author: Krish Gulati Date: Mon Sep 21 18:47:03 2026 +0530 ALSA: hda/realtek: Add mute LED quirk for HP Victus 15-fb2xxx [ Upstream commit c748c42abb9b549fc79c41ea55e1f220eadb60ec ] The HP Victus 15-fb2xxx (PCI SSID 103c:8c2f) with the ALC245 codec does not turn on the mute LED when audio is muted. Add a quirk entry to enable it. Reported-by: erph.briones27@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=221946 Signed-off-by: Krish Gulati Tested-by: Raphael Briones Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260921131728.8999-1-krishgulati7@gmail.com Signed-off-by: Sasha Levin commit 14d1a67641d350040479f03131033d7911245ee6 Author: Tarun Noonemunthala Date: Wed Sep 23 15:10:14 2026 +0530 ALSA: hda/realtek: Add quirk for HP ENVY 13-aq1xxx [ Upstream commit a01a223bd685be42e908d970de32eeb3646097f3 ] The HP ENVY Laptop 13-aq1xxx (PCI SSID 103c:86ad) uses an ALC285 codec with two speaker pairs: front (pin 0x14) and bottom (pin 0x17). The BIOS leaves pin 0x14 as [N/A] ("not connected"), so the generic parser never enables the front pair and only the bottom speakers are audible. The vendor driver (RTKVHD64.sys) programs that pin with the value 0x90170150 and runs the HP amplifier initialization, which is already implemented in the driver as ALC285_FIXUP_HP_GPIO_AMP_INIT. Add a board fixup that applies the pin configuration for 0x14 and chains to the existing amplifier init fixup. The pin value was recovered from the vendor driver's own configuration data. The patch and this changelog were prepared with an AI coding assistant (see the Assisted-by tag below); the change was reviewed and tested by the submitter on the affected machine. Tested on an HP ENVY 13-aq1xxx by rebuilding snd-hda-codec-alc269 from the Fedora 7.1.10 source and loading it: the codec now reports "line_outs=2 (0x14/0x17)", pin 0x14 comes up as an output (Pin-ctls 0x40) with its amplifier unmuted, and both speaker pairs play. Assisted-by: OpenCode:deepseek-v4.1-flash checkpatch Signed-off-by: Tarun Noonemunthala Link: https://patch.msgid.link/20260923094014.58867-1-ntarun2000@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 634410e636357abaf6a3954396246ae074b2aafc Author: Luis Banha Date: Tue Sep 22 00:01:05 2026 +0100 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-ec1xxx [ Upstream commit 775aa96c310d59f3d15a6e5a9bd1796fd1ba95ec ] The mute LED on the HP Pavilion Gaming Laptop 15-ec1xxx (103c:87b2) does not work automatically. Add the ALC285_FIXUP_HP_MUTE_LED quirk to fix this behavior. Signed-off-by: Luis Banha Link: https://patch.msgid.link/20260921230105.16844-1-luisbanha26@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 359096b8ff07f45a19f181531eff9589e297bffe Author: Zhang Heng Date: Mon Sep 21 20:44:49 2026 +0800 ALSA: hda/realtek: Add quirk for Lenovo ThinkBook G8+ [ Upstream commit 4322ac247f4ce7932edbd46aa37f3dae62cde424 ] Fix Bass Speaker volume control on Lenovo ThinkBook G8+ by adding quirk 17aa:38dc with ALC285_FIXUP_SPEAKER2_TO_DAC1. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221799 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260921124450.639601-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1e2dd3f061e0d7ca57b100ed49cf5cbf99591d32 Author: KIM MinWoo Date: Wed Sep 23 10:37:56 2026 +0900 ALSA: hda/realtek: Add quirk for Lenovo ThinkBook 16p Gen 3 ARH (21EK) [ Upstream commit 3867e38b2d4b844d89076f988c7b9741c87a9858 ] The ThinkBook 16p Gen 3 ARH (SSID 17aa:3871) has a TI TAS2563 amplifier device on I2C, exposed by ACPI as INT8866, the same arrangement as the Yoga 7 14ARB7 (SSID 17aa:3870). Without a quirk, the codec falls back to the vendor-wide Lenovo quirk (ALC269_FIXUP_LENOVO_XPAD_ACPI), the amplifier is never bound, and the internal speakers stay silent while the headphone output works. Reuse the Yoga 7 14ARB7 fixup, which binds the INT8866 device as a side codec. ALC287_FIXUP_TAS2781_I2C does not work on this machine because it looks for a TIAS2781 device. Assisted-by: LLM Signed-off-by: KIM MinWoo Link: https://patch.msgid.link/20260923013756.106033-1-phrimm136@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 888a43640be370c10dd1a701075a93f4d914dd09 Author: Tomasz Bojanowski Date: Wed Sep 23 20:49:57 2026 +0200 ALSA: usb-audio: Add mixer mapping for MSI MAG B850M MORTAR WIFI [ Upstream commit 7b457ae8cf711831f19d20963f5ed2fdf4842d3a ] The USB audio device 0db0:cc78 (Realtek ALC4080) on the MSI MAG B850M MORTAR WIFI motherboard exposes all playback controls as "PCM", which makes it hard to tell the outputs apart. Its mixer layout matches the one of the MSI MPG X570S Carbon Max Wifi (units 29, 30 and 32), so reuse msi_mpg_x570s_carbon_max_wifi_alc4080_map for this device too. With the mapping applied, the controls show up as "Speaker", "Front Headphone" and "IEC958". Tested with a patched snd-usb-audio module on a 7.2.7 kernel. Signed-off-by: Tomasz Bojanowski Link: https://patch.msgid.link/20260923184957.6687-1-tomasz@bojanowski.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 654906c34da2bc27dd0d62c95b53f579d8ceb928 Author: Hernan Ganzo Date: Mon Sep 21 21:55:38 2026 +0100 ALSA: hda/realtek: Limit internal mic boost on HP Pavilion 15 (103c:2164) [ Upstream commit 786fb6b3f513937f712db5a9ba6a12cbc6982ba9 ] The HP Pavilion 15 with the ALC3227 codec (SSID 103c:2164) exposes the full four-step internal mic boost on pin 0x12: nsteps=3 with stepsize=0x2f, that is 0, 12, 24 and 36 dB. Combined with the ADC capture gain of +30 dB the analogue cascade reaches 66 dB, and the internal microphone clips on the ambient noise of a quiet room; the upper two steps are unusable at any useful input level. This is the defect class ALC269_FIXUP_LIMIT_INT_MIC_BOOST exists for. The machine matches no SSID quirk and falls through to the pin table, which selects ALC269_FIXUP_HP_MUTE_LED_MIC1 through a pin signature shared with several other HP models. Add an SSID entry instead, using ALC269_FIXUP_LIMIT_INT_MIC_BOOST_MUTE_LED: the existing fixup that applies alc269_fixup_limit_int_mic_boost() and chains to the same mute LED fixup, as already done for 103c:218b. The boost becomes 0 or 12 dB and the LED handling is unchanged. Tested on the affected machine by selecting the same fixup through the model string (snd-hda-intel.model), which bypasses the SSID and pin tables, with the driver confirming the selection: snd_hda_codec_alc269 hdaudioC1D0: ALC3227: picked fixup limit-mic-boost (model specified) With that, Internal Mic Boost reports Limits 0 - 1 (0 or 12 dB) instead of 0 - 3 (0 to 36 dB), so alc269_fixup_limit_int_mic_boost() clamps this codec's internal mic pin as intended. Note that /proc/asound/card1/codec#0 keeps printing the unclamped hardware caps (nsteps=0x03): that file reads codec parameters uncached by design, while the fixup overrides the driver's cached parameter that the control is built from. This does not by itself make the default capture volume sane -- the remaining 12 dB on top of the +30 dB ADC gain is still hotter than this machine's usable operating point. It removes the two unusable steps from the hardware range, which is what a quirk of this class can do. Signed-off-by: Hernan Ganzo Link: https://patch.msgid.link/20260921205538.41192-1-gp@sneemgp.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0ce65d3accd68a6a672bfc6ea46932cbe20c6b08 Author: Christian Brauner Date: Wed Sep 23 14:28:00 2026 +0200 docs: update the unmount propagation rule [ Upstream commit 3f5dc09141a7bfe286620a6869d1d70ffe32d6b8 ] Section 5f still describes the rule propagate_umount() used before commit f0d0ba19985d ("Rewrite of propagate_umount()"). It states that a mount that receives the unmount by propagation is left alone as soon as it has any submount. That's not true anymore. A propagated unmount unmounts a mount with sub-mounts as long as every sub-mount gets unmounted together with it. This is the case when the sub-mounts are unmounted by the same propagation. Only a sub-mount that cannot be unmounted keeps its parent mounted. The section also only describes a single mount without sub-mounts. But lazy unmounts take a tree and every mount of the tree propagates its unmount from its parent mount. Link: https://patch.msgid.link/20260923-work-mount-fixes-v1-8-f424cf8d3242@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit bf4fde54d928dff3b81e3fc10947899863d6ff9e Author: Eric Dumazet Date: Mon Sep 14 16:48:53 2026 +0900 nvme-tcp: delay nvme_tcp_reclassify_socket() [ Upstream commit 447a7a3026eda85ac2738cbe6ee5ab066a39dad0 ] Commit 841aee4d75f1 ("nvme-tcp: lockdep: annotate in-kernel sockets") introduced nvme_tcp_reclassify_socket() to resolve a lockdep WARN by distinguishing userspace sockets from nvme-tcp sockets. After that, TLS encryption support was introduced to nvme-tcp and it added another lock dependency on userspace socket handling by tlshd, which resulted in a new lockdep WARN. This WARN was hidden by the commit 19bdb70c77d3 ("nvme-tcp: lockdep: use dynamic lockdep keys per socket instance"). However, it turned out the commit 19bdb70c77d3 has a bug of lockdep key lifetime management, and it is to be reverted by another patch in this series. After the revert, the WARN was unveiled and observed at the blktests test case nvme/062: WARNING: possible circular locking dependency detected 7.3.0-rc2+ #455 Tainted: G W ------------------------------------------------------ tlshd/75867 is trying to acquire lock: ffffffff91ada5e0 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x64/0x6d0 but task is already holding lock: ffff888197808258 (sk_lock-AF_INET-NVME){+.+.}-{0:0}, at: do_tcp_setsockopt+0x499/0x26a0 which lock already depends on the new lock. To fix the lockdep WARN caused by the TLS encryption support, delay the reclassification of the nvme-tcp sockets. Currently the reclassification happens before the TLS handshake starts, which pulls in the additional lock dependencies related to tlshd. Reclassify the sockets after the TLS handshake instead, to cut that dependency. Link: https://lore.kernel.org/lkml/CANn89i+wnTLC==UnXCpjsS4YxvEfhe5oK0N7fttbqr1zKyqdug@mail.gmail.com/ Reviewed-by: Nilay Shroff Signed-off-by: Eric Dumazet Signed-off-by: Shin'ichiro Kawasaki Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 93449e64cdee84f1c3a9746d4f2186673fd694fa Author: Jasper Firth Date: Fri Sep 25 23:06:25 2026 +1000 ASoC: Intel: bytcr_rt5651: Add quirk for Chuwi Hi8 with generic DMI strings [ Upstream commit c5a8fc2abe05cf6db71f57ff0177fddc59861a1a ] Some Chuwi Hi8 tablets with model number CWI513 ship with a BIOS (American Megatrends 5.11, dated 05/21/2016) whose DMI sys_vendor and product_name are both "Default string". The tested unit is labelled just "Hi8", but its model number is the same as the existing "Chuwi Hi8 Pro (CWI513)" entry, and it needs the same quirks. That entry matches on sys_vendor "Hampoo" and product_name "X1D3_C806N", so it never applies to these units. Without its quirks the internal speaker, whose amplifier has a differential input wired across LOUT left and right, cancels to a faint distorted residual for any centred (L == R) content, and the headphone channels are swapped. Add an entry matching board_vendor "Hampoo" and board_name "Cherry Trail CR", plus the BIOS date since those two are too generic on their own. drivers/platform/x86/touchscreen_dmi.c already matches the Chuwi HiBook the same way. The quirks are those of the existing Hi8 Pro entry, except for the over-current detection scale factor: 1.0 instead of the 0.75 from BYT_RT5651_DEFAULT_QUIRKS. With 0.75 and a CTIA headset (inline mic and one button), loud speech into the mic, and headphone playback coupling onto the mic line, were reported as spurious KEY_PLAYPAUSE presses, one of them held for a whole 8 second speech window. With 1.0 the same test gave no spurious events, and 3 real button presses were reported as exactly 3 press/release pairs. Tested on a unit with the generic DMI strings, with a module built from this patch and no quirk module parameter. The quirks were applied via the new entry, the card components read "cfg-spk:1 cfg-mic:in2 cfg-hp:lrswap", and the following all work: speaker, headphone left/right order, jack and headset-mic detection, headset button, and the internal and headset mics. The problem was diagnosed with the help of an AI coding assistant, which also drafted this changelog. Assisted-by: Claude Opus 5.5 Signed-off-by: Jasper Firth Link: https://patch.msgid.link/20260925-hi8-quirk-v1-1-ffd00b0447f9@hotmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2a6254baab5cb17d95ef8323d16ce67867004d1d Author: Even Xu Date: Tue Sep 22 10:46:37 2026 +0800 HID: Intel-thc-hid: Intel-quicki2c: Fix buffer overflow [ Upstream commit 5e5c3b9db1c5910d6a9175c97b76a95566e4dc32 ] The input and output buffers are used to store complete HID-over-I2C packets, including their protocol headers. However, their sizes are currently calculated from the payload length only. Allocate enough space for both the payload and the packet header to prevent a buffer overflow when the payload reaches its maximum size. Signed-off-by: Even Xu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c6e94c4f31025a6acf82827034db255b7ddeff49 Author: Even Xu Date: Tue Sep 22 10:46:38 2026 +0800 HID: Intel-thc-hid: Intel-quickspi: Fix buffer overflow [ Upstream commit a1cdd72371270640bd357bd3e3b2ec0be17c9536 ] The input buffers are used to store complete HID-over-SPI packets, including their protocol headers. However, their sizes are currently calculated from the payload length only. Allocate enough space for both the payload and the packet header to prevent a buffer overflow when the payload reaches its maximum size. Signed-off-by: Even Xu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 874ef161d968489579a9fb67982bf85b351c98e7 Author: Tomasz Pakuła Date: Tue Sep 22 15:17:58 2026 +0200 HID: universal-pidff: Add support for Turtle Beach VelocityOne Race [ Upstream commit 53f7f7955a684e820bdd6bd6792c45c4b434f637 ] Add usb VID and device PID to hid-ids.h Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a66633b2171ac447b2f154e940e3f9ad8596ce80 Author: Daniel Ortiz Date: Sat Sep 19 20:19:20 2026 -0500 ASoC: amd: yc: Add DMI quirk for Lenovo V15 G6 ARP [ Upstream commit d395e1b62d9694f2e4add9122f8d473eacd374aa ] The Lenovo V15 G6 ARP (product name 83UU) uses the ACP6x PDM interface for its internal digital microphone array. Its firmware exposes neither the AcpDmicConnected _DSD property nor the _WOV method, so acp6x_probe() falls through to the DMI check and returns -ENODEV, leaving acp_yc_mach.0 unbound and no capture device registered. Add a DMI quirk entry for this model. With it, the machine driver binds and the DMIC capture device is created: acp_yc_mach acp_yc_mach.0: Enabling ACP DMIC support via DMI card 2: acp6x [acp6x], device 0: DMIC capture dmic-hifi-0 Capture was verified working with arecord and PipeWire. Signed-off-by: Daniel Ortiz Link: https://patch.msgid.link/20260920011920.2482786-1-letargopausado@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 43d6e9c812edcd8feebdc07485fe958308f9cfa7 Author: Andy Moreton Date: Wed Sep 16 13:56:41 2026 +0100 sfc: add X4D PF support [ Upstream commit 24fedc7a569bce181728f0dd616504bef9f1513b ] X4D is an X4 controller instance as an IP block in an SoC. It has the same feature set as X4. Signed-off-by: Andy Moreton Reviewed-by: Pieter Jansen van Vuuren Reviewed-by: Alejandro Lucero Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260916125641.12238-1-alucerop@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 257610f2b6d8bfb7f4057f70df5fc7f75f9b7342 Author: Rosen Penev Date: Mon Sep 14 17:44:06 2026 -0700 gpio: mvebu: keep resume masks within the irqchip cache [ Upstream commit 02af7eac17bc62a72335c1fc8c4af4471654f6cc ] mvebu_gpio_resume() writes the edge/level mask registers saved at suspend time straight back to hardware, bypassing the irqchip's mask_cache_priv. genirq skips mask_irq() for a line it already considers masked, so restoring a bit in hardware that genirq thinks is still masked leaves that line unmasked behind genirq's back. An asserted level line then has nobody to ack it, and the moment interrupts are re-enabled the chained handler storms, hanging resume. AND the restored mask values with the matching irqchip mask cache so only lines genirq currently considers unmasked are unmasked again. Read the caches under gc->lock to keep them consistent with the mask/unmask handlers. Tested on Helios4 (armhf): 5 suspend cycles woken by magic packet, no hang; mvebu_gpio_resume() returns in 6 usecs. Assisted-by: LLM Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20260915004406.115230-1-rosenp@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 88b0f77c612654475dfb9d4b7b2e3795fb4f8d5b Author: Seiji Adachi Date: Thu Sep 17 22:18:51 2026 +0900 ASoC: amd: yc: Add Lenovo ThinkPad E16 Gen 2 (21JN) to quirks [ Upstream commit 4cae4ca34992d210d115e8e891f1e88c9df5f24c ] Signed-off-by: Seiji Adachi Link: https://patch.msgid.link/20260917131851.2122144-1-seiji_adachi@yahoo.co.jp Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2c7a144e9e077bc5aad3059adc38770f0fc289a6 Author: Ewan D. Milne Date: Tue Sep 15 13:38:00 2026 -0400 scsi: devinfo: Add BLIST_SKIP_IO_HINTS for EMC Symmetrix [ Upstream commit f06a44e235ef188689ba23ffc72e9e89b10951a9 ] EMC Symmetrix returns an error on MODE SENSE for page 0Ah subpage 05h because it does not implement the SBC-5 I/O hints. These commands began to be sent as a result of commit 4f53138fffc2 ("scsi: sd: Translate data lifetime information"). Add BLIST_SKIP_IO_HINTS to avoid sending these commands because in large configurations the failed commands are displacing other useful information in internal error logs. Signed-off-by: Ewan D. Milne Link: https://patch.msgid.link/20260915173800.39117-1-emilne@redhat.com Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 7e2fa3109c1fba7556ac1c3a2e08b25e906f6185 Author: Dmitry Antipov Date: Wed Sep 2 12:45:49 2026 +0300 HID: roccat: fix locking in roccat_connect() and roccat_disconnect() [ Upstream commit d76994443eed0af297cb82bd038ae9d76327ef90 ] Extend critical section in roccat_connect() to ensure that partially initialized 'struct roccat_device' is never exposed in 'devices' list, and do the same in roccat_disconnect() to avoid racy 'devices' access against roccat_release(). Signed-off-by: Dmitry Antipov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 7076e590e98f748239ca39043ecaee7d88813099 Author: Maurizio Lombardi Date: Tue Sep 8 16:34:34 2026 +0200 nvme-fc: do not warn on controller removal race [ Upstream commit 62b70e6c87121ae5b79ca20c3a5b005590336ec5 ] In nvme_fc_reconnect_or_delete(), the system attempts to remove the controller when reconnect limits are reached by calling nvme_delete_ctrl(). This call is currently wrapped in a WARN_ON(). If a user concurrently deletes the controller via sysfs, the controller's state may have already transitioned out of the CONNECTING state. When this happens, nvme_delete_ctrl() correctly rejects the operation and returns -EBUSY. Because of the WARN_ON() wrapper, this race condition triggers an unnecessary kernel warning stack trace. Remove the WARN_ON() macro around nvme_delete_ctrl(); this allows the system to safely ignore the -EBUSY return value if the controller is already being deleted. Signed-off-by: Maurizio Lombardi Reviewed-by: Daniel Wagner Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit bd351a43669053363d2f4a9263e962ba86e7a713 Author: Berke Durak Date: Mon Sep 7 11:47:19 2026 -0700 HID: elecom: Add support for ELECOM M-XT4DRBK (018E) [ Upstream commit f3c2b266b8fd7cf816d36168d19f67e716f2c080 ] The 2025 revision of the left-handed EX-G wireless trackball (M-XT4DRBK-G) reports USB ID 056e:018e instead of 056e:00fd. Its report descriptor declares an 8-bit button field (Report Count 8) but only five usages (Usage Maximum 5), so the sixth (Fn) button ends up as a duplicate of button 5 and is unusable. The report descriptor has the same layout as the M-XT3DRBK 018C (button usage maximum at offset 16, button report count at 22, button report size at 24, padding report size at 30), so reuse that fixup. Rename the existing M_XT4DRBK define to M_XT4DRBK_00FD to match the convention used for the other EX-G revisions. Tested on a Raspberry Pi 5 with the same fixup in an out-of-tree module on 6.12 (6.12.96+rpt-rpi-2712); all six buttons are reported after the fix, and they work (tested with xev as well). Report descriptor as sent by the device, pre-fix (056e:018e, 215 bytes): 05 01 09 02 A1 01 09 01 A1 00 85 01 05 09 19 01 29 05 15 00 25 01 95 08 75 01 81 02 95 01 75 00 81 01 05 01 09 30 09 31 16 00 80 26 FF 7F 75 10 95 02 81 06 C0 A1 00 05 01 09 38 15 81 25 7F 75 08 95 01 81 06 C0 A1 00 05 0C 0A 38 02 95 01 75 08 15 81 25 7F 81 06 C0 C0 06 01 FF 09 00 A1 01 85 02 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0 05 0C 09 01 A1 01 85 05 15 00 26 3C 02 19 00 2A 3C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85 03 19 81 29 83 15 00 25 01 95 03 75 01 81 02 95 01 75 05 81 01 C0 06 BC FF 09 88 A1 01 85 04 95 01 75 08 15 00 26 FF 00 19 00 2A FF 00 81 00 C0 06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00 75 08 95 07 B1 02 C0 Assisted-by: LLM Signed-off-by: Berke Durak Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0b034e308564cd5b690fb83d912787501486ab78 Author: Oleg Keri Date: Thu Sep 10 08:30:50 2026 +0200 HID: i2c-hid: add reset quirk for Lenovo Yoga Slim 7x Gen 11 keyboard [ Upstream commit 39e8e085710a2d36d9ceade11739fb7b87f5aeb0 ] The ITE controller behind the keyboard of the Lenovo Yoga Slim 7x Gen 11 (048d:83db) carries out a reset but never raises the interrupt that acknowledges it. i2c_hid_finish_hwreset() therefore waits out its full one second timeout and logs "device did not ack reset within 1000 ms" on every probe and every resume, before the keyboard comes up regardless. Set I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for it, as is already done for several other ITE parts, so the reset is followed by a fixed 100 ms sleep instead. Signed-off-by: Oleg Keri Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit aac2603cd82977601e3e6fad71e9b3353dc85c57 Author: Youth Cao Date: Fri Sep 4 00:14:44 2026 +0800 HID: i2c-hid: Add i2c-hid-quirk-bad-input-size quirk for 0911:5288 device [ Upstream commit 58d97b45f3f43af0afd9c74e8480d22d36fd3f72 ] I have recently acquired a cheap Apollo Lake-based laptop that uses a Hynitron CST128-A touchpad controller. While booting from a Debian LiveCD, the kernel log is flooded with the following error (though the touchpad works well): i2c_hid_acpi i2c-ALPS0001:00: i2c_hid_get_input: incomplete report (27/42405) The CST128-A was identified via ACPI as ALPS0001:00, and the I2C HID device ID (0911:5288) was shared with the Hantick 5288. Add the I2C_HID_QUIRK_BAD_INPUT_SIZE quirk option to the existing Hantick 5288 quirk entry to suppress the kernel log flood. Signed-off-by: Youth Cao Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 3f89968d6aee399addd1fda4ec546753b8ff7c2e Author: Mark Brown Date: Tue Sep 1 22:55:42 2026 +0100 regmap: irq: Free the irqdomain we create [ Upstream commit 2e42cade8ff1ff579e77976d9869db4df1feaf74 ] When domain support was added to regmap-irq it was not possible to remove domains, this was added later by 8ee99ada293b (irqdomain: Support removal of IRQ domains.). We did update the main removal path to free the domain but forgot the error unwinding case during creation that is now in regmap_add_irq_chip_fwnode() after some code motion, meaning that errors during instantiation result in an unused irqchip being left hanging around. Add the missing irq_remove_domain() call where the comment says it should be. Reported-by: Farhad Alemi Reported-by: Thomas Gleixner Link: https://patch.msgid.link/20260901-regmap-irq-deallocate-domain-v1-1-4bfed4aff559@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit aa8d2e53bee52b7bd4b77ab26321125180bf7d21 Author: Namjae Jeon Date: Sat Jul 11 23:20:41 2026 +0900 ksmbd: handle allocated range queries on dense files [ Upstream commit 350684e0498512d06963858b810101f58563810b ] FSCTL_QUERY_ALLOCATED_RANGES currently relies on SEEK_DATA and SEEK_HOLE for every file. That works for files with holes, but it is not a good match for dense files. A zeroed range in a dense file may be represented as an unwritten extent and skipped by SEEK_DATA. The server can then return no allocated ranges even though the file should still be treated as allocated from the protocol point of view. For dense files, report the requested range clipped to EOF as allocated instead of probing holes. Keep using SEEK_DATA and SEEK_HOLE for files marked with FILE_ATTRIBUTE_SPARSE_FILE, and wait for writeback before probing so punch-hole updates are visible to the filesystem seek implementation. This fixes the case where a query after zeroing data could return no ranges for a dense file. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6938950bd00aa1e8956d62fa94bcca44890b59a9 Author: Fernando Fernandez Mancera Date: Mon Jun 1 21:30:46 2026 +0200 netfilter: tproxy: use DEBUG_NET_WARN_ON_ONCE for protocol fallbacks [ Upstream commit 1f0391aea883e99d402d0f77ba3530e4e879350d ] Replace WARN_ON calls with DEBUG_NET_WARN_ON_ONCE in the default switch blocks of nf_tproxy_get_sock_v4 and v6. Unsupported transport protocols are already safely handled by returning a NULL socket pointer. This prevents unnecessary system panics when panic_on_warn=1 is enabled in production systems. Link: https://patch.msgid.link/cover.1786968834.git.zhilinz@nebusec.ai/ Signed-off-by: Fernando Fernandez Mancera Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit f08a043321aa8e6d4c32c0df0fe6025b29841414 Author: Xiubo Li Date: Tue Jul 14 14:20:37 2026 +0800 ceph: fix use-after-dereference of NULL ci in __ceph_remove_cap() [ Upstream commit a354d7eaa1a57f1532c8072a424cc2d339a73cc0 ] The NULL check for "ci" in __ceph_remove_cap() was dead code because ci was dereferenced via &ci->netfs.inode before the check, and cap->session was dereferenced via session->s_mdsc->fsc->client even earlier. On a double-remove, both cap->ci and cap->session are set to NULL by the first call, so the second call would crash before ever reaching the guard. Move ci, session, cl, and inode initializations after the NULL check so that the early-return actually works. Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit e3b41c907cb3352a1d9594cb64779934ccaf6a2f Author: Mehmet Aysel Date: Tue Aug 25 12:24:31 2026 +0300 ASoC: amd: acp-config: Add HVY-WXX9/M1060 DMI quirk [ Upstream commit 032bb633e0c34a88b70a4bfc65ebd4e2b510f706 ] Add DMI match table entry for HUAWEI HVY-WXX9 board, product version M1060, a MateBook D16 2021 (Ryzen 5 4600H) revision not covered by the existing M1010/M1020/M1040 entries. This board uses the same FLAG_AMD_LEGACY / ACP_PCI_DEV_ID configuration as the other HVY-WXX9 variants. Signed-off-by: Mehmet Aysel Link: https://patch.msgid.link/20260825092432.56292-1-mehmet4ysel@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2aeb9dce7d76c9edab40820bb1a3aa263290973d Author: Bob Song Date: Wed Aug 26 19:53:44 2026 +0800 ALSA: hda/conexant: Always enable the headset-mic pin on plugin [ Upstream commit 9642a5e843758686e02a7f0d1df9eb0f7f96603c ] Rename the function to cx_process_headset_detect_plug_type() to reflect that it only reports the detected plug type, and move the pin control write into cx_update_headset_mic_vref() so that node 0x19 is always set to enable the headset mic with the 80% VREF whenever the mic is present, regardless of the type detection result. Signed-off-by: Bob Song Link: https://patch.msgid.link/20260826115344.2128835-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1fa62b20936a9021502bc6317c94102282e66827 Author: Xiubo Li Date: Thu Jul 23 14:28:19 2026 +0800 ceph: do not cache negative dentries for snapped directories [ Upstream commit af59562a5b3d34fb3aa7753f2543393578d06dbf ] When a LOOKUP/LOOKUPSNAP in a snapped directory returns ENOENT without a trace, ceph_finish_lookup() creates a negative dentry via d_add(dentry, NULL). For live directories this is fine — the dentry naturally expires. But for snapped directories, ceph_d_revalidate() unconditionally trusts all cached dentries (valid = 1), so a negative dentry created by a transient error persists forever, hiding entries that genuinely exist in the snapshot. Only cache negative dentries for live (non-snapshotted) parent directories. For snapped parents, skip the negative dentry so that VFS retries the lookup on the next access. Since the conditions that trigger a negative dentry (MDS transient error, local ENOENT shortcut, or MDS null dentry lease) are all rare in snapped directories, the performance impact of this change is negligible. Link: https://tracker.ceph.com/issues/78529 Reported-by: Andras Pataki Signed-off-by: Xiubo Li Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit d2176dd74e28f61b5b025ff64b443b22d8d2830c Author: Mehmet Aysel Date: Tue Aug 25 12:24:32 2026 +0300 ASoC: amd: acp3x-es83xx: Add HVY-WXX9/M1060 DMI quirk [ Upstream commit c1a39c228aceebc0ede83781ea906d257e324009 ] Add matching DMI table entry for the ES83xx machine driver, so the HUAWEI HVY-WXX9 / M1060 board (MateBook D16 2021, Ryzen 5 4600H) can successfully probe its ES8316 codec via the acp3x-es83xx machine driver, consistent with the existing M1010/M1020/M1040 entries for the same board name. Signed-off-by: Mehmet Aysel Link: https://patch.msgid.link/20260825092432.56292-2-mehmet4ysel@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 498f2b22fb4a89dbecd79c4286d99cce98b5dbf7 Author: Federico Valentín Andrade Date: Mon Aug 24 11:02:11 2026 -0300 ALSA: usb-audio: Skip mixer creation on M-Audio Venom [ Upstream commit 4c0ec35e011309bd7091053ad5bbc01420967a66 ] The M-Audio Venom (0763:2084) does not answer any GET_CUR request of its feature units, hanging up the USB microcontroller and "responding" with timeouts. So the mixer building lasts around 47 seconds, and the device does not stream at all. The same GET_CUR requests issued through libusb (with no kernel driver bound) complete correctly and blazingly fast. So it seems to only happen during the initial probe. I defined an explicit composite quirk to bypass the mixer creation, as it is not needed (the synth already comes with volume controls). With both this and the device flag applied, the synth works flawlessly. Signed-off-by: Federico Valentín Andrade Link: https://patch.msgid.link/20260824140211.17003-3-fandrade@frba.utn.edu.ar Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f71c9aa7c0d07c9c3a39642fd3c3c6b0cd8a29ce Author: Karl Mehltretter Date: Sun Jul 12 20:32:34 2026 +0200 tpm: atmel: depend on X86 [ Upstream commit 4bfacee94f309346bef0b598ea091088b9150af9 ] tpm_atmel probes for the chip at fixed x86 Super-I/O ports (0x4e) with inb()/outb(), so it only works on x86. TCG_ATMEL nevertheless depends only on HAS_IOPORT_MAP/HAS_IOPORT, which arm and arm64 also satisfy. There the probe is useless, and on platforms whose unbacked I/O access faults it oopses in init_atmel() at boot (e.g. arm/versatile): Unable to handle kernel paging request at virtual address fee0004e PC is at init_atmel+0x34/0x244 TCG_NSC and TCG_TIS already "depends on X86" (commit 2f592f2a7d74 ("TPM: NSC and TIS drivers X86 dependency fix")); TCG_ATMEL was missed. Add the same dependency. Signed-off-by: Karl Mehltretter Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260712183234.23125-1-kmehltretter@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 115270245d39b659b00721b6c14c7d15f53b5183 Author: Li Jun Date: Wed Aug 12 18:09:14 2026 +0800 tpm: tpm_tis_spi: fix nodef CR50 tpm_tis_spi_resume is null [ Upstream commit b4d1adc70471d0752bba674552d19971ed9fa869 ] if no define CONFIG_TCG_TIS_SPI_CR50 in config, the add of tpm_tis_spi_resume is null, this cause the tpm chip to fail to resume. Signed-off-by: Li Jun Link: https://lore.kernel.org/r/20260812100914.3540149-1-lijun01@kylinos.cn Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit a9b39298d6db729fccd839576ce88b2986a16ea8 Author: Dave Carey Date: Thu Jul 30 08:43:36 2026 -0400 HID: multitouch: Fix stale MT slots when contact count drops to zero [ Upstream commit e8e60b6439eed340a611e9d7a5b9bcbd0ef62725 ] The INGENIC 17EF:6161 touchscreen (Lenovo Yoga Book 9 14IAH10) reports HID_DG_CONTACTCOUNT=0 in the frame immediately following the last finger lift rather than omitting the frame entirely. In mt_touch_report() the existing code only updates num_expected when contact_count is non-zero, so a zero contact count on the first packet of a new frame leaves num_expected at its previous value (e.g. 2 for a two-finger gesture). The sync check "num_received >= num_expected" then evaluates "0 >= 2" and never fires, preventing INPUT_MT_DROP_UNUSED from releasing the stale slots. Those slots remain active in the kernel MT layer until the next touch, at which point they are released in a batch alongside the new contact — causing the userspace event consumer to miss the intervening finger-up sequence and corrupt its gesture session state. Fix by resetting num_expected to 0 when contact_count is zero and num_received is still 0 (i.e., this is the first and only packet of the frame, not a continuation packet in a multi-packet sequence). With num_expected=0 the sync check "0 >= 0" fires immediately, calling input_mt_sync_frame() which drops the stale slots via INPUT_MT_DROP_UNUSED. The num_received==0 guard is critical: continuation packets in a multi-packet frame arrive after at least one contact has already been processed (num_received>0), so they are correctly excluded from this path and the existing multi-packet logic is unaffected. Signed-off-by: Dave Carey Tested-by: Dave Carey Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit cd95f97f3cd2c34ed9b5bc8b82dd98ffc0b1f3fa Author: Vadim Klishko Date: Mon Jul 27 22:17:18 2026 -0600 HID: i2c-hid: Add a quirk for a Cirque I2C device. [ Upstream commit 1c942462c3969b287a86ab6dbb143324289d564e ] Cirque touchpads with PID D0C1 generate an error when probed by the I2C HID driver, resulting in no hidraw device created. Adding I2C_HID_QUIRK_NO_IRQ_AFTER_RESET fixes the issue. Signed-off-by: Vadim Klishko Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 18f4f406663b4bcffc403c0a7bd6a558c5e8fd6f Author: Zhang Heng Date: Mon Aug 24 21:03:02 2026 +0800 ASoC: amd: yc: Add DMI entry for Alienware m18 R1 AMD [ Upstream commit fd8ed52ecea6b93e23d52cb2758fb4fb4029067f ] Add DMI entry so the YC machine driver probes on this model and the internal DMIC works. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221485 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260824130302.553419-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ce5368025a427efebc16cba9626cd3fde0f6d4c0 Author: Jimmy Zuber Date: Mon Aug 24 14:30:51 2026 +0000 fuse: zero the partial EOF page when extending a file [ Upstream commit 34b5c4a6e4fb9dbb3f9d87f3b0fb0372105c8302 ] Extending a fuse file past a non-page-aligned EOF does not zero the tail of the old last page. When that page is cached and has been mmap-dirtied beyond the old EOF, the now in-bounds tail is served to later reads as stale data rather than zeros, which violates POSIX file-extension semantics. Some file systems get this zeroing automatically at writeback time (block_write_full_folio() / iomap_writeback_handle_eof() zero the tail of the folio straddling i_size). A non-writeback caching fuse file system uses neither path, so it has to zero the tail itself from the size-extending paths, like XFS (xfs_file_write_zero_eof()) and ext4 (ext4_block_zero_eof()) do. Call truncate_pagecache_range() over the newly-exposed range up front from the three paths that extend a file, before the new size is published: - a buffered write whose position is past the old EOF (fuse_perform_write()); - a size-extending setattr/truncate (fuse_do_setattr()); - a size-extending fallocate (fuse_file_fallocate()). This unmaps the stale mappings and zeroes the partial tail of the old EOF folio, so a later read returns zeros. Truncating [old EOF, write start) before a buffered write keeps the dropped range disjoint from the written data, so a write that lands inside the old EOF folio is preserved. writeback_cache connections are unaffected, as their writes go through iomap_file_buffered_write(), which zeroes post-EOF folios. The bug is observable on a non-writeback_cache server that returns FOPEN_KEEP_CACHE on writable files (without FOPEN_DIRECT_IO), and is caught by the new write_extend_eof fuse selftest. Signed-off-by: Jimmy Zuber Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 74460c60c40e927a77018bd27785227f26693833 Author: Zhang Heng Date: Mon Aug 24 20:37:52 2026 +0800 ALSA: hda/realtek: Add quirk for Lenovo IdeaPad Slim 3 15ABR8 [ Upstream commit be79a45e2ec289eb9fad519e8f5a3d4fc3789dd0 ] The internal microphone on Lenovo IdeaPad Slim 3 15ABR8 (subsystem 17aa:3862) exhibits severe distortion at default gain levels. The Capture Volume is fixed at 63 (max) and cannot be lowered without explicit userspace intervention. The existing fixup ALC269_FIXUP_LIMIT_INT_MIC_BOOST limits the gain range and resolves the issue. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221891 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260824123752.525173-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d1687e52368c510ea984ce9e384dd3ead5e3f637 Author: Md Rabbani Date: Fri Aug 21 11:57:18 2026 +0600 net: stmmac: fix device node reference leaks in stmmac_mtl_setup() [ Upstream commit 317fe168f4c0fc30e5c375c22d9c8911940aea9b ] In stmmac_mtl_setup(), q_node is shared across the RX and TX queue parsing loops. When the RX queue loop breaks early because the number of parsed queues reaches plat->rx_queues_to_use, q_node retains an acquired reference count. If the error check passes (queue == plat->rx_queues_to_use), execution proceeds directly to the TX queue loop, where of_get_next_child() immediately overwrites q_node with the first TX child, permanently leaking the retained RX child device node reference. Switch both loops to for_each_child_of_node_scoped() so child node references are automatically dropped upon loop exit or early break, and remove the now-unnecessary function-scoped q_node variable and its manual of_node_put() at the exit label. Signed-off-by: Md Rabbani Link: https://patch.msgid.link/20260821055718.57-1-rabbanyhmm@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 14222a8d56295659a6ab0b1d925ae0e15d9f5595 Author: Sumeet Pawnikar Date: Sat Aug 22 15:16:57 2026 +0530 powercap: intel_rapl: Fix kernel panic during PMU unbind [ Upstream commit 916b61abba586d950a4d8264e2841cc5ccfa4df1 ] rapl_package_add_pmu() fails internally at perf_pmu_register(), and rapl_pmu_update() leaves the global rapl_pmu.pmu structure zero-initialized via memset and returns an error. But any previously probed packages retain has_pmu = true. When the driver is subsequently unbound or removed, rapl_package_remove_pmu_locked() sees has_pmu == true and unconditionally calls perf_pmu_unregister(&rapl_pmu.pmu) on the zeroed-out structure. This attempts a list_del_rcu() on a NULL list head, immediately causing a kernel panic. Fix this by checking if the PMU is actually registered before attempting to unregister it. Signed-off-by: Sumeet Pawnikar Reviewed-by: Abel Vesa [ rjw: Added empty line after the new conditional ] Link: https://patch.msgid.link/20260822094657.12489-1-sumeet4linux@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 582a89109ad98566d54e913d78bdca9f526a7b4f Author: Helge Deller Date: Sat Aug 22 12:03:15 2026 +0200 fbcon: Fix KASAN slab-out-of-bounds Read in fbcon_prepare_logo [ Upstream commit 94e6a058b16820e02f25e1221a4c4e713ba23550 ] Ensure the logo will not exceed the screen size, which then should fix a reported KASAN: slab-out-of-bounds Read in fbcon_prepare_logo. Reported-by: syzbot+0c815b25cdb3678e7083@syzkaller.appspotmail.com Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 855236abde29727de86a39fa7b2371098f166f6b Author: Shiji Yang Date: Wed Aug 19 21:07:07 2026 +0800 net: ethernet: mtk_wed: increase WED v2 WDMA RESV_BUFF to 0x80 [ Upstream commit c0ef04232f9fac083c3d8a77ce58ba32243e6734 ] Change WDMA RESV_BUFF from 0x40 to 0x80 to avoid CDM TX FIFO overflow. Without this patch mt7986 and mt7981 may have WDMA TX hang issue. This patch was pulled from mtk-openwrt-feeds GPL open source project. Link: https://github.com/mediatek/mtk-openwrt-feeds/commit/07c87502e854b68b48544d101b6fe17ec059b97b Signed-off-by: Shiji Yang Reviewed-by: Simon Horman Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/OSZPR01MB779537889255E2F606E47EABBCA52@OSZPR01MB7795.jpnprd01.prod.outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c3d7738b2665a6dab47bd72c29a87ffd38c33de5 Author: Jenson Johnathon Reggentin Date: Wed Aug 19 21:23:59 2026 +0200 docs: block: fix dead http link in blk-mq.rst [ Upstream commit b40a680ea4efe4ef2addada63e304a94d19500d1 ] The current link http://kernel.dk/blk-mq.pdf leads to a 404 error page. https://www.kernel.dk/blk-mq.pdf leads to the correct document. v2 to add the missing www. prefix in the actual file change. Signed-off-by: Jenson Johnathon Reggentin Acked-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260819192422.42189-1-mail@jregg.de> Signed-off-by: Sasha Levin commit 0337af8a6c39d6cdb9d8b500e351cb9461c4b9c0 Author: Chen Changcheng Date: Mon Jul 27 15:34:38 2026 +0800 scsi: snic: Fix SCSI host leak on workqueue allocation failure [ Upstream commit 12e67eb89eb2b9516685c744d3f7de0a2d1bd701 ] In snic_add_host(), if scsi_add_host() succeeds but alloc_ordered_workqueue() fails, the function returns -ENOMEM with shost->work_q left as NULL. The caller's error path then calls snic_del_host(), which returns early when !shost->work_q without calling scsi_remove_host(). The Scsi_Host remains registered in sysfs as a zombie device even after the probe has failed. This causes: - The leaked host remains visible in /sys/class/scsi_host/ after probe failure, with state "running". - Subsequent SCSI host numbering is permanently shifted (the leaked host ID from ida_alloc() is never reclaimed). - Memory leak: the Scsi_Host allocation can never be freed because device_add() took a reference that can only be released by device_del() inside scsi_remove_host(). Fix by adding scsi_remove_host() in the workqueue allocation failure path inside snic_add_host(), undoing the successful scsi_add_host() before returning the error. This is cleaner than modifying snic_del_host() because snic_del_host() is called from a shared error label that also serves paths where snic_add_host() was never invoked. Reproducer (requires no real SNIC hardware): - Build CONFIG_SCSI_SNIC=y (built-in) - Add snic.test_mode=1 snic.inject_wq_fail=1 to kernel cmdline - Boot with a PCI device matching the snic driver (e.g. QEMU edu device, PCI ID 0x1234:0x11e8, temporarily added to the driver's PCI ID table) Before the fix: # /sys/class/scsi_host/ contains a zombie host0: $ cat /sys/class/scsi_host/host0/proc_name snic_scsi $ cat /sys/class/scsi_host/host0/state running # ata_piix gets host1, host2 (host0 stuck): scsi host1: ata_piix scsi host2: ata_piix After the fix: # host0 is properly freed and reused by ata_piix: scsi host0: ata_piix scsi host1: ata_piix # No zombie host in /sys/class/scsi_host/ Signed-off-by: Chen Changcheng Acked-by: Narsimhulu Musini Link: https://patch.msgid.link/20260727073438.209673-1-chenchangcheng@kylinos.cn Signed-off-by: Martin K. Petersen (Oracle) Signed-off-by: Sasha Levin commit 15f26d38bcf58ade0b9b52a68fb8564a0f8453c7 Author: Will Porter Date: Sat Aug 22 20:53:53 2026 -0500 ALSA: usb-audio: Add iD14 MkI to monitor-mix volume quirk [ Upstream commit 17056a36d276a740f09dca723de1bc6aa3eb4ef9 ] Add the iD14 MkI USB ID to the existing audient_id14_map. This names feature unit 12 Monitor Mix Playback Volume. Live meter A/B testing on MkI USB ID 2708:0002 reproduced the same asymmetric attenuation seen on MkII. At ALSA value 104, the right channel was 23.07 dB below the left. At 127, both channels were equal. The misleading Speaker Playback Volume name causes PipeWire to adopt FU12 as the stream master. Reuse the existing map to keep the control available while preventing that selection. Hardware-tested on Bazzite 7.2.0-ogc4.1.fc44.x86_64 with this change backported. ALSA exposed Monitor Mix Playback Volume after module load and USB reconnect. PipeWire volume changes from 100% to 35% and back left all four FU12 values at 127. Channel-isolated left/right playback remained balanced after reconnect. Build-tested with CONFIG_SND_USB_AUDIO=m using the focused sound/usb target. Assisted-by: Codex:gpt-5 Signed-off-by: Will Porter Link: https://patch.msgid.link/20260823015353.686080-1-mrwillporter@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 75e1a1c2738a29adf5da44c19b552703dcd0b91a Author: Csaba Budai Date: Fri Aug 21 12:25:14 2026 +0200 ALSA: hda/realtek: Fix ALC700 audio on Intel Hades Canyon [ Upstream commit 1fcccdc20a76b4639b00124cf2a379b837bd2bf7 ] On Intel Hades Canyon systems with an ALC700 codec, analog audio can become unusable after rebooting from Windows into Linux. The affected system uses codec subsystem ID 8086:2073. In the broken state, Realtek coefficient 0x1b has value 0x4a4b. Setting bit 0x0400 changes it to 0x4e4b and immediately restores normal analog playback. The BIOS also sets this bit after disabling and re-enabling onboard audio, while Windows may leave it cleared. Linux currently does not restore it during codec initialization. Add a machine-specific fixup for Intel Hades Canyon which sets only bit 0x0400 of coefficient 0x1b during HDA_FIXUP_ACT_INIT. The fix has been verified across Windows -> Linux reboots on an Intel NUC8i7HNB with an ALC700 codec. Signed-off-by: Csaba Budai Link: https://patch.msgid.link/20260821102514.11194-1-ilyr73@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e0414672a6878b1bade5fe6e04b45667e79d21dc Author: Daeho Jeong Date: Thu Aug 20 09:43:40 2026 -0700 f2fs: avoid setting SBI_NEED_FSCK on transient resize failure [ Upstream commit 258c95150c26a30db1896eacd3bdef26314f2ca1 ] When free_segment_range() fails in f2fs_resize_fs(), no on-disk superblock or filesystem metadata has been modified yet, and free_segment_range() safely restores all in-memory counters before returning. However, the current error recovery path unconditionally sets the SBI_NEED_FSCK flag and prints a scary error message on any error, forcing an unnecessary and time-consuming fsck.f2fs repair on the subsequent mount/reboot. Fix this by separating the error recovery path with a dedicated recover_user_blocks label to bypass setting SBI_NEED_FSCK on free_segment_range() failures. Signed-off-by: Daeho Jeong Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 167b5e23acf63ea754e98de06827905cd88df5a8 Author: Robin Everaars Date: Mon Aug 17 14:14:17 2026 +0000 ACPI: button: Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch [ Upstream commit 415125669c2ddc773c579a60df108f75712dfa83 ] The lid switch reports "close" but can miss the matching "open", leaving _LID closed after resume. systemd-logind then suspends the system again roughly every 35 seconds. Reading the embedded controller's PSTA byte while _LID is stale shows that bit 0x04 is set, which the DSDT treats as open. The DSDT returns the cached LIDS byte from _LID. Its wake path aborts in RTEC on an unhandled SystemCMOS region before copying PSTA to LIDS. Initialize the lid state to open on resume, matching the existing quirk for the Razer Blade Stealth 13 late 2019. With button.lid_init_state=open, a physical close suspended once and resume reported open without another suspend. Signed-off-by: Robin Everaars Link: https://patch.msgid.link/20260817141414.213075-1-robineveraars@pm.me Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 59f9c4989e6acfb949f87deea646bd184f2d4595 Author: Tao Cui Date: Fri Aug 14 22:41:16 2026 +0800 sched_ext/scx_flatcg: expire cached hweights on weight changes [ Upstream commit 94c20e1fb334c2082b443c4470a86ad982f67282 ] fcg_cgroup_set_weight() updates cgc->weight and the parent's child_weight_sum but doesn't bump hweight_gen, so the hweights cached by cgrp_refresh_hweight() stay stale until some task activation bumps the generation. For cgroups whose tasks never go through a 0->n runnable transition (e.g. persistently busy ones), a cpu.weight change never propagates to scheduling at all. Bump hweight_gen on weight changes so the next refresh recomputes with the new weight. Verified on a flatcg VM: a live cpu.weight 100->800 change on a busy cgroup leaves HWT update at 0 and the distribution unchanged; with it, hweight_gen increments and the refresh recomputes. Signed-off-by: Tao Cui Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b78a4334a8927d4dcc692382a45b420109bcb071 Author: Namjae Jeon Date: Wed Aug 19 10:01:11 2026 +0900 ksmbd: enable TCP keepalive for accepted connections [ Upstream commit 56549c18a4f75309161ca780feaa4d17904e3ee9 ] A client that disappears without sending a FIN or RST can leave its ksmbd connection in ESTABLISHED indefinitely. ksmbd sets a socket receive timeout, but the connection receive loop retries timeout errors without a limit, so the connection remains in conn_list and consumes the per-IP connection quota. Enable SO_KEEPALIVE on accepted TCP sockets so the TCP stack can detect a silent peer failure. The keepalive idle time, interval, and probe count remain controlled by the existing TCP sysctl settings. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 890a3b249d461e2cf732898576722524faf194f5 Author: BingKun Yue Date: Mon Aug 17 14:39:42 2026 +0800 fbdev: platinumfb: add error checking for ioremap calls [ Upstream commit ba13226fc966004713aed47931db8922b84d1960 ] The ioremap() and ioremap_wt() calls in platinumfb_probe() were not checked for failure. If any of these mappings fail, the driver would dereference NULL pointers, leading to a kernel panic. Add proper error checking and use goto-based cleanup to avoid code duplication across the error paths. Signed-off-by: BingKun Yue Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit a4467fbe41147b347a6c2d738afcc4ad79b6d45f Author: Randy Dunlap Date: Thu Aug 13 16:29:34 2026 -0700 fbdev: maxine: fix 64-bit build error [ Upstream commit 3adec5c640dc09dca5605043e138412fd5a0629d ] The KSEG1ADDR() macro is only defined for non-64BIT builds. Use the CKSEG1ADDR() macro instead. In file included from ../drivers/video/fbdev/maxinefb.c:34: ../drivers/video/fbdev/maxinefb.c: In function 'maxinefb_ims332_write_register': ../include/video/maxinefb.h:16:41: error: implicit declaration of function 'KSEG1ADDR'; did you mean 'CKSEG1ADDR'? [-Wimplicit-function-declaration] 16 | #define MAXINEFB_IMS332_ADDRESS KSEG1ADDR(0x1c140000) ../drivers/video/fbdev/maxinefb.c:66:49: note: in expansion of macro 'MAXINEFB_IMS332_ADDRESS' 66 | register unsigned char *regs = (char *) MAXINEFB_IMS332_ADDRESS; ../drivers/video/fbdev/maxinefb.c:66:40: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 66 | register unsigned char *regs = (char *) MAXINEFB_IMS332_ADDRESS; Signed-off-by: Randy Dunlap Acked-by: Maciej W. Rozycki Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit c63885314e5b19586f16200e527351aeb5d4607f Author: Carlos Song Date: Thu Jul 16 15:19:56 2026 +0800 i2c: imx-lpi2c: properly unwind resources on probe failure [ Upstream commit cbd043b00ee3f542c115c8809c4d9a67465c07d5 ] When probe fails at devm_clk_rate_exclusive_get() or clk_get_rate(), which occur before runtime PM is initialized, the clocks enabled by clk_bulk_prepare_enable() are never disabled. When probe fails after runtime PM is initialized, the previous error path called pm_runtime_put_sync(), which triggers the runtime suspend callback. However, due to different clock management strategies on different SoCs[1] (to avoid deadlocks between the global prepare_lock and runtime PM), the callback may only disable clocks without unpreparing them, causing an incomplete unwind. Introduce a new error label 'clk_disable' to explicitly invoke clk_bulk_disable_unprepare(). Replace pm_runtime_put_sync() with the sequence of pm_runtime_disable(), pm_runtime_set_suspended() and pm_runtime_put_noidle() to bypass the runtime suspend callback during error recovery. During the LPI2C driver probe phase, clock APIs are used exclusively to manage clocks. Once probing succeeds, clock management is handed over to the runtime PM core. [1] https://lore.kernel.org/all/20251125084718.2156168-1-carlos.song@nxp.com/ Signed-off-by: Carlos Song Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260716071957.2670263-2-carlos.song@oss.nxp.com Signed-off-by: Sasha Levin commit 5c54d87cbe634c6a1ef7e0450663f89e8571156f Author: Li Jun Date: Thu Aug 20 17:23:51 2026 +0800 spi: loongson: pm: add .freeze .poweroff .thaw .restore [ Upstream commit a9c2f0d401fd1e11ce59e4243946a59bd818e8c5 ] after execute s4, the spi error, [ 1104.754246][ 4] [ T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110 [ 1104.761503][ 4] [ T1] spi_master spi1: failed to transfer one message from queue [ 1104.769201][ 4] [ T1] spi_master spi1: noqueue transfer failed [ 1104.776344][ 4] [ T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110 [ 1104.783609][ 4] [ T1] spi_master spi1: failed to transfer one message from queue [ 1104.791308][ 4] [ T1] spi_master spi1: noqueue transfer failed [ 1104.797446][ 4] [ T1] gttadd tpm_chip_start1 ret = -110 and in s4 the loongson_spi_resume&suspend are not called at all. use DEFINE_SIMPLE_DEV_PM_OPS() add .freeze .poweroff .thaw .restore, after s4 the spi communication is normal. Signed-off-by: Li Jun Link: https://patch.msgid.link/20260820092351.101605-1-lijun01@kylinos.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 48e991d80a2057c2692ad1ddfc4e642446b498f6 Author: Pengpeng Hou Date: Sat Jul 4 20:17:34 2026 +0800 rtc: brcmstb-waketimer: add missing MODULE_DEVICE_TABLE() [ Upstream commit 402c89d28fecd28652a4bfe997f08f6544836381 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704121734.54941-1-pengpeng@iscas.ac.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 889c7d21115ac30e9e7713fb6e364ad4f25cac83 Author: Robert Leussler Date: Tue Jul 21 08:19:07 2026 +0000 rtc: ds1307: fix RX8130 wakeup alarm WADA bit for day-of-month mode [ Upstream commit 878d93aaa596a861dbc8d71f7c38e62a2e805f01 ] The RX8130 wakeup alarm never fired when set via /sys/class/rtc/rtc0/wakealarm. The root cause is that the WADA bit (bit 3) in the Extension register (0x1c) was never set before programming the alarm registers. Per the RX8130 datasheet: WADA=0 - Week alarm: register 0x19 is compared against day-of-week WADA=1 - Day alarm: register 0x19 is compared against day-of-month rx8130_set_alarm() always writes a BCD day-of-month value to alarm register 0x19, so WADA must be 1. With WADA=0 the hardware matched the day-of-month value (e.g. 15) as a day-of-week index, which is always out of range (valid weekdays are 0-6), so the alarm interrupt was never asserted. Fix by setting the WADA bit in rx8130_set_alarm() before writing the Extension register back to the device. This is consistent with rx8130_read_alarm(), which decodes the same register under the same assumption (24-hour and day-of-month mode). Signed-off-by: Robert Leussler Link: https://patch.msgid.link/20260721081907.3518648-1-robert.leussler@leica-geosystems.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit c6e3c175c3ffcee68a195bd128b087b4f350648d Author: Jack Yu Date: Thu Aug 20 17:24:15 2026 +0800 ASoC: rt712-sdca: Pull high JD2 to prevent from entering TV mode [ Upstream commit dfb8bc1d286fd97b7cf47e3af5df84cfb068d214 ] Add a patch setting to prevent ALC712 from entering TV mode which may cause unexpected issues. Signed-off-by: Jack Yu Link: https://patch.msgid.link/20260820092415.2979641-1-jack.yu@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c4726cf942f00fd658f62f52316b1ff3248adcbd Author: Jinqian Yang Date: Thu Jul 16 19:59:40 2026 +0800 virtio_ring: fix infinite loop in virtnet_poll_cleantx when device is broken [ Upstream commit 0d0eff39ceb3dcbf7847a6f4517086c207c60081 ] virtnet_poll_cleantx() contains a do-while loop that cleans up transmitted TX buffers and calls virtqueue_enable_cb_delayed() to check whether more buffers need processing. When the virtio backend stops responding during guest reboot, used->idx is never updated, so virtqueue_enable_cb_delayed() always returns false and the loop never terminates. Then it will block reboot process, and the guest will hang. The problem occurs during guest reboot under network traffic: 1. kernel_restart() -> device_shutdown() traverses the device list 2. virtio_dev_shutdown() calls virtio_break_device() which sets vq->broken = true 3. virtio_dev_shutdown() then calls virtio_synchronize_cbs() to wait for in-flight callbacks to complete 4. A virtio interrupt fires, softirq is deferred to ksoftirqd which calls net_rx_action() -> virtnet_poll() -> virtnet_poll_cleantx() 5. virtnet_poll_cleantx() enters the do-while loop and never exits because the QEMU backend has stopped updating used->idx, despite vq->broken having been set to true in step 2. Since the loop runs inside ksoftirqd (a SCHED_OTHER kthread), it is visible to the scheduler and does not trigger a hard lockup. However, the kthread never leaves the loop, so RCU detects it as a CPU stall and reports it periodically. Meanwhile, the reboot process remains blocked in device_shutdown() because virtio_dev_shutdown() cannot complete its synchronization step, and the guest hangs permanently. This can be reproduced on a guest with a virtio-net device: run iperf3 traffic in the guest, then trigger reboot. The reboot occasionally hangs permanently with RCU stall on ksoftirqd. Observed on ARM64 KVM guest: CPU#1 RCU stall (ksoftirqd/1), repeated periodically: virtqueue_enable_cb_delayed_split <- virtnet_poll <- __napi_poll <- net_rx_action <- handle_softirqs <- run_ksoftirqd <- smpboot_thread_fn <- kthread Fix by adding a vq->broken check in virtqueue_enable_cb_delayed(), so that the loop exits immediately when the device is broken, allowing the device shutdown to proceed. Signed-off-by: Jinqian Yang Reviewed-by: Xuan Zhuo Signed-off-by: Michael S. Tsirkin Message-ID: <20260716115940.394832-1-yangjinqian1@huawei.com> Signed-off-by: Sasha Levin commit 60ae1e266f40a4dbb994b9ea39db18c2fd665828 Author: Szymon Durawa Date: Wed Aug 19 13:05:22 2026 +0000 PCI: vmd: Add Nova Lake (NVL) and Dunlow (DNL) Device IDs [ Upstream commit 55aa45154fe48b7d8e96bc031ad27d5b0edfcdb8 ] Add VMD Device ID Support for Intel NVL/DNL processors. Suggested-by: Nirmal Patel Signed-off-by: Szymon Durawa Signed-off-by: Bjorn Helgaas Cc: Nirmal Patel Cc: Jonathan Derrick Link: https://patch.msgid.link/20260819130523.398493-1-szymon.durawa@linux.intel.com Signed-off-by: Sasha Levin commit b330ab215f2818660ca96b4b2b3b82642d6b50c6 Author: Pengpeng Hou Date: Sat Jul 4 23:25:28 2026 +0800 rtc: ab-eoz9: add missing MODULE_DEVICE_TABLE() [ Upstream commit 7490b8356e52e09c196645912f2c054f79aa5f3a ] The driver has a match table for the i2c bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704152528.53258-1-pengpeng@iscas.ac.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit cfc695ac470db028c4a4935297d8954a3fe6402d Author: Denis V. Lunev Date: Wed Jun 24 16:08:46 2026 +0200 virtio_balloon: warn on failed buffer add in tell_host() [ Upstream commit 198eda395067b56ee605de076f0519620f4e5d90 ] tell_host() ignores the return value of virtqueue_add_outbuf() and goes on to kick the queue and wait_event() for the host's ack. The comment claims "We should always be able to add one buffer to an empty queue", but that does not hold once the virtqueue has been broken (e.g. on device shutdown): the add then fails with -EIO and the following wait_event() would block forever on a buffer the host can never return. Warn and bail out on failure, mirroring virtballoon_free_page_report(). Suggested-by: David Hildenbrand Signed-off-by: Denis V. Lunev Signed-off-by: Michael S. Tsirkin Message-ID: <20260624140846.2616797-5-den@openvz.org> Signed-off-by: Sasha Levin commit 085c485d4952414eec75e2dd2539e2a721555e43 Author: Chad Talbott Date: Tue Aug 18 14:32:37 2026 -1000 ALSA: usb-audio: Add MIN_MUTE quirk for Creative Sound Blaster Play! 3 [ Upstream commit 352cef030f9036a658e6eb03d6bb85fa19c7c103 ] The Creative Sound Blaster Play! 3 (041e:324d) exposes a Feature Unit volume control with a range of -44.00 dB .. 0.00 dB over raw values 0..88, but raw value 0 is in fact a hard mute rather than -44.00 dB. Tested on hardware. Signed-off-by: Chad Talbott Link: https://patch.msgid.link/20260819003237.452807-1-chad.talbott@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b34f1cc7838e7c1a0151dfba638e88e8493b1803 Author: Weimin Xiong Date: Thu Jul 16 13:43:53 2026 +0800 vdpa/mlx5: roll back MR update after VQ setup failure [ Upstream commit 11f79e2780043ad94424a8db02a7a9022ba93252 ] mlx5_vdpa_change_map() must install the new MR before rebuilding or resuming virtqueues, because both paths read the MR keys from mvdev->mres.mr[]. If rebuilding the virtqueue resources fails, the new MR must not remain installed after its reference is released. Keep an extra reference to the old MR before replacing it. On setup failure, restore the old MR; the saved reference then becomes the map reference, while replacing the new MR drops its map reference. Make mlx5_vdpa_change_map() consume new_mr on all error paths so that set_map_data() does not release an MR already released during rollback. v2: - Keep the new MR installed while virtqueues are rebuilt. - Restore the old MR only after setup_vq_resources() fails. Signed-off-by: Weimin Xiong Signed-off-by: Michael S. Tsirkin Message-ID: <20260716054353.155805-1-xiongwm2026@163.com> Signed-off-by: Sasha Levin commit ad008eeee1e9ba2bec2215e3acf7d9f4ba90fc81 Author: Gilles Risch Date: Mon Aug 17 02:43:26 2026 +0200 drm/radeon: fix internal display on iMac11, 1 (RV770/DCE3.1) [ Upstream commit 275c3332585bbabcefad109a6978cc0cbecf2008 ] The Apple iMac11,1 (27-inch, Late 2009) uses a Mobility Radeon HD 4850 (RV770/DCE3.1) with a 2560x1440 internal panel on an internal DisplayPort path. Without this fix the display stays dark under KMS. This machine suffers from the same issue as iMac10,1 and iMac11,2: Apple routes the internal display through Link B of the DIG encoder instead of Link A. Add iMac11,1 to the existing DMI quirk and move the Apple-specific encoder assignment into its own block, independent of the DCE version check. Additionally, the 2560x1440 panel requires RADEON_PLL_USE_FRAC_FB_DIV and ATOM_ENCODER_CMD_DP_VIDEO_ON, limited to iMac11,1 via dmi_match() to avoid affecting other boards. Reviewed-by: Lukas Wunner Signed-off-by: Gilles Risch Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 848b8e33af21825095925cd75a4fd43271c74547 Author: Xiong Weimin Date: Fri Jun 26 10:05:45 2026 +0800 vdpa_sim: hold iommu_lock across dma_unmap passthrough transition [ Upstream commit 7b411448c668bfab0d0e572cee5a592cea396ce7 ] vdpasim_dma_map() updates the IOTLB and the passthrough (iommu_pt) state under iommu_lock. vdpasim_dma_unmap() clears iommu_pt and resets the IOTLB before taking iommu_lock, then deletes the mapping while holding the lock. A concurrent dma_map(), dma_unmap(), or reset path that also touches the same address space can therefore observe or modify the IOTLB and iommu_pt state without consistent locking. Perform the passthrough transition and range deletion under the same iommu_lock scope, matching dma_map(). Tested-on: openEuler VM (6.16.8, /usr/src/linux-6.16.8) Tested-by: Xiong Weimin Signed-off-by: Xiong Weimin Signed-off-by: Michael S. Tsirkin Message-ID: <20260626020545.607600-3-15927021679@163.com> Signed-off-by: Sasha Levin commit f65a37638f236abc7f6c7f2c70d1e2871961788d Author: Kuninori Morimoto Date: Tue Aug 18 01:46:29 2026 +0000 ASoC: codec: max98926: fixup invert setup mask [ Upstream commit dd0ae9a2e19a24c532c9aa80a44f572b4907bcdf ] invert might have both WCI/BCI mask, but regmap_update_bits() masks BCI only. It needs both mask. Fixup it. static int max98926_dai_set_fmt(...) { ... switch (fmt & SND_SOC_DAIFMT_INV_MASK) { case SND_SOC_DAIFMT_NB_NF: break; case SND_SOC_DAIFMT_NB_IF: => invert = MAX98926_DAI_WCI_MASK; break; ^^^^^^^^^^^^^^^^^^^^^ case SND_SOC_DAIFMT_IB_NF: => invert = MAX98926_DAI_BCI_MASK; break; ^^^^^^^^^^^^^^^^^^^^^ case SND_SOC_DAIFMT_IB_IF: => invert = MAX98926_DAI_BCI_MASK | MAX98926_DAI_WCI_MASK; break; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ default: ... } ... regmap_update_bits(max98926->regmap, MAX98926_FORMAT, MAX98926_DAI_BCI_MASK, invert); ... ^^^^^^^^^^^^^^^^^^^^^ } Signed-off-by: Kuninori Morimoto Link: https://patch.msgid.link/87wltomc97.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2c6395235c3cd3d46a2448e360f97358cedffc36 Author: Andrew Onyshchuk Date: Thu Aug 6 08:44:17 2026 -0700 platform/x86: thinkpad_acpi: Fix fan speed reporting on Edge E330 [ Upstream commit 8d840dad456f88374d8a3b03851452a280d6ee50 ] The ThinkPad Edge E330 with H3 firmware uses the non-standard EC fan register block. Without a matching quirk, thinkpad_acpi reads the legacy tachometer registers and reports 0 RPM. Add the H3 BIOS family to TPACPI_FAN_NS so the driver reads the fan period from EC register 0x95 using the existing non-standard reporting path. Tested on a ThinkPad Edge E330 with BIOS H3ET77WW and EC H3EC35WW. Signed-off-by: Andrew Onyshchuk Reviewed-by: Mark Pearson Link: https://patch.msgid.link/20260806154417.618575-1-andryk.rv@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 504309a6d93410c7a85b9b70ba824042a9dd3ad0 Author: Yaroslav Dudkov Date: Fri Aug 7 18:05:53 2026 +0000 platform/x86: msi-ec: Add MSI Katana GF76 11UEK EC firmware [ Upstream commit 0b30e6e583b2988864ffa7aeb2905bc2d0c7d575 ] Add the firmware string '17L1EMS1.107' to the ALLOWED_FW_13 array. This enables Embedded Controller support, including battery charge thresholds, for the MSI Katana GF76 11UEK (MS-17L1) laptop. Tested on MSI Katana GF76 11UEK with EC firmware 17L1EMS1.107 and BIOS E17L1IMS.312. Signed-off-by: Yaroslav Dudkov Link: https://patch.msgid.link/20260807180553.869371-1-aroslavdudkov622@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 6a5808b62103572e8611333f96ffed81b30928ff Author: Benjamin Coddington Date: Thu Jun 25 08:05:50 2026 -0400 NFSv4/flexfiles: report cancelled I/O as a layout error [ Upstream commit 4a013b0e881e0466cc2c6a5518d2f6cda3a4f19f ] When a layout is recalled or revoked the client cancels its in-flight I/O so the layout can be returned. The metadata server needs to learn that this I/O to the storage device did not complete, so that it can reconcile the affected mirror instance (or, if none remains, take other action). The cancellation completed with -EAGAIN, which ff_layout_io_track_ds_error() does not recognise: it fell through the switch and recorded nothing, so no error was reported to the server. -EAGAIN is overloaded in the RPC layer, so rather than key the reporting on it, cancel the I/O with -ECANCELED and map that to NFS4ERR_NXIO in ff_layout_io_track_ds_error() -- the status the client already reports for the transport errors that leave an in-flight write incomplete. The cancelled I/O is then reported to the server via LAYOUTERROR / LAYOUTRETURN. Unlike a genuine transport error, though, we aborted the I/O ourselves and have no evidence the device is at fault, so once the error is recorded we skip marking the device unreachable and forcing a further layout return. The retry disposition is unchanged from the original -EAGAIN cancellation: both NFS4ERR_NXIO and -ECANCELED are no-ops in ff_layout_async_handle_error(), which still resets the I/O to pNFS (or the MDS), so it is re-driven as before. Signed-off-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit b486934bcabda26cf28d97e7d878bf0f72211d9a Author: Alex Elder Date: Wed Aug 12 11:38:30 2026 -0500 net: stmmac: use dma_addr_t for DMA addresses [ Upstream commit 0c1f9020d2ada55aed8a2e055903ad9cd5d49dab ] In jumbo_frm() (implemented in both "chain_mode.c" and "ring_mode.c"), an unsigned integer local variable is used to hold the value returned by dma_map_single(). On systems where a dma_addr_t is 64 bits, the subsequent dma_mapping_error() check of the returned value operates only on the low 32 bits (whose high bit won't be sign-extended). In this case, dma_mapping_error() would return 0 (no error) even if there were one. Fix this in both spots by using a dma_addr_t for the local variable. Reported-by: Sashiko Link: https://lore.kernel.org/linux-devicetree/20260606010122.21A211F00899@smtp.kernel.org/ Reviewed-by: Maxime Chevallier Signed-off-by: Alex Elder Link: https://patch.msgid.link/20260812163832.271742-2-elder@riscstar.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 628874afc85eb52d9d972e992e794a8b3dada4fb Author: Jia Zhu Date: Tue Jul 7 21:36:23 2026 +0800 NFSv4: pin the superblock for active state owners [ Upstream commit 8cb1ce7aa0e8ac30e55f5bccfb80125f2e43e84a ] NFSv4 open state can outlive the file and dentry that created it. This was observed in production when NFSv4 state recovery, such as after a server reboot or lease expiration, raced with unmount. The race requires recovery to hold an open state reference while the last open file is closed and the filesystem is unmounted, allowing the superblock's active reference to drop to zero between refcount_inc(&state->count) and nfs4_put_open_state(): state manager umount nfs4_run_state_manager() nfs4_do_reclaim() nfs4_reclaim_open_state() refcount_inc(&state->count) ... close last file generic_shutdown_super() "Busy inodes after unmount" nfs_free_server() nfs4_put_open_state() iput(inode) evict() nfs_clear_inode() nfs_zap_acl_cache() The "VFS: Busy inodes after unmount" warning is the visible symptom of that lifetime mismatch: superblock teardown proceeds even though the NFS open state still pins an inode. After umount has freed the server, the state manager can then run nfs4_put_open_state() for the last open-state reference. The resulting iput(inode) can evict an NFS inode with freed server data, causing crashes at nfs_zap_acl_cache(). This can be reproduced by delaying the reclaim path before nfs4_put_open_state(), then closing the last file and unmounting the NFS mount. Pin the superblock while a state owner is active, and drop the pin when the owner becomes idle again, so the NFS server stays alive until all open state associated with the owner has been released. Assisted-by: Codex:GPT-5 Signed-off-by: Jia Zhu Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit eb8a4524d32e1c53e654c1cb91d84c4358026850 Author: Xu Rao Date: Mon Aug 17 16:55:31 2026 +0800 ALSA: hda: Add Lisuan HDMI controller and codec support [ Upstream commit ceaebef91d1aff671a512d5f003766ea41152d94 ] Lisuan GPUs expose an HD-audio controller at PCI ID 4c54:5010 and an HDMI/DP codec with codec ID 0x4c545020. Neither ID is currently matched by the HDA stack, leaving HDMI/DP audio unavailable on these devices. The existing downstream support uses the generic HDMI codec path and attaches no Lisuan-specific capability flags to the controller. Its dedicated AZX driver type only changes the short driver name. Use the corresponding generic upstream paths instead: bind 4c54:5010 to AZX_DRIVER_GENERIC, register 0x4c545020 as MODEL_GENERIC, and add the Lisuan codec vendor name. This keeps the enablement minimal and avoids a vendor-only AZX driver type with no vendor-specific behavior. Signed-off-by: Xu Rao Link: https://patch.msgid.link/DE1B62191D573D37+20260817085531.992573-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d44771126e5498f0b150e16dad094abd2a461b52 Author: ZhangGuoDong Date: Fri Jul 3 14:54:48 2026 +0800 NFS: Verify symlink inode before caching target [ Upstream commit 3265f1998ae9a9282a8a6ca95467d9572d6ebb82 ] nfs_symlink() copies the symlink target into a folio before issuing the SYMLINK RPC. After a successful reply, it caches that folio in the instantiated inode mapping and assumes that the dentry now names a symlink. If the dentry is instantiated with a non-symlink inode, the raw symlink target folio can be inserted into the wrong mapping. When that inode is a directory, reclaim or unmount later calls nfs_readdir_clear_array() through nfs_dir_aops and interprets the symlink target as a readdir cache array, which can lead to invalid kfree() calls. A vmcore from a 4.19-based kernel showed the crash when reclaiming a directory mapping on unmount: Stack trace: nfs_readdir_clear_array+0x4d/0x70 [nfs] page_cache_free_page.isra.35+0x1a/0x90 delete_from_page_cache_batch+0x1cf/0x2c0 truncate_inode_pages_range+0x24d/0x910 [...] nfs_evict_inode+0x15/0x30 [nfs] evict+0x115/0x2b0 dispose_list+0x48/0x60 evict_inodes+0x16c/0x1b0 generic_shutdown_super+0x3f/0x120 nfs_kill_super+0x1b/0x40 [nfs] deactivate_locked_super+0x3f/0x70 cleanup_mnt+0x3b/0x80 The current code still has the same unchecked cache insertion pattern, so it may be susceptible to the same failure mode. Verify that the instantiated inode is a symlink before caching the target folio. If the type is wrong, drop the suspect dentry and skip the cache insertion while preserving the successful SYMLINK result. Co-developed-by: Jackie Liu Signed-off-by: Jackie Liu Signed-off-by: ZhangGuoDong Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 085a1eb885f171debf15c3c92dd21acbe0bc548e Author: Thomas Huth Date: Tue Aug 11 17:46:18 2026 +0200 smb: server: Free session data in user_session.c with kfree_sensitive() [ Upstream commit 9a4bd6507c21f66e84dc021705a4b9d84773111e ] struct ksmbd_session contains some arrays with sensitive information, like sess_key, smb3encryptionkey, smb3decryptionkey and smb3signingkey. Thus let's make sure that this information cannot leak via the heap and use kfree_sensitive() to free it. Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 7b3f00649f044f1788a2bc257fc5fa9100c93783 Author: Namjae Jeon Date: Sat Aug 15 22:19:38 2026 +0900 ksmbd: notify parent directory leases on child create [ Upstream commit abe5acb34282206c2a6303d0e09b3165b1addf0e ] BVT_DirectoryLeasing_ReadWriteHandleCaching requires a parent directory lease break notification when another client creates a child in the leased directory. A child CREATE without a lease context did not notify the parent lease holders because the notification path expected a non-NULL lease context. Allow the parent lease notification helper to handle a NULL child lease context and notify matching parent leases. Invoke it after a child is created without a lease context while preserving the existing lease-key filtering for requests that provide one. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 290e5d72744c8b0df25d7cdf293f1f9932c2a341 Author: Benjamin Coddington Date: Thu Jun 25 08:05:49 2026 -0400 pNFS: honor clora_changed when recalling a layout [ Upstream commit aceaa5991bdf744e9c3fa1e5ad73405b1801eaab ] When the metadata server recalls a layout with clora_changed FALSE, the layout is not changing and the client may complete its modified writes to the storage devices before returning the layout (RFC 8881, Section 20.3.3). Only when clora_changed is TRUE -- the server is restriping, or a storage device has failed -- should the client stop writing to the storage devices and redirect through the metadata server. Since commit b739a5bd9d9f ("NFSv4/flexfiles: Cancel I/O if the layout is recalled or revoked") the client cancels in-flight I/O on every recall, regardless of clora_changed. For an unchanged recall this abandons writes whose data may already have reached the storage device; such a write can then land after the LAYOUTRETURN, which the server sees as a write without a layout. Pass the recall's clora_changed value through pnfs_mark_matching_lsegs_return() and only cancel in-flight I/O when the layout is actually changing. When it is not, the existing deferred return path waits for the in-flight writes to drain before sending the LAYOUTRETURN. Other callers, which are tearing down or returning the layout for their own reasons, continue to cancel as before. Signed-off-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit b6534d1bd7dea87dafc8aa034d8c5d18c71de152 Author: Thomas Huth Date: Wed Aug 12 21:36:32 2026 +0900 smb: server: Make sure that passkey is not leaked on the heap in user_config.c [ Upstream commit 2c5a176882695f73b52482df03b0017b006ef2d1 ] Use kfree_sensitive() to free the user->passkey (and the struct ksmbd_login_response in ksmbd_login_user() that contains the same information) to avoid that this information could leak somewhere else via the heap. Signed-off-by: Thomas Huth Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 2b24e1a49f9797f2b89cbd0274527d832fb1b461 Author: Namjae Jeon Date: Fri Jul 17 12:05:00 2026 +0900 ksmbd: honor client signing-required in all modes [ Upstream commit bc2f3f3dd69424f76e2ed3dc53d29bfd6c9966d4 ] The SMB2 NEGOTIATE request's SMB2_NEGOTIATE_SIGNING_REQUIRED bit requires the server to set Connection.ShouldSign. KSMBD represents that state with conn->sign, but previously set it only when its signing configuration was auto or disabled. Set conn->sign whenever the client requires signing, independently of the server's signing mode. Keep the mandatory server-mode handling unchanged. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 3a728c25f7142f09606c129ea91866faeb3112f4 Author: Namjae Jeon Date: Wed Jul 29 21:26:26 2026 +0900 ksmbd: reject blocking compound lock requests [ Upstream commit 16a7f7c2ecf3c893b65f0fb78fa7a7171ae0ba9e ] Clients set SMB2_LOCKFLAG_FAIL_IMMEDIATELY when a LOCK request contains multiple lock elements, and servers reject requests that omit it. Accepting such a request can leave earlier elements locked while a later element waits asynchronously, enabling prolonged partial lock ownership and avoidable deadlocks. Return STATUS_INVALID_PARAMETER before processing any element when a multi-element lock request contains a blocking lock. Unlock arrays remain unaffected. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 010ebd24940f104152f8f98f5daf8a3a30e47ac6 Author: Gael Blivet Date: Fri Jul 17 09:37:20 2026 +0200 ksmbd: fix AsyncId zeroed before use in smb2_lock() cancel response [ Upstream commit 7b461610882c8baa64d56dade57cdbfb686739fa ] release_async_work() zeroes work->async_id before the CANCELLED path calls smb2_send_interim_resp(work, STATUS_CANCELLED), which reads work->async_id to build the response's AsyncId field. The cancellation response for a cancelled blocked-lock request is sent with AsyncId=0 instead of the id the client received in the original STATUS_PENDING response for this request. Checked against every other release_async_work() call site in this file: smb2_read()/smb2_write() don't send a further async response afterward (their status goes out on the synchronous path instead), and smb2_notify()'s two async paths already transfer the id to a separate struct before releasing, so this reordering is scoped to smb2_lock() only. Send the STATUS_CANCELLED response while work->async_id is still valid, then release the async work afterward. Signed-off-by: Gael Blivet Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 394898ff40cd1e6d03191142fed6d9747981638a Author: Namjae Jeon Date: Wed Jul 29 21:24:11 2026 +0900 ksmbd: fix SMB2 byte-range lock end offset [ Upstream commit 54d90311f9b4eb23f3b0b62650b0cfddb11a12ef ] SMB2 describes a byte-range lock using an offset and a length, while Linux file_lock uses an inclusive end offset. smb2_lock() currently sets fl_end to start + length and consequently locks one extra byte for every nonzero-length request. Translate nonzero lengths to start + length - 1 and reject ranges that cannot be represented by loff_t instead of silently truncating them at OFFSET_MAX. Track zero-length locks from the request length so one-byte ranges are not mistaken for zero-length locks after endpoint conversion. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6cdc0ac0c455bacda275e1ba6ff6362285c7c689 Author: Yashraj Ghule Date: Sun Aug 16 16:36:55 2026 +0530 ALSA: hda/realtek: Fix mute LED for HP Victus 15-fa1xxx (MB 8C3F) [ Upstream commit 19b02fecd8f857909af779afe3816e487ac10cd0 ] The HP Victus 15-fa1xxx with motherboard 8C3F is missing the existing mute LED quirk for ALC245 codecs. Add the 103c:8c3f subsystem ID to the existing ALC245_FIXUP_HP_MUTE_LED_COEFBIT quirk. Tested on HP Victus 15-fa1xxx (MB 8C3F). The mute LED works as intended. Signed-off-by: Yashraj Ghule Link: https://patch.msgid.link/20260816110655.11592-1-yashrajghule.221@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bbcfc51648fbf32f8c899163b0851fa812628080 Author: ChenXiaoSong Date: Thu Jul 23 04:11:30 2026 +0000 smb/server: cancel async requests when closing connection [ Upstream commit 4fd5bad647bfa45eb86bfd2f03ba1bef3fcd5851 ] An async request may still be waiting when a connection is closed. This can stop the connection from closing. Cancel active async requests before waiting for them to finish. Suggested-by: Namjae Jeon Signed-off-by: ChenXiaoSong Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit d5eaa5dc2d91ee9f0862a1ba5d91319aea3aba12 Author: Gael Blivet Date: Thu Jul 9 18:50:46 2026 +0200 ksmbd: report actual xattr value length in stream enumeration [ Upstream commit 689f1eb3719d61700b58f984ac8602837f004f8c ] get_file_stream_info() (FileStreamInformation QUERY_INFO) reported each enumerated stream's StreamSize/StreamAllocationSize as stream_name_len -- the byte length of the stream's *name*, not its data. This is the same bug class already fixed for EndOfFile/ AllocationSize on an open stream handle (ksmbd_stream_eof()), just missed at this second site: a client enumerating streams sees a size derived from the name string length instead of the stream's actual content length, inconsistent with what querying the same stream by handle reports. Compute the real value length the same way ksmbd_stream_eof() does, via ksmbd_vfs_casexattr_len() on the already-known xattr key. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 1ffa534cbaa0c178b47f5c978f8e6eccf8371968 Author: Gael Blivet Date: Thu Jul 9 02:01:11 2026 +0200 ksmbd: skip fallocate for SMB2_CREATE_ALLOCATION_SIZE on a stream handle [ Upstream commit bfdf81c62f4f52a3626ea62db0744def6778e83f ] smb2_open() calls vfs_fallocate(fp->filp, ...) unconditionally when a client's CREATE request includes an AllocationSize create context. For a stream handle, fp->filp refers to the base file's data fork (streams are xattr-backed on the same underlying file, not separate files), so this pre-allocates storage on the base file's actual data instead of doing anything meaningful for the stream -- fallocate has no applicability to an xattr-backed stream at all. Skip the fallocate call for stream handles. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 1373a9aba9ee59b1c344175847e8f3cc5ef5ee66 Author: Namjae Jeon Date: Wed Jul 8 22:21:25 2026 +0900 ksmbd: allow FSCTL_SET_SPARSE without input buffer [ Upstream commit 86c84cc760080929b7be44bceebe5854957b99da ] FSCTL_SET_SPARSE without an input buffer sets a file sparse. Treat a zero-length input buffer as SetSparse=true and keep rejecting truncated non-empty buffers. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 752103a26dc1360f15c403f1f5cb668f8f2d92ff Author: Namjae Jeon Date: Sun Jul 12 00:03:34 2026 +0900 ksmbd: honor byte-range locks for zero data [ Upstream commit 8b57448a147d2378088e63cd473e7f2a967d6802 ] FSCTL_SET_ZERO_DATA changes file allocation state and must respect byte-range locks over the affected part of the file. Check the requested range, clipped to EOF, before issuing the fallocate operation. Return STATUS_FILE_LOCK_CONFLICT when the range conflicts with an existing lock. Ranges starting past EOF are left untouched by the lock check so they continue to succeed. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit d4b647621230fc847b3ce9cbd636302f52c6a53f Author: Namjae Jeon Date: Thu Jul 9 20:08:10 2026 +0900 ksmbd: handle empty QUERY_ALLOCATED_RANGES output [ Upstream commit 7f07791522a251e2be087d11ae9cd51eb3408f1d ] FSCTL_QUERY_ALLOCATED_RANGES can be issued with a valid input buffer but without room for an output range. Do not reject the request before looking at the file layout. If the query would produce a range, return STATUS_BUFFER_TOO_SMALL. If it produces no ranges, return success with an empty output. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ca4bc2ab7e747e5f27b4daa375fcf35429232f13 Author: Namjae Jeon Date: Tue Jul 7 00:19:39 2026 +0900 ksmbd: return buffer too small for short security queries [ Upstream commit 2103add92a02505bdd536ba6fce7f64a427222a2 ] SMB2 QUERY_INFO security requests with an output buffer too small for the self-relative security descriptor header can fall through descriptor construction and be reported as STATUS_INVALID_INFO_CLASS. After validating the file handle, reject buffers shorter than struct smb_ntsd with STATUS_BUFFER_TOO_SMALL before building the descriptor. This fixes smb2.getinfo.qsec_buffercheck. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 0adca6c5265c68122d208a11fcc82265ba5ccdd6 Author: Gael Blivet Date: Tue Jul 7 11:55:01 2026 +0200 ksmbd: fix off-by-one rejecting minimal COPYCHUNK query-limits request [ Upstream commit d68d4b3293034f549d55f407a23b4c0a6c90e50a ] The FSCTL_COPYCHUNK/FSCTL_COPYCHUNK_WRITE input length check uses in_buf_len <= sizeof(struct copychunk_ioctl_req), which rejects a buffer that is exactly sizeof(struct copychunk_ioctl_req) bytes -- the minimal, valid request containing only the fixed header with ChunkCount=0 and no chunk entries, used by clients to query the server's copy limits before issuing a real copychunk. Since copychunk_ioctl_req ends in a flexible array member, the correct minimum is that the buffer covers the fixed header, so use offsetof(..., Chunks) with '<' instead of '<=' against sizeof(): same value, but the boundary case is now correctly accepted. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit b0b3a3f35df6c5792b181dd0b3154df177641e12 Author: Namjae Jeon Date: Sat Jul 4 18:21:33 2026 +0900 ksmbd: reject SMB3.1.1 binding with mismatched cipher [ Upstream commit 7019a11f79dc408f2b47b1027240e7f198784c9a ] SMB3.1.1 multichannel connections belonging to the same session must use the same negotiated encryption cipher. ksmbd validates the dialect and client GUID during session binding, but does not compare the cipher negotiated by the new connection with the cipher used by the existing session channels. This allows a channel negotiated with AES-128-CCM to bind to a session using AES-128-GCM. Compare the new connection's cipher with an existing session channel and return STATUS_INVALID_PARAMETER when they differ. This fixes smb2.session.bind_negative_smb3encGtoCs. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a5f2f277999973be810af3e5a2b4e041ea2e8734 Author: Gael Blivet Date: Thu Jul 9 02:01:06 2026 +0200 ksmbd: fix durable handle v2 default timeout units (60 -> 60000) [ Upstream commit c1d7bbfc5e081875053723d1a69eb2cf341eaaf1 ] When a client's Durable Handle Request V2 sets Timeout=0 ("let the server choose"), fp->durable_timeout was set to 60. Every other use of this field is in milliseconds: DURABLE_HANDLE_MAX_TIMEOUT (300000) in smb2pdu.h, the nonzero branch immediately above (min_t(unsigned int, dh_info.timeout, DURABLE_HANDLE_MAX_TIMEOUT), where dh_info.timeout is the wire value and already milliseconds per spec), and the scavenger in vfs_cache.c, which adds it directly to jiffies_to_msecs(jiffies). 60 is off by 1000x: the handle becomes scavenger-eligible 60 milliseconds after close instead of 60 seconds. A client requesting Timeout=0 is relying entirely on the server's default to cover the gap between a dropped connection and its reconnect -- 60ms is not enough time for even a fast network blip to be detected and reconnected, so any real disruption loses the race and a subsequent DH2C reconnect fails with a durable-handle lookup miss instead of succeeding. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Gael Blivet Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ea8bcc91689202155f91567b86c302d48703e188 Author: Namjae Jeon Date: Sun Jul 5 16:01:27 2026 +0900 ksmbd: allow I/O on directory named streams [ Upstream commit 8184c425a19d44f138d42b44cc363917c08e5f1c ] Named streams are stored as extended attributes on the base inode. The VFS read and write helpers reject directory inodes before or together with checking whether the handle represents a stream. Permit read and write operations when a directory-backed handle is a named stream. Continue rejecting direct I/O on ordinary directory handles. This fixes creation of the directory stream in smb2.getinfo.complex. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8b47ffa0476201566e30287ec540eb031af12c3b Author: Namjae Jeon Date: Tue Jul 7 00:49:37 2026 +0900 ksmbd: preserve access denied status for copychunk [ Upstream commit f7c0366e0a80bf8cd5eacc5479927abb50958b5e ] The copychunk error mapping handles -EACCES in an independent if statement. The following error chain therefore reaches its final else clause and overwrites STATUS_ACCESS_DENIED with STATUS_UNEXPECTED_IO_ERROR. Join the -EACCES check to the remaining error chain so an access failure is returned as STATUS_ACCESS_DENIED. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 8db0eab85a89cf8f41e3c81b5aab66e64c790409 Author: Namjae Jeon Date: Sun Jul 5 15:55:14 2026 +0900 ksmbd: protect private extended attributes [ Upstream commit 4ea46ea602fc7055eee4b5b0e84f90f22da7f7e7 ] SMB clients can currently create an EA named NTACL because SMB EAs are mapped into the user namespace while the ksmbd security descriptor is stored as security.NTACL. Allowing the reserved logical name makes the server-private ACL metadata appear writable through the SMB EA API. Reject NTACL, DOSATTRIB, and DosStream-prefixed EA names without regard to case. Filter the same private names from EA query results so stale or externally-created user namespace attributes cannot be exposed. This fixes smb2.ea.acl_xattr when acl_xattr_name is configured as NTACL. Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 220e3f51071bdeef20bb23ec508b0c14a3d1d1a8 Author: David C.C.M. Gall Date: Fri Aug 7 18:22:00 2026 +0200 crypto: keembay - use crypto_memneq() to compare CCM AEAD tags [ Upstream commit ff2ac77a034e03b64e2ba34f775097427dfa5547 ] Use crypto_memneq() for constant-time comparison. The CCM path in ocs-aes.c verifes the received authentication tag with memcmp(), which returns early on the first mismatched byte. This leaks valid-prefix length and allows for valid tag forgery which violates the INT-CTXT guarantee of AEAD. Assisted-by: gregkh_clanker_t1000 Signed-off-by: David C.C.M. Gall Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 567499907e178711bff40802f3427917d1d4fa6b Author: Israel Téllez García Date: Fri Aug 14 14:48:43 2026 +0200 libbpf: Fix ring buffer consumer loop on 32-bit position wrap [ Upstream commit fdd4fad0bbbd08501465c5f9b556963093c5d58a ] ringbuf_process_ring() walks the records between the consumer and the producer with an ordering comparison: while (cons_pos < prod_pos) { cons_pos and prod_pos mirror the kernel's ring positions and are unsigned long here too, so on 32-bit they wrap at 2^32 bytes of traffic. When producer_pos has wrapped and consumer_pos has not, prod_pos is the smaller of the two, the loop body never runs and no record is consumed. Since consumer_pos only advances inside that loop, it never wraps either and the consumer stops delivering samples for good, with no error returned to the caller: ring_buffer__poll() keeps reporting zero records while the kernel side fills up and starts dropping. Compare the distance instead. The consumer never runs ahead of the producer, so prod_pos - cons_pos is the amount of unconsumed data and stays correct across the wrap. 64-bit hosts are unaffected in practice: the counters would need 16 EiB to wrap. This is the userspace counterpart of the kernel-side walk fixed in "bpf: Fix pending_pos walk on 32-bit ring position wrap"; a 32-bit consumer hits whichever of the two comes first. Signed-off-by: Israel Téllez García Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260814124843.22041-5-i.tellez@btesa.com Signed-off-by: Sasha Levin commit 80cb14cc834a2a30cd1a043f737449c410ebcc28 Author: David C.C.M. Gall Date: Fri Aug 7 17:44:16 2026 +0200 crypto: sa2ul - use crypto_memneq() to compare AEAD tag [ Upstream commit 7064af16d2b418d61571dba9bb0116a547ade124 ] Use crypto_memneq() for a constant-time comparison. sa_aead_dma_in_callback() compares the computed authentication tag against the received tag with memcmp(), which short-circuits on the first differing byte. An attacker who can submit decrypt requests and observe completion latency could recover the expected tag byte by byte. Valid tag forgery for AEAD breaks the INT-CTXT guarantee. Assisted-by: gregkh_clanker_t1000 Signed-off-by: David C.C.M. Gall Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9bfa6187948e267cbf406256ae944d4195daf99a Author: David C.C.M. Gall Date: Fri Aug 7 18:13:52 2026 +0200 crypto: keembay - use crypto_memneq() to compare GCM AEAD tags [ Upstream commit 353b3a85136f2a0cf3e872acf8ad6c1dec0b7a8e ] Use crypto_memneq() for constant-time comparison. The GCM path in keembay-ocs-aes-core.c verifes the received authentication tag with memcmp(), which returns early on the first mismatched byte. This leaks valid-prefix length and allows for valid tag forgery which violates the INT-CTXT guarantee of AEAD. Assisted-by: gregkh_clanker_t1000 Signed-off-by: David C.C.M. Gall Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit fa2697301e7ef0eb0809368f09c386e5bb51ebc4 Author: Eric Dumazet Date: Wed Aug 12 14:22:57 2026 +0000 gre: fix ERSPAN o_flags race/corruption in xmit and fill_info [ Upstream commit 9958e69b98930834a576e156f6458166d1db1c02 ] For IPv4 ERSPAN: In erspan_xmit(), the driver clears IP_TUNNEL_SEQ_BIT (for version 0) and IP_TUNNEL_KEY_BIT directly in the shared tunnel->parms.o_flags structure. Since transmit paths can run locklessly and concurrently, this leads to a data race. Furthermore, modifying tunnel->parms.o_flags permanently alters the tunnel configuration. To work around this, erspan_fill_info() (which reports config to userspace) was setting IP_TUNNEL_KEY_BIT back. If erspan_fill_info (running under RTNL) and erspan_xmit (running locklessly) race, erspan_xmit might see IP_TUNNEL_KEY_BIT set when it shouldn't, leading to GRE header corruption (injecting a key field into the ERSPAN GRE header). Fix this by: 1) Passing flags as an argument to __gre_xmit(). 2) Using local stack flags in ipgre_xmit(), gre_tap_xmit(), and erspan_xmit() to prevent TOCTOU data races with concurrent configuration updates, and passing them to __gre_xmit(). 3) Removing the racy modification of t->parms.o_flags in erspan_fill_info(). 4) Forcing IP_TUNNEL_KEY_BIT in the reported flags for ERSPAN locally in ipgre_fill_info(). For IPv6 ERSPAN: ip6erspan_tunnel_xmit() was locklessly clearing IP_TUNNEL_KEY_BIT in t->parms.o_flags even though it does not use these flags for building the GRE header (it uses local flags). This permanently corrupts the configuration and races with ip6gre_fill_info() which reads it. Remove the redundant and racy modification. This should remove false sharing in a fast path. Add const qualifiers in ipgre_fill_info(), erspan_fill_info() and ip6gre_fill_info() to clarify that these methods are not supposed to write any live parameters. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260812142257.21283-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit edff0fa7834abdb22a82ded0b5d63131174952ac Author: Yang Wen Date: Thu Aug 13 22:29:19 2026 +0800 exfat: keep FITRIM within the requested range [ Upstream commit 2de727471b3b13409466a4af4f8824a86073bf4b ] exfat_find_free_bitmap() searches the entire allocation bitmap and may wrap around to its beginning. exfat_trim_fs() does not verify that the returned cluster is still within the requested FITRIM range. As a result, a partial FITRIM operation may discard free clusters outside the user-specified range and report a trimmed length larger than the requested length. Validate each returned cluster against the requested range and stop the search when it wraps around or passes the range end. Signed-off-by: Yang Wen Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 524a770828a39e6c25debc75d0d21aeb4b44ab32 Author: Anuj Bolewar Date: Sun Aug 2 22:05:17 2026 +0530 drm/virtio: reclaim pending vbufs before tearing down vqs [ Upstream commit 61d85f99b5a55d4f717c4bb2f4c4acabf22ee3fc ] virtio_gpu_free_vbufs() destroys the vbufs kmem_cache after the virtqueues have already been released. Commands that were queued but never completed by the device leave their vbuffers stranded in the virtqueue, so the cache still holds live objects when virtio_gpu_deinit() tears everything down. This triggers a WARNING in virtio_gpu_free_vbufs: BUG virtio-gpu-vbufs (Not tainted): Objects remaining in cache on __kmem_cache_shutdown() Drain any buffers still sitting in the control and cursor virtqueues in virtio_gpu_deinit() after the device has been reset and before the virtqueues are deleted, following the same pattern used by virtio_console's remove_vqs(). Each reclaimed buffer is released with free_vbuf(), dropping the reference on any GEM objects it holds. Pending RESOURCE_UNREF commands are handled as well: their resp_cb_data still references a GEM object, so it is cleaned up with virtio_gpu_cleanup_object() to avoid leaking it on teardown. Reported-by: syzbot+06f9b2a53ba4a5a47644@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=06f9b2a53ba4a5a47644 Signed-off-by: Anuj Bolewar Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260802-virtio-gpu-reclaim-vbufs-v2-1-5767fb860691@gmail.com Signed-off-by: Sasha Levin commit 72e4aeb3b6e707db3c9b0a0ece0034cc2777cee1 Author: Basavaraj Natikar Date: Mon Aug 3 23:22:27 2026 +0530 HID: amd_sfh: Serialize access to the shared emp2 pointer [ Upstream commit c57016bcf6d0b57cda5579e5d6856bd9bbe52a77 ] The SFH accessors reach the device through a file-global emp2 pointer that is published at probe and cleared on remove. amd_get_sfh_info() is exported and called from other modules on unrelated threads, so a reader can observe a non-NULL emp2 and then race a concurrent unbind that clears it and frees the device. Serialize the emp2 publish/clear and all readers under a mutex, so a reader either sees a live device for the whole access or sees NULL. Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9f38adcea4f3b01558e97a9aad7c3c2605ffaa64 Author: Neil Andrews Date: Thu Aug 13 20:41:24 2026 +0000 ALSA: usb-audio: Rename the Audient iD14 monitor mix volume control [ Upstream commit 9c0564fcc21aec4f5b7648f61865ce3fc2b84a7f ] On the Audient iD14 (2708:0008), feature unit 12 is traced through to the Speaker output terminal and is therefore exported as "Speaker Playback Volume". The name fits it badly. It advertises Volume on only four of its six logical channels, which the driver records as cmask=0xf, channels=4 on a 6-channel playback stream, and it sits on the monitor mixer branch rather than in the direct playback path: INPUT_TERMINAL 2 (USB streaming, 6ch) -> EXTENSION_UNIT 51 -> FEATURE_UNIT 10 (no controls) -> OUTPUT_TERMINAL 20 (Speaker) while FU 12 hangs off MIXER_UNIT 60 and feeds back into EXTENSION_UNIT 51. Userspace adopts the control as the stream's hardware playback volume, so any setting below 0 dB attenuates part of the stream and not the rest. Measured over the device's own digital loopback, with one -12 dBFS tone per channel played straight to hw:, PCM channel 0 is unaffected while channel 1 tracks the control: at 107/127 (-20 dB) the two read -15.89 and -35.89 dBFS, a 20.00 dB imbalance, and at 127/127 both read -15.89 dBFS. Give the unit a non-standard name so that it is no longer taken for the stream's master volume. Dropping the control instead also fixes the imbalance, but FU 12 keeps its value across a module reload, so dropping it strands a device that is already attenuated with nothing able to reset it. Renaming leaves the monitor gain reachable and that recovery path intact. The mapped name ends in "Playback" because a name from the map suppresses the automatic " Playback" but still gets " Volume" appended; the control comes out as "Monitor Mix Playback Volume". Tested on the ACP path with PipeWire, which is where the problem reproduces: the control now stays at 127 at every volume setting and the imbalance is 0.00 dB, and setting it by hand to 107 and back to 127 gives 20.00 dB and 0.00 dB as before. Link: https://lore.kernel.org/linux-sound/0102019fed22f9d3-fa294ec5-02f1-4fd3-b3fa-76efc14331cc-000000@eu-west-1.amazonses.com/T/#u Signed-off-by: Neil Andrews Link: https://patch.msgid.link/0102019ffcdbb1e6-9b59d3cc-ef05-4df1-8f9f-fb2f425bcda2-000000@eu-west-1.amazonses.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 89e76d0fc8d25a47c391b56d5c34367759612c8e Author: Mathias Nyman Date: Thu Aug 6 17:20:59 2026 +0300 xhci: include all root port children in recovery prevention on link error [ Upstream commit e3d757dc9257f2638ca61eda4faef26c2daeea10 ] Driver already prevents useless transfer retry and endpoint recovery for devices directly connected to a root port with link errors. These devices are either disconnecting or will be reset. Link is gone. Move the flag indicating link error from the xhci device structure to the root port strucure, allowing all child devices behind hubs to easily check for root port link errors, avoiding useless transfer retries and endpoint recovery. This extends the previous endpoint recovery prevention in commit b8c3b718087b ("usb: xhci: Don't try to recover an endpoint if port is in error state.") Only root port link errors can be detected early by xhci driver, not link errors between external hubs and their children. Tested-by: Xu Rao Signed-off-by: Mathias Nyman Link: https://patch.msgid.link/20260806142113.2436238-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d80451f7f980fc45eee9fe2b3b3ed9cd6bad1a8f Author: Takashi Iwai Date: Thu Aug 13 17:03:49 2026 +0200 ALSA: hda/intel: Add sanity check for BAR0 size [ Upstream commit 9895573b0185f922be4cf500a0f2e5b9560ab1c3 ] The recent reports from syzkaller showed that we can bind any wild PCI device to HD-audio controller, and if PCI BAR of the device is too small, it may lead to a crash, as the driver believes as if the full register range were accessible. For avoiding such a problem, add a safeguard before the actual probe to check the available BAR0 size. Note that the threshold (0x200) is chosen to cover all needed registers at probing. But this doesn't mean that it would cover fully for all features including the extended ones. Reported-by: syzbot+10cd2d1efe8eeb604bee@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=10cd2d1efe8eeb604bee Reported-by: syzbot+5ebe7cd17e48b4293660@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5ebe7cd17e48b4293660 Link: https://patch.msgid.link/20260813150354.763502-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9409d38fdde0b598573cb4c7d0fe4608053205af Author: Farhan Ali Date: Wed Aug 5 09:55:16 2026 -0700 PCI: Avoid saving config space state if inaccessible [ Upstream commit e18d1abc3bff0a24a5299f3c150ab9546e9439aa ] The current reset process saves the device's config space state before reset and restores it afterward. However errors may occur unexpectedly and it may then be impossible to save config space because the device may be inaccessible (e.g. DPC). This results in saving invalid values that get written back to the device during state restoration. With a reset we want to recover/restore the device into a functional state. So avoid saving the state of the config space when the device config space is inaccessible. Signed-off-by: Farhan Ali [bhelgaas: comment] Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Schnelle Reviewed-by: Bjorn Helgaas Link: https://patch.msgid.link/20260805165518.794-4-alifm@linux.ibm.com Signed-off-by: Sasha Levin commit 6def7dd96f0408dd2bb7e6d5a6835b7d56f19583 Author: Michail Tatas Date: Fri Aug 7 01:30:20 2026 +0300 ipmi: Fix leak in __ipmi_bmc_register [ Upstream commit 18e633dd9674c8bf118ea8583bb5a531edc2728a ] In case that ida_alloc(&ipmi_bmc_ida,...) succeeds and then platform_device_register() fails, ipmi_bmc_ida is leaked. Fix by freeing the error path Signed-off-by: Michail Tatas Message-ID: Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit c2d18aa6481632b69f7af787a35b52a3f78d0913 Author: Charles Keepax Date: Fri Aug 7 13:14:25 2026 +0100 soundwire: dmi-quirks: Disable ghost Realtek on Asus ROG Zephyrus Duo [ Upstream commit 5b08a3afd2995e5312c4c47ffea9d21b651e8e13 ] The Asus ROG Zephyrus Duo also has a Realtek device in the ACPI that doesn't exist in the physical hardware. This confuses the machine driver into attempting to create DAI links for the device. Add a quirk to remove this device. Suggested-by: Bard Liao Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260807121425.1952003-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 14ecf77177cb1d432dd415a9aed2fe88dc1cc02a Author: Arash Golgol Date: Wed Aug 12 16:20:54 2026 +0330 regulator: fan53555: Add support for FAN53555BUC23X type [ Upstream commit e739acbe05b06de78ef7089470f122432f651faa ] FAN53555BUC23X has the ID 0 and REV 0xc, starts at 600mV and increments in 12.5mV steps. Per the datasheet, the FAN53555BUC23X (23 option) is grouped with the 00 and 13 options for soft-start timing (t_SS = 300us typ.), so the existing enable_time = 400 is reused here as well. This variant is found on the ASUS Tinker Edge R (RK3399Pro) as the supply regulator for both vdd_gpu and vdd_cpu_b. Verified across the full GPU OPP table with the userspace devfreq governor. Signed-off-by: Arash Golgol Link: https://patch.msgid.link/20260812125054.19111-1-arash.golgol@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fe976b0e3c8a4f4c738dec7e0746f03c60bf0de3 Author: Jiaming Zhang Date: Mon Aug 10 17:24:21 2026 +0800 hfsplus: validate extent record length before writing it back [ Upstream commit 627b7865c062ff642c0000f3a4775f1a44b986a4 ] __hfsplus_ext_write_extent() writes the cached extent record back into a B-tree node using fd->entrylength as the length, and fd->entrylength is derived in __hfs_brec_find() from two on-disk values: fd->entrylength = len - keylen; A crafted image can keep both len and keylen valid but make fd->entrylength negative (keylen > len). __hfsplus_ext_write_extent() doesn't check fd->entrylength before consuming it, and hfs_bnode_write() takes the length as u32, so the negative value turns into a huge one. The copy then reads data past the end of hip->cached_extents, which is only sizeof(hfsplus_extent_rec) bytes long, and leaks kernel memory into the image. Reject an fd->entrylength that does not match sizeof(hfsplus_extent_rec) in __hfsplus_ext_write_extent(), mirroring the check already performed in __hfsplus_ext_read_extent(). Link: https://lore.kernel.org/lkml/cbd7003314c530d4f910eacf019ff80adad6687e.camel@dubeyko.com/ Signed-off-by: Jiaming Zhang Reviewed-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260810092422.1691377-1-r772577952@gmail.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 2ed996cb5d14db93bee46813a682e99bd0e09b9d Author: Dmytro Moroziuk Date: Wed Aug 12 15:18:56 2026 +0300 ALSA: hda/conexant: Add mute LED quirk for HP ProBook 440 G5 [ Upstream commit 191fe151eb85ff6cb24189fc88c970745497c057 ] The HP ProBook 440 G5 requires the CXT_FIXUP_MUTE_LED_GPIO quirk to properly toggle the physical mute and mic-mute LEDs via the CX8200 codec. Without this quirk, the LEDs remain permanently dark. Signed-off-by: Dmytro Moroziuk Link: https://patch.msgid.link/20260812121856.30353-1-dmorozyk1@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 340894cf9332883e20eed0b1f051e4efb6af1861 Author: Matt Turner Date: Mon Aug 10 16:28:34 2026 -0400 alpha: run the remote RTC access in a worker, not an IPI callback [ Upstream commit 6f45effbd74012f1715584ba51abaa3196a47c08 ] On Marvel the CMOS clock is only reachable from the boot cpu, so remote_read_time() and remote_set_time() bounce the access there with smp_call_function_single(), whose callback runs in hard interrupt context. alpha_rtc_read_time() calls mc146818_get_time() with a 10 ms timeout. That waits out the RTC update cycle in mc146818_avoid_UIP(), which drops rtc_lock and udelay()s 100 us at a time until the update completes or the timeout expires: for (i = 0; UIP_RECHECK_LOOPS_MS(i) < timeout; i++) { spin_lock_irqsave(&rtc_lock, flags); ... if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) { spin_unlock_irqrestore(&rtc_lock, flags); udelay(UIP_RECHECK_DELAY); continue; } So a clock read from a non-boot cpu can spin for up to 10 ms in hard interrupt context on the boot cpu, while the cpu that sent the request spins in smp_call_function_single() waiting for it to finish. mc146818_set_time() does not poll, but it takes rtc_lock too, and rtc_lock is a spinlock_t. Only raw spinlocks may be taken in hard interrupt context, so lockdep reports the write path as soon as a non-boot cpu sets the clock: [ BUG: Invalid wait context ] ----------------------------- swapper/0/0 is trying to lock: fffffc0003690470 (rtc_lock){....}-{3:3}, at: mc146818_set_time+0x74/0x450 other info that might help us debug this: context-{2:2} no locks held by swapper/0/0. stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc1 #1 NONE Trace: [] dump_stack+0x28/0x44 [] __lock_acquire+0xb0c/0x1060 [] lock_acquire.part.0+0xd0/0x300 [...] [] mc146818_set_time+0x74/0x450 [] _raw_spin_lock_irqsave+0x7c/0xc0 [] do_remote_set+0x90/0xc0 [] __flush_smp_call_function_queue+0x314/0x5c0 [] generic_smp_call_function_single_interrupt+0x24/0x40 [] handle_ipi+0xa4/0x230 [] do_entInt+0x1a4/0x2e0 The rtc class ops are always called from process context, so there is no reason to run the access from an interrupt at all. Use work_on_cpu() to run it in a worker on the boot cpu. Alpha does not support cpu hotplug, so the boot cpu cannot go offline while the work is pending. Tested on an AlphaServer ES47 (Marvel/EV7): hwclock read and write pinned to a non-boot cpu, twenty times, with no splat. Signed-off-by: Matt Turner Reviewed-by: Magnus Lindholm Link: https://lore.kernel.org/r/20260810202835.3592833-1-mattst88@gmail.com Signed-off-by: Magnus Lindholm Signed-off-by: Sasha Levin commit f360874df64b9268d2e8b0ebaa75a8e73459afba Author: Chao Shi Date: Mon Aug 10 18:02:58 2026 -0400 nvme: ratelimit the completion-path messages driven by device data [ Upstream commit c05c86681170e381e24498257db3a879deb1ae89 ] nvme_find_rq() and nvme_handle_cqe() print an unratelimited message for every completion queue entry whose command id does not resolve to an in-flight request. Both are reached from the completion interrupt path (nvme_irq() -> nvme_poll_cq() -> nvme_handle_cqe()) and the decision to print is made entirely from device-supplied data, so a controller that posts a stream of bogus command ids drives unbounded printk from hard interrupt context. This is not hypothetical. A single boot under an emulated controller that posts invalid completions produced 846 "could not locate request for tag 0x0", 846 "invalid id 0 completed on queue 2" and 123 "genctr mismatch" lines. Once the tag set has been torn down every subsequent completion resolves to nothing, so the print rate is bounded only by how fast the device can post entries. Ratelimit the three messages. The information they carry is diagnostic and repeats, so the suppression count printed by the ratelimit helpers is enough to tell that the condition persists. This matches how the other device-driven error prints in the driver are already handled, for example the status messages in nvme_log_error() and nvme_log_err_passthru(). nvme_find_rq() lives in nvme.h and is shared by pci, tcp, rdma, apple and target-loop, so all transports are covered. Found by FuzzNvme. Signed-off-by: Chao Shi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 9c5a037acdec408a7db4a85fbc78217109ee72e7 Author: Griffin Kroah-Hartman Date: Tue Jul 7 16:23:27 2026 +0200 nfc: nxp-nci: Add remove on IRQ error [ Upstream commit 56345cea6a30dc7a1b036d5fb7900434b4a4c5e8 ] Add a call to nxp_nci_remove() in nxp_nci_i2c_probe() when the request_threaded_irq() fails. Previously, IRQ resources were not being freed upon error. Assisted-by: gkh_clanker_2000 Cc: David Heidelberg Cc: Carl Lee Cc: Jakub Kicinski Cc: Krzysztof Kozlowski Cc: Ian Ray Cc: "Uwe Kleine-König (The Capable Hub)" Signed-off-by: Griffin Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Reviewed-by: Ian Ray Link: https://patch.msgid.link/2026070726-observer-fang-9716@gregkh Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit d72106a40a554fae26e600214bac2aaeb12e4203 Author: Griffin Kroah-Hartman Date: Tue Jul 7 16:22:17 2026 +0200 nfc: mrvl: spi: Unregister dev on allocation fail [ Upstream commit d832b95697384a2b67f20b35106bbf925358cde9 ] Call nfcmrvl_nci_unregister_dev() if nci_spi_allocate_spi() fails, unwrapping the previous call to nfcmrvl_nci_register_dev() during the nfcmrvl_spi_probe() function. Assisted-by: gkh-clanker-2000 Cc: David Heidelberg Signed-off-by: Griffin Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026070716-crucial-slouchy-b8a9@gregkh Signed-off-by: David Heidelberg Signed-off-by: Sasha Levin commit 8f22f2b887fcfa62fd5f62f1b98c67be727b8632 Author: Vasant Hegde Date: Tue Aug 11 04:08:58 2026 +0000 iommu/amd: Fix missing CMD_COMPLETE_PPR response for invalid PPR requests [ Upstream commit bc1f5ec826bfa510e7138e2be5aad23907850874 ] The AMD IOMMU spec, requires the host to respond with a CMD_COMPLETE_PPR command when an EVENT_TYPE_INV_PPR_REQ event is received with the RX bit cleared. This response was missing in the current implementation, leaving invalid PPR requests unacknowledged. Introduce amd_iommu_report_ppr_err() to handle EVENT_TYPE_INV_PPR_REQ events. The new function logs the invalid PPR request and when the RX bit is cleared, sends CMD_COMPLETE_PPR response. Reported-by: Gaultier Delbarre Co-developed-by: Wei Huang Signed-off-by: Wei Huang Signed-off-by: Vasant Hegde Reviewed-by: Ankit Soni Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 7c42cf55b15fef029488b97623156f12540b07d6 Author: Feng Tang Date: Fri Aug 7 08:24:36 2026 +0800 selftests: net: reuseport_bpf_numa: consider cpuless numa node [ Upstream commit 88b8d85e889e2fe1cce3e66e50c3029dda94842a ] reuseport_bpf_numa case failed when testing on a platform with CXL memory: #./reuseport_bpf_numa ---- IPv4 UDP ---- send node 0, receive socket 0 ./reuseport_bpf_numa: failed to pin to node: Invalid argument The root cause is that the platform has 2 numa nodes: node 0 has both cpu and memory, while node 1 is a CXL node which only has memory, and caused numa_run_on_node() to fail. Add sanity check to skip cpuless numa node for the numa binding test. Signed-off-by: Feng Tang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260807002436.43991-1-feng.tang@linux.alibaba.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0929249787896b9b7a0daab3c5301b19faa9fa52 Author: John Johansen Date: Tue Jul 28 13:14:49 2026 -0700 apparmor: fix auditing of mount binary data [ Upstream commit b9f2181b90ec047488dcb4fb1c631d417aff07e0 ] AppArmor only mediates non-binary mount data, and should only audit the mount data if it is non-binary. Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 2f99cf389f72032776898fb2aa29842786ad4651 Author: Rongguang Wei Date: Fri Aug 7 15:09:14 2026 +0800 tap: fix incorrect variable used for USO check in set_offload() [ Upstream commit fac7973f004de6dd51fb15a33e33ed37718e58bb ] The USO features in set_offload() incorrectly uses feature_mask and features argument. The USO feature was written to the local features variable instead of feature_mask. All other offload bits (TSO, TSO_ECN) are stored in feature_mask which becomes tap->tap_features and is used by tap_handle_frame() for GSO segmentation. Without NETIF_F_GSO_UDP_L4 in tap->tap_features, making USO on tap effectively non-functional. Keeping the USO handling inside the TUN_F_CSUM block avoids enabling GRO/LRO when userspace requests USO without CSUM. This has not worked since the beginning, so commit 399e0827642f ("driver/net/tun: Added features for USO.") Signed-off-by: Rongguang Wei Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260807070914.112698-1-clementwei90@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 852e06e77d7eced54aabf42c5f002d306c7a26de Author: Geliang Tang Date: Sun Jul 26 10:46:49 2026 +0800 nvme-tcp: look up host_iface in the current netns [ Upstream commit 58202950e39c127d593ec4f0624d8b8985a285b1 ] nvme_tcp_alloc_ctrl() looks opts->host_iface up in &init_net, the boot-time netns. When called from any other netns - e.g. the selftest's ns2, where ns2eth1 actually lives - the lookup misses and the controller setup fails with "invalid interface passed": nvmet: adding nsid 1 to subsystem nqn.2014-08.org.nvmexpress.mptcpdev nvmet_tcp: enabling port 24660 (0.0.0.0:24099) # nvme discover -a 10.1.1.1 --tos=0x10 --host-iface=ns2eth1 nvme_tcp: invalid interface passed: ns2eth1 # failed to add controller, error invalid interface Look the device up in current->nsproxy->net_ns instead so the check sees the calling task's netns. Reviewed-by: Hannes Reinecke Signed-off-by: Geliang Tang Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 42a29688f693bb3fdb0c39d6b581167570b8b293 Author: Zhe Liu Date: Mon Aug 10 14:35:35 2026 +0800 docs: cgroup-v2: fix stale "io" controller introduction [ Upstream commit 3345c7248a9e2a91cb9e2477c29af16881706f4f ] The introductory paragraph for the IO controller still states that weight based distribution is "available only if cfq-iosched is in use" and that "neither scheme is available for blk-mq devices". This text dates from when the cgroup v2 documentation was first written (2015) and was correct at the time, but is no longer accurate: * cfq-iosched was removed in v5.0; * blk-mq is now the only block I/O path, and both the absolute limit scheme (io.max via blk-throttle) and the weight based scheme (io.weight via iocost, or io.bfq.weight under BFQ) work on it; * latency based protection (iolatency) and I/O priority (ioprio) controllers have since been added. The rest of the section already documents io.weight, io.max, io.cost.{qos,model}, io.latency and io.prio.class correctly, so the introduction is the only part that contradicts them. Rewrite it to reflect the current state. Signed-off-by: Zhe Liu Reviewed-by: Tao Cui Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 9407cfd34fe29d2804a79c2a50fbc078a89652d9 Author: Brian Grech Date: Thu Aug 6 10:16:45 2026 -0500 selftests/net: fin_ack_lat: fix latency threshold typo [ Upstream commit 2373107782a98ba15931a37bbd9dd46d7213e5aa ] The commit message for af8c8a450bf4 ("selftests: net: Add FIN_ACK processing order related latency spike test") states: "if the latency is larger than 1 second (spike), print a message". However the code uses a threshold of 100000 us (100 ms), not 1000000 us (1 s). The lower threshold causes false positives on slower hardware where normal connection latency occasionally exceeds 100 ms but never approaches the 1 s spike that indicates the actual FIN/ACK race bug. Fix the threshold to match the documented intent. Reviewed-by: Simon Horman Signed-off-by: Brian Grech Link: https://patch.msgid.link/20260806151645.4172900-1-bgrech@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit def617fb61508dcfc921ee293fade45ed8129d03 Author: Hari Mishal Date: Fri Jul 17 16:43:53 2026 +0200 nvmet: passthru: fix OOB reads when parsing ns id descriptor list [ Upstream commit bc7f75eba50012ed447654d8ce169ebaba695193 ] nvmet_passthru_override_id_descs() walks a namespace identification descriptor list populated from the underlying passthru controller's Identify response, which is device reported. The loop advanced pos by device controlled amounts (sizeof(*cur) + nidl) without checking that the next descriptor header actually fits inside the buffer, so a malicious device could push pos to within a few bytes of the buffer end and cause cur->nidl, cur->nidt or the reserved field to be read past the allocation. Additionally, when a CSI descriptor lands exactly at the last valid header offset, cur + 1 points one byte past the end of the buffer. The unconditional memcpy(&csi, cur + 1, NVME_NIDT_CSI_LEN) could read that out-of-bounds byte and copy it back to the initiator via nvmet_copy_to_sgl(), leaking adjacent heap memory. Bounds check both the descriptor header and the CSI value before dereferencing them. Signed-off-by: Hari Mishal Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 1f8ddae246332537b4681fae2918d9a788d17c91 Author: Dapeng Mi Date: Fri Jul 17 16:03:36 2026 +0800 perf/x86: Free hybrid state on PMU init failure [ Upstream commit 96746e731e1626545e343974ca4673739dceb31b ] If PMU initialization fails, for example in check_hw_exists(), hybrid state can be left partially initialized: x86_pmu.hybrid_pmu is not freed and perf_is_hybrid remains set. This can leak memory and leave stale hybrid state reachable after a failed init path. Add x86_pmu_free_hybrid() and use it on PMU init failure paths so all hybrid-related state is consistently reset. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Thomas Falcon Reviewed-by: Zide Chen Link: https://patch.msgid.link/20260717080342.1879573-3-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit 5db10037b9c1288d70680c3dde2b8553f35aa62e Author: Dapeng Mi Date: Fri Jul 17 16:03:35 2026 +0800 perf/x86: Unregister PMI handler on PMU init failure [ Upstream commit 91787047b1dc52b1fee68b07f79af70aae5fce47 ] Fix an NMI handler leak in init_hw_perf_events(). When PMU initialization fails after register_nmi_handler(), the error path exits without calling unregister_nmi_handler(), leaving a stale NMI_LOCAL "PMI" handler registered. Add the missing call before clearing x86_pmu state. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Thomas Falcon Reviewed-by: Zide Chen Link: https://patch.msgid.link/20260717080342.1879573-2-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit ad47c1a094740ce3207bb28477b0c83d352ad5a0 Author: Michal Pecio Date: Mon Aug 10 07:57:28 2026 +0200 ALSA: usx2y: Stop clearing urb->hcpriv before submission [ Upstream commit fabae5548149ef5c8a056875d9ebdc38366db539 ] This is managed by USB core and drivers aren't expected to touch it. It should only be not NULL on a submitted URB, in which case clearing defeats the "submitted while active" sanity check in usb_submit_urb() and may crash the HCD handling the URB and panic the kernel. Signed-off-by: Michal Pecio Link: https://patch.msgid.link/20260810075728.483c827e.michal.pecio@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1b8a5b21ef8d9ba3f7b59e5e606b8e94a26fe76f Author: Guanghui Feng Date: Wed Aug 5 07:42:57 2026 +0800 iommu/vt-d: Fix CACHE_TAG_NESTING_DEVTLB polluting shared variables in flush loop [ Upstream commit 3846e469c1ba1407260066070bff5c88ee39a4c7 ] In cache_tag_flush_range(), the CACHE_TAG_NESTING_DEVTLB case modifies the shared local variables 'addr' and 'mask' before falling through to CACHE_TAG_DEVTLB. This causes all subsequent CACHE_TAG_DEVTLB entries in the same loop iteration to incorrectly use the full-range flush parameters (addr=0, mask=MAX_AGAW_PFN_WIDTH) instead of the precisely calculated PSI range. This is not the intended behavior, as regular DEVTLB entries should always perform targeted range-based invalidation. Fix this by having CACHE_TAG_NESTING_DEVTLB directly call cache_tag_flush_devtlb_psi() with the full-range constants and break, instead of modifying shared variables and falling through. This ensures CACHE_TAG_DEVTLB always uses the original calculated addr and mask for precise range flush. This change slightly affects trace_cache_tag_flush_range() behavior. Previously, after addr/mask were overwritten, the tracepoint could record a full-range flush even when the caller requested a narrower range. The tracepoint should reflect caller intent. Although this helper may widen the actual hardware invalidation range for implementation reasons, that does not change what the caller requested, so logging the requested range is the correct behavior. If the actual invalidation range sent to hardware is needed, it is already visible via the qi_submit trace event, which records the invalidation descriptors emitted by the driver. Signed-off-by: Guanghui Feng Signed-off-by: Guixin Liu Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 01f4a7eeedac8e8f597dde77e61538dbd2be541d Author: Pengpeng Hou Date: Mon Jul 6 17:30:38 2026 +0800 fbdev: udlfb: validate vendor descriptor items [ Upstream commit 3cc2fad376ac7360b4518277aa923752624db59c ] dlfb_parse_vendor_descriptor() walks key-length-value items inside the DisplayLink vendor descriptor. Require each item to contain its key, length and declared value bytes before reading item-specific fields such as max_area. Signed-off-by: Pengpeng Hou Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 8b9b1c171bafe87ac6a7c02b7cf33fd09e237642 Author: Andreas Kemnade Date: Thu Jul 2 17:50:35 2026 +0200 fbdev: omap2: dsi: do not copy isr table [ Upstream commit 31875c51c31edec57b3620f278680c23a823763b ] To te able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table. Suggested-by: sashiko-bot@kernel.org Signed-off-by: Andreas Kemnade Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 8020e4ad1c59f89fbe5d77c50e9328bf6b007397 Author: Atish Patra Date: Fri Aug 7 19:24:30 2026 -0600 RISC-V: perf: fix resource cleanup on driver probe failure [ Upstream commit e24a1418e90beac2ef4384bc9b0b5a10f19b806e ] Sashiko pointed out various UAF and memory leak issues around pmu_sbi_device_probe() error paths. If the probe fails, here are list of cleanups needed. a. Already registered pmu must be freed b. per cpu IRQ must be released c. pmu_ctr_list data structure must be freed d. cpu hotplug state must be cleaned up only if added. Fix the resource cleanup by reorganizing the code around probe failure. Reported-by: Sashiko AI Reviewed-by: Charlie Jenkins Signed-off-by: Atish Patra Link: https://patch.msgid.link/20260807-counter_delegation-v9-1-58658104e487@meta.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 38c960fb5b83ac2c94208df1799763df661ad24b Author: Rui Qi Date: Fri Aug 7 19:24:33 2026 -0600 riscv: kprobes: Prevent probes in breakpoint handlers [ Upstream commit e7d8ea6c6d1bc685a8943ffad2d3679be92d164f ] The ftrace selftest multiple_kprobes.tc registers kprobe events on the first 256 text symbols from /proc/kallsyms. If handle_break() is selected as a probe target on RISC-V, the breakpoint exception path can trap again before it reaches the kprobe breakpoint handler. That recursively enters do_trap_break() and can make the system unresponsive. Mark handle_break() and its local probe dispatch helpers as nokprobe symbols so they are added to the kprobe blacklist, matching other low-level breakpoint exception paths. Signed-off-by: Rui Qi Reviewed-by: Nam Cao Link: https://patch.msgid.link/20260806043807.2583001-1-qirui.001@bytedance.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 2c6e0e56225900be64ae591945f3c30faf2ab951 Author: Daniel Golle Date: Tue Aug 4 04:10:46 2026 +0100 net: dsa: mt7530: check CORE_PLL_GROUP4 access in mt7531_setup() [ Upstream commit 1ae63b018d3d70e96d420b59a1334860cf232bc6 ] mt7531_setup() reads CORE_PLL_GROUP4 through the MT7531 indirect c45 PHY access, modifies it and writes it back to enable the PHY core PLL, but checks neither the read nor the write. Now that the indirect access functions propagate command-write failures, a failed read returns a negative errno that would be bit-modified and written back into the PLL register, and a failed write-back would go unnoticed. Check both and bail out. The adjacent EEE advertisement writes push a constant value and cannot corrupt state, so they are left as is. Signed-off-by: Daniel Golle Link: https://patch.msgid.link/a7dfe3b66ea6ac1ae7915034de0527060e6ddcd4.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 77eed1651eb6f8119bc6982e75416205abf80456 Author: Daniel Golle Date: Tue Aug 4 04:10:26 2026 +0100 net: pcs: mtk-lynxi: check regmap reads in mtk_pcs_lynxi_get_state() [ Upstream commit 5cc65c01cdc577621d1320f4aa03a1382c5a4a45 ] mtk_pcs_lynxi_get_state() ignores regmap_read()'s return value; a failed read leaves bm and adv holding uninitialized stack values which are then decoded into the reported link state. The regmaps backing the MT7531 SGMII PCS instances sit on an MDIO bus where reads can fail. Check both reads and report the link as down on error; phylink presets state->link before the callback, so a bare return would leave a failed read reported as link-up. Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/fce70657fc03bbaf60a04c0fbf2f418531135c4f.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f3cd9a1d3828d887764df8151d76583d4758985d Author: Daniel Golle Date: Tue Aug 4 04:10:33 2026 +0100 net: dsa: mt7530: check bus->read() error in core_rmw() [ Upstream commit 573d6e3afe3d01e34dc82c77bf22ca96a74d805e ] core_rmw() accesses the MMD core registers directly rather than through the regmap and has the same unchecked bus->read() as the one just fixed in the MDIO regmap backend: a negative errno is consumed as register data, modified and written back to the switch. Check the read and bail out like the surrounding bus accesses do. Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/48bb9f0b311a9efeda2a6b24a7e05d4792393a3b.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 851a01505ed711a04ed8d11898a7dc03d3071697 Author: Laxman Acharya Date: Wed Aug 5 23:22:01 2026 +0545 Bluetooth: hci_event: fix out-of-bounds read in LE PA report reassembly [ Upstream commit e3643fbddb257c928c075cab05bbd929106b56ee ] hci_le_per_adv_report_evt() is dispatched with a minimum length of sizeof(struct hci_ev_le_per_adv_report), which only covers the fixed part of the event and not the trailing data[] array: struct hci_ev_le_per_adv_report { __le16 sync_handle; __u8 tx_power; __u8 rssi; __u8 cte_type; __u8 data_status; __u8 length; __u8 data[]; } __packed; The handler notifies the ISO layer via hci_proto_connect_ind(), which reaches iso_connect_ind(). That function retrieves the stored event with hci_recv_event_data() and, while reassembling the periodic advertising data, does: memcpy(hcon->le_per_adv_data + hcon->le_per_adv_data_offset, ev->data, ev->length); ev->length is taken directly from the event and is never validated against the amount of data the event actually carries. A controller that reports a length larger than the received event therefore causes the memcpy() to read past the end of the event buffer. The leaked bytes are stored in hcon->le_per_adv_data and can subsequently be read back from user space via getsockopt(BT_ISO_BASE). Validate that the event contains ev->length data bytes before it is consumed, mirroring the check already performed by hci_le_ext_adv_report_evt() and hci_le_adv_report_evt(). Signed-off-by: Laxman Acharya Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7723752655f250b66aba4815980360f3b9e20d86 Author: Daniel Golle Date: Tue Aug 4 04:10:40 2026 +0100 net: dsa: mt7530: error out on failed PHY_IAC command writes [ Upstream commit 1c95dcb7e923beebccdc79adc3dc1ec8c52295d0 ] MT7531_PHY_ACS_ST is only ever set by the command write that precedes each poll in the MT7531 indirect PHY access functions, and that write's return value is discarded. A failed write leaves ACS_ST at 0 from the previous access, so the poll succeeds on its first iteration and the functions return stale IAC contents as if they were fresh PHY data. Check the writes and bail out before polling. Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/c34602e63a20ebbfb97babd145c82832d7a0b523.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9f8852db6036a66d8e6d645dbe0477e9a3364272 Author: Muhammad Saheed Date: Wed Aug 5 01:40:51 2026 +0530 Bluetooth: hci_sync: Disable legacy instance's ext adv before setup snapshot [ Upstream commit 75722cde87ee24029e93e4e32d85309989f55991 ] hci_setup_ext_adv_instance_sync(...) only disabled HCI_OP_LE_SET_EXT_ADV_ENABLE before setup snapshot in case of non-legacy instances (instance > 0) and never disabled the same for legacy instance (instance == 0). This would lead to failure in setting ext adv params with HCI_ERROR_COMMAND_DISALLOWED (0x0c) error like below, when toggling the discoverable/connectable property of a controller with advertising enabled. ``` $ btmgmt advertising off hci0 Set Advertising complete, settings: powered ssp br/edr le secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt connectable on hci0 Set Connectable complete, settings: powered connectable ssp br/edr le secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt connectable off hci0 Set Connectable complete, settings: powered ssp br/edr le secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt advertising on hci0 Set Advertising complete, settings: powered connectable ssp br/edr le advertising secure-conn wide-band-speech cis-central cis-peripheral $ btmgmt connectable on Set Connectable for hci0 failed with status 0x0a (Busy) $ btmgmt connectable off Set Connectable for hci0 failed with status 0x0a (Busy) $ dmesg ... [ 21.970527] hci0: Opcode 0x2036 [ 21.970529] hci0: opcode 0x2036 plen 25 [ 21.970537] hci0: skb len 28 [ 21.970539] hci0: length 1 [ 21.976099] hci0: result 0x0c [ 21.976105] hci0: end: err -16 [ 21.976114] Bluetooth: hci0: Opcode 0x2036 failed: -16 ``` Signed-off-by: Muhammad Saheed Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit cb2e195752677e3f9ea113c3d45a54e6217da82f Author: Iva Kasprzaková Date: Wed Jul 22 15:08:49 2026 +0200 Bluetooth: fix BT dependency for submodules [ Upstream commit 6ec1896b5331563fedf3f01014aba9c9e35d7f29 ] The modules rfcomm (BT_RFCOMM), bnep (BT_BNEP), hidp (BT_HIDP), and bluetooth_6lowpan (BT_6LOWPAN) are dependent on the bluetooth module (BT, tristate) only transitively through the boolean BT_BREDR for the first three and through the boolean BT_LE for the bluetooth_6lowpan. Therefore, the modules can be selected as built-in even if the BT=m. The combination of BT=m and =y for the said modules leads to the kernel build system silently ignoring those modules, without ever compiling them as built-in or as loadable modules. Add BT as a direct dependency to the Kconfig of rfcomm, bnep, hidp, and bluetooth_6lowpan. The modules set to =y when BT=m will default to =m, rather then getting silently ignored by the build system. Signed-off-by: Iva Kasprzaková Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3fb4a0376b4ee5e831c5042492a5fdd3d5f9381f Author: Li Qiang Date: Thu Jul 16 16:47:30 2026 +0800 Bluetooth: hci_bcsp: validate received packet lengths [ Upstream commit ceea75ad8925425ee6520ead964b55888fe871ec ] The BCSP transmit path reads an HCI command header when an extension packet has only been tested for a nonzero length. Its LE configuration packet handler also indexes bytes through offset seven without a length check. Validate the complete command and LE configuration packet headers before accessing their fields. Signed-off-by: Li Qiang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 6594a73c6b1b03c66d13549d55ed195ab5b97048 Author: Chen Changcheng Date: Wed Jul 22 16:31:36 2026 +0800 Bluetooth: btrsi: Move set_bt_context after successful HCI registration [ Upstream commit 290a3644609526f7ac12529cd1618042fa5a32db ] In rsi_hci_attach(), ops->set_bt_context() stores the newly allocated h_adapter into common->bt_adapter before hci_alloc_dev() and hci_register_dev() are called. If either of these fails, h_adapter is freed but common->bt_adapter remains a non-NULL dangling pointer. This causes a deterministically reachable use-after-free when the device operates in a BT+WiFi coexistence mode and CONFIG_RSI_COEX is enabled. The following software-only trigger paths exist: 1. SDIO driver .remove (rsi_disconnect) 2. USB driver .disconnect (rsi_disconnect) 3. SDIO driver .shutdown (rsi_shutdown) 4. Hibernation .freeze (rsi_freeze) All four paths check: if (IS_ENABLED(CONFIG_RSI_COEX) && coex_mode > 1 && bt_adapter) rsi_bt_ops.detach(bt_adapter); // use-after-free coex_mode is set during rsi_91x_init(), before rsi_hci_attach() is called, and is not cleared on attach failure. Since set_bt_context() already wrote bt_adapter before the failure, the deinit paths see a non-NULL dangling pointer and proceed to detach it. Fix this by moving set_bt_context() after hci_register_dev() succeeds. On failure paths bt_adapter stays NULL, and the deinit callers correctly skip the detach call. Signed-off-by: Chen Changcheng Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ea138f7a5a69cd10b125301cded99d5cd97510f7 Author: Zhang Heng Date: Fri Aug 7 20:58:54 2026 +0800 ALSA: hda/realtek: Add quirk for Acer Nitro ANV16-42 headset mic [ Upstream commit e00a6a89900dfa4cda3669558d2f3581cd41a656 ] The Acer Nitro ANV16-42 (subsystem 0x1025:0x1909, Realtek ALC245) does not detect the headset microphone jack. Adding the ALC2XX_FIXUP_HEADSET_MIC quirk resolves the issue and restores proper headset mic functionality. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221623 Signed-off-by: Zhang Heng Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260807125857.678297-1-zhangheng@kylinos.cn Signed-off-by: Sasha Levin commit 1e475880c031bfe8d3b94533401c49e27f15d4ee Author: Zhang Heng Date: Fri Aug 7 20:58:57 2026 +0800 ALSA: hda/conexant: Add pin config quirk for Huawei Matebook [ Upstream commit d152afd1cd7a69c752236b6e825c4e62a74788eb ] The headphone jack is not detected on this Huawei Matebook (Conexant SN6140 codec). The BIOS incorrectly marks Pin 0x18 as [N/A], causing the driver to report hp_outs=0 and no "Headphones" output appears. Override the pin configuration for NID 0x18 to set it as a headphone jack, which restores proper detection and audio routing. Link: https://github.com/thesofproject/sof/issues/10687 Signed-off-by: Zhang Heng Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260807125857.678297-4-zhangheng@kylinos.cn Signed-off-by: Sasha Levin commit 5af0fb2f2579e14f0a5f1d05f249ed4242a14e2b Author: Garrett Blackmon Date: Fri Aug 7 10:07:08 2026 -0500 ALSA: hda/realtek: Fix speakers on ASUS ROG Zephyrus G14 GA403UM [ Upstream commit 140fe610af607fd70da95c447943fc2690855519 ] The GA403UM (SSID 1043:1044) uses the same ALC285 codec + dual CS35L56 I2C amplifier topology as the GA403U and GA403W variants, which already have quirk entries (1043:1b13, 1043:1024). Without the quirk, the woofers sit on a separate DAC from the tweeters, so the hardware volume control only scales part of the speaker system and the headset microphone pins are not configured. Apply the existing ALC285_FIXUP_ASUS_GA403U_HEADSET_MIC fixup to the GA403UM as well. Signed-off-by: Garrett Blackmon Link: https://patch.msgid.link/20260807150708.33785-1-garrett@blackmon.dev Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5c462ae712133368283aad90dfbcde3eaa5a91fe Author: Zhang Heng Date: Fri Aug 7 20:58:56 2026 +0800 ALSA: hda/realtek: Fix headset mic on ASUS Vivobook S14 S5406SA [ Upstream commit f2d08f3651fb12634347fef2c41687a807a7dcba ] On the ASUS Vivobook S14 S5406SA (subsystem 0x104310c4, Lunar Lake platform) with an ALC294 codec, the headset microphone (3.5mm jack) fails to capture any audio. Adding the ALC2XX_FIXUP_HEADSET_MIC quirk resolves the issue and restores proper headset mic recording. Link: https://github.com/thesofproject/linux/issues/5729 Signed-off-by: Zhang Heng Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260807125857.678297-3-zhangheng@kylinos.cn Signed-off-by: Sasha Levin commit bb3502307a71d326c4d1464d5d758c8e9657aea5 Author: Junhao He Date: Wed May 27 16:27:07 2026 +0800 ACPI: APEI: Handle repeated SEA error storms [ Upstream commit e61487226b7df39e5f4683b036ee6aa7a5039d7b ] When hardware memory corruption occurs and a user process accesses the corrupted page, the CPU triggers a Synchronous External Abort (SEA). The kernel invokes do_sea() to handle the exception, which calls memory_failure() to handle the faulty page. Scenario 1: Memory Error Interrupt First, then SEA The page is already poisoned by the memory error interrupt path. The subsequent SEA handler sends a SIGBUS to the task, which accesses the poisoned page. This flow is correct. Scenario 2: SEA first, then memory error interrupt (problematic scenario) If a user task directly accesses corrupted memory through a PFNMAP-style mapping (e.g., devmem), the page may still be in the free-buddy state when SEA is handled. In this case, memory_failure() will poison the page without invoking kill_accessing_process(), and then takes the free-buddy recovery path. After the CPU returns to the task context, the task re-enters the SEA handler due to the same access. However, ghes_estatus_cached() suppresses all subsequent entries during the 10-second window, preventing ghes_do_proc() from being called. This suppression blocks the MF_ACTION_REQUIRED-based SIGBUS delivery, causing the kernel to fail to kill the task immediately. Consequently, the process keeps re-entering the SEA handler, leading to an SEA storm. Later, the memory error interrupt path also cannot kill the task, leaving the system stuck in this repeated loop. The following error logs are explained using the devmem process: NOTICE: SEA Handle [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9 [Hardware Error]: event severity: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: physical fault address: 0x0000001000093c00 [T54990] Memory failure: 0x1000093: recovery action for free buddy page: Recovered [ T9955] EDAC MC0: 1 UE Multi-bit ECC on unknown memory (page:0x1000093 offset:0xc00 grain:1 - APEI location: ...) NOTICE: SEA Handle NOTICE: SEA Handle ... ... ---> SEA storm ... NOTICE: SEA Handle [ T9955] Memory failure: 0x1000093: already hardware poisoned ghes_print_estatus: 1 callbacks suppressed [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9 [Hardware Error]: event severity: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: physical fault address: 0x0000001000093c00 [T54990] Memory failure: 0x1000093: already hardware poisoned [T54990] 0x1000093: Sending SIGBUS to devmem:54990 due to hardware memory corruption To resolve this, return an error when encountering the same SEA again. The subsequent SEA handler invocation uses arm64_notify_die() to send a SIGBUS signal to the task, which terminates the process and prevents it from re-entering the handler loop. Signed-off-by: Junhao He Reviewed-by: Wupeng Ma Reviewed-by: Shuai Xue Reviewed-by: Tony Luck Link: https://patch.msgid.link/20260527082707.2013499-1-hejunhao3@h-partners.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 9bf8e55664306a8aed56352b76ae3c5322cd33f6 Author: Aurabindo Pillai Date: Wed Jul 22 14:44:37 2026 -0400 drm/amd: Add DCN6 register headers [ Upstream commit fe219bd7d9783a6cb9249bc333546cb58d2c2723 ] Add new headers for: - dcn 6.0.0 - dpcs 6.0.0 - mmhub 5.0.1 Signed-off-by: Aurabindo Pillai Signed-off-by: Roman Li Reviewed-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d9ce845629cfb4a56a72cfaa29ee702bc6588388 Author: Filipe Manana Date: Fri Jun 12 12:02:14 2026 +0100 btrfs: fix memory barrier order in reloc_root_is_dead() [ Upstream commit 6f1c97695a6e230ee15c9e052e1933bdccfd5fa3 ] When we set a root's reloc_root to NULL, we do it like this: static void clear_reloc_root(struct btrfs_root *root) { root->reloc_root = NULL; /* * Need barrier to ensure clear_bit() only happens after * root->reloc_root = NULL. Pairs with have_reloc_root(). */ smp_wmb(); clear_bit(BTRFS_ROOT_DEAD_RELOC_TREE, &root->state); } So that a NULL reloc_root is always seen before seeing that the bit BTRFS_ROOT_DEAD_RELOC_TREE was cleared. But on the read side we have: static bool reloc_root_is_dead(const struct btrfs_root *root) { smp_rmb(); if (test_bit(BTRFS_ROOT_DEAD_RELOC_TREE, &root->state)) return true; return false; } And then callers of reloc_root_is_dead() access root->reloc_root. Because the read memory barrier is placed before testing the bit, the CPU is completely free to speculatively reorder those two loads. It can read root->reloc_root before it actually checks the dead tree bit. Sashiko reported this as an existing problem in another patch review, see the link in the Link tag below. Fix this by moving the read memory barrier to happen after testing the bit and update the comment to reflect current reality. Link: https://sashiko.dev/#/patchset/cf84f1a217c719e25b6b69e4298dd7afd36c9427.1781194426.git.fdmanana%40suse.com Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ada5c75dd93ffd9716ef1ef60d505bee90114a7d Author: Li Qiang Date: Thu Jul 16 16:47:28 2026 +0800 Bluetooth: bfusb: validate received block boundaries [ Upstream commit 6afadcff79b157a4770c4e987a6005bff40a670b ] The USB receive path trusts the block header to contain the required number of bytes and passes it to the reassembly routine. The routine also trusts a malformed HCI packet type and can append more data than the skb allocated from the advertised packet length. A malformed USB transfer can therefore cause out-of-bounds reads or an skb tail overwrite. Validate block header availability, declared block size, packet type, and reassembly tailroom. Drop the partial frame on an invalid block. Signed-off-by: Li Qiang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ef01d3ea451a84a640543caf76bb9860b8520e41 Author: Zhao Dongdong Date: Fri May 15 08:46:07 2026 +0800 Bluetooth: btnxpuart: Fix use-after-free in probe error path [ Upstream commit a2b3b4f00403a3a40c5627d1bf537c8fb166e221 ] In nxp_serdev_probe(), if hci_register_dev() succeeds but ps_setup() fails, the error path jumps to 'probe_fail' which only calls hci_free_dev() and asserts the reset GPIO, but does NOT call hci_unregister_dev() first. This leaves the HCI device registered in the system with its backing memory freed, leading to a use-after-free when userspace subsequently accesses the device (e.g. via hciconfig or bluetoothd). Fix by adding a 'probe_fail_unregister' label that calls hci_unregister_dev() before falling through to the existing 'probe_fail' label. The original 'probe_fail' label is preserved for the case where hci_register_dev() itself fails (device was never registered, so no unregister is needed). Signed-off-by: Zhao Dongdong Reviewed-by: Neeraj Sanjay Kale Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3e4e7a9907a16db636a0c88fd157e9422f8060e2 Author: Pengpeng Hou Date: Mon Jul 6 17:17:01 2026 +0800 Bluetooth: hci_nokia: validate firmware packet bounds [ Upstream commit 45640627e3ddc5f4d3a0d08618a596a8c65d48a5 ] nokia_setup_fw() walks a length-prefixed firmware stream and decodes HCI command packets from each record. Check that each record fits in the remaining firmware image, that command records contain the HCI command header, and that the payload length is covered before submitting the command. Signed-off-by: Pengpeng Hou Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8a184070477c5a71185cb7edd739612be9a4be28 Author: Pavel Zverev Date: Wed Jul 8 01:15:49 2026 +0300 Bluetooth: btusb: Add support for 1357:c123 Realtek 8852BE device [ Upstream commit 335d7bd554a20f33acf762655cafe1089f7f5822 ] Wiko Hi MateBook 14 Ryzen 200 laptops (DMI system-product-name "MNCA-XX", board "M1060") are equipped with an RTL8852BE Wi-Fi/BT combo chip (rtw89_8852be), whose Bluetooth radio enumerates as 1357:c123 instead of one of the already-supported 1358:c123 / 0bda:c123 identifiers, presumably due to OEM rebranding. Without a matching entry it only matches the generic USB Bluetooth class fallback, so the Realtek firmware/config (rtl8852btu_fw.bin / rtl8852btu_config.bin) is never loaded and the adapter cannot discover or connect to any device, even though hciconfig reports it as powered and scanning. Device descriptor: idVendor 0x1357 idProduct 0xc123 bcdDevice 0.00 iManufacturer 1 Realtek iProduct 2 Bluetooth Radio bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth Adding the same BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH quirk already used for 1358:c123 and 0bda:c123 fixes firmware loading and normal operation. Signed-off-by: Pavel Zverev Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f8b6ea70abc0560d09b33e42e52ca752734ae6d0 Author: Gustavo Evgucci Date: Thu Jun 25 11:32:30 2026 +0300 Bluetooth: btusb: Add USB ID 13d3:3625 for MediaTek MT7922 [ Upstream commit 849a3bf1489093996859ba0c3c1c0cd314d6ff96 ] The IMC Networks MT7922 Bluetooth adapter with USB ID 13d3:3625 is not recognized as a MediaTek device because it is missing from the btusb device ID table. As a result, btmtk firmware loading is never triggered and the HCI reset command times out with -ETIMEDOUT. Add the device with BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH flags, consistent with the neighboring 13d3:3627, 13d3:3628 and 13d3:3630 entries which use the same chip. Tested on: MediaTek MT7922 (Wi-Fi 6E combo card, IMC Networks BT USB interface), kernel 7.0.11-arch1-1. /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=12 Cnt=03 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3625 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Gustavo Evgucci Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 147d899c7b988501681193393489de8c9b3dadfd Author: Rui Qi Date: Fri Aug 7 16:15:11 2026 +0800 selftests/ftrace: Force C locale in ftracetest [ Upstream commit c13fcd3951dcc19524ce0b3e852844b16cd32b22 ] Some ftracetest test cases parse command output by matching English field names. Tools such as readelf may localize their output via gettext, while ftracetest currently inherits the user locale from the environment. If a translated field name is printed, parsing can fail even though the tested kernel behavior is unchanged. For example, add_remove_uprobe can fail to find the ELF entry point and then write a uprobe event with a missing offset. Export LC_ALL=C in the top-level ftracetest runner so every test case gets stable command output by default. Link: https://lore.kernel.org/all/20260807081512.2974757-2-qirui.001@bytedance.com/ Signed-off-by: Rui Qi Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 7f8a0b02651399002cddb96fef698ebb52442a2d Author: Andreas Haufler Date: Tue Jul 21 10:32:13 2026 +0200 tools/lib/thermal: Fix misplaced extern "C" closing brace [ Upstream commit cb0ec27efac2aaf92393ad563a35fb6f00d0a6cd ] The public libthermal header opens the C++ 'extern "C" {' block inside the __LIBTHERMAL_H include guard, but places the closing brace after the guard has already ended: #endif /* __LIBTHERMAL_H */ #ifdef __cplusplus } #endif On a single inclusion the braces still balance, so the problem is invisible. On the second inclusion of the header in the same C++ translation unit the include guard skips the opening 'extern "C" {', while the closing '}' lives outside the guard and is emitted anyway. This leaves a stray '}' and breaks compilation for any C++ consumer that includes the header more than once. Move the closing block inside the include guard so both halves of the 'extern "C"' declaration are guarded consistently. Signed-off-by: Andreas Haufler Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260721083230.91246-1-andreas@haufler.info Signed-off-by: Sasha Levin commit 7419a8dfa09f0b7af0f4c6e7497e4ed85860d106 Author: Yunye Zhao Date: Thu Jul 23 21:55:34 2026 +0800 md: add cond_resched() to md_do_sync()'s skip path [ Upstream commit 162eb5ba791f6260fdaabae75fa2df20134f67d8 ] When sync_request() reports a skipped region (*skipped == 1), md_do_sync()'s main loop advances the cursor and takes an early continue: j += sectors; ... if (last_check + window > io_sectors || j == max_sectors) continue; If the personality returns a small span per call (raid10 recovery returns only 128 sectors), syncing a large, mostly clean array iterates this branch an enormous number of times without ever yielding the CPU. On a non-preemptive kernel the resync thread then trips the soft-lockup watchdog: watchdog: BUG: soft lockup - CPU#149 stuck for 313s! [mdX_resync] md_bitmap_start_sync+0x6f/0xe0 raid10_sync_request+0x2c9/0x1530 [raid10] md_do_sync+0x810/0x1030 md_thread+0xa7/0x150 Add a cond_resched(). This does not reduce the wasted iterations; the excessive iteration count is a raid10 problem addressed separately. Signed-off-by: Yunye Zhao Link: https://patch.msgid.link/20260723135535.101995-3-yunye.zhao@linux.alibaba.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 2c2a8cf8dd4b219f1974bca4149c3a0cbea126a8 Author: Yu Kuai Date: Mon Aug 3 03:50:19 2026 +0800 md: skip bitmap accounting for empty write ranges [ Upstream commit 87c10252e3d6c28769d93bea9e6a9b592e5809d1 ] mkfs.ext4 can submit zero-sector flush/FUA bios. These bios are WRITE bios for md_write_start() purposes, but they do not cover any data sector and must not dirty bitmap bits. md bitmap accounting currently passes such bios to bitmap start_write(). For llbitmap this reaches llbitmap_start_write() with sectors == 0, which underflows the end chunk calculation. Personality bitmap mapping can also turn a non-empty bio into an empty bitmap range when the requested sectors are outside the active bitmap geometry. Treat both cases as not started, so the completion path will not call end_write() for an empty range. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-11-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit ae07a0c3554473cc9f58d15c7157539129632ab2 Author: Yu Kuai Date: Mon Aug 3 03:50:13 2026 +0800 md/raid5: reject zero-sector reshape chunks [ Upstream commit a41bb2ee1aca486853e84920565e50c15f86fa5d ] Sashiko reported that RAID5 can accept a reshape chunk size that becomes zero sectors. chunk_size_store() stores the sysfs byte value as n >> 9, so writing a value below 512 bytes sets mddev->new_chunk_sectors to zero. RAID5 then accepted that pending reshape geometry and raid5_start_reshape() installed it into conf->chunk_sectors, letting reshape code divide by zero. Reject zero-sector chunks both in check_reshape(), where normal sysfs requests are validated, and in raid5_start_reshape(), so assembly/resume paths also cannot install zero chunk geometry. Test script: in QEMU, create a plain three-disk RAID5 array with 64K chunks, write/read back a small pattern, write 1 to /sys/block/md0/md/chunk_size, add a fourth disk, and run mdadm --grow --raid-devices=4 --backup-file=... . The script scans dmesg for divide error/Oops/KASAN signatures. Bad kernel, eb29914412c3: echo 1 > /sys/block/md0/md/chunk_size mdadm --grow /dev/md0 --raid-devices=4 --backup-file=/root/md0-grow.bak Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: raid5_get_active_stripe+0x863/0xc10 Call Trace: raid5_sync_request md_do_sync md_thread Kernel panic - not syncing: Fatal exception Fixed kernel: echo 1 > /sys/block/md0/md/chunk_size bash: echo: write error: Invalid argument chunk_write_rc=1 grow_rc=skipped RESULT: REJECTED_ZERO_CHUNK_NO_OOPS Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-5-yukuai@kernel.org Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 2f7ad98de370d702e3b48aaae434596369a364f6 Author: Shang En Sim Date: Thu Aug 6 22:51:27 2026 -0700 ALSA: hda/realtek: Enable mute LEDs on HP Spectre x360 16-aa0xxx [ Upstream commit bfcdc1c0eaeae5525c726193568e8d638b2afdc0 ] The HP Spectre x360 2-in-1 Laptop 16-aa0xxx with PCI subsystem ID 0x103c:0x8c17 only gets the CS35L41 amplifier setup from ALC287_FIXUP_CS35L41_I2C_2, so the speaker-mute and mic-mute keyboard LEDs do not work. Use ALC245_FIXUP_HP_SPECTRE_X360_16_AA0XXX like subsystem ID 0x8c16 so the mute LEDs work. Tested on HP Spectre x360 2-in-1 Laptop 16-aa0xxx. Signed-off-by: Shang En Sim Link: https://patch.msgid.link/20260807055139.58707-1-sim@shangen.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bb8625b38c5c1925df1db3b297c8c52481d1c23d Author: Junzhe Yu Date: Tue Aug 4 12:55:33 2026 +0800 ext4: guard against NULL s_group_info in ext4_get_group_info [ Upstream commit 8f3901fbb40745046e513226ad84e8b84492632d ] Resend: previous attempt was rejected by vger for containing HTML. ================================================================== ext4_mark_group_bitmap_corrupted() already treats a NULL return from ext4_get_group_info() as "nothing to do", but ext4_get_group_info() indexes s_group_info without checking whether the array exists. During mount, fast-commit replay runs inside jbd2_journal_load() from ext4_load_and_init_journal(), which is before ext4_mb_init() allocates s_group_info. Replaying an FC UNLINK for an inode whose bitmap bit is already clear takes:   ext4_fc_replay_unlink -> iput -> ext4_evict_inode -> ext4_free_inode     -> ext4_mark_group_bitmap_corrupted -> ext4_get_group_info and faults on the NULL s_group_info base. Userspace only mounts a dirty ext4 image; this is a supported recovery path. Return NULL when s_group_info (or the per-block grp_info row) is unset so the existing caller check is effective during early mount. Tested on Linux v6.6.145 KASAN: crafted FC-unlink image previously triggered KASAN null-ptr-deref / panic in ext4_get_group_info; with this patch, mount succeeds (EXT4 "bit already cleared" may still log). Also observed on v6.6.144; still present on torvalds/linux as of f5098b6bae76 (2026-07-26). A self-contained Docker/QEMU reproducer (craft + mount + patch verify) is available on request. Signed-off-by: Yu Junzhe Link: https://patch.msgid.link/65c955b0-716b-4599-b925-59c2782e38b4@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 28332e8aae84ac2717f0fece9ccd3e608c0e5b64 Author: Pengpeng Hou Date: Tue Jun 30 14:52:45 2026 +0800 HID: rmi: check report length before trimming sentinel bytes [ Upstream commit 28a3e326fad2451bdb66b747dd1f7ccbb900eed6 ] rmi_check_sanity() trims trailing 0xff sentinel bytes, but its loop reads data[valid_size - 1] before checking that valid_size is non-zero. Reverse the condition so the length is proved before the last byte is inspected. Signed-off-by: Pengpeng Hou Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit db1e5bd4ee8efe8d8f294576d20e13b9d435a6f7 Author: Yang Wang Date: Thu Jul 30 09:50:40 2026 +0800 drm/amd/pm: derive stable PPT limits from PPTable [ Upstream commit 25f4a46b0c8acd77c9065b50a1fe48af27d91fdf ] GetPptLimit reports mutable PMFW runtime state. Using that value for static capabilities causes two externally visible problems: - A userspace override changes the default reported through hwmon. - A firmware reset changes the advertised minimum or maximum range. Derive platform defaults and supported ranges from the driver PPTable for Sienna Cichlid, Navi10, Arcturus, and Aldebaran. Reserve PMFW queries for the effective current limit. Runtime policy can no longer redefine immutable platform capabilities. Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b6d0b00a296366319cb8d447b630f395a9189f92 Author: liulhong617 Date: Wed May 13 09:02:55 2026 +0800 arm64: mm: fix accidental linear mapping of no-map reserved memory [ Upstream commit 7ace06a01efaba1ec585630aa4c98ac39b38452a ] When reserved-memory regions with the "no-map" property are not page-aligned, the kernel may accidentally map them into the linear mapping, contradicting the no-map semantics. The root cause is a mismatch between /proc/iomem's address boundaries and the actual page table mapping boundaries: 1. /proc/iomem derives its ranges from memblock via memblock_region_reserved_base_pfn/memblock_region_reserved_end_pfn, which perform PFN rounding so the displayed boundaries are page-aligned. This gives the impression that the no-map region occupies whole pages. 2. However, memblock_mark_nomap() splits memblock.memory regions at exact byte boundaries (memblock_isolate_range preserves raw DT base/size with no alignment). When for_each_mem_range iterates the non-NOMAP regions adjacent to a no-map region, it returns start/end values that are NOT page-aligned — they are the precise byte boundaries from the memblock split. 3. These sub-page-aligned values are passed to __create_pgd_mapping_locked(), which does: phys &= PAGE_MASK; addr = virt & PAGE_MASK; end = PAGE_ALIGN(virt + size); The downward rounding of phys via PAGE_MASK extends the mapped range backward into the adjacent no-map region, effectively including no-map memory in the linear mapping. For example, with 64K pages, reserved_region@A2000000 (base=0xA2000000, size=0x8000, no-map) causes for_each_mem_range to return start=0xA2008000 for the next mappable region. After phys &= PAGE_MASK, the actual mapping starts at 0xA2000000 — the entire no-map region is incorrectly mapped. Fix this by rounding the mappable range inward to PAGE_SIZE boundaries before passing it to __map_memblock: start is rounded UP and end is rounded DOWN. This ensures the mapped area never overlaps with adjacent no-map regions. The cost is at most one page of unmapped gap at each boundary, which is preferable to violating no-map semantics. Signed-off-by: liulhong617 Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit dab4eb4a21353ed64c7e9fae638e5a25f3e3f0c2 Author: Stefan Hansson Date: Tue Aug 4 10:55:41 2026 +0200 wifi: rsi: Fix types to appease CFI [ Upstream commit da308f6e471252ae5e8009dcea16bc5e9c9dc5dd ] Avoids errors like: CFI failure at kthread+0x124/0x1cc (target: rsi_coex_scheduler_thread+0x0/0x1b4 [redpine_91x]; expected type: 0x89fb613d) As seen in the aforementioned error this was tested using the downstream redpine_91x driver found in the Librem 5's downstream source tree. However, it appears that this driver is a modified version of the rsi driver found in mainline Linux and as such I decided to port the changes here too. Signed-off-by: Stefan Hansson Link: https://patch.msgid.link/20260804-rsi-cfi-fix-v2-1-59679a520240@postmarketos.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 31b92853b9b306715700acffc7d79082cd985214 Author: Charles Keepax Date: Mon Jul 20 10:57:41 2026 +0100 soundwire: dmi-quirks: Disable ghost Realtek on Asus Zenbook Duo [ Upstream commit ca02ffd4975ca5249abf0cfb750a495d23b453ee ] The Asus Zenbook Duo also has a Realtek device in the ACPI that doesn't exist in the physical hardware. This confuses the machine driver into attempting to create DAI links for the device. Add a quirk to remove this device. Signed-off-by: Charles Keepax Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260720095741.3592825-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit de8256a63ba2230c4dd33bb37a4945faebe12c1d Author: Praveen Talari Date: Mon Jul 27 22:33:12 2026 +0530 opp: Use clk_get_optional() to avoid leaving opp_table->clk as an error pointer [ Upstream commit 84f05af0975c9f9c8ffee0361d6f7cbb1f289231 ] _update_opp_table_clk() uses clk_get(dev, NULL) to acquire the device's clock. On platforms where the perf domain device has no Linux clock and is instead managed entirely by firmware via devm_pm_opp_of_add_table() (through of_genpd_add_provider_simple()/onecell()), clk_get() returns -ENOENT. That case is treated as valid (the OPP table can still have entries sourced from firmware), but opp_table->clk is left holding ERR_PTR(-ENOENT) rather than being reset to NULL: opp_table->clk = clk_get(dev, NULL); ret = PTR_ERR_OR_ZERO(opp_table->clk); ... if (ret == -ENOENT) { opp_table->clk_count = 1; return opp_table; /* opp_table->clk is still ERR_PTR(-ENOENT) */ } Consumers that only check IS_ERR(opp_table->clk) treat this as a valid clk and pass it straight into the clk consumer API. In particular, dev_pm_opp_set_rate() calls clk_round_rate(opp_table->clk, target_freq), and clk_round_rate() only guards against a NULL clk, so it dereferences the error pointer to read clk->exclusive_count and crashes: Unable to handle kernel NULL pointer dereference at virtual address 000000000000002e ... pc : clk_round_rate+0x3c/0x188 ... Call trace: clk_round_rate+0x3c/0x188 (P) dev_pm_opp_set_rate+0x114/0x33c Rather than teaching every clk consumer API to special-case ERR_PTR(-ENOENT), fix it at the source: use clk_get_optional() instead of clk_get() in _update_opp_table_clk(), which already translates -ENOENT into a NULL clk. This documents that the clock is genuinely optional for such devices, and keeps opp_table->clk holding either a valid clk or NULL, never a lingering -ENOENT error pointer. _opp_config_clk_single() is only wired up via opp_table->config_clks when a clk was actually found, and every other opp_table->clk consumer already tolerates NULL through the standard clk API (which treats a NULL clk as a no-op), so no other call site needs to change. Suggested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel Signed-off-by: Praveen Talari Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit a5da12211b986eab4e88f02577a313ea53a8e5eb Author: Edson Juliano Drosdeck Date: Wed Aug 5 12:45:18 2026 -0300 ALSA: hda/realtek: Limit mic boost on Positivo N15RPE-S [ Upstream commit 253010acfc8ad908446347b30a613032d1517bb5 ] The internal mic boost on the Positivo N15RPE-S is too high. Fix this by applying the ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine to limit the gain. Signed-off-by: Edson Juliano Drosdeck Link: https://patch.msgid.link/20260805154518.19093-1-edson.drosdeck@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bc32b9880d1b7375f65cae6ab4818187121d3a81 Author: Carl Quist Date: Thu Aug 6 11:47:18 2026 +0200 ALSA: hda/realtek: Enable mute LED on HP Laptop 15-dy0xxx [ Upstream commit eb2b516900f2cff6c931a0d664a625ee93855779 ] The mute LED on the HP Laptop 15-dy0xxx (PCI SSID 103c:864f, Realtek ALC236) does not work, because the machine has no entry in the quirk table. No fixup is applied, so no mute LED classdev is registered and nothing ever drives the LED. The LED is controlled by COEF index 0x07, bit 0. This was verified on the hardware with hda-verb: setting the bit lights the mute LED and clearing it turns the LED off. hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x07 hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x1 # LED on hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x200 # LED off That is exactly what ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 configures, and the closely related HP Laptop 15-dw0xxx (103c:85f0) already uses it. Bit 9 (0x200) is set by default on this board and is preserved by the fixup's read-modify-write. Tested on an HP Laptop 15-dy0xxx (SKU 7FU54UA#ABA, board 864F, BIOS F.40). Signed-off-by: Carl Quist Link: https://lore.kernel.org/CAOtcGaxXndKxTK5MVSEcmF-LUy+V51K7fhE=qvLA+VvW5ZyCNA@mail.gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ee78a5c533afbe70d5a2160870742d7891a2ec86 Author: Zihan Xi Date: Fri Jul 31 16:46:23 2026 +0000 xsk: account ring allocations to memcg [ Upstream commit b0057c68df711bf6a62033c072ac61c4f9d3cbc1 ] AF_XDP rings are allocated from setsockopt() and can be mapped into user space. The shared xskq_create() helper allocates the ring backing memory, but the user-controlled and long-lived allocation is not charged as kmem to the allocating memory cgroup. The current implementation uses vmalloc_user(), which allocates the backing pages with GFP_KERNEL | __GFP_ZERO. Use the same VM_USERMAP vmalloc path, but pass GFP_KERNEL_ACCOUNT so the ring backing pages are attributed to memcg/kmem and can be constrained by existing cgroup memory limits. This keeps the existing zeroing and mmap semantics while avoiding AF_XDP-specific optmem or RLIMIT_MEMLOCK accounting. Signed-off-by: Zihan Xi Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20260731164623.4694-2-zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 24dd15e91fa6c66382e49baa7a9c2a064969496c Author: Jinhui Guo Date: Thu Jul 30 13:13:41 2026 +0800 net: usb: cdc_ether: add quirk for AMI BMC stale link events [ Upstream commit 089ca284afb0f3b2870a5ce41524cbc91ed350d4 ] On AMD Genoa/Turin platforms the BMC-provided USB-Ethernet gadget (American Megatrends, VID 0x046b PID 0xffb0) intermittently fails to respond to ARP after AC cold boot. usbmon captures a stale NETWORK_CONNECTION(off) immediately followed by NETWORK_CONNECTION(on) on the interrupt endpoint (~130us apart) after enumeration. Because alloc_netdev() leaves __LINK_STATE_NOCARRIER cleared, netif_carrier_ok() returns true when the spurious OFF arrives, so usbnet_cdc_status() cannot recognise it as redundant and schedules EVENT_LINK_CHANGE. __handle_link_change() then calls unlink_urbs(), killing ~60 rx URBs whose payload has already been DMA'd into memory — xHCI trace confirms them completing as -ECONNRESET with non-zero residual length. rx_complete() drops these unconditionally. The following ON restores the carrier and re-submits URBs, but the ARP reply is already lost; the interface looks "up but silent" until ifdown/ifup. Fix this by adding a device-specific quirk with FLAG_LINK_INTR set, which makes usbnet_probe() call netif_carrier_off() after bind. With initial carrier == OFF, usbnet_cdc_status() recognises the spurious OFF as matching the current state and drops it; the subsequent ON is the first real event and brings the link up cleanly without ever tearing down the rx queue. The scheduled link-change kevent is harmless because EVENT_DEV_OPEN is not yet set at probe time. This is applied as a device-specific quirk rather than a change to the shared cdc_info driver_info because some CDC devices never send NETWORK_CONNECTION notifications; forcing carrier off for them would leave the link permanently DOWN. Restricting the change to this VID/PID keeps that class of device untouched. Tested on Genoa and Turin across 100+ AC cold boot cycles; ping first-packet success rate went from intermittent to 100%. Signed-off-by: Jinhui Guo Link: https://patch.msgid.link/20260730051341.24930-1-guojinhui.liam@bytedance.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3b34ca885168c6be5a1bc4244c18c37f504a8ab3 Author: Johan Alvarado Date: Fri Jul 31 14:45:22 2026 -0500 net: stmmac: raise TX completion interrupt at the end of an xmit burst [ Upstream commit d21a374995df9d7cfd193427748a19dcc87956a9 ] The TX mitigation logic only sets the Interrupt on Completion bit once every tx_coal_frames descriptors (STMMAC_TX_FRAMES = 25), with the tx_coal_timer hrtimer (STMMAC_COAL_TX_TIMER = 5000 us) as the only fallback. TX skbs are freed exclusively from the TX completion path, so any flow that keeps fewer than 25 frames in flight has all of its skbs held for up to 5 ms after transmission. Paced flows never queue enough frames to reach the frame threshold: TCP Small Queues caps the amount of unfreed data at roughly two pacing intervals worth, which at moderate pacing rates is only a couple of packets. Every small burst then stalls until the coalesce timer fires, and throughput collapses to approximately tsq_limit / tx_coal_timer regardless of link capacity. This is easily reproducible with BBR, which paces its output and thus keeps only a few frames in flight at a time. On a YT6801 (dwmac-motorcomm) equipped Orange Pi 5 Pro, a BBR upload over a ~23 ms RTT path is capped at 5.24 Mbit/s, while CUBIC reaches 207 Mbit/s on the same path. BBR measures the stalled send rate as the path bandwidth and locks its estimate near the floor, so the connection never recovers. Lowering the coalesce settings with ethtool -C (tx-usecs 100 tx-frames 1) lifts the same transfer to 447 Mbit/s, confirming the mechanism. Fix this by setting the IC bit on the last descriptor of every xmit burst, i.e. whenever netdev_xmit_more() reports that no further frames are pending in the current dequeue batch. Frame-based coalescing still applies within a burst, bulk traffic keeps batching through qdisc bulk dequeue and NAPI polling, and the coalesce timer becomes a pure fallback instead of the primary completion mechanism for lightly queued flows. tx-frames 0 keeps its meaning of timer-based mitigation only. Signed-off-by: Johan Alvarado Link: https://patch.msgid.link/20260731194522.55069-1-contact@c127.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eb5702c3a407cbb0956ff11940a52d0113b13ed7 Author: Felix Fietkau Date: Sat Aug 1 14:53:32 2026 +0000 wifi: mt76: mt7603: file buffered frames under the TID reported to mac80211 [ Upstream commit 0bbd6c52dfff62b319963f54cd9370f9486e59d2 ] The PS queue filed redirected frames under the TID taken from the TXD, while mac80211 was told about the TID taken from the QoS header, or TID 0 for anything that is not a QoS data frame. When the two disagree, mt7603_release_buffered_frames() skips the frame because it does not match the requested TIDs, so it stays in the PS queue until the station wakes up. Buffered MMPDUs hit this whenever they were sent on a non-zero TID. Use one TID for both. Link: https://patch.msgid.link/20260801145334.1166751-8-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f02d25d753df9dd39618177c7c0cfbcf97d24252 Author: Marcos Paulo Medeiros Date: Mon Jul 27 10:21:51 2026 -0300 ACPI: video: force native backlight on Acer Nitro AN515-46 [ Upstream commit 525ba51157ac6e1772b5412eae26b20dd7ef8bda ] The Acer Nitro AN515-46 is a hybrid graphics laptop whose internal panel is driven by the AMD GPU (Radeon 680M); the discrete NVIDIA GPU only drives external outputs. The firmware nevertheless advertises the NVIDIA WMI EC backlight GUID, so the backlight type resolves to nvidia_wmi_ec. The nvidia-wmi-ec-backlight driver however fails to probe ("EC backlight control failed: AE_NOT_FOUND") and, since the backlight type is still nvidia_wmi_ec, amdgpu skips registering its own backlight device. The result is no backlight device at all, leaving the brightness keys and the desktop brightness slider non-functional. Booting with acpi_backlight=native makes amdgpu register its backlight interface and brightness control works. Add a DMI quirk to use the native backlight on this model by default. Signed-off-by: Marcos Paulo Medeiros Link: https://patch.msgid.link/20260727132151.12792-1-maarcospm1996@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 795698c7f08f4aa2c77ffa57d4b156f9884aae71 Author: Luca Castaldini Date: Wed Aug 5 14:29:07 2026 +0200 ALSA: hda/realtek: Add mute LED support for HP Pavilion 15-eh2xxx [ Upstream commit daf55a381dca9bda12cc8c3a47605698f2d560e9 ] Add the subsystem ID 103c:8a0e to the ALC287 HP GPIO LED quirk table so the mute LED follows the speaker mute state. Tested on HP Pavilion Laptop 15-eh2xxx with ALC287 codec. The mute LED now follows the speaker mute state. Signed-off-by: Luca Castaldini Link: https://patch.msgid.link/20260805122907.52302-1-luca.castaldini96@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit de4d87d5b5ab3e8031eb81b1f291a038e549998e Author: Stefan Haberland Date: Wed Aug 5 13:15:57 2026 +0200 s390/dasd: Snapshot intrc before freeing the request block [ Upstream commit dc3e3f7306cb74066f231251602b1be5aaec7bd8 ] __dasd_cleanup_cqr() maps the completion result to a block status by reading cqr->intrc, but only after discipline->free_cp() has returned the request block to its memory pool (dasd_eckd_free_cp() ends in dasd_sfree_request()). On SMP another CPU can reallocate that block and overwrite cqr->intrc before it is read, completing the request with the wrong error. proc_bytes is already snapshotted before free_cp() for the same reason; do the same for intrc. Reviewed-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260805111612.1285190-5-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f302c2ce5e78d1ba5ddc9592d4e1a5ea018ac97d Author: Simon Glass Date: Tue Jul 14 07:35:42 2026 -0600 kconfig: abort rather than loop for ever on EOF [ Upstream commit f915149f5cfbd0d4406ec0b0f57b1d2c8685ae55 ] When a non-interactive 'make oldconfig' or 'syncconfig' meets a new int or hex symbol whose default cannot be applied, conf_string() reads a value from stdin. At end of file fgets() returns NULL, no value is set and the loop asks again. The result is an endless loop which fills the output until it exhausts memory, rather than a clean failure. Detect this in conf_string(): if the value cannot be set and stdin is at end of file, stop with an error that names the symbol. Note that a symbol with no default doesn't trigger this, since sym_calc_value() falls back to 0, which is accepted at end of file. The loop is triggered by a broken Kconfig file, with a default whose text fails sym_string_valid(). Such mistakes do creep in from time to time and are hard to debug, since the build fills the log with repeated prompts instead of pointing at the offending symbol. Some bad defaults draw a parse-time warning, but menu_validate_number() accepts a reference to any int or hex symbol, so a cross-type reference loops with no warning at all. For example, "0xff" is not a valid int value: config HEXSYM hex default 0xff config VAL int "Value" default HEXSYM Interactive use is unaffected, since feof() only becomes true once a read actually hits end of file: an invalid answer at a terminal still re-prompts, while Ctrl-D at such a prompt exits with the error instead of looping. bool and tristate symbols and choices already accept the default on an empty line, so they still take their defaults in a non-interactive build. Tested with int and hex symbols carrying such defaults: with empty stdin, the code without this change produces around 190MB of repeated prompts within two seconds, while with the change it exits 1 naming the symbol. Piped and interactive (pty) sessions still re-prompt on an invalid answer and then accept a valid one. A new string symbol with no default still takes the empty string at end of file, since any text is valid for a string. Signed-off-by: Simon Glass Link: https://patch.msgid.link/20260714133545.3294648-1-sjg@chromium.org Signed-off-by: Nicolas Schier Signed-off-by: Sasha Levin commit 2c4825a78bf444df92a5e608a5beda864e9c09a9 Author: Allison Henderson Date: Wed Jul 29 21:16:29 2026 -0700 net/rds: unpin MR pages with unpin_user_pages_dirty_lock() [ Upstream commit a507023e6ff1d0b4e7aac49b2f547fed0c21ea4e ] The pages backing an RDS memory region are pinned in __rds_rdma_map() with rds_pin_pages(), which uses pin_user_pages_fast(): each page's refcount is biased by GUP_PIN_COUNTING_BIAS to account the pin. The scatterlist is then handed to the IB transport, and the transport releases the pages in __rds_ib_teardown_mr() with set_page_dirty(page); put_page(page); put_page() drops a single reference instead of removing the pin bias, so every MR teardown permanently strands the remaining references and the pages are never freed - a userspace-triggerable memory leak of up to RDS_MAX_MSG_SIZE per RDS_GET_MR/RDS_GET_MR_FOR_DEST call. The conversion to the pin API updated the unpin sites in rdma.c but missed this one on the transport side. Release the pages with unpin_user_pages_dirty_lock(), which removes the pin bias and also dirties the page under the folio lock, closing the truncation race that a bare set_page_dirty() leaves open. Dirtying under the folio lock can sleep, which is safe in every path that reaches __rds_ib_teardown_mr(): the registration-reuse path (rds_ib_map_frmr()) runs in syscall context, and the pool flush (rds_ib_unreg_frmr()) runs under pool->flush_lock, a mutex, and already sleeps in rds_ib_post_inv(). The WARN_ON that guarded the old irq-context set_page_dirty() case is dropped along with it. Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260730041629.3512480-5-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3ae57d5de9155635c4a2c9637b7b7c34d22238f1 Author: Sharath Srinivasan Date: Wed Jul 29 21:16:28 2026 -0700 net/rds: fix rds_message leak in the rds_send_xmit() drop path [ Upstream commit eb8a59a17f4a8b6f2afb4a8063e99dd96cc3fab0 ] When rds_send_xmit() picks the next message off cp_send_queue it takes its own reference with rds_message_addref(). If the message then hits the never-retransmit check (RDS_MSG_FLUSH, or an RDMA op that was already retransmitted), it is moved to the local to_be_dropped list and that reference is dropped after the batch. However, if RDS_MSG_ON_CONN has already been cleared, the message is not added to to_be_dropped and the reference taken above is never dropped: cp_xmit_rm has not been set at this point, so the loop simply abandons rm and the rds_message (and everything it pins: pages, MRs, notifiers) leaks after an RDMA error. The only other places that clear RDS_MSG_ON_CONN are rds_send_path_drop_acked() and rds_send_drop_to(), and both can run while rds_send_xmit() has dropped cp_lock between moving the message to cp_retrans and re-taking the lock in the never-retransmit check: rds_send_path_drop_acked() can ack away a message that already sat on cp_retrans - the RDS_MSG_RETRANSMITTED case above - and rds_send_drop_to() runs on socket close. Both unlink the message under cp_lock and put their own reference, leaving the xmit-path reference stranded. Drop the reference directly in that case. This mirrors Oracle UEK commit "net/rds: fix rds_message memleak in rds_send_xmit". Signed-off-by: Gerd Rausch Signed-off-by: Sharath Srinivasan [achender: port to net-next; update commit message, checkpatch nits] Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260730041629.3512480-4-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d27f95e1d8e1d6abc30d2baf1d7c501d9cadaf87 Author: Håkon Bugge Date: Wed Jul 29 21:16:27 2026 -0700 net/rds: hold the socket while an rds_mr references it [ Upstream commit 9079adef042c1e7a6141dcdfd3041acd30607297 ] Each rds_mr stores a bare back pointer to the socket that created it (mr->r_sock) but takes no reference on it. When the mr is destroyed it references the rs. Hence, provisions must be made to avoid the rs being destroyed before all mrs referencing it have been destroyed. The MR itself is refcounted, and in-flight messages legitimately hold MR krefs that can outlive the socket: rds_release() drops the rb-tree references via rds_rdma_drop_keys(), but a send completion arriving afterwards drops the final message reference from the CQ handler and ends up in rds_message_purge() __rds_put_mr_final() rds_destroy_mr() -> takes rs->rs_rdma_lock dereferencing a socket that may already have been freed. Oracle UEK fixed the same use-after-free ("rds: Add proper refcnt when an RDS MR references an RDS Socket") after seeing crashes of the form: PF: supervisor write access in kernel mode _raw_spin_lock_irqsave+0x4a/0x6a __rds_put_mr_final+0x2c/0xe0 [rds] rds_message_purge+0x13c/0x150 [rds] rds_message_put+0x39/0x54 [rds] rds_ib_send_cqe_handler+0x147/0x3dd [rds_rdma] To fix this, take a socket reference when an MR is created and drop it when the final MR kref goes away. The reference cycle is broken by rds_release(), which always runs rds_rdma_drop_keys() on close. So the socket reference held by an MR never prevents release, it only delays sk_free() until the last MR user is done. The hold sits next to kref_init() at both allocation sites - __rds_rdma_map() and the on-demand-paging path in rds_cmsg_rdma_args() - so every MR owns exactly one socket reference from the moment it becomes kref-managed. For that to work on the ODP path, its get_mr() error handling is converted from a bare kfree() to kref_put(..., __rds_put_mr_final), with r_trans_private cleared first since it holds an ERR_PTR there; both sites then tear down through the same path and a future error-path change cannot silently leak or double-drop the reference. Signed-off-by: Håkon Bugge [achender: port to net-next (sock_hold/sock_put in place of the UEK rds_sock_addref/rds_sock_put helpers); also balance the reference on the rds_cmsg_rdma_args() ODP path and unify its error path with __rds_put_mr_final(); update commit message] Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260730041629.3512480-3-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6e016448a0dc0b39b23803beea441da7662bebea Author: Allison Henderson Date: Wed Jul 29 21:16:26 2026 -0700 net/rds: don't use unpin_user_pages_dirty_lock() from atomic context [ Upstream commit d100966325f782aa7775e5f0e8fb04f66f56308e ] rds_rdma_free_op() and rds_atomic_free_op() are reached from the IB send completion path via rds_ib_tasklet_fn_send() rds_ib_send_cqe_handler() rds_message_put() rds_message_purge() rds_rdma_free_op() / rds_atomic_free_op() which runs in tasklet (softirq) context. Both functions unpin the user pages of the op with unpin_user_pages_dirty_lock(), which uses set_page_dirty_lock() and thus may take the folio lock and sleep. Sleeping in softirq context is not allowed and can deadlock or crash. Dirtying the pages with the non-sleeping set_page_dirty() instead would just trade one bug for another, as pointed out during review: the pinned range can be file-backed. rds_pin_pages() pins with FOLL_LONGTERM, which refuses fs-dax but takes the page-cache pages of a MAP_SHARED file mapping just fine, and RDS does not restrict what memory the caller registers as an RDMA destination. For a file-backed page, set_page_dirty() from a tasklet can take non-irq-safe filesystem locks (e.g. mapping->i_private_lock and inode->i_lock in block_dirty_folio()) and deadlock against the task it interrupted. Without the folio lock, it races with truncation clearing folio->mapping, which is the race set_page_dirty_lock() exists to close. The pre-pin_user_pages() version of this code dirtied pages that way from the tasklet, so that bug is older than the sleeping unpin. The page dirtying therefore has to move to process context, not merely avoid the folio lock. When the final rds_message_put() runs in atomic context, rds_rdma_free_op() and rds_atomic_free_op() now leave the op's pages pinned and flag the op. Later, rds_message_put() hands the message to a work item that unpins the flagged ops' pages and frees the message from process context. Here, unpin_user_pages_dirty_lock() is safe outside the atomic context. Everything else keeps running in the caller's context exactly as before: the rest of the purge - the zerocopy completion, the socket put and the MR reference drops - as well as RDMA writes, whose pages the remote side only reads and which unpin without dirtying, everything on rds_tcp, and final puts that already happen in process context (socket close, connection teardown). Deferring only the unpin means the work item touches nothing but the pinned pages and the rds module's own memory: it cannot call back into a transport module, so it changes nothing about the transports' shutdown and unload ordering. rds_exit() drains any pending unpin work via destroy_workqueue(rds_wq) before the module goes away. The Oracle UEK kernel avoids the sleeping unpin by calling set_page_dirty() directly from the tasklet, which is subject to the file-backed page problem above, so this deliberately does not follow UEK here. Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260730041629.3512480-2-achender@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6802944b2bca3a31b9284b45754e6e30a1a63294 Author: Wahid Khan Date: Mon Jul 20 23:26:56 2026 +0530 HID: intel-ish-hid: ignore post-init ENUM_DEVICES from firmware [ Upstream commit f3f3f6df05226dfa220c4e603310dae94595060a ] Some ISH firmware versions (observed on Tiger Lake LP, 8086:a0fc, GUID {33AECD58-B679-4E54-9BD9-A04D34F0C226}) periodically re-send an unsolicited HOSTIF_DM_ENUM_DEVICES response roughly every 79 seconds. The current guard collapses two distinct cases into one condition: if (!(response_flag) || init_done) -> bad packet + ish_hw_reset This incorrectly treats a valid post-init firmware announcement as a corrupted packet, triggering an ISH soft-reset and a full ISHTP re-initialisation cycle on each occurrence (~1100 times per day on affected hardware). Split the check: reject messages with no response flag as before, but simply discard valid ENUM_DEVICES messages that arrive after init is complete. Signed-off-by: Wahid Khan Acked-by: Srinivas Pandruvada Tested-by: Zhang Lixu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d8152a70f694a5ed960e1cdf79f82fada1183b3a Author: Yuxiang Lin Date: Thu Jul 23 01:56:02 2026 +0800 HID: quirks: add ALWAYS_POLL quirk for AULA Mini 60 HE Pro Dongle [ Upstream commit 2884e21b18613708f050ec75330b265dd07ecc03 ] The AULA Mini 60 HE Pro wireless keyboard dongle (USB ID 0c45:fefe) becomes unresponsive after roughly one minute of idle. No error appears in dmesg; the only recovery is physically replugging the dongle. This has been reproduced across kernels 6.8, 6.14 and 7.1.3. Testing shows HID_QUIRK_ALWAYS_POLL alone resolves the issue, verified via usbhid.quirks=0x0c45:0xfefe:0x400. Signed-off-by: Yuxiang Lin Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 799f1158406074aa70c77af9fd27c726b2ab9031 Author: Aaron Ma Date: Mon Aug 3 13:39:32 2026 +0800 HID: quirks: Add ALWAYS_POLL quirk for Beitong BTP-KP20D dongle [ Upstream commit bfff246b3a31cb45ec297ca5e2a77c1410b207ac ] The BTP-KP20D dongle in Direct/HID mode (20dd:5159) re-enumerates every few seconds because usbhid never submits its interrupt-IN URB: no HID driver binds to the vendor-specific report descriptor, so the device is never opened, and the firmware treats the idle endpoint as a lost link. Add HID_QUIRK_ALWAYS_POLL to keep the interrupt-IN URB submitted from probe time. Signed-off-by: Aaron Ma Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d191b5ca149b7597e45051c82cbe43d76a1f881e Author: Stuart Hayhurst Date: Tue Jul 21 18:12:48 2026 +0100 HID: logitech-hidpp: Add support for G502 X Plus USB mouse [ Upstream commit 6f4b44abe4ccdcfdab75c9493b8c7634fee37133 ] The wireless dongle is already supported, this adds detection for the mouse in wired mode. Supports battery reporting. Signed-off-by: Stuart Hayhurst Reviewed-by: Bastien Nocera Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 70c6c25f1fdc52c435ace317010e1f819c985416 Author: Mauricio Orozco Date: Wed Jul 29 22:34:55 2026 -0500 ALSA: hda/realtek: Add quirk for ASUS VivoBook M515DA/X515DAP [ Upstream commit a9fa2a016e805504223abf8c9b373ac9f7bfb9b3 ] The ASUS VivoBook M515DA/X515DAP (subsystem ID 1043:1e3e) requires the ALC256_FIXUP_ASUS_MIC_NO_PRESENCE fixup to enable the internal microphone. Without this quirk, the internal microphone captures only silence under Linux, while it works correctly under Windows. The fix has been verified on real hardware. Tested on an ASUS VivoBook M515DA/X515DAP running Linux Mint 22.3 with Ubuntu HWE kernel 7.0.0-28. Signed-off-by: Mauricio Orozco Link: https://patch.msgid.link/20260730033506.8958-1-mauoro3@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0a03dd1d896b15b8900db304f988fbfaf7ea20dd Author: Mariano Baragiola Date: Tue Jul 28 16:26:10 2026 -0300 wifi: wilc1000: validate monitor transmit frame headers [ Upstream commit 9d96e037ff90a2fc81a841b2002d500a5a4a5351 ] wilc_wfi_mon_xmit() reads the radiotap length before ensuring that the fixed header is present. After stripping that header, it reads the frame type and all three 802.11 addresses without checking how much frame data remains. A truncated monitor injection can therefore cause out-of-bounds reads. Validate the radiotap header first, use the common 802.11 helper to check the variable header length, and require a complete three-address header before using the addresses. This covers QoS and four-address data headers while rejecting short control headers that this path cannot classify. Signed-off-by: Mariano Baragiola Link: https://patch.msgid.link/20260728192610.2236361-1-mbaragiola@linux.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cbbef3c7d07caee341bea159044a1a746352ff8a Author: Can Peng Date: Thu Jul 23 13:56:17 2026 +0800 wifi: brcmfmac: validate msgbuf flowring IDs before use [ Upstream commit 32856f39fefdc75bd253cab999f996750628648e ] Firmware messages carry flow_ring_id values which brcmfmac converts to an internal flowid by subtracting BRCMF_H2D_MSGRING_FLOWRING_IDSTART. The resulting value is used as a bit index in txstatus_done_map and as an array index into msgbuf->flowrings and the flowring state. Validate the firmware supplied flow_ring_id before using it. This prevents flow_ring_id values below BRCMF_H2D_MSGRING_FLOWRING_IDSTART from underflowing and rejects values outside msgbuf->max_flowrings. In the tx status path, complete the packet with an error after removing a valid packet id so the skb is not leaked when the flow ring id is invalid. Signed-off-by: Can Peng Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260723055618.550834-1-pengcan@kylinos.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cc03f779a328c9e06e725355dea8267df9c32b41 Author: Can Peng Date: Fri Jul 24 17:25:30 2026 +0800 wifi: brcmfmac: Set DMA direction for msgbuf packet IDs [ Upstream commit f0ba5fd51ff23077ce66cb9be79d41a4b7c19c5e ] brcmf_msgbuf_init_pktids() takes the DMA direction from its callers, but never stores it in the packet ID state. Since the state is zeroed, pktids->direction remains DMA_BIDIRECTIONAL for both the TX and RX packet ID pools. All msgbuf packet ID map and unmap paths use pktids->direction. As a result, TX buffers requested with DMA_TO_DEVICE and RX buffers requested with DMA_FROM_DEVICE are mapped and unmapped as DMA_BIDIRECTIONAL instead. Store the caller-provided direction when initializing the packet ID state. Signed-off-by: Can Peng Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260724092530.674624-1-pengcan@kylinos.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 853afa74a0a8db6b5ff17a33b6c7df6d8d617e20 Author: Felix Fietkau Date: Sat Aug 1 14:53:31 2026 +0000 wifi: mt76: mt7603: restore hardware PS buffering after a service period [ Upstream commit 636a883e2feef5e4ff95695d3c372ceff03960f5 ] Releasing buffered frames has to turn off the PSE redirect for the station, otherwise the released frames are looped straight back into the driver PS queue. Nothing ever turns it back on: mt7603_sta_ps() only runs on an observed PM bit transition, and MT_WCID_FLAG_PS keeps mt76 from reporting the same state twice. After the first service period the hardware therefore treats a dozing station as awake and transmits at it directly, which is where the retry storms and the packet loss reported against U-APSD clients come from. Re-arm hardware buffering from mt7603_mac_work() for every station that is still known to be asleep, once the PSD queue has drained and the released frames have passed the redirect stage. Frames that are still queued belong to the service period that was just served, so unlike on a sleep transition they must not be pulled back with mt7603_filter_tx(). Track the sleep state separately from the WTBL state, so a station that wakes up while the re-arm is pending is not put back to sleep. Link: https://patch.msgid.link/20260801145334.1166751-7-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f1a8ab40a5a2ee4231f7e82518a8914dc9308b3e Author: Felix Fietkau Date: Sat Aug 1 14:53:29 2026 +0000 wifi: mt76: mt7603: fix U-APSD service period termination [ Upstream commit 697badc27a9b3b2a8d86092abeed767714f735a2 ] Frames released from the driver PS queue were all tagged with MORE_DATA and none of them ever carried the EOSP bit, so from the client's point of view a U-APSD service period was started but never finished. Clients that keep their receiver on until EOSP arrives stop sending trigger frames, and all downlink traffic for that station stalls until they give up. ieee80211_sta_eosp() only cleared the service period state inside mac80211, which is why the mismatch went unnoticed. Assign MORE_DATA per frame and set the wire EOSP bit on the last one. If the last released frame is a bufferable MMPDU it has no QoS control field to carry EOSP, so let mac80211 append a QoS-Null frame instead. Also stop handing the remaining frame budget to mt76_release_buffered_frames() once frames have been released from the PS queue: both would signal the end of the same service period. Releasing fewer frames than requested is allowed, and MORE_DATA tells the client to trigger again. Link: https://patch.msgid.link/20260801145334.1166751-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fe0126804871cbabf5aca900e3bad90e5c1c484e Author: Felix Fietkau Date: Sat Aug 1 14:53:28 2026 +0000 wifi: mt76: set the EOSP bit in the QoS header of the last released frame [ Upstream commit 0b8d2524716099ea4743fa65bc364f94b3106a31 ] When the driver implements .release_buffered_frames, mac80211 leaves the U-APSD signalling entirely to the driver: "In this case it is also responsible for setting the EOSP flag in the QoS header of the frames" (include/net/mac80211.h). Only IEEE80211_TX_STATUS_EOSP was being set, which merely ends the service period inside mac80211, so on air the service period was never terminated. Clients that wait for EOSP before going back to doze keep the SP open and stop triggering, which stalls all downlink traffic for that station. Set the wire EOSP bit on the last frame of a U-APSD service period. EOSP has no meaning for a PS-Poll response, so pass the release reason down and leave those frames alone. Link: https://patch.msgid.link/20260801145334.1166751-4-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 562b8dae64597a119fcdab5bdc1520650fdaef82 Author: Felix Fietkau Date: Fri Jul 24 12:48:07 2026 +0000 wifi: mt76: mt7615: fix NULL deref in mt7615_mac_set_rates [ Upstream commit 98aff74779da9f417386c589c36848e9c568f0f9 ] mt7615_tx() falls back to the vif BSS wcid when mac80211 hands a frame over without a station, e.g. while a station is being torn down, and to the global wcid when there is no vif either. Both tx_prepare_skb implementations derive a mt7615_sta from that wcid unconditionally and, if the rate control probe flag is set, pass it to mt7615_mac_set_rates(), which dereferences the NULL vif backpointer of the per-vif embedded sta: Unable to handle kernel read from unreadable memory at virtual address 0000000000000002 ... pc : mt7615_mac_set_rates lr : mt7615_tx_prepare_skb Neither entry is rate controlled by mac80211: the embedded sta has an empty rate set, and for the global wcid the container_of does not yield a valid mt7615_sta at all. Only resolve the sta for wcids that belong to a station. Reported-by: Chad Monroe Link: https://patch.msgid.link/20260724124813.3961474-23-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b9ba943727cc65c842f02e55ffbeddefd642ed53 Author: Peter Ujfalusi Date: Thu Jul 30 15:28:57 2026 +0300 ASoC: SOF: Intel: mtl: Power down DSP if it is left enabled in pre_fw_run() [ Upstream commit 31fd7a0bbfa4b7e8aff11f278e817664c6a5f68b ] It is expected that the DSP is in power down state when the firmware boot is attempted. If the DSP for any reason was left powered up then the DSP boot will fail since the ROM boot sequence might not be able to run. Make sure that the DSP is off before proceeding to boot it up. Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730122857.5294-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2ab864e23245323f0519e23d9c9f974572532a9b Author: ZhaoJinming Date: Wed Jul 29 10:00:05 2026 +0800 wifi: ath11k: fix resource leak on error in ext IRQ setup [ Upstream commit 8ab38bbac02298e3fb03008ed4a0227485c0fd62 ] In ath11k_ahb_config_irq(), when a CE request_irq() fails, the function returns the error immediately without freeing the CE IRQs that were successfully registered in previous loop iterations. The probe error path does not call ath11k_ahb_free_irq() either, so the previously registered CE IRQ handlers remain attached to the interrupt lines and are never released. In ath11k_ahb_config_ext_irq(), when an external request_irq() fails, the error is only logged and the loop continues. The function then returns 0 indicating success, leaving the device in a partially configured state where some external IRQs are not registered. This causes enable_irq()/disable_irq()/free_irq() to be called on unregistered IRQs during runtime and remove/shutdown, triggering WARN_ON(!desc->action), and missing interrupt handlers lead to data loss. Additionally, if alloc_netdev_dummy() fails for a later IRQ group, the function returns -ENOMEM without freeing the ext IRQs and napi_ndev that were successfully set up for earlier groups. Fix all three issues: propagate the error up to the caller and unwind all successfully registered IRQs and allocated resources on failure. Also move ab->irq_num[irq_idx] assignment after request_irq() succeeds in the ext IRQ path to match the CE IRQ path and avoid storing a stale IRQ number on failure. Signed-off-by: ZhaoJinming Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260729020005.219253-1-zhaojinming@uniontech.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 25fbd699677554849541ceab007b9b3ee722c321 Author: Geetha sowjanya Date: Mon Jun 1 13:03:18 2026 +0530 perf: marvell: Cancel CN10K DDR PMU hrtimer on device remove [ Upstream commit 7dbcb0268d1e2a1d3badb0c6e77ee70e550b1787 ] cn10k_ddr_perf_remove() did not cancel the poll hrtimer before returning. If the device was unbound while perf events were still active the timer callback could run post-free. To fix the issue by adding hrtimer_cancel() in remove(). Signed-off-by: Geetha sowjanya Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4da920688df0069618f608bafabd4abe3b0a4bd2 Author: Pablo Neira Ayuso Date: Tue Jul 28 10:40:06 2026 +0200 netfilter: nf_tables: call skb_valid_dst() before skb_dst() [ Upstream commit 689db98e535bf8efb5bc9c36f4fd3de3bd715eb6 ] When fetching the dst_entry from the skb, check if it valid, ie. this is not a template dst, for extensions that can be used from the netdev ingress and egress chains. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0c6d33329960b2d884a399196c8403643d8a9de6 Author: Minghao Zhang Date: Wed Jul 29 15:46:52 2026 +0000 netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets [ Upstream commit bf80e6802273a900311b44e47c9b1a59c6d2473c ] Commit be0502a3f2e9 ("netfilter: conntrack: tcp: only close if RST matches exact sequence") keeps an established conntrack entry in ESTABLISHED when an in-window RST does not match the expected sequence number exactly, so the endpoint can validate the RST with a challenge ACK. The timeout selection nevertheless uses the CLOSE timeout for every RST packet. The bug is that timeout selection is based on the packet type, not on the state transition result: even when RST validation keeps new_state in ESTABLISHED, the timeout is still forced to TCP_CONNTRACK_CLOSE. Linux TCP independently rate limits challenge ACKs per socket. A second non-exact RST can therefore arrive after the first challenge ACK has restored the timeout but before the rate limit expires. The second RST lowers the timeout to 10 seconds again while the endpoint suppresses the second challenge ACK, allowing the conntrack entry to expire while both TCP endpoints remain established. Using the ESTABLISHED timeout for such RSTs would avoid this short expiration window, but it could also retain stale entries for the five-day default because conntrack cannot reliably match the endpoint's exact TCP state. Use the UNACK timeout for RST packets that leave the conntrack entry in TCP_CONNTRACK_ESTABLISHED. Exact-match RSTs and accepted RST packet trains still fall through to timeouts[new_state], which preserves the CLOSE timeout when conntrack accepts the RST as closing the flow. This avoids the aggressive 10-second expiration window for non-exact RSTs while preserving the short timeout for RSTs that conntrack accepts as closing the flow. Suggested-by: Florian Westphal Reported-by: Minghao Zhang Reported-by: Jianjun Chen Signed-off-by: Minghao Zhang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7b592201c2657e6d2ba9e043419444c10dd9a493 Author: Zhi-Jun You Date: Wed Jul 15 23:21:12 2026 +0800 wifi: mt76: wed: fix kernel panic on non-DBDC MT7986 [ Upstream commit 8a177dabeeead47dda4d4f91331282790eed0097 ] In mt76_wed_init_rx_buf, it's hardcoded to use MT_RXQ_MAIN. But for non-DBDC MT7986 MT_RXQ_BAND1 is used for RX data queue which leads to kernel panic when attaching WED. Use the correct RX queue by checking WED version and band_idx. v2 and band 1 -> MT_RXQ_BAND1 Others -> MT_RXQ_MAIN Kernel panic: Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 Internal error: Oops: 0000000096000005 [#1] SMP CPU: 1 UID: 0 PID: 925 Comm: kmodloader Tainted: G O 6.18.26 #0 NONE Tainted: [O]=OOT_MODULE Hardware name: Acer Connect Vero W6m (DT) pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : page_pool_alloc_frag_netmem+0x1c/0x1bc lr : page_pool_alloc_frag+0xc/0x34 sp : ffffffc081dab660 x29: ffffffc081dab660 x28: ffffffc081dabc60 x27: ffffff80091af040 x26: 0000008000000000 x25: ffffff80091a8898 x24: ffffff80091a5440 x23: 0000000000001000 x22: 0000000140000000 x21: ffffff80091a2040 x20: ffffff8003f1d780 x19: 0000000000000000 x18: 0000000000000020 x17: ffffffbfbf0ac000 x16: ffffffc080ee0000 x15: ffffff80049d47ca x14: 000000000000037b x13: 000000000000037b x12: 0000000000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffffff8003f1d7c0 x7 : 0000000000000000 x6 : ffffff8003f1d780 x5 : 0000000000000680 x4 : 0000000000000000 x3 : 0000000000002824 x2 : 0000000000000000 x1 : ffffffc081dab71c x0 : 0000000000000000 Call trace: page_pool_alloc_frag_netmem+0x1c/0x1bc (P) page_pool_alloc_frag+0xc/0x34 mt76_wed_init_rx_buf+0xf8/0x2ac [mt76] mtk_wed_start+0x79c/0x12ac mt7915_dma_start+0x274/0x63c [mt7915e] mt7915_dma_start+0x5b4/0x63c [mt7915e] mt7915_dma_init+0x49c/0x81c [mt7915e] mt7915_register_device+0x24c/0x530 [mt7915e] mt7915_mmio_probe+0x91c/0x1980 [mt7915e] platform_probe+0x58/0xa0 really_probe+0xb8/0x2a8 __driver_probe_device+0x74/0x118 driver_probe_device+0x3c/0xe0 __driver_attach+0x88/0x154 bus_for_each_dev+0x60/0xb0 driver_attach+0x20/0x28 bus_add_driver+0xdc/0x200 driver_register+0x64/0x118 __platform_driver_register+0x20/0x30 init_module+0x74/0x1000 [mt7915e] do_one_initcall+0x4c/0x1f8 do_init_module+0x50/0x210 load_module+0x15f8/0x1b10 __do_sys_init_module+0x1a8/0x260 __arm64_sys_init_module+0x18/0x20 invoke_syscall.constprop.0+0x4c/0xd0 do_el0_svc+0x3c/0xd0 el0_svc+0x18/0x60 el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x158/0x15c Code: aa0003f3 a9025bf5 a90363f7 d2820017 (b9400000) Signed-off-by: Zhi-Jun You Link: https://patch.msgid.link/20260715152113.553-1-hujy652@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f39060120cf8171173e2d39b029adf89d5424355 Author: Ahmed Naseef Date: Sun Jul 19 12:25:30 2026 +0400 wifi: mt76: mt7603: add 0x7592 EEPROM chip ID [ Upstream commit d16447d7470502e998d82e806ca7ed49d1baa853 ] Some EcoNet based routers ship an on-flash EEPROM whose chip-id is 0x7592 instead of the expected 0x7603. The device probes as PCI 14c3:7603 and the hardware MT_HW_CHIPID register reports 0x7603, independent of the EEPROM value. This is seen across multiple EcoNet EN751221 and EN7528 based devices (for example the Genexis Platinum 4410). Signed-off-by: Ahmed Naseef Link: https://patch.msgid.link/20260719082530.3879831-1-naseefkm@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c16fe00dc2fd32662391b0186ebadddf1cda2a0e Author: Prashant Rahul Date: Thu Jul 16 21:55:10 2026 +0530 wifi: mt76: mt7921: fix memory leak when skb_linearize fails in mcu rx event [ Upstream commit 4361f1660101270611eb5dc39799f620b35f2e4d ] The ownership of sk_buff skb is passed to mt7921_queue_rx_skb, each path inside it under the switch case handles cleaning of skb and it is true for mt7921_mcu_rx_event as well. mt7921_mcu_rx_event, on a success path, either queues skb via mt76_mcu_rx_event or cleans it immediately inside mt7921_mcu_uni_rx_unsolicited_event. However inside mt7921_mcu_rx_event, if skb_linearize fails, the function returns immediately and never bothers cleaning skb which leaks skb. Since skb is fully owned at this point, it is safe to call dev_kfree_skb which fixes the leak. Granted, the skb_linearize failure is rare as it can only fail under heavy memory usage, but at the same time, leaking memory under heavy memory usage can worsen the OOM condition. Signed-off-by: Prashant Rahul Link: https://patch.msgid.link/20260716-mt7921-mem-leak-v1-1-6e9c0ea19f63@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 44081a569fb64ae38ba97d6208a36f13096ab8c3 Author: David Bauer Date: Sat May 16 16:49:42 2026 +0200 wifi: mt76: mt7915: configure noise floor reporting on reset [ Upstream commit a92cd5dd792a63a5d8a72142835382d4edbe9933 ] When performing a full system recovery of the MCU on a dual-phy platform, band 0 (usually 2.4GHz) stops reading correct noise floor data. This is due to noise floor reporting only being configured correctly for the second device PHY. Configure the respective registers correctly after restarting the MCU firmware to fix reported noise-floor values. Signed-off-by: David Bauer Link: https://patch.msgid.link/20260516144944.2574053-1-mail@david-bauer.net Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5470927c67dcf3e573d0f942cfa41a5f129495a2 Author: Devin Wittmayer Date: Fri Jun 12 17:25:44 2026 -0700 wifi: mt76: mt76x02: report rx FCS errors to mac80211 [ Upstream commit ddae0bcb01e71c1184bb3f526f9622e31dc38f3b ] When the fcsfail filter is enabled the hardware passes frames with a bad FCS up to the driver, but mt76x02_mac_process_rx() never checks MT_RXINFO_CRCERR and hands them to mac80211 without RX_FLAG_FAILED_FCS_CRC. In monitor mode the radiotap flags byte then never gets IEEE80211_RADIOTAP_F_BADFCS set and corrupted frames cannot be told apart from clean ones. Set RX_FLAG_FAILED_FCS_CRC from the descriptor CRC error bit, matching mt7603, mt7615, mt7915, mt7921, mt7925 and mt7996. Reported-by: 0072a70 <90307219+0072a70@users.noreply.github.com> Closes: https://github.com/morrownr/mt76/issues/38 Tested-by: 0072a70 <90307219+0072a70@users.noreply.github.com> Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260613002544.27750-3-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3b45fe35f1c060c8d2e66bfe6c107de54e6e77e2 Author: David Bauer Date: Thu Jun 11 23:56:56 2026 +0200 wifi: mt76: mt7603: free beacon SKB on error [ Upstream commit 965cbdbdfbd37a659a05ff88e49c216975bd9d2e ] The SKB containing the generated beacon is not freed when the beacon queue is deected stuck and scheduled for recovery. Fixes potential memory leaks in case the beacon queue is detected stuck. Signed-off-by: David Bauer Link: https://patch.msgid.link/20260611215658.259324-1-mail@david-bauer.net Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9bc5063c5123ca7f075d240c434cd790135b98b3 Author: Hari Mishal Date: Fri Jul 17 17:06:22 2026 +0200 virtio_console: take a kref in find_port_by_vq() to fix port UAF [ Upstream commit 18dd0b4e489e4f0e3b748cf36ccb909c75a3efab ] find_port_by_vq() returns a raw struct port pointer without taking a reference on it, unlike find_port_by_devt_in_portdev() which does. find_port_by_vq()'s only two callers, in_intr() and out_intr(), run as virtqueue interrupt callbacks, entirely independent of and possibly concurrently with unplug_port(), which itself runs from a workqueue when the host sends a VIRTIO_CONSOLE_PORT_REMOVE control message. unplug_port() removes the port from portdev->ports under ports_lock, then later drops its last reference with kref_put(), freeing it via remove_port(). find_port_by_vq() also walks portdev->ports under ports_lock, so if it finds the port still on the list, the list removal, and therefore the eventual kref_put(), has not happened yet, and taking a reference at that point is always safe. Without doing so, in_intr()/out_intr() can be left holding a pointer to a port that unplug_port() frees on another core before they are done using it. Both triggers are host-controlled as the host decides when to send the PORT_REMOVE control message and when to kick the port's data vq. So a malicious backend could race the two on purpose, without any guest side cooperation. The freed object is a generic kmalloc allocation containing a wait_queue_head_t, which in_intr()/out_intr() pass to wake_up_interruptible() after touching the stale pointer. wake_up_interruptible() invokes a function pointer read out of the wait queue's entries. If the freed slab slot is reclaimed with attacker influenced content before that call, then this is an arbitrary function call primitive rather than just undefined behaviour. Take a reference in find_port_by_vq() while still holding ports_lock, matching find_port_by_devt_in_portdev(), and release it in in_intr() and out_intr() once they are done with the port. Signed-off-by: Hari Mishal Link: https://patch.msgid.link/20260717150622.23636-1-harimishal1@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b64510df5898a8c36c3940d35036527a382552cf Author: Rosen Penev Date: Wed Jul 29 10:46:46 2026 +0100 nvmem: brcm_nvram: fix out-of-bounds access on malformed flash data [ Upstream commit a67e2c323a47a2254ed3472b5e4c53abac20f116 ] The length check in brcm_nvram_parse() validated header->len against priv->nvmem_size (the full partition size) instead of priv->data_len (the actual allocated data buffer). A malformed flash partition with header->len between the two would pass the check, causing brcm_nvram_add_cells() to read and write priv->data[len - 1] beyond the heap allocation. Also add a minimum bound: len < sizeof(*header) could underflow the data[len - 1] access. Fix both bounds by rejecting len outside [sizeof(*header), priv->data_len]. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260729094647.111468-14-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6983cdcd9e478f182e8d0bc17b5c5ce3673930d8 Author: Rosen Penev Date: Wed Jul 29 10:46:45 2026 +0100 nvmem: brcm_nvram: reject empty NVRAM partition [ Upstream commit fde46579cf8872138b296349c2bd8a3cd3f132e2 ] If the partition is completely erased (all padding bytes), the trimming loop reduces data_len to 0. devm_kzalloc(dev, 0, GFP_KERNEL) returns ZERO_SIZE_PTR ((void *)16), which is non-NULL and bypasses the NULL check. The subsequent cast of priv->data to struct brcm_nvram_header * and dereference of header->magic causes a page fault on address 0x10. Reject data_len smaller than the header before allocating. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260729094647.111468-13-srini@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 10a665862bfe0ecfd2bd79786e6d91c65a385ea4 Author: 이상호 Date: Thu Jul 2 07:07:29 2026 +0900 romfs: detect hard link cycles [ Upstream commit d30b5a954e0a4dcc16bba9c310c13709a6169a52 ] romfs_iget() follows on-disk hard link entries until it reaches a non-hard link inode: pos = be32_to_cpu(ri.spec) & ROMFH_MASK; The target position is image-controlled, and the loop does not detect cycles. A crafted romfs image can make the root inode a hard link. The hard link can point back to itself and leave mount(2) spinning in the kernel. Reject excessive hard link indirection with -ELOOP. Normal romfs images do not need long hard link chains. This bounds corrupted-image traversal. Propagate romfs_iget() errors from lookup because hard link traversal can now fail with -ELOOP. Signed-off-by: 이상호 Link: https://patch.msgid.link/20260701220729.822112-1-kudo3228@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit b7e89e2fa8f18d70d966cef55082226f0aa5d9e8 Author: Genjian Zhang Date: Sun Jul 12 00:13:26 2026 +0800 md/raid5: complete discard bios while reshape is active [ Upstream commit 85764f475f3b3abd956bf8eaeaa643b367676cf4 ] make_discard_request() returns without completing the bio when reshape is in progress. Discard callers block in submit_bio_wait() waiting for a completion that never arrives. The caller hangs in uninterruptible sleep, and this does not resolve when reshape finishes. Complete the bio with BLK_STS_AGAIN so userspace can retry after reshape, consistent with the existing policy of not processing discard during reshape. Tested on a loop-backed RAID5 array during mdadm --grow: without this patch, blkdiscard hangs in bio_await() and remains in uninterruptible sleep after md reports "reshape done"; with this patch it returns -EAGAIN instead. Signed-off-by: Genjian Zhang Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260711161326.962336-1-zhanggenjian@126.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 50d94323e8558b018dc16380e2909344e1dc926b Author: bui duc phuc Date: Wed Jul 29 17:00:18 2026 +0700 regulator: rt6245: Restore state on enable failure [ Upstream commit e95a0a309ca02bf26dc937cdeb3fe2a235c65f63 ] Currently, if regcache_sync() fails after the enable GPIO has been asserted, the driver returns with enable_gpio still set high and regcache_cache_only() left disabled. This leaves the device state inconsistent with the disabled state, where the enable GPIO is low and cache_only is enabled. On failure, restore the original state by setting cache_only back to true and driving the enable GPIO low before returning the error. Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260729100018.66577-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1a23e121c92e45dac842febaac7834be6b76cb58 Author: Oleg Proshkin Date: Thu Jun 11 18:46:29 2026 +0300 mfd: axp20x: Preserve other control bits when powering off [ Upstream commit 3756bf05c963563f1325af105356541882dd5899 ] axp20x_power_off() triggers shutdown by writing AXP20X_OFF (BIT(7)) to the power-off control register with regmap_write(), which rewrites the whole register and clears other control bits in it. On the AXP221/AXP223 (and the register-compatible AXP228) - that register also holds the CHGLED auto-control bit. Clearing it during an orderly shutdown disables the hardware charge indicator, so the charge LED stays dark while the board is powered off and charging. Other variants keep unrelated configuration in the same register too. Set only the power-off bit with regmap_set_bits() and leave the rest of the register untouched. The shutdown register is readable on every variant, so the read-modify-write should be safe. Tested on a ClockworkPi uConsole (Raspberry Pi Compute Module 4, AXP228, which enumerates as AXP221): register AXP20X_OFF_CTRL reads 0x08 at runtime, so the old code left it 0x80 whereas setting only BIT(7) leaves 0x88. Writing 0x88 at power-off enables the charge LED while still powering off the PMIC. Signed-off-by: Oleg Proshkin Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260611154629.76607-1-oleg.pro171@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 6a81aedf497a49fa98439123c19a6811e9562b98 Author: Bob Song Date: Thu Jul 30 09:53:01 2026 +0800 ALSA: hda/realtek: add missing error checks for COEF index reads in alc269 [ Upstream commit 5b106b40ed22098f2bc049efb645148d038444bd ] alc_read_coef_idx() and alc_read_coefex_idx() can return -1 on error via snd_hda_codec_read(). Several codec initialization and shutdown functions save these return values and later write them back to hardware registers without checking for errors, potentially corrupting COEF register state on a read failure. Add error checks in: - alc282_init() and alc282_shutup(): check coef78 before write-back - alc285_hp_init(): check coef38/coef0d/coef36 before update, check val before write-back, and break polling loop on error - alc294_hp_init(): break polling loop on read error Signed-off-by: Bob Song Link: https://patch.msgid.link/20260730015302.253008-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 937f704f4bfc76d912c3df618d90b4e8e7277eb0 Author: Dmitry Torokhov Date: Wed Jun 10 16:03:52 2026 -0700 mfd: ipaq-micro: Fix out-of-bounds stack read in ipaq_micro_str [ Upstream commit da3a98c941753255418616d249e5b40db0927c26 ] ipaq_micro_str() decodes a UTF-16LE string into an ASCII string. It copies characters to a stack buffer retstr, but fails to null-terminate it. When kstrdup() is called on retstr, it can read past the buffer into uninitialized stack memory, potentially leaking stack contents. Fix this by initializing retstr to zero. Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov Link: https://patch.msgid.link/aintJF4X5tWDW-Ej@google.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f732a202ae1cac8958282b21d1c1cd17bd806afc Author: Konstantin Komarov Date: Thu Jul 30 10:42:58 2026 +0200 fs/ntfs3: Fix memory leak in indx_find_sort() [ Upstream commit 194491be54e1c9e4d29d3ee777b05ff031c4b670 ] When popping a level from the index lookup stack, indx_find_sort() frees the struct indx_node but not the index buffer it owns. Every call that descends and then pops a level leaks that allocation. Free n->index before freeing the node itself. Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 2728611a9cc501e4f6b0ebe2270d1fbbdee2e369 Author: Bob Song Date: Thu Jul 30 09:53:02 2026 +0800 ALSA: hda/realtek: add missing NULL check for codec->bus->pci [ Upstream commit 3b36ac93739e7b119a30affaee9c2dd41f24efbb ] In alc269_probe(), codec->bus->pci is dereferenced without a NULL check for the ALC236 vendor ID case. Add the missing check, consistent with the existing pattern used elsewhere in the same function. Signed-off-by: Bob Song Link: https://patch.msgid.link/20260730015302.253008-2-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ed7d338c57cddd8d404bcd40a42ba8d5c73fa9eb Author: Yichong Chen Date: Tue Jul 28 12:29:23 2026 +0800 exfat: free new directory cluster if zeroing fails [ Upstream commit ce12a39bed483008683438962b3a605374e6f803 ] exfat_alloc_new_dir() allocates a cluster for a new directory before zeroing it. If exfat_zeroed_cluster() fails, the function returns the error but leaves the allocated cluster in use. Free the newly allocated cluster before returning the zeroing error. Signed-off-by: Yichong Chen Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ff69fd262ed126255f8566853e2d6dfbaefb2cf7 Author: Pengpeng Hou Date: Sat Jul 4 20:43:08 2026 +0800 soc: mediatek: add missing MODULE_DEVICE_TABLE() [ Upstream commit ec762057868d70d474a9816e9c293c2ef801c3c9 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 2c6749d443ac2950b5e9101dc017b60b2a33d42d Author: Weiji Wang Date: Tue Jul 28 03:58:20 2026 +0800 drm/panel-edp: Add BOE NE140QDM-NX2 [ Upstream commit 354b9c43d36ce9b41e48b2d67c5d9b953a0e9d64 ] Add timing from datasheet for BOE NE140QDM-NX2. edid-decode (hex): 00 ff ff ff ff ff ff 00 09 e5 f2 0a 00 00 00 00 20 1f 01 04 a5 1e 13 78 03 ee 96 a3 54 4c 99 26 0f 4e 51 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 60 d2 00 a0 a0 40 32 60 30 20 35 00 2e bd 10 00 00 18 c8 9d 00 a0 a0 40 32 60 30 20 35 00 2e bd 10 00 00 18 00 00 00 fd 00 30 78 c6 c6 36 01 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 45 31 34 30 51 44 4d 2d 4e 58 32 20 01 f8 70 13 79 00 00 03 01 14 30 69 00 05 ff 09 9f 00 2f 00 1f 00 3f 06 31 00 02 00 04 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 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 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 00 00 00 4d 90 Signed-off-by: Weiji Wang Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/82fc6395-3425-4f71-ba58-813856cee61d@gmail.com Signed-off-by: Sasha Levin commit 0d96af6c34ca3761196dbf69f3072bb671578755 Author: Heiko Carstens Date: Mon Jul 20 10:58:30 2026 +0200 s390/mm: Fix handling of vmalloc area in do_secure_storage_access() [ Upstream commit a2e5a9d853e015bc876399eb18435aa88101c60a ] Secure storage access exceptions in vmalloc area need to be handled separately since virt_to_phys() does not work on such addresses. Given that there cannot be a valid access let such exceptions fail immediately. The kernel will either fixup or crash. Tested-by: Christian Borntraeger Signed-off-by: Heiko Carstens Reviewed-by: Christian Borntraeger > --- Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 020be4f6fa046b862d92201bb29c5b908cd62d95 Author: Heiko Carstens Date: Mon Jul 20 10:58:28 2026 +0200 s390/mm: Add missing mm check to do_secure_storage_access() [ Upstream commit 7cf227b2707ed0129018c283ffc8f893945586db ] Similar like the normal exception handler the secure storage access exception handler needs to verify if mm is not NULL, which may happen with kernel threads. Reported-by: sashiko-bot Closes: https://lore.kernel.org/all/20260717132345.539A11F00A3A@smtp.kernel.org/ Signed-off-by: Heiko Carstens Reviewed-by: Christian Borntraeger > --- Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit ad0976d2cc58b1c3d55d320882a6d02f985b5ecd Author: Armin Wolf Date: Mon Jul 20 15:19:19 2026 +0200 platform/x86: dell-smbios-wmi: Fix chardev resource management [ Upstream commit 41427211f663c6eb36986ca2ea68d7e87aac52e9 ] When unbinding the WMI driver while a userspace application has an open file descriptor for the character device, a UAF occurs: KASAN: slab-use-after-free in _copy_to_user from platform/x86/dell-smbios-wmi The reason for this is that even after calling misc_deregister(), userspace appications can still call read() and/or ioctl() on open file descriptors associated with the already unregistered character device. This causes a UAF by attempting to access the already freed state container of the WMI driver. Fix this by no longer storing the state container inside filp->private_data. Instead retrieve the state container using get_first_smbios_priv() and return -ENODEV if the state container does not exist anymore. Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/platform-driver-x86/178144969601.60470.13396800403157907003@gmail.com/ Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260720131921.368000-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 7ad1c9970678a40372e1991b7e23d4858753e32f Author: Rob Clark Date: Wed Jul 29 08:55:38 2026 -0700 drm/msm: Fix barriers accessing ctx vm [ Upstream commit ae88499d71ce80ecd25c055eddddace108266321 ] Don't rely on store ordering to protect us from caller seeing a partially initialized vm. Reported-by: Sashiko Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/743079/ Message-ID: <20260729155609.20190-2-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 94e9beb9f07edf273f5a0fa1bfc972a50c48b29e Author: Rob Clark Date: Wed Jul 29 08:55:42 2026 -0700 drm/msm: Move nr_cmds initialization [ Upstream commit 9ee2884ed58e6b39da35732146446d5930e4746b ] Previously if we entered an error path between these two points, we could leak the relocs tables due to submit->nr_cmds still being zero. In practice, relocs are disallowed on a6xx+, and non-ancient userspace will not use relocs on earlier gens unless running on an ancient kernel. But userspace could use this to trigger a memory leak. Reported-by: Sashiko Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/743085/ Message-ID: <20260729155609.20190-6-robin.clark@oss.qualcomm.com> Signed-off-by: Sasha Levin commit 53b20af866fac2cf29ae749cc8c2ff83974ff760 Author: wangdicheng Date: Wed Jul 29 15:09:35 2026 +0800 ALSA: hda/conexant: Add NULL check for dc_mode_path [ Upstream commit 273806f38ce95c95c288a03d3de1e423cd3e5543 ] snd_hda_add_new_path() returns NULL when no path exists between the given NIDs, but olpc_xo_update_mic_pins() passes dc_mode_path straight to snd_hda_activate_path() which dereferences it without checking. Add the missing NULL guards, same as the local path variable already has in the same function. Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260729070935.548050-2-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 521f9dcf2e2614c0b3a9adee3b0724b4fb401154 Author: Yichong Chen Date: Wed Jul 29 10:25:43 2026 +0800 exfat: clean up new entry on add entry failure [ Upstream commit 0901a71e8cff5c60dd464529cba2ed30a2ab0a3f ] exfat_add_entry() initializes a new directory entry set before writing it with exfat_put_dentry_set(). If the write fails, mkdir/create returns an error but a partially written entry may be left behind. For non-zero-size directories, the failure also happens after a cluster has been allocated for the new directory. Clean up the new entry best-effort, and free the newly allocated directory cluster only when the cleanup writeback succeeds. This avoids freeing a cluster that may still be referenced by an on-disk entry if the cleanup fails. Signed-off-by: Yichong Chen Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit f10cfe517a1581a10d3758a7cca3c51181a6ef06 Author: K Prateek Nayak Date: Tue Jul 28 05:25:34 2026 +0000 arm64/runtime-const: Use aarch64_insn_patch_text_nosync() for patching [ Upstream commit a6690350a4ae7558b39d15fcc776c4d1ab5bbf39 ] The current scheme to directly patch the kernel text for runtime constants runs into the following issue with futex adapted to using runtime constants on arm64: Unable to handle kernel write to read-only memory at virtual address ... The pc points to the *p assignment in the following call chain: futex_init() runtime_const_init(shift, __futex_shift) __runtime_fixup_shift() *p = cpu_to_le32(insn); which suggests that core_initcall() is too late to patch the kernel text directly unlike the "d_hash_shift" which is initialized during vfs_caches_init_early() before the protections are in place. Use aarch64_insn_patch_text_nosync() to patch the runtime constants instead of doing it directly to allow runtime_const_init() slightly later into the boot. Since aarch64_insn_patch_text_nosync() calls caches_clean_inval_pou() internally, __runtime_fixup_caches() ends up being redundant. runtime_const_init() are rare and the overheads of multiple calls to caches_clean_inval_pou() instead of batching them together should be negligible in practice. The cpu_to_le32() conversion of instruction isn't necessary since it is handled later in the aarch64_insn_patch_text_nosync() call-chain: aarch64_insn_patch_text_nosync(addr, insn) aarch64_insn_write(addr, insn) __aarch64_insn_write(addr, cpu_to_le32(insn)) Sashiko noted that aarch64_insn_patch_text_nosync() does not expect a lm_alias() address and Catalin suggested it is safe to drop the lm_alias() for runtime patching since the kernel text is readable. The address passed to fixup function is interpreted as a __le32 and dereferenced as is to read the opcode at the patch site. No functional changes are intended. Signed-off-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Catalin Marinas Reviewed-by: Charlie Jenkins Tested-by: Charlie Jenkins Link: https://patch.msgid.link/20260728052540.4728-3-kprateek.nayak@amd.com Signed-off-by: Sasha Levin commit a5c18f62c897e0cffc469db8af52143a6e1b57f3 Author: Matthew Stewart Date: Fri Jun 19 13:41:36 2026 -0400 drm/amd/display: Fix rounding errors in CalculatePrefetchSchedule [ Upstream commit fa0300333db07ca4ad56c9879f155faafd3f7079 ] [why] Rounding errors were causing mode validation to fail in some cases when it should not. (IE. Increasing fclk from a lower value could lead to validation failure, which should not happen.) Reviewed-by: Dillon Varone Signed-off-by: Matthew Stewart Signed-off-by: Fangzhi Zuo Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a5bc8c907c9fa3540f750a4c3ea2b25bd54cacb4 Author: Amber Lin Date: Tue Jul 28 14:08:20 2026 -0400 drm/amdkfd: Fix signal reset event [ Upstream commit b38f9b6ffdfc86d5aff36881d9e8028c79bc98c9 ] When a mode reset happens, driver needs to notify the process on that GPU a reset event is happening. The existing code assumes the process is using the GPU that is getting mode reset, which is not always true. For example, on a 8G system, the process may be only using GPU 0~4 but a mode 2 reset is resetting the all 8 GPUs connected by XGMI. Trying to find a process on GPU 5~7 will fail, which is fine and should skip the event signal. Signed-off-by: Amber Lin Reviewed-by: David Yat Sin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b42b5fcf47c75797e8cba0f78c5ac020e5889e41 Author: David Strahan Date: Wed Jul 22 17:04:00 2026 -0500 scsi: smartpqi: Add new PCI device-ids [ Upstream commit 1a220e6e87a31c2572cd07ff47023e5cd92ac80f ] All PCI ID entries in Hex. Add PCI IDs for Hurray Data controllers: VID / DID / SVID / SDID ---- ---- ---- ---- 9005 / 028f / 207d / 4246 9005 / 028f / 207d / 4256 9005 / 028f / 207d / 4356 9005 / 028f / 207d / 4940 9005 / 028f / 207d / 4a46 Add PCI IDs for ZTE controllers: VID / DID / SVID / SDID ---- ---- ---- ---- 9005 / 028f / 1cf2 / 5451 9005 / 028f / 1cf2 / 5452 9005 / 028f / 1cf2 / 5453 Add PCI ID for Ramaxel controller: VID / DID / SVID / SDID ---- ---- ---- ---- 9005 / 028f / 1f3f / 0670 Signed-off-by: David Strahan Reviewed-by: Don Brace Link: https://lore.kernel.org/linux-scsi/20260722220401.6357-1-david.strahan@microchip.com/ Link: https://patch.msgid.link/20260722220401.6357-4-david.strahan@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 27577bc864c76dcb614afbd04a9a6a0327bf8156 Author: Pengpeng Hou Date: Wed Jun 24 13:52:37 2026 +0800 i2c: qup: Propagate clock enable failures [ Upstream commit a477626332800942f463d76aa48db0c47f1dfd18 ] The QUP I2C driver treats the core and iface clocks as required resources, but qup_i2c_enable_clocks() ignores clk_prepare_enable() failures. Probe can then continue to register the I2C adapter, and runtime/system resume can return success, even when a required clock transition failed. Make the helper return an error, unwind a partially enabled clock, and propagate failures from probe and resume paths. Signed-off-by: Pengpeng Hou Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260624055237.29977-1-pengpeng@iscas.ac.cn Signed-off-by: Sasha Levin commit 47aa1638074e20f6b6540e7ae561f07940b61e65 Author: Gary Guo Date: Thu Jul 23 23:00:40 2026 +0100 ata: ata_generic: Don't store pci_device_id [ Upstream commit 4f3075f629077a8cb3d3455c794a1f4a8fc8b43e ] pci_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. All information apart from driver_data can be easily retrieved from pci_dev, so just store driver_data. Signed-off-by: Gary Guo Signed-off-by: Bjorn Helgaas Reviewed-by: Danilo Krummrich Acked-by: Damien Le Moal Link: https://patch.msgid.link/20260723-pci_id_fix-v4-1-3580726844e1@garyguo.net Signed-off-by: Sasha Levin commit 39985760acd2b65aa953e49016c098a8e989e0e1 Author: Colin Foster Date: Mon Jun 29 15:53:44 2026 -0500 clk: clocking-wizard: fix clock difference detection [ Upstream commit 006ba909c240b832c876b7aed29c6beec9d1f5e5 ] Reviewed-by: Shubhrajyoti Datta Reviewed-by: Brian Masney Signed-off-by: Colin Foster Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 91b9c9cc4066fea6f1277a6bdf461a6b8b89e8b8 Author: Dmitry Osipenko Date: Thu Jun 25 11:30:52 2026 +0300 clk: tegra: support 48MHz clock for pll_p_out1 [ Upstream commit 46e31d69a547530fbef499bde888b6bb45a1deac ] UEFI on Surface2 sets pll_p_out1 to 48MHz which is not supported by kernel and causes BUG() early on. Add 48MHz clock support for pll_p_out1. Acked-by: Thierry Reding Signed-off-by: Dmitry Osipenko Signed-off-by: Jonas Schwöbel Signed-off-by: Svyatoslav Ryhel Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 409acb7efcbfdcb7037ec4fde86788becd6b77fc Author: Pengpeng Hou Date: Sat Jul 4 20:48:08 2026 +0800 clk: mediatek: mt6735-vencsys: add missing MODULE_DEVICE_TABLE() [ Upstream commit 36cf8d279ff90835f4b002dec28eedb059554842 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 1d6ad628f553d8db613ef3affc2c408582f5720a Author: Pengpeng Hou Date: Sat Jul 4 20:44:50 2026 +0800 clk: mediatek: mt6735-vdecsys: add missing MODULE_DEVICE_TABLE() [ Upstream commit 096ab64a0e69460bfb3557d09e17d2933280a1c6 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Reviewed-by: Brian Masney Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit fe6152b31967faf0b2427e948bd1fd0c9657e6c6 Author: Chen Changcheng Date: Fri Jul 24 10:52:18 2026 +0800 media: cx88: fix memory leak in cx8802_register_driver() error path [ Upstream commit e228b8b1a5b47a72b265671dc6d864c0da5528d0 ] In cx8802_register_driver(), when drv->probe(driver) fails (non-zero), the allocated cx8802_driver struct is freed neither in the else branch nor later in cx8802_unregister_driver() (which only frees entries that were added to dev->drvlist on success). Each failed probe leaks the driver struct. Add kfree(driver) in the else branch to fix the leak. Signed-off-by: Chen Changcheng Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7554cd67a40233207caa28993a5d9d828c970020 Author: Pengpeng Hou Date: Sat Jul 4 23:01:41 2026 +0800 clk: imx: imx8qxp-lpcg: add missing MODULE_DEVICE_TABLE() [ Upstream commit e89485455ac49925565061733c0d73d568333fc0 ] The driver has a match table for the of bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Reviewed-by: Frank Li Reviewed-by: Brian Masney Reviewed-by: Peng Fan Link: https://patch.msgid.link/20260704150344.59563-1-pengpeng@iscas.ac.cn Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit a2ec55a40da21a20abded935fb01df1878ea299a Author: Pengpeng Hou Date: Sun Jul 5 08:17:05 2026 +0800 clk: imx: imx8qxp: add missing MODULE_DEVICE_TABLE() [ Upstream commit cd21fdcbef3fb32136f72075ab668b075423b3f6 ] The driver has a match table for the of bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Reviewed-by: Brian Masney Link: https://patch.msgid.link/20260705001705.70400-1-pengpeng@iscas.ac.cn Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 9438ed031075a2423fc21bd033b2b57d9532fde1 Author: Nicolin Chen Date: Tue Jul 14 13:55:08 2026 -0700 iommu/tegra241-cmdqv: Rate-limit the error ISR's log message [ Upstream commit a86c36163c9722545d27e92bdad8418fdcaa8b1d ] tegra241_cmdqv_isr() logs the error-map registers on every error interrupt. A malfunctioning device, or a guest deliberately faulting its own VCMDQs, can raise these interrupts rapidly, and the unconditional dev_warn() then floods the kernel log. Rate-limit the message with dev_warn_ratelimited(), and pass the error-map registers straight to it so their four MMIO reads run only when the limiter prints, instead of building the string on every interrupt. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 5bcbc5dfb8bbfa83c6ebcb040474038f5f259503 Author: Bjorn Andersson Date: Thu Jul 23 03:52:29 2026 +0000 remoteproc: Force shutdown during device removal [ Upstream commit 4059c64d78b5d543dabae332922e763b4c95c79e ] rproc_del() is subjected to the reference counted shutdown path, as such a remoteproc with more than one reference will be left running as its resources are released underneath it. Refactor the shutdown path such that the reference count value is ignored when called from rproc_del(). Assisted-by: OpenCode:GPT-5.5 Signed-off-by: Bjorn Andersson Reviewed-by: Pradnya Dahiwale Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-3-546dfd5de0e6@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3243737978f3aa070e98d7a0adbe945c8c898e61 Author: Yichong Chen Date: Mon Jul 27 17:12:14 2026 +0800 exfat: write moved entry before removing source [ Upstream commit 896fcc93574fd511ee04a4110e8ea59d6d8d43d7 ] exfat_move_file() removes the old directory entry before the new entry has been written. If writing the new entry fails, rename returns an error after the source entry has already been marked deleted. Write the new entry first, then remove the old entry and update the cached inode location. This keeps the source entry intact if creating the destination entry fails. Signed-off-by: Yichong Chen Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ea0a6f62eb583d03c3808f5c75b23d63c2bf7781 Author: Jay Vadayath Date: Fri Jul 17 11:40:19 2026 -0700 udf: bound lengthAllocDescs from unallocated space entry [ Upstream commit b8228f59dc58aea06dc024efd8f64c2d048c4578 ] udf_read_inode() copies the on-disk lengthAllocDescs field of a USE (unallocSpaceEntry) inode into iinfo->i_lenAlloc without checking that it fits in the i_data buffer that is subsequently allocated for the inode. udf_count_free_table(), called from udf_statfs(), then walks the allocation descriptor array up to i_lenAlloc bytes, so a crafted UDF image with lengthAllocDescs larger than (blocksize - sizeof(struct unallocSpaceEntry)) causes udf_get_fileshortad() to read past the end of the kmalloc'd i_data buffer. KASAN report from mounting a crafted UDF image and calling statfs() from an unprivileged process: BUG: KASAN: slab-out-of-bounds in udf_get_fileshortad+0x126/0x130 Read of size 4 at addr ffff8880042137d8 by task poc/65 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x610 kasan_report+0xce/0x100 udf_get_fileshortad+0x126/0x130 udf_current_aext+0x3c4/0xa10 udf_next_aext+0x241/0x440 udf_statfs+0xb7d/0x11c0 statfs_by_dentry+0x117/0x1e0 user_statfs+0xac/0x130 __do_sys_statfs+0x80/0xe0 do_syscall_64+0x102/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reject USE inodes whose lengthAllocDescs would place descriptors past the end of the i_data buffer, mirroring the checks the rest of the UDF code performs on descriptor lengths. This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer (and the crafted UDF image) is available on request. Assisted-by: LLM Signed-off-by: Jay Vadayath Link: https://patch.msgid.link/20260717184021.13476-1-jay@artiphishell.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 65bd51927d8d36bf7acb014f85bfd41c55f9364f Author: Jan Kara Date: Mon Jul 27 13:37:12 2026 +0200 udf: Fix bh leak for unallocated space entries [ Upstream commit d95094d4c0a62ea17b8a7c6399b42381b8a55bc0 ] When processing unallocated space entries we didn't properly release the inode bh. Fix it. Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit cb0f7456d550b2a172303766f0cb827528129122 Author: Tyrel Datwyler Date: Wed Jul 22 17:01:20 2026 -0700 scsi: ibmvfc: free ibmvfc_target allocations with mempool_free [ Upstream commit 99143433f7f14139ac373c553ec8e1317d0ae58a ] The ibmvfc_target *tgt structures for discovery are allocated using mempool_alloc but in turn free'd via kfree in ibmvfc_release_target breaking pool guarentees. Fixup ibmvfc_release_target to call mempool_free instead so that memory is properly returned to the mempool instead of the general allocator. Signed-off-by: Tyrel Datwyler Link: https://patch.msgid.link/20260723000149.969416-5-tyreld@linux.ibm.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d2cf7dd54f2fea514be8f7e0d7bae0bc6100e0c5 Author: Tyrel Datwyler Date: Wed Jul 22 17:01:19 2026 -0700 scsi: ibmvfc: check for NULL evt in implicit LOGO and target delete path [ Upstream commit 0122eab60b151d7815f420a91c7315944a037714 ] Unlike ibmvfc_tgt_implicit_logout the ibmvfc_tgt_implicit_logout_and_del path fails to check for a NULL evt returned from ibmvfc_get_reserved_event and passes that directly to ibmvfc_send_event which will unconditionally derefence the evt. Check for a NULL evt and perform same escalation as ibmvfc_implicit_logout. Signed-off-by: Tyrel Datwyler Link: https://patch.msgid.link/20260723000149.969416-4-tyreld@linux.ibm.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1b2f849cd57213c2a8bc6fc76436fa9e8b7a6210 Author: Jiaxing Hu Date: Sat Jul 18 15:11:43 2026 +1200 iommu/rockchip: Clear stale page faults before enabling stall [ Upstream commit b10d5920cafa292ee3cab9c20f813da4fe4f00b8 ] Boot firmware can leave an IOMMU bank in PAGE_FAULT_ACTIVE before the driver has configured paging: PAGE_FAULT_ACTIVE=1 STALL_ACTIVE=0 IDLE=1 Such a bank ignores CMD_ENABLE_STALL and never reaches STALL_ACTIVE, so rk_iommu_enable_stall()'s readx_poll_timeout() spins until it times out (seen on the RK3576 NPU, whose MMUs share this poll across banks). Rather than special-casing these banks in the stall path, acknowledge the stale fault with CMD_PAGE_FAULT_DONE before enabling stall, so every bank starts from a clean state and the normal stall sequence applies to all of them. Banks without a pending fault are untouched. Signed-off-by: Jiaxing Hu Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ebf377dcba5ff34d548b2c6ab524aa337189466f Author: Pengpeng Hou Date: Tue Jun 16 08:43:48 2026 +0800 hsi: omap_ssi: remove debugfs on port creation failure [ Upstream commit 760318e2e69857214314e94ac477219f0c89106b ] ssi_probe() creates the controller debugfs tree before creating the SSI port child devices. If a port device cannot be created, the error path removes any children and tears down the controller, but leaves the debugfs tree behind. Remove the controller debugfs tree on the port creation failure path, matching the normal remove path. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260616004348.97684-1-pengpeng@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ec6a78f9541acd6aa6cfd9cbc56963b44dee631d Author: Tomer Maimon Date: Wed Jul 15 15:29:21 2026 +0300 pinctrl: npcm8xx: move GPIO IRQ setup into request_resources [ Upstream commit b8edfde12e355030e708394c0fa11632559c7ac5 ] npcmgpio_irq_startup() calls pinctrl_gpio_direction_input(), which may sleep while taking the pinctrl core mutex. That makes IRQ startup trip lockdep when CONFIG_PROVE_LOCKING is enabled. Move the direction change into irq_request_resources() and keep startup limited to the ack and unmask operations that are safe in atomic context. Signed-off-by: Tomer Maimon Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 3046577a258700aff4bda98fb8188fa7f5af7d8c Author: Tomer Maimon Date: Wed Jul 15 15:29:23 2026 +0300 pinctrl: npcm8xx: fix debounce register selection [ Upstream commit 602ee6c9447e4382c7e145b26a1c940813f2a144 ] Each DBNCS register programs debounce source selection for 16 GPIOs. The current offset calculation advances the register address every four GPIOs, so offsets 4-15 and 20-31 end up touching the wrong selector register. Advance the DBNCS offset per 16 GPIOs so each line uses the debounce selector bank that matches the hardware layout. Signed-off-by: Tomer Maimon Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6ea28cfe3424b0202d20521d3e7be72d8890f4cb Author: Tomer Maimon Date: Wed Jul 15 15:29:19 2026 +0300 pinctrl: npcm8xx: clear pending GPIO events during init [ Upstream commit cd39cce4cfd499f555eb8b8252636609c3468f57 ] A bank may retain pending event status across resets of the GPIO block. If probe leaves the old state in place, the chained IRQ handler can see spurious events as soon as the irqchip is registered. Disable event generation and clear EVST before wiring each GPIO bank into gpiolib so the driver starts from a known state. Signed-off-by: Tomer Maimon Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d00d165f4cc407ca78cc40373ed64f233d681034 Author: Tomer Maimon Date: Wed Jul 15 15:29:17 2026 +0300 pinctrl: npcm8xx: enable RMII outputs from RMII groups [ Upstream commit c6ccdc305589dd7c7976116e0870a23f291c5fa9 ] NPCM8xx uses GCR_INTCR4 bits to release the R1, R2 and RMII3 transmit outputs from Hi-Z. Those bits need to follow the mandatory r1, r2 and rmii3 pin groups. The R1_OEn, R2_OEn and R3_OEn side groups are optional and should not be required just to enable RMII transmit outputs. Program the INTCR4 bits when the corresponding RMII groups are selected and clear them again when those pins switch back to GPIO or another shared function. Signed-off-by: Tomer Maimon Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 9c9d79cf6b58dc4e45e15d6549b588e9a192400c Author: Pengpeng Hou Date: Tue Jun 16 08:59:01 2026 +0800 firmware: imx: scu: manage mailbox channels and global handle [ Upstream commit 55c748d596f841a18cf659ce0999f64029a5c88c ] imx_scu_probe() requests mailbox channels with the non-managed mbox_request_channel_byname() helper and then publishes sc_ipc through the global imx_sc_ipc_handle. Later probe failures, including child population failure, can leave the channels and global handle live after the probe has failed. Register devres actions to free each mailbox channel and clear the global handle. Also depopulate partially created child devices when devm_of_platform_populate() reports an error. Signed-off-by: Pengpeng Hou Signed-off-by: Frank Li Signed-off-by: Sasha Levin commit a77dc10cccc23cd710e3559b9e0ef0c17fbcbde9 Author: Abdun Nihaal Date: Thu Jul 23 18:14:16 2026 +0530 platform/x86: int1092: Fix info leak in parse_package() [ Upstream commit f5eb833730c071b68a68de5d1df442aae4ae7e6e ] Sashiko reports a possible information leak that can occur as follows: 1. In parse_package(), memory allocated for data->device_mode_info is not zerozed initially as it is allocated with devm_kmalloc_array(). 2. In the for loop after the allocation, a malformed ACPI package provided by firmware can cause some fields in data->device_mode_info to remain uninitialized. 3. Later in update_sar_data(), the uninitialized fields gets copied to the fields of context->sar_data, which can be exposed to userspace through sysfs attribute read (intc_data_show()). Fix the leak by switching to use devm_kcalloc() for allocation. Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260710052806.100107-1-nihaal%40cse.iitm.ac.in Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260723-platx86-v4-2-93b4a178b595@cse.iitm.ac.in Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 2715ac3f0b8e3c04d72ab16555a04a819519b38d Author: Konstantin Komarov Date: Thu Jul 2 13:07:13 2026 +0200 fs/ntfs3: load ATTR_BITMAP run extents from $MFT extension records [ Upstream commit e31886cb6e0e14cf65e27da0bf1a422ff419d893 ] When $MFT's ATTR_BITMAP attribute is heavily fragmented, its run list can span multiple MFT extension records (attribute list entries with vcn > 0). The non-primary segment handler in ntfs_read_mft() only processed ATTR_DATA extension segments for MFT_REC_MFT, silently skipping any ATTR_BITMAP segments. This left sbi->mft.bitmap.run incomplete, causing wnd_init() to fail with -ENOENT when wnd_rescan() tried to look up a VCN not covered by the truncated run list. Observed on a 16 TB NTFS volume (0xFFFFFEFF total clusters) whose MFT bitmap run list was split across 97 extents in extension records. wnd_rescan() successfully looked up VCNs 0-122 from the runs loaded from the base record, then failed at VCN 123 (the last cluster of the bitmap) whose run was only present in an extension record. Fix by extending the MFT_REC_MFT special case to also handle ATTR_BITMAP extension segments, storing their runs into sbi->mft.bitmap.run the same way the primary segment does. Signed-off-by: Senjin Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit cd64f6c8f944aa68fe9dda95a06d09d16c448818 Author: Senjin Date: Sat Jun 13 20:16:14 2026 +0000 fs/ntfs3: fix lseek EINVAL on sparse/compressed files with 64-bit clusters [ Upstream commit 789af83e41aef54c1ff1cee16adc27822e0a0d71 ] When CONFIG_NTFS3_64BIT_CLUSTER is enabled, sbi->maxbytes_sparse is set to -1. As a signed loff_t this is -1LL, the most negative value. Any lseek on a sparse or compressed file passes this as maxsize to vfs_setpos(), which returns -EINVAL whenever offset > maxsize, and since -1LL is less than any non-negative offset, every seek fails, including lseek(fd, 0, SEEK_SET). The intent of -1 here appears to be "no limit" (matching the spirit of MAX_LFS_FILESIZE assigned to sbi->maxbytes and sb->s_maxbytes in the same block), but the signed type makes it the minimum instead of the maximum. Fix by assigning MAX_LFS_FILESIZE to sbi->maxbytes_sparse in the 64-bit cluster path, consistent with the other two limits set there. Observed on a 16 TB NTFS volume with 0xFFFFFEFF total clusters compiled with CONFIG_NTFS3_64BIT_CLUSTER=y. Sequential reads via dd/cp worked correctly; any lseek call on sparse files returned EINVAL, preventing archive managers and other tools from random-accessing files on the volume. The non-64-bit-cluster path correctly sets maxbytes_sparse to (1ull << (cluster_bits + 32)) - 1, a large positive value. Signed-off-by: Senjin Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit a664da9f549dcb62cdf9ac65f794018d57307cb7 Author: Konstantin Komarov Date: Thu Jul 2 13:29:09 2026 +0200 ntfs3: fix info-leak in ntfs_rename() [ Upstream commit 2fa56613b25d0c983ef3ff6d3e865d4254280abe ] Hard to say about copy_to_user_iter(), but at least the first splat looks correct. At the end of fill_name_de(), data layout is: struct NTFS_DE *e = buf; ... |<- data_size + sizeof(struct NTFS_DE) ->|<- XXX ->| buf |----------------------------------------------------------- |<- ALIGN(data_size, 8) + sizeof(struct NTFS_DE) ->| ;; e->size If 'buf' was allocated with kmalloc(), XXX remains uninitialized and passed as such to memcpy() called from hdr_insert_de(). So using kzalloc() for all buffers passed to fill_name_de() looks the simplest and most safe solution. OTOH if someone would have said that an overhead of PAGE_SIZE'd memset() is too large, more fine-granted solution is to memset() XXX only. Reported-by: syzbot+905d785c4923bea2c1db@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=905d785c4923bea2c1db Signed-off-by: Dmitry Antipov Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 2a793f20a7e758cb9cc922af66474985a4277632 Author: Kyle Zeng Date: Thu Jun 11 14:33:31 2026 -0700 fs/ntfs3: reserve NUL byte when converting UTF-16 names [ Upstream commit 4871fedaabbfd574ac0a075b80e75afdd532e11e ] ntfs_utf16_to_nls() appends a trailing NUL to the converted output, but it passes the caller-supplied size directly to the conversion loop. For the UTF-8 path, utf16s_to_utf8s() can legitimately fill all buf_len bytes and return buf_len, after which ntfs_utf16_to_nls() writes the terminator one byte past the end of the destination buffer. The same contract problem exists for the NLS path when a converted character consumes the last available byte. Reserve one byte for the terminator before doing either conversion. The function continues to return the number of converted bytes, excluding the NUL terminator. Assisted-by: Codex:gpt-5.5 Signed-off-by: Kyle Zeng Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 1affb82f183060be09288d3cedd786d9b0763591 Author: Brian Norris Date: Wed Jul 22 16:09:42 2026 -0700 PCI/portdrv: Allow probing even without child services [ Upstream commit 834171efeefffb1a0f2136f32e76669bbc11db86 ] The PCIe port driver fails to probe if it finds no child services, presumably under the assumption that the driver is not useful in that case. However, the driver *can* still be useful for power management support -- namely, it still configures the port for runtime PM / D3, which may be important for allowing a bridge to enter low power modes. Thus, allow probe to succeed even if no IRQs and no child services are available. This also mirrors existing behavior for ports that don't support any portdrv services (PCIe hotplug, AER, DPC, PME, bwctrl), where we'd also probe successfully. This change is a bit more important after commit f5cd8a929c82 ("PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI controller"), because it's common for some DWC-based systems to: 1. have only the "aer" and "pcie_pme" port services available and 2. not define legacy INTx interrupts properly in their device tree. After commit f5cd8a929c82, such systems may fail pcie_init_service_irqs() and so exit with -ENODEV. Link: https://lore.kernel.org/all/nyada24tqwlkzdceyoxbzitzygvp4elvj5oajnqdwb33xkcdwk@76vnrx45fsfd/ Signed-off-by: Brian Norris [bhelgaas: reorder pcie_port_device_register() decls per Lukas] Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Link: https://patch.msgid.link/20260722160942.v4.1.I5fd5d83f518681b3949d8ab2f16ba8244fd3e774@changeid Signed-off-by: Sasha Levin commit 49a49271d6a396e56072c481ce6f1643434fd07d Author: Ruoyu Wang Date: Thu Jun 18 02:22:27 2026 +0800 ntfs3: initialize err in attr_wof_frame_info [ Upstream commit dd64afb32c4d8d3c934ae84df59a2e463d6fa43c ] attr_wof_frame_info() may reuse a cached offsets folio. In that case the loop can fill the output offsets without calling attr_load_runs_range() or ntfs_read_run(), leaving err uninitialized before the common return path. Initialize err to 0 for the successful cached path. Signed-off-by: Ruoyu Wang Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 493f39b7fe9715881c1e4484f96d611b2ddd428f Author: Pengpeng Hou Date: Sat Jul 4 20:18:51 2026 +0800 soc: ixp4xx: qmgr: add missing MODULE_DEVICE_TABLE() [ Upstream commit 01479280fa5d4691013bcd64fdfd935117b69769 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Message-ID: <20260704121851.63805-1-pengpeng@iscas.ac.cn> Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 7460497fe7df9c0bfaf4a30af9d98fd43b531e93 Author: Randolph Sapp Date: Mon Oct 13 12:01:23 2025 -0500 drm/etnaviv: force flush on power register ops [ Upstream commit c182a2ae13886463f7ae36e034449477306d182b ] Add gpu_write_power_sync to verify that power register modifications have reached the endpoint device in sequence specific sections that do not validate device state. These sequence specific areas have been detected experimentally with an am57xx-evm through numerous boot and module load+unload cycles. Signed-off-by: Randolph Sapp Reviewed-by: Lucas Stach Signed-off-by: Lucas Stach Link: https://patch.msgid.link/20251013170122.1145387-2-rs@ti.com Signed-off-by: Sasha Levin commit 4ae6749e29625ea13ab3c01144cdb8713423cc8f Author: Rosen Penev Date: Sun Jul 19 19:02:29 2026 -0700 ata: pata_ep93xx: fix PIO fallback when DMA init fails [ Upstream commit c303c3619a1d5cf7d4b457106062d16724724a80 ] ep93xx_pata_dma_init() returns an error when dma_request_chan() fails, which causes ep93xx_pata_probe() to abort entirely. The probe function already has a PIO fallback path (it checks both channel pointers before enabling UDMA), so the DMA init should not fail the probe on non-fatal errors. Propagate -EPROBE_DEFER, such that we allow the DMA controller driver to load, in case we got probed before the DMA controller driver. For all other failures (e.g. -ENODEV when the DMA controller is missing in the device tree), fall back to PIO. Assisted-by: Opencode:Big-Pickle Signed-off-by: Rosen Penev Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 7a4e9be7b7d163e0fcf36c601c8e7cf540464335 Author: Benjamin Marzinski Date: Mon Jul 6 16:23:24 2026 -0400 bitops: make the *_bit_le functions use unsigned long [ Upstream commit 1c61b0a6e5c472737619f74f79c390363ee258df ] The *_bit_le functions use a signed integer for the bit number. However, the *_bit functions can use an unsigned long. This causes problems if there is a large bitmap and a bit number > 0x80000000 is passed in. Since that is a negative int, it will get sign extended to a long when getting passed to the *_bit function, turning it into a huge bit number. This usually ends up with the memory address wrapping around and the function accessing memory before the start of the bitmap. Avoid this by making the *_bit_le functions take an unsigned long. This can be triggered by faking an almost 4TB dm-mirror device, which uses bitmaps to track the mirror regions: $ dmsetup create bigzero --table '0 8589934590 zero' $ dmsetup create mymirror --table '0 8589934590 mirror core 2 2 nosync 2 /dev/mapper/bigzero 0 /dev/mapper/bigzero 0' This will access memory before the start of the sync_bits bitmap, and likely hit the guard page of the previously allocated clean_bits bitmap, causing a kernel panic with the old code. I looked and didn't see any crazy code using the signed int to intentionally try and access bits before some address within the bitmap. Signed-off-by: Benjamin Marzinski Signed-off-by: Yury Norov Signed-off-by: Sasha Levin commit 3a2b86ccf13e006cb75e584267c9ae95dfaef750 Author: Zhang Yi Date: Tue Jul 14 16:00:36 2026 +0800 ext4: use FGP_WRITEBEGIN for tail block zeroing [ Upstream commit e1cf7b5f5c8ad1e00d00c50c61c3e8fdc79cd422 ] ext4_load_tail_bh() returns a locked folio that callers immediately mutate through folio_zero_range() and mark_buffer_dirty(). Use FGP_WRITEBEGIN so that, on backing devices that require stable writes, __filemap_get_folio() waits for writeback to finish before returning the folio; on regular devices the wait is a no-op. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260714080044.4038124-2-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e860ffebadc944f92cc57f65016da6aa3a6b0351 Author: Zhang Yi Date: Tue Jul 14 16:00:38 2026 +0800 ext4: check return value of ext4_get_block() in ext4_load_tail_bh() [ Upstream commit 705a3fd3bac167f1dabe3d3bba46cd484c5528dd ] ext4_load_tail_bh() ignores the return value of ext4_get_block(), so an I/O or allocation failure is silently discarded. buffer_mapped(bh) stays false and the function returns NULL, which callers such as ext4_block_do_zero_range() treat as "nothing to do" and return success. This can mask real failures during zero-range, truncate, or punch-hole operations, potentially exposing stale data if the block was not actually a hole and needed zeroing. So propagate the error to the callers. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260714080044.4038124-4-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit a51500c4d9ac149984bfe9cd921366f30cb6f4c4 Author: Alexander Wilhelm Date: Fri Jul 3 09:35:38 2026 +0200 wifi: ath12k: fix scan command endianness on big endian [ Upstream commit 6c90f68f97de591e0413f7d2de59449a0388bbab ] ath12k_wmi_scan_req_arg stores scan parameters in CPU-native byte order, while ath12k_wmi_send_scan_start_cmd() writes them into a WMI command buffer whose contents must be in little-endian format. The existing code copies the channel list and writes s_ssid and hint_bssid related values to the command buffer without endian conversion. As a result, scan requests contain invalid parameters on big-endian systems and fail. Convert the channel list as well as the s_ssid and hint_bssid related values to little-endian before writing them to the WMI command buffer. This preserves the existing behaviour on little-endian systems while fixing scan requests on big-endian architectures. Signed-off-by: Alexander Wilhelm Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260703-fix-channel-list-copy-v2-1-372c39306d79@westermo.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 213ba5c52564759585bd351c417c47f5e777b3b8 Author: Manikanta Pubbisetty Date: Fri Jul 10 11:34:06 2026 +0530 wifi: ath10k: trigger hardware recovery upon rx failures [ Upstream commit f78210dd4bea09090b828adc2733cad4b9916306 ] When an error occurs during RX packet processing (e.g., MSDU done failure), the driver sets rx_confused and drops all subsequent RX packets until a Wi-Fi ON/OFF cycle clears the flag. This can leave the device in a bad state where it cannot process RX data traffic. Instead of leaving the device in such a state, trigger hardware recovery so that such an error state can be reset and the device can function again normally. Tested-on: WCN3990 hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189 Signed-off-by: Manikanta Pubbisetty Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260710060406.3323260-1-manikanta.pubbisetty@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit e05a1a4ca1db2c2b00c8bb6cf2a6c0f74fafcc38 Author: Pengpeng Hou Date: Sat Jul 4 09:10:40 2026 +0800 wifi: ath11k: validate regulatory capability phy_id [ Upstream commit f8729a40ebcc94d164be8f154483a21669f3ab52 ] ath11k_wmi_tlv_ext_hal_reg_caps() copies firmware regulatory capability records into soc->hal_reg_cap[] using reg_cap.phy_id as the destination index. The loop count is bounded by num_phy, but the phy_id embedded in each record is not checked against the fixed MAX_RADIOS-sized destination array. Reject firmware records whose phy_id does not fit soc->hal_reg_cap[] before copying the parsed capability. Signed-off-by: Pengpeng Hou Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260704011040.26233-1-pengpeng@iscas.ac.cn Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d4ffdd817e43bae1403ef3430a36e8d776d4222e Author: Jiawen Wu Date: Mon Jul 13 14:04:41 2026 +0800 net: libwx: disable TX VLAN offload for packets with >2 VLAN tags [ Upstream commit f5cfb576ce39ba5647024c6d6eeb5b7a822fab6e ] The current hardware does not support TX VLAN offload for packets with three or more VLAN tags. When such packets are transmitted with hardware VLAN offload enabled, the hardware may malfunction or produce corrupted frames. Add a check in wx_features_check() to parse the VLAN depth of the skb. If more than two VLAN tags are detected (including both the hardware tag and in-band tags), strip NETIF_F_HW_VLAN_CTAG_TX and NETIF_F_HW_VLAN_STAG_TX from the feature set. This forces the kernel networking stack to handle VLAN insertion in software for these specific packets, ensuring correct transmission. Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/069DF89AA8029189+20260713060441.276612-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 823403820ab17f587254aa14d10b465386dbd437 Author: Mukesh Ojha Date: Fri Jul 17 20:16:07 2026 +0530 iommu/qcom: Publish pgtbl_ops before releasing init_mutex [ Upstream commit a05b67cd45ad09a19f41b2d37255da714512e0ca ] qcom_domain->pgtbl_ops was assigned after mutex_unlock(). Another thread calling qcom_iommu_init_domain() would see qcom_domain->iommu already set (domain fully initialized) and skip re-initialization under the mutex. If it then called qcom_iommu_map() before the first thread set pgtbl_ops, it would observe a NULL ops pointer and return -ENODEV for valid mappings. Move the assignment to before mutex_unlock() so that once the mutex is released the domain is fully visible to concurrent operations. Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 79b547ff77c32ef6690c0abe8f24f3a155f2d83a Author: Pengpeng Hou Date: Mon Jun 15 14:52:41 2026 +0800 thermal: intel: int340x: clean up RFIM groups on DVFS failure [ Upstream commit 28f34d7dafa6dfa657efd6760b7c78e98c9b2f6a ] proc_thermal_rfim_add() can create the FIVR and DLVR sysfs groups before creating the DVFS group. If DVFS group creation fails while both earlier groups are enabled, the current error handling removes only one group: the FIVR branch returns before the DLVR cleanup branch can run. This leaves the DLVR group behind even though RFIM setup fails. Use one DVFS failure path that removes all previously created RFIM groups before returning the error. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260615065245.84252-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f8cd002bb33edcd44058dbd6ed895310dc415477 Author: Mukesh Ojha Date: Fri Jul 17 20:16:08 2026 +0530 iommu/qcom: Enable clocks before hardware access in qcom_iommu_ctx_probe() [ Upstream commit cb776a03a53429aa59e25a8cbc3d1a48bd11afdb ] qcom_iommu_ctx_probe() reads and writes the CB_FSR register to clear any stale IRQ left by the bootloader. This happens during devm_of_platform_populate() which is called from the parent device's probe before any pm_runtime_get(). The parent's clocks (iface, bus, tbu) are therefore not guaranteed to be on, making the register access unreliable on rebind or after a suspend cycle. Use pm_runtime_resume_and_get() on the parent device to ensure clocks are enabled before the register access, and release the reference immediately after. Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 34e6afb88d0212e34643b1455d8030ba32034cbc Author: Mukesh Ojha Date: Fri Jul 17 20:16:05 2026 +0530 iommu/qcom: Check pm_runtime_resume_and_get() return in probe [ Upstream commit e910315ae08a23bc953daed10b1c518abac1df49 ] The SMMU_INTR_SEL_NS register write in qcom_iommu_device_probe() uses pm_runtime_get_sync() without checking the return value. If runtime resume fails the subsequent writel_relaxed() would access hardware with clocks potentially disabled. Switch to pm_runtime_resume_and_get() which handles the usage-count cleanup on failure, check the return value, and unwind the already registered iommu device on error. Reviewed-by: Konrad Dybcio Signed-off-by: Mukesh Ojha Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 6a0f6531a327014db8c1afb255e66c25ae4e41f3 Author: Heiko Schocher Date: Tue Jul 21 06:19:32 2026 +0200 drm/panel: simple: Add Kyocera tcg070wvlq panel [ Upstream commit 900517da69afca6f72dacf14278aee3b65275507 ] Commit 922fb2db0287 ("dt-bindings: display: simple: Add Kyocera tcg070wvlq panel") added the compatible string for the Kyocera tcg070wvlq panel to the devicetree bindings documentation (panel-simple.yaml), but the corresponding entry was not added to the panel-simple driver. Add the missing compatible entry to the driver. Signed-off-by: Heiko Schocher Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260721041935.757240-1-hs@nabladev.com Signed-off-by: Sasha Levin commit 4061582141c0d0052e8750498c2afeb2303b099d Author: Esteban Urrutia Date: Sat Jul 11 23:14:01 2026 -0400 iommu/arm-smmu-qcom: Add SM8450 MDSS compatible [ Upstream commit d149c8b2c0146a01f1be326ddb1e182b55aee638 ] Add the compatible for the MDSS client on the Snapdragon 8 Gen 1 so it can be properly configured by the IOMMU driver. Otherwise, there is an unhandled context fault, because the framebuffer is already configured in UEFI. Reviewed-by: Konrad Dybcio Signed-off-by: Esteban Urrutia Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 7a56475bb968c144c3e1fde2809bc5544af4fff6 Author: Baokun Li Date: Mon Jun 8 19:11:48 2026 +0800 ext4: reject mount if clusters/inodes per group are not 8-aligned [ Upstream commit d42dc7726a003262b73ffef2b744ff57a5488799 ] The block and inode bitmap checksums are computed over a whole number of bytes: ext4_inode_bitmap_csum_*() use EXT4_INODES_PER_GROUP(sb) >> 3 and ext4_block_bitmap_csum_*() use EXT4_CLUSTERS_PER_GROUP(sb) / 8 as the length passed to ext4_chksum(). If s_inodes_per_group or s_clusters_per_group is not a multiple of 8, the trailing fractional bits are excluded from the checksum. Those bits are then unprotected, and any incremental csum update path that assumes a byte-aligned bitmap can compute a checksum inconsistent with the full recalculation, corrupting the on-disk bitmap checksum. Reject such filesystems at mount time by adding the missing " & 7" alignment checks alongside the existing range validation. Suggested-by: Theodore Ts'o Link: https://patch.msgid.link/h3n7jlfhyna64dn5o76qxcspnhxdddcs6crpxftmy7gnl7b3sx@jenszfpcsnit Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260508121539.4174601-1-libaokun%40linux.alibaba.com?part=10 Signed-off-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20260608111150.827117-2-libaokun@linux.alibaba.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 131d675880a856791088a72b08421db5d9a70200 Author: Lachlan Hodges Date: Tue Jul 21 15:39:58 2026 +1000 wifi: cfg80211: include cf1 offset when sending chandef [ Upstream commit 5a69b8dffd2a1b06e4cc4c9003c639eb78bac4cd ] The cf1 offset is not included when sending the chandef leading to incorrect channel resolution in usermode. Include it. Signed-off-by: Lachlan Hodges Link: https://patch.msgid.link/20260721053958.227853-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b3bec69dd24dd65f0cfdbf17207f7a43ff5995ef Author: Kuan-Wei Chiu Date: Tue Jul 14 00:24:50 2026 +0000 riscv, bpf: Add support for BPF_MOVSX in RV32 JIT [ Upstream commit c6a08afdfe3a81b1a54e921921e9481dd6c78f8a ] The current rv32 bpf jit compiler incorrectly treats BPF_MOVSX as a standard zero-extended move operation. The bpf instruction set allows sign-extension moves by reusing the BPF_MOV opcode with the instruction offset set to 8, 16, or 32. Update the bpf_jit_emit_insn() function to check the offset field for both ALU and ALU64 MOV operations. If the offset is non-zero, emit the correct slli and srai instructions to perform the sign extension. Before this patch: [ 19.549705] test_bpf: #82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.551354] test_bpf: #83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.552576] test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.553542] test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) [ 19.554807] test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) After this patch: [ 17.931172] test_bpf: #82 ALU_MOVSX | BPF_B jited:1 125 PASS [ 17.932198] test_bpf: #83 ALU_MOVSX | BPF_H jited:1 124 PASS [ 17.933039] test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 124 PASS [ 17.933918] test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 124 PASS [ 17.934751] test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 122 PASS Signed-off-by: Kuan-Wei Chiu Reviewed-by: Pu Lehui Link: https://lore.kernel.org/bpf/20260714002451.4091139-3-visitorckw@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit da882736cbedab84a780b5fc0c8a52ddcee1f95a Author: Pengpeng Hou Date: Sat Jul 4 23:23:36 2026 +0800 power: reset: piix4-poweroff: add missing MODULE_DEVICE_TABLE() [ Upstream commit ffefc5d9a052f67bc87b57d1107fd7cc1fa1a3d4 ] The driver has a match table for the pci bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704152336.51384-1-pengpeng@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 71d4ef0a0b274d7a6e91bb829f970dd9b6bc0a9e Author: Yuyang Huang Date: Sat Jul 11 09:54:02 2026 +0900 net: prestera: ignore duplicate RIF destruction events [ Upstream commit 3cbbc9fa33382d03f2813118e672eb318eba9cde ] During address teardown, the inetaddr notifier may be called multiple times for the same interface. Ignore NETDEV_DOWN events if the RIF has already been destroyed, rather than returning -EEXIST, which aborts the notifier chain. Cc: Ido Schimmel Cc: Kuniyuki Iwashima Signed-off-by: Yuyang Huang Link: https://patch.msgid.link/20260711005405.2861680-2-yuyanghuang@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9fd6abedac7937edf7e9111cbabbd38defd45b75 Author: Aleksander Jan Bajkowski Date: Sun Jul 19 12:01:55 2026 +0200 net: sfp: add quirk for HORACO copper SFP+ module [ Upstream commit 1bb028baab541900d3603d4f93c1c0fb5aba5401 ] Add quirk for a copper SFP+ module that identifies itself as "OEM" "HC-10GE-113C". It uses RollBall protocol to talk to the PHY. Signed-off-by: Aleksander Jan Bajkowski Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260719100158.874882-1-olek2@wp.pl Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 16b873971b929db92ec0cadd9a2eb5d269561ae8 Author: Pengpeng Hou Date: Mon Jun 15 14:31:05 2026 +0800 power: supply: cros_pchg: unregister EC notifier [ Upstream commit 631adfa03595c63b2a621cdc62db60bb1ce5f91c ] cros_pchg_probe() registers an EC event notifier whose callback uses the devm-allocated charger_data via container_of(). The driver has no remove callback and does not unregister the notifier, so the notifier chain can retain a pointer to freed driver state after unbind or probe cleanup. Register a devm cleanup action immediately after the notifier is installed so the notifier is unregistered before the driver state is released. Also fail probe if the notifier cannot be registered, instead of leaving a charger device that cannot receive EC events. Signed-off-by: Pengpeng Hou Reviewed-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260615063105.39152-1-pengpeng@iscas.ac.cn Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 5a83f99967922fb27e2e62b861d0f62bfabcc452 Author: Kuan-Wei Chiu Date: Tue Jul 14 00:24:49 2026 +0000 riscv, bpf: Add support for BPF_SDIV and BPF_SMOD in RV32 JIT [ Upstream commit 2e0fa2389c50fd3a69bb738efa74e127b7516938 ] The current rv32 bpf jit compiler incorrectly treats BPF_SDIV and BPF_SMOD as unsigned operations. The BPF instruction set allows signed division and modulo by reusing the BPF_DIV and BPF_MOD opcodes with the instruction offset set to 1. Update the emit_alu_r32() function to accept an 'is_sdiv' variable and emit the correct div and rem instructions when the offset is 1. Before this patch: [ 44.161771] test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) [ 44.167385] test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) [ 44.171053] test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) [ 44.172081] test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) After this patch: [ 16.002192] test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 95 PASS [ 16.002983] test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 1059 PASS [ 16.017167] test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 136 PASS [ 16.023002] test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 109 PASS Signed-off-by: Kuan-Wei Chiu Reviewed-by: Pu Lehui Link: https://lore.kernel.org/bpf/20260714002451.4091139-2-visitorckw@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit 04f44f6885a58b127afb38f5957a9aa2947f9da1 Author: Thomas Renninger Date: Fri Jul 17 08:51:22 2026 +0200 ACPI: sysfs: Properly map BERT and CCEL data to their ACPI tables [ Upstream commit e45ee607ca6f9f97a2f97be356d844a912971a16 ] In the case of multiple BERT ACPI tables, one gets: sysfs: cannot create duplicate filename '/firmware/acpi/tables/data/BERT' This is because both: /firmware/acpi/tables/BERT1 /firmware/acpi/tables/BERT2 are attempted to be mapped to the same data table: /firmware/acpi/tables/data/BERT Address this problem by passing and using the same filename for data tables. Signed-off-by: Thomas Renninger Reported-by: Michal Suchanek Closes: https://bugzilla.suse.com/show_bug.cgi?id=1270211 [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260717065129.72924-3-trenn@suse.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit a6caf23bbbd01dfb33d121a6293ac93b5b329983 Author: Zhao Li Date: Thu Jul 9 03:59:04 2026 +0800 wifi: mac80211_hwsim: clear PMSR request state on abort [ Upstream commit 37a77bd1395e8261d1760ae39c7f5eb637300550 ] mac80211_hwsim saves the in-flight cfg80211 PMSR request and its wdev in data->pmsr_request / data->pmsr_request_wdev when a measurement starts, and clears them only when it reports completion. mac80211_hwsim_abort_pmsr() never cleared that saved state. cfg80211 owns the request and frees it once the abort callback returns (cfg80211_pmsr_process_abort() calls rdev_abort_pmsr() then kfree(req)), so after an abort data->pmsr_request dangles. A later hwsim PMSR report then dereferences the freed request in hwsim_pmsr_report_nl() and completes it; a use-after-free. Clear data->pmsr_request and data->pmsr_request_wdev once the abort matches the active request. Move the wmediumd/virtio notification check below the clear so the saved state is dropped even when no notification is sent. Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260708195911.84365-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6e0ea620b21961a82fbce5a006c7d8e34de0e952 Author: Shahar Tzarfati Date: Wed Jul 15 21:27:43 2026 +0300 wifi: mac80211: ibss: read deauth reason_code after frame length check [ Upstream commit aa4c0a649903567762edf2bbc7fff608953b3ca4 ] The function was reading reason_code from the frame before validating that the frame is at least IEEE80211_DEAUTH_FRAME_LEN bytes long. Move the reason_code read to after the length check so the field is guaranteed to be present before it is accessed. Signed-off-by: Shahar Tzarfati Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715212706.db26604650bd.I2caa73c396b8c9d357224b9334d5df3cafac498e@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6166f19a699540a7ef8bf424df6c192813b2344a Author: Yun Zhou Date: Tue Jun 23 14:19:03 2026 +0800 ext4: set EXT4_STATE_NO_EXPAND in ext4_evict_inode [ Upstream commit 2c0e4fb511f97467dafc91b6afb3414100289081 ] An inode being evicted will never need its extra isize expanded. Set EXT4_STATE_NO_EXPAND before ext4_mark_inode_dirty() in ext4_evict_inode() to make this explicit and prevent any unnecessary work in ext4_try_to_expand_extra_isize(). This also provides defense-in-depth for the s_writepages_rwsem deadlock during mount-time orphan cleanup, ensuring the expand path is blocked for inodes under eviction regardless of how they are reached. Signed-off-by: Yun Zhou Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260623061903.2148767-2-yun.zhou@windriver.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 72b2bf5592438867fd25cdadd46d42d00fb7ab41 Author: Ali Alaei Date: Sun Jun 28 16:34:50 2026 +0200 PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX [ Upstream commit 72b32eccbcd591b9606edacf3bd7c455176d7660 ] On Intel Arrow Lake-HX systems (e.g. Core Ultra 9 275HX on Acer Predator PH16-73), the VMD controller reports BUS_RESTRICT_CFG = 3 in the VMCONFIG register. The existing switch statement only handled values 0, 1, and 2, causing vmd_get_bus_number_start() to return -ENODEV and aborting the entire VMD probe. This leaves NVMe drives behind the VMD controller invisible to the kernel. Hardware registers (VMCAP/VMCONFIG at offsets 0x40/0x44): VMD 0000:00:0e.0 (8086:ad0b): VMCAP=0x000f, VMCONFIG=0x03b8 BUS_RESTRICT_CFG(0x03b8) = (0x03b8 >> 8) & 0x3 = 3 Add cfg=3 as a fallthrough to cfg=2, setting busn_start=224, which is the correct bus number base for this hardware. Also add a PCI_POSSIBLE_ERROR() guard after reading VMCONFIG: a failed config space read returns 0xFFFF, and BUS_RESTRICT_CFG(0xFFFF) = 3, so without this guard a removed or errored device would falsely match the new case 3 instead of being caught as an error. Reported-by: Lin Mohan Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221137 # Arrow-Lake-S Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221136 # Arrow-Lake-S Signed-off-by: Ali Alaei Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260628143450.92492-1-ali.alaei.tabatabaei@gmail.com Signed-off-by: Sasha Levin commit dc40b64d04f80fee740f322a969593f4b5d44dff Author: Baokun Li Date: Mon Jun 8 19:11:49 2026 +0800 ext4: reduce max cluster size to match documented 256MB limit [ Upstream commit afa3caf2fbc417f755f36e271c4b3c2d45ccda9d ] The mke2fs man page documents: Valid cluster-size values are from 2048 to 256M bytes per cluster. but EXT4_MAX_CLUSTER_LOG_SIZE was set to 30 (1GB), allowing crafted filesystem images to specify cluster sizes up to 1GB. On 32-bit systems with bigalloc enabled, the consistency check in ext4_handle_clustersize(): s_blocks_per_group == s_clusters_per_group * (clustersize / blocksize) can overflow when the cluster ratio is large enough. Since s_blocks_per_group is not range-checked in the bigalloc path, the wrapped product can pass the consistency check, leading to inconsistent group geometry and potential out-of-bounds block allocation. Reduce EXT4_MAX_CLUSTER_LOG_SIZE to 28 to match the documented 256MB limit. With this cap, the maximum product is: (blocksize * 8) * (256M / blocksize) = 2^31 which fits safely in a 32-bit unsigned long for all block sizes. Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260608061112.392391-1-libaokun%40linux.alibaba.com Signed-off-by: Baokun Li Reviewed-by: Andreas Dilger Link: https://patch.msgid.link/20260608111150.827117-3-libaokun@linux.alibaba.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 745d9352ec80a76ca7e25f304c65ce69c9f1ec14 Author: Yap Weei Choong Date: Fri Jul 17 14:07:45 2026 +0800 platform/x86/amd/pmc: Add T14 Gen2 AMD (20XL) to s2idle quirk list [ Upstream commit e25fb2258bddbcf70df69d1358be3e1274bdc5f2 ] The ThinkPad T14 Gen 2 AMD was sold under two machine types, 20XK and 20XL, but only 20XK has been in the s2idle quirk list since the quirk was introduced in commit 455cd867b85b ("platform/x86: thinkpad_acpi: Add a s2idle resume quirk for a number of laptops"). On 20XL machines the firmware SMI handler therefore still runs on the NVMe D3->D0 transition when exiting suspend-to-idle. With IOMMU translation enabled (the default), this intermittently stalls resume for ~10.25 seconds: seven devices across three root ports (nvme, both xhci_hcd functions, xhci-pci-renesas, snd_hda_intel x2, snd_rn_pci_acp3x) block in pci_pm_resume_noirq and are released simultaneously, consistent with all cores being held in SMM. Add the missing 20XL machine type, mirroring the existing 20XK entry. This is the same class of omission fixed by commit 9a469c6dfab3 ("platform/x86: thinkpad_acpi: Add missing T14s Gen1 type to s2idle quirk list"). Verified on a ThinkPad T14 Gen 2a (type 20XLS41C00, BIOS R1MET62W 1.32, kernel 6.12.95): with this entry the quirk message appears at probe and a 14-hour suspend resumes in ~1s with no noirq stalls, where previously even short suspends could hit the ~10s delay. A further two-day soak (short naps and two ~14-hour suspends) showed every resume clean. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221755 Signed-off-by: Yap Weei Choong Tested-by: Yap Weei Choong Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260717060744.1252065-2-ywc8891@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit c3023181ec3ef1eaab7881be6dfa4772bfc965d5 Author: Kate Hsuan Date: Fri Jul 10 20:51:22 2026 +0800 ACPI: battery: Sanitise model_number by dropping unprintable characters [ Upstream commit 6587dd87595cfae6bf1304cd0cd1df2274424e42 ] The battery Embedded Controller (EC) may return the model name with trailing unprintable or non-ASCII characters. For example, on some systems: $ cat /sys/class/power_supply/BAT0/model_name LNV-5B10W51864�� If a non-ASCII or an unprintable character is found, it will be replaced with '\0' to ensure the model_number is a valid string. If left intact, the malformed string prevents udev rules and hwdb working correctly. Link: https://gitlab.freedesktop.org/upower/upower/-/work_items/345 Signed-off-by: Kate Hsuan Reviewed-by: Mark Pearson [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260710125122.1621877-1-hpa@redhat.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 45083910bc256ea3032cd2691685e8d162f980e5 Author: Pengpeng Hou Date: Mon Jul 6 17:41:41 2026 +0800 ACPI: FPDT: validate table and record lengths [ Upstream commit 458b40fcdd04a9a0334830de5a536d8425454e4b ] FPDT records are supplied by firmware and are walked through length fields stored in the table itself. Check the main-table entry length before reading an entry, check the mapped subtable length before remapping it, and check each record length before saving a typed record pointer for sysfs. This keeps malformed firmware records from being interpreted as complete resume, suspend, or boot records when the current item is shorter than the structure consumed by the driver. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706094141.82438-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c9aacd7db81326b34ca70d0dc403762218c4ef7e Author: Bob Song Date: Fri Jul 17 10:49:48 2026 +0800 ALSA: hda: Check snd_hda_power_pm construct error before executing verb [ Upstream commit df27e4dc80c4a30ad206432cb848aab00de22ca7 ] When userspace writes 1 to /sys/bus/pci/devices/XX/remove to remove HDA PCI device, the HDA hardware control path is shut down and devres unmaps the BAR virtual address bus->remap_addr automatically during driver removal. If a delayed HDA verb command arrives after the MMIO region is unmapped, the driver will access invalid virtual addresses and trigger a page fault splat. So add an error check right after constructing snd_hda_power_pm. Signed-off-by: Bob Song Link: https://patch.msgid.link/20260717024948.506335-1-songxiebing@kylinos.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 996766054b8870b73bc804a061fe90e80c241484 Author: Nizar Al-Kabbani Date: Sun Jul 19 12:08:43 2026 +0300 platform/x86: asus-nb-wmi: map ProArt key (0x8b) to KEY_PROG3 [ Upstream commit 6303451189a6d8f304221065c44ccd597e0acbe5 ] The dedicated "ProArt" key on the ASUS ProArt PX13 (HN7306) emits ASUS WMI event code 0x8b. This code is absent from the asus-nb-wmi sparse keymap, so pressing the key only produces a "Unknown key code 0x8b" message and does nothing in userspace. On this model the key is exposed solely through the WMI interface and has no HID scancode, so it can only be handled inside asus-nb-wmi. Map 0x8b to KEY_PROG3 so the key emits a bindable event, consistent with the existing KEY_PROG3 mapping used for the ASUS programmable/Armoury key. Signed-off-by: Nizar Al-Kabbani Reviewed-by: Denis Benato Link: https://patch.msgid.link/20260719090843.66777-1-nizar.m.kabbani@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 5e1f73e1c34d0f50d2be0369a141ac92c5f976bd Author: Dio Zhang Date: Mon Jul 20 10:53:58 2026 +0800 drm/panel: panel-edp: Adjust T8 timing for AUO B116XAK01.6 and B140XTK02.4 [ Upstream commit 0d40cab39158704e372240ed9821a00bfe117125 ] Screen garbage or flickering can be observed during mode changes (such as VT switches) on systems using the AUO B116XAK01.6 and B140XTK02.4 panels. This occurs because the backlight is enabled before the video signal stabilizes. Waveform measurements show that the panel signal takes around 140ms to stabilize after a mode change, meaning the previous 50ms T8 timing was insufficient. To resolve this issue, adjust the eDP panel delay entry from delay_200_500_e50 to delay_200_500_e200 (increasing T8 from 50ms to 200ms). This matches the updated panel specifications from AUO, which now formally define T8 as 200ms to mask any display abnormalities during mode changes. Signed-off-by: Dio Zhang Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260720025358.2781136-1-dioyc_zhang@compal.corp-partner.google.com Signed-off-by: Sasha Levin commit 5f9d81c7144f4a0cce0a36e4ba4e45cb3abb529e Author: Yousef Alhouseen Date: Tue Jun 30 12:50:15 2026 +0200 media: go7007: s2250: propagate control I/O failures [ Upstream commit 59dc14a6cb5ff1ae5ce2f6ebf51fe0139e1c0623 ] The brightness and contrast paths use oldvalue after read_reg_fp() without checking whether the read succeeded. A failed read leaves oldvalue uninitialized and can write arbitrary reserved register bits. Return read and write errors from every control path so failed hardware access cannot be reported as a successful control update. Signed-off-by: Yousef Alhouseen Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c023ae2228cfa00fbd2a81c7b41d570f2e952930 Author: Rituparna Warwatkar Date: Tue Jul 14 16:10:59 2026 +0200 media: dvb-core: fix feed leak on failed DMX_ADD_PID [ Upstream commit 9fa26c971ca310dd10a3bc0014f2fc7ea7167bba ] dvb_dmxdev_add_pid() allocates a new dmxdev_feed, links it into filter->feed.ts and, when the filter is already running, immediately starts the feed. If starting the feed fails, the newly allocated feed remains on the list. Subsequent restart and rollback paths may then operate on this stale entry, leaving feed resources allocated and causing leaks in drivers that allocate resources from ->start_feed() and release them from ->stop_feed(). Remove the feed from the list and free it when dvb_dmxdev_start_feed() fails. Reported-by: syzbot+e9a1f5e196de6663631b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e9a1f5e196de6663631b Signed-off-by: Rituparna Warwatkar Link: https://patch.msgid.link/20260714141059.63582-1-rwarwatkar@gmail.com Signed-off-by: Mauro Carvalho Chehab Message-ID: <20260714141059.63582-1-rwarwatkar@gmail.com> Signed-off-by: Sasha Levin commit b571ade3a064213bc1d516ae073e58fd09cf8add Author: Emmanuel Grumbach Date: Fri Jul 17 17:31:07 2026 +0300 wifi: iwlwifi: mvm: ignore sync frames when sync is disabled [ Upstream commit a790f60cc4d7dc64a2d7cadb94a3d9f60392bed4 ] Gate time-sync frame interception on the active flag so frames are not queued after time-sync teardown. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260717172958.ac73ee199a25.Ic1489244f9b02da93060f0a0e5b300a73527f265@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 9e458e80d21d366a3f166145709dd73e896081bb Author: Ayala Beker Date: Fri Jul 17 17:31:08 2026 +0300 wifi: iwlwifi: mld: drop connection on D3 resume failure [ Upstream commit 4f5384b58b483e4aec576ce461dec45b41df18db ] When FW crashes on D3 exit, iwl_mld_nic_error() sets STATUS_RESET_PENDING and queues restart wk, but mac80211's resume callback synchronously calls iwl_trans_stop_device() which clears the flag. As a result restart wk skips sw_reset, and the FW error recovery buffer is never read. The new FW boots with empty BA state and initial sequence numbers, while the AP still holds its A-MPDU RX reorder window. This causes MPDUs to be dropped as IWL_RX_MPDU_REORDER_BA_OLD_SN until ADDBA is renegotiated. We don't know how long the firmware has been in an error state or whether the AP still considers us associated, so keeping the connection alive is not worth it. Call ieee80211_resume_disconnect() when iwl_mld_wait_d3_notif() fails, and let userspace reassociate. Signed-off-by: Ayala Beker Reviewed-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260717172958.3e10c8498f53.Icf5644b42d79e984ecc16abfa873bd37f611e778@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit d2554d9bd3ecd73ab0cb67b5b2bb22b00d881bfb Author: Emmanuel Grumbach Date: Fri Jul 17 17:31:05 2026 +0300 wifi: iwlwifi: mld: validate wake packet crypto overhead [ Upstream commit c5cb9dd220ba9fdcf4ba485ce3d1d36ca32ac00b ] Wake packet parsing only accounted for FCS and missed per-key IV/ICV overhead for protected data frames. Prevent size underflow and bad packet trimming when notifications are malformed or truncated. Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260717172958.e06595623533.Ie09494b7e34e5872b750fd90e325648ee469d0da@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit b7e3bcd3b2a162669ca571e43e49a75b75257c66 Author: Aditya Sherawat Date: Fri Jul 10 00:12:00 2026 +0530 drm/msm/adreno: Add support for A704 GPU [ Upstream commit 1f69339da06255a7f8560b4768fff83992c03deb ] Adreno A704 GPU found in Shikra is an IP reuse of A702 GPU with very minimal changes. The only KMD facing difference is the chipid and the zap firmware which is specified via devicetree. Just add the new chipid to enable support for A704 GPU in Shikra. Signed-off-by: Aditya Sherawat Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/738931/ Message-ID: <20260710-shikra-gpu-v6-1-b388ec5dce77@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 5528da68628d2f26e1fd37b2f37b64e58d4a4612 Author: Yuho Choi Date: Mon Jun 8 13:27:17 2026 -0400 driver core: attribute_container: Unwind device_add() on attr failure [ Upstream commit 8cfe7ad274bb42c4653b645267410d4a3a23db98 ] attribute_container_add_class_device() first calls device_add() and then creates the container attributes. If attribute_container_add_attrs() fails, the helper returns the error with the class device still registered. Callers use an error from this helper as a failed add and do not call device_del() on that path. Undo the successful device_add() before returning the attribute creation error. Signed-off-by: Yuho Choi Link: https://patch.msgid.link/20260608172717.88657-1-dbgh9129@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6f244ea2fafa4303365ce3a3781453d1be640819 Author: Logan Gunthorpe Date: Tue Jul 14 15:20:10 2026 -0600 PCI: switchtec: Add Microchip PCI1008 to NTB DMA alias quirk [ Upstream commit 00a479ba1d01249d43ca5e453380d1ed60946f8a ] Add the PCI1008 device ID to the quirk_switchtec_ntb_dma_alias PCI fixup table. Without it, DMA transactions from a PCI1008 switch's NTB function are not given the correct requester ID alias, which can misdirect them under an IOMMU. Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260714212010.230606-4-logang@deltatee.com Signed-off-by: Sasha Levin commit a1474ca79993349f7f206ded56469f0fcc98ca3f Author: Logan Gunthorpe Date: Tue Jul 14 15:20:09 2026 -0600 PCI: switchtec: Add Microchip PCI1008 device ID [ Upstream commit 0d8a6306c680ee534be131e360f0cafa2bada7be ] Add the Microchip PCI1008 device ID to the core switchtec management driver's PCI ID table. Without it, the management endpoint on a PCI1008 switch is not bound by this driver, preventing userspace tools from configuring or monitoring the switch and leaving NTB functionality unavailable. Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260714212010.230606-3-logang@deltatee.com Signed-off-by: Sasha Levin commit 62a24f902e8ceb55df5397bb3da26665d124535c Author: Yousef Alhouseen Date: Wed Jun 24 19:51:39 2026 +0200 misc: ibmvmc: reject oversized inbound messages [ Upstream commit 18189e5d84aa0b3bc89189cba13b9105634cb6fb ] ibmvmc_recv_msg() trusts the message length from the CRQ. It passes that length directly to h_copy_rdma(). The destination buffer is only max_mtu bytes. A larger length can overrun it before userspace reads the message. Validate the CRQ length before issuing the RDMA copy. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260624175139.7981-1-alhouseenyousef@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 97193b096581dcb4a9cc630e84cdb27a092d23e6 Author: Pei Xiao Date: Wed Jul 1 10:01:10 2026 +0800 ipack: ipoctal: add rwsem to guard against TOCTOU in remove path [ Upstream commit 7d3a708af7f4e2af9e114d731bd60d30c1ec884e ] The "removed" flag check in each tty op has a TOCTOU race with __ipoctal_remove(): the device could be removed between the flag check and the subsequent access to hardware resources (channel registers via iowrite8, or xmit_buf in write_tty). Close this race by introducing a read-write semaphore (remove_sem). The tty ops acquire the read lock via guard(rwsem_read) for the full duration of the operation, while __ipoctal_remove() acquires the write lock via scoped_guard(rwsem_write) when setting the removed flag. This ensures that once removed is true, no in-flight tty op can still be accessing resources that are about to be freed by the remove path. Signed-off-by: Pei Xiao Link: https://patch.msgid.link/fbce75010a0f0a3a3709a5e06fd0ffd19ca0a0ed.1782870760.git.xiaopei01@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 61d91a89e1364bee57531d4e0b9efb8762d1a054 Author: Yousef Alhouseen Date: Wed Jun 24 20:59:25 2026 +0200 misc: ibmvmc: release send buffer on write errors [ Upstream commit fd62c1f591372f7dc4c5bc041569c2f0a4a86be1 ] ibmvmc_get_valid_hmc_buffer() marks the selected send buffer busy before ibmvmc_write() validates the backing storage or copies data from user space. Error exits after that point leave the buffer permanently busy. Keep the buffer pointer until ownership is handed to the hypervisor, and mark it free again on local write failures. Also report an RDMA send failure instead of returning a successful byte count. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260624185925.2133-1-alhouseenyousef@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit afcf127aa07d98955a0cfe7e24204b2d6e528db8 Author: Pengpeng Hou Date: Mon Jul 6 17:19:35 2026 +0800 greybus: manifest: validate string descriptor header [ Upstream commit 18b6510f642dbcb856c3af8be974d1600f3ba2d3 ] identify_descriptor() computes a string descriptor size from desc->string.length. Require the descriptor to contain the fixed string descriptor header before reading the variable string length. The existing descriptor-size check then reports the short descriptor. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706091935.78020-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bc01e7408d8ab422fbeb8a91bc8cd7db409d44de Author: Pengpeng Hou Date: Tue Jun 16 23:10:28 2026 +0800 misc: rp1: clear chained IRQ handlers on teardown [ Upstream commit 82aa033fef523ab4f0165afbc1c1fb0dadb89f94 ] rp1_probe() installs a chained handler for each parent MSI-X vector and stores the rp1 device pointer as handler data. rp1_unregister_interrupts() then disposes the child IRQ mappings, removes the IRQ domain, and frees the PCI IRQ vectors without first removing those chained handlers. If a teardown path runs after the handlers have been installed, a later parent IRQ can still call rp1_chained_handle_irq() with stale handler data and a removed IRQ domain. Clear the chained handlers before disposing mappings and freeing the vectors. Signed-off-by: Pengpeng Hou Reviewed-by: Andrea della Porta Link: https://patch.msgid.link/20260616151028.69890-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e1a03a65162b404dff093fc07f7ad9b403cecd97 Author: Yousef Alhouseen Date: Wed Jun 24 21:09:19 2026 +0200 misc: hpilo: validate device queue entries before use [ Upstream commit 7bf6940d7cf41f1f0330a9bae4b7a886e18fd8e3 ] ilo_pkt_dequeue() trusts descriptor IDs and lengths read from the shared FIFO entry. A bad entry can select a descriptor outside the allocated queue memory or report a packet length larger than one descriptor. Reject entries whose descriptor index or packet length exceeds the queue layout before deriving the packet pointer returned to read and write paths. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260624190919.3432-1-alhouseenyousef@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fc586ea5441086d518d7e3f4201b61b050e1f3a2 Author: Yousef Alhouseen Date: Tue Jun 30 12:49:23 2026 +0200 misc: genwqe: handle a first DMA address of zero [ Upstream commit d401772a9e18e837631450844f835229354528a4 ] genwqe_setup_sgl() uses zero as the initial previous DMA address. DMA address zero is valid, so a first entry at that address enters the merge path before last_s has been assigned and dereferences NULL. Only merge adjacent mappings after an SGL data entry has been created. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260630104923.53827-1-alhouseenyousef@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cfe59571ce974bc93361f9b67b67f141b0dfa41e Author: Yousef Alhouseen Date: Mon Jun 29 18:06:05 2026 +0200 misc: bcm-vk: validate write size before allocation [ Upstream commit f66c40cd90954f52809b3eabd386137f56bb6215 ] bcm_vk_write() uses the user-supplied write count to size a flexible-array work entry and then copies count bytes into that array. The allocation expression is evaluated before any overflow check, so a very large count can wrap the allocation smaller than the subsequent copy. Reject empty writes, check the allocation arithmetic before kzalloc(), and initialize the __counted_by field before copying into to_v_msg[]. Signed-off-by: Yousef Alhouseen Link: https://patch.msgid.link/20260629160605.29412-1-alhouseenyousef@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 833c44918f919fe9e1727df24eed07eaf7fbd52b Author: Ian Abbott Date: Thu Jun 18 11:09:17 2026 +0100 comedi: pcmuio: Add sanity check to interrupt handler [ Upstream commit 6f6f6644e011fa910db744e9978127a443b94001 ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, check the dev->attached flag in the interrupt handler pcmuio_interrupt() to ensure the device has been fully set up, avoiding a possible null pointer dereference of dev->subdevices by pcmuio_handle_asic_interrupt(). Also make use of the IRQ_HANDLED(x) macro for the normal return path of the interrupt handler. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-11-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 52e7dfa88e395f6c4cd6f6d650f5a5f37a32068b Author: Ian Abbott Date: Thu Jun 18 11:09:14 2026 +0100 comedi: pcm816: Fix sanity check in interrupt handler [ Upstream commit 4fdac5090ce3616283216d9a1d2b9664e8e20747 ] The driver requests an interrupt handler for the device before it is fully set up. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing the devpriv->dma pointer which may be NULL if dev->attached is false. Move the dereference of the devpriv->dma pointer after dev->attached has been checked to avoid the possible null pointer dereference. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-8-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7fbcd6f65358607a666d6c8d3eba1d8608550d8b Author: Ian Abbott Date: Thu Jun 18 11:09:16 2026 +0100 comedi: pcmmio: Add sanity check to interrupt handler [ Upstream commit ea72e2fc9026f375314421ddfa4dbdc49432a899 ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, check the dev->attached flag in the interrupt handler to ensure the device has been fully set up, avoiding a possible null pointer dereference of dev->read_subdev. Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/lkml/20260610115912.780131-1-jjy600901@snu.ac.kr/ Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-10-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7beb6ca2f3ffdf097bddbff0dbf7c92f5aa743f9 Author: Ian Abbott Date: Thu Jun 18 11:09:08 2026 +0100 comedi: aio_iiro_16: Add sanity check to interrupt handler [ Upstream commit 1ca44751915134f19e8627768159781e75b5da50 ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, check the dev->attached flag in the interrupt handler to ensure the device has been fully set up, avoiding a possible null pointer dereference of dev->read_subdev. Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/lkml/20260610115912.780131-1-jjy600901@snu.ac.kr/ Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-2-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ce0aea8f724bd2331d1848aa87fa82ffc9a1b3ca Author: Ian Abbott Date: Thu Jun 18 11:09:13 2026 +0100 comedi: pcm711: Fix sanity check in interrupt handler [ Upstream commit f876cbfe3e066bc9e3f3210907bd534be82946c8 ] The driver requests an interrupt handler for the device before it is fully set up. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing the dev->read_dev pointer which may be NULL if dev->attached is false. Move the check to avoid the possible null pointer dereference. Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/lkml/20260610115912.780131-1-jjy600901@snu.ac.kr/ Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-7-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 83b49a8dacfc211b30c7259c3be63d008683e50b Author: Ian Abbott Date: Thu Jun 18 11:09:10 2026 +0100 comedi: dt2811: Fix sanity check in interrupt handler [ Upstream commit 8dda63825752ab19fcbc2a19ecab91d128112415 ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing dev->read_subdev, which may be NULL if dev->attached is false. Move the check to avoid the possible null pointer dereference. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-4-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 27c6696abcce11e67efdf1dadf855f5e1c80caeb Author: Ian Abbott Date: Thu Jun 18 11:09:09 2026 +0100 comedi: das6402: Add sanity check to interrupt handler [ Upstream commit e90d0550c5b3056c8821f5cd714f80902de0fca6 ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, check the dev->attached flag in the interrupt handler to ensure the device has been fully set up, avoiding a possible null pointer dereference of dev->read_subdev. Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/lkml/20260610115912.780131-1-jjy600901@snu.ac.kr/ Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-3-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9fbe69c3ba2af15030f54c4cc5e95c45c5e2a2c8 Author: Ian Abbott Date: Thu Jun 18 11:09:18 2026 +0100 comedi: quatech_daqp_cs: Fix sanity check in interrupt handler [ Upstream commit 1bc9538df6be8dac8727179d8bcc0d880648361b ] The driver requests an interrupt handler for the device before it is fully set up. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing the dev->read_dev pointer which may be NULL if dev->attached is false. Move the check to avoid the possible null pointer dereference. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-12-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1b077ad73af7d17f574035c3974431198fec74e1 Author: Ian Abbott Date: Thu Jun 18 11:09:15 2026 +0100 comedi: pcm818: Fix sanity check in interrupt handler [ Upstream commit 956e8478261a575d1e87490f2e5db1788b8c209d ] The driver requests an interrupt handler for the device before it is fully set up. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing the dev->read_dev pointer which may be NULL if dev->attached is false. Move the check to avoid the possible null pointer dereference. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-9-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6c5a43d797addaac4b044a188fbb13c21023d091 Author: Ian Abbott Date: Thu Jun 18 11:09:11 2026 +0100 comedi: ni_at_a2150: Fix sanity check in interrupt handler [ Upstream commit e7356cdc7077a4f30fc5232a18e9fc6a4d404581 ] The driver requests an interrupt handler for the device before it is fully set up. For safety, the interrupt handler checks the dev->attached flag to ensure the device is fully set up, but it currently does that after dereferencing various pointers which may be NULL if dev->attached is false. Move the check to avoid the possible null pointer dereferences. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-5-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a7300663fa0e033c03920537d00fdbdc4a604a51 Author: Ian Abbott Date: Thu Jun 18 11:09:12 2026 +0100 comedi: ni_atmio16d: Add sanity check to interrupt handler [ Upstream commit 13f4796223489a5349b466ce54bb868f46c9fefd ] The driver requests an interrupt handler for the device, after setting device registers to disable interrupt generation. The interrupt handler should not be called prematurely unless the user-configured I/O port base address and/or IRQ number are incorrect or the hardware is bad. For safety, check the dev->attached flag in the interrupt handler to ensure the device has been fully set up, avoiding a possible null pointer dereference of dev->read_subdev. Reported-by: Jaeyoung Chung Link: https://lore.kernel.org/lkml/20260610115912.780131-1-jjy600901@snu.ac.kr/ Reported-by: Sangyun Kim Reported-by: Kyungwook Boo Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260618102949.26607-6-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1b432b8013855c531c6cf8c0b5693c9571ebe7eb Author: Pengpeng Hou Date: Sat Jul 4 23:26:42 2026 +0800 uio: sercos3: add missing MODULE_DEVICE_TABLE() [ Upstream commit a432f68c51fc6761658445e80a798b8425fdb3dc ] The driver has a match table for the pci bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704152642.54769-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 55836402fc5192a46b36b6f62f11ca5bdc2d4a7b Author: Michail Tatas Date: Fri Jul 17 01:24:13 2026 +0300 USB: misc: uss720: Fix leak in get_1284_register [ Upstream commit 15902712b9e2a46649cba2f22002d05faec2a990 ] if wait_for_completion_timeout() times out in get_1284_register() then we do not destroy the reference acquired via kref_get() in submit_async_request. Add the missing kref_put in the timeout path. link: https://syzkaller.appspot.com/bug?extid=56962eb32ba0136cd330 Reported-by: syzbot+56962eb32ba0136cd330@syzkaller.appspotmail.com Signed-off-by: Michail Tatas Link: https://patch.msgid.link/allaDTUua9n5DQ0a@michalis-linux Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7277d38c00bd3e2d5904778e9001b5817f2b3009 Author: Oliver Neukum Date: Fri Jul 10 11:55:18 2026 +0200 usb: misc: cypress_cy7c63: check result of IO [ Upstream commit 0673b919e0933541ae56bb3f0253853f696d3773 ] If the device returns a bogus short read, treat it as EIO. Actually check for IO errors. Signed-off-by: Oliver Neukum Link: https://patch.msgid.link/20260710095523.1646308-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 148fcb7faf16e0c9b08afa62734a1e95a11309f5 Author: Lucas Martins Alves Date: Tue Jul 14 13:49:49 2026 +0000 usb: musb: host: clear stale RX interrupt on three-strikes error [ Upstream commit 3a3a48487344a653f46a4aadc9ba296386eb3541 ] Unplugging a busy USB Ethernet adapter can leave a stale RX interrupt pending while the host handles MUSB_RXCSR_H_ERROR. On AM335x/DSPS platforms this can retrigger the same three-strikes error before the disconnect path completes, flooding the log and potentially leaving the host port stuck until reboot. Clear the pending endpoint RX interrupt when aborting the transfer so the error storm is broken, and rate limit the error message to avoid spamming the log while the fault path completes. Signed-off-by: Lucas Martins Alves Link: https://patch.msgid.link/20260714134941.18508-1-lucas.alves@lumal21.com.br Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3c09eb8edc591138bb08d2291370e37d3c9b02d2 Author: Hans Verkuil Date: Fri Jul 10 13:07:32 2026 +0200 media: cec/core: drop cec_post_state_event call [ Upstream commit 2ff4b91e82bd76e1a6e1ff22bfc9aeda08e12a61 ] No need to call cec_post_state_event() if the next call is to cec_adap_unconfigure() since that will also call cec_post_state_event(). This fixes the case when, when the physical address is invalidated, you get two CEC_EVENT_STATE_CHANGE events: one with a non-zero log_addr_mask and one with a zero log_addr_mask. You just want to see the event with phys_addr set to f.f.f.f and log_addr_mask set to 0. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5bb38ddc4ddf9aa154817948330e0ecc588d895c Author: Hans Verkuil Date: Fri Jul 10 11:53:17 2026 +0200 media: cec: tegra_cec: don't break off msg on NACK [ Upstream commit be627f257ce283c95fd2988080dc0db3a20d0d2a ] The Tegra CEC hardware has a bug where, if the first attempt to transmit a message is NACKed so the transmit is aborted, then the second attempt can contain corrupt data. Ensure that the full message is always transmitted to avoid hitting this bug. I suspect some internal state is not reset in the case of aborting a message due to a NACK. Signed-off-by: Hans Verkuil Reviewed-by: Mikko Perttunen Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c643f5567089eb12adbd2a4c96e61ff5a398c891 Author: Shivaprasad G Bhat Date: Fri May 15 13:45:18 2026 +0000 scsi: qla2xxx: Handle INTx not connected while passing through [ Upstream commit 7268e509b43ac1734e1bdb7d18553f7e1080dfb4 ] The PCI_INTERRUPT_PIN reports if the device supports the INTx. However, when the device is assigned to a guest via vfio, the PCI_INTERRUPT_PIN is set to 0 (i.e none) if the line is not connected and/or the platform cannot route the interrupt. In such cases, the guest PCI_INTERRUPT_PIN is 0 and the port number becomes -1 (255, uint8_t underflow) for qla[25|27|28]xx and qla2031 devices. The flt_region_nvram is never set, and subsequently the LUN detection fails. Below warnings show the NVRAM configuration failure: []-0073:1: Inconsistent NVRAM checksum=0xffffffc0 id=HCAM version=0x100. []-0074:1: Falling back to functioning (yet invalid -- WWPN) defaults. []-0076:1: NVRAM configuration failed. Handle this case and set the port_no to devfn like its done everywhere else. Reference: commit 2bd42b03ab6b ("vfio/pci: Virtualize zero INTx PIN if no pdev->irq") Signed-off-by: Shivaprasad G Bhat Reviewed-by: Kyle Mahlkuch Link: https://patch.msgid.link/177885270578.1573.14283751510936407585.stgit@linux.ibm.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c91060db4f4acaec200a567af9ce87ec97ebc785 Author: Ilan Peer Date: Wed Jul 15 22:04:30 2026 +0300 wifi: iwlwifi: mld: Do not cleanup FW state when the device is dead [ Upstream commit 1c031ac5a39ebcc3269eace8b606043adc398bfa ] When a channel context is unassigned, there is a path to cleanup the FW state in case of NON MLO connection: remove the link and add it again. However, when the transport is dead, e.g., during device removal etc., this flow will fail and as a result the mld_vif->link[0] would be set to NULL. Later, when the interface is removed, iwl_mld_remove_link() would warn as the link is NULL. Fix this by not doing the cleanup when the device is dead. Signed-off-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.89a0c44a72a3.I45cca8b84a25943d5771199af6b0155dbac77b58@changeid Signed-off-by: Sasha Levin commit c7d73393a9e5e5907b0ffa54d3665995949b1f21 Author: Avraham Stern Date: Wed Jul 15 22:04:17 2026 +0300 wifi: iwlwifi: mld: support aborting an ongoing ftm request [ Upstream commit ef704fc32ae1a519801ac4a06aa290fece5f403c ] Add support for aborting an ongoing FTM request. Signed-off-by: Avraham Stern Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715220243.340040bdc6a3.Ifbbf70021e42bf1d59db6ec45a73f1806a1c2289@changeid Signed-off-by: Sasha Levin commit 47e3a46c3c98d3ea680547882769a1ffad59a745 Author: Mikko Perttunen Date: Tue Jun 9 17:09:17 2026 +0900 gpu: host1x: Wait for timeout worker completion on channel free [ Upstream commit 7a39b9856acccc8e9b05845ca2bf62494fcd3dfa ] cdma_timeout_destroy() used cancel_delayed_work() to cancel pending timeout work when destroying the CDMA. Usually this is fine, but there is a narrow race condition where the timeout handler has started execution but has not taken cdma->lock; the channel is freed causing cdma_stop to take cdma->lock and flush the channel; host1x_cdma_deinit then proceeds with deinitializing cdma while the handler is waiting to take cdma->lock. Therefore change cdma_timeout_destroy to use cancel_delayed_work_sync instead to ensure any pending timeout work completes before proceeding. Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-1-7c1131c0b3ad@nvidia.com Signed-off-by: Sasha Levin commit cc9422f6caeeff497d2afdaceb54ee54eea5bf5e Author: Namhyung Kim Date: Fri Jul 10 17:32:35 2026 -0700 tools/lib/api: Fix potential double-free from fdarray__grow() [ Upstream commit eadce0f46a1d066b812c7e5aa46a33711c78a755 ] If the realloc for fda->entries succeeds but the realloc for fda->priv fails, the error path frees the newly allocated entries. However, fda->entries is neither updated to point to the new entries block nor cleared to NULL. If realloc moved the allocation to a new block, the old fda->entries pointer is now freed memory. When fdarray__exit() is later called to clean up, it executes free(fda->entries), which would trigger a double-free on that old pointer. Reported-by: Sashiko Review Closes: https://lore.kernel.org/linux-perf-users/20260710200150.11FE71F00A3A@smtp.kernel.org Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit bca5f8ecbeaf82bfece55e194c68d5c48696c4dc Author: Miri Korenblit Date: Tue Jul 14 17:02:11 2026 +0300 wifi: iwlwifi: mld: cancel wiphy work before freeing wiphy [ Upstream commit c99bc4d4e0ba6f4661b2b914c96a597d26e7cc05 ] When we fail to load the fw during op-mode start, we purge the list of the async handlers but we don't cancel the work. Same when we stop the op-mode. Before freeing wiphy, we need to cancel/flush any pending wiphy work, otherwise the work will fire with a freed memory. cfg80211 will do it anyway, but it will warn. Cancel the work in those cases. Reviewed-by: Johannes Berg Link: https://patch.msgid.link/20260714165826.07aa49f755a2.I734a27b1b0eeb5b0e821aee3318fee8dc0a6bc03@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 7ee63a67d2da926ac487f6eb61faf7147f7513ba Author: Emmanuel Grumbach Date: Tue Jul 14 17:02:16 2026 +0300 wifi: iwlwifi: mvm: reset the smart fifo state upon FW stop [ Upstream commit a51cc8131214870af92abbceab64877b27e690c2 ] The smart fifo is a feature in the firmware configured by the driver. The driver keeps a state to remember what was the last configuration sent to the firmware. Obviously, if the firmware stops, we need to reconfigure the smart fifo. Since we didn't reset that state upon firmware stop, we thought the firmware is already properly configured and we didn't send the smart fifo configuration command as part of the init sequence. Reset the smart fifo state in iwl_mvm_stop_device() so that we will properly send the command during the init that will come later. Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260714165826.7d3c5efe2d1a.I16b23c328a677257257f695fa6f439e41fbcd081@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 38c0dfbd44dda653ecef6d94ae1de756e258293d Author: Stefan Binding Date: Wed Jul 15 13:01:33 2026 +0100 ASoC: cs35l56: Add support for CS35L62 for SoundWire [ Upstream commit 3330b5f6d8dea66df51c07362f01a39ad9845aad ] CS35L62 uses the same control and regmap interface as CS35L63 so support for it can be added into the CS35L56 driver. Signed-off-by: Stefan Binding Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260715120135.939280-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 30d81bbb623919d0d85e690fef28096e72952d4d Author: Emmanuel Grumbach Date: Tue Jul 14 17:02:18 2026 +0300 wifi: iwlwifi: mld: reset the driver state upon firmware recovery [ Upstream commit 71ac392d8b5c23c45c66f30eff1c319580ada4da ] Just like we did in iwlmvm, we also need to clear the mld state when the firmware was killed because of the device being powered off during suspend. Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260714165826.ff1c9e05e0a9.I8df8d4a0384065fd2a32cf258339be77084c55bd@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 3da9cb696cee620dba5c8abbca9b1d0669cc0eb2 Author: Jingyi Wang Date: Tue Jun 23 02:05:36 2026 -0700 remoteproc: core: cancel crash_handler work in rproc_add() error path [ Upstream commit 0ec167625b4fea30b26da33c188e853ff25d5583 ] Ensure crash_handler work is cancelled before tearing down rproc resources to avoid accessing freed memory. Signed-off-by: Jingyi Wang Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-3-8e24310707ce@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3eae2410216a6905406870178701c1c232094318 Author: Emmanuel Grumbach Date: Tue Jul 14 17:02:12 2026 +0300 wifi: iwlwifi: mld: validate D3_END notif size [ Upstream commit 4e777dcdfe70d9b3ddf38cb49de9e30306889b18 ] Check D3_END_NOTIFICATION payload length before reading notif->flags. On short payloads, mark notif handling as failed. Avoid out-of-bounds reads from malformed notifications. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20260714165826.db2df8b6b6bb.I6163bbdf433379bf1dbf9eb46fb9562892217bd7@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 46403a03d416e87ac8055539096d64928ce534fe Author: Pengpeng Hou Date: Wed Jul 15 21:57:50 2026 +0800 wifi: iwlwifi: validate UEFI reduced-power SKU TLV length [ Upstream commit f051995c539582b05276abda4c5874fd4cafd2a5 ] iwl_uefi_reduce_power_parse() reads an iwl_sku_id from an IWL_UCODE_TLV_PNVM_SKU payload after only checking that the generic TLV payload is present. A short type-specific payload can therefore make the three data[] reads extend beyond the TLV. Reject SKU TLVs shorter than the structure before accessing it. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260715135916.24417-2-pengpeng@iscas.ac.cn Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 5133a95f41092125a05e77a8e42f44f3146f5502 Author: Miri Korenblit Date: Tue Jul 14 17:02:07 2026 +0300 wifi: iwlwifi: support TTL platform device ID [ Upstream commit 3bff0d12c36247073fca976498b58a940fca72dc ] Add support for a new device ID that we will have on TTL (sc2). Reviewed-by: Johannes Berg Link: https://patch.msgid.link/20260714165826.46183446954f.Icc260831e530c1c92c9be615a7077768b1b9ae30@changeid Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 528b299318ee2aa50f1a692b8486f1854d4f0234 Author: Pengpeng Hou Date: Wed Jul 15 21:57:50 2026 +0800 wifi: iwlwifi: validate PNVM SKU TLV length [ Upstream commit 7410e4548a17bd868dfc60b48f2e78eacde3ad78 ] iwl_pnvm_parse() reads an iwl_sku_id from an IWL_UCODE_TLV_PNVM_SKU payload after only checking that the generic TLV payload is present. A short type-specific payload can therefore make the three data[] reads extend beyond the TLV. Reject SKU TLVs shorter than the structure before accessing it. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260715135916.24417-1-pengpeng@iscas.ac.cn Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit d9754d77182fd09995c30ec8305f88f386d5a179 Author: Jingyi Wang Date: Tue Jun 23 02:05:35 2026 -0700 remoteproc: qcom: Check subdev start status in rproc_stop() [ Upstream commit f44ae8ce156a387b07d40e2d6a0ef979a2748aa1 ] For rproc that doing attach, rproc_start_subdevices() is called only when attach successfully. If rproc_report_crash() is called in the attach function, rproc_boot_recovery()->rproc_stop()->rproc_stop_subdevices()-> glink_subdev_stop() could be called and cause NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000300 Mem abort info: ... pc : qcom_glink_smem_unregister+0x14/0x48 [qcom_glink_smem] lr : glink_subdev_stop+0x1c/0x30 [qcom_common] ... Call trace: qcom_glink_smem_unregister+0x14/0x48 [qcom_glink_smem] (P) glink_subdev_stop+0x1c/0x30 [qcom_common] rproc_stop+0x58/0x17c rproc_trigger_recovery+0xb0/0x150 rproc_crash_handler_work+0xa4/0xc4 process_scheduled_works+0x18c/0x2d8 worker_thread+0x144/0x280 kthread+0x124/0x138 ret_from_fork+0x10/0x20 Code: a9be7bfd 910003fd a90153f3 aa0003f3 (b9430000) ---[ end trace 0000000000000000 ]--- Introduce "subdevs_started" flag to indicate rproc_start_subdevices() has been called successfully. Ensure subdevices are only stopped if they have been started. Signed-off-by: Jingyi Wang Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-2-8e24310707ce@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 660cb7f6dafb20d008a7e1165c3fab21a19388b9 Author: Yousef Alhouseen Date: Tue Jun 30 12:52:57 2026 +0200 media: go7007: avoid undefined shifts in MPEG-4 headers [ Upstream commit 41f82777e547732460290ceb28fcc7c1b95ef192 ] The byte-alignment paths can call CODE_ADD() with a zero bit length. The macro then shifts an int by name.b, which can be 32 after the preceding bit was flushed. vti_bitlen() can likewise shift a signed int into its sign bit while searching for the bit length, and the package mask construction can shift by the full type width. Make zero-length additions a no-op, derive the bit length with fls(), and build the mask with GENMASK(). Signed-off-by: Yousef Alhouseen Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1f000ae86851d0fe5bf6a84bb85b713e9a384756 Author: Pengpeng Hou Date: Tue Jun 30 14:56:36 2026 +0800 media: cx18: stop VBI start-code scan before short tail [ Upstream commit bf533acaaa7dee21d49bcaabf8e813ea36bddcd8 ] compress_sliced_buf() scans one byte at a time while testing a four-byte VBI start code. The final iterations can read beyond the remaining buffer tail. Stop the scan once fewer than four bytes remain. Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2579f03aad9375ab5503114cd1db8a7e11ca31b5 Author: Pengpeng Hou Date: Tue Jun 30 15:19:33 2026 +0800 media: ivtv: stop VBI start-code scan before short tail [ Upstream commit f373cf17fb8e7a530bc6e1e36fc41cb5dab2cdaa ] compress_sliced_buf() scans one byte at a time while testing a four-byte VBI start code. The final iterations can read beyond the remaining buffer tail. Stop the scan once fewer than four bytes remain. Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 39ef93ceb83bab404324ef756826ca0f55060ddc Author: Jurison Murati Date: Wed Jun 10 12:22:37 2026 +0200 media: i2c: ov8865: Program the sensor on stream start [ Upstream commit 4e1446ac169a1a621ba90502ab8db3be821fe726 ] The sensor registers are only written in the runtime PM resume handler; ov8865_set_fmt() merely stores the requested mode, relying on the sensor being runtime suspended between uses so that the next resume applies it. That assumption breaks when something keeps the sensor powered. On IPU3 platforms, ipu_bridge instantiates the VCM device with a DL_FLAG_PM_RUNTIME device link to the sensor, so a userspace process holding the VCM subdev open (e.g. wireplumber's camera monitor) pins the sensor runtime-active. A subsequent set_fmt() then never reaches the hardware: the sensor keeps streaming the mode programmed on the last resume while the CSI-2 receiver expects the newly negotiated format. On a Surface Book 2 (IPU3, ov8865 + dw9719 VCM), requesting the 3264x2448 mode while the hardware was left programmed for the 1632x1224 binned mode makes ipu3-cio2 report "frame sync error" and "payload length is 10340352, received 2585088" (exactly one binned frame) for every frame, and the inverse case stalls the stream after a single frame. Camera applications end up displaying one bogus frame forever. Program the sensor configuration and apply the control values on stream start instead, where the negotiated mode is always current, and only write the configuration in the runtime PM resume handler when resuming with the stream already started. Signed-off-by: Jurison Murati Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 2e7b5b3b6688b9ebc8004bb065054132d1ea3538 Author: Lucas Stach Date: Mon May 11 10:51:48 2026 +0200 drm/etnaviv: check MMUv2 status after reset [ Upstream commit 4720915ab48282429f9e22ad5984b7870e4e962c ] A full GPU reset is the only way to disable the MMUv2 and the driver depends on the MMU being disabled after a reset to be able to properly restart the GPU. Validate this assumption by checking that the reset actually did disable the MMU. Reviewed-by: Christian Gmeiner Link: https://patch.msgid.link/20260511085148.652256-2-l.stach@pengutronix.de Signed-off-by: Lucas Stach Signed-off-by: Sasha Levin commit 80d182edba4fb5b6d78e424be85711e6c8fb1bdc Author: Lucas Stach Date: Mon May 11 10:51:47 2026 +0200 drm/etnaviv: check all modules for idle after reset [ Upstream commit 1006d1f7c03d92b28c252333836635df8e165401 ] While the FE is an important part of the GPU, which needs to be idle after reset, all other modules should be idle after a proper reset. Check all present modules for being idle to determine whether the reset was successful. Reviewed-by: Christian Gmeiner Link: https://patch.msgid.link/20260511085148.652256-1-l.stach@pengutronix.de Signed-off-by: Lucas Stach Signed-off-by: Sasha Levin commit 57a0b2edcd5fa0b12acbceae261cde3064528e75 Author: Jurison Murati Date: Wed Jun 10 12:22:36 2026 +0200 media: i2c: ov8865: Drop the runtime PM usage count on stream failure [ Upstream commit 3fe797a12bfa9a49aa998ee722e5f25c957b9b15 ] ov8865_s_stream() takes a runtime PM reference when enabling the stream, but returns without releasing it if ov8865_sw_standby() fails, leaving the reference unbalanced and the sensor powered indefinitely. The same applies to a failure while disabling the stream, in which case the reference acquired at stream start is never dropped. Drop the reference in a single place, both when disabling the stream and on failure, and only update the streaming state on success. Signed-off-by: Jurison Murati Reviewed-by: Daniel Scally Signed-off-by: Sakari Ailus Signed-off-by: Sasha Levin commit 25e807780416a425d34c19112fa0b18b2776ade5 Author: Hari Mishal Date: Thu Jul 9 14:30:33 2026 +0200 nvme: clamp FDP nruhsd to allocated RUH status descriptor count [ Upstream commit 29261f8bb41662f2a660c479e5cf592942b53f78 ] nvme_query_fdp_info() allocates the RUH status buffer for at most S8_MAX - 1 descriptors, and then copies ruhs->ruhsd[] into head->plids[] using the controller reported ruhs->nruhsd directly as the loop bound. However, that count wasn't taken into account for the actual buffer's size, so there was a chance for a controller reporting a larger nruhsd to cause the copy to overflow the buffer. Clamp nr_plids to the same bound used for the allocation. Assisted-by: gkh_clanker_t1000 Reviewed-by: Christoph Hellwig Signed-off-by: Hari Mishal Signed-off-by: Greg Kroah-Hartman Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit c9513f41be7e92cf159562b85a08b3abfc733b61 Author: Haoxiang Li Date: Wed Apr 1 11:05:55 2026 +0800 iwlwifi: dvm: add missing cleaup for on error path [ Upstream commit 94280e6e0c69a5327e377803732f494d8b5a74cd ] In iwlagn_tx_agg_start(), call iwlagn_dealloc_agg_txq() to clear bit on error path. Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260401030555.541685-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Miri Korenblit Signed-off-by: Sasha Levin commit 155ae5908007b63af52ad133691b2a75858ca98f Author: Hari Mishal Date: Thu Jul 9 14:30:32 2026 +0200 nvme: bound ns descriptor header and body to identify buffer [ Upstream commit 3c568b35a0d309acb40746552bec2af24cd550ef ] nvme_identify_ns_descs() allocates a buffer and gives it to the controller, which populates it and then iterates the buffer with variable byte increments that vary by type and body size. But, there is no bounds check inside the iteration itself except the loop bound itself. Fix this by checking and stopping iteration if the next header or its declared body would go past the buffer itself. Assisted-by: gkh_clanker_t1000 Reviewed-by: Christoph Hellwig Signed-off-by: Hari Mishal Signed-off-by: Greg Kroah-Hartman Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit b2fd3bc65516edd60db9b34ae6eb161bbee09c33 Author: David Maximiliano Hermitte Date: Wed Jul 8 21:56:36 2026 +0000 hfs: validate catalog CNIDs before instantiating inodes [ Upstream commit 53c3c138d672765c26884c55728307a65c634328 ] hfs_cat_find_brec() first resolves a catalog thread record by CNID and then looks up the corresponding catalog record by parent/name. On a corrupted filesystem image, the second lookup may find a record whose CNID does not match the CNID that was requested. Validate the record found by the second lookup before returning it. Read the already-found record with hfs_bnode_read(), require the exact fixed size for file and directory records, reject other record types, and verify that the stored CNID matches the requested CNID. Also validate reserved CNIDs in hfs_read_inode() before populating the inode, propagate hfs_read_inode() failures from the resource-fork lookup path, and reject bad resource-fork and root inodes. Keep hfs_write_inode() unchanged, so corrupted catalog records are rejected before reaching its existing reserved-CNID BUG() path. Reported-by: syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=97e301b4b82ae803d21b Cc: George Anthony Vernon Cc: Tetsuo Handa Signed-off-by: David Maximiliano Hermitte Reviewed-by: Viacheslav Dubeyko Signed-off-by: Viacheslav Dubeyko Link: https://lore.kernel.org/r/20260708215636.73815-1-davemadmaxxx@gmail.com Signed-off-by: Viacheslav Dubeyko Signed-off-by: Sasha Levin commit 2fcd643f0e3ab09112f629c6a35a49b30cd0c434 Author: Charles Keepax Date: Wed Jul 8 13:29:48 2026 +0100 soundwire: intel_auxdevice: Add cs42l44 to wake_capable_list [ Upstream commit d08e4d9197396ceb906715d976b63aed0c5cc8e5 ] Add cs42l44 to the wake_capable_list because it can generate jack events whilst the bus is stopped. Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260708122948.1502227-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 45d4470612293dbd10b34b410650eb83a780d244 Author: Bard Liao Date: Fri Jul 3 09:16:56 2026 +0800 soundwire: dmi-quirks: add a global ghost list [ Upstream commit b7a5d101d7d267922e828c40135bcaccf8cfb3bf ] Not like other ghost devices, the 0x000000D010010500 ADR doesn't belong to any codec. We should disable it in all devices. Signed-off-by: Bard Liao Reviewed-by: Charles Keepax Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260703011656.2572959-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d6c7e4fa4fcc90a4c8c7e62e1673bb3d02c4a2b0 Author: Niranjana Vishwanathapura Date: Mon Jul 13 13:23:16 2026 -0700 drm/xe: only resume exec queues that were actually suspended [ Upstream commit 65f40fa5022bcdb90d3a39e4948adf2aa16732a3 ] A consumer-issued suspend() can fail (e.g. the queue is killed, banned or wedged), leaving the queue un-suspended. The consumer must then not issue the matching resume(): resuming a queue that was never suspended is incorrect. Add an lr.suspended flag to struct xe_exec_queue that records whether a consumer suspend() succeeded and a matching resume() is still owed. Set it on a successful suspend() in the preempt-fence path, clear it on resume(), and only resume queues that have it set. In resume_and_reinstall_preempt_fences() also skip queues that have since been reset/killed/banned/wedged: such a queue's suspend may not have completed (suspend_pending can still be set, e.g. a preempt fence signalled with -ENOENT without waiting), so resuming it would trip the !suspend_pending assert in the backend. Leave it marked suspended and let teardown resolve its state. A queue is only ever suspended by a single consumer at a time (preempt-fence mode and hw engine group fault mode are mutually exclusive), so a single flag is sufficient. Assisted-by: Github-Copilot:Claude-opus-4.8 Signed-off-by: Niranjana Vishwanathapura Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260713202317.2187787-9-niranjana.vishwanathapura@intel.com Signed-off-by: Sasha Levin commit aeb724dae9a792b2a24c0a6a845ee06be2cc45f2 Author: Hans Verkuil Date: Tue May 19 13:33:38 2026 +0200 media: em28xx: use vb2_video_unregister_device [ Upstream commit 7c8bf63b79371f5b57da1bd1401bd420180ac6e6 ] Use vb2_video_unregister_device instead of video_unregister_device to ensure any streaming is correctly stopped at unregister time. Signed-off-by: Hans Verkuil Tested-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fbc2053fc89c5dd2713c9854585651bf49813c68 Author: Hans Verkuil Date: Tue Jun 16 14:42:16 2026 +0200 media: em28xx: requeue buffers if start_streaming fails [ Upstream commit 67f87b104f4ef3108607ac9d8fa2075b13ed314d ] If start_streaming fails, then all queued buffers must be returned to vb2 in state QUEUED. Otherwise it will trigger a WARN_ON. Signed-off-by: Hans Verkuil Tested-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3b9bfc463b2f1b53b995a70c44fd206d0f246882 Author: Hans Verkuil Date: Tue Jun 16 14:00:12 2026 +0200 media: em28xx: dev_info->pr_info since dev has been freed [ Upstream commit c132b07f7e5853c0df35a9b94b8e204cdc6afdef ] In em28xx_free_device() dev_info passed &dev->intf->dev, but that device can be freed already. Just use pr_info instead. Signed-off-by: Hans Verkuil Tested-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3909eaa26344eda5f5b36f57281d4a150c914bd3 Author: Sean Rhodes Date: Mon Jul 6 16:40:44 2026 +0100 mmc: rtsx_usb_sdmmc: suppress false CD after init timeout [ Upstream commit 7185b6d33b170cae54fb562ead44452810b6c231 ] Some Realtek USB SD readers with a tray keep raw SD_CD asserted when an empty tray is inserted. The MMC core then repeatedly tries to initialize non-existent media, sees command timeouts, calls ->get_cd() again, and starts the same detect cycle over. Do not qualify media by open-coding MMC commands in ->get_cd(). Instead, let the normal MMC rescan path probe the card. If an initialization command times out before a card has been attached, suppress the raw SD_CD signal so the host can settle and the USB parent can autosuspend. Clear the suppression only when raw SD_CD drops. On the affected tray reader, changing media requires removing and reinserting the tray, so a low CD transition is the signal that a new insertion attempt can be trusted again. Signed-off-by: Sean Rhodes Acked-by: Greg Kroah-Hartman Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 8879a96ba07d94c1255dd8ad2cbd4f820bac731a Author: Mike Tipton Date: Mon Jun 29 13:33:36 2026 -0700 pmdomain: qcom: rpmhpd: Skip retention by default [ Upstream commit 7178817f190496f2bfdec181fb4aa72832448468 ] Retention is very rarely an operational corner. In the majority of cases, HW cannot operate properly at Retention levels and so the minimum operational level when enabling a rail is the first corner above Retention. A small subset of always-on use cases can operate at Retention, but those aren't controlled from HLOS. Currently, we allow Retention by default and only disallow it special cases. But this leaves us open to various failures when the PD is enabled without first being voted to an OPP above Retention. Such as when a child GDSC PD requests to enable its parent RPMh PD. In this case, the GDSC would get stuck powering on. Newer chips have started supporting Retention on rails that didn't previously (such as for MMCX). Instead of adding more special cases to skip Retention on MMCX, start skipping Retention by default since it's almost never desired from an HLOS perspective. Signed-off-by: Mike Tipton Reviewed-by: Konrad Dybcio Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 4a1ce4307f09ee51f285d3080bd51d7001fdd192 Author: Pengpeng Hou Date: Sat Jul 4 20:21:23 2026 +0800 gpio: vf610: add missing MODULE_DEVICE_TABLE() [ Upstream commit 975a1d61260cf74d467f34898fade63165c80735 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260704122123.73004-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 7823cf4f9bc93619a207498a791009068aea2639 Author: Pengpeng Hou Date: Sat Jul 4 20:46:09 2026 +0800 crypto: keembay - add missing MODULE_DEVICE_TABLE() [ Upstream commit b73b71df4cb4ca241165ad31218c82dfe489147c ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit edd239bf397ffd25bc0da960d7b5f561e4edf44d Author: Pengpeng Hou Date: Sat Jul 4 23:22:30 2026 +0800 pinctrl: sx150x: add missing MODULE_DEVICE_TABLE() [ Upstream commit 5fe4b12c087db3e565f53b87f1dafdf2f0d1ee0f ] The driver has a match table for the i2c bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d0fa85e364968f531ea906df59962e32872e4b63 Author: Gabriel Prostitis Date: Mon Jun 1 08:44:11 2026 +0200 USB: gadget: inode: fix mm lifetime handling [ Upstream commit a1c33c80e11ecd5c3310a38c4be324095dd85ac5 ] priv stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending. This can result in a use-after-free if the task exits before completion handling finishes. Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion. Reported-by: Gabriel Prostitis Signed-off-by: Gabriel Prostitis Acked-by: Alan Stern Link: https://patch.msgid.link/20260601-mm-uaf-fix-v2-2-3c942a707bce@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4fba239be9110b0fb82948e5fb4d17c5ca49b27b Author: David Laight Date: Mon Jun 8 10:55:21 2026 +0100 usb_string_copy: Use kzalloc() to avoid leaking old data [ Upstream commit 057df423bf4747091cf942af57307627e941e1fb ] If the string is read while being updated (which is why the copy is done in place) and the new string is longer than the old one, then the reader can read memory that isnt part of either string. Use memcpy() to copy the known length string instead of strcpy. Signed-off-by: David Laight Link: https://patch.msgid.link/20260608095523.2606-37-david.laight.linux@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 099d34863a4c1b6f60432c2d9a8afb0bc366b8de Author: Xu Rao Date: Thu Jun 11 17:12:28 2026 +0800 usb: gadget: u_audio: clean up capture endpoint on feedback failure [ Upstream commit 7a0d4f60da261f61dcb50c8e05fa53cc7d4d4427 ] u_audio_start_capture() enables the capture OUT endpoint, queues capture requests and marks the stream active before setting up the optional feedback endpoint. If feedback endpoint configuration or enablement fails, the function returns an error while the capture endpoint remains enabled and its requests may remain queued. The current code even leaves TODO comments at these return paths. Unwind the already started capture endpoint on these failures. Also set fb_ep_enabled only after usb_ep_enable() succeeds, so the software state matches the endpoint state. Signed-off-by: Xu Rao Link: https://patch.msgid.link/183621D513E0DE8B+20260611091229.4017443-1-raoxu@uniontech.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6997b82a2a26d40141dec72c71f13284869d25db Author: Haoxiang Li Date: Sat Jun 20 20:06:31 2026 +0800 usb: fsl_qe_udc: check qe_alloc_request() failure in ch9getstatus() [ Upstream commit 612551bf7cf7113b8bbd5e8c1eea86d9427c2f95 ] qe_alloc_request() may return NULL on allocation failure. ch9getstatus() passes the return value directly to container_of() and then immediately dereferences the resulting qe_req pointer. Check the allocation result before using it and stall the control request on failure. Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260620120631.2894977-1-haoxiang_li2024@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e8ba98b981a740be135b49038fdd1be46965cb07 Author: Aniket Randive Date: Mon Jul 6 15:07:49 2026 +0530 serial: qcom_geni: Disable closing_wait for console to prevent shutdown timeout [ Upstream commit acba38e675dd66f52925cb9edf9ed8db16335875 ] During system power-off, systemd closes the console UART and blocks in tty_wait_until_sent() waiting for pending TX completion before uart_shutdown() can cancel pending TX operations. With the default closing_wait of 30s, this causes a watchdog reset when systemd is responsible for watchdog feeding. Set closing_wait to ASYNC_CLOSING_WAIT_NONE in startup() for console ports to bypass tty_wait_until_sent() on close, allowing uart_shutdown() to cancel TX commands cleanly. This change doesn't impact regular ports functionality. Signed-off-by: Aniket Randive Link: https://patch.msgid.link/20260706093749.836121-1-aniket.randive@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d4b9dc0a5b4d1cb2ec8034d334994733bef59a4a Author: Haoxiang Li Date: Tue Jun 23 22:05:39 2026 +0800 tty: serial: pch_uart: add check for pci_get_slot() [ Upstream commit 970ede67de0e3f6a1e707ec99ae49d80bf3f2966 ] Add check for pci_get_slot() to prevent a potetial null pointer dereference in pch_request_dma(). Signed-off-by: Haoxiang Li Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260623140539.2272473-1-haoxiang_li2024@163.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5996913c7c04fb3e2f11f8e4130093906cf37ea2 Author: Rahul Bukte Date: Wed Jun 10 14:41:30 2026 +0900 serial: 8250: force synchronous probe for the ISA and PNP drivers [ Upstream commit 31e11af34e2c7cc61e25533ab877b1f9cc3eb528 ] On x86_64 defconfig, booting with driver_async_probe=serial hangs in early init. The 8250 PNP driver is put onto the async probe pool. serial8250_register_8250_port() runs in a kworker concurrently with the ISA registration done from the serial8250_init() initcall resulting in a deadlock or NULL dereference. - Deadlock: serial_core_register_port() holds port_mutex across serial_core_add_one_port() uart_configure_port() autoconfig_irq() probe_irq_on() async_synchronize_full(), which waits for the async probe pool to drain. The async PNP worker reaches the "port already in use" check and tries to unregister it. serial8250_register_8250_port() uart_remove_one_port() serial_core_unregister_port() This blocks on port_mutex. The init thread waits for the worker and the worker waits for the init thread. - NULL deref: when the worker instead observes a slot whose port.dev is set but whose port_dev has not yet been populated, it hits the null pointer on the call to serial_core_get_ctrl_dev() in serial_core_unregister_port(). Signed-off-by: Rahul Bukte Link: https://patch.msgid.link/20260610054130.2825182-1-rahul.bukte@sony.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aa7c80d4e25a47d73e99da22dc417a74dd59e8c9 Author: Xu Rao Date: Mon Jul 6 17:25:00 2026 +0800 mmc: block: reject invalid perdev_minors before division [ Upstream commit 5253aee00a4383cb0482d5e99bde48b8054ae2c0 ] The mmcblk.perdev_minors module parameter is parsed as a signed int and is used during mmc_blk_init() to compute the number of supported block devices. Passing perdev_minors=0 makes the init path divide by zero when it computes max_devices. Negative values are invalid as well and would make max_devices negative before it is later used as an IDA limit. Reject non-positive perdev_minors values before registering any mmcblk resources. Signed-off-by: Xu Rao Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 813a0eaf5570f8045cc9083355fbb39f5e4ce79a Author: Arnd Bergmann Date: Thu Jun 18 16:32:47 2026 +0200 media: v4l2-tpg: reduce stack usage for kasan builds [ Upstream commit c49cdaafa443ccf861a72d3191121294742c28c7 ] tpg_fill_plane_buffer() is a rather complex function. While there is nothing wrong with it per se, I have run into corner cases with clang-22 on s390 using KASAN that makes it run out of registers and blow the stack warning limit from excessive spills: drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2629:6: error: stack frame size (1560) exceeds limit (1536) in 'tpg_fill_plane_buffer' [-Werror,-Wframe-larger-than] 2629 | void tpg_fill_plane_buffer(struct tpg_data *tpg, v4l2_std_id std, Forcing the two largest callees out of line completely avoids the problem and prevents all the register spills, with the stack usage for each function going down to a few bytes for the local variables. Arguably this is a problem caused by clang rather than the code, but a noinline_for_stack annotation is an easy workaround. Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 6b772df6ea8e3e275652b6fb5d0d57a551a33566 Author: Pengpeng Hou Date: Sat Jul 4 20:26:31 2026 +0800 media: cec: tegra: add missing MODULE_DEVICE_TABLE() [ Upstream commit 8dcf23edaf4bdf22259f6a47cfddc8bb1467425c ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d638c584bdae71d46f3e5391dd70551349d8ea78 Author: Chris Lew Date: Mon Apr 6 09:59:50 2026 +0530 rpmsg: char: Check for ongoing chrdev destroy [ Upstream commit 1f9c2897afb0fe86c1fdf4f5e23c5fb8f7442f6d ] A null pointer panic is observed when stopping a remoteproc and closing a character device using the RPMSG_DESTROY_EPT_IOCTL. There is a race where each context calls rpmsg_chrdev_eptdev_destroy(). The thread that runs second will call cdev_device_del() for a second time, which fails because the first call already removed the device from sysfs. Add a check at the beginning of destroy and exit early if the destroy call has already been done. [ 26.654130] Call trace [ 26.656658] kernfs_find_and_get_ns+0x28/0x8 [ 26.661140] sysfs_unmerge_group+0x2c/0x7 [ 26.665357] dpm_sysfs_remove+0x38/0x8 [ 26.669305] device_del+0xa4/0x3e [ 26.672811] cdev_device_del+0x28/0x7 [ 26.676675] rpmsg_chrdev_eptdev_destroy+0x68/0x98 [ 26.682765] rpmsg_eptdev_ioctl+0x130/0x11c8 [ 26.688318] __arm64_sys_ioctl+0xb4/0x10 [ 26.692448] invoke_syscall+0x50/0x12 [ 26.696312] el0_svc_common.constprop.0+0xc8/0xf [ 26.701151] do_el0_svc+0x24/0x3 [ 26.704570] el0_svc+0x40/0x17 [ 26.707810] el0t_64_sync_handler+0x120/0x13 [ 26.712288] el0t_64_sync+0x1a0/0x1a Signed-off-by: Chris Lew Signed-off-by: Vishnu Santhosh Link: https://lore.kernel.org/r/20260406-rpmsg-char-fix-chrdev-destroy-race-v1-1-7317434fa246@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c50acb6685598c319c77a64bdca96cfd6a389323 Author: Pranjal Shrivastava Date: Mon Jun 15 23:50:34 2026 +0000 PCI/ATS: Ensure pci_ats_supported() is PF-aware for VFs [ Upstream commit 4f2cd6091ac41566a7300f5a4590d20a99aaa8bc ] Update pci_ats_supported() to additionally check the associated PF's status when called on a VF. This ensures that PF-level quirks and untrusted status are correctly propagated to VFs, providing a robust support check that aligns with the kernel's PF-centric ATS configuration model and is immune to the timing of VF-specific fixups. Reviewed-by: Jason Gunthorpe Reviewed-by: Samiullah Khawaja Reviewed-by: Nicolin Chen Reviewed-by: Lu Baolu Reviewed-by: Kevin Tian Acked-by: Bjorn Helgaas Signed-off-by: Pranjal Shrivastava Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 6d7097c6cc34e428223bcecf1a5b0a9ee581884f Author: Muralidhara M K Date: Mon Jun 29 21:26:32 2026 +0530 platform/x86/amd/hsmp: Validate _DSD mailbox sub-package element count [ Upstream commit 0d7a2664494534d6152be9bd9bf1cb1d089c67d3 ] hsmp_read_acpi_dsd() dereferenced elements[0] and elements[1] of each mailbox sub-package before confirming the package actually held two elements, allowing an out-of-bounds read on a malformed _DSD. Verify package.count >= 2 first, then fetch the string and integer objects. Signed-off-by: Muralidhara M K Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20260625123337.886435-3-muralidhara.mk@amd.com Link: https://patch.msgid.link/20260629155634.1807598-3-muralidhara.mk@amd.com Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 42dcaf236bf8f170f5c4dc28458cb3fabb44350c Author: Pengpeng Hou Date: Sat Jul 4 12:06:51 2026 +0800 ASoC: codecs: max98396: Unwind supplies on resume failure [ Upstream commit d20de7409dfa8e3341af7f157cd42130bd4ba3a7 ] max98396_resume() enables the core, pvdd, and vbat supplies before leaving cache-only mode, resetting the device, and replaying cached register state. The function currently ignores regcache_sync() failures, and the optional pvdd/vbat enable failures return without unwinding supplies that were already enabled in this resume attempt. Rework the function to use common error labels. This propagates sync failures, restores cache-only/dirty state on failed cache replay, and disables each supply acquired by this resume path before returning the error. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704040651.47558-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8cc9318ac315be56f4250597b8377edf36ef3632 Author: Muralidhara M K Date: Mon Jun 29 21:26:31 2026 +0530 platform/x86/amd/hsmp: Validate ACPI UID before parsing socket index [ Upstream commit 4c7d1b4cd75a775326e6802608440f7642284ea6 ] hsmp_get_uid() passed the device UID directly to kstrtou16(uid + 2) without checking it. A NULL UID or one shorter than three characters would dereference a NULL pointer or read past the end of the string. Reject such UIDs with -EINVAL before stripping the "ID" prefix. Signed-off-by: Muralidhara M K Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/20260625123337.886435-3-muralidhara.mk@amd.com Link: https://patch.msgid.link/20260629155634.1807598-2-muralidhara.mk@amd.com Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 87afe445153c0580cdef776172e1dc24e22e5ec3 Author: Qingtao Cao Date: Wed Jun 3 11:06:11 2026 +1000 bus: mhi: core: Fix sys error transition latency [ Upstream commit 22568e8f13a42ab69b7d624741768cbf15dded74 ] Bring forward the idea to fix the power down latency in mhi_pm_disable_transition() further to mhi_pm_sys_error_transition() so that the transition into system error (triggered by AT!RESET) in the modems won't have to return only after the timeout of up to 24 seconds. Once the device gets reset, there is no guarantee that it will send an interrupt to indicate the state transition. So polling is the sensible option here. Signed-off-by: Qingtao Cao [mani: commit log] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Krishna Chaitanya Chundru Link: https://patch.msgid.link/20260603011333.3306102-2-qingtao.cao.au@gmail.com Signed-off-by: Sasha Levin commit 21ffa516ded0d6c700a03aad8d263ac3d8964d7a Author: John Garry Date: Mon Jul 6 12:54:02 2026 +0000 nvme: don't reference NS after unlocking in nvme_ns_head_ctrl_ioctl() [ Upstream commit 77c57daf98a2ad95ec9ac1371caeff8939cc1f58 ] In nvme_ns_head_ctrl_ioctl(), once we drop the SRCU read lock we should not reference the NS to lookup the controller, so use the available controller pointer directly. Reviewed-by: Christoph Hellwig Signed-off-by: John Garry Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 61ebae16cef33e8601d030e3d200e36025a2c49b Author: Alex Deucher Date: Mon Jun 15 18:55:21 2026 -0400 drm/amdgpu/gfx11: WARN() rather than BUG() for invalid SDMA engine [ Upstream commit c24edbd5ae0e4f24e0179e8c9f22a867016177bb ] There's no need to crash the kernel for these cases. Reviewed-by: Kent Russell Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a1a4ef16abcaa0bf09952b4413a2cc2991f20b89 Author: Alex Deucher Date: Mon Jun 15 18:57:29 2026 -0400 drm/amdgpu/atomfirmware: WARN() rather than BUG() [ Upstream commit d7c595044965c826e6f3ce30590d3ec4399cd633 ] There's no need to crash the kernel for this case. Just return an error. Reviewed-by: Kent Russell Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7bec37dbc03ded95e68167e81c5d85ae4870dbd3 Author: Pengpeng Hou Date: Sat Jul 4 15:21:40 2026 +0800 ASoC: codecs: uda1342: Leave cache-only mode before syncing [ Upstream commit 29da72e58fde87e632f2fa43e448fcd1e3ab31b0 ] uda1342_suspend() puts the regmap into cache-only mode. uda1342_resume() marks the cache dirty and syncs it, but does not first leave cache-only mode and ignores sync failures. Leave cache-only mode before syncing the dirty cache, propagate sync failures, and restore cache-only/dirty state on failure. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704072140.67222-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e26ea9ee489f20b22a0099ff35aedda41b4e8ca7 Author: Deepanshu Kartikey Date: Sun Jun 21 09:28:41 2026 +0530 udf: avoid recursive s_alloc_mutex deadlock when freeing AED blocks [ Upstream commit 31e5e0c8c8e2617eb9f7a20c1cf5df23f592ade2 ] udf_table_prealloc_blocks() and udf_table_new_block() call udf_delete_aext() on the unallocated-space-table inode while holding sbi->s_alloc_mutex. When the deleted allocation descriptor empties an allocation-extent (AED) block, udf_delete_aext() returns that block to free space via udf_free_blocks(). For a table-managed partition that path is udf_free_blocks() -> udf_table_free_blocks() -> mutex_lock(&sbi->s_alloc_mutex), i.e. the task tries to acquire a mutex it already holds. On a PREEMPT_RT kernel the rtmutex deadlock detector reports this as -EDEADLK: rtmutex deadlock detected WARNING: kernel/locking/rtmutex.c:1698 at rt_mutex_handle_deadlock udf_table_free_blocks fs/udf/balloc.c:376 [inline] udf_free_blocks+0xa8c/0x1900 fs/udf/balloc.c:678 udf_delete_aext+0x4f5/0xc00 fs/udf/inode.c:2381 udf_table_prealloc_blocks fs/udf/balloc.c:544 [inline] udf_prealloc_blocks+0xbd4/0x10e0 fs/udf/balloc.c:702 On a non-RT kernel the same path is a hard self-deadlock (or a lockdep recursive-locking splat). It is reachable from a crafted UDF image via the write/sendfile path. The allocator already refuses to recurse on the add side: see the comment in udf_table_free_blocks() explaining why it must not call udf_add_aext() while holding s_alloc_mutex. Apply the same rule to the delete side. Let udf_delete_aext() report the AED block it would otherwise free through a new out-parameter, and have the two callers that hold s_alloc_mutex free it after dropping the lock. The block is already unlinked from the inode's descriptor chain by then, so nothing can reference it in the meantime. All other callers pass NULL and keep freeing the block inline, exactly as before. The out-parameter is pre-initialised with the reserved partition number 0xFFFF, which can never name a real block, so the caller can tell whether a block was handed back. Reported-by: syzbot+6a680377e13041c19d50@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6a680377e13041c19d50 Signed-off-by: Deepanshu Kartikey Link: https://syzkaller.appspot.com/bug?extid=6a680377e13041c19d50 Link: https://patch.msgid.link/20260621035841.56194-1-kartikey406@gmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit d7f0518e1bbd2e7b43de8e81a34c3aa1bfb9b73a Author: Kyle Zeng Date: Fri Jun 12 15:58:46 2026 -0700 udf: validate extent partition references in udf_current_aext() [ Upstream commit 120ec50984b8645232c2c004310dd94ceff5520e ] Long allocation descriptors carry an on-disk extLocation.partitionReferenceNum. udf_current_aext() copies that value into a kernel_lb_addr and returns it to several consumers. If the partition reference is outside s_partitions, callers can later index s_partmaps out of bounds. The truncate/free path can pass such an extent to udf_free_blocks(), where the invalid partition reference causes a slab out-of-bounds read. Validate eloc->partitionReferenceNum in udf_current_aext() before returning a decoded extent. This rejects invalid file extents and indirect allocation descriptor extents in the common parser, so callers do not need to duplicate the partition-map bounds check. Assisted-by: Codex:gpt-5.5 Signed-off-by: Kyle Zeng Link: https://patch.msgid.link/20260612225846.97678-1-kylebot@openai.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 1e100c7514502321632d2a520e74db95e6618df1 Author: Pengpeng Hou Date: Sat Jul 4 20:47:14 2026 +0800 usb: typec: mux: tusb1046: add missing MODULE_DEVICE_TABLE() [ Upstream commit 5e4eb5c96324b226220d29d025a334df28054ed3 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Reviewed-by: Romain Gantois Link: https://patch.msgid.link/20260704124714.18404-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8a85caef42628eaaf87d00cd601aaf74424b7a91 Author: Devansh Soni Date: Fri Jun 19 18:27:24 2026 +0530 staging: rtl8723bs: fix missing unregister_netdev on sdio_alloc_irq failure [ Upstream commit 51b554f1a758570159a770983c7a0ccd7c761491 ] In rtw_drv_init(), if rtw_drv_register_netdev() succeeds but sdio_alloc_irq() fails, the error path jumps to free_if1 and calls rtw_sdio_if1_deinit(). However, rtw_sdio_if1_deinit() calls rtw_free_netdev() without a preceding unregister_netdev(), freeing a still-registered netdev but leaving stale sysfs entries behind. Signed-off-by: Devansh Soni Link: https://patch.msgid.link/20260619125724.12458-1-devanshsoni874@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e4bde5182fa112acfb6e82c7b0c7342810c409e1 Author: Xixin Liu Date: Thu Jun 25 10:00:00 2026 +0800 nvme: zns: cap zone report nr_zones by DMA buffer size [ Upstream commit 09c9062d4f62199a634a45e2bb9e6e8e572cc78c ] With Partial Report (PR=1), the Number of Zones (NZ) field in the report header must equal the number of zone descriptors fully transferred in the DMA buffer (ZNS Command Set Specification Rev 1.2, section 3.4.2). nvme_ns_report_zones() does not cap the parse loop by max_in_buf derived from buflen. Cap nz with min3() over the device-reported count, nr_zones - zone_idx, and max_in_buf. Signed-off-by: Xixin Liu Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 4be4e86ba5f7a86cc218fe0d564fd476b0a621ee Author: Xixin Liu Date: Wed Jul 1 14:30:00 2026 +0800 nvme-auth: use crypto_memneq for DH-HMAC-CHAP response comparison [ Upstream commit 3a6d89836ab09d53f4c32c57588689a378ce4363 ] DH-HMAC-CHAP authentication compares HMAC response digests with memcmp(). Standard memcmp() may stop at the first differing byte, which can leak timing information to a remote attacker and allow incremental recovery of the expected digest. Use crypto_memneq() for constant-time comparison on both the host path that validates the controller Success1 response and the target path that validates the host Reply digest. Other memcmp() uses in the NVMe auth code (e.g. fixed string prefix checks) are not security-sensitive and are left unchanged. Signed-off-by: Xixin Liu Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 0f4def9c8171efee5b06365947c6cab28f0ccfd0 Author: John Garry Date: Tue Jun 30 10:27:17 2026 +0000 nvme: handle positive error codes in nuse_show() [ Upstream commit dd516cd7624648c71d338d99368587f10ecc9f0b ] Function __nvme_submit_sync_cmd() returns a positive error code for NVMe errors. Otherwise, we get 0 for success or a negative error code for a kernel error. In nuse_show() -> ns_{head}_update_nuse() -> nvme_identify_ns() -> nvme_submit_sync_cmd() -> __nvme_submit_sync_cmd(), we then may get a positive error code returned. Function nuse_show() - being a device attr handler - should return the number of bytes written to the buffer or a negative error code. Convert any positive NVMe error code to -EIO. Signed-off-by: John Garry Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit c9bfb6382c5fdfaa77092c4a7d0f429eb956d97d Author: Tanmay Shah Date: Mon Jun 29 17:48:05 2026 -0700 remoteproc: core: Full attach detach during recovery [ Upstream commit d93ffd549fb4df18c934ca7a47d4128a18c718cb ] Current attach on recovery mechanism loads the clean resource table during recovery, but doesn't re-allocate the resources. RPMsg communication will fail after recovery due to this. Fix this incorrect behavior by doing the full detach and attach of remote processor during the recovery. This will load the clean resource table and re-allocate all the resources, which will set up correct vring information in the resource table. Signed-off-by: Tanmay Shah Link: https://lore.kernel.org/r/20260630004806.3835488-2-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit d94ce712685340a7536aa2509624506ae340eed9 Author: Jerome Brunet Date: Mon Jul 6 11:32:11 2026 +0200 clk: sunxi-ng: fix ccu probe clock unregister on error [ Upstream commit 81f4ddc9f7e0c11d3e9d24d0f30023845a02f7ee ] When registering clocks with sunxi_ccu_probe(), the number of ccu_clocks and the number of hw clocks might be different, eventhough they usually are the same. If they are different, it could lead to out-of-bound access or registered clock left behind on error. Use a different variable when iterating on hw clocks so every registered clock, and only those, gets unregistered on error. Reported-by: Sashiko Closes: https://lore.kernel.org/r/20260629131254.7E34C1F00A3A@smtp.kernel.org Reviewed-by: Chen-Yu Tsai Signed-off-by: Jerome Brunet Link: https://patch.msgid.link/20260706-a733-rtc-v4-3-f330728db3d3@baylibre.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 2b7412064bfad4bfc783d3322d2bcfbd3c819073 Author: Marek Szyprowski Date: Wed Jun 3 10:39:35 2026 +0200 mmc: dw_mmc: stop and complete DMA also in STATE_DATA_BUSY state [ Upstream commit cb3fcb8d118b874178251d1f02613f60d25e4ddc ] When transfer was stopped in STATE_DATA_BUSY state, there was no call to dma_ops->cleanup function, so the DMA mapped buffer was never properly unmapped. Fix this by calling dw_mci_stop_dma() function also in that state to ensure proper cleanup call when DMA transfer was used. Signed-off-by: Marek Szyprowski Reviewed-by: Shawn Lin Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9978e5b0ebcb7fdc41662401b786d4143dccbdde Author: Pengpeng Hou Date: Sat Jul 4 20:41:15 2026 +0800 mmc: sdhci-of-ma35d1: add missing MODULE_DEVICE_TABLE() [ Upstream commit 9b3732cce41d177acac731e0b8024d72f0dfde38 ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. Signed-off-by: Pengpeng Hou Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 7cc038a9c2887fa871cae347285a8f509b84675f Author: Ben Dooks Date: Mon Jun 22 15:50:36 2026 +0100 mmc: cqhci: fix to missed endian conversions [ Upstream commit 0aae2c73175821a71c0e20607f8e333be5b71940 ] Fix two places where the wrong type or conversion of little-endian types to fix the following sparse warnings: drivers/mmc/host/cqhci-core.c:487:15: warning: incorrect type in assignment (different base types) drivers/mmc/host/cqhci-core.c:487:15: expected restricted __le32 [usertype] drivers/mmc/host/cqhci-core.c:487:15: got int drivers/mmc/host/cqhci-core.c:566:19: warning: incorrect type in assignment (different base types) drivers/mmc/host/cqhci-core.c:566:19: expected unsigned long long [usertype] *task_desc drivers/mmc/host/cqhci-core.c:566:19: got restricted __le64 [usertype] * Signed-off-by: Ben Dooks Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 7228d04ae8cfdfa18c2bf48cafb2d84289d42409 Author: Pengpeng Hou Date: Tue Jun 23 14:11:12 2026 +0800 mmc: moxart: report DMA completion timeout [ Upstream commit e29e650077e01dddf69bc8fac31e0cd60043aa7c ] moxart_transfer_dma() waits for the DMA completion but ignores wait_for_completion_interruptible_timeout(). It then unconditionally reports the full transfer length in data->bytes_xfered. Terminate the DMA channel and set data->error when the wait is interrupted or times out. Only report host->data_len as transferred after the completion is observed. Signed-off-by: Pengpeng Hou Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit aca5b61f01c4bbb17692273224e3ceaddfe96de0 Author: Pengpeng Hou Date: Sat Jul 4 20:22:30 2026 +0800 gpio: sifive: add missing MODULE_DEVICE_TABLE() [ Upstream commit 8fe6fa0f223f44b8b869319d1b9c383749aa147b ] The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260704122230.75964-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit f2cf823286f8909968a8a823effd0d1af12a0737 Author: David Heidelberg Date: Sat Jun 27 19:50:15 2026 +0200 dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDM 850 [ Upstream commit d529495c991a2b7d07c01622e8b3cb5ec066acee ] Add SoC ID for Qualcomm Snapdragon SDM850. Signed-off-by: David Heidelberg Reviewed-by: Konrad Dybcio Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260627-sda850-v2-1-44bf46ade42e@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2aa1e4219a1c67360356987688463c883a3f656d Author: Zhiwei Zhang <202275009@qq.com> Date: Fri Jun 26 09:59:20 2026 +0800 RDMA/rxe: Check PDs for memory window binds [ Upstream commit fbbe1d5cd7d400a98afcf337969cfdb808cb198f ] The IBTA Software Transport Verbs specification requires the QP, Memory Window and Memory Region for a Bind Memory Window operation to belong to the same HCA and protection domain. rxe only checked the QP and MW protection domain for type 2 MWs. Move the QP/MW PD check to the common bind path and also reject binding an MW to an MR from a different PD. Invalid bind requests continue to fail with IB_WC_MW_BIND_ERR. Reviewed-by: Zhu Yanjun Signed-off-by: Zhiwei Zhang <202275009@qq.com> Link: https://patch.msgid.link/tencent_FD4FB25AA4FFA845E63F5AC36CF4A46CDC0A@qq.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f6e8195ab2e07076860d7f601187e68455eac2d6 Author: David Heidelberg Date: Sat Jun 27 19:50:16 2026 +0200 soc: qcom: socinfo: Add SoC ID for SDM850 [ Upstream commit 743af1d6a8b4bfa62dd01b5c2d81b1c62ea597f7 ] Recognize the SDM850 SoC. Signed-off-by: David Heidelberg Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260627-sda850-v2-2-44bf46ade42e@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 25c13a5b8151d31ffe98bd79ab6f7944857a7a1b Author: Seyeong Kim Date: Fri Jun 19 05:00:44 2026 +0000 RDMA/irdma: Suppress PF reset on HMC error [ Upstream commit 4dc9c884c0aafac1e8d37536d88d485135e26883 ] The irdma driver currently issues an unconditional PF reset whenever the HMC Error interrupt (PFINT_OICR bit 26) fires: if (event->reg & IRDMAPFINT_OICR_HMC_ERR_M) { ibdev_err(&iwdev->ibdev, "HMC Error\n"); iwdev->rf->reset = true; } request_reset() issues an IIDC_PFR to ice. In practice a single HMC_ERR can trigger cascading PF resets, IOMMU faults during teardown, and teardown of every RDMA connection on the device. i40e handles the identically-named interrupt by reading PFHMC_ERRORINFO and PFHMC_ERRORDATA and logging them without touching device state; see commit 9c010ee0ea5f ("i40e: Suppress HMC error to Interrupt message level") which removed the reset as "not necessary". This patch mirrors that handling on irdma. With this change, repeated HMC_ERR no longer produces a reset storm and RDMA traffic on the device continues uninterrupted. Signed-off-by: Seyeong Kim Link: https://patch.msgid.link/20260619050044.1807044-1-seyeong.kim@canonical.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5a57301b3b2e99ccda234fe07d7bf407ad1ba164 Author: Pengpeng Hou Date: Sat Jul 4 23:16:33 2026 +0800 iio: adc: max1241: add missing MODULE_DEVICE_TABLE() [ Upstream commit 790a2080e0c9eabefea3561dec301172043de236 ] The driver has a match table for the spi bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 323a97943fd342c910a4a243fd3cf91add0fc78f Author: Yun Zhou Date: Fri Jul 3 14:55:48 2026 +0800 block: reject block device inodes with i_rdev == 0 in lookup_bdev() [ Upstream commit 83887ad02f30c1814bed5da3ca999f7b0f3f337c ] lookup_bdev() blindly returns inode->i_rdev without validating it. When a FUSE filesystem exposes a root inode with S_IFBLK mode but i_rdev == 0 (via rootmode=060000), any subsequent mount attempt using that path as a block device source propagates dev_t 0 into the superblock machinery. After commit 9ee5f161a4db ("fs: maintain a global device-to-superblock table") this triggers a WARNING in super_dev_register(). Reject i_rdev == 0 early with -ENODEV since no real block device driver registers major 0. Reported-by: syzbot+72fe3ea5814121fbc76e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72fe3ea5814121fbc76e Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260703065548.1135125-1-yun.zhou@windriver.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 724be334c2944e9df54604649535c88873fc16fc Author: Pengpeng Hou Date: Mon Jun 15 17:15:31 2026 +0800 soc: amlogic: meson-clk-measure: remove debugfs tree [ Upstream commit 67481152be2ec5de3529664c82054b43d6d4b9f5 ] meson_msr_probe() creates a debugfs tree with entries that reference devm-managed measurement table entries and the driver's private regmap state. The driver has no remove callback, so unbinding the device can leave those debugfs entries behind after the private data is released. Store the debugfs root and remove the subtree from a new remove callback. Signed-off-by: Pengpeng Hou Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260615091531.21964-1-pengpeng@iscas.ac.cn Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 0d75eb5f52cf0aa5a5c978806b439aa1a295a8b6 Author: Chin-Yen Lee Date: Thu Jun 25 14:15:44 2026 +0800 wifi: rtw89: wow: add QoS control field to WoWLAN ARP response for MLO [ Upstream commit 03a963f4aeda538acad50806e94ef25d95b78743 ] Some MLO APs expect WoWLAN ARP response frames to be transmitted as QoS data frames and may discard frames that do not contain a QoS Control field. Add a QoS Control field and use the QoS Data subtype when generating WoWLAN ARP responses for MLD vifs. Keep the existing frame format unchanged for non-MLO connections. This allows WoWLAN ARP responses to be accepted by MLO APs while preserving compatibility with legacy APs. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260625061545.44808-10-pkshih@realtek.com Signed-off-by: Sasha Levin commit 0bc19a2f4a26227b15176562b0bc9b4fa86a0c68 Author: William Hansen-Baird Date: Tue Jun 30 16:15:51 2026 +0200 wifi: rtlwifi: fix disabling of ASPM for RTL8723BE with AER flooding [ Upstream commit 04a46c2dbf3b516c96a1d19b72917b56055ad6c1 ] commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723") adds code which sets ppsc->support_aspm to false in _rtl_pci_update_default_setting() in order to disable ASPM. This does not, however, disable ASPM. Rather, it disables driver control of ASPM, and blocks calls to rtl_pci_enable_aspm() and rtl_pci_disable_aspm(). In some cases, the pci device supplied to the probe function has ASPM enabled. The code would therefore not disable ASPM, as it means to, but rather just leave it enabled. This was discovered through testing on a Razer Blade 14 2017. Implement a new __rtl_pci_disable_aspm(hw) function which does not check ppsc->support_aspm before disabling and call it from rtl_pci_disable_aspm(). Then move the code added in the previous commit to rtl_pci_init_aspm() to allow adding a call to __rtl_pci_disable_aspm(hw). This makes sure ASPM is disabled while still disabling driver control of ASPM to block it from being enabled later. Signed-off-by: William Hansen-Baird Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260630141553.785769-2-william.hansen.baird@gmail.com Signed-off-by: Sasha Levin commit a64fad3193fc0b1181d5ed029d6b327ecebbe709 Author: Chih-Kang Chang Date: Thu Jun 25 14:15:45 2026 +0800 wifi: rtw89: wow: only WiFi 6 chips initialize RF registers in WoWLAN mode [ Upstream commit dbff9040587e9bd6d3ee337315971957f9f76612 ] Only the WiFi 6 chips need to initialize RF register when WoWLAN download FW for some power save issue. Applying the same initialization flow to WiFi 7 chips might trigger the error 'RF parameters exceed size. path=1, idx=1500.'. This happens because normal mode uses rtw89_phy_config_rf_reg_v1(), which skips registers with addresses below 0x100. However, WoWLAN mode uses rtw89_phy_config_rf_reg_noio(), and WiFi 7 chips do not satisfy the rtw89_chip_rf_v1() condition. As a result, more RF registers are configured, causing the size overflow error. Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260625061545.44808-11-pkshih@realtek.com Signed-off-by: Sasha Levin commit 61b73a744e95ce187d533da925879ebd620a91e6 Author: William Hansen-Baird Date: Tue Jun 9 11:53:59 2026 +0200 wifi: rtlwifi: rtl8723be: Remove unnecessary irq save/restore in hw_init() [ Upstream commit 1b4cd55626b6ffa93d18848412afb912a4add585 ] rtl8723be hw_init() calls local_save_flags(flags) followed by local_irq_enable(). Later, local_irq_restore(flags) is called. This causes warnings from Lockdep on boot and modprobe, as local_irq_restore(flags) should only be called while irqs are disabled. The warning was introduced to detect this class of bug in [1]. With testing I found that all paths which call hw_init() have irqs already enabled for rtl8723be. Furthermore, the calls were originally added for the rtl8192ce in commit f78bccd79ba3 ("rtlwifi: rtl8192ce: Fix too long disable of IRQs") before later being added to most other rtlwifi drivers. Commit d3feae41a347 ("rtlwifi: Update power-save routines for 062814 driver") then replaces the call to spin_lock_irqsave() before hw_init(), and thus the codepath which caused irqs to be disabled in hw_init and prompted the original commit has been removed. The same irq save/restore pattern is also present in the hw_init() of rtl8192ce, rtl8723ae, rtl8188ee, rtl8192se and rtl8192cu, however I don't have the hardware to test them, so I did not include them in my changes. Tested on a Razer Blade 14 2017. Example of output from Lockdep prior to fix: raw_local_irq_restore() called with IRQs enabled ... Call Trace: rtl8723be_hw_init+0x5992/0x7220 [rtl8723be] ? static_obj+0x61/0xa0 rtl_pci_start+0x222/0x5c0 [rtl_pci] rtl_op_start+0x128/0x1a0 [rtlwifi] ? __kasan_check_read+0x11/0x20 drv_start+0x16c/0x550 [mac80211] ... irq event stamp: 887679 hardirqs last enabled at (887689): [] __up_console_sem+0x90/0xa0 hardirqs last disabled at (887698): [] __up_console_sem+0x75/0xa0 softirqs last enabled at (887670): [] __irq_exit_rcu+0x175/0x2f0 softirqs last disabled at (887649): [] __irq_exit_rcu+0x175/0x2f0 ---[ end trace 0000000000000000 ]--- [1] https://lore.kernel.org/all/20210111153707.10071-1-mark.rutland@arm.com/ Signed-off-by: William Hansen-Baird Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260609095359.2964193-1-william.hansen.baird@gmail.com Signed-off-by: Sasha Levin commit b2f84c6f8e8a6ea33fcf07ac33a2f1fb3cef0621 Author: Ben Dooks Date: Wed Jun 17 09:49:43 2026 +0100 dmaengine: dw-axi-dmac: fix __le32 on set of CH_CTL_H_LLI_VALID [ Upstream commit 89aba9c39bdda8a973a6ffed7c9e93321edcfc16 ] When writing the lli->ctl_hi, this is an __le32 type so the value being orred should be convered to __le32 by cpu_to_le32. Fixes 1deb96c0fa58a ("dmaegine: dw-axi-dmac: Support device_prep_dma_cyclic()") -- Note, the call to axi_chan_irq_clear() is passing lli->status_lo through which is also an __le32 but it does not seem to be set anywhere. Is this also a bug? Signed-off-by: Ben Dooks Link: https://patch.msgid.link/20260617084944.705266-1-ben.dooks@codethink.co.uk Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5b2dc86f8ad71d9d2bfc7ec93e43d2cde714fb0b Author: Yun Zhou Date: Tue Jun 30 14:03:11 2026 +0800 net: mvneta_bm: add suspend/resume support to prevent crash after resume [ Upstream commit 140be217df577961bea1ca36240439a463026cbd ] The mvneta driver uses the hardware Buffer Manager (BM) for RX buffer allocation. During suspend, mvneta disables its clock, causing BM to lose all buffer address state. On resume, mvneta_bm_port_init() re- attaches the BM pool to the NIC, but BM hardware returns stale/garbage buffer addresses. When NAPI poll processes these buffers, DMA cache sync hits an invalid virtual address causing a kernel panic: Unable to handle kernel paging request at virtual address b0000080 PC is at v7_dma_inv_range Call trace: v7_dma_inv_range from arch_sync_dma_for_cpu+0x94/0x158 arch_sync_dma_for_cpu from __dma_sync_single_for_cpu+0xc4/0x15c __dma_sync_single_for_cpu from mvneta_rx_swbm+0x6c8/0xf48 mvneta_rx_swbm from mvneta_poll+0x6fc/0x70c mvneta_poll from __napi_poll.constprop.0+0x2c/0x1e0 __napi_poll.constprop.0 from net_rx_action+0x160/0x2c4 net_rx_action from handle_softirqs+0xd8/0x2b8 handle_softirqs from run_ksoftirqd+0x30/0x94 run_ksoftirqd from smpboot_thread_fn+0x100/0x204 smpboot_thread_fn from kthread+0xf4/0x110 kthread from ret_from_fork+0x14/0x28 Fix by adding suspend/resume callbacks to the BM driver: - suspend: drain all buffers (with DMA unmapping), free the BPPE regions, and reset pool state to FREE before stopping BM and gating the clock. - resume: enable the clock, reinitialize BM defaults, and restore pool read/write pointers and size registers. Pool allocation and buffer refill are handled by mvneta_resume() through the normal mvneta_bm_port_init() path, which sees pools as FREE and performs full initialization identical to probe. Add a device_link (DL_FLAG_AUTOREMOVE_CONSUMER) in mvneta_probe to guarantee BM resumes before mvneta and suspends after mvneta. If the link cannot be created, fall back to SW buffer management to avoid a potential crash on resume due to unordered PM transitions. Signed-off-by: Yun Zhou Link: https://patch.msgid.link/20260630060311.4072140-1-yun.zhou@windriver.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 680154d070c436c101c519c950f108de70faedaa Author: Pengpeng Hou Date: Mon Jun 15 17:16:45 2026 +0800 dmaengine: pl330: remove debugfs file on teardown [ Upstream commit 0d3e3376b289cdaff5b3b6c1581999926ff1000f ] init_pl330_debugfs() creates a debugfs file with struct pl330_dmac as private data. pl330_remove() then unregisters the DMA device and frees the PL330 channel/thread state without removing that file. Keep the debugfs dentry and remove it before tearing down the DMAC state used by the debugfs show callback. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260615091645.28878-1-pengpeng@iscas.ac.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 329df0483984d57a8bc3251c00599a75e205d7e2 Author: Charles Keepax Date: Tue Jun 30 09:11:32 2026 +0100 soundwire: dmi-quirks: Disable ghost Realtek on Asus Expertbook [ Upstream commit 90af3209742db61a7f9d7d054a16165818cfc6d8 ] The Asus Expertbook B9406CAA also has a Realtek device in the ACPI that doesn't exist in the physical hardware. This confuses the machine driver into attempting to create DAI links for the device. Add a quirk to remove this device. Closes: https://github.com/thesofproject/linux/issues/5828 Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260630081132.3294488-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 873f33349f3d399a62dc6853c1acbbb30020aa55 Author: Jiayuan Chen Date: Wed Jun 10 11:02:59 2026 +0800 netfilter: ebtables: bound num_counters like nentries in do_replace() [ Upstream commit 43ae85af154b27f9a0ff602f7a01e3a7583ffdab ] do_replace_finish() allocates the counter buffer before it is validated: counterstmp = vmalloc_array(repl->num_counters, sizeof(*counterstmp)); do_replace() only checks num_counters against INT_MAX / sizeof(struct ebt_counter), so vmalloc_array() can be asked for up to 134217726 * 16 = 2147483616 bytes (~2 GiB). num_counters must in fact equal nentries: do_replace_finish() later rejects the request when repl->num_counters != t->private->nentries. get_counters() folds the per-CPU counters back into one entry per rule, so what userspace gets is bounded by nentries, never by nentries * nr_cpus. Apply the same upper bound used for nentries (MAX_EBT_ENTRIES) to the incoming num_counters so the over-sized allocation can no longer be requested. The allocation is still kept outside the ebt_mutex, since vmalloc() may sleep and trigger reclaim; only the bound is tightened. Signed-off-by: Jiayuan Chen Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 2e23f7167e4a71c500673f8ad30ec4ff209e20ad Author: Yousef Alhouseen Date: Tue Jun 30 12:12:16 2026 +0200 net: usb: rtl8150: handle link status read failures [ Upstream commit 8c9c5b9a689612dcb92a04a4218c975cd19f19d8 ] set_carrier() ignores the result of the USB control transfer and tests the stack variable supplied as its receive buffer. If the device rejects or aborts the request, that variable remains uninitialized and the driver chooses an arbitrary carrier state. Leave the existing carrier state unchanged when the link status cannot be read. A transient USB error should not be treated as link loss. Reported-by: syzbot+9db6c624635564ad813c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9db6c624635564ad813c Suggested-by: Petko Manolov Signed-off-by: Yousef Alhouseen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260630101216.10365-1-alhouseenyousef@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8e9b795a570b6565111f380898be7fb1af7b45d9 Author: Yuan Chen Date: Wed Jun 10 22:50:53 2026 +0800 libbpf: Skip bpf_object__probe_loading() when BPF token is in use [ Upstream commit d262a25d8b58b697b2a1a2fe4b0078446cc00e11 ] bpf_object__probe_loading() tries to load trivial SOCKET_FILTER and TRACEPOINT programs to verify the BPF environment works. When a BPF token is in use with restricted program type permissions, these probe loads may fail because the token does not allow the specific program types, even though BPF loading is perfectly functional. Fix by skipping the probe when a token FD is present: BPF token creation itself proves the kernel has a working BPF subsystem. Real BPF issues will be caught during actual program and map loading. Signed-off-by: Yuan Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20260610145059.113412-2-chenyuan_fl@163.com Signed-off-by: Sasha Levin commit 3e96da49091109cebf0cb806422a0527665c6cd3 Author: Haikun Zhou Date: Wed Jul 1 09:30:18 2026 +0800 drm/panel-edp: Support MB116AS01'3 edp panel [ Upstream commit 844e71ba7d7a50c5ffa29d147afaeaafb19b39e4 ] MB116AS01'3 raw edid: 00 ff ff ff ff ff ff 00 21 63 03 12 00 00 00 00 00 23 01 04 95 1a 0e 78 23 e7 05 9c 5b 56 93 27 21 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 36 1c 56 92 50 00 1c 30 60 18 a8 00 00 90 10 00 00 18 00 00 00 fd 00 28 3c 30 30 07 01 0a 20 20 20 20 20 20 00 00 00 fe 00 48 4b 43 20 4d 59 20 20 20 20 0a 20 20 00 00 00 fe 00 4d 42 31 31 36 41 53 30 31 27 33 20 20 01 cb 70 20 79 02 00 22 00 14 1c 1a 01 84 55 05 91 00 5f 00 17 00 ff 02 1b 00 09 00 07 00 2b 00 06 27 00 28 3b 00 00 81 00 13 72 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 00 00 00 00 25 01 09 1c 1a 01 1c 1a 01 28 3c 80 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e7 90 Signed-off-by: Haikun Zhou Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260701013018.2621972-1-zhouhaikun5@huaqin.corp-partner.google.com Signed-off-by: Sasha Levin commit f1be0815acc30ec458aef72fafb393b28476c27e Author: Eric Huang Date: Wed Jun 17 14:42:48 2026 -0400 drm/amdkfd: add sanity check in svm_range_is_valid [ Upstream commit aa7e29cf9a37092cf5057a612ee09f28df20258f ] to prevent svm range to be overflow or underflow. Signed-off-by: Eric Huang Reviewed-by: Philip Yang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 35606292782dd35d152cc997a95742fd9bc2bcbd Author: Yang Wang Date: Tue Jun 23 11:37:41 2026 +0800 drm/amd/pm: Validate legacy hwmgr PP table offsets [ Upstream commit 0ceb6bc43e62f0e73b282c9de8f4bc4d5498f281 ] processpptables.c walks several variable-length PPLIB tables by using offsets from the VBIOS PowerPlay table. Some paths dereference extended headers, state arrays, clock arrays, non-clock arrays, or VCE records before checking that the referenced data is inside the table buffer. Add local bounds helpers and validate the relevant offsets and entry sizes before dereferencing them. This prevents truncated or malformed legacy PowerPlay tables from driving out-of-bounds reads during hwmgr initialization and table entry lookup. Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d930abfdca53f3db4c60eb4b30069f51c8528c83 Author: Yang Wang Date: Tue Jun 23 16:36:21 2026 +0800 drm/amd/pm: Validate Vega10 PPTable subtable bounds [ Upstream commit 9914149f99fd2ddcfd2a8c1053a57d96ec43448e ] v1: Vega10 PPTable parsing uses VBIOS-provided offsets, revision fields and entry counts to locate subtables. Malformed data can otherwise drive out-of-bounds reads from soft_pp_table_size, and voltage lookup tables can overrun their fixed-size destination arrays. Add shared bounds helpers and validate fixed-size subtables, dynamic entry arrays and revision-specific layouts before consuming thermal, fan, power-tune, clock dependency, PCIE, hard-limit and voltage lookup data. v2: if ucRevId is not matched, fallback to default table size instead of returning -EINVAL. Signed-off-by: Yang Wang Reviewed-by: Asad Kamal Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 269e57807b70ba29832a866de83a3cbe00b0cc66 Author: Yang Wang Date: Tue Jun 23 16:37:07 2026 +0800 drm/amd/pm: Validate Tonga PPTable subtable bounds [ Upstream commit 53ef33c084c5778cc2dcd1efff25e31b6e231141 ] v1: Tonga PPTable parsing also relies on VBIOS offsets, revision fields and entry counts for several subtables. Malformed data can cause out-of-bounds reads, while voltage lookup tables can overrun their fixed-size destination arrays. Add common bounds helpers and validate fixed subtables, dynamic entry arrays and revision-specific layouts before consuming voltage lookup, dependency, PCIE, power-tune, hard-limit, thermal, fan, GPIO, PPM and VCE state data. v2: correct to handle get_tonga_ppm_table() return value. Signed-off-by: Yang Wang Reviewed-by: Asad Kamal Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f20fe19df5d99abc6fac744b279486cb1c2ab07f Author: Xiang Liu Date: Tue Jun 23 10:59:18 2026 +0800 drm/amd/pm: Guard VBIOS AC timing table walk [ Upstream commit 2bf6867e5953a140fc91c3159987656e44ed29fb ] Reject AC timing blocks with a stride smaller than a dword before walking VBIOS data. A zero stride can otherwise keep reg_data pinned on a nonmatching MEM_ID forever. Also bound the data-block and END marker reads by the returned VRAM_Info table size so malformed index/data sizes do not push the timing walk past the table. Signed-off-by: Xiang Liu Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2fe60f66d6ab08a5a0df484d2c2983328142dc0d Author: Yang Wang Date: Tue Jun 23 11:36:39 2026 +0800 drm/amd/pm: Validate Tonga PowerPlay state array bounds [ Upstream commit 1ac24df78c566d767a5ef05a1fe0ecc55bac248d ] process_pptables_v1_0.c builds the Tonga state array pointer from usStateArrayOffset before checking that the table buffer covers the referenced data. A truncated PowerPlay table can therefore lead to out-of-bounds reads while validating the state array. Validate the fixed table size first, then check the state array offset and entry range before dereferencing the state array. Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4487046481a55b053342c4c7273b65aeeeb46e6b Author: Yongqiang Sun Date: Tue Jun 23 15:24:11 2026 -0400 drm/amdkfd: use node XCC count for v9 CRIU control stack restore [ Upstream commit 1a0aa3c4cb207fcbf7ebd2d9ed9f1cfb4560bd2c ] set_queue_properties_from_criu() divided the checkpointed control stack size by NUM_XCC(adev->gfx.xcc_mask) (whole GPU), while the checkpoint size was recorded, the MQD buffer allocated, and the control stack restored using the per-node mask NUM_XCC(mm->dev->xcc_mask). On spatially partitioned GFX9.4.3 (CPX/QPX) these differ, so the per-XCC control stack size used for the restore memcpy could exceed the region sized for the MQD allocation, writing past the BO into adjacent kernel memory; it also broke legitimate restore on partitioned parts. Divide by the per-node XCC count so allocation and copy agree, leaving kfd_queue_acquire_buffers() to bound the size against the node's advertised control stack size. Signed-off-by: Yongqiang Sun Reviewed-by: David Francis Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 88b64ba96052256c8b1693c97981da489b0f62e4 Author: Yang Wang Date: Tue Jun 23 11:36:20 2026 +0800 drm/amd/pm: Use uploaded size for legacy custom PPTable [ Upstream commit 055a40c32f3a2dcd4d1a6f85ff4c231cf35f1b53 ] The legacy powerplay path used to allocate hardcode_pp_table from the original VBIOS PPTable size, copy only the uploaded bytes into it, and keep soft_pp_table_size unchanged. If a custom PPTable is shorter than the original table, later code can still treat the stale tail as valid table data. Treat the uploaded buffer as the complete custom PPTable: duplicate the uploaded buffer directly, replace hardcode_pp_table atomically, and set soft_pp_table_size to the uploaded size. Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bb556e5ff437c0e5228011b9618fd9b2908400e6 Author: Yang Wang Date: Tue Jun 23 00:04:33 2026 +0800 drm/amd/pm: Validate pp_table header before reading size [ Upstream commit a17e79d01f22182a9fcbe79fcbe2ad1477d43e0f ] smu_sys_set_pp_table() reads usStructureSize from the uploaded pp_table buffer before validating that the buffer contains a complete ATOM_COMMON_TABLE_HEADER. A short write can therefore make the driver read past the supplied sysfs buffer. Reject empty or header-short uploads before dereferencing the header pointer. Keep the existing structure-size check for the full uploaded table. Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6bd63ff350e1e2115b74f88f90258ca60e696a5c Author: Yang Wang Date: Tue Jun 23 11:37:23 2026 +0800 drm/amd/pm: Validate Vega hwmgr PowerPlay table bounds [ Upstream commit 3a8d8e0b7f61cd759d5d4870b6220161f8a5b114 ] The Vega hwmgr PowerPlay table parsers read fixed table fields, state array entries, or SMC PPT fields before validating that the VBIOS table buffer covers those structures. A truncated table can therefore lead to out-of-bounds reads during hwmgr initialization. Reject tables smaller than the fixed PowerPlay table. For Vega10, also validate the state array offset and entry range before dereferencing the state array. Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cfb27089cf04d8dfb9554891cffd8e426f3f78cf Author: Gangliang Xie Date: Tue Jun 23 10:42:19 2026 +0800 drm/amdgpu: add check for xcp id [ Upstream commit fa1531170d2c96060478d697fe93f1cafc0e7ddd ] check sel_xcp_id before its use Signed-off-by: Gangliang Xie Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cafbd67662675a95d6019b4f5698e72b7bac3ec0 Author: Lijo Lazar Date: Wed Jun 17 14:42:02 2026 +0530 drm/amdgpu: Guard reads in pcie state readout [ Upstream commit 230753e46a4a9d04dad6a9b5dbaeb7fd52add7d0 ] Internal US/DS switch may not be exposed in passthrough. Guard the upstream port reads to avoid a NULL dereference. Signed-off-by: Lijo Lazar Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 884ffe359625621c7d509b671d78e4a67bfa3559 Author: Matthew Jacob Date: Fri Jun 19 11:45:46 2026 -0700 drm/amdgpu: Support some Barco AMD based graphics adapters [ Upstream commit 3dc4d68ee26a7ac12069ff0562ad8935106c79b6 ] These adapters typically are only supported by Barco on the Windows platform. However, with these changes in the linux driver, multiple monitor support should work correctly. Signed-off-by: Matthew Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6441c5b430eb3df95efec01f62e9043d5573cf42 Author: Lijo Lazar Date: Thu Jun 18 10:56:54 2026 +0530 drm/amd/pm: validate vega10 profile mode inputs [ Upstream commit bf939f2a1687ef4ab815640096357f8ef5bd5fb6 ] Check for out of range profile modes and custom params that exceed 8 bits. Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9d34f2148207454472e7ea578c329efb626c6d7b Author: Asad Kamal Date: Tue Jun 16 21:24:05 2026 +0800 drm/amdgpu: validate XCP topology counts before division [ Upstream commit 0eda57ee303b4392057b7d4c32e8fda9d14cffad ] In aqua_vanjaram_get_xcp_res_info(), max_res[i] can be zero. When res_lt_xcp is true the code divides num_xcp by max_res[i], causing a divide fault. Skip the loop body for absent resources. v2: Remove redundant checks (Lijo) Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6d6b861cd078e64accbe74df1c9a0b332dfe890c Author: Lijo Lazar Date: Mon May 18 17:43:32 2026 +0530 drm/amdgpu: Validate ATIF buffer length before use [ Upstream commit b978b7d43963bbb3e2d850288f7c21ac11c3b751 ] Add a min_size parameter to amdgpu_atif_call() to validate that the returned ACPI buffer is of type ACPI_TYPE_BUFFER, holds at least a u16 size field, does not claim more data than was actually returned, and meets the minimum size required by the calling function. Each caller passes its required minimum via sizeof() or offsetof() of the expected output struct and drops its own size check. Signed-off-by: Lijo Lazar Assisted-by: Claude Sonnet (Cursor AI) Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 27eef4dcedf82f8d7fa5e679843c129462068738 Author: Lijo Lazar Date: Wed Jun 17 14:22:08 2026 +0530 drm/amdgpu: Fix kobject cleanup in xcp sysfs [ Upstream commit 62d8b452615fd7a61976a1372bb81937807968c3 ] Fix the indexing issue. Release the kobject whose init/add failed, and unwind the successfully added ones. Signed-off-by: Lijo Lazar Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 41e21fe60adfe8a45c03d20a03b8791d015146aa Author: Lijo Lazar Date: Mon May 18 17:43:44 2026 +0530 drm/amdgpu: Validate ATPX buffer length before use [ Upstream commit 916867cd75dbbc383aa6cb724556de769912157a ] Add amdgpu_atpx_buffer_validate() to check that the returned ACPI buffer is of type ACPI_TYPE_BUFFER, is large enough to hold the u16 size field, and that the BIOS-reported size does not exceed the actual allocation length or fall below the minimum required by the caller. Use it in VERIFY_INTERFACE and GET_PX_PARAMETERS callers. Signed-off-by: Lijo Lazar Assisted-by: Claude Sonnet (Cursor AI) Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 66b095839f0b3e1bfe75559fdbc6f6f2ac7c0330 Author: Lijo Lazar Date: Mon Jun 15 11:02:51 2026 +0530 drm/amdgpu: Add checks to vbios fetch through ATRM [ Upstream commit 8c3fcfc14fc1320a1155acb2dd7656fce7003bc0 ] Check if a valid buffer object is returned after ATRM call. Also, match the buffer length against requested size before copying. Signed-off-by: Lijo Lazar Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7fca266784f6b004448a5b229487fcb1fb7dc385 Author: Abhijeeth Babu Date: Thu Jun 18 00:56:11 2026 +0530 i2c: acpi: Force ELAN1300 touchpads to 100 kHz [ Upstream commit 9e9762e578db7556bea644bb5a8a2435f63544d1 ] The ELAN1300 touchpad with HID ID 04F3:3104 on the ASUS VivoBook X513UA_KM513UA exhibits severe pointer jumps and erratic movement when the I2C bus operates at 400 kHz. The system DSDT describes the touchpad using an I2cSerialBusV2 resource with a speed of 0x00061A80, corresponding to 400 kHz, on the AMDI0010:03 controller. At this speed, libinput repeatedly reports: kernel bug: Touch jump detected and discarded Add ELAN1300 to i2c_acpi_force_100khz_device_ids so that it operates at 100 kHz. Before the change, nine touch-jump events were recorded, with additional messages suppressed by libinput's rate limiter. With the bus forced to 100 kHz, no touch-jump events have been observed and the touchpad operates normally. The affected system uses BIOS X513UA.319 dated 2023-05-09. Signed-off-by: Abhijeeth Babu Acked-by: Mika Westerberg Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260617192611.125513-1-babu.jeeth@gmail.com Signed-off-by: Sasha Levin commit 6c65dfeb93ab0899b2aaac09b7a36d80b537d085 Author: Breno Leitao Date: Mon Jun 29 04:45:41 2026 -0700 netpoll: do not warn when the best-effort pool refill fails [ Upstream commit 84c0ff1efb62b0053aa265b8deb13842f68f1a74 ] refill_skbs() tops up the per-netpoll skb pool with GFP_ATOMIC and simply stops on the first allocation failure, leaving the pool partially filled; a later refill tops it up once memory frees up. The allocation failing is therefore an expected and fully handled condition, but without __GFP_NOWARN the page allocator emits a warn_alloc() splat with a full stack trace on every miss. Pass __GFP_NOWARN so the best-effort refill stays quiet, mirroring the same change in netconsole's find_skb(). Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260629-netpoll_no_warn-v1-2-f380f0b2cd0c@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f3433cfb30fdb27d67875f2a5f065990810f70bb Author: Paritosh Potukuchi Date: Fri Jun 12 10:18:15 2026 +0000 i2c: amd-asf: Validate firmware-reported length [ Upstream commit b2f4816a378dc840b605a1235b80e57c5f85b46c ] The firmware may sometimes return a length greater than the allocated buffer size, which can lead to out-of-bounds access and a kernel panic. Currently, the driver does not validate the length read from firmware. Add a check to ensure the firmware-reported length stays within the bounds of the data buffer. Signed-off-by: Paritosh Potukuchi Acked-by: Shyam Sundar S K Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260612101815.4124804-1-paritosh.potukuchi@amd.com Signed-off-by: Sasha Levin commit e291a2ccc553907bdfd6da016c3d97548099a5d1 Author: Nicolas Escande Date: Tue Jun 23 17:16:13 2026 +0200 wifi: ath12k: avoid setting 320MHz support on non 6GHz band [ Upstream commit eaf478b3ea68e1b5df659acd24c4df5850e12325 ] On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz related features on the 5GHz band while it should not: Wiphy phy1 [...] Band 2: [...] EHT Iftypes: managed [...] EHT PHY Capabilities: (0xe2ffdbe018778000): 320MHz in 6GHz Supported [...] Beamformee SS (320MHz): 7 [...] Number Of Sounding Dimensions (320MHz): 3 [...] EHT MCS/NSS: (0x22222222222222222200000000): This is also reflected in the beacons sent by a mesh interface started on that band. They erroneously advertise 320MHz support too. This should not happen as IEEE Std 802.11-2024, subclause 9.4.2.323.3 says we should not set the 320MHz related fields when not operating on a 6GHz band. For example it says about Bit 0 "Support For 320 MHz In 6 GHz" "Reserved if the EHT Capabilities element is indicating capabilities for the 2.4 GHz or 5 GHz bands." Fix this by clearing the related bits when converting from WMI eht phy capabilities to mac80211 phy capabilities, for bands other than 6GHz. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1 Signed-off-by: Nicolas Escande Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260623151613.72113-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 1f80e8bbe7c25fc9f8d41f0fe9d961110f3cb473 Author: Ruoyu Wang Date: Thu Jun 18 02:22:02 2026 +0800 memory: stm32_omm: initialize ret in stm32_omm_set_amcr [ Upstream commit 1527acf2295cf2d6e11e3e9b121d63709667e6e7 ] stm32_omm_set_amcr() returns ret after checking whether the AMCR value matches the device tree description. On the normal matching path ret is not otherwise assigned, so initialize it to 0 before the checks. Signed-off-by: Ruoyu Wang Reviewed-by: Patrice Chotard Link: https://patch.msgid.link/20260617182202.961843-1-ruoyuw560@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 81673a22e1ee57341e7e2bd2f2182ff00c125204 Author: Jiawen Liu <1298662399@qq.com> Date: Sat Jun 20 12:39:29 2026 +0400 spi: bcmbca-hsspi: return error from failed controller suspend [ Upstream commit faa878d4805ca375738294bc52eae310eb287b16 ] spi_controller_suspend() can fail if pending transfers cannot stop. bcmbca_hsspi_suspend() ignored the error and still disabled the PLL and core clocks. Return the error before disabling the clocks. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_54F5634545908FBA724E758054BF03953808@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8af06aa5e860bc194de1c995c9eaedc0d29f44a9 Author: Jiawen Liu <1298662399@qq.com> Date: Sat Jun 20 12:39:31 2026 +0400 spi: nxp-fspi: disable runtime PM on probe failures [ Upstream commit 5d14285d60ba95561609a293064654a0c7d7d928 ] nxp_fspi_probe() enables runtime PM and autosuspend before several operations that can fail. Some failure paths returned directly before the devm cleanup action was installed, leaving runtime PM enabled. Route those failures through a common runtime PM cleanup path. Use pm_runtime_resume_and_get() for the initial clock enable. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_8FC0B8DFAF4AE67AEBA20548045D53A77707@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5a6dd98304fa15b9747944430ba1538691cde6f1 Author: Jiawen Liu <1298662399@qq.com> Date: Sat Jun 20 12:39:30 2026 +0400 spi: fsl-dspi: clean up after failed suspend and resume [ Upstream commit 2543355f3da56a297e3803ccb5d29f4dce5f18f1 ] dspi_suspend() disabled the IRQ before spi_controller_suspend(), but ignored a suspend failure and kept tearing the device down. Restore the IRQ and return the error if suspend fails. dspi_resume() also left the clock prepared if controller resume or hardware init failed. Route those failures through clock cleanup. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_427FA55E3D59112524886E9C931CA0F92F06@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9e93c02b6bf06a95a3fcc469736a043e59b63326 Author: Damon Ding Date: Thu Jun 25 15:19:16 2026 +0800 drm/panel-edp: Add BOE NE160QDM-NY1 panel [ Upstream commit be4f10d44757211fd656fa57f37034657f26c883 ] Add an entry for the BOE NE160QDM-NY1 eDP panel. The panel's AUX backlight functionality is verified and working on the RK3576 EVB1 board. edid-decode (hex): 00 ff ff ff ff ff ff 00 09 e5 85 09 00 00 00 00 1c 1e 01 04 b5 22 15 78 03 7c e5 a4 55 4c 9f 26 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 6b 6e 00 a0 a0 40 84 60 30 20 36 00 58 d7 10 00 00 1a 00 00 00 fd 0c 3c a5 1f 1f 4e 01 0a 20 20 20 20 20 20 00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 45 31 36 30 51 44 4d 2d 4e 59 31 0a 01 ed 02 03 1d 00 e3 05 80 00 e6 06 05 01 6a 6a 24 6d 1a 00 00 02 03 3c a5 00 04 6a 24 6a 24 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 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 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 00 00 ff Signed-off-by: Damon Ding Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260625071916.744686-1-damon.ding@rock-chips.com Signed-off-by: Sasha Levin commit 8c249f45dde839ca6f3feffce0741da9d0d6690f Author: Jiawen Liu <1298662399@qq.com> Date: Thu Jun 18 20:45:17 2026 +0400 spi: bcm63xx-hsspi: return error from failed controller suspend [ Upstream commit 3b5414d76a0381db77b9694537254af7acfa187a ] spi_controller_suspend() can fail if the SPI core cannot stop the controller. bcm63xx_hsspi_suspend() ignored that error, disabled the PLL and core clocks, and returned success. Return the suspend error before disabling the clocks. Signed-off-by: Jiawen Liu <1298662399@qq.com> Acked-by: William Zhang Link: https://patch.msgid.link/tencent_B5A06807924A77C8690730EBF7A052AABE05@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5bbe145daa754604311b19580682133da95e30ea Author: Jiawen Liu <1298662399@qq.com> Date: Thu Jun 18 20:45:16 2026 +0400 spi: bcm63xx: return error from failed controller suspend [ Upstream commit bbbc1ef5b35341c5122418a14f8924688a4bb954 ] spi_controller_suspend() can fail if the SPI core cannot stop the controller. bcm63xx_spi_suspend() ignored that error, disabled the controller clock, and returned success. Return the suspend error before tearing down the clock. Signed-off-by: Jiawen Liu <1298662399@qq.com> Link: https://patch.msgid.link/tencent_0BD7D4091B90EC17A8B2BA5EBA8803725905@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b902b2bf21ed0ce106b243971838bd1e30b8e5d2 Author: Jiawen Liu <1298662399@qq.com> Date: Thu Jun 18 20:45:18 2026 +0400 spi: bcm-qspi: return error from failed controller suspend [ Upstream commit 44d09ef0ba690ac46d17eb05c12a47a5dd75e231 ] spi_controller_suspend() can fail if the SPI core cannot stop the controller. bcm_qspi_suspend() ignored that error, disabled the controller clock, uninitialized the hardware, and returned success. Return the suspend error before tearing down the clock and hardware state. Signed-off-by: Jiawen Liu <1298662399@qq.com> Reviewed-by: Kamal Dasu Link: https://patch.msgid.link/tencent_21BF5F9512F56D45FD9018BAF14ED2805808@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a78ed42facf1567ac6f87fef2e2a711e2d363f29 Author: Guopeng Zhang Date: Mon Jun 1 11:29:11 2026 +0800 fs/namespace: notify pollers of legacy propagation changes [ Upstream commit 0ae44a20835e5cf37d03a83e70c92e92deda3703 ] Changing mount propagation through the legacy mount API changes user-visible mountinfo contents, including the shared: and master: optional fields. The mount_setattr() path already touches the mount namespace after change_mnt_propagation(), so pollers of /proc//mountinfo are woken when the namespace event changes. The legacy mount --make-* path also changes propagation through change_mnt_propagation(), and MOVE_MOUNT_SET_GROUP updates the propagation relationship of the target mount. Both paths currently return without touching the affected mount namespace. As a result, userspace polling /proc//mountinfo can miss these propagation-only changes even though mountinfo has changed. A simple reproducer that polls /proc/self/mountinfo while changing propagation shows the inconsistency. Before this change: legacy MS_SHARED: poll ret=0 revents=0x0 mount_setattr MS_SHARED: poll ret=1 revents=0xa After this change: legacy MS_SHARED: poll ret=1 revents=0xa mount_setattr MS_SHARED: poll ret=1 revents=0xa Fix this by touching the affected mount namespace after successful propagation changes in do_change_type() and do_set_group(). Signed-off-by: Guopeng Zhang Link: https://patch.msgid.link/20260601032911.940507-1-guopeng.zhang@linux.dev Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 00ad8fb259e95e7c7b5aa35ed5aaccbf824c4120 Author: Zide Chen Date: Thu Jun 11 09:00:26 2026 -0700 perf/x86/intel/uncore: Fix PCI PMU cleanup on setup failure [ Upstream commit 003267cb94e21d762eb72d6977d84f44f1705bb7 ] When uncore_pci_pmu_register() fails, pmu->boxes[die] is set to NULL before returning. In the uncore_pci_remove() path, this causes uncore_pci_pmu_unregister() to be skipped entirely, leaking pmu->activeboxes. In the uncore_bus_notify() path, uncore_pci_pmu_unregister() may still be called and must exit early when pmu->boxes[die] is NULL to avoid a NULL pointer dereference, and to ensure activeboxes is only decremented for a previously active box. Additionally, since pci_get_drvdata() returns NULL on registration failure, uncore_pci_remove() can no longer treat NULL drvdata as an indicator of an auxiliary PCI device. Remove the associated WARN_ON_ONCE(). Signed-off-by: Zide Chen Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dapeng Mi Link: https://sashiko.dev/#/patchset/20260512233048.9577-1-zide.chen@intel.com?part=1 Link: https://patch.msgid.link/20260611160033.66760-2-zide.chen@intel.com Signed-off-by: Sasha Levin commit 2ff10d259445316ae558a1eafa68308f928e09df Author: Zizhi Wo Date: Mon Jun 29 21:09:43 2026 +0800 fat: reject name longer than NAME_MAX in msdos_format_name() [ Upstream commit 9d7ed813ee5ff0d469bd99630828ed6fdef4e8da ] msdos_format_name() performs no upper-bound check on the input name length. It silently truncates an arbitrarily long name into the 8.3 form (11 bytes) and returns success. The subsequent fat_scan() then matches only against these 11 truncated bytes, so it returns an inode as long as any entry with the same 8.3 name exists on disk. For example, passing a 300-byte name of all 'A's returns 0 with res set to "AAAAAAAA" (8 'A's + 3 padding spaces), reporting success for a name far longer than NAME_MAX. As a result, when a user calls open() on a path component longer than NAME_MAX (255) bytes, the VFS only enforces PATH_MAX, not the length of an individual component. The dentry keeps the original long name but gets an inode attached and becomes positive. Later in vfs_open() -> fsnotify_open() -> fanotify_info_copy_name() triggers WARN_ON_ONCE(), and the event is reported to userspace with an empty name. vfat is not affected, as create goes through xlate_to_uni() which refuses names longer than FAT_LFN_LEN. Fix this by checking 'len > NAME_MAX' at the entry of msdos_format_name(), the single entry point for all msdos name handling, aligning with the NAME_MAX check that xfs/9p/ceph/simple_lookup() perform at lookup. Signed-off-by: Zizhi Wo Link: https://patch.msgid.link/20260629130943.3671939-1-wozizhi@huaweicloud.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 0211c538cc7b74c96307619cae3c4f5464f04d85 Author: Dapeng Mi Date: Tue Jun 16 12:46:53 2026 +0800 perf/core: Fix kernel register info leak via hardware skid [ Upstream commit 166f10836a653dfa280d4335603b52f685b8b1ef ] An unprivileged hardware perf event using exclude_kernel=1 can leak kernel register data to user space via PERF_SAMPLE_REGS_INTR or PERF_SAMPLE_IP. Due to hardware skid, a PMI may trigger after the CPU has already entered kernel space (Ring 0), bypassing the perf_allow_kernel() privilege barrier. This security vulnerability is severely exacerbated by upcoming support for SIMD register sampling via XSAVES, which could expose sensitive kernel FPU states (such as active cryptographic keys). Fix this by ensuring that sampled register data is dropped if the event's exclude_kernel attribute is set but the PMI catches the CPU in kernel mode. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/20260529085613.CCAFB1F00893@smtp.kernel.org/ Link: https://patch.msgid.link/20260616044654.3468742-8-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit d87eb804028e28ce4c7f0bf1a670f4ce1e0535cd Author: Thomas Zimmermann Date: Thu Jun 25 11:39:37 2026 +0200 drm/sysfb: simpledrm: Validate mmap size against framebuffer size [ Upstream commit 127d52f9c64b1d9aab6226c4a1f38c37fb7254dc ] The size of the mmap'ed framebuffer could be smaller than the minimum required framebuffer size. Validate the resource size against the framebuffer size. Buggy firmware that triggers this check should be fixed up with a quirk on a case-by-case base. v3: - fix size checks (Sashiko) - improve error message for alignment check (Thierry) - do not store aligned size value Signed-off-by: Thomas Zimmermann Suggested-by: Sashiko Reviewed-by: Thierry Reding Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260625094509.157581-6-tzimmermann@suse.de Signed-off-by: Sasha Levin commit fb4a3facba36aa785d3b7b9242b6cdd221284b9f Author: Dapeng Mi Date: Tue Jun 16 12:46:49 2026 +0800 perf/x86/intel: Fallback to sw branch type decoding if no hw decoding [ Upstream commit 170cc6b02e3d5203ccaa49ffea1ee5a7ab08c885 ] intel_pmu_lbr_filter() currently assumes arch-LBR provides hardware branch-type decoding and skips software decoding on that path. However, arch-LBR may not always expose branch-type information. In that case, treating entries as hardware-decoded can misclassify sampled branches (for example, defaulting to JCC), which breaks branch-type filtering results. Fix this by using software branch-type decoding when hardware branch-type decoding is unavailable (that is, when x86_lbr_type is not enabled). This keeps branch classification and filtering behavior correct across arch-LBR configurations. Since x86_lbr_type is only set to true when arch-LBR is supported, it's unnecessary to check if the CPU has the arch-LBR feature. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260616044654.3468742-4-dapeng1.mi@linux.intel.com Signed-off-by: Sasha Levin commit e85198f3f6b424e133321942e68b067e9b81b0c2 Author: Bryam Vargas Date: Tue Jun 16 20:56:15 2026 -0500 iio: accel: fxls8962af: clamp the device-reported FIFO sample count [ Upstream commit 2f8225b91eb478ca2e9aec8aaef4d229765bcebe ] fxls8962af_fifo_flush() transfers the sample count the device reports in BUF_STATUS into an on-stack buffer sized for FXLS8962AF_FIFO_LENGTH (32) samples, but the count is a 6-bit field (0..63) that is only checked for zero. A device, or an attacker on the I2C/SPI bus, reporting 33..63 overflows the buffer by up to 186 bytes: a stack out-of-bounds write. Clamp the count to FXLS8962AF_FIFO_LENGTH before the transfer, mirroring the clamp already applied in fxls8962af_set_watermark(). Conforming hardware reports at most that many samples and is unaffected. Signed-off-by: Bryam Vargas Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit ee5298ac5f2b3ace3aa056a5d5aa8d2c066633a8 Author: Mithil Bavishi Date: Wed Jun 3 22:40:48 2026 -0700 ARM: OMAP2+: Add CFI type for omap4_finish_suspend [ Upstream commit 4a7b197ad28d71f9fac873f283b4408df3fdb287 ] With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower() because omap_pm_ops.finish_suspend points directly to the assembly routine omap4_finish_suspend, which lacks the expected KCFI type metadata. Annotate omap4_finish_suspend with SYM_TYPED_FUNC_START so the assembly routine carries the KCFI type metadata. Signed-off-by: Mithil Bavishi Reviewed-by: Nathan Chancellor Reviewed-by: Andreas Kemnade Link: https://patch.msgid.link/20260604054048.18980-1-bavishimithil@gmail.com Signed-off-by: Kevin Hilman (TI) Signed-off-by: Sasha Levin commit b220b2bb99b3c8e7b3c79afd0daed6eada4095a2 Author: Joe Simmons-Talbott Date: Fri Jun 26 16:29:22 2026 -0400 selftests/cgroup: Adjust cpu test duration based on HZ [ Upstream commit a2703c2980c0776e9be7d8f9e144afd054dddb12 ] For lower HZ values a quota of 1000us is much lower than the amount of microseconds per tick which makes the tests test_cpucg_max and test_cpugc_max_nested fail. Increase the test duration to accommodate for lower HZ values. Link: https://lore.kernel.org/lkml/20260625203307.1114538-1-joest@redhat.com/ Signed-off-by: Joe Simmons-Talbott Acked-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 62549edc55291564652f169fe3977c29c9b15dbc Author: Uwe Kleine-König (The Capable Hub) Date: Fri Jun 26 08:04:23 2026 +0200 regmap: maple: Workaround for another false-positive compiler warning [ Upstream commit dffd32eb2b0e714a8ae23f98518ad7152cb06369 ] Similar to the issue fixed in commit 542440fd7b30 ("regmap: maple: work around gcc-14.1 false-positive warning"), I see an uninitialized warning for upper_index and upper_last. Happens with arc-linux-gnu-gcc (Debian 15.3.0-1) 15.3.0 on an allmodconfig for ARCH=arc. Signed-off-by: Uwe Kleine-König (The Capable Hub) Link: https://patch.msgid.link/20260626060427.2548578-2-u.kleine-koenig@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 709c3865ede5e9c595fc867e4b168d029d4f4f39 Author: Haoxiang Li Date: Mon Jun 22 23:11:27 2026 +0800 ASoC: hdac_hdmi: Fix resource cleanup on probe failure [ Upstream commit 785903b7770f19ea05b8a76081dff691c56fa771 ] hdac_hdmi_dev_probe() gets the HDA link before allocating and initializing the HDMI codec private data. Several later error paths return directly without dropping the link reference, leaving the hlink refcount unbalanced. Release the link reference on probe failures. Also turn display power off if the failure happens after it has been enabled. This issue was dicussed in: https://lore.kernel.org/all/s5h1s0esk8o.wl-tiwai@suse.de/ I think the paths fixed here are probe failure paths: the device has not been fully initialized or bound, and runtime PM suspend cannot be relied on to balance the reference taken during probe. Signed-off-by: Haoxiang Li Link: https://patch.msgid.link/20260622151127.1198196-1-haoxiang_li2024@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 32b1dce444ace86469af043e85010c3dc3392e86 Author: Pengpeng Hou Date: Mon Jun 15 14:45:48 2026 +0800 ASoC: tlv320aic26: remove keyclick sysfs file [ Upstream commit ae375f8d063d71e598c0d7e14fc056154c84d7a7 ] aic26_probe() creates the keyclick sysfs file on the component device. The file callback uses the ASoC component pointer stored in the driver private data. There is no matching remove callback, so the sysfs file can remain after the component is removed while its backing component state is gone. Add a component remove callback that removes the keyclick file. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260615064549.34110-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2f5641f9740eaecefc528e34420503ba452a8e8b Author: William Theesfeld Date: Mon Jun 1 16:35:00 2026 -0400 clk: zynq: handle kasprintf() failure in periph_clk registration [ Upstream commit d4d0d335e8d37c6c7e1c5664c7664288eca5a09b ] zynq_clk_register_periph_clk() ignores the return value of the two kasprintf() calls used to build the mux and divider clock names, and passes the resulting (possibly NULL) pointers straight into clk_register_mux(), clk_register_divider() and clk_register_gate() as the clock '"'name'"' argument. On allocation failure that name later gets dereferenced by the clock framework (e.g. in debugfs name formatting), causing a NULL-pointer dereference. Check both kasprintf() returns. On failure unwind any allocated name buffer and the spinlock, then fall through to the existing err label which sets clks[] to ERR_PTR(-ENOMEM). Freeing the spinlock on the error path is correct here because no clk_register_*() call has had a chance to take ownership of it; the success path intentionally hands it off to the registered clocks. The neighbouring zynq_clk_register_fclk() in the same file already uses this per-allocation goto-label cleanup pattern; this change brings periph_clk into line with it. Signed-off-by: William Theesfeld Reviewed-by: Brian Masney Reviewed-by: Michal Simek Signed-off-by: Brian Masney Signed-off-by: Sasha Levin commit 69b25b97d439b244ce147f9383de56e27eb991bf Author: Pengpeng Hou Date: Tue Jun 16 23:11:29 2026 +0800 spi: qpic-snand: free OOB buffer with ECC context [ Upstream commit 5504e50ffbcf97b3b6ed3740532497922c96a1f1 ] qcom_spi_ecc_init_ctx_pipelined() allocates qspi->oob_buf as part of the pipelined ECC context setup. The buffer is then used by the raw and ECC page I/O paths through the NAND ECC context. The matching cleanup callback only frees the qpic_ecc structure, and the init error path also skips the OOB buffer after it has been allocated. Free qspi->oob_buf on both paths and clear the pointer so the ECC context teardown owns all resources allocated during init. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260616151129.76060-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f6e11b1c35a682fa6fc63d2d7f87255fb511d299 Author: Pengpeng Hou Date: Mon Jun 15 14:44:56 2026 +0800 ASoC: sma1303: remove fault-check sysfs group on remove [ Upstream commit ce3733792d38ade8df8ce288a96ff0c6ad858bf3 ] sma1303_i2c_probe() creates a sysfs group that exposes the fault-check controls. The check_fault_status store callback can queue check_fault_work. sma1303_i2c_remove() only cancels the delayed work. It does not remove the sysfs group, so the controls can remain published after remove while their callbacks still use the driver data and can queue the work again. Remove the sysfs group before cancelling the delayed work. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260615064456.28615-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 65f32bb18f5e452294ac24dc167d0166cd92fb5b Author: Kemeng Shi Date: Tue Jun 23 15:51:32 2026 +0800 irqdomain: Plug leak in irq_domain_alloc_irqs_locked() error path [ Upstream commit 13856e22217fbf7c1200633716ff87ccb50fd89a ] When irq_domain_trim_hierarchy() fails in irq_domain_alloc_irqs_locked(), the error handling path fails to undo the hierarchy allocations. Add the missing cleanup. [ tglx: Massage change log ] Signed-off-by: Kemeng Shi Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260623075134.4432-2-shikemeng@huaweicloud.com Signed-off-by: Sasha Levin commit 41088f2032937beefaf9c8f4ca40e1ea28a5918a Author: Cen Zhang Date: Fri Jun 19 01:00:26 2026 +0800 ALSA: usb-audio: Release components on probe errors [ Upstream commit 3213bf9885e3356fff12ac18b12d4c2fb4687734 ] usb_audio_probe() can create USB-audio component resources before the first interface is recorded in chip->num_interfaces. If a later probe step fails, the error path drops chip->active and frees the card directly when no interfaces have been registered. Normal disconnect first releases USB-audio components in a fixed order before the card is freed. The first-interface probe error path skipped that sequence, so partially initialized PCM, endpoint, MIDI, media, or mixer resources could be left for the card private_free path without their disconnect handling having run. Move the existing normal-disconnect component release sequence into a helper and call it from the zero-interface probe error path before snd_card_free(). Keep the normal disconnect ordering unchanged: PCM streams, endpoint resources, MIDI 1.0 resources, MIDI 2.0 resources, media device cleanup, then mixer resources. Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260618170026.192212-1-zzzccc427@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 54116b5fc4d0af29ce65274ec5bdcea3ca21a54c Author: Pengpeng Hou Date: Wed Jun 24 22:40:15 2026 +0800 media: cec: stm32: return an error when log-address wait times out [ Upstream commit 3bc2e4a26465386332ee1a40219d8dafba335b0b ] stm32_cec_adap_log_addr() waits for TXSOM to clear before disabling CEC and updating the logical address registers. The wait result is ignored, so a timeout can still be reported as a successful logical address update. Return the polling error before touching the address registers. Compute the address mask only for valid logical addresses so the invalid-address path does not evaluate a shift based on CEC_LOG_ADDR_INVALID. Signed-off-by: Pengpeng Hou Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit b97aa8f8ec988b60fea9f9579ee8d4ab66c9cc97 Author: Nícolas F. R. A. Prado Date: Fri Jun 26 11:47:22 2026 -0400 ALSA: hda: Force resume if acomp notified during system suspend [ Upstream commit c0933934d5d96fc641e8d0025f9099e554a7b47a ] Currently if an HDMI cable is connected while the system is suspended, the HDMI audio jack status stays off after resume. This is due to the jack state not being synced by the HDA HDMI codec device's runtime resume, as that never happens if the device was runtime suspended before the system suspended, or by the acomp notification triggered from the DRM side if that happens before the HDA HDMI codec device has resumed. To fix this, if snd_hda_hdmi_acomp_pin_eld_notify() gets called before the HDA HDMI codec device has resumed, mark it to be forcefully runtime resumed at the next PM complete time. Do this using a separate acomp_requested_resume flag that can be temporarily set without overwriting forced_resume for drivers that always want to force resume. Assisted-by: Copilot:claude-sonnet-4.6 Signed-off-by: Nícolas F. R. A. Prado Link: https://patch.msgid.link/20260626-hda-force-resume-eld-notify-v1-1-a92cb01393e0@collabora.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8c804241ce99af312577cdc97634aa8bea06ae1d Author: Fu Hao Date: Mon Jun 15 20:22:40 2026 +0800 ALSA: hda: Add support for Hygon family 18h model 5h HD-Audio [ Upstream commit 41212ff3e4ed475d9f91d26b5324075087702987 ] Add the new PCI ID 0x1d94 0x14a9 for Hygon family 18h model 5h HDA controller. Signed-off-by: Fu Hao Link: https://patch.msgid.link/8b38f2941375553e4246167736c6acb5a541e833.1781523812.git.fuhao@open-hieco.net Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5073bafe7a8f828028a9dad83e47b132f0bcd1e0 Author: Kryštof Černý Date: Fri Jun 12 09:55:07 2026 +0200 w1: ds2482: add OF device match table [ Upstream commit 53f33fd74d3993af0fbb5494b5be709f6ca6b712 ] Add an of_device_id table and hook it into the i2c driver so the ds2482/ds2484 can be matched and auto-probed from Device Tree. This allows automatic module loading when instantiated via DT. Signed-off-by: Kryštof Černý Link: https://patch.msgid.link/20260612-w1-of-autoload-v1-1-74e8a17626e6@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit bd78ad6bfa958b2077fc493043fc63814a2720f5 Author: Ruoyu Wang Date: Wed Jun 17 15:20:35 2026 +0800 HID: wacom: avoid copying Bluetooth input reports [ Upstream commit 8310cdeefc8a14d2093c3234b570c7805c20bcbf ] wacom_intuos_bt_irq() duplicates the received Bluetooth report with kmemdup() so that it can pass 10-byte input report payloads to the common Intuos parser. The helper then copies each payload back into wacom->data before calling wacom_intuos_irq(). Avoid the allocation and copy by temporarily pointing wacom->data at the current 10-byte payload while the common parser runs, then restoring the original report pointer. The Bluetooth report parser keeps using the original report buffer for dispatch and battery parsing, while the common parser sees the same payload bytes as before. This also removes the unchecked kmemdup() result from the Bluetooth IRQ path. Suggested-by: Jason Gerecke Signed-off-by: Ruoyu Wang Reviewed-by: Jason Gerecke Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c51a3ad1477cf476367369b2b36d69ad61878bbb Author: Christian Brauner Date: Mon Jun 15 15:19:57 2026 +0200 selftests/filesystems/overlayfs: fix set_layers_via_fds link error [ Upstream commit e5804b1024193c91ff2648403beda882cb4f8b6c ] set_layers_via_fds.c calls open_tree() directly, but that wrapper is not provided by all C libraries, so the test fails to link with "undefined reference to open_tree" on toolchains without it. Use sys_open_tree() from ../wrappers.h, the syscall wrapper already used for move_mount(), fsmount() and friends here. This is also a prerequisite for building the new idmapped_mounts test added to this directory. Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-8-7381632aa402@kernel.org Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 220414ffec1b692b8930cefbdf30367cc30926b6 Author: Pengpeng Hou Date: Wed Jun 24 13:37:44 2026 +0800 gpio: pca9570: Use I2C match data [ Upstream commit 415c63896b76fd98883e190bc7518383cb01779c ] The driver stores chip metadata in both the OF match table and the I2C id table, but probe currently reads it with device_get_match_data(). That helper only returns firmware-node match data, so an I2C-id/modalias match can leave chip_data NULL before the driver dereferences it to read ngpio. Use i2c_get_match_data() so the I2C id table driver_data is consumed when firmware match data is not present. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260624053744.72612-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit e0f1d03b9a648bcbc47216332676c4f450aa8061 Author: YiPeng Chai Date: Tue Jun 16 16:18:22 2026 +0800 drm/amdgpu: add bounds check to prevent array overflow [ Upstream commit db15c49a17b8fab9ada38f3a548e5353d7d6b1a8 ] Add bounds check to prevent array overflow. v2: Add warning messages. Signed-off-by: YiPeng Chai Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9614f912f9aec21bd1a6b70c6871e437b1fc302d Author: Gangliang Xie Date: Tue Jun 16 17:04:47 2026 +0800 drm/amdgpu: add buf length check [ Upstream commit 473f99e4a262776141366f7fb10f101d0f22b019 ] add buf length check before using it to access data Signed-off-by: Gangliang Xie Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d09f84813b4a67e1c2ca734335569fc61739cd7c Author: Ruoyu Wang Date: Mon Jun 8 14:36:38 2026 +0800 drm/radeon: avoid double free in r600 DPM cleanup [ Upstream commit d3f30034f861a585f8e487ae1555d9f288a96f87 ] r600_parse_extended_power_table() uses manual kfree() calls for some early allocation failures, but the freed pointers are left in the dynamic power-management state. If device teardown later calls r600_free_extended_power_table(), those stale pointers can be freed again. Use the common extended power table cleanup helper for those early failure paths as well, and clear each pointer after freeing it so repeated cleanup stays safe. Signed-off-by: Ruoyu Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 95437a99037738e926aeb38bd645f792dc88ab71 Author: Charlene Liu Date: Thu May 21 20:36:01 2026 -0400 drm/amd/display: fix max dispclk_khz/dppclk_khz double 1000 [ Upstream commit f48124ff35357d05a98d9cd5cb7982e7e5509003 ] [why] Fix regresson caused by double roundup and index out of range Reviewed-by: Dillon Varone Reviewed-by: Dmytro Laktyushkin Signed-off-by: Charlene Liu Signed-off-by: Aurabindo Pillai Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7a8c7e9212c35e69a8c385d79fdcd7c403f1cf37 Author: Asad Kamal Date: Wed Jun 3 17:30:29 2026 +0800 drm/amdgpu: Gate debugfs MMIO access on kernel lockdown [ Upstream commit 17ac73b24006700f50972d37e297dec1f523c14a ] amdgpu_regs, amdgpu_regs2, and related debugfs nodes allow arbitrary MMIO read/write via RREG32/WREG32 without checking security_locked_down(). On kernel_lockdown=integrity systems this bypasses the same restrictions as /dev/mem and PCI config space sysfs. Check LOCKDOWN_PCI_ACCESS (matching pci-sysfs) at the entry of every debugfs handler that performs direct register access. v2: Use consistent check as per previous check to use LOCKDOWN_DEBUGFS(Lijo) v3: Do not create any entry from amdgpu_debugfs_regs_init() if LOCKDOWN_PCI_ACCESS is active and log once. (Lijo) Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 29000475b125d1c8dda42d704b7d6bfa293a658c Author: Asad Kamal Date: Wed Jun 3 02:03:33 2026 +0800 drm/amd/pm: Validate OD DPM triples before mutating tables [ Upstream commit b390cb9d776039fc4f0be13b2649299079227d12 ] vega10_odn_edit_dpm_table() and smu7_odn_edit_dpm_table() could mutate the live ODN table for valid triples, then return 0 after detecting a truncated buffer or out-of-range index. Validate all (index, clock, voltage) triples first and return -EINVAL on any failure; only then apply updates. v2: Use distinct message for different error case, removed unused input_level from validation loop (Lijo) v3: Reject negative level indices, input[] is long but was compared only against unsigned table bounds, so negative values could pass and truncate when assigned to uint32_t input_level. Set DPMTABLE_OD_UPDATE_SCLK/MCLK only after validation passes, so a failed sysfs write does not leave need_update_dpm_table set for a later commit. Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 86229fb465756fda6bc8b200a1c59bbc55959742 Author: Jesse Zhang Date: Mon Mar 30 09:33:27 2026 +0800 drm/amdgpu/mes_v12_0: use mes schedule pipe for legacy queues on unified MES [ Upstream commit 5ec4cc91708370847772f2a2397316dbd8d8f066 ] when suspend_all_gangs is issued to pipe0 MES during system suspend or runtime PM, pipe0 can only suspend and resume queues it has tracked. KCQs registered with a non-zero pipe slot may not be correctly handled, leaving them in an inconsistent state after resume. v3: fix the schedule pipe issue v4: use schedule pipe for KQ resets Reviewed-by: Michael Chen Suggested-by: Michael Chen Suggested-by: Alex Deucher Suggested-by: Shaoyun Liu Signed-off-by: Jesse Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0c42724fcbcdf58c6be63760938bb258b79f933a Author: Terry Hsiao Date: Mon Jun 8 16:03:10 2026 +0800 drm/panel-edp: Add BOE NV116WH2-M30, BOE NT116WHM-N21, BOE NV116FH1-M31, BOE NV116FH1-M30 [ Upstream commit d4ae726fc08024b359e9cacf2507f1c256b9d71c ] The raw EDIDs for each panel: BOE NV116WH2-M30 00 ff ff ff ff ff ff 00 09 e5 6e 38 00 00 00 00 0a 24 01 04 95 1a 0e 78 03 0b 55 9a 5f 58 95 28 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 96 1d 56 c8 50 00 26 30 30 20 36 00 00 90 10 00 00 1a b9 13 56 c8 50 00 26 30 30 20 36 00 00 90 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 40 ff 0a 3c 7d 0f 0c 17 7d 00 00 00 00 80 BOE NT116WHM-N21 00 ff ff ff ff ff ff 00 09 e5 79 38 00 00 00 00 08 24 01 04 95 1a 0e 78 03 3a d5 95 5c 58 94 29 24 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 38 1d 56 c8 50 00 1c 30 30 20 36 00 00 90 10 00 00 1a 7b 13 56 c8 50 00 1c 30 30 20 36 00 00 90 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 40 ff 0a 3c 7d 0f 0c 17 7d 00 00 00 00 7a BOE NV116FH1-M31 00 ff ff ff ff ff ff 00 09 e5 8b 38 01 ff 00 00 0c 24 01 04 a5 1a 0e 78 03 50 d5 9c 55 52 8f 27 15 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 9a 36 80 a0 70 38 28 40 30 20 35 00 00 90 10 00 00 1a 67 24 80 a0 70 38 28 40 30 20 35 00 00 90 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 36 ff 0a 3c 96 0f 0b 1a 96 00 00 00 01 cd 70 20 79 02 00 20 00 0c 9a 0e 00 8b 38 00 00 00 00 0c 1a 00 21 01 1d 03 0a a2 05 80 07 38 04 88 c2 39 55 1e 15 8f 7a 32 15 02 35 54 b0 5c b0 5c 00 36 12 78 22 00 14 ff 21 02 85 7f 07 9f 00 2f 00 1f 00 37 04 27 00 02 00 04 00 81 00 15 74 1a 00 00 03 00 28 3c 00 00 53 5a 53 5a 3c 00 00 00 00 00 00 2b 00 06 27 00 28 3b 00 00 2e 00 06 80 4b b0 5c b0 5c 00 00 00 00 00 00 00 00 00 89 90 BOE NV116FH1-M30 00 ff ff ff ff ff ff 00 09 e5 8c 38 01 ff 00 00 0c 24 01 04 a5 1a 0e 78 03 50 d5 9c 55 52 8f 27 15 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 9a 36 80 a0 70 38 28 40 30 20 35 00 00 90 10 00 00 1a 67 24 80 a0 70 38 28 40 30 20 35 00 00 90 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 36 ff 0a 3c 96 0f 0b 1a 96 00 00 00 01 cc 70 20 79 02 00 20 00 0c 9a 0e 00 8c 38 00 00 00 00 0c 1a 00 21 01 1d 03 0a a2 05 80 07 38 04 88 c2 39 55 1e 15 8f 7a 32 15 02 35 54 b0 5c b0 5c 00 36 12 78 22 00 14 ff 21 02 85 7f 07 9f 00 2f 00 1f 00 37 04 27 00 02 00 04 00 81 00 15 74 1a 00 00 03 00 28 3c 00 00 53 5a 53 5a 3c 00 00 00 00 00 00 2b 00 06 27 00 28 3b 00 00 2e 00 06 80 4b b0 5c b0 5c 00 00 00 00 00 00 00 00 00 88 90 Signed-off-by: Terry Hsiao Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20260608080310.15126-3-terry_hsiao@compal.corp-partner.google.com Signed-off-by: Sasha Levin commit 350761e9892f197eeeb140abcab8a0ed68cfc577 Author: Ryosuke Yasuoka Date: Mon Jun 1 16:53:15 2026 +0900 drm/virtio: abort virtqueue wait on device removal to avoid hung task [ Upstream commit a46991b334f663fa0e0e9c051e50587ef977ac8b ] virtio_gpu_queue_ctrl_sgs() and virtio_gpu_queue_cursor() use wait_event() without any abort condition when waiting for virtqueue space. If the host device stops processing commands, these waits block indefinitely inside a drm_dev_enter/exit() critical section. Since drm_dev_unplug(), which is called in device removal and system shutdown call path, blocks on synchronize_srcu() until all critical sections complete, device removal and system shutdown also hang. Add a vqs_released flag to virtio_gpu_device and include it in the wait_event() condition. Set the flag and wake up both queues in a new virtio_gpu_release_vqs() helper, called before drm_dev_unplug() in both virtio_gpu_remove() and virtio_gpu_shutdown(). When the flag is set, the wait returns immediately and the command is aborted, following the same cleanup path as drm_dev_enter() failure. Signed-off-by: Ryosuke Yasuoka Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260601-virtio-gpu_wait_event-v3-1-89530517a98a@redhat.com Signed-off-by: Sasha Levin commit d65d52d6370ee1675f4f8fbbcbe75c21d419038f Author: Jonas Karlman Date: Mon May 18 19:37:45 2026 +0000 drm/rockchip: dw_hdmi: Use resume_early pm ops for system suspend [ Upstream commit af3a9eadc11896f6677bcb7102bfb7c84be48d2d ] rockchip_drm_sys_resume()/drm_mode_config_helper_resume() is called before the resume pm ops of dw-hdmi. This result in an atomic_enable() before dw_hdmi_rockchip_resume()/dw_hdmi_resume() is called. Resume (without changes): - rockchip_drm_sys_resume() - drm_mode_config_helper_resume() - atomic_enable() - dw_hdmi_rockchip_resume() - dw_hdmi_resume() - dw_hdmi_init_hw() Change to use resume_early pm ops for system suspend to ensure pm ops for dw-hdmi is run before rockchip-drm pm ops. Also fix a possible NULL pointer dereference timing issue while at it. Resume (with changes): - dw_hdmi_rockchip_resume_early() - dw_hdmi_resume() - dw_hdmi_init_hw() - rockchip_drm_sys_resume() - drm_mode_config_helper_resume() - atomic_enable() Signed-off-by: Jonas Karlman Tested-by: Heiko Stuebner #rk3328 Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260518193748.2482823-12-jonas@kwiboo.se Signed-off-by: Sasha Levin commit 862d9268f40a6e10cef24eb226e738fb69ce8aa7 Author: YuanZhe Liu <25031212351@stu.xidian.edu.cn> Date: Tue Oct 13 14:35:54 2026 +0800 ALSA: line6: Clear prev_fbuf on capture buffer release commit aa118c8f61d59387961d58ffae831c5259a9f222 upstream. A KASAN slab-use-after-free read was reported in submit_audio_out_urb() when generating an impulse test signal: BUG: KASAN: slab-use-after-free in create_impulse_test_signal sound/usb/line6/playback.c:76 [inline] BUG: KASAN: slab-use-after-free in submit_audio_out_urb+0x1848/0x1b20 sound/usb/line6/playback.c:249 Read of size 2 at addr ffff888008d74870 by task syz.2.3214/7785 Allocated by task 11: kmem_cache_alloc_noprof+0x2f0/0x390 mm/slub.c:4144 line6_buffer_acquire+0x1a1/0x220 sound/usb/line6/pcm.c:158 line6_pcm_acquire+0xb6/0x230 sound/usb/line6/pcm.c:329 line6_startup_work+0x3c/0x50 sound/usb/line6/driver.c:728 Freed by task 7785: kfree+0xf8/0x390 mm/slub.c:6566 line6_buffer_release sound/usb/line6/pcm.c:176 [inline] line6_buffer_release+0xa5/0xf0 sound/usb/line6/pcm.c:170 __line6_pcm_release sound/usb/line6/pcm.c:305 [inline] line6_pcm_release+0x5a/0x80 sound/usb/line6/pcm.c:313 snd_toneport_monitor_put+0x11b/0x190 sound/usb/line6/toneport.c:183 line6pcm->prev_fbuf points into the capture PCM stream buffer (line6pcm->in.buffer), which is updated during audio_in_callback() to feed rate synchronization, software monitoring, and impulse test signal generation on playback side. When all capture streams are closed, line6_buffer_release() frees pstr->buffer with kfree(). However, it does not clear line6pcm->prev_fbuf. If playback is subsequently started (e.g. via impulse test signal volume control snd_line6_impulse_volume_put()), submit_audio_out_urb() dereferences the stale pointer line6pcm->prev_fbuf under in.lock, resulting in a slab-use-after-free read. Clear prev_fbuf and prev_fsize in line6_buffer_release() when releasing the capture stream buffer under in.lock, ensuring that no stale buffer pointer can be accessed by submit_audio_out_urb(). Fixes: 63e20df1e5b2 ("ALSA: line6: Reorganize PCM stream handling") Cc: stable@vger.kernel.org Co-developed-by: Bin Yu Signed-off-by: Bin Yu Co-developed-by: Cheng Wen Signed-off-by: Cheng Wen Signed-off-by: YuanZhe Liu <25031212351@stu.xidian.edu.cn> Link: https://patch.msgid.link/20261013063554.571-1-25031212351@stu.xidian.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit aff15e1f648e90bac17fd571cd4c48337929f49a Author: Tonghao Zhang Date: Sun Jan 18 12:21:12 2026 +0800 net: bonding: move bond_should_notify_peers, e.g. into rtnl lock block commit 70fc6649b36cf22167bbd7e2a6cc0960b746316e upstream. This patch tries to avoid the possible peer notify event loss. In bond_mii_monitor()/bond_activebackup_arp_mon(), when we hold the rtnl lock: - check send_peer_notif again to avoid unconditionally reducing this value. - send_peer_notif may have been reset. Therefore, it is necessary to check whether to send peer notify via bond_should_notify_peers() to avoid the loss of notification events. Cc: Jay Vosburgh Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Simon Horman Cc: Jonathan Corbet Cc: Andrew Lunn Cc: Nikolay Aleksandrov Cc: Hangbin Liu Cc: Jason Xing Signed-off-by: Tonghao Zhang Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/78cef328822b94638c97638b89011c507b8bf19e.1768709239.git.tonghao@bamaicloud.com Signed-off-by: Paolo Abeni Cc: Struan Bartlett Signed-off-by: Greg Kroah-Hartman commit 024b63ae8c6abb4399ad07c82c52bc2e8390c401 Author: Tonghao Zhang Date: Sun Jan 18 12:21:11 2026 +0800 net: bonding: use workqueue to make sure peer notify updated in lacp mode commit 11ea9b8a88dd7524c23dffc22d8173504273a9db upstream. The rtnl lock might be locked, preventing ad_cond_set_peer_notif() from acquiring the lock and updating send_peer_notif. This patch addresses the issue by using a workqueue. Since updating send_peer_notif does not require high real-time performance, such delayed updates are entirely acceptable. In fact, checking this value and using it in multiple places, all operations are protected at the same time by rtnl lock, such as - read send_peer_notif - send_peer_notif-- - bond_should_notify_peers By the way, rtnl lock is still required, when accessing bond.params.* for updating send_peer_notif. In lacp mode, resetting send_peer_notif in workqueue is safe, simple and effective way. Additionally, this patch introduces bond_peer_notify_may_events(), which is used to check whether an event should be sent. This function will be used in both patch 1 and 2. Cc: Jay Vosburgh Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Simon Horman Cc: Jonathan Corbet Cc: Andrew Lunn Cc: Nikolay Aleksandrov Cc: Hangbin Liu Cc: Jason Xing Suggested-by: Hangbin Liu Signed-off-by: Tonghao Zhang Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/f95accb5db0b10ce3ed2f834fc70f716c9abbb9c.1768709239.git.tonghao@bamaicloud.com Signed-off-by: Paolo Abeni Cc: Struan Bartlett Signed-off-by: Greg Kroah-Hartman commit 0160184fbf890e0c49080698e17451f5a8e29e26 Author: Christian Brauner Date: Wed Oct 28 16:47:03 2026 -0400 coredump: prevent TIF_NOTIFY_SIGNAL from interrupting coredumps [ Upstream commit a58d647acfdc62561f3570d114025b3bf38ae41b ] TIF_NOTIFY_SIGNAL is used to kick a task in uninterruptible sleep to return to userspace and run task work and then go back to sleep. This mechanism works well but breaks coredumps. dump_interrupted() only allows fatal signals to interrupt a coredump and the whole regular write path going to actual filesystems is impervious to TIF_NOTIFY_SIGNAL as well. However, both the usermodehelper pipe and the coredump socket will bail early on TIF_NOTIFY_SIGNAL. This affects the following codepaths: - coredump_sock_recv() -> unix_stream_read_generic() The request/ack handshake is abandoned before any coredump data is sent. - anon_pipe_write() returning -ERESTARTSYS Once the pipe is full this truncates the coredump. - unix_stream_sendmsg() returning -ERESTARTSYS Once the send buffer is full this truncates the coredump. - coredump_sock_wait() -> __kernel_read() This reports a failure that didn't happen. - wait_for_dump_helpers() -> wait_event_interruptible() This stops waiting for the coredump helpers. Such truncation is entirely invisible to userspace and all uapi bits still indicate that a successful coredump happened. A crashing process with a bunch of file backed mappings and io_uring thrown in loses most of the coredump data. If the NT_FILE note goes past PAGE_SIZE mappings it's gonzo. TIF_NOTIFY_SIGNAL is sent by io_uring for the common case. And it uses poll without sleeping so a completion callback runs task_work_add() from interrupt context against the task that submitted the request. This is the task that is running the coredump. Since that task hasn't set work_exited (it hasn't exited yet after all) TIF_NOTIFY_SIGNAL keeps reappearing. A coredumping task doesn't return to userspace. The task work is run at exit. So interrupting it doesn't buy anything and just loses the coredump which is quite valuable. Note that this isn't specific to io_uring. There's also klp_send_signals(), bpf_task_work_schedule_signal(), landlock's tsync and then technically, kthread_stop() and the printk kunit test set the bit raw. Link: https://patch.msgid.link/20260824-work-tif_notify_signal-v2-2-6609e42b3157@kernel.org Fixes: 12db8b690010 ("entry: Add support for TIF_NOTIFY_SIGNAL") Reviewed-by: Oleg Nesterov Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) [ sashal: adjusted context for inline coredump handling with override_creds() instead of scoped_with_creds(). ] Signed-off-by: Sasha Levin commit 64f2a38a1658493d7a53d656bcc483ee4b837623 Author: Christian Brauner Date: Wed Oct 28 14:35:33 2026 -0400 fork: don't create io threads once PF_POSTCOREDUMP is set [ Upstream commit 1f978881ce6c9ac4f4d4a7b6a6e52339eadcd350 ] zap_process() skips every thread that already has PF_POSTCOREDUMP set. Such a thread is past synchronize_group_exit(), so a coredump can't catch it anymore. It isn't counted in core_state->threads_remaining and it isn't sent SIGKILL. do_exit() sets PF_POSTCOREDUMP in synchronize_group_exit() and calls io_uring_files_cancel() right after that. The cancellation runs task work and a create_worker_cb() that io-wq queued before the exit creates a new io-wq worker from there. If another thread started a coredump in the meantime that worker joins a thread-group which is already being dumped. zap_process() never saw it so it was never counted. But when it exits it sees signal->core_state in synchronize_group_exit() and decrements threads_remaining like any other thread. So the count reaches zero one thread early and the dumper leaves coredump_wait_inactive() while a thread it counted is still running. The task has no fatal signal pending because zap_process() deliberately didn't send it one, and it never went through get_signal() so it doesn't have PF_SIGNALED either. Refuse to create an io thread when the creator has PF_POSTCOREDUMP. That costs nothing. io_uring_files_cancel() raises IO_WQ_BIT_EXIT before it runs any task work, so a worker created from there only ever gets to exit again, and io_should_retry_thread() doesn't retry -EINTR. Clearing PF_POSTCOREDUMP for the new thread in copy_process() was the other option. It makes the worker a thread like any other, but it only helps while the dump hasn't started. A worker born after zap_process() has run is invisible to it whatever its flags say and still decrements threads_remaining on the way out. Refusing to create it covers both, and then no task is ever born with the flag, so there is nothing to clear. Moving io_uring_files_cancel() ahead of synchronize_group_exit() closes the same window. It runs the cancellation, and whatever that can block on, before the thread announces itself to the dumper. A thread that blocks there never reaches coredump_task_exit() at all, so the dumper ends up waiting for a thread that never parks. Refusing the creation leaves the cancellation where it is. But it's very ugly to run io_uring work even before we did all the generic exit work. Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping core") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-14-8e4adb1619e6@kernel.org Acked-by: Oleg Nesterov Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit c3b9c90f32c5d7034d8e4f5544b0b82933ff7c39 Author: Christian Brauner Date: Wed Oct 28 14:35:32 2026 -0400 fork: move the coredump and exec checks into create_io_thread() [ Upstream commit e760200370e4de054b6b5f568a7faa911e2956bb ] Only a PF_USER_WORKER thread returns from get_signal() after a fatal signal and can go on to create a thread. get_signal() sets PF_SIGNALED before it dumps core and before it lets a PF_USER_WORKER thread return. That flags sticks. The exec'ing thread itself is never signaled. But it doesn't need the check anyway as we moved cancellation of io_uring requests before de_thread(). create_io_thread() is the only way a signaled thread creates another one. vhost_task_create() is reached from ioctls alone. io_should_retry_thread() doesn't retry -EINTR, so io-wq callers give up the same way they did when copy_process() refused. Suggested-by: Oleg Nesterov Link: https://lore.kernel.org/r/aq0VLTyxNatFmLOK@redhat.com Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-13-8e4adb1619e6@kernel.org Acked-by: Oleg Nesterov Signed-off-by: Christian Brauner (Amutable) Stable-dep-of: 1f978881ce6c ("fork: don't create io threads once PF_POSTCOREDUMP is set") Signed-off-by: Sasha Levin commit 4e023a26c613e456f1c200889934211bb4b679b8 Author: Christian Brauner Date: Wed Oct 28 15:43:45 2026 -0400 exec: cancel io_uring requests before de_thread() [ Upstream commit b42c85c20d84ff3e4f0f027d6596c3b3b4a20657 ] begin_new_exec() cancels the exec'ing thread's io_uring requests after de_thread() made it the only thread in the thread-group. Now io_uring_task_cancel() runs task work after. If it runs a create_worker_cb() item then a io-wq queued on the thread before the exec creates a new io-wq worker thread. Said thread joins the thread-group which de_thread() just took down. The io-iwq sticks around until it notices that its workqueue is dying. But code after de_thread() relies on being single-threaded. Move io_uring_task_cancel() before de_thread() but behind the point of no return. Any worker created during task work run from io_uring_task_cancel() is just a sibling thread that de_thread() will take down and reap. Once io_uring_task_cancel() returned the thread has neither a task context nor a workqueue left so nothing can add a thread behind de_thread()'s back anymore. Suggested-by: Oleg Nesterov Link: https://lore.kernel.org/r/aq0_lvHDViIpX_Mu@redhat.com Fixes: 3bfe6106693b ("io-wq: fork worker threads from original task") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260921-work-coredump-fixes-v3-12-8e4adb1619e6@kernel.org Acked-by: Oleg Nesterov Reviewed-by: Jens Axboe Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit e6223dfe62a222c999d64e05306415c46d728cfd Author: Guenter Roeck Date: Thu Jun 5 17:29:55 2025 -0700 hwmon: (lm90) Rely on subsystem locking [ Upstream commit e9b64fae44be190ea21c1092e96f316f90deb663 ] Attribute access is now serialized in the hardware monitoring core, so locking n the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 1a1ed9ba4386db6472ba743ef2014d66c301f8f4 Author: André Draszik Date: Thu Oct 29 11:03:26 2026 +0000 kbuild: link-vmlinux.sh: improve detection of third pass requirement commit 14b8b4bf2d7bd5d58c17adbeed0edfda1dfc1a7f upstream. It can happen that symbol sizes within .tmp_vmlinux1.kallsyms.o and .tmp_vmlinux2.kallsyms.o differ, without affecting file size on disk because of section alignment and/or padding emitted by the assembler. link-vmlinux.sh doesn't detect this case currently and keeps using .tmp_vmlinux2.kallsyms.o to link the final vmlinux. Due to the different symbol sizes, other symbols are shifted within the final image compared to .tmp_vmlinux2, and the final comparison of System.map against "${kallsyms_sysmap}" fails with the message: Inconsistent kallsyms data Try "make KALLSYMS_EXTRA_PASS=1" as a workaround This can happen in particular if the linker emits additional symbols that might have different names between our (re-)linking steps, e.g. because those names depend on the virtual address of the symbol. Linker stubs for ARM errata work-arounds are one such case. These changed symbol names can cause the output of the token compression of kallsyms.c to change due to the changed symbol substring count, which in turn can change the size of the kallsyms_names symbol itself, causing the potential shift of subsequent symbol addresses in .tmp_vmlinux2.kallsyms.o and therefore the final image. Update link-vmlinux.sh to not rely on file size of .tmp_vmlinux?.kallsyms.o alone but to also consider symbol offsets within to resolve this, and do a third pass if required. Signed-off-by: André Draszik Tested-by: Nathan Chancellor Reviewed-by: Nicolas Schier Signed-off-by: Nicolas Schier [AD: adjust context] Signed-off-by: André Draszik Signed-off-by: Sasha Levin commit 220705d574388b3c1361096ed9a5fac0d0651dbb Author: Ridham Khurana Date: Mon Sep 21 20:41:47 2026 +0000 platform: cznic: turris-omnia-mcu: Add missing MODULE_DEVICE_TABLE() [ Upstream commit 59797443846bc2451c35816026bbb79d281c9f23 ] The driver wires of_omnia_mcu_match into the i2c_driver's .of_match_table but never exports it with MODULE_DEVICE_TABLE(), so no module alias is generated and the module is not autoloaded when the MCU is probed from the device tree. Found by code inspection. Not tested on the hardware itself; with the module built, the alias lookup $ modprobe -R 'of:Nsystem-controllerT(null)Ccznic,turris-omnia-mcu' reports no match before this change and resolves to turris_omnia_mcu after it. Fixes: 992f1a3d4e88 ("platform: cznic: Add preliminary support for Turris Omnia MCU") Signed-off-by: Ridham Khurana Link: https://patch.msgid.link/20260921204204.797294-1-khurana.ridham222@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit fb1e15ddd94ced53fb000283f1d2bf658eb42b97 Author: Daniel Schaefer Date: Thu Jul 23 01:18:58 2026 +0800 iio: hid-sensor: als: scale each channel individually [ Upstream commit cad928dad9a4c26aa56b4223dc2a29bca517fb5f ] Some sensors have multiple channels (not just brightness but color ALS sensors) with different scaling factors. Signed-off-by: Daniel Schaefer Link: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/merge_requests/413 Tested-by: Sven Vainküla #Asus ProArt PX13 laptop. Acked-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 62be46110a2c2bbbe08d4fb70c243bb67f1c9115 Author: Baolin Wang Date: Wed Oct 28 00:39:03 2026 +0800 mm: vmscan: fix dirty folios throttling on cgroup v1 for MGLRU [ Upstream commit 13b6b620910436c29dea398382e83c9499fd13e4 ] The balance_dirty_pages() won't do the dirty folios throttling on cgroupv1. See commit 9badce000e2c ("cgroup, writeback: don't enable cgroup writeback on traditional hierarchies"). Moreover, after commit 6b0dfabb3555 ("fs: Remove aops->writepage"), we no longer attempt to write back filesystem folios through reclaim. On large memory systems, the flusher may not be able to write back quickly enough. Consequently, MGLRU will encounter many folios that are already under writeback. Since we cannot reclaim these dirty folios, the system may run out of memory and trigger the OOM killer. Hence, for cgroup v1, let's throttle reclaim after waking up the flusher, which is similar to commit 81a70c21d917 ("mm/cgroup/reclaim: fix dirty pages throttling on cgroup v1"), to avoid unnecessary OOM. The following test program can easily reproduce the OOM issue. With this patch applied, the test passes successfully. $mkdir /sys/fs/cgroup/memory/test $echo 256M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes $echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs $dd if=/dev/zero of=/mnt/data.bin bs=1M count=800 Link: https://lore.kernel.org/3445af0f09e8ca945492e052e82594f8c4f2e2f6.1774606060.git.baolin.wang@linux.alibaba.com Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") Signed-off-by: Baolin Wang Reviewed-by: Barry Song Reviewed-by: Kairui Song Acked-by: Johannes Weiner Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: David Hildenbrand Cc: Lorenzo Stoakes (Oracle) Cc: Michal Hocko Cc: Qi Zheng Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton Signed-off-by: Leno Hou Signed-off-by: Sasha Levin commit 49675f7bc0e1ae12a60f6af5cb2b800eb39fe055 Author: Namjae Jeon Date: Wed Sep 30 20:39:53 2026 +0900 ksmbd: wait for negotiation before receiving another PDU [ Upstream commit 68f410faedaf6ee74d81e574733c50ebcc1bd8ed ] The receive thread queues a request and can read the next PDU before the negotiation worker finishes. While need_neg is set, the next PDU can cause ksmbd_init_smb_server() to replace conn->ops. A pipelined SMB2 request can therefore make the worker handle an earlier, shorter SMB1 request with SMB2 operations and read beyond its buffer. An SMB1 multi-protocol negotiate may be followed by an SMB2 NEGOTIATE that changes conn->ops again. Wait for work queued while the connection is new or needs negotiation to complete before reading another PDU. This keeps the operations stable for both stages of negotiation without changing when need_neg is cleared. Fixes: dc8289f91238 ("ksmbd: fix slab-out-of-bounds in init_smb2_rsp_hdr") Reported-by: ihopenre-eng Reviewed-by: ihopenre-eng Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 1c623e3cbf43f12dd4a72712079bfa247a9b8ba3 Author: Zizhen Liu Date: Thu Oct 22 18:42:17 2026 +0800 net: skbuff: propagate shared-frag marker in skb_zerocopy() commit 79dc34beb1fdb3da79753e51e15c68591a2561fe upstream. skb_zerocopy() moves frag descriptors from @from into @to and takes a reference on each frag, but it does not copy skb_shinfo(from)->flags into skb_shinfo(to)->flags. A destination skb holding the same page-cache backed frags as the source therefore reports skb_has_shared_frag() as false. That breaks the invariant relied on by later in-place writers. ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(); with the marker lost, an skb that skb_zerocopy() built for nfnetlink_queue or for an openvswitch upcall is decrypted in place, letting an unprivileged user write into the page cache of a root-owned read-only file. Propagate SKBFL_SHARED_FRAG when frag descriptors are copied, as done for the other frag-transfer helpers. Fixes: af2806f8f90a ("net: Export skb_zerocopy() to zerocopy from one skb to another") Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Cc: stable@kernel.org Signed-off-by: Zizhen Liu Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20261022104217.1852191-1-pointerliu@126.com Signed-off-by: Jakub Kicinski [ sashal: Adjusted context in skb_zerocopy() due to missing from->unreadable propagation. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman